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.