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

[Vojtech Pavlik <vojtech@suse.cz>]

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