Deunan wrote on 2021-05-03, 15:09:

I want to submit a bug 😀
Nothing serious really, just that POPAD bug is not always detected on 386DX, and STOS bug is never detected. NSSI doesn't detect STOS bug either but I wrote my own code to test it and I can trigger it.

Can you please provide more details? I will look into that.
Maybe there are some additional conditions needed to trigger the POPAD bug? Also a HWiNFO report file might be useful.

Duh, forgot logs. It's interesting that POPAD bug is not detected when HWiNFO is run normally, but detected when I used -R option. Interrupts not disabled during detection maybe? I tried it twice and got the same results both times.

EDIT: Oopsie, wrote that backwards. Corrected. As for details, what do you need?

Deunan wrote on 2021-05-03, 15:49:

Duh, forgot logs. It's interesting that POPAD bug is not detected when HWiNFO is run normally, but detected when I used -R option. Interrupts not disabled during detection maybe? I tried it twice and got the same results both times.

EDIT: Oopsie, wrote that backwards. Corrected. As for details, what do you need?

Thanks. That behavior is weird, there's no difference in interrupt enabling between auto report and manual mode (in both cases they are enabled). I have no idea what is making the difference in outcome..
Would you be willing to share your STOSB code? I'm not sure if it requires a PUSH/POP around the STOSB instruction.

I noticed the window shows POPAD OK the first time I enter it, and ERROR on all later visits. Tested on 386DX 0303, 0305 and 0308 steppings (all have that bug). Curious.

As for STOS bug, here's my code - I use STOSB but it should trigger on all sizes. The value is returned in AX (0x0000 = OK, 0x0001 = bug present)

1  ;-----------------
2wat_proc x86_BugStos
3  push di
4  xor edi,edi
5  pushf
6  cli
7
8  mov al,[es:di]
9  std
10  stosb
11  db 0x67			; 32-bit address prefix
12  nop				; stos bug trigger
13  shr edi,16
14  setnz al
15
16  popf
17  xor ah,ah
18  pop di
19  wat_ret

Deunan wrote on 2021-05-03, 20:35:

I noticed the window shows POPAD OK the first time I enter it, and ERROR on all later visits. Tested on 386DX 0303, 0305 and 030 […]
Show full quote

I noticed the window shows POPAD OK the first time I enter it, and ERROR on all later visits. Tested on 386DX 0303, 0305 and 0308 steppings (all have that bug). Curious.

As for STOS bug, here's my code - I use STOSB but it should trigger on all sizes. The value is returned in AX (0x0000 = OK, 0x0001 = bug present)

Copy code to clipboard

1  ;-----------------
2wat_proc x86_BugStos
3  push di
4  xor edi,edi
5  pushf
6  cli
7
8  mov al,[es:di]
9  std
10  stosb
11  db 0x67			; 32-bit address prefix
12  nop				; stos bug trigger
13  shr edi,16
14  setnz al
15
16  popf
17  xor ah,ah
18  pop di
19  wat_ret

Thanks for the code. It seems a bit weird however because it extends the NOP instruction to 32-bits. Are you sure this was the intent?
My STOS test does "DB 67h, STOSB" but that doesn't seem to trigger the bug.. However for MOVS test this works

AFAIK any instruction that uses address size prefix direcly after the STOS will trigger the bug. Sure, I could've setup a "proper" memory access, like do XOR EBX,EBX before STOS and then MOV BL,[EBX] right after, but why bother? In fact you could argue that NOP - with prefixes or not - should not have any ill effects on previous instruction. And it does so it's a bug. I could skip the NOP and let the SHR take the prefix but I like to separate the bug trigger from proper code after it.

I'm triggering MOVS and REP MOVS (both have different bugs) in the same way. None of these instructions should be prefixed with 0x67 in real code, but there being a memory access instruction with 0x67 right after is a valid combination. So that it a true bug test for code that can happen. I just go the easy way of using NOP to simplify things.

Thanks for the clarification. It was my misunderstanding and I thought that the 32-bit prefix on the STOS instruction is triggering it. I forgot a lot of things from the "good old" days 😁
But it's interesting that it does that on the MOVS...
I have adjusted my code, could you please try the attached build and let me know how it works?

Works fine now. STOS bug is now detected and POPA bug is detected every time as well. The errata window works a bit more stable now too. I had some minor issues with it before, like weird screen corruption or that window opening seemingly by itself again after I closed it - but it was random and I could never figure out the cause. Seems to be fixed now. Do you need the report generated?

Unfortunately I don't have a non-sigma CPU to test the 32-bit multiplier issue (apparently it's somewhat random, not so easily repeatable as the other ones). I've also read that some 386SX have the POPA bug but I've yet to find one, which is curious considering all the DX have it. Neither Intel nor AMD bothered to fix it. Well, I'm off to detect some protected mode bugs on my B1 - at least those that can be reproduced without a total system crash.

That's great 😀 For the POPAD bug I just added disabling interrupts during the test, so that seems to have helped indeed 😀
Any reports are highly welcome for my reference (even better with the respective DBG files, so I can see a few more internal details). I noticed in the previous report that your 83D87 FPU seems to be slightly under-reporting the clock (assuming it should be 20 MHz). But it seems to me that these FPUs didn't have uniform instruction times, looks like there were different revisions with different properties.

Oh I didn't realize there was an option to generate more information, or I would've done it the first time around. Here you go, still the same system except different floppy drive is connected.

As for the 83D87, it should be using CLK2 but I know some mobos run the clock through chipsef for some reason. Maybe to steal cycles for RAM refresh? I don't know if that's even possible to do on these CPUs, just a guess. I'm going to investigate that with a scope someday but don't have the time right now. It's not just with the 386 though, the SXL chip I've tried tested at 40.1 MHz and the Cyrix was then reported as 39.0 MHz - but I don't mind, I was happy enough to finally know which version of the chip this is (the older or the newer model)

Deunan wrote on 2021-05-04, 18:32:

I was happy enough to finally know which version of the chip this is (the older or the newer model)

Can you elaborate a bit on that? What models are there?

I don't want to derail this thread so in short, according to coproc.txt document, there are two main versions of the FasMath 83D87. The older one is called 83D87 and the newer one, depeding on region, is 83D87 (USA) or 387+ (Europe, other places?). Since the USA had both of them named 83D87 it's hard to tell which one is which, there's not much solid info about what to look for - and Cyrix did not print any easy to figure out date codes on these.
The older version is supposed to be a tad bit faster but only goes up to 33MHz and apparently 40 is not always a stable overclock on these. The newer ones do come in 40MHz variants and seem to clock even higher than that. In theory a part marked 40 should be the new one, but lately there's been a lot of fakes...

Ah yes, but there's more. Mine is a Cx87DLC-40GP which might be one of the earlier models with a name change, or a completely new and different core... I don't know.

HWINFO32 doesn't know what to make of my FIC PN-6210 dual-Pentium Pro motherboard.

I am using an Adaptec ASH-1205A PCI SATA controller, if you are curious.

the_ultra_code wrote on 2021-05-05, 12:09:

HWINFO32 doesn't know what to make of my FIC PN-6210 dual-Pentium Pro motherboard. https://i.imgur.com/CwMXXvf.png […]
Show full quote

HWINFO32 doesn't know what to make of my FIC PN-6210 dual-Pentium Pro motherboard.

I am using an Adaptec ASH-1205A PCI SATA controller, if you are curious.

Thanks for the report. Unfortunately the DBG file attached is empty. Could you please re-do the run and attach the full one?

Mumak wrote on 2021-05-05, 13:26:

the_ultra_code wrote on 2021-05-05, 12:09:

HWINFO32 doesn't know what to make of my FIC PN-6210 dual-Pentium Pro motherboard. https://i.imgur.com/CwMXXvf.png […]
Show full quote

HWINFO32 doesn't know what to make of my FIC PN-6210 dual-Pentium Pro motherboard.

I am using an Adaptec ASH-1205A PCI SATA controller, if you are curious.

Thanks for the report. Unfortunately the DBG file attached is empty. Could you please re-do the run and attach the full one?

Here.

the_ultra_code wrote on 2021-05-05, 13:52:

Mumak wrote on 2021-05-05, 13:26:

the_ultra_code wrote on 2021-05-05, 12:09:

HWINFO32 doesn't know what to make of my FIC PN-6210 dual-Pentium Pro motherboard. https://i.imgur.com/CwMXXvf.png […]
Show full quote

HWINFO32 doesn't know what to make of my FIC PN-6210 dual-Pentium Pro motherboard.

I am using an Adaptec ASH-1205A PCI SATA controller, if you are curious.

Thanks for the report. Unfortunately the DBG file attached is empty. Could you please re-do the run and attach the full one?

Here.

Thanks! Chipset detection shall be fixed in the next build.

Strange misreport on my Voodoo2 - 8GB of video memory instead of 8MB. 🤷

the_ultra_code wrote on 2021-05-09, 22:08:

Strange misreport on my Voodoo2 - 8GB of video memory instead of 8MB. :shrug: https://i.imgur.com/PGaFgyq.png […]
Show full quote

Strange misreport on my Voodoo2 - 8GB of video memory instead of 8MB. 🤷

Oops 😀 Could you please attach the content of the "HKEY_LOCAL_MACHINE\Software\3Dfx Interactive\Voodoo2\PropPage" node?

I have this motherboard: "LION COMPUTERS, INC. NICE GREEN-VL/ISA" http://www.win3x.org/uh19/motherboard/show/3461

Contaq 596a chipset w/ latest HWInfo 6.1.3 from this thread, May 4th 2021 build.

Locks up when trying to view "Mainboard Info" with a "Resetting CPU [Method 1]" message in the bottom right.

I tried different switches -d -v -r -s with no luck.

I need to do a hardware reset to reboot.