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

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

[Dmitry Torokhov]

Sorry for breaking the thread....

Sascha Wilde wrote:
> On Wed, Aug 11, 2004 at 02:27:11PM +0200, Vojtech Pavlik wrote:
> > On Wed, Aug 11, 2004 at 01:31:13AM -0500, Dmitry Torokhov wrote:
> > > On Thursday 05 August 2004 07:48 am, David N. Welton wrote:
> > > > By putting a series of 'crashme/reboot' calls into the kernel, I
> > > > narrowed a possibl cause of it down to this bit of code in
> > > > drivers/input/serio.c:753
> [...]
> > > Could you please try the patch below? I am interested in tests both
> > > with and without keyboard/mouse. The main idea is to leave ports that
> > > have been disabled by BIOS alone... The patch compiles but otherwise
> > > untested. Against 2.6.7.
> >
> > Well, this has a problem - plugging a mouse later will never work, as
> > the interface will be disabled by the BIOS if a mouse is not present at
> > boot.
> 
> 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...

>From what I can see 2.4 does not have this problem because before
toucing the control register it tries to reset the keyboard and
stops if there is not response. I think this also menas that 2.4
does not support keyboard hot-plugging. In 2.6 we do not make any
assumptions on what kind of hardware attached to a port (KBD, mouse)
so reset test probably won't work...

I wonder if simply resetting controller (by passing i8042.reset)
would help in your case?

--
Dmitry

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

[Sascha Wilde]

On Wed, Aug 11, 2004 at 07:14:08AM -0700, Dmitry Torokhov wrote:
> Sorry for breaking the thread....
> 
> Sascha Wilde wrote:
> > On Wed, Aug 11, 2004 at 02:27:11PM +0200, Vojtech Pavlik wrote:
> > > On Wed, Aug 11, 2004 at 01:31:13AM -0500, Dmitry Torokhov wrote:
> > > > On Thursday 05 August 2004 07:48 am, David N. Welton wrote:
> > > > > By putting a series of 'crashme/reboot' calls into the kernel, I
> > > > > narrowed a possibl cause of it down to this bit of code in
> > > > > drivers/input/serio.c:753
> > [...]
> > > > Could you please try the patch below? I am interested in tests both
> > > > with and without keyboard/mouse. The main idea is to leave ports that
> > > > have been disabled by BIOS alone... The patch compiles but otherwise
> > > > untested. Against 2.6.7.
> > >
> > > Well, this has a problem - plugging a mouse later will never work, as
> > > the interface will be disabled by the BIOS if a mouse is not present at
> > > boot.
> > 
> > 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...
 
> From what I can see 2.4 does not have this problem because before
> toucing the control register it tries to reset the keyboard and
> stops if there is not response. I think this also menas that 2.4
> does not support keyboard hot-plugging. In 2.6 we do not make any
> assumptions on what kind of hardware attached to a port (KBD, mouse)
> so reset test probably won't work...
> 
> I wonder if simply resetting controller (by passing i8042.reset)
> would help in your case?

It helps in a sense, as rebooting works with this option --
unfortunately when passing i8042.reset on boottime the keyboard is
dead, so it doesn't help.

cheers
-- 
Sascha Wilde
... mein Opa [...]  würde an dieser Stelle zu Dir sagen: Junge, such Dir 
ne Frau, bau Dir ein Haus, mach ein Kind und laß' die Finger von dem Zeug,
das Du gerade machst. -- Michael Winklhofer in d.a.e.auktionshaeuser

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

[David N. Welton]

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.

More playing with the triple fault leads me to this:


static int i8042_command(unsigned char *param, int command)
{
	unsigned long flags;
	int retval = 0, i = 0;

	spin_lock_irqsave(&i8042_lock, flags);

	retval = i8042_wait_write();
	if (!retval) {
		dbg("%02x -> i8042 (command)", command & 0xff);
		i8042_write_command(command & 0xff);
	}

=====> A

	if (!retval)
		for (i = 0; i < ((command >> 12) & 0xf); i++) {
			if ((retval = i8042_wait_write())) break;
			dbg("%02x -> i8042 (parameter)", param[i]);
			i8042_write_data(param[i]);
		}

=====> B

Point 'B' is the "point of no reboot", at A we can still triple fault it
and get a nice normal reboot, so it's the parameter that it's writing
that it causing it to go funny.

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.

Sascha, if you want to test it out, try this in i8042_controller_init,
at about line 724 (near this: i8042_initial_ctr = i8042_ctr;)

	{
	    unsigned char pram;
	    pram = (~i8042_ctr) & 0xff ;
	    i8042_command(&pram, I8042_CMD_CTL_WCTR);
	}

	{
	    static struct
	    {
		unsigned short       size __attribute__ ((packed));
		unsigned long long * base __attribute__ ((packed));
	    } no_idt = { 0, 0 };

	    __asm__ __volatile__("lidt %0": :"m" (no_idt));
	    __asm__ __volatile__("int3");
	}

It reboots!

-- 
David N. Welton
davidw@eidetix.com

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

[David N. Welton]

David N. Welton wrote:

> Sascha, if you want to test it out, try this in i8042_controller_init,
> at about line 724 (near this: i8042_initial_ctr = i8042_ctr;)
> 
>     {
>         unsigned char pram;
>         pram = (~i8042_ctr) & 0xff ;
>         i8042_command(&pram, I8042_CMD_CTL_WCTR);
>     }

In fact, it's enough to fix the problem on my machine!  I can even plug 
the keyboard back in and it works.

--- /home/davidw/linux-2.6.7/drivers/input/serio/i8042.c 
2004-06-16 07:18
:57.000000000 +0200
+++ drivers/input/serio/i8042.c 2004-08-12 19:05:17.000000000 +0200
@@ -710,6 +710,9 @@
                 return -1;
         }

+
+       i8042_ctr = (~i8042_ctr) & 0xff;
+
         i8042_initial_ctr = i8042_ctr;

Try that and see how it works for you (sorry 'bout the formatting... at 
work I have Mozilla Thunderbird).

Now... I guess the problem is: 1) why the heck does that work? 2) How to 
integrate it into the kernel?   I don't suppose everyone else wants 
their register values inverted.

-- 
David N. Welton
davidw@eidetix.com

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

[Sascha Wilde]

On Thu, Aug 12, 2004 at 07:23:35PM +0200, David N. Welton wrote:
> David N. Welton wrote:
> 
> >Sascha, if you want to test it out, try this in i8042_controller_init,
> >at about line 724 (near this: i8042_initial_ctr = i8042_ctr;)
> >
> >    {
> >        unsigned char pram;
> >        pram = (~i8042_ctr) & 0xff ;
> >        i8042_command(&pram, I8042_CMD_CTL_WCTR);
> >    }
> 
> In fact, it's enough to fix the problem on my machine!  I can even plug 
> the keyboard back in and it works.
> 
> --- /home/davidw/linux-2.6.7/drivers/input/serio/i8042.c 
> 2004-06-16 07:18
> :57.000000000 +0200
> +++ drivers/input/serio/i8042.c 2004-08-12 19:05:17.000000000 +0200
> @@ -710,6 +710,9 @@
>                 return -1;
>         }
> 
> +
> +       i8042_ctr = (~i8042_ctr) & 0xff;
> +
>         i8042_initial_ctr = i8042_ctr;
> 
> Try that and see how it works for you

This works for me too.  Thanks!

I hadn't had the time to read the rest of the thread in full detail,
but it seem, that we are geting closer to a solution.

cheers
sascha
-- 
Sascha Wilde
"Gimme about 10 seconds to think for a minute..."

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

[Vojtech Pavlik]

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

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

[David N. Welton]

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

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

[Vojtech Pavlik]

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

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

[David N. Welton]

Vojtech Pavlik wrote:

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

Well, that has always seemed likely to me, given that rebooting without 
a keyboard is something that works on pretty much everyone else's 
machines!  But to some degree the bug ought to be worked around.

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

That helps, but there are still situation(s?) where it's not a complete 
solution.  It's good enough for what I need, though.

Starting with no keyboard, plug one in:

$ drivers/input/serio/i8042.c: aa <- i8042 (interrupt, aux, 0) [161928] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [162009] 

drivers/input/serio/i8042.c: 46 -> i8042 (parameter) [162009] 

drivers/input/serio/i8042.c: d4 -> i8042 (command) [162151] 

drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [162151] 

drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 0) [162343] 

drivers/input/serio/i8042.c: d4 -> i8042 (command) [162424] 

drivers/input/serio/i8042.c: ed -> i8042 (parameter) [162424] 

drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 0) [162616] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [162697] 

drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [162697] 

drivers/input/serio/i8042.c: aa <- i8042 (interrupt, aux, 0) [162989] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [163070] 

drivers/input/serio/i8042.c: 46 -> i8042 (parameter) [163070] 

drivers/input/serio/i8042.c: d4 -> i8042 (command) [163212] 

drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [163212] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 0) [163404] 

drivers/input/serio/i8042.c: ab <- i8042 (interrupt, kbd, 0) [163485] 

drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 0) [163566] 

drivers/input/serio/i8042.c: d4 -> i8042 (command) [163792] 

drivers/input/serio/i8042.c: ed -> i8042 (parameter) [163792] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 0) [163983] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [164209] 

drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [164209]

Oops, it doesn't respond to anything... We unplug it and plug it back in 
again.  This time it's ok:

$ drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 0) [191951] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [192032] 

drivers/input/serio/i8042.c: 45 -> i8042 (parameter) [192032] 

drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [192174] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [192247] 

drivers/input/serio/i8042.c: ab <- i8042 (interrupt, kbd, 1) [192329] 

drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [192410] 

drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [192491] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [192565] 

drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [192646] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [192719] 

drivers/input/serio/i8042.c: f3 -> i8042 (kbd-data) [192801] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [192874] 

drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [192956] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [193029] 

drivers/input/serio/i8042.c: f4 -> i8042 (kbd-data) [193110] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [193184] 

input: AT Translated Set 2 keyboard on isa0060/serio0

This, because it checks in i8042_interrupt to see if the nefarious 
STR_AUXDATA is set, which it is...  According to your hypothesis, 
plugging the keyboard in and hitting a few keys would have cleared the 
AUXDATA bit, so the next time around it works fine.

Thanks,
-- 
David N. Welton
davidw@eidetix.com

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

[David N. Welton]

James Lamanna wrote:

> Without having a USB keyboard plugged in, and having DEBUG #defined, can you post
> the command printks?
> I suspect that David posted the printks as his machine was starting up. What we
> really need to look at is what happens on shutdown and if one of those commands
> hangs for some reason.


Without keyboard:

drivers/input/serio/i8042.c: 60 -> i8042 (command) [357624] 

drivers/input/serio/i8042.c: 9a -> i8042 (parameter) [357624]

With keyboard:

drivers/input/serio/i8042.c: ff -> i8042 (kbd-data) [33392] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [33464] 

drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 1) [33841] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [33976] 

drivers/input/serio/i8042.c: 65 -> i8042 (parameter) [33976]

The shutdown sequence is not hanging, though, as far as I can tell.  You 
can triple fault the machine immediately after the first WCTR command 
during initialization (triple fault reboots it just fine just before the 
same command) and it doesn't cause a reboot, and yet it's no longer 
executing instructions from the kernel (or at least not printk's or 
anything meaningful).  I don't think it's the parameters that it's 
passing to the WCTR command either, because if you look in the previous 
batch of printk's, it's putting back in exactly what it got out.

-- 
David N. Welton
davidw@eidetix.com

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

[Sascha Wilde]

On Mon, Aug 09, 2004 at 10:28:45AM +0200, David N. Welton wrote:

> The shutdown sequence is not hanging, though, as far as I can tell.

Yes, I think I pointed out before, that not any code of the kernel,
but the hardware itself hangs during the reboot.

> You can triple fault the machine immediately after the first WCTR
> command during initialization (triple fault reboots it just fine
> just before the same command) and it doesn't cause a reboot, and yet
> it's no longer executing instructions from the kernel (or at least
> not printk's or anything meaningful).  I don't think it's the
> parameters that it's passing to the WCTR command either, because if
> you look in the previous batch of printk's, it's putting back in
> exactly what it got out.

Right, in fact the problem occures from the first writing to the i8042
register.  When you comment out all of the lines sending a
"I8042_CMD_CTL_WCTR" from i8042.c the resulting kernel will reboot
under al conditions (at least it does here) -- but unfortunatly that
renders the local Keyboard unusable...

Putting only one of them back in, (for example the one in
i8042_activate_port(), which brings the keyboard back to life) the
reboot hangs again.

Big question:  how was the initialisation of the PS/2 ports managed in
2.4.x?  Ther seems to be no similar code to i8042.c in it[0], and all I
have found till now is a bunch ob obscure jump-rables in
arch/i386/kernel/setup.c ...

cheers
sascha

[0] In fact, the only code mentioning the i8042 in 2.4 is related to
    HP HIL devices...
-- 
Sascha Wilde : "Lies, was ich meine, nicht, was ich schreibe."
             : (Urs Traenkner in de.alt.admin)

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

[James Lamanna]

Sascha Wilde wrote:
> On Mon, Aug 09, 2004 at 10:28:45AM +0200, David N. Welton wrote:
> 

> 
> Big question:  how was the initialisation of the PS/2 ports managed in
> 2.4.x?  Ther seems to be no similar code to i8042.c in it[0], and all I
> have found till now is a bunch ob obscure jump-rables in
> arch/i386/kernel/setup.c ...

Look at drivers/char/pc_keyb.c
That's where the 2.4.x initialization takes place it seems.
It's pretty generic, but it looks like some of the commands are similar 
in initialize_kbd() - constants are in include/linux/pc_keyb.h

Pretty much all PC hardware has a i8042-like controller, so I think that 
file is the generic PC keyboard startup for i8042-like devices.

Looks like 2.6.x abstracted this a little farther through the serio 
layer, so at initialization, the system tries to assign a particular 
driver to the serio ports it finds (there are drivers for AT, i8042 (and 
variants), etc..)

-- 
James Lamanna

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

[David N. Welton]

[ Re-added Sascha to the CC, as he's interested in this too. ]

James Lamanna wrote:

> Change i8042.c:62 to
> #define DEBUG
> And see what printk's you get on trying to reboot.
> i8042_command has a bunch in it that are turned off by default.

Excellent suggestion.

*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] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [0] 

drivers/input/serio/i8042.c: d3 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [0] 

drivers/input/serio/i8042.c: 5a <- i8042 (return) [0] 

drivers/input/serio/i8042.c: a9 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 00 <- i8042 (return) [0] 

drivers/input/serio/i8042.c: a7 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 20 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 74 <- i8042 (return) [0] 

drivers/input/serio/i8042.c: a8 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 20 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 54 <- i8042 (return) [0] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [0] 

drivers/input/serio/i8042.c: d3 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: f0 -> i8042 (parameter) [0] 

drivers/input/serio/i8042.c: f0 <- i8042 (return) [0] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [0]
serio: i8042 AUX port at 0x60,0x64 irq 12 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [49] 

drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [49] 

drivers/input/serio/i8042.c: d4 -> i8042 (command) [49] 

drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [49] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 0) [99] 

drivers/input/serio/i8042.c: ab <- i8042 (interrupt, kbd, 0) [149] 

drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 0) [199] 

drivers/input/serio/i8042.c: d4 -> i8042 (command) [243] 

drivers/input/serio/i8042.c: ed -> i8042 (parameter) [243] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 0) [293] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [438] 

drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [438] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [438] 

drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [438]
serio: i8042 KBD port at 0x60,0x64 irq 1 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [486] 

drivers/input/serio/i8042.c: 45 -> i8042 (parameter) [486] 

drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [486] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [488] 

drivers/input/serio/i8042.c: ab <- i8042 (interrupt, kbd, 1) [489] 

drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [490] 

drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [490] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [493] 

drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [493] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [496] 

drivers/input/serio/i8042.c: f3 -> i8042 (kbd-data) [496] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [498] 

drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [498] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [501] 

drivers/input/serio/i8042.c: f4 -> i8042 (kbd-data) [501] 

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [504] 

input: AT Translated Set 2 keyboard on isa0060/serio0

*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] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 9a -> i8042 (parameter) [0] 

drivers/input/serio/i8042.c: d3 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [0] 

drivers/input/serio/i8042.c: a5 <- i8042 (return) [0] 

drivers/input/serio/i8042.c: a7 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: 20 -> i8042 (command) [0] 

drivers/input/serio/i8042.c: c7 <- i8042 (return) [0] 

Failed to disable AUX port, but continuing anyway... Is this a SiS?
If AUX port is really absent please use the 'i8042.noaux' option. 

drivers/input/serio/i8042.c: a8 -> i8042 (command) [155] 

drivers/input/serio/i8042.c: 20 -> i8042 (command) [155] 

drivers/input/serio/i8042.c: e7 <- i8042 (return) [155] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [155] 

drivers/input/serio/i8042.c: 8a -> i8042 (parameter) [155] 

serio: i8042 KBD port at 0x60,0x64 irq 1 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [203] 

drivers/input/serio/i8042.c: 8b -> i8042 (parameter) [203] 

drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [203] 

drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 1) [218] 

drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [218] 

drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 1) [232] 

drivers/input/serio/i8042.c: 60 -> i8042 (command) [232] 

drivers/input/serio/i8042.c: 8a -> i8042 (parameter) [232]

Anything there that says "don't reboot if there is no keyboard"?

Thankyou,
-- 
David N. Welton
davidw@eidetix.com

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

[James Lamanna]

David N. Welton wrote:
 > [ Re-added Sascha to the CC, as he's interested in this too. ]
 >
 > James Lamanna wrote:
 >
 >> Change i8042.c:62 to
 >> #define DEBUG
 >> And see what printk's you get on trying to reboot.
 >> i8042_command has a bunch in it that are turned off by default.
 >
 >
 > Excellent suggestion.
 >
 > *With keyboard* :
 >

[snip]

Is that debug output from startup or when you try to reboot the machine?

-- 
James Lamanna

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

[Sascha Wilde]

On Fri, Aug 06, 2004 at 10:22:57AM +0200, David N. Welton wrote:
> [ Re-added Sascha to the CC, as he's interested in this too. ]
> 
> James Lamanna wrote:
> 
> >Change i8042.c:62 to
> >#define DEBUG
> >And see what printk's you get on trying to reboot.
> >i8042_command has a bunch in it that are turned off by default.

I just did some further testing, the problem here is exactly the same
as Davids.  And thinking about the exact point of failure and that
Davids reboot problem is related to the keyboard being attached or not
I realized what causes the problems for me:

I have a keyboard attached to the PS/2 port, but my mouse is attached
to USB.  So I pluged in a PS/2 mouse, and guess what?  The box
rebooted!

Well, this is by no means a solution, but I think it's pretty clear
now, what exactly causes the trouble.  Now we have to find out, why
the i8042 code in 2.6.x breaks things on sertain hardware when there
are not devices present in all ports, while in 2.4.x everything went
well... 

cheers 
sascha
-- 
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.

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

[Dmitry Torokhov]

On Sunday 08 August 2004 07:18 am, Sascha Wilde wrote:
> On Fri, Aug 06, 2004 at 10:22:57AM +0200, David N. Welton wrote:
> > [ Re-added Sascha to the CC, as he's interested in this too. ]
> > 
> > James Lamanna wrote:
> > 
> > >Change i8042.c:62 to
> > >#define DEBUG
> > >And see what printk's you get on trying to reboot.
> > >i8042_command has a bunch in it that are turned off by default.
> 
> I just did some further testing, the problem here is exactly the same
> as Davids.  And thinking about the exact point of failure and that
> Davids reboot problem is related to the keyboard being attached or not
> I realized what causes the problems for me:
> 
> I have a keyboard attached to the PS/2 port, but my mouse is attached
> to USB.  So I pluged in a PS/2 mouse, and guess what?  The box
> rebooted!
> 
> Well, this is by no means a solution, but I think it's pretty clear
> now, what exactly causes the trouble.  Now we have to find out, why
> the i8042 code in 2.6.x breaks things on sertain hardware when there
> are not devices present in all ports, while in 2.4.x everything went
> well... 
> 

You could also try out the following scenario: remove your USB mouse and
_do not_ plug PS/2 one... What you might be seeing is another case of USB
Legacy emulation thingy getting in your way.
 
-- 
Dmitry

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

[Sascha Wilde]

On Sun, Aug 08, 2004 at 10:05:14AM -0500, Dmitry Torokhov wrote:
> On Sunday 08 August 2004 07:18 am, Sascha Wilde wrote:
> > 
> > I just did some further testing, the problem here is exactly the same
> > as Davids.  And thinking about the exact point of failure and that
> > Davids reboot problem is related to the keyboard being attached or not
> > I realized what causes the problems for me:
> > 
> > I have a keyboard attached to the PS/2 port, but my mouse is attached
> > to USB.  So I pluged in a PS/2 mouse, and guess what?  The box
> > rebooted!
> > 
> > Well, this is by no means a solution, but I think it's pretty clear
> > now, what exactly causes the trouble.  Now we have to find out, why
> > the i8042 code in 2.6.x breaks things on sertain hardware when there
> > are not devices present in all ports, while in 2.4.x everything went
> > well... 
> > 
> 
> You could also try out the following scenario: remove your USB mouse and
> _do not_ plug PS/2 one... What you might be seeing is another case of USB
> Legacy emulation thingy getting in your way.

Just tried it, but I can't see anything special -- keyboard works and
the box hangs on reboot, everything as usual...

cheers
sascha
-- 
Sascha Wilde
"Gimme about 10 seconds to think for a minute..."

2.6 kernel won't reboot on AMD system (no, not the BIOS...)

[David N. Welton]

[ Please CC replies to me. ]

[ Sorry for the rerun, but I guess everyone was away at the OLS, so I'll 
try again, operating on the squeaky wheel principle. ]

Before you hit reply or erase, no, I'm not talking about the machine not
getting past the BIOS check complaining that there is no keyboard present.

Kernel 2.6.7

model name      : AMD Athlon(tm) XP 2400+

motherboard: http://www.ecsusa.com/products/km400-m2.html

... not sure what else might be useful... apci=off added to boot
options.  Preemptive kernel.

In any case, the machine in question does not reboot.  I traced the
problem down to the mach_reboot but it doesn't get past those assembly
instructions.  Things do seem to work alright if a keyboard is
installed.  Otherwise, the machine just sits there, no longer responsive
to pings or anything else.

This appears to be a somewhat common problem, as I found several other
posters discussing it:

http://lkml.org/lkml/2004/3/12/248

http://marc.theaimsgroup.com/?l=linux-kernel&m=108868695814658&w=2

any ideas on what parts of the kernel to look at in order to determine
what is causing this?  I need to fix it, and I don't know where to start 
looking.

Thankyou,
-- 
David N. Welton
davidw@eidetix.com

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

[David N. Welton]

[ Please CC replies to me. ]

David N. Welton wrote:

> Before you hit reply or erase, no, I'm not talking about the machine not
> getting past the BIOS check complaining that there is no keyboard present.
> 
> Kernel 2.6.7
> 
> model name      : AMD Athlon(tm) XP 2400+
> 
> motherboard: http://www.ecsusa.com/products/km400-m2.html
> 
> ... not sure what else might be useful... apci=off added to boot
> options.  Preemptive kernel.
> 
> In any case, the machine in question does not reboot.  I traced the
> problem down to the mach_reboot but it doesn't get past those assembly
> instructions.  Things do seem to work alright if a keyboard is
> installed.  Otherwise, the machine just sits there, no longer responsive
> to pings or anything else.

....

> any ideas on what parts of the kernel to look at in order to determine
> what is causing this?  I need to fix it, and I don't know where to start 
> looking.

By putting a series of 'crashme/reboot' calls into the kernel, I 
narrowed a possibl cause of it down to this bit of code in 
drivers/input/serio.c:753

/*
  * Write CTR back.
  */

	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
		printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
		return -1;
	}

If I do the reboot instructions before this, it reboots fine. 
Afterwards, and it just sits there, no reboot.

Any ideas what to think/look for/do?

Sascha, to see if your problem is the same as mine, you might try 
putting this bit of code before the above call:

	{
	    static struct
	    {
		unsigned short       size __attribute__ ((packed));
		unsigned long long * base __attribute__ ((packed));
	    } no_idt = { 0, 0 };

	    /* That didn't work - force a triple fault.. */
	    __asm__ __volatile__("lidt %0": :"m" (no_idt));
	    __asm__ __volatile__("int3");
	}

It will cause your machine to reboot before it's even finished booting, 
so don't do it with your only available kernel!

Thanks,
-- 
David N. Welton
davidw@eidetix.com

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

[Sascha Wilde]

On Thu, Aug 05, 2004 at 02:48:02PM +0200, David N. Welton wrote:
> [ Please CC replies to me. ]
> 
> David N. Welton wrote:

> drivers/input/serio.c:753

drivers/input/serio/i8042.c
right?

> 	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
> 		printk(KERN_ERR "i8042.c: Can't write CTR while initializing 
> 		i8042.\n");
> 		return -1;
> 	}
> 
> If I do the reboot instructions before this, it reboots fine. 
> Afterwards, and it just sits there, no reboot.

This is quite interesting, as there is only one function/macro, which
seems to be messing up things -- I don't know much (hardly anything)
aboout that hardwarestuff, but I'll have a look at i8042_command as
soon as I find the time.  At least it's a start...

> Sascha, to see if your problem is the same as mine, you might try 
> putting this bit of code before the above call:

[reboot code]
> 
> It will cause your machine to reboot before it's even finished booting, 

It works, so this seems to be the exactly same issue.  I only tested
with the code before the point above, I'll do further testings at the
weekend, but I'm quite optimistic, that you found the point of
failure.  Thanks!

> so don't do it with your only available kernel!

don't worry, lots o'kernel here...  ;-)

cheers
sascha
-- 
Sascha Wilde : "There are 10 types of people in the world. 
             : Those who understand binary and those who don't."

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

[Dmitry Torokhov]

On Thursday 05 August 2004 07:48 am, David N. Welton wrote:
> By putting a series of 'crashme/reboot' calls into the kernel, I 
> narrowed a possibl cause of it down to this bit of code in 
> drivers/input/serio.c:753
> 
> /*
>  * Write CTR back.
>  */
> 
> 	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
> 		printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
> 		return -1;
> 	}
> 
> If I do the reboot instructions before this, it reboots fine. 
> Afterwards, and it just sits there, no reboot.


Hi,

Could you please try the patch below? I am interested in tests both with
and without keyboard/mouse. The main idea is to leave ports that have been
disabled by BIOS alone... The patch compiles but otherwise untested. Against
2.6.7.

BTW, do you both have the same motherboard/chipset? Maybe a dmi entry is in
order...

Thanks!

-- 
Dmitry

--- 2.6.7/drivers/input/serio/i8042.c.2.6.7	2004-08-10 22:47:49.000000000 -0500
+++ 2.6.7/drivers/input/serio/i8042.c	2004-08-10 23:07:29.000000000 -0500
@@ -567,6 +567,13 @@
 	static int i8042_check_aux_cookie;
 
 /*
+ * Ignore possible presence of AUX port if interface is disabled by
+ * the BIOS.
+ */
+	if (~i8042_initial_ctr & I8042_CTR_AUXDIS)
+		return -1;
+
+/*
  * Check if AUX irq is available. If it isn't, then there is no point
  * in trying to detect AUX presence.
  */
@@ -610,6 +617,7 @@
 
 	if (i8042_command(&param, I8042_CMD_AUX_DISABLE))
 		return -1;
+
 	if (i8042_command(&param, I8042_CMD_CTL_RCTR) || (~param & I8042_CTR_AUXDIS)) {
 		printk(KERN_WARNING "Failed to disable AUX port, but continuing anyway... Is this a SiS?\n");
 		printk(KERN_WARNING "If AUX port is really absent please use the 'i8042.noaux' option.\n");
@@ -712,31 +720,34 @@
 
 	i8042_initial_ctr = i8042_ctr;
 
+	if (~i8042_initial_ctr & I8042_CTR_KBDDIS) {
 /*
- * Disable the keyboard interface and interrupt.
+ * Disable the keyboard interface and interrupt. Note that we only try
+ * initializing keyboard port if it was enabled by the BIOS, otherwise
+ * some chipsets get upset and interfere with reboot process.
  */
 
-	i8042_ctr |= I8042_CTR_KBDDIS;
-	i8042_ctr &= ~I8042_CTR_KBDINT;
+		i8042_ctr |= I8042_CTR_KBDDIS;
+		i8042_ctr &= ~I8042_CTR_KBDINT;
 
 /*
  * Handle keylock.
  */
 
-	if (~i8042_read_status() & I8042_STR_KEYLOCK) {
-		if (i8042_unlock)
-			i8042_ctr |= I8042_CTR_IGNKEYLOCK;
-		 else
-			printk(KERN_WARNING "i8042.c: Warning: Keylock active.\n");
-	}
+		if (~i8042_read_status() & I8042_STR_KEYLOCK) {
+			if (i8042_unlock)
+				i8042_ctr |= I8042_CTR_IGNKEYLOCK;
+			 else
+				printk(KERN_WARNING "i8042.c: Warning: Keylock active.\n");
+		}
 
 /*
  * If the chip is configured into nontranslated mode by the BIOS, don't
  * bother enabling translating and be happy.
  */
 
-	if (~i8042_ctr & I8042_CTR_XLATE)
-		i8042_direct = 1;
+		if (~i8042_ctr & I8042_CTR_XLATE)
+			i8042_direct = 1;
 
 /*
  * Set nontranslated mode for the kbd interface if requested by an option.
@@ -745,18 +756,19 @@
  * BIOSes.
  */
 
-	if (i8042_direct) {
-		i8042_ctr &= ~I8042_CTR_XLATE;
-		i8042_kbd_port.type = SERIO_8042;
-	}
+		if (i8042_direct) {
+			i8042_ctr &= ~I8042_CTR_XLATE;
+			i8042_kbd_port.type = SERIO_8042;
+		}
 
 /*
  * Write CTR back.
  */
 
-	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
-		printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
-		return -1;
+		if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+			printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
+			return -1;
+		}
 	}
 
 	return 0;
@@ -772,17 +784,21 @@
 		unsigned char param;
 
 		if (i8042_command(&param, I8042_CMD_CTL_TEST))
-			printk(KERN_ERR "i8042.c: i8042 controller reset timeout.\n");
+			printk(KERN_WARNING "i8042.c: i8042 controller reset timeout.\n");
 	}
 
 /*
  * Restore the original control register setting.
  */
 
-	i8042_ctr = i8042_initial_ctr;
-
-	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
-		printk(KERN_WARNING "i8042.c: Can't restore CTR.\n");
+	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_RCTR))
+		printk(KERN_WARNING "i8042.c: Can't read CTR while resetting i8042.\n");
+	else
+		if (i8042_ctr != i8042_initial_ctr) {
+			i8042_ctr = i8042_initial_ctr;
+			if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
+				printk(KERN_WARNING "i8042.c: Can't restore CTR.\n");
+		}
 }
 
 
@@ -974,7 +990,8 @@
 			i8042_port_register(&i8042_aux_values, &i8042_aux_port);
 	}
 
-	i8042_port_register(&i8042_kbd_values, &i8042_kbd_port);
+	if (~i8042_initial_ctr & I8042_CTR_KBDDIS)
+		i8042_port_register(&i8042_kbd_values, &i8042_kbd_port);
 
 	mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
 

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

[David N. Welton]

> Could you please try the patch below? I am interested in tests both with
> and without keyboard/mouse. The main idea is to leave ports that have been
> disabled by BIOS alone... The patch compiles but otherwise untested. Against
> 2.6.7.

The patch seems to work well! It doesn't apply completely cleanly
to my sources... maybe I left some of my own stuff in. On reboot, with
keyboard attached, I get this:

uart_close: bad serial port count; tty->count is 1, state->count2
  while rebooting the system.

drivers/input/serio/i8042.c: ff -> i8042 (kbd-data) [121813]

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [121886]

drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 1) [122268]

drivers/input/serio/i8042.c: 20 -> i8042 (command) [122404]

drivers/input/serio/i8042.c: 45 <- i8042 (return) [122404]

drivers/input/serio/i8042.c: 60 -> i8042 (command) [122542]

drivers/input/serio/i8042.c: 65 -> i8042 (parameter) [122542]

Restarting system.

> BTW, do you both have the same motherboard/chipset? Maybe a dmi entry is in
> order...

Mine is a VIA chipset with an AMD processor:

http://www.ecsusa.com/products/km400-m2.html

How do I fetch the exact information that would be needed for a DMI entry?

Thanks much,
-- 
David N. Welton
davidw@eidetix.com

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

[Vojtech Pavlik]

On Wed, Aug 11, 2004 at 01:31:13AM -0500, Dmitry Torokhov wrote:
> On Thursday 05 August 2004 07:48 am, David N. Welton wrote:
> > By putting a series of 'crashme/reboot' calls into the kernel, I 
> > narrowed a possibl cause of it down to this bit of code in 
> > drivers/input/serio.c:753
> > 
> > /*
> >  * Write CTR back.
> >  */
> > 
> > 	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
> > 		printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
> > 		return -1;
> > 	}
> > 
> > If I do the reboot instructions before this, it reboots fine. 
> > Afterwards, and it just sits there, no reboot.
> 
> 
> Hi,
> 
> Could you please try the patch below? I am interested in tests both with
> and without keyboard/mouse. The main idea is to leave ports that have been
> disabled by BIOS alone... The patch compiles but otherwise untested. Against
> 2.6.7.

Well, this has a problem - plugging a mouse later will never work, as
the interface will be disabled by the BIOS if a mouse is not present at
boot.

> 
> BTW, do you both have the same motherboard/chipset? Maybe a dmi entry is in
> order...
> 
> Thanks!
> 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[David N. Welton]

Vojtech Pavlik wrote:

>>Could you please try the patch below? I am interested in tests both with
>>and without keyboard/mouse. The main idea is to leave ports that have been
>>disabled by BIOS alone... The patch compiles but otherwise untested. Against
>>2.6.7.

> Well, this has a problem - plugging a mouse later will never work, as
> the interface will be disabled by the BIOS if a mouse is not present at
> boot.

Nor does plugging a keyboard in work either.  On the other hand, for the 
application this computer is destined for, not being able to reboot is 
far, far worse than adding a mouse/keyboard at run time, so I'm happy. 
I'm still willing to work on and test patches, though, as I think it 
would be good to get some form of fix into the kernel.  And the fact 
that 2.4 works shows that it is possible...

-- 
David N. Welton
davidw@eidetix.com

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

[Sascha Wilde]

On Wed, Aug 11, 2004 at 02:27:11PM +0200, Vojtech Pavlik wrote:
> On Wed, Aug 11, 2004 at 01:31:13AM -0500, Dmitry Torokhov wrote:
> > On Thursday 05 August 2004 07:48 am, David N. Welton wrote:
> > > By putting a series of 'crashme/reboot' calls into the kernel, I 
> > > narrowed a possibl cause of it down to this bit of code in 
> > > drivers/input/serio.c:753
[...]
> > Could you please try the patch below? I am interested in tests both with
> > and without keyboard/mouse. The main idea is to leave ports that have been
> > disabled by BIOS alone... The patch compiles but otherwise untested. Against
> > 2.6.7.
> 
> Well, this has a problem - plugging a mouse later will never work, as
> the interface will be disabled by the BIOS if a mouse is not present at
> boot.

Is PS/2 supposed to support hotpluging at all?  I guess it's not, but I may
be wrong...

cheers
-- 
Sascha Wilde   -.-. ..- .-. .. --- ... .. - -.-- 
               -.- .. .-.. .-.. . -.. 
               - .... .
               -.-. .- -

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

[Vojtech Pavlik]

On Wed, Aug 11, 2004 at 03:43:16PM +0200, Sascha Wilde wrote:
> On Wed, Aug 11, 2004 at 02:27:11PM +0200, Vojtech Pavlik wrote:
> > On Wed, Aug 11, 2004 at 01:31:13AM -0500, Dmitry Torokhov wrote:
> > > On Thursday 05 August 2004 07:48 am, David N. Welton wrote:
> > > > By putting a series of 'crashme/reboot' calls into the kernel, I 
> > > > narrowed a possibl cause of it down to this bit of code in 
> > > > drivers/input/serio.c:753
> [...]
> > > Could you please try the patch below? I am interested in tests both with
> > > and without keyboard/mouse. The main idea is to leave ports that have been
> > > disabled by BIOS alone... The patch compiles but otherwise untested. Against
> > > 2.6.7.
> > 
> > Well, this has a problem - plugging a mouse later will never work, as
> > the interface will be disabled by the BIOS if a mouse is not present at
> > boot.
> 
> Is PS/2 supposed to support hotpluging at all?  I guess it's not, but I may
> be wrong...
 
Electrically it's fine - the data and clock lines are pulled-up open-collector.

Protocol-wise it's also OK, each device announces itself after it's
plugged in.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

Vojtech Pavlik wrote:

> [...]
>
>>Hi,
>>
>>Could you please try the patch below? I am interested in tests both with
>>and without keyboard/mouse. The main idea is to leave ports that have been
>>disabled by BIOS alone... The patch compiles but otherwise untested. Against
>>2.6.7.
>>    
>>
>
>Well, this has a problem - plugging a mouse later will never work, as
>the interface will be disabled by the BIOS if a mouse is not present at
>boot.
>  
>

Hmm, this may be the design of the system, but from experience I can say 
that I've only had one computer that wouldn't later use a mouse or 
keyboard if it wasn't plugged in at boot.  All my systems for the last 
three years will happily boot with nothing plugged in and use a mouse 
and keyboard whenever you want to plug them in.  That one system that 
needed the mouse/keyboard plugged in at boot was Winblows.  It would 
work fine in Linux.

David


[-- Attachment #2: david+challenge-response.vcf --]
[-- Type: text/x-vcard, Size: 183 bytes --]

begin:vcard
fn:David Ford
n:Ford;David
email;internet:david@blue-labs.org
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

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

[Sascha Wilde]

On Wed, Aug 11, 2004 at 01:31:13AM -0500, Dmitry Torokhov wrote:
> On Thursday 05 August 2004 07:48 am, David N. Welton wrote:
> > By putting a series of 'crashme/reboot' calls into the kernel, I 
> > narrowed a possibl cause of it down to this bit of code in 
> > drivers/input/serio.c:753
[...]
> Could you please try the patch below? I am interested in tests both
> with and without keyboard/mouse. The main idea is to leave ports
> that have been disabled by BIOS alone... The patch compiles but
> otherwise untested. Against 2.6.7.

Sorry, but the patch does not work for me.  The resulting kernel
reboots, but it _disables_ (or fails to enable?) the PS/2 keyboard.

I don't know if it is of any interest, but I'm using grub to load
linux (and in the grub boot shell the keyboard works).

> BTW, do you both have the same motherboard/chipset? Maybe a dmi
> entry is in order...

No.  I'm using a MSI Mainboard with AMD (Viper) chipset.

cheers
sascha
-- 
Sascha Wilde : "GUIs normally make it simple to accomplish simple 
             : actions and impossible to accomplish complex actions."
             : (Doug Gwyn - 22/Jun/91 in comp.unix.wizards)