[coreboot] memtest86 reading 0k memory

[Timothy Pearson]

On 02/05/2015 09:45 PM, Timothy Pearson wrote:
> On 02/05/2015 09:13 PM, Scott Duplichan wrote:
>> Timothy Pearson [mailto:tpearson at raptorengineeringinc.com] 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.
>
> I suspect you're right about the USB structures; my USB keyboard quit
> working when memtest started. Looks like I'll be building memtest86 with
> coreboot support disabled; judging by the numerous problems reported by
> other coreboot users memtest badly needs an update to disable coreboot
> support by default.
>

Recompiling memtest with the coreboot table detection bypassed resolved 
the problem.

Thanks for the help!

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