On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
so the culprit appears to be:
b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit commit b705120e4198315f4ae043de06c62f65e0851fd3 Author: Michael Karcher kernel@mkarcher.dialup.fu-berlin.de Date: Sun Jan 23 18:17:17 2011 +0000
drm/i915: Use consistent mappings for OpRegion between ACPI and i915 The opregion is a shared memory region between ACPI and the graphics driver. As the ACPI mapping has been changed to cachable in commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion non-cachable now fails. As no bus-master hardware is involved in the opregion, cachable map should do no harm. Tested on a Fujitsu Lifebook P8010. Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> [ickle: convert to acpi_os_ioremap for consistency] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>thoughts? once again, the salient output from "lspci -v":
Indeed looks like using ioremap_cache is not as safe as was assumed. Does
*sigh*. there was, in fact, an "ioremap_error" message displayed *very* early in the boot sequence, but it was generated even for successful boots so i never paid it any mind. in hindsight, might have been useful to have mentioned it.
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..42108ab 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) {
return ioremap_cache(phys, size);
return ioremap_wc(phys, size);}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
ok, i'll make this single change and report back shortly.
rday