releases/2.6.36.2/hpet-unmap-unused-i-o-space.patch

   1 From a56d5318716d120e040294bb258901ba89fb9c90 Mon Sep 17 00:00:00 2001
   2 From: Jiri Slaby <jslaby@suse.cz>
   3 Date: Tue, 26 Oct 2010 14:22:11 -0700
   4 Subject: hpet: unmap unused I/O space
   5
   6 From: Jiri Slaby <jslaby@suse.cz>
   7
   8 commit a56d5318716d120e040294bb258901ba89fb9c90 upstream.
   9
  10 When the initialization code in hpet finds a memory resource and does not
  11 find an IRQ, it does not unmap the memory resource previously mapped.
  12
  13 There are buggy BIOSes which report resources exactly like this and what
  14 is worse the memory region bases point to normal RAM.  This normally would
  15 not matter since the space is not touched.  But when PAT is turned on,
  16 ioremap causes the page to be uncached and sets this bit in page->flags.
  17
  18 Then when the page is about to be used by the allocator, it is reported
  19 as:
  20
  21 BUG: Bad page state in process md5sum  pfn:3ed00
  22 page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
  23 page flags: 0x20000001000000(uncached)
  24 Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
  25 Call Trace:
  26  [<ffffffff810df851>] bad_page+0xb1/0x100
  27  [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0
  28  [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640
  29  [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0
  30 ...
  31
  32 In this particular case:
  33
  34 1) HPET returns 3ed00000 as memory region base, but it is not in
  35 reserved ranges reported by the BIOS (excerpt):
  36  BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable)
  37  BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved)
  38
  39 2) there is no IRQ resource reported by HPET method. On the other
  40 hand, the Intel HPET specs (1.0a) says (3.2.5.1):
  41 _CRS (
  42   // Report 1K of memory consumed by this Timer Block
  43   memory range consumed
  44   // Optional: only used if BIOS allocates Interrupts [1]
  45   IRQs consumed
  46 )
  47
  48 [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND
  49 Legacy 8254/Legacy RTC hardware still exists, the device objects
  50 associated with 8254 & RTC devices should not report IRQ0/IRQ8 as
  51 "consumed resources".
  52
  53 So in theory we should check whether if it is the case and use those
  54 interrupts instead.
  55
  56 Anyway the address reported by the BIOS here is bogus, so non-presence
  57 of IRQ doesn't mean the "optional" part in point 2).
  58
  59 Since I got no reply previously, fix this by simply unmapping the space
  60 when IRQ is not found and memory region was mapped previously.  It would
  61 be probably more safe to walk the resources again and unmap appropriately
  62 depending on type.  But as we now use only ioremap for both 2 memory
  63 resource types, it is not necessarily needed right now.
  64
  65 Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908
  66
  67 Reported-by: Olaf Hering <olaf@aepfle.de>
  68 Signed-off-by: Jiri Slaby <jslaby@suse.cz>
  69 Acked-by: Clemens Ladisch <clemens@ladisch.de>
  70 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
  71 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  72 Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  73
  74 ---
  75  drivers/char/hpet.c |    2 ++
  76  1 file changed, 2 insertions(+)
  77
  78 --- a/drivers/char/hpet.c
  79 +++ b/drivers/char/hpet.c
  80 @@ -985,6 +985,8 @@ static int hpet_acpi_add(struct acpi_dev
  81                 return -ENODEV;
  82
  83         if (!data.hd_address || !data.hd_nirqs) {
  84 +               if (data.hd_address)
  85 +                       iounmap(data.hd_address);
  86                 printk("%s: no address or irqs in _CRS\n", __func__);
  87                 return -ENODEV;
  88         }