2.6 kernel won't reboot on AMD system (no, not the BIOS...)
David N. Welton
[ 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
dav...@eidetix.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David N. Welton
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,
Sascha Wilde
> [ 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."
David N. Welton
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
dav...@eidetix.com
James Lamanna
> [ 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
Sascha Wilde
> [ 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
--
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.
Dmitry Torokhov
> 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
David N. Welton
> 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
dav...@eidetix.com
-
Sascha Wilde
> 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)
James Lamanna
> 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
Dmitry Torokhov
> 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(¶m, I8042_CMD_AUX_DISABLE))
return -1;
+
if (i8042_command(¶m, 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(¶m, 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);
David N. Welton
> 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
dav...@eidetix.com
-
Vojtech Pavlik
> 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
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.
> 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
dav...@eidetix.com
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.
>
> 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 -.-. ..- .-. .. --- ... .. - -.--
-.- .. .-.. .-.. . -..
- .... .
-.-. .- -
David Ford
> [...]
>
>>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
Dmitry Torokhov
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
Vojtech Pavlik
> 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...
Protocol-wise it's also OK, each device announces itself after it's
plugged in.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Sascha Wilde
> 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
Sascha Wilde
> 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..."
Sascha Wilde
> > 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)
David N. Welton
>>> 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
dav...@eidetix.com
David N. Welton
> 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.
Vojtech Pavlik
> 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
David N. Welton
> 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
dav...@eidetix.com
Vojtech Pavlik
> 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
David N. Welton
> 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
dav...@eidetix.com
Sascha Wilde
> 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..."
-