On Thu, Feb 5, 2015 at 1:15 PM, Timothy Pearson tpearson@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@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 KollaschYep, 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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot