red-ray wrote on 2020-12-15, 14:21:

When I looked some more at the save file I noticed that MSR 0000001B is returned as zero and as this is the APIC base it should never be zero. As a result of this SIV did not even try to read any of the other MSRs as it deduced the CPU was not a real CPU and therefore unlikely to return anything useful in the MSRs. Which MSRs are implemented?

The APIC is not emulated yet, which is why MSR 1B is implemented as read-only and always 0. I was more concerned about SIV trying to read unimplemented MSRs and resulting in a BSOD (UNEXPECTED_KERNEL_MODE_TRAP with parameter 0x0000000D) but that's clearly an emulation issue since you do catch the GPF exceptions.

If you're really curious about what MSRs are implemented, here's WRMSR and RDMSR for P6 CPUs. I didn't write these, but the people who did usually amend the MSR implementation on demand, whenever a BIOS or an application shows up requiring a specific MSR (MTRRs are notably not implemented but will be in the future because I ran into the Coreboot BIOS which requires them).

red-ray wrote on 2020-12-15, 14:21:

Your Intel 82443BX 440BX Chipset PCI to AGP Bridge - Vendor ID 8086-7191 is incorrect as 0F to 17 are reserved and should be zero. The values present result in impossible BAR 0 settings.

Noted. Thanks for all the insight.

RichardG867 wrote on 2020-12-17, 18:25:

I was more concerned about SIV trying to read unimplemented MSRs and resulting in a BSOD (UNEXPECTED_KERNEL_MODE_TRAP with parameter 0x0000000D) but that's clearly an emulation issue since you do catch the GPF exceptions.

The MSR implementations are WRMSR and RDMSR for P6 CPUs.

Yes, stopping the BSOD would be my top priority and suspect once you have done this many more hardware reporting programs will run.

Thank you for the links, I had a look and adjusted SIV32X 5.55 Beta-00 light of what I found. Please may I have two new save files? I also added code to deduce there are four DIMMs, so don't use -DIMMS=4.

In passing I spotted the CPUID 2 emulation which should be trivial to correct to return the cache size data, do/can you plan to do this? I think as below will do the trick for Klamath + Mendocino + Deschutes + PentiumPro

1  EAX = 0x03020101;
2  EBX = 0x00000000;
3  ECX = 0x00000000;
4  EDX = 0x0C040843;  // Klamath + Deschutes
5  EDX = 0x0C040841;  // Mendocino
6  EDX = 0x06040A42;  // PentiumPro 256
7  EDX = 0x06040A43;  // PentiumPro 512
8  EDX = 0x06040A44;  // PentiumPro 1MB

red-ray wrote on 2020-12-17, 20:14:

Yes, stopping the BSOD would be my top priority and suspect once you have done this many more hardware reporting programs will run.

Thank you for the links, I had a look and adjusted SIV32X 5.55 Beta-00 light of what I found. Please may I have two new save files? I also added code to deduce there are four DIMMs, so don't use -DIMMS=4.

Test build BSODs on startup. I'm leaning towards it being another emulation issue not directly related to MSRs, in which case it's 100% our problem; I recall SIV being able to probe MSR C0000080 (an AMD MSR as far as I understand) without any ill effects in previous builds. I just brought SIV into this because it's currently the only hardware reporting tool to actively cause BSODs with our emulation (HWiNFO used to but was mysteriously fixed).

1RDMSR: Invalid MSR: 00000150
2*** 3 repeats ***
3RDMSR: Invalid MSR: 00000611
4RDMSR: Invalid MSR: 00000639
5RDMSR: Invalid MSR: 00000641
6RDMSR: Invalid MSR: 00000619
7RDMSR: Invalid MSR: 000000E7
8RDMSR: Invalid MSR: C0000080

red-ray wrote on 2020-12-17, 20:14:

In passing I spotted the CPUID 2 emulation which should be trivial to correct to return the cache size data, do/can you plan to do this? I think as below will do the trick for Klamath + Mendocino + Deschutes + PentiumPro

I'm aware the cache CPUID is not implemented, but don't know why. I'm told it caused issues with some BIOSes as we don't emulate a cache. I'll ask around EDIT: Confirmed.

RichardG867 wrote on 2020-12-19, 19:53:

I just brought SIV into this because it's currently the only hardware reporting tool to actively cause BSODs with our emulation (HWiNFO used to but was mysteriously fixed).

I can't comment on unnamed utilities, but know that as HWiNFO reads MSRs on W9x it must only read MSRs that exist as W9x fails to support kernel mode SEHs . AFAIK CPUZ also does this.

I designed SIV for NT4 and later all of which do support kernel mode SEHs, reads the same MSRs for all CPUs and relies on catching the GPFs.

RichardG867 wrote on 2020-12-19, 19:53:

Test build BSODs on startup. I'm leaning towards it being another emulation issue not directly related to MSRs, in which case it […]
Show full quote

Test build BSODs on startup. I'm leaning towards it being another emulation issue not directly related to MSRs, in which case it's 100% our problem;

Copy code to clipboard

1RDMSR: Invalid MSR: 00000150
2*** 3 repeats ***
3RDMSR: Invalid MSR: 00000611
4RDMSR: Invalid MSR: 00000639
5RDMSR: Invalid MSR: 00000641
6RDMSR: Invalid MSR: 00000619
7RDMSR: Invalid MSR: 000000E7
8RDMSR: Invalid MSR: C0000080

After pondering this I decided SIV should not be trying to read these MSRs on your 86BOX system so please will you try SIV32X 5.55 Beta-01 or later. If it still triggers a BSOD do SIV32X -DBGINI > SIV_DBGOUT.log so we can see how far it gets.

RichardG867 wrote on 2020-12-19, 19:53:

I'm aware the cache CPUID is not implemented, but don't know why. I'm told it caused issues with some BIOSes as we don't emulate a cache. I'll ask around EDIT: Confirmed.

I assume the BIOSes only run in real mode, is this correct? If so would it be sensible to implement CPUID 2 to return the correct values when the CPU is not in real mode?

red-ray wrote on 2020-12-20, 09:59:

After pondering this I decided SIV should not be trying to read these MSRs on your 86BOX system so please will you try SIV32X 5.55 Beta-01 or later. If it still triggers a BSOD do SIV32X -DBGINI > SIV_DBGOUT.log so we can see how far it gets.

The startup BSOD no longer happens, that's good. The MSR section still BSODs, but I'm ready to call that an emulation bug. Sorry for wasting your time.

red-ray wrote on 2020-12-20, 10:05:

I assume the BIOSes only run in real mode, is this correct? If so would it be sensible to implement CPUID 2 to return the correct values when the CPU is not in real mode?

Noted, I'll go talk to the people who figured out the cache issue.

RichardG867 wrote on 2020-12-23, 21:04:

The startup BSOD no longer happens, that's good. The MSR section still BSODs, but I'm ready to call that an emulation bug.

Good, please may I have new Menu->File->Save Selected files with [msrs] deselected so I can check the changes I made such that SIV should use MSR 2A work OK?

Do you plan to fix the MSRs emulation bug?

red-ray wrote on 2020-12-24, 10:29:

Good, please may I have new Menu->File->Save Selected files with [msrs] deselected so I can check the changes I made such that SIV should use MSR 2A work OK?

Attached.

red-ray wrote on 2020-12-24, 10:29:

Do you plan to fix the MSRs emulation bug?

I plan on doing some more tests myself - other versions of Windows, other CPUs, and real hardware (none of us actually have a board with the SMSC chipset, it's a very rare product from the late Pentium III era) - then writing a detailed bug report so that me and the other developers can figure out what's going on.

I haven't forgotten about the reserved 440BX AGP bridge registers either, I actually wrote the PCI/AGP bridge emulation and will get around to fixing that.

RichardG867 wrote on 2020-12-27, 02:08:

other CPUs

Thank you for the new save files, the changes I made worked as I hoped they would.

I noticed there was a VIA Samuel, did you try SIV with it?

red-ray wrote on 2020-12-27, 12:32:

I noticed there was a VIA Samuel, did you try SIV with it?

The Samuel works fine just because its emulation happens to be currently less thorough than the P6 emulation, and as a result, it wasn't coded to GPF on unknown MSR yet.

RichardG867 wrote on 2020-12-31, 17:21:

The Samuel works fine just because its emulation happens to be currently less thorough than the P6 emulation, and as a result, it wasn't coded to GPF on unknown MSR yet.

Thank you and all looks OK. Did you know that some VIA/CentaurHauls CPUs use MSR 00001204 (HARDWARECTRL4) to control what happens when an unknown MSR is accessed, but I don't know exactly which CPU models support this. If you have the NDA datasheets I feel it would be wise to check the details before changing the MSR emulation.

1[SPD Summary] <- SIV32X - System Information Viewer V5.55 Beta-03 NNNNNNNNNNNNNNN::Uuuuuuuuuuuuu
2
3SIV32X - Award ATC7020BXII SPD Summary for 4 DIMMs took 0.004 seconds on \\NNNNNNNNNNNNNNN - Windows XP x32 Professional  V5.01  Build 2600  Service Pack 3
4
5SMBus  Total for 4 DIMMs     1GB  Banks     Manufacturer (DRAM)  Part Number     Serial     #  [_]Speed   [Y]Suppress Same
6
70_50   SDRAM DIMM          256MB  2  128Mb  None                 86Box-SDR-256M  0000-0000         Clock  tCL  tRCD tRP  tRAS tRC  |G|CRC
8       PC-133 (133MHz)                                                               JEDEC  1    66.7MHz  3    1    1    1    -    |K|ECC
9                                                                                            2   100.0MHz  4    1    1    1    -    Ranks 2
10                                                                                            3   133.3MHz  5    1    1    1    -
110_51   SDRAM DIMM          256MB  2  128Mb  ...                  ...             ...           ...
120_52   SDRAM DIMM          256MB  2  128Mb  ...                  ...             ...           ...
130_53   SDRAM DIMM          256MB  2  128Mb  ...                  ...             ...           ...
14
15[  OK ]  [ Copy]   [Windows]  [Machine]  [ DIMMs]  [Sensors]  [Status]   [USB Bus]  [ SPD ]  [Volumes]   [SMB Bus]  [PCI Bus]  [ALL Dev]

For some time I have been pondering how to dump the NVidia GPU VBIOS when there are multiple GPUs present so when I stumbled across the undocumented NvAPI_GPU_GetVbiosImage(), even in the NDA NVAPI, this set me pondering. I felt I should see if I could deduce how it worked so added Menu->Machine->GPU VBIOS State. As from SIV 5.55 Beta-04 it's possible to dump the VBIOS, but I am unsure which driver first supported NvAPI_GPU_GetVbiosImage() so would be interested to get some feedback. Below you can see it worked with 309.08 , but expect earlier releases also supported it. I am also wondering when V2 was added, it's needed to support GPUs with a VBIOS > 64KB so I suspect for first driver to support Kepler GPUs.

NOt ES )

ApostolCV wrote on 2021-01-06, 17:29:

No [ES] 😀

Thank you for checking the fix and posting the save files. I had a quick check and all looks OK. Please update to SIV 5.55 Beta-00 which I have just released.

I am wondering that the other Willamette you have reports in MSR 0000002C (EBC_FREQUENCY_ID). Next time you have it running please will you post Menu->Hardware->CPUID->CPU-0 so I can check?

ApostolCV wrote on 2021-01-06, 17:03:

Yes, my friend,no matter which multiper i put.It start at locked -x14

Thank you, with my [ES] CPU the speed does change from 800 MHz to 1600 MHz as I change the BIOS setting 😀, but anything > x16 results in x16 🙁

Here a data you ask.
By the way. I check smth.
Realy ,if multiple is x14 then even in V54 of program CPU is not ES. But if i change multiple in BIOS to x8 program gives information that it's ES CPU.
And no matter that multiple locked on x14.)

ApostolCV wrote on 2021-01-06, 20:28:

Here a data you ask. By the way. I check smth. Realy ,if multiple is x14 then even in V54 of program CPU is not ES. But if i cha […]
Show full quote

Here a data you ask.
By the way. I check smth.
Realy ,if multiple is x14 then even in V54 of program CPU is not ES. But if i change multiple in BIOS to x8 program gives information that it's ES CPU.
And no matter that multiple locked on x14.)

Thank you for the screen shot, but I meant the SL57V which is a 1.70 GHz CPU.

I am unclear what you mean. V54 of which program? If you mean SIV 5.54 then say SIV 5.54. SIV 5.54 will report [ES] when it should not, this is fixed in SIV 5.55 Beta-05 so use SIV 5.55 Beta-05 or later.

red-ray wrote on 2021-01-06, 20:56:

ApostolCV wrote on 2021-01-06, 20:28:

Here a data you ask. By the way. I check smth. Realy ,if multiple is x14 then even in V54 of program CPU is not ES. But if i cha […]
Show full quote

Here a data you ask.
By the way. I check smth.
Realy ,if multiple is x14 then even in V54 of program CPU is not ES. But if i change multiple in BIOS to x8 program gives information that it's ES CPU.
And no matter that multiple locked on x14.)

Thank you for the screen shot, but I meant the SL57V which is a 1.70 GHz CPU.

I am unclear what you mean. V54 of which program? If you mean SIV 5.54 then say SIV 5.54. SIV 5.54 will report [ES] when it should not, this is fixed in SIV 5.55 Beta-05 so use SIV 5.55 Beta-05 or later.

Hello again.
Yes i mean SIS V5.54
I didn't understand you about which CPU info you needed before.
Here info about SL57V.

ApostolCV wrote on 2021-01-08, 18:41:

Yes i mean SIS SIV V5.54. Here info about SL57V.

I wished to check that MSR 0000002C contained what I expected, it does so I have more confidence in the change I made being correct. If only the old Intel NDA datasheets specified how MSR 0000002C is used.

Thank you for raising incorrect [ES] in the first place and all your testing.

repaxan wrote on 2020-07-02, 01:34:

Yes, I installed the 96.85 Vista drivers (despite that I'm using Win 7), which is the one listed as the latest Vista driver on Nvidia's download page.

I have been adjusting SIV for the NVidia Version 96.85 driver release and suspect my latest code will do rather better on your Quadro FX 1300, in fact any GPU using that driver release. Do you still have a Rankine GPU in a W7 system and if so please will you checkout what happens with my latest code. To do this you will need to use SIV 5.55 Beta-07 or later.

I am pleased I managed to make the GPU plots work on Windows 7 and on my test system got as attached.