[lkml]   [2004]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6 kernel won't reboot on AMD system - 8042 problem?
    On Thu, Aug 12, 2004 at 07:00:04PM +0200, David N. Welton wrote:

    > Sascha Wilde wrote:
    > >>>Is PS/2 supposed to support hotpluging at all? I guess it's not,
    > >>> but I may be wrong...
    > >>
    > >>Yes it is, at least with newer (or rather not ancient) hardware...
    > >
    > >
    > >well, so the patch obviously can't be a final solution...
    > Yes, it doesn't strike me as being ideal.
    > I noticed something odd though... I reported this in another email:
    > *With keyboard* :
    > mice: PS/2 mouse device common for all mice
    > drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
    > drivers/input/serio/i8042.c: 65 <- i8042 (return) [0]
    > *Without keyboard* :
    > mice: PS/2 mouse device common for all mice
    > drivers/input/serio/i8042.c: fa <- i8042 (flush, aux) [0]
    > drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
    > drivers/input/serio/i8042.c: 9a <- i8042 (return) [0]
    > I noticed that
    > 0x9a is the 'inverse' of 0x65. If I set it to 0x65 and write that out,
    > it still reboots afterwards! Hrm. I don't know what that means
    > exactly, but apparently it *is* possible to write something to the
    > controller and have it keep going.

    Reserved bit is zero (must be)
    Scancode translation enabled
    AUX interface disabled
    KBD interface enabled
    Keylock not ignored
    Selftest OK
    AUX interrupt disabled
    KBD interrupt enabled

    All in all, 0x65 is what one would expect to be in the CTR register
    after boot on a normal machine without a PS/2 mouse installed.

    0x9a doesn't make sense _AT_ALL_, though!

    And there comes a thought ...

    In i8042_command(), we do this:

    if (!retval)
    for (i = 0; i < ((command >> 8) & 0xf); i++) {
    if ((retval = i8042_wait_read())) break;
    if (i8042_read_status() & I8042_STR_AUXDATA)
    param[i] = ~i8042_read_data();
    param[i] = i8042_read_data();
    dbg("%02x <- i8042 (return)", param[i]);

    to distinguish whether a response came from the AUX interface instead of
    the KBD or controller itself. We _negate_ the value if the AUXDATA bit is
    set in he status register.

    So I think what happens is that the controller sets the AUXDATA bit for
    some reason (or at least we read a status byte with the AUXDATA bit
    set), which negates the value when we read the initial CTR.

    Then when we write that nonsensical CTR back to the controller on
    reboot, we're screwed, since the i8042 is the more important CPU in the
    system and can do many nasty things to it. ;)

    Now, the question is, where does that AUXDATA bit come from?

    Vojtech Pavlik
    SuSE Labs, SuSE CR
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.029 / U:1.420 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site