Errors detected in Legacy BIOS V4.x but not UEFI V5.x

[wazzledoozle]

I'm trying to track down intermittent crashes with my laptop... when I run V4.x under Legacy BIOS, I get a set of errors within about 30-120 sec of starting the test. (Between 20-74 errors) On V5.x booting with UEFI, it's been running for a couple of hours now with no errors.
I am booting memtest86 5.1.0 off a USB stick, and I have memtest86+ 5.0.1 on a CD that immediately finds errors under Legacy BIOS. (I know that memtest86+ isn't passmark's software...)

I have tried memtest86 on two different sets of RAM, and both error out immediately under v4.x. I have tried each stick individually, in different slots etc. and it doesn't seem to matter which set I use. It does seem to only happen with two sticks installed at once though. (Memory controller fault?). I'm thinking the problem is related to my CPU/motherboard, as having USB devices plugged in to the USB 2.0 ports (but not 3.0) seems to increase the frequency of problems. I have pinpointed a BSOD to a generic USB driver, but there are many other random application hangs that I cant explain. I need to get this narrowed down so I can RMA the laptop with a specific procedure to reproduce errors... but this discrepancy between 4.x and 5.x seems odd.

I have also ran the prime95 torture test for several hours without errors. The problem is very intermittent. I've also done 2 factory image recoveries in case it was an OS issue....

These are pics I took of the errors-
http://imgur.com/a/gaOOH


Relevant system info:
Acer V3-551-8419 (updated to latest UEFI firmware)
Windows 8.1 64 Bit
AMD A8-4500M APU
2GB+4GB DDR3-1333 (kingston/hynix) & 4GB+4GB DDR3-1600 (g.skill)

Sorry for such a long-winded post. I'm leaving v5.1.0 running all night and tomorrow to see what happens.

[keith]

Judging by the locality of the errors, it looks like V4 (and MemTest86+) may be incorrectly trying to access sections of the system memory map allocated to MMIO (memory mapped I/O). The values read from those memory addresses seem to indicate device register values. So it might be the case that those sections of memory are properly marked off limits to MemTest86 v5 but not for v4. So it might be a BIOS error, that doesn't appear in UEFI. It would be good to see a screenshot of the memory map in v5 ('View Memory Usage' in the Main Menu).

[wazzledoozle]

Here's the memory map images-
http://imgur.com/a/niHtW

If an address block of memory is marked off-limits to memtest, such as device register values, could I have a faulty address block of ram that wouldn't normally be tested? Perhaps the USB host controller is occupying a certain part of the ram... thus the instability associated with using it? Or does testing memory addresses that contain device register values always result in errors (when they should be off-limits)... Sorry if that doesnt make sense, this is going beyond my knowledge level. I'm thinking it could be a chipset fault creating corruption in a specific block of memory addresses.

I ran 8 passes of memtest86, found no errors. Going to try passmark's burn-in tool now.

[David (PassMark)]

The memory address that had the error was in the 15MB boot services data block, which should be off limits. (Addresses, 0x0000BC2C2000 to 0x0000BD28AFFF ). So this adds weight to the possibility of it being BIOS error, which allows MemTest86 V4 to use RAM it shouldn't be using.

What should happen in BIOS and UEFI is that there is a table of free and reserved memory addresses. (This is sometimes called the e820 table in BIOS and EFI_MEMORY_DESCRIPTOR in UEFI)

Then when the operating system boots up (or your run MemTest86) there is code executed to read the free address ranges in the table and then use these addresses.

While this goes some way to explain the MemTest86 V4 errors, it doesn't explain the crashes in Win8 because Win8 will have booted up using the seemingly correct, EFI_MEMORY_DESCRIPTOR table.

[wazzledoozle]

Thanks for the analysis. Since memtest only tests non-reserved areas of ram, could it be possible to have a reserved area that is getting corrupted? Whether it's the ram itself, or the chipset causing the corruption....

[David (PassMark)]

There are a few different types of reserved memory addresses.
There is some reserved RAM that is used by UEFI / BIOS and there is other address blocks that are replaced with RAM from various other devices. See,
http://en.wikipedia.org/wiki/Memory-mapped_I/O

So yes it is possible the reserved RAM go bad. But as it generally makes up only a few % of the overall RAM, it isn't very likely. If you are getting a BSOD related to the USB driver then it is far more likely there is a bug in the device driver.

[lqm]

Interesting post as I just ran into this the other night with my Toshiba Qosmio x875 laptop. I started to use my Ethernet port recently and Windows 7 started to have BSOD. Ran MemTest86 and saw errors like you did when the RJ-45 cable was plugged in and no errors when the cable was unplugged. I never had BSOD before I started using the Ethernet port. I am using the Legacy BIOS option and running Windows 7. Since Toshiba is no longer in the consumer laptop market I am going to just not use the LAN and upgrade my older WiFi adapter, but definitely a first for me seeing this issue.

I'm trying to track down intermittent crashes with my laptop... when I run V4.x under Legacy BIOS, I get a set of errors within about 30-120 sec of starting the test. (Between 20-74 errors) On V5.x booting with UEFI, it's been running for a couple of hours now with no errors.
I am booting memtest86 5.1.0 off a USB stick, and I have memtest86+ 5.0.1 on a CD that immediately finds errors under Legacy BIOS. (I know that memtest86+ isn't passmark's software...)

I have tried memtest86 on two different sets of RAM, and both error out immediately under v4.x. I have tried each stick individually, in different slots etc. and it doesn't seem to matter which set I use. It does seem to only happen with two sticks installed at once though. (Memory controller fault?). I'm thinking the problem is related to my CPU/motherboard, as having USB devices plugged in to the USB 2.0 ports (but not 3.0) seems to increase the frequency of problems. I have pinpointed a BSOD to a generic USB driver, but there are many other random application hangs that I cant explain. I need to get this narrowed down so I can RMA the laptop with a specific procedure to reproduce errors... but this discrepancy between 4.x and 5.x seems odd.

I have also ran the prime95 torture test for several hours without errors. The problem is very intermittent. I've also done 2 factory image recoveries in case it was an OS issue....

These are pics I took of the errors-
http://imgur.com/a/gaOOH


Relevant system info:
Acer V3-551-8419 (updated to latest UEFI firmware)
Windows 8.1 64 Bit
AMD A8-4500M APU
2GB+4GB DDR3-1333 (kingston/hynix) & 4GB+4GB DDR3-1600 (g.skill)

Sorry for such a long-winded post. I'm leaving v5.1.0 running all night and tomorrow to see what happens.