LinuxBIOS + filo Errors from C0000 to EFEFC Walltime Cached RsvdMem MemMap Cache ECC Test 224M 0 LinuxBIOS on off std
Obviously, memtest86 isn't skipping the cmos -- I managed to pause it just as it hit C000, and looked at the error result -- AA 55 was in there. It's reading the cmos, and failing to test it, as it should.
That range is not CMOS. CMOS is 128 bytes and you access it via portIO. Memtest86 never hits CMOS. Those are your legacy video bios and other shadow area ranges. Depending on how they are enabled by your setup code they may not be writeable.
Doubtfull its a problem though as Linux won't use those area for RAM.
-- Richard A. Smith
OK, I know that at one point we had a motherboard that had weird cmos hardware. The cmos bits seemed to control motherboard functions BEFORE the CPU executed first instruction. What I really think was going on was that a piece of hardware also received the CMOS writes ... it was weird.
Eric, can you quick patch LB so that ALL writes to cmos are disabled? Just comment them out. Then try again. Something weird is going on.
ron
Ack, you're right -- was thinking ROM, but typed CMOS. Well, makes my RAM tests pointless under LB. I don't think it's a HW RAM problem, as it tested just fine under factory BIOS.
Richard Smith wrote:
LinuxBIOS + filo Errors from C0000 to EFEFC Walltime Cached RsvdMem MemMap Cache ECC Test 224M 0 LinuxBIOS on off std
Obviously, memtest86 isn't skipping the cmos -- I managed to pause it just as it hit C000, and looked at the error result -- AA 55 was in there. It's reading the cmos, and failing to test it, as it should.
That range is not CMOS. CMOS is 128 bytes and you access it via portIO. Memtest86 never hits CMOS. Those are your legacy video bios and other shadow area ranges. Depending on how they are enabled by your setup code they may not be writeable.
Doubtfull its a problem though as Linux won't use those area for RAM.
-- Richard A. Smith
Yes, but not tonight =) Soon.
Ronald G Minnich wrote:
OK, I know that at one point we had a motherboard that had weird cmos hardware. The cmos bits seemed to control motherboard functions BEFORE the CPU executed first instruction. What I really think was going on was that a piece of hardware also received the CMOS writes ... it was weird.
Eric, can you quick patch LB so that ALL writes to cmos are disabled? Just comment them out. Then try again. Something weird is going on.
ron
On 4/27/06, Eric Poulsen eric@zyxod.com wrote:
Ack, you're right -- was thinking ROM, but typed CMOS. Well, makes my RAM tests pointless under LB. I don't think it's a HW RAM problem, as it tested just fine under factory BIOS.
Well I was more concerned with the RAM under LinuxBIOS. Ram settings are very tricky. Just makeing sure your board wasn't on the edge of some timing or buffer drive spec. That would be the cause of a lot of op code issues.
-- Richard A. Smith
Eric Poulsen wrote:
Ack, you're right -- was thinking ROM, but typed CMOS. Well, makes my RAM tests pointless under LB. I don't think it's a HW RAM problem, as it tested just fine under factory BIOS.
the factory bios ram tests are useless.
thanks
ron
I should have been more clear: I ran memtest86+ using the Factory BIOS and Grub
Ronald G Minnich wrote:
Eric Poulsen wrote:
Ack, you're right -- was thinking ROM, but typed CMOS. Well, makes my RAM tests pointless under LB. I don't think it's a HW RAM problem, as it tested just fine under factory BIOS.
the factory bios ram tests are useless.
thanks
ron
Eric Poulsen wrote:
I should have been more clear: I ran memtest86+ using the Factory BIOS and Grub
you need to run it under LB. thanks ron
Ron, re-read my original email. I DID run it (memtest86+) under both LB and Factory BIOS. I get several thousand of errors (under LB) because memtest86 is trying to check the shadow area from C000 to EFEFC. I suspect the "MemMap" (whatever that is) is wrong. Makes the ram testing a bit difficult, because "real" errors are lost in the noise.
Factory BIOS: Ran memtest86+ for four hours -- no errors.
Walltime Cached RsvdMem MemMap Cache ECC Test 224M 76K e820-std on off std
_LinuxBIOS_ + filo Errors from C0000 to EFEFC Walltime Cached RsvdMem MemMap Cache ECC Test 224M 0 LinuxBIOS on off std
Ronald G Minnich wrote:
Eric Poulsen wrote:
I should have been more clear: I ran memtest86+ using the Factory BIOS and Grub
you need to run it under LB. thanks ron
Eric Poulsen wrote:
Ron, re-read my original email. I DID run it (memtest86+) under both LB and Factory BIOS. I get several thousand of errors (under LB) because memtest86 is trying to check the shadow area from C000 to EFEFC. I suspect the "MemMap" (whatever that is) is wrong. Makes the ram testing a bit difficult, because "real" errors are lost in the noise.
sorry. But you can build memtest to only check the 1M+ area .. that's how I do it. misread your mail.
ron
* Ronald G Minnich rminnich@lanl.gov [060427 20:41]:
sorry. But you can build memtest to only check the 1M+ area .. that's how I do it. misread your mail.
question is why is this not needed with legacy bios? Can we emulate their behavior easily?
S.
question is why is this not needed with legacy bios? Can we emulate their behavior easily?
I think its already there. Notice what Reserved memeory map it used for factory.
224M 76K e820-std on off std
the e820 map.
And for LB
224M 0 LinuxBIOS on off std
The LinuxBIOS map. So you may not have your LB reserved memory map setup. I can't help you much on setting that up since I wasn't even aware we had a reserved memory map but memtest had to get that from somewhere.
-- Richard A. Smith
-
Eric Poulsen -
Richard Smith -
Ronald G Minnich -
Stefan Reinauer