[coreboot] memtest86 reading 0k memory

Timothy Pearson tpearson at raptorengineeringinc.com
Fri Feb 6 01:48:30 CET 2015


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.

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com



More information about the coreboot mailing list