[coreboot] memtest86 reading 0k memory

[Aaron Durbin]

On Thu, Feb 5, 2015 at 1:15 PM, Timothy Pearson
<tpearson at raptorengineeringinc.com> wrote:
> On 02/05/2015 12:59 PM, Aaron Durbin wrote:
>>
>> On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson
>> <tpearson at raptorengineeringinc.com>  wrote:
>>>
>>> On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote:
>>>>
>>>>
>>>> That's a pretty old memtest86+.  Also, memtest86+ prefers
>>>> linuxbios/coreboot memory map to e820.  This becomes a problem
>>>> when SeaBIOS sets up a USB controller to DMA to e820-reserved
>>>> memory that wasn't reserved by coreboot.
>>>>
>>>> Try a modern memtest86+ with the coreboot table probe patched out.
>>>>
>>>>          Jonathan Kollasch
>>>
>>>
>>>
>>> Yep, that was it.  Didn't catch the obsolete version number.
>>>
>>> I'm trying to figure out the point of memtest86 reading the coreboot
>>> tables.
>>> It doesn't help that the coreboot tables / e820 map are apparently wrong;
>>> memtest86+ almost immediately started stepping on the lower MMIO regions
>>> (e.g. 0xb800) rendering the display mostly useless. Interestingly Linux
>>> doesn't seem to have any problems; I'll need to investigate further.
>>>
>>
>> Your e820 looks fine to me. memtest86 should just be testing the
>> usable regions. Since b800 isn't in there, the only issue that could
>> arise is it using that physical address as a mmio bar. However, that'd
>> be an OS level thing, and I wouldn't expect the memtest86 doing any
>> such things. It sounds more like it does a merge of some sort with
>> e820 and its notion of valid memory instead relying on e820 proper.
>>
>
> Thanks for the information.  The e820 map is comparable to the one generated
> from the proprietary BIOS so I agree it is likely correct. That leaves the
> coreboot tables themselves and/or memtest86's interpretation of them.
>
> BTW it looks I am not the only one to have run into this:
> http://www.coreboot.org/pipermail/coreboot/2010-December/062245.html
>
> At this point I'm not sure if the bug is in coreboot, SeaBIOS, or memtest86.


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.


>
> --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645
> http://www.raptorengineeringinc.com
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot