2.6.6-mm2 : suddent lost of keyboard. Everything else OK.

2.6.6-mm2 : suddent lost of keyboard. Everything else OK.

[Eric Valette]

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

Andrew,

I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
Everything else is working, I can rlogin, shutdown the system. It also
happens in console mode and looks like either keyboard irq or more 
likely its post processing just do not process queued characters.

I have nothing in dmesg nor in syslog. Attached in my .config.

-- 
     __
    /  `                   	Eric Valette
   /--   __  o _.          	6 rue Paul Le Flem
  (___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr





[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 7104 bytes --]

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Eric Valette]

Eric Valette wrote:
> Andrew,
> 
> I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 

Well, I can reproduce it at will : I just need to hit the numlock key 
and keyboard is frozen.

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Andrew Morton]

Eric Valette <eric.valette@free.fr> wrote:
>
> Eric Valette wrote:
> > Andrew,
> > 
> > I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
> 
> Well, I can reproduce it at will : I just need to hit the numlock key 
> and keyboard is frozen.

Could you please do

	patch -p1 -R -i bk-input.patch

and see if it fixes it?

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm2/broken-out/bk-input.patch

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Mathieu Segaud]

Andrew Morton wrote:

>Eric Valette <eric.valette@free.fr> wrote:
>  
>
>>Eric Valette wrote:
>>    
>>
>>>Andrew,
>>>
>>>I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
>>>      
>>>
>>Well, I can reproduce it at will : I just need to hit the numlock key 
>>and keyboard is frozen.
>>    
>>
>
>Could you please do
>
>	patch -p1 -R -i bk-input.patch
>
>and see if it fixes it?
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm2/broken-out/bk-input.patch
>

It worked on my box, currently running 2.6.6-mm2

-- 
Mathieu Segaud

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Luiz Fernando N. Capitulino]

Em Thu, May 13, 2004 at 12:57:50PM -0700, Andrew Morton escreveu:

| Eric Valette <eric.valette@free.fr> wrote:
| >
| > Eric Valette wrote:
| > > Andrew,
| > > 
| > > I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
| > 
| > Well, I can reproduce it at will : I just need to hit the numlock key 
| > and keyboard is frozen.
| 
| Could you please do
| 
| 	patch -p1 -R -i bk-input.patch
| 
| and see if it fixes it?

 Did that and fixed to me.

-- 
Luiz Fernando N. Capitulino
<http://www.telecentros.sp.gov.br>

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Luiz Fernando N. Capitulino]

Em Thu, May 13, 2004 at 04:07:40PM -0500, Fernando Paredes escreveu:

| Does this happen in a Toshiba laptop?

 In my case don't.

-- 
Luiz Fernando N. Capitulino
<http://www.telecentros.sp.gov.br>

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Eric Valette]

Andrew Morton wrote:
> Eric Valette <eric.valette@free.fr> wrote:
> 
>>Eric Valette wrote:
>>
>>>Andrew,
>>>
>>>I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
>>
>>Well, I can reproduce it at will : I just need to hit the numlock key 
>>and keyboard is frozen.
> 
> 
> Could you please do
> 
> 	patch -p1 -R -i bk-input.patch

Yes it fixes it. Thanks for the quick answer and sorry for the delay...

In the thread, other have reported the same problem with the Caps Lock 
key. Both keys have at least three things in common :
	1) They do no echo any character,
	2) They modify the interpretation of the next key pressed (change a 
keyboard status),
	3) They light up a led on the keyboard,

As the input handling logic has changed (if I remember correctly), the 
new logic (locking, signaling)  must be wrong for those keys...

Thanks for the quic way to reverse the faulty patch. Can now peacefully 
wait for the real fixe :-)

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Dmitry Torokhov]

On Thursday 13 May 2004 04:41 pm, Eric Valette wrote:
> Andrew Morton wrote:
> > Eric Valette <eric.valette@free.fr> wrote:
> > 
> >>Eric Valette wrote:
> >>
> >>>Andrew,
> >>>
> >>>I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
> >>
> >>Well, I can reproduce it at will : I just need to hit the numlock key 
> >>and keyboard is frozen.
> > 
> > 
> > Could you please do
> > 
> > 	patch -p1 -R -i bk-input.patch
> 
> Yes it fixes it. Thanks for the quick answer and sorry for the delay...
> 
> In the thread, other have reported the same problem with the Caps Lock 
> key. Both keys have at least three things in common :
> 	1) They do no echo any character,
> 	2) They modify the interpretation of the next key pressed (change a 
> keyboard status),
> 	3) They light up a led on the keyboard,
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^

atkbd tries to switch leds but one tasklet can not interrupt another so
it deadlocks...

You need to revert just the patch below, not entire bk-input

-- 
Dmitry


===================================================================


ChangeSet@1.1587.20.13, 2004-05-10 01:39:35-05:00, dtor_core@ameritech.net
  Input: split i8042 interrupt handling into an IRQ handler and a tasklet


 i8042.c |  141 +++++++++++++++++++++++++++++++++++++++++-----------------------
 1 files changed, 92 insertions(+), 49 deletions(-)


===================================================================



diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c	Tue May 11 00:58:28 2004
+++ b/drivers/input/serio/i8042.c	Tue May 11 00:58:28 2004
@@ -2,6 +2,7 @@
  *  i8042 keyboard and mouse controller driver for Linux
  *
  *  Copyright (c) 1999-2002 Vojtech Pavlik
+ *  Copyright (c) 2004      Dmitry Torokhov
  */
 
 /*
@@ -74,6 +75,14 @@
 	unsigned char *phys;
 };
 
+#define I8042_QUEUE_LEN		64
+struct {
+	unsigned char str[I8042_QUEUE_LEN];
+	unsigned char data[I8042_QUEUE_LEN];
+	unsigned int read_pos;
+	unsigned int write_pos;
+} i8042_buf;
+
 static struct serio i8042_kbd_port;
 static struct serio i8042_aux_port;
 static unsigned char i8042_initial_ctr;
@@ -82,7 +91,7 @@
 static unsigned char i8042_mux_present;
 static unsigned char i8042_sysdev_initialized;
 static struct pm_dev *i8042_pm_dev;
-struct timer_list i8042_timer;
+static struct timer_list i8042_timer;
 
 /*
  * Shared IRQ's require a device pointer, but this driver doesn't support
@@ -374,77 +383,109 @@
 static char i8042_mux_phys[4][32];
 
 /*
- * i8042_interrupt() is the most important function in this driver -
- * it handles the interrupts from the i8042, and sends incoming bytes
- * to the upper layers.
+ * i8042_handle_data() is the most important function in this driver -
+ * it processes data received by i8042_interrupt and sends it to the
+ * upper layers.
  */
 
-static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+static void i8042_handle_data(unsigned long notused)
 {
-	unsigned long flags;
 	unsigned char str, data = 0;
 	unsigned int dfl;
-	int ret;
 
-	mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
+	/*
+	 * No locking it required on i8042_buf as the tasklet is guaranteed
+	 * to be serialized and if write_pos changes while comparing it with
+	 * read_pos another run will be scheduled by i8042_interrupt.
+	 */
+	while (i8042_buf.read_pos != i8042_buf.write_pos) {
 
-	spin_lock_irqsave(&i8042_lock, flags);
-	str = i8042_read_status();
-	if (str & I8042_STR_OBF)
-		data = i8042_read_data();
-	spin_unlock_irqrestore(&i8042_lock, flags);
+		str = i8042_buf.str[i8042_buf.read_pos];
+		data = i8042_buf.data[i8042_buf.read_pos];
 
-	if (~str & I8042_STR_OBF) {
-		if (irq) dbg("Interrupt %d, without any data", irq);
-		ret = 0;
-		goto out;
+		i8042_buf.read_pos++;
+		i8042_buf.read_pos %= I8042_QUEUE_LEN;
+
+		dfl = ((str & I8042_STR_PARITY)  ? SERIO_PARITY  : 0) |
+	      	      ((str & I8042_STR_TIMEOUT) ? SERIO_TIMEOUT : 0);
+
+		if (i8042_mux_values[0].exists && (str & I8042_STR_AUXDATA)) {
+
+			if (str & I8042_STR_MUXERR) {
+				switch (data) {
+					case 0xfd:
+					case 0xfe: dfl = SERIO_TIMEOUT; break;
+					case 0xff: dfl = SERIO_PARITY; break;
+				}
+				data = 0xfe;
+			} else dfl = 0;
+
+			dbg("%02x <- i8042 (interrupt, aux%d, %d%s%s)",
+				data, (str >> 6), irq,
+				dfl & SERIO_PARITY ? ", bad parity" : "",
+				dfl & SERIO_TIMEOUT ? ", timeout" : "");
+
+			serio_interrupt(i8042_mux_port + ((str >> 6) & 3), data, dfl, NULL);
+		} else {
+
+			dbg("%02x <- i8042 (interrupt, %s, %d%s%s)",
+				data, (str & I8042_STR_AUXDATA) ? "aux" : "kbd", irq,
+				dfl & SERIO_PARITY ? ", bad parity" : "",
+				dfl & SERIO_TIMEOUT ? ", timeout" : "");
+
+			if (i8042_aux_values.exists && (str & I8042_STR_AUXDATA))
+				serio_interrupt(&i8042_aux_port, data, dfl, NULL);
+			else if (i8042_kbd_values.exists)
+				serio_interrupt(&i8042_kbd_port, data, dfl, NULL);
+		}
 	}
+}
+
+DECLARE_TASKLET(i8042_tasklet, i8042_handle_data, 0);
+
+/*
+ * i8042_interrupt() handles the interrupts from i8042 and schedules
+ * i8042_handle_data to process and pass received bytes to the upper
+ * layers.
+ */
 
-	dfl = ((str & I8042_STR_PARITY) ? SERIO_PARITY : 0) |
-	      ((str & I8042_STR_TIMEOUT) ? SERIO_TIMEOUT : 0);
+static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	unsigned long flags;
+	unsigned char str;
+	unsigned int n_bytes = 0;
 
-	if (i8042_mux_values[0].exists && (str & I8042_STR_AUXDATA)) {
+	mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
 
-		if (str & I8042_STR_MUXERR) {
-			switch (data) {
-				case 0xfd:
-				case 0xfe: dfl = SERIO_TIMEOUT; break;
-				case 0xff: dfl = SERIO_PARITY; break;
-			}
-			data = 0xfe;
-		} else dfl = 0;
+	spin_lock_irqsave(&i8042_lock, flags);
 
-		dbg("%02x <- i8042 (interrupt, aux%d, %d%s%s)",
-			data, (str >> 6), irq,
-			dfl & SERIO_PARITY ? ", bad parity" : "",
-			dfl & SERIO_TIMEOUT ? ", timeout" : "");
+	while ((str = i8042_read_status()) & I8042_STR_OBF) {
 
-		serio_interrupt(i8042_mux_port + ((str >> 6) & 3), data, dfl, regs);
+		n_bytes++;
 
-		goto irq_ret;
-	}
+		i8042_buf.str[i8042_buf.write_pos] = str;
+		i8042_buf.data[i8042_buf.write_pos] = i8042_read_data();
 
-	dbg("%02x <- i8042 (interrupt, %s, %d%s%s)",
-		data, (str & I8042_STR_AUXDATA) ? "aux" : "kbd", irq,
-		dfl & SERIO_PARITY ? ", bad parity" : "",
-		dfl & SERIO_TIMEOUT ? ", timeout" : "");
+		i8042_buf.write_pos++;
+		i8042_buf.write_pos %= I8042_QUEUE_LEN;
 
-	if (i8042_aux_values.exists && (str & I8042_STR_AUXDATA)) {
-		serio_interrupt(&i8042_aux_port, data, dfl, regs);
-		goto irq_ret;
+		if (unlikely(i8042_buf.write_pos == i8042_buf.read_pos))
+			printk(KERN_WARNING "i8042.c: ring buffer full\n");
 	}
 
-	if (!i8042_kbd_values.exists)
-		goto irq_ret;
+	spin_unlock_irqrestore(&i8042_lock, flags);
 
-	serio_interrupt(&i8042_kbd_port, data, dfl, regs);
+	if (unlikely(n_bytes == 0)) {
+		if (irq) dbg("Interrupt %d, without any data", irq);
+		return IRQ_NONE;
+	}
 
-irq_ret:
-	ret = 1;
-out:
-	return IRQ_RETVAL(ret);
+	tasklet_schedule(&i8042_tasklet);
+
+	return IRQ_HANDLED;
 }
 
+
 /*
  * i8042_enable_mux_mode checks whether the controller has an active
  * multiplexor and puts the chip into Multiplexed (as opposed to
@@ -1019,6 +1060,8 @@
 	for (i = 0; i < 4; i++)
 		if (i8042_mux_values[i].exists)
 			serio_unregister_port(i8042_mux_port + i);
+
+	tasklet_kill(&i8042_tasklet);
 
 	i8042_platform_exit();
 }

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Dmitry Torokhov]

On Thursday 13 May 2004 05:45 pm, Dmitry Torokhov wrote:
> On Thursday 13 May 2004 04:41 pm, Eric Valette wrote:
> > Andrew Morton wrote:
> > > Eric Valette <eric.valette@free.fr> wrote:
> > > 
> > >>Eric Valette wrote:
> > >>
> > >>>Andrew,
> > >>>
> > >>>I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
> > >>
> > >>Well, I can reproduce it at will : I just need to hit the numlock key 
> > >>and keyboard is frozen.
> > > 
> > > 
> > > Could you please do
> > > 
> > > 	patch -p1 -R -i bk-input.patch
> > 
> > Yes it fixes it. Thanks for the quick answer and sorry for the delay...
> > 
> > In the thread, other have reported the same problem with the Caps Lock 
> > key. Both keys have at least three things in common :
> > 	1) They do no echo any character,
> > 	2) They modify the interpretation of the next key pressed (change a 
> > keyboard status),
> > 	3) They light up a led on the keyboard,
> 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> atkbd tries to switch leds but one tasklet can not interrupt another so
> it deadlocks...
> 
> You need to revert just the patch below, not entire bk-input
> 

Guys,

I need some guidance. The issue can be resolved in several ways but I am not
sure which one is better:

- just revert the patch and continue doing everything in IRQ context;
- move IRQ/tasklet split higher, into atkbd and psmouse-base respectively.
  Every device would have it's own ring buffer, tasklet will be fired off
  for incoming data only (i.e. ACKs and command response will be processed
  right there in IRQ context);
- move drivers/char/keyboard.c from tasklet to schedule_work. Need also
  take care of others who are using keyboard_tasklet (qtronix, scan_keyb,
  ec3104_keyb);
- have atkbd use schedule_work to do LED and repeat rate setting.

What would you suggest?

-- 
Dmitry

Re: 2.6.6-mm2 : Hitting Num Lock kills keyboard

[Vojtech Pavlik]

On Fri, May 14, 2004 at 12:32:52AM -0500, Dmitry Torokhov wrote:

> > > 	3) They light up a led on the keyboard,
> > 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > atkbd tries to switch leds but one tasklet can not interrupt another so
> > it deadlocks...
> > 
> > You need to revert just the patch below, not entire bk-input
> 
> Guys,
> 
> I need some guidance. The issue can be resolved in several ways but I am not
> sure which one is better:
> 
> - just revert the patch and continue doing everything in IRQ context;
> - move IRQ/tasklet split higher, into atkbd and psmouse-base respectively.
>   Every device would have it's own ring buffer, tasklet will be fired off
>   for incoming data only (i.e. ACKs and command response will be processed
>   right there in IRQ context);
> - move drivers/char/keyboard.c from tasklet to schedule_work. Need also
>   take care of others who are using keyboard_tasklet (qtronix, scan_keyb,
>   ec3104_keyb);
> - have atkbd use schedule_work to do LED and repeat rate setting.
> 
> What would you suggest?
 
Now that I'm considering it all, I think serio->interrupt function
should indeed be called within an interrupt context. The name should be
a big enough warning not to do too much processing (and definitely no
communication with the device other than doing something with the
received byte) there.

The input core and the handlers were intended to be lightweight enough
so that they could be executed from an interrupt handler as well.

Are we really spending too much time in the interrupt there? It's well
possible, but it'd be good if it could be evaluated. It should be rather
easy to add a rdtsc before an after the invocation of serio->interrupt
from i8042.c.

That should give us the answer about what to do - which parts of the
input processing can stay in the interrupt (because that is simple), and
what needs to be postponed to a tasklet or schedule_work().

Each of your options seems reasonable. I think moving keyboard.c to
schedule_work is a definitely good idea, but we may want to do more than
that.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

USB optical mouse is also jumpy

[Eric Valette]

Dmitry,

I've reverse applyied the patch on my laptop and desktop and the 
keyboard is fine. However, my USB optical mouse is also hardly 
manageable. I've seen other post on the synaptic touchpad beeing jumppy 
but for me it is an USB optical mouse (It's branded Asus but I think it 
is a logitech optical well mouse...)

FYI...

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.6.6-mm2 : suddent lost of keyboard. Everything else OK.

[Ramón Rey Vicente]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 952 bytes --]

El jue, 13 de may de 2004, a las 09:15:29 +0200, Eric Valette dijo:

> I tested 2.6.6-mm2 this afternoon and twice I totally lost my keyboard. 
> Everything else is working, I can rlogin, shutdown the system. It also
> happens in console mode and looks like either keyboard irq or more 
> likely its post processing just do not process queued characters.

In my system this is happening when I press the "caps lock" key.

> I have nothing in dmesg nor in syslog. Attached in my .config.

The same here.

-- 
Ramón Rey Vicente       <ramon dot rey at hispalinux dot es>        
jabber ID               <rreylinux at jabber dot org>
GPG public key ID       0xBEBD71D5 -> http://pgp.escomposlinux.org/
===================================================================
Ranty, te echaré de menos. - Ranty, I'll miss you.
http://roncero.org/blog/varios/erconde-ranty
===================================================================

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.6-mm2 : suddent lost of keyboard. Everything else OK.

[Luiz Fernando N. Capitulino]

Em Thu, May 13, 2004 at 04:52:50PM -0300, Ramón Rey Vicente escreveu:

| El jue, 13 de may de 2004, a las 09:15:29 +0200, Eric Valette dijo:
| 
| > I tested 2.6.6-mm2 this afternoon and twice I totally lost my
| keyboard. 
| > Everything else is working, I can rlogin, shutdown the system. It also
| > happens in console mode and looks like either keyboard irq or more 
| > likely its post processing just do not process queued characters.
| 
| In my system this is happening when I press the "caps lock" key.

 I think you found the problem, here it locks when I press "caps
lock" too.

-- 
Luiz Fernando N. Capitulino
<http://www.telecentros.sp.gov.br>