Re: [coreboot] memtest86 reading 0k memory
On 02/05/2015 09:13 PM, Scott Duplichan wrote: Timothy Pearson [mailto:tpear...@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 0xa, 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: - 0009fc00 = 1 RAM ]> 1: 0009fc00 - 000a = 2 RESERVED ]> 2: 000f - 0010 = 2 RESERVED ]> 3: 0010 - 3ffad000 = 1 RAM ]> 4: 3ffad000 - 4000 = 2 RESERVED ]> 5: e000 - f000 = 2 RESERVED ]> ]> coreboot table: 460 bytes. ]> CBMEM ROOT 0. 3000 1000 ]> CONSOLE 1. 3ffdf000 0002 ]> TIME STAMP 2. 3ffde000 1000 ]> GDT 3. 3ffdd000 1000 ]> SMP TABLE 4. 3ffdc000 1000 ]> ACPI 5. 3ffb8000 00024000 ]> SMBIOS 6. 3ffb7000 1000 ]> COREBOOT 7. 3ffaf000 8000 ]> ]> 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 0x3ffb ] 0. -0fff: CONFIGURATION TABLES ] 1. 1000-0009: RAM ] 2. 000a-000a: RESERVED ] 3. 000b-000b7fff: RAM ] 4. 000b8000-000b: RESERVED ] 5. 000c-3ffaefff: RAM ] 6. 3ffaf000-3fff: CONFIGURATION TABLES ] 7. e000-efff: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] memtest86 reading 0k memory
Timothy Pearson [mailto:tpear...@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 0xa, 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: - 0009fc00 = 1 RAM ]> 1: 0009fc00 - 000a = 2 RESERVED ]> 2: 000f - 0010 = 2 RESERVED ]> 3: 0010 - 3ffad000 = 1 RAM ]> 4: 3ffad000 - 4000 = 2 RESERVED ]> 5: e000 - f000 = 2 RESERVED ]> ]> coreboot table: 460 bytes. ]> CBMEM ROOT 0. 3000 1000 ]> CONSOLE 1. 3ffdf000 0002 ]> TIME STAMP 2. 3ffde000 1000 ]> GDT 3. 3ffdd000 1000 ]> SMP TABLE 4. 3ffdc000 1000 ]> ACPI 5. 3ffb8000 00024000 ]> SMBIOS 6. 3ffb7000 1000 ]> COREBOOT 7. 3ffaf000 8000 ]> ]> 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 0x3ffb ] 0. -0fff: CONFIGURATION TABLES ] 1. 1000-0009: RAM ] 2. 000a-000a: RESERVED ] 3. 000b-000b7fff: RAM ] 4. 000b8000-000b: RESERVED ] 5. 000c-3ffaefff: RAM ] 6. 3ffaf000-3fff: CONFIGURATION TABLES ] 7. e000-efff: 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. ]-- ]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
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 0xa, 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: - 0009fc00 = 1 RAM 1: 0009fc00 - 000a = 2 RESERVED 2: 000f - 0010 = 2 RESERVED 3: 0010 - 3ffad000 = 1 RAM 4: 3ffad000 - 4000 = 2 RESERVED 5: e000 - f000 = 2 RESERVED coreboot table: 460 bytes. CBMEM ROOT 0. 3000 1000 CONSOLE 1. 3ffdf000 0002 TIME STAMP 2. 3ffde000 1000 GDT 3. 3ffdd000 1000 SMP TABLE 4. 3ffdc000 1000 ACPI 5. 3ffb8000 00024000 SMBIOS 6. 3ffb7000 1000 COREBOOT 7. 3ffaf000 8000 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 0x3ffb 0. -0fff: CONFIGURATION TABLES 1. 1000-0009: RAM 2. 000a-000a: RESERVED 3. 000b-000b7fff: RAM 4. 000b8000-000b: RESERVED 5. 000c-3ffaefff: RAM 6. 3ffaf000-3fff: CONFIGURATION TABLES 7. e000-efff: 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. -- 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
Re: [coreboot] memtest86 reading 0k memory
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 0xa, 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: - 0009fc00 = 1 RAM 1: 0009fc00 - 000a = 2 RESERVED 2: 000f - 0010 = 2 RESERVED 3: 0010 - 3ffad000 = 1 RAM 4: 3ffad000 - 4000 = 2 RESERVED 5: e000 - f000 = 2 RESERVED coreboot table: 460 bytes. CBMEM ROOT 0. 3000 1000 CONSOLE 1. 3ffdf000 0002 TIME STAMP 2. 3ffde000 1000 GDT 3. 3ffdd000 1000 SMP TABLE 4. 3ffdc000 1000 ACPI5. 3ffb8000 00024000 SMBIOS 6. 3ffb7000 1000 COREBOOT7. 3ffaf000 8000 Why the discrepancy? Am I correct in assuming this is a bug in coreboot that needs to be fixed? -- 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
Re: [coreboot] memtest86 reading 0k memory
On Thu, Feb 5, 2015 at 1:15 PM, Timothy Pearson wrote: > On 02/05/2015 12:59 PM, Aaron Durbin wrote: >> >> On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson >> 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@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] memtest86 reading 0k memory
On 02/05/2015 12:59 PM, Aaron Durbin wrote: On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson 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. -- 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
Re: [coreboot] memtest86 reading 0k memory
On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson 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. > -- > 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] memtest86 reading 0k memory
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. -- 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
Re: [coreboot] memtest86 reading 0k memory
On Thu, Feb 05, 2015 at 12:23:40PM -0600, Timothy Pearson wrote: > All, > > I have a board here that loads memtest86 but won't actually test memory. > > This is the output: > > Memtest86+ v2.11 > AMD K10 CPU @ 2312 MHz > L1 Cache: 64K 35028 MB/s > L2 Cache: 512K 6963 MB/s > L3 Cache: 2048K 6052 MB/s > Memory :0K |- > Chipset : > > > > > 0K LinuxBIOS > > > > I'm guessing memtest86 doesn't understand coreboot's memory > tables/structure, but I have no idea why that would be. The e820 > map is valid: > e820: BIOS-provided physical RAM map: > BIOS-e820: [mem 0x-0x0009fbff] usable > BIOS-e820: [mem 0x0009fc00-0x0009] reserved > BIOS-e820: [mem 0x000f-0x000f] reserved > BIOS-e820: [mem 0x0010-0x3ffacfff] usable > BIOS-e820: [mem 0x3ffad000-0x3fff] reserved > BIOS-e820: [mem 0xe000-0xefff] reserved > > Any ideas? Other than this one irritating glitch coreboot is > working perfectly on this board. 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] memtest86 reading 0k memory
All, I have a board here that loads memtest86 but won't actually test memory. This is the output: Memtest86+ v2.11 AMD K10 CPU @ 2312 MHz L1 Cache: 64K 35028 MB/s L2 Cache: 512K 6963 MB/s L3 Cache: 2048K 6052 MB/s Memory :0K |- Chipset : 0K LinuxBIOS I'm guessing memtest86 doesn't understand coreboot's memory tables/structure, but I have no idea why that would be. The e820 map is valid: e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000f-0x000f] reserved BIOS-e820: [mem 0x0010-0x3ffacfff] usable BIOS-e820: [mem 0x3ffad000-0x3fff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved Any ideas? Other than this one irritating glitch coreboot is working perfectly on this board. Thanks! -- 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
