lkml.org 
[lkml]   [2009]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: EeePC 900 trackpad often not detected at boot in 2.6.30-rc4
On Wed, May 20, 2009 at 10:38:46AM +0200, Ingo Molnar wrote:
> * Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > 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???
>
> possibly something else was running (looping?) in that time? A more
> detailed trace would tell i guess.

What sort of options do I boot with for such a trace? Would
booting with initcall_debug be enough?

--
Sitsofe | http://sucs.org/~sits/


\
 
 \ /
  Last update: 2009-05-27 00:17    [W:0.192 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site