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.
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
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.
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
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
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
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.
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
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.
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
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(&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.
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;
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.
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
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