Re: EeePC 900 trackpad often not detected at boot in 2.6.30-rc4
From: Dmitry Torokhov
Date: Wed May 20 2009 - 03:25:35 EST
On Tuesday 19 May 2009 22:47:39 Sitsofe Wheeler wrote:
> On Tue, May 19, 2009 at 07:47:08PM -0700, Dmitry Torokhov wrote:
> > It is just unfortunate scheduling that messes us up:
>
> The really frustrating thing is that for a time this was happening quite
> consistently leading me to believe it was a kernel issue...
>
Well, it is a kernel issue... We really should not be waiting for over
1 sec for a process to be woken 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.
>
> It's worth noting that this kernel is stuffed full of debugging options
> as is running on an EeePC 900 with 900Mhz Celeron. I am also using the
> following boot parameters:
>
> root=/dev/sdb2 cfg80211.ieee80211_regdom=GB usb_storage.delay_use=0
> cfg80211 pcie_aspm=force pcie_aspm.policy=powersave fastboot ro
> rootfstype=ext2
>
> > In the meantime, the patch below should fix work around that delay.
>
> This one could be tough to test unless there is a way of forcing the
> awkward scheduling...
Umm.... you could try sticking
if (timeout == 0)
printk(KERN_INFO "libps2: BINGO!\n");
into the body of "if (psmouse->cmdcnt ...)" statement that was modified
by the patch I sent and see if it gets activated. If your mouse still
works with this message in the logs then the patch is working.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/