]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3 .25 patches
authorGreg Kroah-Hartman <gregkh@suse.de>
Thu, 2 Oct 2008 20:18:30 +0000 (13:18 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 2 Oct 2008 20:18:30 +0000 (13:18 -0700)
queue-2.6.25/acpi-avoid-bogus-ec-timeout-when-ec-is-in-polling-mode.patch [new file with mode: 0644]
queue-2.6.25/rtc-fix-deadlock.patch [new file with mode: 0644]
queue-2.6.25/series
queue-2.6.25/x86-add-io-delay-quirk-for-presario-f700.patch [new file with mode: 0644]

diff --git a/queue-2.6.25/acpi-avoid-bogus-ec-timeout-when-ec-is-in-polling-mode.patch b/queue-2.6.25/acpi-avoid-bogus-ec-timeout-when-ec-is-in-polling-mode.patch
new file mode 100644 (file)
index 0000000..8fff389
--- /dev/null
@@ -0,0 +1,63 @@
+From yakui.zhao@intel.com  Wed Oct  1 16:54:01 2008
+From: Zhao Yakui <yakui.zhao@intel.com>
+Date: Tue, 23 Sep 2008 13:38:13 +0800
+Subject: ACPI: Avoid bogus EC timeout when EC is in Polling mode
+To: stable@kernel.org
+Cc: epprecht@solnet.ch
+Message-ID: <1222148293.3999.168.camel@yakui_zhao.sh.intel.com>
+
+From : Zhao Yakui <yakui.zhao@intel.com>
+
+commit 9d699ed92a459cb408e2577e8bbeabc8ec3989e1 upstream
+
+When EC is in Polling mode, OS will check the EC status continually by using
+the following source code:
+       clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
+       while (time_before(jiffies, delay)) {
+               if (acpi_ec_check_status(ec, event))
+                           return 0;
+               msleep(1);
+       }
+But msleep is realized by the function of schedule_timeout. At the same time
+although one process is already waken up by some events, it won't be scheduled
+immediately. So maybe there exists the following phenomena:
+     a. The current jiffies is already after the predefined jiffies.
+       But before timeout happens, OS has no chance to check the EC
+       status again.
+     b. If preemptible schedule is enabled, maybe preempt schedule will happen
+       before checking loop. When the process is resumed again, maybe
+       timeout already happens, which means that OS has no chance to check
+       the EC status.
+
+In such case maybe EC status is already what OS expects when timeout happens.
+But OS has no chance to check the EC status and regards it as AE_TIME.
+
+So it will be more appropriate that OS will try to check the EC status again
+when timeout happens. If the EC status is what we expect, it won't be regarded
+as timeout. Only when the EC status is not what we expect, it will be regarded
+as timeout, which means that EC controller can't give a response in time.
+
+http://bugzilla.kernel.org/show_bug.cgi?id=9823
+http://bugzilla.kernel.org/show_bug.cgi?id=11141
+
+Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
+Signed-off-by: Zhang Rui  <rui.zhang@intel.com>
+Signed-off-by: Andi Kleen <ak@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ drivers/acpi/ec.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/acpi/ec.c
++++ b/drivers/acpi/ec.c
+@@ -228,6 +228,8 @@ static int acpi_ec_wait(struct acpi_ec *
+                       if (acpi_ec_check_status(ec, event))
+                               goto end;
+               }
++              if (acpi_ec_check_status(ec,event))
++                      return 0;
+       }
+       pr_err(PREFIX "acpi_ec_wait timeout,"
+                              " status = %d, expect_event = %d\n",
diff --git a/queue-2.6.25/rtc-fix-deadlock.patch b/queue-2.6.25/rtc-fix-deadlock.patch
new file mode 100644 (file)
index 0000000..9c64a4a
--- /dev/null
@@ -0,0 +1,66 @@
+From 38c052f8cff1bd323ccfa968136a9556652ee420 Mon Sep 17 00:00:00 2001
+From: Ingo Molnar <mingo@elte.hu>
+Date: Sat, 23 Aug 2008 17:59:07 +0200
+Subject: rtc: fix deadlock
+
+From: Ingo Molnar <mingo@elte.hu>
+
+commit 38c052f8cff1bd323ccfa968136a9556652ee420 upstream
+
+if get_rtc_time() is _ever_ called with IRQs off, we deadlock badly
+in it, waiting for jiffies to increment.
+
+So make the code more robust by doing an explicit mdelay(20).
+
+This solves a very hard to reproduce/debug hard lockup reported
+by Mikael Pettersson.
+
+Reported-by: Mikael Pettersson <mikpe@it.uu.se>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ include/asm-generic/rtc.h |   12 ++++--------
+ 1 file changed, 4 insertions(+), 8 deletions(-)
+
+--- a/include/asm-generic/rtc.h
++++ b/include/asm-generic/rtc.h
+@@ -17,6 +17,7 @@
+ #include <linux/mc146818rtc.h>
+ #include <linux/rtc.h>
+ #include <linux/bcd.h>
++#include <linux/delay.h>
+ #define RTC_PIE 0x40          /* periodic interrupt enable */
+ #define RTC_AIE 0x20          /* alarm interrupt enable */
+@@ -45,7 +46,6 @@ static inline unsigned char rtc_is_updat
+ static inline unsigned int get_rtc_time(struct rtc_time *time)
+ {
+-      unsigned long uip_watchdog = jiffies;
+       unsigned char ctrl;
+       unsigned long flags;
+@@ -55,19 +55,15 @@ static inline unsigned int get_rtc_time(
+       /*
+        * read RTC once any update in progress is done. The update
+-       * can take just over 2ms. We wait 10 to 20ms. There is no need to
++       * can take just over 2ms. We wait 20ms. There is no need to
+        * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
+        * If you need to know *exactly* when a second has started, enable
+        * periodic update complete interrupts, (via ioctl) and then 
+        * immediately read /dev/rtc which will block until you get the IRQ.
+        * Once the read clears, read the RTC time (again via ioctl). Easy.
+        */
+-
+-      if (rtc_is_updating() != 0)
+-              while (jiffies - uip_watchdog < 2*HZ/100) {
+-                      barrier();
+-                      cpu_relax();
+-              }
++      if (rtc_is_updating())
++              mdelay(20);
+       /*
+        * Only the values that we read from the RTC are set. We leave
index 56b813607cd0436ddca6d82f7d43a1442df94dcc..086ba1990a45a3f309303e8462cdaa9a57d02366 100644 (file)
@@ -5,3 +5,6 @@ drivers-mmc-card-block.c-fix-refcount-leak-in-mmc_block_open.patch
 alsa-hda-fix-model-for-dell-inspiron-1525.patch
 i2c-dev-return-correct-error-code-on-class_create-failure.patch
 acpi-fix-thermal-shutdowns.patch
+x86-add-io-delay-quirk-for-presario-f700.patch
+rtc-fix-deadlock.patch
+acpi-avoid-bogus-ec-timeout-when-ec-is-in-polling-mode.patch
diff --git a/queue-2.6.25/x86-add-io-delay-quirk-for-presario-f700.patch b/queue-2.6.25/x86-add-io-delay-quirk-for-presario-f700.patch
new file mode 100644 (file)
index 0000000..a767395
--- /dev/null
@@ -0,0 +1,52 @@
+From cebbert@redhat.com  Wed Oct  1 16:54:55 2008
+From: Chuck Ebbert <cebbert@redhat.com>
+Date: Wed, 24 Sep 2008 19:26:04 -0400
+Subject: x86: add io delay quirk for Presario F700
+To: stable@kernel.org
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Message-ID: <20080924192604.090ffc03@redhat.com>
+
+
+From: Chuck Ebbert <cebbert@redhat.com>
+
+commit e6a5652fd156a286faadbf7a4062b5354d4e346e upstream
+
+Manually adding "io_delay=0xed" fixes system lockups in ioapic
+mode on this machine.
+
+System Information
+       Manufacturer: Hewlett-Packard
+       Product Name: Presario F700 (KA695EA#ABF)
+
+Base Board Information
+       Manufacturer: Quanta
+       Product Name: 30D3
+
+Reference:
+https://bugzilla.redhat.com/show_bug.cgi?id=459546
+
+Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: H. Peter Anvin <hpa@zytor.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/io_delay.c |    8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/arch/x86/kernel/io_delay.c
++++ b/arch/x86/kernel/io_delay.c
+@@ -92,6 +92,14 @@ static struct dmi_system_id __initdata i
+                       DMI_MATCH(DMI_BOARD_NAME, "30BF")
+               }
+       },
++      {
++              .callback       = dmi_io_delay_0xed_port,
++              .ident          = "Presario F700",
++              .matches        = {
++                      DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
++                      DMI_MATCH(DMI_BOARD_NAME, "30D3")
++              }
++      },
+       { }
+ };