VOGONS


HWiNFO support of vintage hardware

Topic actions

Reply 480 of 496, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 481 of 496, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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?

Attachments

  • Filename
    HWINFO.TXT
    File size
    18 KiB
    Downloads
    2 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    HWINFO.LOG
    File size
    1.61 KiB
    Downloads
    1 download
    File license
    Fair use/fair dealing exception

Reply 482 of 496, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 483 of 496, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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)

  ;-----------------
wat_proc x86_BugStos
push di
xor edi,edi
pushf
cli

mov al,[es:di]
std
stosb
db 0x67 ; 32-bit address prefix
nop ; stos bug trigger
shr edi,16
setnz al

popf
xor ah,ah
pop di
wat_ret

Reply 484 of 496, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
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)

  ;-----------------
wat_proc x86_BugStos
push di
xor edi,edi
pushf
cli

mov al,[es:di]
std
stosb
db 0x67 ; 32-bit address prefix
nop ; stos bug trigger
shr edi,16
setnz al

popf
xor ah,ah
pop di
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

Reply 485 of 496, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 486 of 496, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie

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?

Filename
HWINF613.ZIP
File size
995.63 KiB
Downloads
4 downloads
File license
Fair use/fair dealing exception

Reply 487 of 496, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 488 of 496, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 489 of 496, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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)

Attachments

  • Filename
    HWiNFO.zip
    File size
    5.45 KiB
    Downloads
    1 download
    File license
    Fair use/fair dealing exception

Reply 491 of 496, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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...

Reply 493 of 496, by the_ultra_code

User metadata
Rank Oldbie
Rank
Oldbie

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

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

Attachments

  • Filename
    HWINFO_Result.zip
    File size
    66.72 KiB
    Downloads
    2 downloads
    File license
    Public domain

Builds

Other:
* USB2 PCI Card in Win98 SE
* Futuremark Result Browsers

Reply 494 of 496, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
the_ultra_code wrote on Today, 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.
CwMXXvf.png

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?

Reply 495 of 496, by the_ultra_code

User metadata
Rank Oldbie
Rank
Oldbie
Mumak wrote on Today, 13:26:
the_ultra_code wrote on Today, 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.
CwMXXvf.png

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.

Attachments

  • Filename
    oops.zip
    File size
    10.13 KiB
    Downloads
    2 downloads
    File license
    Public domain

Builds

Other:
* USB2 PCI Card in Win98 SE
* Futuremark Result Browsers

Reply 496 of 496, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
the_ultra_code wrote on Today, 13:52:
Mumak wrote on Today, 13:26:
the_ultra_code wrote on Today, 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.
CwMXXvf.png

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.