public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David N. Welton" <davidw@eidetix.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Sascha Wilde <wilde@sha-bang.de>,
	Dmitry Torokhov <dtor_core@ameritech.net>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.6 kernel won't reboot on AMD system - 8042 problem?
Date: Fri, 13 Aug 2004 12:13:30 +0200	[thread overview]
Message-ID: <411C944A.3040907@eidetix.com> (raw)
In-Reply-To: <20040812201344.GA270@ucw.cz>

Vojtech Pavlik wrote:

> 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.

Sure, if you search google on the results from the 20 command, you see a 
lot of things like 0x64 0x64 0x75 0x74 and similar values.

> 0x9a doesn't make sense _AT_ALL_, though!

Right.

> 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.

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...

-- 
David N. Welton
davidw@eidetix.com

  reply	other threads:[~2004-08-13 10:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-11 14:14 2.6 kernel won't reboot on AMD system - 8042 problem? Dmitry Torokhov
2004-08-11 17:56 ` Sascha Wilde
2004-08-12 17:00   ` David N. Welton
2004-08-12 17:23     ` David N. Welton
2004-08-13 21:29       ` Sascha Wilde
2004-08-12 20:13     ` Vojtech Pavlik
2004-08-13 10:13       ` David N. Welton [this message]
2004-08-13 12:03         ` Vojtech Pavlik
2004-08-13 12:58           ` David N. Welton
     [not found] <auto-000000462036@appliedminds.com>
2004-08-09  8:28 ` David N. Welton
2004-08-10  9:37   ` Sascha Wilde
2004-08-10 15:38     ` James Lamanna
     [not found] <4112A626.1000706@appliedminds.com>
2004-08-06  8:22 ` David N. Welton
2004-08-06 16:55   ` James Lamanna
2004-08-08 12:18   ` Sascha Wilde
2004-08-08 15:05     ` Dmitry Torokhov
2004-08-11 20:06       ` Sascha Wilde
  -- strict thread matches above, loose matches on Subject: below --
2004-07-28 17:51 2.6 kernel won't reboot on AMD system (no, not the BIOS...) David N. Welton
2004-08-05 12:48 ` 2.6 kernel won't reboot on AMD system - 8042 problem? David N. Welton
2004-08-05 19:25   ` Sascha Wilde
2004-08-11  6:31   ` Dmitry Torokhov
2004-08-11  8:36     ` David N. Welton
2004-08-11 12:27     ` Vojtech Pavlik
2004-08-11 12:45       ` David N. Welton
2004-08-11 13:43       ` Sascha Wilde
2004-08-11 14:17         ` Vojtech Pavlik
2004-08-11 13:55       ` David Ford
2004-08-11 20:14     ` Sascha Wilde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=411C944A.3040907@eidetix.com \
    --to=davidw@eidetix.com \
    --cc=dtor_core@ameritech.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vojtech@suse.cz \
    --cc=wilde@sha-bang.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox