From mboxrd@z Thu Jan 1 00:00:00 1970 From: Len Brown Subject: Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code Date: Thu, 06 Jan 2011 16:01:12 -0500 (EST) Message-ID: References: <201101060028.43342.rjw@sisk.pl> <201101061657.39723.rjw@sisk.pl> <4D25E943.804@gmail.com> <201101061738.14581.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: Received: from vms173009pub.verizon.net ([206.46.173.9]:55144 "EHLO vms173009pub.verizon.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752489Ab1AFVB1 (ORCPT ); Thu, 6 Jan 2011 16:01:27 -0500 In-reply-to: <201101061738.14581.rjw@sisk.pl> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: "Rafael J. Wysocki" Cc: Jiri Slaby , Jiri Slaby , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, ACPI Devel Maling List , Linux-pm mailing list , Matthew Garrett > ... My theory is that we have mapped the > same area already using ioremap_cache() and now we're trying to map it again > using ioremap_nocache(), hence the conflict. I need to confirm this. On my test box. BIOS-e820: 0000000077626000 - 0000000077632000 (ACPI NVS) yet there are at least two tables (FACS and SSDT) that live in that region, and there are several run-time AML memory opregions residing in that range too. So the region has already been mapped by acpi_os_map_memory() (now using ioremap_cache()) before suspend_nvs_save() runs. Is there a reason that suspend_nvs_save() requires a non-cached mapping? cheers, Len Brown, Intel Open Source Technology Center