Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Sat, 30 Dec 2006 00:25:05 -0500, Dmitry Torokhov wrote: > Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps > command and data into keyboard before i8042_interrupt gets a chance to > run. JFTR, my old Dell Optiplex GX110 with an Intel i810 chipset has the same problem, and your patch fixes it there, too. So it seems that this behaviour is not all that unusual. Thanks Tilman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Sat, 30 Dec 2006 00:25:05 -0500, Dmitry Torokhov wrote: Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps command and data into keyboard before i8042_interrupt gets a chance to run. JFTR, my old Dell Optiplex GX110 with an Intel i810 chipset has the same problem, and your patch fixes it there, too. So it seems that this behaviour is not all that unusual. Thanks Tilman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 30.12.2006 08:20, Rene Herman a écrit : Dmitry Torokhov wrote: Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps command and data into keyboard before i8042_interrupt gets a chance to run. Could you please apply the debug patch below and tell me the pattern of the data flow. Yes, I believe the below trace confirms what you said? Both the ED and the 00/05 are sent before the first ACK gets back, by a 1 jiffie margin: drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [N] drivers/input/serio/i8042.c: 05 -> i8042 (panic blink) [N + 2] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [N + 3] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [N + 6] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [M] drivers/input/serio/i8042.c: 00 -> i8042 (panic blink) [M + 2] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [M + 3] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [M + 6] The +2, +3 and +6 are constant. Forgot to pay attention to M - N, but I suppose it's not too important. For me, the patch as you posted it is actually good to go. No more spurious ACK complaints... Thanks, Rene. Hi Dmitry, Rene I can confirm Rene's report: this patch works fine since there is no more "Spurious ACK on isa0060/serio0" message. Here is a debug output as requested: <0>Kernel panic - not syncing: Fatal exception in interrupt <7>drivers/input/serio/i8042.c: 13 <- i8042 (interrupt, 0, 1) [49602] drivers/input/serio/i8042.c: 93 <- i8042 (interrupt, 0, 1) [49603] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [49728] drivers/input/serio/i8042.c: 05 -> i8042 (panic blink) [49729] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49730] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49732] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [49856] drivers/input/serio/i8042.c: 00 -> i8042 (panic blink) [49857] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49858] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49860] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [49983] drivers/input/serio/i8042.c: 05 -> i8042 (panic blink) [49985] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49986] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49988] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [50112] drivers/input/serio/i8042.c: 00 -> i8042 (panic blink) [50114] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [50115] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [50117] thanks -- laurent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 30.12.2006 08:20, Rene Herman a écrit : Dmitry Torokhov wrote: Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps command and data into keyboard before i8042_interrupt gets a chance to run. Could you please apply the debug patch below and tell me the pattern of the data flow. Yes, I believe the below trace confirms what you said? Both the ED and the 00/05 are sent before the first ACK gets back, by a 1 jiffie margin: drivers/input/serio/i8042.c: ed - i8042 (panic blink) [N] drivers/input/serio/i8042.c: 05 - i8042 (panic blink) [N + 2] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [N + 3] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [N + 6] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [M] drivers/input/serio/i8042.c: 00 - i8042 (panic blink) [M + 2] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [M + 3] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [M + 6] The +2, +3 and +6 are constant. Forgot to pay attention to M - N, but I suppose it's not too important. For me, the patch as you posted it is actually good to go. No more spurious ACK complaints... Thanks, Rene. Hi Dmitry, Rene I can confirm Rene's report: this patch works fine since there is no more Spurious ACK on isa0060/serio0 message. Here is a debug output as requested: 0Kernel panic - not syncing: Fatal exception in interrupt 7drivers/input/serio/i8042.c: 13 - i8042 (interrupt, 0, 1) [49602] drivers/input/serio/i8042.c: 93 - i8042 (interrupt, 0, 1) [49603] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [49728] drivers/input/serio/i8042.c: 05 - i8042 (panic blink) [49729] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49730] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49732] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [49856] drivers/input/serio/i8042.c: 00 - i8042 (panic blink) [49857] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49858] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49860] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [49983] drivers/input/serio/i8042.c: 05 - i8042 (panic blink) [49985] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49986] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49988] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [50112] drivers/input/serio/i8042.c: 00 - i8042 (panic blink) [50114] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [50115] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [50117] thanks -- laurent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote: Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps command and data into keyboard before i8042_interrupt gets a chance to run. Could you please apply the debug patch below and tell me the pattern of the data flow. Yes, I believe the below trace confirms what you said? Both the ED and the 00/05 are sent before the first ACK gets back, by a 1 jiffie margin: drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [N] drivers/input/serio/i8042.c: 05 -> i8042 (panic blink) [N + 2] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [N + 3] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [N + 6] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [M] drivers/input/serio/i8042.c: 00 -> i8042 (panic blink) [M + 2] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [M + 3] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [M + 6] The +2, +3 and +6 are constant. Forgot to pay attention to M - N, but I suppose it's not too important. For me, the patch as you posted it is actually good to go. No more spurious ACK complaints... Thanks, Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Friday 29 December 2006 14:08, Rene Herman wrote:
> Laurent Riffard wrote:
>
> > Le 29.12.2006 06:54, Rene Herman a écrit :
>
> >> Not even an analog camera, but with or without the above, I get a single:
> >>
> >> " <7>drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [ 902]"
>
> ... and when I add "debug" as a kernel param so that I actually get to
> see them (doh) I get the same as Laurent:
>
> >
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172]
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172]
> > atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
> > access hardware directly.
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35296]
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35297]
> > atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
> > access hardware directly.
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35420]
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35421]
> > atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
> > access hardware directly.
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35544]
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35545]
> > atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
> > access hardware directly.
> > ===
>
> I tried just ignoring more ACKs in i8042_interrupt() but that didn't do
> anything other than alternating between 2 and 1 i8042.c printks between
> atkbd.c printks when ignoring an even or oneven number, respectively. I
> guess it's atkbd.c which needs to ack something to keep it from just
> being delivered over and over again or something like it?
>
No, atkbd does not need to ACK anything, it is keyboard controller
ACKs commands set to it. Normally there is only one owner of a serio
port and atkbd rightfully complains when it gets ACks from keyboard
controller when it does not expect it. However during panic we cut
in the middle and start sending kommands to the keybaord without atkbd
knowledge. Keyboard ACKs commands we sent to it and these ACKs reach
atkbd causing it to complain.
Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps
command and data into keyboard before i8042_interrupt gets a chance to
run. Could you please apply the debug patch below and tell me the
pattern of the data flow.
Thank you.
--
Dmitry
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/serio/i8042.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
Index: work/drivers/input/serio/i8042.c
===
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO &&
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ i8042_suppress_kbd_ack--;
goto out;
}
@@ -838,13 +838,14 @@ static long i8042_panic_blink(long count
led ^= 0x01 | 0x04;
while (i8042_read_status() & I8042_STR_IBF)
DELAY;
- i8042_suppress_kbd_ack = 1;
+ dbg("%02x -> i8042 (panic blink)", 0xed);
+ i8042_suppress_kbd_ack = 2;
i8042_write_data(0xed); /* set leds */
DELAY;
while (i8042_read_status() & I8042_STR_IBF)
DELAY;
DELAY;
- i8042_suppress_kbd_ack = 1;
+ dbg("%02x -> i8042 (panic blink)", led);
i8042_write_data(led);
DELAY;
last_blink = count;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Laurent Riffard wrote: Le 29.12.2006 06:54, Rene Herman a écrit : Not even an analog camera, but with or without the above, I get a single: " <7>drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [ 902]" ... and when I add "debug" as a kernel param so that I actually get to see them (doh) I get the same as Laurent: drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35296] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35297] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35420] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35421] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35544] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35545] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. === I tried just ignoring more ACKs in i8042_interrupt() but that didn't do anything other than alternating between 2 and 1 i8042.c printks between atkbd.c printks when ignoring an even or oneven number, respectively. I guess it's atkbd.c which needs to ack something to keep it from just being delivered over and over again or something like it? If I apply the following, things seem to be working for me; no "Spurious ACK" messages anymore (but a steady stream of fa's from i8042). Not a real fix, but I hope it's enough of a clue for someone who understands the infrastructure here. Vojtech added to CC as well. I by the way also tried plugging in a PS/2 mouse (I normally use a USB mouse), adding atkbd_reset=1 to the kernel params and lifting the if (!flags && data == ATKBD_RET_ACK) atkbd->resend = 0; out of the ! __i386__ define. No help. diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c index c621a91..5f88dde 100644 --- a/drivers/input/keyboard/atkbd.c +++ b/drivers/input/keyboard/atkbd.c @@ -372,9 +372,8 @@ #if !defined(__i386__) && !defined (__x8 atkbd->resend = 0; #endif - if (unlikely(atkbd->ps2dev.flags & PS2_FLAG_ACK)) - if (ps2_handle_ack(>ps2dev, data)) - goto out; + if (ps2_handle_ack(>ps2dev, data)) + goto out; if (unlikely(atkbd->ps2dev.flags & PS2_FLAG_CMD)) if (ps2_handle_response(>ps2dev, data)) Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 29.12.2006 06:54, Rene Herman a écrit :
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably
not surprising, but the following gets me blinking leds without the
spurious ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO &&
(data == 0xfa || data == 0xfe)) {
-i8042_suppress_kbd_ack = 0;
+/* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I
wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
Not even an analog camera, but with or without the above, I get a single:
" <7>drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [ 902]"
when it panics. During a full boot, I get:
===
[snip]
===
Rene.
Dmitry,
How about this output? (got this after a kernel panic)
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35296]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35297]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35420]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35421]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35544]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35545]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
===
~~
laurent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 29.12.2006 06:54, Rene Herman a écrit :
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably
not surprising, but the following gets me blinking leds without the
spurious ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO
(data == 0xfa || data == 0xfe)) {
-i8042_suppress_kbd_ack = 0;
+/* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I
wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
Not even an analog camera, but with or without the above, I get a single:
7drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [ 902]
when it panics. During a full boot, I get:
===
[snip]
===
Rene.
Dmitry,
How about this output? (got this after a kernel panic)
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35296]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35297]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35420]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35421]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35544]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35545]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
===
~~
laurent
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Laurent Riffard wrote: Le 29.12.2006 06:54, Rene Herman a écrit : Not even an analog camera, but with or without the above, I get a single: 7drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [ 902] ... and when I add debug as a kernel param so that I actually get to see them (doh) I get the same as Laurent: drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35296] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35297] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35420] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35421] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35544] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35545] atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. === I tried just ignoring more ACKs in i8042_interrupt() but that didn't do anything other than alternating between 2 and 1 i8042.c printks between atkbd.c printks when ignoring an even or oneven number, respectively. I guess it's atkbd.c which needs to ack something to keep it from just being delivered over and over again or something like it? If I apply the following, things seem to be working for me; no Spurious ACK messages anymore (but a steady stream of fa's from i8042). Not a real fix, but I hope it's enough of a clue for someone who understands the infrastructure here. Vojtech added to CC as well. I by the way also tried plugging in a PS/2 mouse (I normally use a USB mouse), adding atkbd_reset=1 to the kernel params and lifting the if (!flags data == ATKBD_RET_ACK) atkbd-resend = 0; out of the ! __i386__ define. No help. diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c index c621a91..5f88dde 100644 --- a/drivers/input/keyboard/atkbd.c +++ b/drivers/input/keyboard/atkbd.c @@ -372,9 +372,8 @@ #if !defined(__i386__) !defined (__x8 atkbd-resend = 0; #endif - if (unlikely(atkbd-ps2dev.flags PS2_FLAG_ACK)) - if (ps2_handle_ack(atkbd-ps2dev, data)) - goto out; + if (ps2_handle_ack(atkbd-ps2dev, data)) + goto out; if (unlikely(atkbd-ps2dev.flags PS2_FLAG_CMD)) if (ps2_handle_response(atkbd-ps2dev, data)) Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Friday 29 December 2006 14:08, Rene Herman wrote:
Laurent Riffard wrote:
Le 29.12.2006 06:54, Rene Herman a écrit :
Not even an analog camera, but with or without the above, I get a single:
7drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [ 902]
... and when I add debug as a kernel param so that I actually get to
see them (doh) I get the same as Laurent:
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
access hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35296]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35297]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
access hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35420]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35421]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
access hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35544]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35545]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
access hardware directly.
===
I tried just ignoring more ACKs in i8042_interrupt() but that didn't do
anything other than alternating between 2 and 1 i8042.c printks between
atkbd.c printks when ignoring an even or oneven number, respectively. I
guess it's atkbd.c which needs to ack something to keep it from just
being delivered over and over again or something like it?
No, atkbd does not need to ACK anything, it is keyboard controller
ACKs commands set to it. Normally there is only one owner of a serio
port and atkbd rightfully complains when it gets ACks from keyboard
controller when it does not expect it. However during panic we cut
in the middle and start sending kommands to the keybaord without atkbd
knowledge. Keyboard ACKs commands we sent to it and these ACKs reach
atkbd causing it to complain.
Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps
command and data into keyboard before i8042_interrupt gets a chance to
run. Could you please apply the debug patch below and tell me the
pattern of the data flow.
Thank you.
--
Dmitry
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/serio/i8042.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
Index: work/drivers/input/serio/i8042.c
===
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ i8042_suppress_kbd_ack--;
goto out;
}
@@ -838,13 +838,14 @@ static long i8042_panic_blink(long count
led ^= 0x01 | 0x04;
while (i8042_read_status() I8042_STR_IBF)
DELAY;
- i8042_suppress_kbd_ack = 1;
+ dbg(%02x - i8042 (panic blink), 0xed);
+ i8042_suppress_kbd_ack = 2;
i8042_write_data(0xed); /* set leds */
DELAY;
while (i8042_read_status() I8042_STR_IBF)
DELAY;
DELAY;
- i8042_suppress_kbd_ack = 1;
+ dbg(%02x - i8042 (panic blink), led);
i8042_write_data(led);
DELAY;
last_blink = count;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote: Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps command and data into keyboard before i8042_interrupt gets a chance to run. Could you please apply the debug patch below and tell me the pattern of the data flow. Yes, I believe the below trace confirms what you said? Both the ED and the 00/05 are sent before the first ACK gets back, by a 1 jiffie margin: drivers/input/serio/i8042.c: ed - i8042 (panic blink) [N] drivers/input/serio/i8042.c: 05 - i8042 (panic blink) [N + 2] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [N + 3] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [N + 6] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [M] drivers/input/serio/i8042.c: 00 - i8042 (panic blink) [M + 2] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [M + 3] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [M + 6] The +2, +3 and +6 are constant. Forgot to pay attention to M - N, but I suppose it's not too important. For me, the patch as you posted it is actually good to go. No more spurious ACK complaints... Thanks, Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO &&
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ /* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
Not even an analog camera, but with or without the above, I get a single:
" <7>drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [ 902]"
when it panics. During a full boot, I get:
===
pnp: the driver 'i8042 kbd' has been registered
pnp: match found with the PnP device '00:06' and the driver 'i8042 kbd'
pnp: the driver 'i8042 aux' has been registered
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
drivers/input/serio/i8042.c: 20 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 65 <- i8042 (return) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: 5a <- i8042 (return) [1]
drivers/input/serio/i8042.c: a7 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 74 <- i8042 (return) [1]
drivers/input/serio/i8042.c: a8 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 54 <- i8042 (return) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [2]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [2]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [2]
drivers/input/serio/i8042.c: a5 -> i8042 (parameter) [2]
drivers/input/serio/i8042.c: a5 <- i8042 (flush, aux) [252]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [252]
drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [252]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [252]
drivers/input/serio/i8042.c: 65 -> i8042 (parameter) [252]
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [252]
input: PC Speaker as /class/input/input4
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [255]
drivers/input/serio/i8042.c: ab <- i8042 (interrupt, 0, 1) [256]
drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, 0, 1) [258]
drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [258]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [261]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [261]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [264]
drivers/input/serio/i8042.c: f3 -> i8042 (kbd-data) [264]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [267]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [267]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [270]
drivers/input/serio/i8042.c: f4 -> i8042 (kbd-data) [270]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [273]
input: AT Translated Set 2 keyboard as /class/input/input5
===
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Friday 29 December 2006 00:17, Rene Herman wrote:
> Dmitry Torokhov wrote:
>
> >>> The change to suppress ACKs from paic blinking is already in Linus's
> >>> tree. I just tried booting with root=/dev/sdg and I had leds blinking
> >>> but no messages from atkbd were seen.
> >>>
> >>> Could it be that you loaded older kernel by accident? Does anybody
> >>> else still seeing "Spurios ACK" messages during kernel panic?
> >> Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do
> >> get atkbd.c complaining at me when I boot with root=/dev/wrong-device.
> >>
> >> Could you point me to the changeset in question? I couldn't find it
> >> searching for "leds" in the log.
> >>
> >
> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11
>
> Yes, I do have that in my tree. From the looks of it it's probably not
> surprising, but the following gets me blinking leds without the spurious
> ACK messages. Maybe still useful to know?
>
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index debe944..9c70d34 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
> if (unlikely(i8042_suppress_kbd_ack))
> if (port_no == I8042_KBD_PORT_NO &&
> (data == 0xfa || data == 0xfe)) {
> - i8042_suppress_kbd_ack = 0;
> + /* i8042_suppress_kbd_ack = 0; */
> goto out;
That would indicate that your keyboard generates multiple acks... I wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote:
The change to suppress ACKs from paic blinking is already in Linus's
tree. I just tried booting with root=/dev/sdg and I had leds blinking
but no messages from atkbd were seen.
Could it be that you loaded older kernel by accident? Does anybody
else still seeing "Spurios ACK" messages during kernel panic?
Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do
get atkbd.c complaining at me when I boot with root=/dev/wrong-device.
Could you point me to the changeset in question? I couldn't find it
searching for "leds" in the log.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO &&
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ /* i8042_suppress_kbd_ack = 0; */
goto out;
}
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Thursday 28 December 2006 23:20, Rene Herman wrote: > Dmitry Torokhov wrote: > > > The change to suppress ACKs from paic blinking is already in Linus's > > tree. I just tried booting with root=/dev/sdg and I had leds blinking > > but no messages from atkbd were seen. > > > > Could it be that you loaded older kernel by accident? Does anybody > > else still seeing "Spurios ACK" messages during kernel panic? > > Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do > get atkbd.c complaining at me when I boot with root=/dev/wrong-device. > > Could you point me to the changeset in question? I couldn't find it > searching for "leds" in the log. > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11 -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote: The change to suppress ACKs from paic blinking is already in Linus's tree. I just tried booting with root=/dev/sdg and I had leds blinking but no messages from atkbd were seen. Could it be that you loaded older kernel by accident? Does anybody else still seeing "Spurios ACK" messages during kernel panic? Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do get atkbd.c complaining at me when I boot with root=/dev/wrong-device. Could you point me to the changeset in question? I couldn't find it searching for "leds" in the log. Rene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Thursday 28 December 2006 16:45, Rene Herman wrote: > Dave Jones wrote: > > > On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: > > >> The bug where the kernel repetitively emits "atkbd.c: Spurious ACK > >> on isa0060/serio0. Some program might be trying access hardware > >> directly" (sic) on a panic, thereby scrolling away the information > >> that would help in seeing what exactly the problem was (ie, "Unable > >> to mount root fs" or something) is still present in 2.6.20-rc2. > > > > Do you have a KVM ? Quite a few of those seem to tickle this printk. > > No, regular old PS/2 keyboard, directly connected. Due to that exact > uneventfullness and having seen it reported before recently (*) I > assumed everyone was seeing this. If not, I guess I can try to narrow it > down. > > It's easy to test for anyone willing: just boot with "root=/dev/null" or > something as a kernel param. The printk's are in sync with the panic > code blinking the leds. > > (*) Here there was supposed to be a link to the post I was refferring > to, but googling for it led to http://lkml.org/lkml/2006/11/13/300 > > Dmitry, could you ask Linus to pull the change? I find this to be an > exceedingly annoying bug. It's just so incredibly silly, having one part > of the kernel helpfully blink leds at you with another part going "hey, > dude! don't do that!" > Hi Rene, The change to suppress ACKs from paic blinking is already in Linus's tree. I just tried booting with root=/dev/sdg and I had leds blinking but no messages from atkbd were seen. Could it be that you loaded older kernel by accident? Does anybody else still seeing "Spurios ACK" messages during kernel panic? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dave Jones wrote: On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: The bug where the kernel repetitively emits "atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly" (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, "Unable to mount root fs" or something) is still present in 2.6.20-rc2. Do you have a KVM ? Quite a few of those seem to tickle this printk. No, regular old PS/2 keyboard, directly connected. Due to that exact uneventfullness and having seen it reported before recently (*) I assumed everyone was seeing this. If not, I guess I can try to narrow it down. It's easy to test for anyone willing: just boot with "root=/dev/null" or something as a kernel param. The printk's are in sync with the panic code blinking the leds. (*) Here there was supposed to be a link to the post I was refferring to, but googling for it led to http://lkml.org/lkml/2006/11/13/300 Dmitry, could you ask Linus to pull the change? I find this to be an exceedingly annoying bug. It's just so incredibly silly, having one part of the kernel helpfully blink leds at you with another part going "hey, dude! don't do that!" Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: > Good day. > > The bug where the kernel repetitively emits "atkbd.c: Spurious ACK on > isa0060/serio0. Some program might be trying access hardware directly" > (sic) on a panic, thereby scrolling away the information that would help > in seeing what exactly the problem was (ie, "Unable to mount root fs" or > something) is still present in 2.6.20-rc2. Do you have a KVM ? Quite a few of those seem to tickle this printk. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Thursday 28 December 2006 16:45, Rene Herman wrote: Dave Jones wrote: On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: The bug where the kernel repetitively emits atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, Unable to mount root fs or something) is still present in 2.6.20-rc2. Do you have a KVM ? Quite a few of those seem to tickle this printk. No, regular old PS/2 keyboard, directly connected. Due to that exact uneventfullness and having seen it reported before recently (*) I assumed everyone was seeing this. If not, I guess I can try to narrow it down. It's easy to test for anyone willing: just boot with root=/dev/null or something as a kernel param. The printk's are in sync with the panic code blinking the leds. (*) Here there was supposed to be a link to the post I was refferring to, but googling for it led to http://lkml.org/lkml/2006/11/13/300 Dmitry, could you ask Linus to pull the change? I find this to be an exceedingly annoying bug. It's just so incredibly silly, having one part of the kernel helpfully blink leds at you with another part going hey, dude! don't do that! Hi Rene, The change to suppress ACKs from paic blinking is already in Linus's tree. I just tried booting with root=/dev/sdg and I had leds blinking but no messages from atkbd were seen. Could it be that you loaded older kernel by accident? Does anybody else still seeing Spurios ACK messages during kernel panic? -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote: The change to suppress ACKs from paic blinking is already in Linus's tree. I just tried booting with root=/dev/sdg and I had leds blinking but no messages from atkbd were seen. Could it be that you loaded older kernel by accident? Does anybody else still seeing Spurios ACK messages during kernel panic? Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do get atkbd.c complaining at me when I boot with root=/dev/wrong-device. Could you point me to the changeset in question? I couldn't find it searching for leds in the log. Rene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Thursday 28 December 2006 23:20, Rene Herman wrote: Dmitry Torokhov wrote: The change to suppress ACKs from paic blinking is already in Linus's tree. I just tried booting with root=/dev/sdg and I had leds blinking but no messages from atkbd were seen. Could it be that you loaded older kernel by accident? Does anybody else still seeing Spurios ACK messages during kernel panic? Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do get atkbd.c complaining at me when I boot with root=/dev/wrong-device. Could you point me to the changeset in question? I couldn't find it searching for leds in the log. http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11 -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote:
The change to suppress ACKs from paic blinking is already in Linus's
tree. I just tried booting with root=/dev/sdg and I had leds blinking
but no messages from atkbd were seen.
Could it be that you loaded older kernel by accident? Does anybody
else still seeing Spurios ACK messages during kernel panic?
Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do
get atkbd.c complaining at me when I boot with root=/dev/wrong-device.
Could you point me to the changeset in question? I couldn't find it
searching for leds in the log.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ /* i8042_suppress_kbd_ack = 0; */
goto out;
}
Rene.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Friday 29 December 2006 00:17, Rene Herman wrote:
Dmitry Torokhov wrote:
The change to suppress ACKs from paic blinking is already in Linus's
tree. I just tried booting with root=/dev/sdg and I had leds blinking
but no messages from atkbd were seen.
Could it be that you loaded older kernel by accident? Does anybody
else still seeing Spurios ACK messages during kernel panic?
Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do
get atkbd.c complaining at me when I boot with root=/dev/wrong-device.
Could you point me to the changeset in question? I couldn't find it
searching for leds in the log.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ /* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
--
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ /* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
Not even an analog camera, but with or without the above, I get a single:
7drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [ 902]
when it panics. During a full boot, I get:
===
pnp: the driver 'i8042 kbd' has been registered
pnp: match found with the PnP device '00:06' and the driver 'i8042 kbd'
pnp: the driver 'i8042 aux' has been registered
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
drivers/input/serio/i8042.c: 20 - i8042 (command) [1]
drivers/input/serio/i8042.c: 65 - i8042 (return) [1]
drivers/input/serio/i8042.c: 60 - i8042 (command) [1]
drivers/input/serio/i8042.c: 74 - i8042 (parameter) [1]
drivers/input/serio/i8042.c: d3 - i8042 (command) [1]
drivers/input/serio/i8042.c: 5a - i8042 (parameter) [1]
drivers/input/serio/i8042.c: 5a - i8042 (return) [1]
drivers/input/serio/i8042.c: a7 - i8042 (command) [1]
drivers/input/serio/i8042.c: 20 - i8042 (command) [1]
drivers/input/serio/i8042.c: 74 - i8042 (return) [1]
drivers/input/serio/i8042.c: a8 - i8042 (command) [1]
drivers/input/serio/i8042.c: 20 - i8042 (command) [1]
drivers/input/serio/i8042.c: 54 - i8042 (return) [1]
drivers/input/serio/i8042.c: 60 - i8042 (command) [2]
drivers/input/serio/i8042.c: 56 - i8042 (parameter) [2]
drivers/input/serio/i8042.c: d3 - i8042 (command) [2]
drivers/input/serio/i8042.c: a5 - i8042 (parameter) [2]
drivers/input/serio/i8042.c: a5 - i8042 (flush, aux) [252]
drivers/input/serio/i8042.c: 60 - i8042 (command) [252]
drivers/input/serio/i8042.c: 74 - i8042 (parameter) [252]
drivers/input/serio/i8042.c: 60 - i8042 (command) [252]
drivers/input/serio/i8042.c: 65 - i8042 (parameter) [252]
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
drivers/input/serio/i8042.c: f2 - i8042 (kbd-data) [252]
input: PC Speaker as /class/input/input4
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [255]
drivers/input/serio/i8042.c: ab - i8042 (interrupt, 0, 1) [256]
drivers/input/serio/i8042.c: 41 - i8042 (interrupt, 0, 1) [258]
drivers/input/serio/i8042.c: ed - i8042 (kbd-data) [258]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [261]
drivers/input/serio/i8042.c: 00 - i8042 (kbd-data) [261]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [264]
drivers/input/serio/i8042.c: f3 - i8042 (kbd-data) [264]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [267]
drivers/input/serio/i8042.c: 00 - i8042 (kbd-data) [267]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [270]
drivers/input/serio/i8042.c: f4 - i8042 (kbd-data) [270]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [273]
input: AT Translated Set 2 keyboard as /class/input/input5
===
Rene.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: Good day. The bug where the kernel repetitively emits atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, Unable to mount root fs or something) is still present in 2.6.20-rc2. Do you have a KVM ? Quite a few of those seem to tickle this printk. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dave Jones wrote: On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: The bug where the kernel repetitively emits atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, Unable to mount root fs or something) is still present in 2.6.20-rc2. Do you have a KVM ? Quite a few of those seem to tickle this printk. No, regular old PS/2 keyboard, directly connected. Due to that exact uneventfullness and having seen it reported before recently (*) I assumed everyone was seeing this. If not, I guess I can try to narrow it down. It's easy to test for anyone willing: just boot with root=/dev/null or something as a kernel param. The printk's are in sync with the panic code blinking the leds. (*) Here there was supposed to be a link to the post I was refferring to, but googling for it led to http://lkml.org/lkml/2006/11/13/300 Dmitry, could you ask Linus to pull the change? I find this to be an exceedingly annoying bug. It's just so incredibly silly, having one part of the kernel helpfully blink leds at you with another part going hey, dude! don't do that! Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Good day. The bug where the kernel repetitively emits "atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly" (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, "Unable to mount root fs" or something) is still present in 2.6.20-rc2. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Good day. The bug where the kernel repetitively emits atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, Unable to mount root fs or something) is still present in 2.6.20-rc2. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
