lkml.org 
[lkml]   [2009]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: 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@gmail.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@mail.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,

    \
     
     \ /
      Last update: 2009-05-20 04:49    [W:0.025 / U:62.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site