[kernel] r16268 - in dists/sid/linux-2.6/debian: . patches/bugfix/x86 patches/series

Ben Hutchings benh at alioth.debian.org
Sun Sep 12 16:36:04 UTC 2010


Author: benh
Date: Sun Sep 12 16:35:49 2010
New Revision: 16268

Log:
[x86] HPET: unmap unused I/O space

Added:
   dists/sid/linux-2.6/debian/patches/bugfix/x86/HPET-unmap-unused-I-O-space.patch
Modified:
   dists/sid/linux-2.6/debian/changelog
   dists/sid/linux-2.6/debian/patches/series/22

Modified: dists/sid/linux-2.6/debian/changelog
==============================================================================
--- dists/sid/linux-2.6/debian/changelog	Sun Sep 12 14:29:06 2010	(r16267)
+++ dists/sid/linux-2.6/debian/changelog	Sun Sep 12 16:35:49 2010	(r16268)
@@ -50,6 +50,7 @@
     controllers
   * r8169: Remove MODULE_FIRMWARE declarations since the firmware is
     non-essential and we do not distribute it
+  * [x86] HPET: unmap unused I/O space
 
   [ Bastian Blank ]
   * Use Breaks instead of Conflicts.

Added: dists/sid/linux-2.6/debian/patches/bugfix/x86/HPET-unmap-unused-I-O-space.patch
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ dists/sid/linux-2.6/debian/patches/bugfix/x86/HPET-unmap-unused-I-O-space.patch	Sun Sep 12 16:35:49 2010	(r16268)
@@ -0,0 +1,83 @@
+From: Jiri Slaby <jslaby at suse.cz>
+Subject: [PATCH -resend 1/1] HPET: unmap unused I/O space
+Date: Fri,  3 Sep 2010 10:27:54 +0200
+
+When the initialization code in hpet founds a memory resource and does
+not found IRQ, it does not unmap the memory resource previously
+mapped.
+
+There are buggy BIOSes which report resources exactly like this and
+what is worse the memory region bases point to normal RAM. This
+normally would not matter since the space is not touched. But when PAT
+is turned on, ioremap causes the page to be uncached and sets this bit
+in page->flags.
+
+Then when the page is about to be used by the allocator, it is
+reported as:
+BUG: Bad page state in process md5sum  pfn:3ed00
+page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
+page flags: 0x20000001000000(uncached)
+Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
+Call Trace:
+ [<ffffffff810df851>] bad_page+0xb1/0x100
+ [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0
+ [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640
+ [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0
+...
+
+In this particular case:
+
+1) HPET returns 3ed00000 as memory region base, but it is not in
+reserved ranges reported by the BIOS (excerpt):
+ BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable)
+ BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved)
+
+2) there is no IRQ resource reported by HPET method. On the other
+hand, the Intel HPET specs (1.0a) says (3.2.5.1):
+_CRS (
+  // Report 1K of memory consumed by this Timer Block
+  memory range consumed
+  // Optional: only used if BIOS allocates Interrupts [1]
+  IRQs consumed
+)
+
+[1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND
+Legacy 8254/Legacy RTC hardware still exists, the device objects
+associated with 8254 & RTC devices should not report IRQ0/IRQ8 as
+“consumed resources.”
+
+So in theory we should check whether if it is the case and use those
+interrupts instead.
+
+Anyway the address reported by the BIOS here is bogus, so non-presence
+of IRQ doesn't mean the "optional" part in point 2).
+
+Since I got no reply previously, fix this by simply unmapping the
+space when IRQ is not found and memory region was mapped previously.
+It would be probably more safe to walk the resources again and unmap
+appropriately depending on type.  But as we now use only ioremap for
+both 2 memory resource types, it is not necessarily needed right now.
+
+References: https://bugzilla.novell.com/show_bug.cgi?id=629908
+Signed-off-by: Jiri Slaby <jslaby at suse.cz>
+Acked-by: Clemens Ladisch <clemens at ladisch.de>
+---
+ drivers/char/hpet.c |    2 ++
+ 1 files changed, 2 insertions(+), 0 deletions(-)
+
+diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
+index 8372a34..e3e184b 100644
+--- a/drivers/char/hpet.c
++++ b/drivers/char/hpet.c
+@@ -1017,6 +1017,8 @@ static int hpet_acpi_add(struct acpi_device *device)
+ 		return -ENODEV;
+ 
+ 	if (!data.hd_address || !data.hd_nirqs) {
++		if (data.hd_address)
++			iounmap(data.hd_address);
+ 		printk("%s: no address or irqs in _CRS\n", __func__);
+ 		return -ENODEV;
+ 	}
+-- 
+1.7.2.1
+

Modified: dists/sid/linux-2.6/debian/patches/series/22
==============================================================================
--- dists/sid/linux-2.6/debian/patches/series/22	Sun Sep 12 14:29:06 2010	(r16267)
+++ dists/sid/linux-2.6/debian/patches/series/22	Sun Sep 12 16:35:49 2010	(r16268)
@@ -120,3 +120,4 @@
 + features/all/r8169-rtl8168d-1-2-request_firmware-3.patch
 + bugfix/all/irda-correctly-clean-up-self-ias_obj-on-irda_bind-failure.patch
 + bugfix/all/drm-nouveau-nva3-noaccel.patch
++ bugfix/x86/HPET-unmap-unused-I-O-space.patch



More information about the Kernel-svn-changes mailing list