[patch 10/28] ACPI: Avoid bogus EC timeout when EC is in Polling mode

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <linux-kernel@...>, <stable@...>
Cc: Justin Forbes <jmforbes@...>, Zwane Mwaikambo <zwane@...>, Theodore Ts'o <tytso@...>, Randy Dunlap <rdunlap@...>, Dave Jones <davej@...>, Chuck Wolber <chuckw@...>, Chris Wedgwood <reviews@...>, Michael Krufky <mkrufky@...>, Chuck Ebbert <cebbert@...>, Domenico Andreoli <cavokz@...>, Willy Tarreau <w@...>, Rodrigo Rubira Branco <rbranco@...>, Jake Edge <jake@...>, Eugene Teo <eteo@...>, <torvalds@...>, <akpm@...>, <alan@...>, <epprecht@...>, Zhao Yakui <yakui.zhao@...>, Zhang Rui <rui.zhang@...>, Andi Kleen <ak@...>
Date: Monday, October 6, 2008 - 7:17 pm

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
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",

-- 
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[patch 00/28] 2.6.25-stable review, Greg KH, (Mon Oct 6, 7:16 pm)
[patch 28/28] udp: Fix rcv socket locking, Greg KH, (Mon Oct 6, 7:18 pm)
[patch 24/28] niu: panic on reset, Greg KH, (Mon Oct 6, 7:17 pm)
[patch 10/28] ACPI: Avoid bogus EC timeout when EC is in Pol..., Greg KH, (Mon Oct 6, 7:17 pm)
[patch 09/28] rtc: fix deadlock, Greg KH, (Mon Oct 6, 7:17 pm)
[patch 07/28] ACPI: Fix thermal shutdowns, Greg KH, (Mon Oct 6, 7:17 pm)
[patch 03/28] pxa2xx_spi: chipselect bugfixes, Greg KH, (Mon Oct 6, 7:17 pm)
[patch 02/28] pxa2xx_spi: dma bugfixes, Greg KH, (Mon Oct 6, 7:17 pm)
Re: [patch 02/28] pxa2xx_spi: dma bugfixes, Ned Forrester, (Mon Oct 6, 8:15 pm)
[patch 01/28] USB: fix hcd interrupt disabling, Greg KH, (Mon Oct 6, 7:16 pm)