Re: [coreboot] memtest86 reading 0k memory

[Scott Duplichan]

Timothy Pearson [mailto:[e-mail]] wrote:

]Sent: Thursday, February 05, 2015 06:49 PM
]To: Coreboot
]Subject: Re: [coreboot] memtest86 reading 0k memory
]
]On 02/05/2015 06:42 PM, Timothy Pearson wrote:
]> On 02/05/2015 02:06 PM, Timothy Pearson wrote:
]>> On 02/05/2015 01:51 PM, Aaron Durbin wrote:
]>>> Do you have the coreboot console log? Looking at memtest86 it
]>>> constructs its own e820 when using linuxbios. Additionally, it also
]>>> has some concept of a "window" to test as well as plim_lower and
]>>> plim_upper variables that seem to add to the mix.
]>>>
]>>> What's super frightening is that find_chunks(int tst) is called in the
]>>> code as find_chunks() while the find_chunks() function actually
]>>> references tst as an array index. That's all from config.c. But I
]>>> think that's only if you hit c on the keyboard. I wouldn't do that...
]>>>
]>>> I can't make heads or tails of that code at the moment. for selecting
]>>> the window to test.
]>>
]>> Please see text log attached. It looks like the failing accesses start
]>> at 0xa0000, which (judging by memtest's effects on the screen) appears
]>> to be mapped to the VGA text buffer. That region is *not* reserved under
]>> the proprietary BIOS's e820 map.
]>>
]>> Thanks!
]>>
]>
]> I was able to resolve the lower MMIO region failures (coreboot driver
]> patch in for review), but memtest86 is stubbornly insisting on testing
]> reserved memory, causing a single failure at 3ffade80. The e820 map says
]> that address is out of bounds but the coreboot tables do not:
]>
]> e820 map has 6 items:
]> 0: 0000000000000000 - 000000000009fc00 = 1 RAM
]> 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
]> 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
]> 3: 0000000000100000 - 000000003ffad000 = 1 RAM
]> 4: 000000003ffad000 - 0000000040000000 = 2 RESERVED
]> 5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED
]>
]> coreboot table: 460 bytes.
]> CBMEM ROOT 0. 3ffff000 00001000
]> CONSOLE 1. 3ffdf000 00020000
]> TIME STAMP 2. 3ffde000 00001000
]> GDT 3. 3ffdd000 00001000
]> SMP TABLE 4. 3ffdc000 00001000
]> ACPI 5. 3ffb8000 00024000
]> SMBIOS 6. 3ffb7000 00001000
]> COREBOOT 7. 3ffaf000 00008000
]>
]> Why the discrepancy? Am I correct in assuming this is a bug in coreboot
]> that needs to be fixed?
]>
]
]Sorry, wrong coreboot table above:
]
]Writing coreboot table at 0x3ffaf000
]rom_table_end = 0x3ffaf000
]... aligned to 0x3ffb0000
]  0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
]  1. 0000000000001000-000000000009ffff: RAM
]  2. 00000000000a0000-00000000000affff: RESERVED
]  3. 00000000000b0000-00000000000b7fff: RAM
]  4. 00000000000b8000-00000000000bffff: RESERVED
]  5. 00000000000c0000-000000003ffaefff: RAM
]  6. 000000003ffaf000-000000003fffffff: CONFIGURATION TABLES
]  7. 00000000e0000000-00000000efffffff: RESERVED
]
]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) 
]and that overwriting it is a Bad Thing, but whatever it is does not 
]update the coreboot tables and memtest86 promptly stomps on it.

I imagine SeaBIOS is taking memory from the end of free RAM below
4GB for USB structures. There is probably an incrementing frame
counter at 3ffade80. It looks like SeaBIOS builds the E820 table
to properly account for the memory it uses. If memtest86 uses the
coreboot tables even when an E820 handler is installed, that seems
wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to
reflect its memory usage, which I don't think is the case.

]-- 
]Timothy Pearson
]Raptor Engineering
][phone]
]http://www.raptorengineeringinc.com