linux-kernel - Re: EeePC 900 trackpad often not detected at boot in 2.6.30-rc4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090520024658.GD17649@dtor-d630.eng.vmware.com>
Date:	Tue, 19 May 2009 19:47:08 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Sitsofe Wheeler <sitsofe@...oo.com>
Cc:	linux-kernel@...r.kernel.org,
	Alan Jenkins <sourcejedi.lkml@...glemail.com>,
	Matthew Garrett <mjg59@...f.ucam.org>, mingo@...e.hu
Subject: Re: EeePC 900 trackpad often not detected at boot in 2.6.30-rc4

On Mon, May 18, 2009 at 10:42:10AM +0100, Sitsofe Wheeler wrote:
> On Mon, May 18, 2009 at 09:41:46AM +0100, Sitsofe Wheeler wrote:
> > 
> > And of course just as soon as I finish building a new kernel the issue
> > disappears. Even in older kernels that were seemingly showing the
> > problem all the time. Sigh.
> 
> After numerous reboots I finally managed to reproduce the problem the
> original way with your patch installed. I have no idea what the
> necessary triggers are but I suspect it involves suspend to ram...
> 

It is just unfortunate scheduling that messes us up:

> [    4.267050] drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, 1, 12) [113]
> [    4.270440] drivers/input/serio/i8042.c: d4 -> i8042 (command) [116]
> [    4.271016] drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [116]
> [    4.274883] ALSA device list:
> [    4.274963]   #0: HDA Intel at 0xf7eb8000 irq 16
> [    4.275258] TCP cubic registered
> [    4.276597] NET: Registered protocol family 17
> [    4.276802] Using IPI Shortcut mode
> [    4.279191]   Magic number: 9:810:70
> [    4.279548] rtc_cmos 00:03: setting system clock to 2009-05-18 09:03:27 UTC (1242637407)
> [    4.281412] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 1, 12) [127]
> [    4.283338] drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, 1, 12) [129]
> [    5.406620] libps2: errorneously fail 754 command

As you can see the device responded to our command and interrupt fired
at 4.28 but for some reason the thread did not get woken up until 5.40,
second and a half later... Crazy if you ask me.

Ingo, do you have any idea why would it not be woken up for so long???

In the meantime, the patch below should fix work around that delay.

-- 
Dmitry


Input: libps2 - better handle bad scheduler decisions

From: Dmitry Torokhov <dmitry.torokhov@...il.com>

Sometimes devices send us their responses in time but due to
unfortunate scheduling decisions the receiving thread does not
get scheduled till much later and we erroneously decide that
device timed out. Work around this problem by checking whether we
received the data we needed instead of checking timeout
condition.

Signed-off-by: Dmitry Torokhov <dtor@...l.ru>
---

 drivers/input/serio/libps2.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
index a0d8968..3a95b50 100644
--- a/drivers/input/serio/libps2.c
+++ b/drivers/input/serio/libps2.c
@@ -208,7 +208,7 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command)
 	timeout = wait_event_timeout(ps2dev->wait,
 				     !(ps2dev->flags & PS2_FLAG_CMD1), timeout);
 
-	if (ps2dev->cmdcnt && timeout > 0) {
+	if (ps2dev->cmdcnt && !(ps2dev->flags & PS2_FLAG_CMD1)) {
 
 		timeout = ps2_adjust_timeout(ps2dev, command, timeout);
 		wait_event_timeout(ps2dev->wait,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/