phantom_pl wrote on 2020-05-04, 16:18:

In my case nothing is fixed 🙁
Both boards (FIC 486-GVT-2 and Shuttle HOT-409) report and display wrong CPU clock (FIC is almost there in the report, but not on the display).
Report + HWiNFO printscreens + CHKCPU before&after screens are attached.

I haven't been able to determine why is this yet, but I have added a new feature - Debug Mode.
Please run this new build including the -d parameter. That will also produce a file called HWINFO.DBG, which includes more insider details that might help me to determine what's going on there.
Please run HWINFO twice with this parameter: along with the -r parameter and without it in case it's showing different clock speeds while running manually and in automatic report generation mode.
Don't forget to backup the DBG file produced from previous run since a new run will overwrite it.
Also when running manually, it should be sufficient to just open the Mainboard info screen and btw you don't need to take photos of the screen - pressing the F2 key will save the content of the actual screen into HWINFO.LOG
[build pulled, newer available]

Mumak wrote on 2020-05-04, 18:19:

I haven't been able to determine why is this yet, but I have added a new feature - Debug Mode. Please run this new build includi […]
Show full quote

phantom_pl wrote on 2020-05-04, 16:18:

In my case nothing is fixed 🙁
Both boards (FIC 486-GVT-2 and Shuttle HOT-409) report and display wrong CPU clock (FIC is almost there in the report, but not on the display).
Report + HWiNFO printscreens + CHKCPU before&after screens are attached.

I haven't been able to determine why is this yet, but I have added a new feature - Debug Mode.
Please run this new build including the -d parameter. That will also produce a file called HWINFO.DBG, which includes more insider details that might help me to determine what's going on there.
Please run HWINFO twice with this parameter: along with the -r parameter and without it in case it's showing different clock speeds while running manually and in automatic report generation mode.
Don't forget to backup the DBG file produced from previous run since a new run will overwrite it.
Also when running manually, it should be sufficient to just open the Mainboard info screen and btw you don't need to take photos of the screen - pressing the F2 key will save the content of the actual screen into HWINFO.LOG
HWINF610.ZIP

Just wanted to say I appreciate the work you're doing! It could be pretty sweet to get old hardware running again and all, at least to find the correct drivers hah

Debugs done.
Attached together with CHKCPU debug screenshot.

phantom_pl wrote on 2020-05-05, 05:14:

Debugs done.
Attached together with CHKCPU debug screenshot.

Thanks! I'm staring at the data, analyzing, yet still have no clue why is this happening 🙁

It seems, that the older system is, the more uphill road is, and more obstacles you meet 😀

phantom_pl wrote on 2020-05-05, 06:55:

It seems, that the older system is, the more uphill road is, and more obstacles you meet 😀

Yes, indeed. I guess this is also down to the fact that despite those systems being rather simple, they are often plagued with various compatibility issues due to the lack of compliance with advanced/universal standards.

phantom_pl wrote on 2020-05-05, 06:55:

It seems, that the older system is, the more uphill road is, and more obstacles you meet 😀

I did some updates to clock measurement code, could you please try the following build again on the DX4?
[build pulled, newer available]

I'm sorry, still needs work 🙁

phantom_pl wrote on 2020-05-06, 05:37:

I'm sorry, still needs work 🙁

Thanks. Could you please make one more test with the FIC board:
1. Start HWiNFO manually and at the welcome screen just hit Enter. Don't open any item in the menu, instead just hit Esc to exit the application.
2. Then right after that start it to automatically create report (-d -r). Wondering if that will contain correct clock then.

Also, if you run it 2 times in a row with automatic report mode, will the second report also contain a correct clock?

Another thing, I'm not sure if I asked you about this, but is the situation same if you disable all Reset methods in HWiNFO?

Retested, but still wrong 🙁
All reset methods were this time disabled, previous times they were at default (method 1 and 3 active).

I have noticed one strange problem concerning this build (in my opinion).
If I try to open HWiNFO without any parameter, from command line I got on the screen information, that HWINFO.DAT file is damaged.
If I however, run HWiNFO with parameters (-d, -r, or both) it runs just fine, also if I start file manager first (Norton Commander in this case) and then start HWiNFO it also runs just without problems.

regards

phantom_pl wrote on 2020-05-06, 08:54:

Retested, but still wrong :-( All reset methods were this time disabled, previous times they were at default (method 1 and 3 act […]
Show full quote

Retested, but still wrong 🙁
All reset methods were this time disabled, previous times they were at default (method 1 and 3 active).

I have noticed one strange problem concerning this build (in my opinion).
If I try to open HWiNFO without any parameter, from command line I got on the screen information, that HWINFO.DAT file is damaged.
If I however, run HWiNFO with parameters (-d, -r, or both) it runs just fine, also if I start file manager first (Norton Commander in this case) and then start HWiNFO it also runs just without problems.

regards

Thanks. Such a message about corrupted DAT file could mean some problem with memory. HWINFO has read the data into memory, but subsequent CRC check shows an error.
So I'm starting to wonder whether that system is otherwise running stable. Perhaps some issues seen in HWiNFO are related to some instability.

Mumak wrote on 2020-05-06, 12:52:

Thanks. Such a message about corrupted DAT file could mean some problem with memory. HWINFO has read the data into memory, but subsequent CRC check shows an error.
So I'm starting to wonder whether that system is otherwise running stable. Perhaps some issues seen in HWiNFO are related to some instability.

After reading your remarks about possible memory errors , and stability issues I have done further investigation, and here are the results:

1. Bad memory is not an issue, I just have run 3 passes of MemTest, and there were no errors
2. System has been changed (in BIOS) from setup defaults, to slowest possible settings to ensure maximum stability
3. Memory manager is an issue. If no memory manager was installed – there was no errors; if HimemX.exe has been used – no errors; if Himem.sys has been used – there was an error (same as previously reported; it didn’t hang the system, I could exit HWiNFO an run it again)
4. I thought that I had a corrupted Himem.sys file, so I extracted a fresh one form DOS install disk, but it didn’t help - still error.
5. I started system from floppy WITH Himem.sys installed –and there was NO error!

It seems that two VLB boards, even at slowest settings may be too much for this board.
I have no more time for tests now 🙁, but I will check in next week if changing VLB IDE controller to an ISA one , or installing a single VLB combo card will fix Himem.sys error.
Back to the results – I have done tests for 2 memory managers (HimemX is with and without CPU detection), and clean system with no drivers. All results seem to me the same - ~95 MHz (both on the screen, and in the report). That’s pretty close.

regards

P.S. HimemX, and clean systems were booted from HDD, Himem was booted from floppy.

phantom_pl wrote on 2020-05-06, 13:08:

After reading your remarks about possible memory errors , and stability issues I have done further investigation, and here are t […]
Show full quote

Mumak wrote on 2020-05-06, 12:52:

Thanks. Such a message about corrupted DAT file could mean some problem with memory. HWINFO has read the data into memory, but subsequent CRC check shows an error.
So I'm starting to wonder whether that system is otherwise running stable. Perhaps some issues seen in HWiNFO are related to some instability.

After reading your remarks about possible memory errors , and stability issues I have done further investigation, and here are the results:

1. Bad memory is not an issue, I just have run 3 passes of MemTest, and there were no errors
2. System has been changed (in BIOS) from setup defaults, to slowest possible settings to ensure maximum stability
3. Memory manager is an issue. If no memory manager was installed – there was no errors; if HimemX.exe has been used – no errors; if Himem.sys has been used – there was an error (same as previously reported; it didn’t hang the system, I could exit HWiNFO an run it again)
4. I thought that I had a corrupted Himem.sys file, so I extracted a fresh one form DOS install disk, but it didn’t help - still error.
5. I started system from floppy WITH Himem.sys installed –and there was NO error!

It seems that two VLB boards, even at slowest settings may be too much for this board.
I have no more time for tests now 🙁, but I will check in next week if changing VLB IDE controller to an ISA one , or installing a single VLB combo card will fix Himem.sys error.
Back to the results – I have done tests for 2 memory managers (HimemX is with and without CPU detection), and clean system with no drivers. All results seem to me the same - ~95 MHz (both on the screen, and in the report). That’s pretty close.

regards

P.S. HimemX, and clean systems were booted from HDD, Himem was booted from floppy.

Thanks for your time and the extensive testing !
Now it looks much better. Even though the results slightly differ between runs (it's varying between 95-99 MHz), it looks like the problem is indeed something with the board and/or VLB. HWiNFO is most likely triggering something that's causing fluctuations that normally should not occur. I'm still not sure what exactly that is, but it would be quite difficult to determine it remotely. And because this issue seems to be system rather than software related, I don't think I'm going to waste more of your and mine time to search for some workaround.
BTW, I just found an issue in detection of some Award BIOS mainboards, I will upload a new build in the HWiNFO for DOS thread so that everyone else can grab it.

First, it is You, who should be thanked, for going deeper, and deeper into the rabbit hole, and spending time (a lot of), and writing more, and more, and more builds of your magnificent program 😊

I am not entirely convinced, that this is only a question of this particular system instability(why only this one CPU, why some other diagnostic software works?), but I agree, that spending more and more time to fix this one particular system makes little sense.

Sometimes I think, that we do not take into account, that we are dealing with really elderly systems, that has its own problems resulting from its age (often a very respectable one). There are dozens (or even hundreds) elements like capacitors, resistors, diodes, etc., that may fail, or lose its nominal parameters after all this years.
I earlier wrote, that I do not believe that this is only a system fault (and I keep this), BUT I wouldn't cut my head either, that this system works the same, as when it was new.
When we couple a pre-standardized design of early boards with its truly unknown technical state; we see the full scale of problems diagnostic software has to deal with.

Regards

phantom_pl wrote on 2020-05-11, 18:43:

First, it is You, who should be thanked, for going deeper, and deeper into the rabbit hole, and spending time (a lot of), and wr […]
Show full quote

First, it is You, who should be thanked, for going deeper, and deeper into the rabbit hole, and spending time (a lot of), and writing more, and more, and more builds of your magnificent program 😊

I am not entirely convinced, that this is only a question of this particular system instability(why only this one CPU, why some other diagnostic software works?), but I agree, that spending more and more time to fix this one particular system makes little sense.

Sometimes I think, that we do not take into account, that we are dealing with really elderly systems, that has its own problems resulting from its age (often a very respectable one). There are dozens (or even hundreds) elements like capacitors, resistors, diodes, etc., that may fail, or lose its nominal parameters after all this years.
I earlier wrote, that I do not believe that this is only a system fault (and I keep this), BUT I wouldn't cut my head either, that this system works the same, as when it was new.
When we couple a pre-standardized design of early boards with its truly unknown technical state; we see the full scale of problems diagnostic software has to deal with.

Regards

Thanks for your kind words. I think this is an issue of both - the system and software that's triggering something that causes clock fluctuation. Unfortunately to determine what exactly is causing this without having direct access to such system and tracing this step-by-step would require dozens of additional builds and tests.
I'm still thinking about acquiring a DX2/DX4 VLB system, but the chances to reproduce this on another system are probably quite low. My oldest system is currently a dual P5-90 with genuine FDIV bug 😀 That allowed me to tune detection of several graphics cards that I acquired recently. It has become a quite expensive test set..

Hi, on my Gigabyte EP45-UD3P, HWInfo doesn't display the right memory clock.
I'm using two sticks of DDR2-667 running at 800. FSB is at 400.
So it should show 400 MHz and 1:1 ratio, but instead shows 600 MHz and 3:2 ratio.

Anyway, CPU-Z does show this correctly.

repaxan wrote on 2020-05-12, 05:14:

Hi, on my Gigabyte EP45-UD3P, HWInfo doesn't display the right memory clock. I'm using two sticks of DDR2-667 running at 800. FS […]
Show full quote

Hi, on my Gigabyte EP45-UD3P, HWInfo doesn't display the right memory clock.
I'm using two sticks of DDR2-667 running at 800. FSB is at 400.
So it should show 400 MHz and 1:1 ratio, but instead shows 600 MHz and 3:2 ratio.

Anyway, CPU-Z does show this correctly.

This is because of FSB overclocking. The memory controller doesn't seem to reflect correct FSB setting (it's set for 266 FSB). Not sure whether this is the correct configuration, but I'll add a workaround for this.

Mumak wrote on 2020-05-12, 06:36:

repaxan wrote on 2020-05-12, 05:14:

Hi, on my Gigabyte EP45-UD3P, HWInfo doesn't display the right memory clock. I'm using two sticks of DDR2-667 running at 800. FS […]
Show full quote

Hi, on my Gigabyte EP45-UD3P, HWInfo doesn't display the right memory clock.
I'm using two sticks of DDR2-667 running at 800. FSB is at 400.
So it should show 400 MHz and 1:1 ratio, but instead shows 600 MHz and 3:2 ratio.

Anyway, CPU-Z does show this correctly.

This is because of FSB overclocking. The memory controller doesn't seem to reflect correct FSB setting (it's set for 266 FSB). Not sure whether this is the correct configuration, but I'll add a workaround for this.

The original FSB is 333, I overclocked it to 400, and set the '(G)MCH Frequency Latch' is to 400 as well. So it's definitely weird that it's showing 266.

repaxan wrote on 2020-05-12, 06:57:

Mumak wrote on 2020-05-12, 06:36:

repaxan wrote on 2020-05-12, 05:14:

Hi, on my Gigabyte EP45-UD3P, HWInfo doesn't display the right memory clock. I'm using two sticks of DDR2-667 running at 800. FS […]
Show full quote

Hi, on my Gigabyte EP45-UD3P, HWInfo doesn't display the right memory clock.
I'm using two sticks of DDR2-667 running at 800. FSB is at 400.
So it should show 400 MHz and 1:1 ratio, but instead shows 600 MHz and 3:2 ratio.

Anyway, CPU-Z does show this correctly.

This is because of FSB overclocking. The memory controller doesn't seem to reflect correct FSB setting (it's set for 266 FSB). Not sure whether this is the correct configuration, but I'll add a workaround for this.

The original FSB is 333, I overclocked it to 400, and set the '(G)MCH Frequency Latch' is to 400 as well. So it's definitely weird that it's showing 266.

Hum, I checked the documents and your setting of FSB ratio isn't even documented in the BIOS specification 😀

Mumak wrote on 2020-05-12, 08:40:

Hum, I checked the documents and your setting of FSB ratio isn't even documented in the BIOS specification :)

It's in the motherboard manual, page 39 shows the BIOS screen and page 42 has the description:

https://download1.gigabyte.com/Files/Manual/m … ep45-ud3p_e.pdf