666f.MOO.gz 253 (OUTSD) -- A20 grounded?

[mras0]

Once again thanks for this (I also commented on reddit)! With the SIB discovery nearly everything lines up (note: no scaling of the base when mod=0b00/base=0b101, but that makes sense) outside of documented undefined behavior.

Except test 8abbbc61a5866292b0bc816660d7b334bea7962a.
There are a bunch of segment override prefixes, but the last one is for DS (and other test show last one sticks).

We have DS=0xFFFF ESI=0xE250'6758 so I expect read from linear address 0x106748 (0xFFFF*16+0x6758) but the test reads from 0x06748 (checked the cycles). None of the other segment addresses would make that exact address so it seems like A20 is ignored here (and just for this test).

I checked all the test and none seem to do output to the 386EX "A20" register (92h/f092h) so it doesn't seem like it's just a mistake in the previous test (I know you blacklist them).

Apologies in advance if I just didn't do my homework :)

[dbalsom]

This looks like a test bug. When I replay the test I get 106748 like you'd expect. Not sure how this fell through the validation cracks, but apparently it did.

Is this the only test you've seen with this issue?

[mras0]

Yes, this is literally the only test where I've seen an unexpected physical/linear memory address being used. Except for this one, each and every other memory access in the test suite is perfectly explained.