Deunan wrote on 2023-07-21, 22:13:

I wish my 386SX was this fast, sadly it's just a 40MHz system. This bug was also present in 6.2.0 version. Also, does HWiNFO nee […]
Show full quote

Copy code to clipboard

1                                 HWiNFO v6.2.2 
2  █████████████████████████████System Information█████████████████████████████
3  ║                                                                          ║
4  ║ Main Processor:           Intel 80386SX, 100.0 MHz                       ║
5  ║ Math Co-Processor:        Cyrix FasMath 83S87 Old, 100.0 MHz             ║

I wish my 386SX was this fast, sadly it's just a 40MHz system. This bug was also present in 6.2.0 version.
Also, does HWiNFO need more than 4M on PCI systems to run? I also get a memory error with 8M - that there's not enough XMS memory, but it works when HIMEM is loaded. With more than 8M program works with and without HIMEM.

Please provide the HWiNFO LOG + Debug File for analysis.

Per HWiNFO for DOS resurrected !
Requirements for HWiNFO DOS:
- 386 CPU
- ~ 550 KB of free Conventional system memory
- ~ 830 KB (Non-PCI systems) / 5 MB (PCI systems) free XMS memory (XMS manager recommended)

Mumak wrote on 2023-07-21, 22:24:

Please provide the HWiNFO LOG + Debug File for analysis.

There you go - HWINFO.7z. The NPU is GREEN MATH 4C87SLC-40

Mumak wrote on 2023-07-21, 22:24:

- ~ 830 KB (Non-PCI systems) / 5 MB (PCI systems) free XMS memory (XMS manager recommended)

Well, I might have a lead on that memory issue. It was happening on a particular mobo (AP43) and I've just noticed that HWiNFO reports less free memory than there is installed, by about 2M, but correctly reports all SIMMs. See HWINFO_AP43.7z.
This is not just HWINFO issue though, some other programs also report only 14M out of 16 installed when running without HIMEM, like System Speed Test Ver 4.78. On the other hand CACHECHK tests all 16 megs and reports this:

1 CMOS reports: conv_mem= 640K, ext_mem= 15,360K, Total RAM= 16,000K
2 BIOS reports:                 ext_mem= 15,360K  Total mem: 16 MB

So I thought it might be a BIOS issue but why does it affect only certain programs? It's on this mobo, with 8M installed, that HWiNFO works with HIMEM loaded but complains about free XMS memory without it (and quits). Sadly I can't provide a debug log at this time, this mobo is now at a different location. But I will have it back eventually.

Deunan wrote on 2023-07-22, 10:12:

There you go - HWINFO.7z. The NPU is GREEN MATH 4C87SLC-40 […]
Show full quote

Mumak wrote on 2023-07-21, 22:24:

Please provide the HWiNFO LOG + Debug File for analysis.

There you go - HWINFO.7z. The NPU is GREEN MATH 4C87SLC-40

Mumak wrote on 2023-07-21, 22:24:

- ~ 830 KB (Non-PCI systems) / 5 MB (PCI systems) free XMS memory (XMS manager recommended)

Well, I might have a lead on that memory issue. It was happening on a particular mobo (AP43) and I've just noticed that HWiNFO reports less free memory than there is installed, by about 2M, but correctly reports all SIMMs. See HWINFO_AP43.7z.
This is not just HWINFO issue though, some other programs also report only 14M out of 16 installed when running without HIMEM, like System Speed Test Ver 4.78. On the other hand CACHECHK tests all 16 megs and reports this:

Copy code to clipboard

1 CMOS reports: conv_mem= 640K, ext_mem= 15,360K, Total RAM= 16,000K
2 BIOS reports:                 ext_mem= 15,360K  Total mem: 16 MB

So I thought it might be a BIOS issue but why does it affect only certain programs? It's on this mobo, with 8M installed, that HWiNFO works with HIMEM loaded but complains about free XMS memory without it (and quits). Sadly I can't provide a debug log at this time, this mobo is now at a different location. But I will have it back eventually.

Thanks for the reports.
I have to admit that I have no idea why the CPU clock on 386SX is reported so off. This is measured using the 8253 Timer (counter 2) and it seems that on some systems this gives incorrect results. Maybe try to disable the CPU Reset Method 1 if that causes some issue with timers.. As for the FPU, that can't be detected using software means. It's clock is affected the same way as CPU so it might indicate some issue with the system timer..

The issue with memory size might be a BIOS bug. There are different methods to determine available XMS size, mostly via BIOS calls. So maybe there's some bug or the BIOS reserves some region of the XMS memory.

That's OK, Landmark also glitches more than usual on that mobo, it shows a CPU bar around 54 (and reports that as the AT-equivalent speed) but the text near the bar is also "100.0". But then again, it's Landmark.
I don't much care about the reported speed, I know it's a 40MHz system (with no other clock straps) and I have other programs that confirm that, I just figured I'll report it in case it's easy to fix.

As for the AP43 mobo, I only run a clean system for benchmarks, and AFAIR Quake is also not detecing the full memory size in that case, so it must be something in this BIOS. Since for any other use it will have HIMEM loaded this is not an issue, just a curiosity FYI. Just one more thing, now I see there's something like a half page blank in the AP43 report, looks like some text is missing after "INTC Compability Select". This is also the case with other CPUs on this mobo so it's not a one-time glitch in that particular report. You might want to look into this.

I also have a feature request - would it be possible to make a screenshot key like F2 but have it output full report page, not just what is on the screen? Example: IDE Drive Physical Information - on typical 25 rows screen the F2 output to file will be cut at the "DMA Transfer Modes" line. Nothing past that is written and the the DMA speeds (and all the extra features) are not listed. So I'd like to be able to generate a full output from this page, even on 25 rows display, without having to run with /R switch and waiting for the complete system test (and then having to find the info in the 80k text file).

I'm still curious as to why the clock is not properly measured. Can you try to disable "Use Method 1 to Reset CPU.." in HWiNFO menu "Setup" -> "Configuration" to check if that's maybe causing it?

The text missing after "INTC Compability Select" might be due to insufficient free memory.

Deunan wrote on 2023-07-22, 21:44:

That's OK, Landmark also glitches more than usual on that mobo, it shows a CPU bar around 54 (and reports that as the AT-equival […]
Show full quote

That's OK, Landmark also glitches more than usual on that mobo, it shows a CPU bar around 54 (and reports that as the AT-equivalent speed) but the text near the bar is also "100.0". But then again, it's Landmark.
I don't much care about the reported speed, I know it's a 40MHz system (with no other clock straps) and I have other programs that confirm that, I just figured I'll report it in case it's easy to fix.

As for the AP43 mobo, I only run a clean system for benchmarks, and AFAIR Quake is also not detecing the full memory size in that case, so it must be something in this BIOS. Since for any other use it will have HIMEM loaded this is not an issue, just a curiosity FYI. Just one more thing, now I see there's something like a half page blank in the AP43 report, looks like some text is missing after "INTC Compability Select". This is also the case with other CPUs on this mobo so it's not a one-time glitch in that particular report. You might want to look into this.

I also have a feature request - would it be possible to make a screenshot key like F2 but have it output full report page, not just what is on the screen? Example: IDE Drive Physical Information - on typical 25 rows screen the F2 output to file will be cut at the "DMA Transfer Modes" line. Nothing past that is written and the the DMA speeds (and all the extra features) are not listed. So I'd like to be able to generate a full output from this page, even on 25 rows display, without having to run with /R switch and waiting for the complete system test (and then having to find the info in the 80k text file).

I was totally puzzled with the wrong CPU clock and analyzed all possible cases.. Till I found something interesting! HWiNFO actually properly measures the clock and gets an accurate result. But when trying to translate the numbers into MHz via floating point math something goes wrong. So it seems that it's actually the FPU giving out wrong numbers! I don't know why is that - if it's always happening, or due to some action done by HWiNFO the FPU goes weird.. Would be interesting to get results with disabled Reset 1/2/3 options in the HWiNFO options.

Mumak wrote on 2023-07-24, 13:29:

I was totally puzzled with the wrong CPU clock and analyzed all possible cases.. Till I found something interesting! HWiNFO actually properly measures the clock and gets an accurate result. But when trying to translate the numbers into MHz via floating point math something goes wrong. So it seems that it's actually the FPU giving out wrong numbers! I don't know why is that - if it's always happening, or due to some action done by HWiNFO the FPU goes weird.. Would be interesting to get results with disabled Reset 1/2/3 options in the HWiNFO options.

I've run some tests. Disabling reset options does nothing. Removing the NPU from socket fixes the clock issue, and also un-glitches Landmark bars. Interestingly it's not even required to remove the NPU, setting it to Absent in BIOS will work too. Landmark will then fail to detect it but HWiNFO does, with a 21.8MHz clock and 40.1 clock for the 386SX. I suppose this is compiler/C-lib related and now the code to convert the numbers for display runs purely in software.

Sadly this mobo is going to long term storage now, I need space, I've removed the battery already so running any more tests will have to wait. Perhaps even Wait, with capital W.
I might return to it eventually as PARANOIA NPU/FPU test shows some erros pretty early (like X * 1/X results, or X*Y == Y*X pairs also fails) and then the Overflow treshold test just hangs. So this silicon is not that great actually, even if it does run at 40MHz and seems to produce correct fractals in my own testing suite. It's probably not a faulty chip but rather one not in-spec when it comes to corner cases and LSB rounding. All in all though this is clearly not HWiNFO issue then, sorry for wasting your time.

As for AP43 report and missing text, do you mean it has run out of low memory? Under 1M that is. I didn't check if the clean DOS 6.22 provides the required 550k or not on that mobo, but on other ones such configuration results in 561k even with NC loaded, and that particular run was done with 12M of RAM in total. So I'm not sure why it would run out of memory?

Deunan wrote on 2023-07-24, 15:20:

I've run some tests. Disabling reset options does nothing. Removing the NPU from socket fixes the clock issue, and also un-glitc […]
Show full quote

Mumak wrote on 2023-07-24, 13:29:

I was totally puzzled with the wrong CPU clock and analyzed all possible cases.. Till I found something interesting! HWiNFO actually properly measures the clock and gets an accurate result. But when trying to translate the numbers into MHz via floating point math something goes wrong. So it seems that it's actually the FPU giving out wrong numbers! I don't know why is that - if it's always happening, or due to some action done by HWiNFO the FPU goes weird.. Would be interesting to get results with disabled Reset 1/2/3 options in the HWiNFO options.

I've run some tests. Disabling reset options does nothing. Removing the NPU from socket fixes the clock issue, and also un-glitches Landmark bars. Interestingly it's not even required to remove the NPU, setting it to Absent in BIOS will work too. Landmark will then fail to detect it but HWiNFO does, with a 21.8MHz clock and 40.1 clock for the 386SX. I suppose this is compiler/C-lib related and now the code to convert the numbers for display runs purely in software.

Sadly this mobo is going to long term storage now, I need space, I've removed the battery already so running any more tests will have to wait. Perhaps even Wait, with capital W.
I might return to it eventually as PARANOIA NPU/FPU test shows some erros pretty early (like X * 1/X results, or X*Y == Y*X pairs also fails) and then the Overflow treshold test just hangs. So this silicon is not that great actually, even if it does run at 40MHz and seems to produce correct fractals in my own testing suite. It's probably not a faulty chip but rather one not in-spec when it comes to corner cases and LSB rounding. All in all though this is clearly not HWiNFO issue then, sorry for wasting your time.

As for AP43 report and missing text, do you mean it has run out of low memory? Under 1M that is. I didn't check if the clean DOS 6.22 provides the required 550k or not on that mobo, but on other ones such configuration results in 561k even with NC loaded, and that particular run was done with 12M of RAM in total. So I'm not sure why it would run out of memory?

Thanks for confirming my assumption. I was scratching my head so long because non-working basic math isn't something that I'd expect 😁

The AP43 report issue could be both - either system or XMS memory low. It's using both to buffer the memory and hard to say which one of them was low.

I observed some somewhat reproducible freezes on my Win 98 SE on an ASUS P2B-S: I had an Elasa Winner 2000 Pro/X PCI graphics (S3 Vision968) card plugged in and HWiNFO 7.62 and 7.66 froze the whole system every time during 'Analyzing PCI Bus'. Once I swapped for a Rage XL AGP it worked fine. However sometimes I got it working with the W2000Pro plugged in by swapping some other Hardware around as well but never as reliably as without the W2000Pro (it never froze on me with it not plugged in). I created a debug report and attached it, I hope it helps.

Also what surprises me is that HWiNFO still detects some ISA PnP-devices long after I have unplugged them while the Windows device manager doesn't show them. Is this the expected behavior?

P4C800 wrote on 2023-11-18, 15:29:

I observed some somewhat reproducible freezes on my Win 98 SE on an ASUS P2B-S: I had an Elasa Winner 2000 Pro/X PCI graphics (S3 Vision968) card plugged in and HWiNFO 7.62 and 7.66 froze the whole system every time during 'Analyzing PCI Bus'. Once I swapped for a Rage XL AGP it worked fine. However sometimes I got it working with the W2000Pro plugged in by swapping some other Hardware around as well but never as reliably as without the W2000Pro (it never froze on me with it not plugged in). I created a debug report and attached it, I hope it helps.

Also what surprises me is that HWiNFO still detects some ISA PnP-devices long after I have unplugged them while the Windows device manager doesn't show them. Is this the expected behavior?

Try to increase the PCI Latency Timer in BIOS if it has such option, that helped on some systems with such issues.
Regarding the ISA PnP devices - depends on which exact devices in HWiNFO you mean - a screenshot might be helpful.