From patchwork Wed Aug 24 04:16:15 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Huang, Ying" X-Patchwork-Id: 1090702 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p7O4EINN029289 for ; Wed, 24 Aug 2011 04:14:19 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750803Ab1HXEOC (ORCPT ); Wed, 24 Aug 2011 00:14:02 -0400 Received: from mga01.intel.com ([192.55.52.88]:31295 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750788Ab1HXEOC (ORCPT ); Wed, 24 Aug 2011 00:14:02 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 23 Aug 2011 21:14:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,273,1312182000"; d="scan'208";a="44439924" Received: from yhuang-mobile.sh.intel.com (HELO [10.239.70.127]) ([10.239.70.127]) by fmsmga001.fm.intel.com with ESMTP; 23 Aug 2011 21:13:59 -0700 Message-ID: <4E547B0F.6000001@intel.com> Date: Wed, 24 Aug 2011 12:16:15 +0800 From: Huang Ying User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: "rick@microway.com" CC: Don Zickus , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Richard Houghton , ACPI Devel Mailing List , Len Brown , Matthew Garrett Subject: Re: kernel oops and panic in acpi_atomic_read under 2.6.39.3. call trace included References: <201108171751.51648.rick@microway.com> <8338f9871d1f52f9376a1eca319a7866.squirrel@www.microway.com> <201108222047.11086.rjw@sisk.pl> <201108221651.35654.rick@microway.com> <20110823171432.GA10794@redhat.com> In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Wed, 24 Aug 2011 04:14:19 +0000 (UTC) Hi, Rick, It appears that panic occurs in acpi_atomic_read. I think the most likely cause is that the acpi_generic_address is not pre-mapped. Can you try the patch attached? It will print registers mapped and accessed. To use it, run the following command line before workload. dmesg | grep GHES Then try to find something like GHES: gar accessed: x, xxxx in kernel log when panic occurs. Best Regards, Huang Ying --- drivers/acpi/apei/ghes.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -299,6 +299,9 @@ static struct ghes *ghes_new(struct acpi return ERR_PTR(-ENOMEM); ghes->generic = generic; rc = acpi_pre_map_gar(&generic->error_status_address); + pr_info(GHES_PFX "gar mapped: %d, 0x%llx\n", + generic->error_status_address.space_id, + generic->error_status_address.address); if (rc) goto err_free; error_block_length = generic->error_block_length; @@ -398,6 +401,9 @@ static int ghes_read_estatus(struct ghes u32 len; int rc; + pr_info(GHES_PFX "gar accessed: %d, 0x%llx\n", + g->error_status_address.space_id, + g->error_status_address.address); rc = acpi_atomic_read(&buf_paddr, &g->error_status_address); if (rc) { if (!silent && printk_ratelimit())