Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753203AbbB0KhY (ORCPT ); Fri, 27 Feb 2015 05:37:24 -0500 Received: from foss.arm.com ([217.140.101.70]:42991 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752317AbbB0KhT (ORCPT ); Fri, 27 Feb 2015 05:37:19 -0500 Date: Fri, 27 Feb 2015 10:36:50 +0000 From: Mark Rutland To: Ard Biesheuvel Cc: Timur Tabi , "hanjun.guo@linaro.org" , Catalin Marinas , "Rafael J. Wysocki" , Will Deacon , Olof Johansson , "grant.likely@linaro.org" , Ashwin Chaugule , Lorenzo Pieralisi , Robert Richter , Arnd Bergmann , "graeme.gregory@linaro.org" , Linaro ACPI Mailman List , Marc Zyngier , "jcm@redhat.com" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Mark Brown , "suravee.suthikulpanit@amd.com" , Sudeep Holla , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v9 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 Message-ID: <20150227103650.GA9011@leverpostej> References: <1424853601-6675-1-git-send-email-hanjun.guo@linaro.org> <54EFE282.1090305@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1683 Lines: 39 > > I'm still debugging it, but v9 on the 4.0-rc1 kernel crashes after calling > > the UEFI boot time services exit function. That is, this line: > > > > status = sys_table->boottime->exit_boot_services(handle, mmap_key); > > > > in allocate_new_fdt_and_exit_boot() gets called, and then soon after it > > returns, the kernel crashes. It's really early because the UEFI exception > > handler is called. > > > > I did not have this problem with v8 patchset on 3.19. > > > > Are you not seeing this on v4.0-rc1 without the patchset applied? > > Could the crash be inside the subsequent call to > SetVirtualAddressMap() instead of inside ExitBootServices()? > > If so, you have a firmware bug: Mark Rutland spotted a similar bug in > the AMD Seattle firmware, which has been fixed in the mean time. > It has to do with the firmware dereferencing the virtual mapping as it > is being installed, which violates the UEFI spec. A simple way to test is to change EFI_RT_VIRTUAL_BASE to point to the (unmapped) high half of the address space (e.g. set it to 0xffff000000000000). If EFI is using pointers erroneously then something should fault within SetVirtualAddressMap(), and you can catch this with your favourite debugger. Otherwise it's possible that the virtual address space chosen will cover memory and/or devices in the existing idmap, and any erroneous accesses will corrupt memory and/or cause devices to explode. Thanks, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/