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

Vojtech Pavlik
2004-08-13T12:02:38Z

On Fri, Aug 13, 2004 at 12:13:30PM +0200, David N. Welton wrote:

> Oh, yep, there we go... that's what's switching it around.
>
> >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?
>
> I noticed that the FreeBSD folks attempt to flush both kbd and aux:
>
> http://fxr.watson.org/fxr/source/dev/kbd/atkbdc.c#L790
>
> I tried doing that like so:
>
> while ((i8042_read_status() & (I8042_STR_OBF | I8042_STR_AUXDATA))
> && (i++ < I8042_BUFFER_SIZE)) {
> data = i8042_read_data();
> dbg("%02x <- i8042 (flush, %s)", data,
> i8042_read_status() & I8042_STR_AUXDATA ? "aux" :
> "kbd");
> }
>
> with different variations, and it seems as if it will go on reading
> forever if you let it. So it keeps reporting AUXDATA as being
> present... Hrm...

There is only one queue in the i8042, shared for KBD and AUX. To see if
any data is present, you check the I8042_STR_IBF bit. The
I8042_STR_AUXDATA bit then says which device the data came from.

You can't choose which device you want to read from.

Now I think the problem lies in that that on your i8042 issuing a
command doesn't clear the AUXDATA bit. It's only cleared by data from
the keyboard.

This is likely a bug in you i8042 firmware (or hw, if it's just an
ASIC).

I suppose we can get rid of the checking of data source and negation and
be done with it.

--
Vojtech Pavlik
SuSE Labs, SuSE CR