linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Parag Warudkar <parag.lkml@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, luto@amacapital.net,
	josh@joshtriplett.org
Subject: BGRT Pointer in System RAM
Date: Sun, 14 Jul 2013 15:07:25 -0400	[thread overview]
Message-ID: <CAOULuOY5VMiiuYmesaGxVWWKtby4Cj9Pc9ctQZeOKfoUzV46dA@mail.gmail.com> (raw)

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

             reply	other threads:[~2013-07-14 19:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-14 19:07 Parag Warudkar [this message]
2013-07-15 20:28 ` BGRT Pointer in System RAM Andy Lutomirski
2013-07-15 23:04   ` Josh Triplett
2013-07-15 23:08     ` Andy Lutomirski
2013-07-15 23:20       ` Josh Triplett
2013-07-15 23:24         ` Andy Lutomirski
2013-07-16 21:15           ` Andy Lutomirski
2013-07-15 23:56     ` Parag Warudkar
2013-07-16  0:00       ` Parag Warudkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOULuOY5VMiiuYmesaGxVWWKtby4Cj9Pc9ctQZeOKfoUzV46dA@mail.gmail.com \
    --to=parag.lkml@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).