[coreboot] memtest86 reading 0k memory

[Timothy Pearson]

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.

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