All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.