On Mon, Jul 15, 2013 at 4:24 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Mon, Jul 15, 2013 at 4:20 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: >> On Mon, Jul 15, 2013 at 04:08:13PM -0700, Andy Lutomirski wrote: >>> On Mon, Jul 15, 2013 at 4:04 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: >>> > On Mon, Jul 15, 2013 at 01:28:36PM -0700, Andy Lutomirski wrote: >>> >> >>> >> Interesting. My BGRT says: >>> >> >>> >> [028h 0040 8] Image Address : 0D06801800000001 >>> >> >>> >> If I reverse the high and low 32-bit dwords, then I get an address in >>> >> system RAM. >>> > >>> > Does that address in RAM start with a BMP header? >>> >>> No idea. I'd presumably have to modify the driver to find out -- >>> otherwise something else will overwrite it. >> >> You could boot with a mem= command-line argument that reserves that >> memory. > > I'll see what I can do. > I booted with mem=3G, and: $ sudo dd bs=1 skip=4513853464 if=/dev/mem count=1 dd: reading ‘/dev/mem’: Bad address The kernel log says nothing, which suggests that ioremap_cache is failing. I don't know why. The address 4513853464 is 0x10D0BF018, which should be okay: [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000045fffffff] usable [ 0.000000] e820: remove [mem 0xc0000000-0xfffffffffffffffe] usable EFI agrees: [ 0.000000] efi: mem213: type=7, attr=0xf, range=[0x0000000100000000-0x0000000460000000) (13824MB) This could be related to the fact that mtrr cleanup is failing, possibly due to bugs related to mem=. That's about my tolerance for debugging something that doesn't really deserve to work. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
