Re: 2.6 kernel won't reboot on AMD system - 8042 problem?

[Vojtech Pavlik <vojtech@suse.cz>]

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.

0x65:
	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();
                        else
                                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