--- /dev/null
+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",
--- /dev/null
+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
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
--- /dev/null
+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")
++ }
++ },
+ { }
+ };
+