Saw this warning running latest git (Ubuntu daily mainline.) It looked
similar to what Andy saw on MSI hardware -
http://www.spinics.net/lists/linux-acpi/msg43410.html . The patch for
it doesn't seem to be merged, although it won't help in my case -
different hardware with valid status instead of invalid and image
address falling in system RAM instead of just being wild.
Unsure how this should be handled - moving the is_ram() check in
efi_bgrt_init and ignoring the BGRT in case where the check succeeds?
Doesn't sound completely right to me - since the BGRT is valid and
exists somewhere, but..
[ 0.015141] ------------[ cut here ]------------
[ 0.015147] WARNING: CPU: 0 PID: 0 at
/home/apw/COD/linux/arch/x86/mm/ioremap.c:102
__ioremap_caller+0x312/0x390()
[ snip ]
[ 0.015160] Call Trace:
[ 0.015165] [<ffffffff8170a704>] dump_stack+0x46/0x58
[ 0.015169] [<ffffffff8106406c>] warn_slowpath_common+0x8c/0xc0
[ 0.015171] [<ffffffff810640ba>] warn_slowpath_null+0x1a/0x20
[ 0.015173] [<ffffffff81054e32>] __ioremap_caller+0x312/0x390
[ 0.015176] [<ffffffff814013d4>] ? acpi_tb_verify_table+0x54/0x58
[ 0.015179] [<ffffffff81d35551>] ? efi_bgrt_init+0x8f/0x143
[ 0.015181] [<ffffffff81054f07>] ioremap_nocache+0x17/0x20
[ 0.015183] [<ffffffff81d35551>] efi_bgrt_init+0x8f/0x143
[ 0.015186] [<ffffffff81401d36>] ? acpi_tb_initialize_facs+0x32/0x34
[ 0.015188] [<ffffffff81d34e7f>] efi_late_init+0x9/0xb
[ 0.015190] [<ffffffff81d18f17>] start_kernel+0x3fd/0x419
[ 0.015192] [<ffffffff81d189ac>] ? do_early_param+0x87/0x87
[ 0.015194] [<ffffffff81d18120>] ? early_idt_handlers+0x120/0x120
[ 0.015196] [<ffffffff81d185e6>] x86_64_start_reservations+0x2a/0x2c
ioremap.c:102
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
last_pfn = last_addr >> PAGE_SHIFT;
for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) {
int is_ram = page_is_ram(pfn);
if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
return NULL;
WARN_ON_ONCE(is_ram);
}
Looking at the BGRT table from IASL, the status seems to be valid but
the image address *seems* to me that is falling under system RAM.
[000h 0000 4] Signature : "BGRT" [Boot
Graphics Resource Table]
[004h 0004 4] Table Length : 00000038
[008h 0008 1] Revision : 00
[009h 0009 1] Checksum : 3D
[00Ah 0010 6] Oem ID : "HPQOEM"
[010h 0016 8] Oem Table ID : "SLIC-CPC"
[018h 0024 4] Oem Revision : 01072009
[01Ch 0028 4] Asl Compiler ID : "AMI "
[020h 0032 4] Asl Compiler Revision : 00010013
[024h 0036 2] Version : 0001
[026h 0038 1] Status : 01
[027h 0039 1] Image Type : 00
[028h 0040 8] Image Address : 00000000B2E1B018
[030h 0048 4] Image OffsetX : 00000279
[034h 0052 4] Image OffsetY : 0000014F
Below is from 3.8 kernel - I think that shouldn't make a difference
given ioremap also find the address in RAM.
$ cat /proc/iomem |grep RAM00010000-0009ffff : System RAM
00100000-bdb6bfff : System RAM
be6ef000-be6effff : System RAM
be8f6000-bed2ffff : System RAM
beff3000-beffffff : System RAM
bf000000-bfffffff : RAM buffer
100001000-2beffffff : System RAM
2bf000000-2bfffffff : RAM buffer
On Sun, Jul 14, 2013 at 12:07 PM, Parag Warudkar <[email protected]> wrote:
> Saw this warning running latest git (Ubuntu daily mainline.) It looked
> similar to what Andy saw on MSI hardware -
> http://www.spinics.net/lists/linux-acpi/msg43410.html . The patch for
> it doesn't seem to be merged, although it won't help in my case -
> different hardware with valid status instead of invalid and image
> address falling in system RAM instead of just being wild.
>
> Unsure how this should be handled - moving the is_ram() check in
> efi_bgrt_init and ignoring the BGRT in case where the check succeeds?
> Doesn't sound completely right to me - since the BGRT is valid and
> exists somewhere, but..
>
> [ 0.015141] ------------[ cut here ]------------
> [ 0.015147] WARNING: CPU: 0 PID: 0 at
> /home/apw/COD/linux/arch/x86/mm/ioremap.c:102
> __ioremap_caller+0x312/0x390()
> [ snip ]
> [ 0.015160] Call Trace:
> [ 0.015165] [<ffffffff8170a704>] dump_stack+0x46/0x58
> [ 0.015169] [<ffffffff8106406c>] warn_slowpath_common+0x8c/0xc0
> [ 0.015171] [<ffffffff810640ba>] warn_slowpath_null+0x1a/0x20
> [ 0.015173] [<ffffffff81054e32>] __ioremap_caller+0x312/0x390
> [ 0.015176] [<ffffffff814013d4>] ? acpi_tb_verify_table+0x54/0x58
> [ 0.015179] [<ffffffff81d35551>] ? efi_bgrt_init+0x8f/0x143
> [ 0.015181] [<ffffffff81054f07>] ioremap_nocache+0x17/0x20
> [ 0.015183] [<ffffffff81d35551>] efi_bgrt_init+0x8f/0x143
> [ 0.015186] [<ffffffff81401d36>] ? acpi_tb_initialize_facs+0x32/0x34
> [ 0.015188] [<ffffffff81d34e7f>] efi_late_init+0x9/0xb
> [ 0.015190] [<ffffffff81d18f17>] start_kernel+0x3fd/0x419
> [ 0.015192] [<ffffffff81d189ac>] ? do_early_param+0x87/0x87
> [ 0.015194] [<ffffffff81d18120>] ? early_idt_handlers+0x120/0x120
> [ 0.015196] [<ffffffff81d185e6>] x86_64_start_reservations+0x2a/0x2c
>
> ioremap.c:102
> /*
> * Don't allow anybody to remap normal RAM that we're using..
> */
> last_pfn = last_addr >> PAGE_SHIFT;
> for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) {
> int is_ram = page_is_ram(pfn);
>
> if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
> return NULL;
> WARN_ON_ONCE(is_ram);
> }
>
> Looking at the BGRT table from IASL, the status seems to be valid but
> the image address *seems* to me that is falling under system RAM.
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.
--Andy
On Mon, Jul 15, 2013 at 01:28:36PM -0700, Andy Lutomirski wrote:
> On Sun, Jul 14, 2013 at 12:07 PM, Parag Warudkar <[email protected]> wrote:
> > Saw this warning running latest git (Ubuntu daily mainline.) It looked
> > similar to what Andy saw on MSI hardware -
> > http://www.spinics.net/lists/linux-acpi/msg43410.html . The patch for
> > it doesn't seem to be merged, although it won't help in my case -
> > different hardware with valid status instead of invalid and image
> > address falling in system RAM instead of just being wild.
> >
> > Unsure how this should be handled - moving the is_ram() check in
> > efi_bgrt_init and ignoring the BGRT in case where the check succeeds?
> > Doesn't sound completely right to me - since the BGRT is valid and
> > exists somewhere, but..
> >
> > [ 0.015141] ------------[ cut here ]------------
> > [ 0.015147] WARNING: CPU: 0 PID: 0 at
> > /home/apw/COD/linux/arch/x86/mm/ioremap.c:102
> > __ioremap_caller+0x312/0x390()
> > [ snip ]
> > [ 0.015160] Call Trace:
> > [ 0.015165] [<ffffffff8170a704>] dump_stack+0x46/0x58
> > [ 0.015169] [<ffffffff8106406c>] warn_slowpath_common+0x8c/0xc0
> > [ 0.015171] [<ffffffff810640ba>] warn_slowpath_null+0x1a/0x20
> > [ 0.015173] [<ffffffff81054e32>] __ioremap_caller+0x312/0x390
> > [ 0.015176] [<ffffffff814013d4>] ? acpi_tb_verify_table+0x54/0x58
> > [ 0.015179] [<ffffffff81d35551>] ? efi_bgrt_init+0x8f/0x143
> > [ 0.015181] [<ffffffff81054f07>] ioremap_nocache+0x17/0x20
> > [ 0.015183] [<ffffffff81d35551>] efi_bgrt_init+0x8f/0x143
> > [ 0.015186] [<ffffffff81401d36>] ? acpi_tb_initialize_facs+0x32/0x34
> > [ 0.015188] [<ffffffff81d34e7f>] efi_late_init+0x9/0xb
> > [ 0.015190] [<ffffffff81d18f17>] start_kernel+0x3fd/0x419
> > [ 0.015192] [<ffffffff81d189ac>] ? do_early_param+0x87/0x87
> > [ 0.015194] [<ffffffff81d18120>] ? early_idt_handlers+0x120/0x120
> > [ 0.015196] [<ffffffff81d185e6>] x86_64_start_reservations+0x2a/0x2c
> >
> > ioremap.c:102
> > /*
> > * Don't allow anybody to remap normal RAM that we're using..
> > */
> > last_pfn = last_addr >> PAGE_SHIFT;
> > for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) {
> > int is_ram = page_is_ram(pfn);
> >
> > if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
> > return NULL;
> > WARN_ON_ONCE(is_ram);
> > }
> >
> > Looking at the BGRT table from IASL, the status seems to be valid but
> > the image address *seems* to me that is falling under system RAM.
>
> 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?
Because that would be *special*. I don't think it's worth trying to
cope with that bug; better to just write off the BGRT as invalid if the
BIOS can't get endianness right.
In theory we could guess at that bug if the unmangled address points to
a location in RAM starting with a BMP header. In practice, let's not; a
missing BGRT is a purely cosmetic issue, and BIOS vendors can learn to
get that one right if they want to see their logo during Linux boot.
This won't break fastboot support, it just breaks fancy crossfades from
the BIOS logo to a Linux desktop or splash.
So, a "firmware bug" message in dmesg seems sufficent for that case. We
do need to handle the case of a valid pointer into memory that e820
calls system RAM, as well as the case of a valid pointer into memory
reserved for the BIOS or similar, but not the case of an invalid
pointer.
- Josh Triplett
On Mon, Jul 15, 2013 at 4:04 PM, Josh Triplett <[email protected]> wrote:
> On Mon, Jul 15, 2013 at 01:28:36PM -0700, Andy Lutomirski wrote:
>> On Sun, Jul 14, 2013 at 12:07 PM, Parag Warudkar <[email protected]> wrote:
>> > Saw this warning running latest git (Ubuntu daily mainline.) It looked
>> > similar to what Andy saw on MSI hardware -
>> > http://www.spinics.net/lists/linux-acpi/msg43410.html . The patch for
>> > it doesn't seem to be merged, although it won't help in my case -
>> > different hardware with valid status instead of invalid and image
>> > address falling in system RAM instead of just being wild.
>> >
>> > Unsure how this should be handled - moving the is_ram() check in
>> > efi_bgrt_init and ignoring the BGRT in case where the check succeeds?
>> > Doesn't sound completely right to me - since the BGRT is valid and
>> > exists somewhere, but..
>> >
>> > [ 0.015141] ------------[ cut here ]------------
>> > [ 0.015147] WARNING: CPU: 0 PID: 0 at
>> > /home/apw/COD/linux/arch/x86/mm/ioremap.c:102
>> > __ioremap_caller+0x312/0x390()
>> > [ snip ]
>> > [ 0.015160] Call Trace:
>> > [ 0.015165] [<ffffffff8170a704>] dump_stack+0x46/0x58
>> > [ 0.015169] [<ffffffff8106406c>] warn_slowpath_common+0x8c/0xc0
>> > [ 0.015171] [<ffffffff810640ba>] warn_slowpath_null+0x1a/0x20
>> > [ 0.015173] [<ffffffff81054e32>] __ioremap_caller+0x312/0x390
>> > [ 0.015176] [<ffffffff814013d4>] ? acpi_tb_verify_table+0x54/0x58
>> > [ 0.015179] [<ffffffff81d35551>] ? efi_bgrt_init+0x8f/0x143
>> > [ 0.015181] [<ffffffff81054f07>] ioremap_nocache+0x17/0x20
>> > [ 0.015183] [<ffffffff81d35551>] efi_bgrt_init+0x8f/0x143
>> > [ 0.015186] [<ffffffff81401d36>] ? acpi_tb_initialize_facs+0x32/0x34
>> > [ 0.015188] [<ffffffff81d34e7f>] efi_late_init+0x9/0xb
>> > [ 0.015190] [<ffffffff81d18f17>] start_kernel+0x3fd/0x419
>> > [ 0.015192] [<ffffffff81d189ac>] ? do_early_param+0x87/0x87
>> > [ 0.015194] [<ffffffff81d18120>] ? early_idt_handlers+0x120/0x120
>> > [ 0.015196] [<ffffffff81d185e6>] x86_64_start_reservations+0x2a/0x2c
>> >
>> > ioremap.c:102
>> > /*
>> > * Don't allow anybody to remap normal RAM that we're using..
>> > */
>> > last_pfn = last_addr >> PAGE_SHIFT;
>> > for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) {
>> > int is_ram = page_is_ram(pfn);
>> >
>> > if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
>> > return NULL;
>> > WARN_ON_ONCE(is_ram);
>> > }
>> >
>> > Looking at the BGRT table from IASL, the status seems to be valid but
>> > the image address *seems* to me that is falling under system RAM.
>>
>> 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.
>
> Because that would be *special*. I don't think it's worth trying to
> cope with that bug; better to just write off the BGRT as invalid if the
> BIOS can't get endianness right.
>
> In theory we could guess at that bug if the unmangled address points to
> a location in RAM starting with a BMP header. In practice, let's not; a
> missing BGRT is a purely cosmetic issue, and BIOS vendors can learn to
> get that one right if they want to see their logo during Linux boot.
> This won't break fastboot support, it just breaks fancy crossfades from
> the BIOS logo to a Linux desktop or splash.
FWIW, the address that my BIOS gives is non-canonical. Maybe that's
good enough.
>
> So, a "firmware bug" message in dmesg seems sufficent for that case. We
> do need to handle the case of a valid pointer into memory that e820
> calls system RAM, as well as the case of a valid pointer into memory
> reserved for the BIOS or similar, but not the case of an invalid
> pointer.
Is the efi_bgrt code called early enough that data in system RAM will
still be there?
--Andy
On Mon, Jul 15, 2013 at 04:08:13PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 15, 2013 at 4:04 PM, Josh Triplett <[email protected]> wrote:
> > On Mon, Jul 15, 2013 at 01:28:36PM -0700, Andy Lutomirski wrote:
> >> On Sun, Jul 14, 2013 at 12:07 PM, Parag Warudkar <[email protected]> wrote:
> >> > Saw this warning running latest git (Ubuntu daily mainline.) It looked
> >> > similar to what Andy saw on MSI hardware -
> >> > http://www.spinics.net/lists/linux-acpi/msg43410.html . The patch for
> >> > it doesn't seem to be merged, although it won't help in my case -
> >> > different hardware with valid status instead of invalid and image
> >> > address falling in system RAM instead of just being wild.
> >> >
> >> > Unsure how this should be handled - moving the is_ram() check in
> >> > efi_bgrt_init and ignoring the BGRT in case where the check succeeds?
> >> > Doesn't sound completely right to me - since the BGRT is valid and
> >> > exists somewhere, but..
> >> >
> >> > [ 0.015141] ------------[ cut here ]------------
> >> > [ 0.015147] WARNING: CPU: 0 PID: 0 at
> >> > /home/apw/COD/linux/arch/x86/mm/ioremap.c:102
> >> > __ioremap_caller+0x312/0x390()
> >> > [ snip ]
> >> > [ 0.015160] Call Trace:
> >> > [ 0.015165] [<ffffffff8170a704>] dump_stack+0x46/0x58
> >> > [ 0.015169] [<ffffffff8106406c>] warn_slowpath_common+0x8c/0xc0
> >> > [ 0.015171] [<ffffffff810640ba>] warn_slowpath_null+0x1a/0x20
> >> > [ 0.015173] [<ffffffff81054e32>] __ioremap_caller+0x312/0x390
> >> > [ 0.015176] [<ffffffff814013d4>] ? acpi_tb_verify_table+0x54/0x58
> >> > [ 0.015179] [<ffffffff81d35551>] ? efi_bgrt_init+0x8f/0x143
> >> > [ 0.015181] [<ffffffff81054f07>] ioremap_nocache+0x17/0x20
> >> > [ 0.015183] [<ffffffff81d35551>] efi_bgrt_init+0x8f/0x143
> >> > [ 0.015186] [<ffffffff81401d36>] ? acpi_tb_initialize_facs+0x32/0x34
> >> > [ 0.015188] [<ffffffff81d34e7f>] efi_late_init+0x9/0xb
> >> > [ 0.015190] [<ffffffff81d18f17>] start_kernel+0x3fd/0x419
> >> > [ 0.015192] [<ffffffff81d189ac>] ? do_early_param+0x87/0x87
> >> > [ 0.015194] [<ffffffff81d18120>] ? early_idt_handlers+0x120/0x120
> >> > [ 0.015196] [<ffffffff81d185e6>] x86_64_start_reservations+0x2a/0x2c
> >> >
> >> > ioremap.c:102
> >> > /*
> >> > * Don't allow anybody to remap normal RAM that we're using..
> >> > */
> >> > last_pfn = last_addr >> PAGE_SHIFT;
> >> > for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) {
> >> > int is_ram = page_is_ram(pfn);
> >> >
> >> > if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
> >> > return NULL;
> >> > WARN_ON_ONCE(is_ram);
> >> > }
> >> >
> >> > Looking at the BGRT table from IASL, the status seems to be valid but
> >> > the image address *seems* to me that is falling under system RAM.
> >>
> >> 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.
> > Because that would be *special*. I don't think it's worth trying to
> > cope with that bug; better to just write off the BGRT as invalid if the
> > BIOS can't get endianness right.
> >
> > In theory we could guess at that bug if the unmangled address points to
> > a location in RAM starting with a BMP header. In practice, let's not; a
> > missing BGRT is a purely cosmetic issue, and BIOS vendors can learn to
> > get that one right if they want to see their logo during Linux boot.
> > This won't break fastboot support, it just breaks fancy crossfades from
> > the BIOS logo to a Linux desktop or splash.
>
> FWIW, the address that my BIOS gives is non-canonical. Maybe that's
> good enough.
What do you mean by "non-canonical".
> > So, a "firmware bug" message in dmesg seems sufficent for that case. We
> > do need to handle the case of a valid pointer into memory that e820
> > calls system RAM, as well as the case of a valid pointer into memory
> > reserved for the BIOS or similar, but not the case of an invalid
> > pointer.
>
> Is the efi_bgrt code called early enough that data in system RAM will
> still be there?
In theory, it should always point to data in EFI's "reserved until after
boot time" memory.
- Josh Triplett
On Mon, Jul 15, 2013 at 4:20 PM, Josh Triplett <[email protected]> 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 <[email protected]> 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.
>
>> > Because that would be *special*. I don't think it's worth trying to
>> > cope with that bug; better to just write off the BGRT as invalid if the
>> > BIOS can't get endianness right.
>> >
>> > In theory we could guess at that bug if the unmangled address points to
>> > a location in RAM starting with a BMP header. In practice, let's not; a
>> > missing BGRT is a purely cosmetic issue, and BIOS vendors can learn to
>> > get that one right if they want to see their logo during Linux boot.
>> > This won't break fastboot support, it just breaks fancy crossfades from
>> > the BIOS logo to a Linux desktop or splash.
>>
>> FWIW, the address that my BIOS gives is non-canonical. Maybe that's
>> good enough.
>
> What do you mean by "non-canonical".
Brainfart. I'm confusing physical and virtual addresses. More
usefully, the bogus address from my BIOS is too large -- it's way
above the highest e820 spot (and I'm pretty sure it exceeds the
maximum address that my CPU can address). Maybe that would be a
decent heuristic to use to avoid trying to follow the pointer.
>
>> > So, a "firmware bug" message in dmesg seems sufficent for that case. We
>> > do need to handle the case of a valid pointer into memory that e820
>> > calls system RAM, as well as the case of a valid pointer into memory
>> > reserved for the BIOS or similar, but not the case of an invalid
>> > pointer.
>>
>> Is the efi_bgrt code called early enough that data in system RAM will
>> still be there?
>
> In theory, it should always point to data in EFI's "reserved until after
> boot time" memory.
>
> - Josh Triplett
On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett <[email protected]> wrote:
> We do need to handle the case of a valid pointer into memory that e820
> calls system RAM, as well as the case of a valid pointer into memory
> reserved for the BIOS or similar, but not the case of an invalid
> pointer.
Would that be as simple as
page_is_ram(
On Mon, Jul 15, 2013 at 7:56 PM, Parag Warudkar <[email protected]> wrote:
> On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett <[email protected]> wrote:
>
>> We do need to handle the case of a valid pointer into memory that e820
>> calls system RAM, as well as the case of a valid pointer into memory
>> reserved for the BIOS or similar, but not the case of an invalid
>> pointer.
>
> Would that be as simple as
>
> page_is_ram(
Damn shortcuts -
virt_addr = phys_to_virt(image->base_address);
if(page_is_ram(virt_to_page(virt_addr))) {
//direct read from virt addr
}
Would that suffice for the System RAM case or some other MM trickery
is involved?
Thanks,
Parag
On Mon, Jul 15, 2013 at 4:24 PM, Andy Lutomirski <[email protected]> wrote:
> On Mon, Jul 15, 2013 at 4:20 PM, Josh Triplett <[email protected]> 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 <[email protected]> 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