From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Triplett Subject: Re: BGRT Pointer in System RAM Date: Mon, 15 Jul 2013 16:20:53 -0700 Message-ID: <20130715232053.GB2649@leaf> References: <20130715230418.GA2649@leaf> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from relay3-d.mail.gandi.net ([217.70.183.195]:57580 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754474Ab3GOXVB (ORCPT ); Mon, 15 Jul 2013 19:21:01 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Andy Lutomirski Cc: Parag Warudkar , LKML , linux-acpi@vger.kernel.org On Mon, Jul 15, 2013 at 04:08:13PM -0700, Andy Lutomirski wrote: > On Mon, Jul 15, 2013 at 4:04 PM, Josh Triplett 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 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] [] dump_stack+0x46/0x58 > >> > [ 0.015169] [] warn_slowpath_common+0x8c/0xc0 > >> > [ 0.015171] [] warn_slowpath_null+0x1a/0x20 > >> > [ 0.015173] [] __ioremap_caller+0x312/0x390 > >> > [ 0.015176] [] ? acpi_tb_verify_table+0x54/0x58 > >> > [ 0.015179] [] ? efi_bgrt_init+0x8f/0x143 > >> > [ 0.015181] [] ioremap_nocache+0x17/0x20 > >> > [ 0.015183] [] efi_bgrt_init+0x8f/0x143 > >> > [ 0.015186] [] ? acpi_tb_initialize_facs+0x32/0x34 > >> > [ 0.015188] [] efi_late_init+0x9/0xb > >> > [ 0.015190] [] start_kernel+0x3fd/0x419 > >> > [ 0.015192] [] ? do_early_param+0x87/0x87 > >> > [ 0.015194] [] ? early_idt_handlers+0x120/0x120 > >> > [ 0.015196] [] 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