Hi!
I started getting blinking capslock leds in 2.6.22-somewhere. Every 5
seconds or so, capslock led toggles on thinkpad x60. Ouch.
I also get some stuck keys I was not getting before. I hope my
userland did not go crazy...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
06/04/2007 01:24 PM, Pavel Machek wrote/a écrit:
> Hi!
>
> I started getting blinking capslock leds in 2.6.22-somewhere. Every 5
> seconds or so, capslock led toggles on thinkpad x60. Ouch.
>
Could it be related to commit f038f9a361a764ed013447174b7170073f89cbe9
aka "Add keyboard blink driver" ? Probably you don't want it in hard in
the kernel ;-)
See you,
Eric
On Mon, June 4, 2007 13:24, Pavel Machek wrote:
> I also get some stuck keys I was not getting before. I hope my
> userland did not go crazy...
I get that too, and wasn't sure about it either. It happens irregularly,
so it's hard to debug, but often enough to be annoying.
My mouse pointer tends to warp too in the same irregular way,
no idea if that's related (it seemed to happen in an earlier kernel
version than the sticky key thing, but not sure, as I don't have this
mouse that long.)
Greetings,
Indan
On Mon, 4 Jun 2007, Pavel Machek wrote:
> I started getting blinking capslock leds in 2.6.22-somewhere. Every 5
> seconds or so, capslock led toggles on thinkpad x60. Ouch. I also get
> some stuck keys I was not getting before. I hope my userland did not go
> crazy...
Hi Pavel,
what does
grep BLINK .config
show?
--
Jiri Kosina
On Mon, 4 Jun 2007, Indan Zupancic wrote:
> > I also get some stuck keys I was not getting before. I hope my
> > userland did not go crazy...
> I get that too, and wasn't sure about it either. It happens irregularly,
> so it's hard to debug, but often enough to be annoying.
What kind of keyboards are they? I guess the x60 case is serio/ps2, what
keyboard do you experience this with, Indan?
--
Jiri Kosina
On Mon 2007-06-04 14:35:23, Jiri Kosina wrote:
> On Mon, 4 Jun 2007, Pavel Machek wrote:
>
> > I started getting blinking capslock leds in 2.6.22-somewhere. Every 5
> > seconds or so, capslock led toggles on thinkpad x60. Ouch. I also get
> > some stuck keys I was not getting before. I hope my userland did not go
> > crazy...
>
> Hi Pavel,
>
> what does
>
> grep BLINK .config
> show.
CONFIG_BLINK=y
OOps. WTF is that?
config BLINK
tristate "Keyboard blink driver"
help
Driver that when loaded will blink the keyboard LEDs
continuously.
This is useful for debugging and for kernels that cannot
necessarily
output something to the screen like kexec kernels to give
the user
a visual indication that the kernel is doing something.
..does it need "default n"? Why does it make keys stuck sometimes?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 4 Jun 2007, Pavel Machek wrote:
> CONFIG_BLINK=y
> OOps. WTF is that?
>
> config BLINK
> tristate "Keyboard blink driver"
> help
> Driver that when loaded will blink the keyboard LEDs
> continuously.
> This is useful for debugging and for kernels that cannot
> necessarily
> output something to the screen like kexec kernels to give
> the user
> a visual indication that the kernel is doing something.
> ..does it need "default n"? Why does it make keys stuck sometimes?
Are you sure that it's this dummy blink driver that makes the kernel
stuck? I can't see how it could be causing any hogs - see commit f038f9.
Anyway, added Andi to CC.
--
Jiri Kosina
Hi!
> > CONFIG_BLINK=y
> > OOps. WTF is that?
> >
> > config BLINK
> > tristate "Keyboard blink driver"
> > help
> > Driver that when loaded will blink the keyboard LEDs
> > continuously.
> > This is useful for debugging and for kernels that cannot
> > necessarily
> > output something to the screen like kexec kernels to give
> > the user
> > a visual indication that the kernel is doing something.
> > ..does it need "default n"? Why does it make keys stuck sometimes?
>
> Are you sure that it's this dummy blink driver that makes the kernel
> stuck? I can't see how it could be causing any hogs - see commit f038f9.
>
> Anyway, added Andi to CC.
I'm not sure, and stuck keys are quite hard to reproduce. It only
happened twice in two days. But I've never seen stuck key on this
thinkpad x60 before, so...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 4 Jun 2007, Pavel Machek wrote:
> I'm not sure, and stuck keys are quite hard to reproduce. It only
> happened twice in two days. But I've never seen stuck key on this
> thinkpad x60 before, so...
Dmitry should be on CC here, re-added.
--
Jiri Kosina
On Monday 04 June 2007 15:12, Jiri Kosina wrote:
> Are you sure that it's this dummy blink driver that makes the kernel
> stuck? I can't see how it could be causing any hogs - see commit f038f9.
>
> Anyway, added Andi to CC.
Hmm, in theory it could be triggering bugs in some buggy keyboard
controller. But then a
while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps -numlock ;
sleep 1 ; done
should trigger it too.
Anyways; it is normally only intended for special
case kdump or other debugging kernels which tend to not get
much interaction; you shouldn't really set it anywhere else.
I've been also considering to make it always dependent on
a command line option, but that is not done yet.
-Andi
Hi!
> > Are you sure that it's this dummy blink driver that makes the kernel
> > stuck? I can't see how it could be causing any hogs - see commit f038f9.
> >
> > Anyway, added Andi to CC.
>
> Hmm, in theory it could be triggering bugs in some buggy keyboard
> controller. But then a
>
> while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps -numlock ;
> sleep 1 ; done
>
> should trigger it too.
...and it does.
pavel@amd:~$ while true; do setleds +num; setleds -num; done
Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
pavel@amd:~$
...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
often. Launch the line above and try to do some typing...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 6/4/07, Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > Are you sure that it's this dummy blink driver that makes the kernel
> > > stuck? I can't see how it could be causing any hogs - see commit f038f9.
> > >
> > > Anyway, added Andi to CC.
> >
> > Hmm, in theory it could be triggering bugs in some buggy keyboard
> > controller. But then a
> >
> > while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps -numlock ;
> > sleep 1 ; done
> >
> > should trigger it too.
>
> ...and it does.
>
> pavel@amd:~$ while true; do setleds +num; setleds -num; done
> Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
>
> pavel@amd:~$
>
> ...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> often. Launch the line above and try to do some typing...
This used to work fine on my box last time I tried it (the switch
itself is offloaded to a keventd and shoud not get in the way) but
then they push all kind of ACPI/SMM crap together with KBC so who
knows... I should try it again when I get home.
--
Dmitry
Hi!
> >> > Anyway, added Andi to CC.
> >>
> >> Hmm, in theory it could be triggering bugs in some buggy keyboard
> >> controller. But then a
> >>
> >> while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps
> >-numlock ;
> >> sleep 1 ; done
> >>
> >> should trigger it too.
> >
> >...and it does.
> >
> >pavel@amd:~$ while true; do setleds +num; setleds -num; done
> >Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
> >
> >pavel@amd:~$
> >
> >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> >often. Launch the line above and try to do some typing...
>
> This used to work fine on my box last time I tried it (the switch
> itself is offloaded to a keventd and shoud not get in the way) but
> then they push all kind of ACPI/SMM crap together with KBC so who
> knows... I should try it again when I get home.
Hmm, this needs to be ran from console (not X). Can someone with
thinkpad try this?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, June 4, 2007 14:38, Jiri Kosina wrote:
> On Mon, 4 Jun 2007, Indan Zupancic wrote:
>
>> > I also get some stuck keys I was not getting before. I hope my
>> > userland did not go crazy...
>> I get that too, and wasn't sure about it either. It happens irregularly,
>> so it's hard to debug, but often enough to be annoying.
>
> What kind of keyboards are they? I guess the x60 case is serio/ps2, what
> keyboard do you experience this with, Indan?
Also serio/ps2:
input: AT Translated Set 2 keyboard as /class/input/input0
On 2007.06.04 16:13:45 +0200, Pavel Machek wrote:
> Hi!
>
> > >> > Anyway, added Andi to CC.
> > >>
> > >> Hmm, in theory it could be triggering bugs in some buggy keyboard
> > >> controller. But then a
> > >>
> > >> while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps
> > >-numlock ;
> > >> sleep 1 ; done
> > >>
> > >> should trigger it too.
> > >
> > >...and it does.
> > >
> > >pavel@amd:~$ while true; do setleds +num; setleds -num; done
> > >Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
> > >
> > >pavel@amd:~$
> > >
> > >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> > >often. Launch the line above and try to do some typing...
> >
> > This used to work fine on my box last time I tried it (the switch
> > itself is offloaded to a keventd and shoud not get in the way) but
> > then they push all kind of ACPI/SMM crap together with KBC so who
> > knows... I should try it again when I get home.
>
> Hmm, this needs to be ran from console (not X). Can someone with
> thinkpad try this?
The version that doesn't sleep totally messes up keyboard input on my
T43. Some keypresses are totally ignored and the keys that are part of
the "numpad" sometimes generate crap, e.g. holding down "j"
results in j, 1 or ^[[4~
Bj?rn
On Mon, June 4, 2007 15:12, Jiri Kosina wrote:
> Are you sure that it's this dummy blink driver that makes the kernel
> stuck? I can't see how it could be causing any hogs - see commit f038f9.
To make it clear, I'm not using the blink driver and get the stuck
key problem too. (And also a warpy PS/2 mouse.)
Wildly guessing: As the problem doesn't seem to be widespread,
perhaps it's suspend to ram related. I'll try running a while without
suspending and see if it crops up too then.
Greetings,
Indan
Hi!
> > > >pavel@amd:~$ while true; do setleds +num; setleds -num; done
> > > >Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
> > > >
> > > >pavel@amd:~$
> > > >
> > > >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> > > >often. Launch the line above and try to do some typing...
> > >
> > > This used to work fine on my box last time I tried it (the switch
> > > itself is offloaded to a keventd and shoud not get in the way) but
> > > then they push all kind of ACPI/SMM crap together with KBC so who
> > > knows... I should try it again when I get home.
> >
> > Hmm, this needs to be ran from console (not X). Can someone with
> > thinkpad try this?
>
> The version that doesn't sleep totally messes up keyboard input on my
> T43. Some keypresses are totally ignored and the keys that are part of
> the "numpad" sometimes generate crap, e.g. holding down "j"
> results in j, 1 or ^[[4~
Ok, I did not want to focus on "numpad" keys. Even normal keys
misbehave for me, like being lost or duplicated. Strange.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Jun 04, 2007, Pavel Machek wrote:
>
> > >> Hmm, in theory it could be triggering bugs in some buggy keyboard
> > >> controller. But then a
> > >>
> > >> while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps -numlock ; sleep 1 ; done
> > >>
> > >> should trigger it too.
> > >
> > >...and it does.
> > >
> > >pavel@amd:~$ while true; do setleds +num; setleds -num; done
> > >Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
> > >
> > >pavel@amd:~$
> > >
> > >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> > >often. Launch the line above and try to do some typing...
> >
> > This used to work fine on my box last time I tried it (the switch
> > itself is offloaded to a keventd and shoud not get in the way) but
> > then they push all kind of ACPI/SMM crap together with KBC so who
> > knows... I should try it again when I get home.
>
> Hmm, this needs to be ran from console (not X). Can someone with
> thinkpad try this?
I see the same thing with a 2.6.21 kernel on a T42p.
HTH,
Johannes
Hi!
> > Are you sure that it's this dummy blink driver that makes the kernel
> > stuck? I can't see how it could be causing any hogs - see commit f038f9.
>
> To make it clear, I'm not using the blink driver and get the stuck
> key problem too. (And also a warpy PS/2 mouse.)
>
> Wildly guessing: As the problem doesn't seem to be widespread,
> perhaps it's suspend to ram related. I'll try running a while without
> suspending and see if it crops up too then.
It is not suspend related -- at least on my machine anyway.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 6/4/07, Pavel Machek <[email protected]> wrote:
>
> Hmm, this needs to be ran from console (not X). Can someone with
> thinkpad try this?
Are you saying it works OK when run in X?
--
Dmitry
On 2007.06.04 17:10:25 +0200, Pavel Machek wrote:
> Hi!
>
> > > > >pavel@amd:~$ while true; do setleds +num; setleds -num; done
> > > > >Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
> > > > >
> > > > >pavel@amd:~$
> > > > >
> > > > >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> > > > >often. Launch the line above and try to do some typing...
> > > >
> > > > This used to work fine on my box last time I tried it (the switch
> > > > itself is offloaded to a keventd and shoud not get in the way) but
> > > > then they push all kind of ACPI/SMM crap together with KBC so who
> > > > knows... I should try it again when I get home.
> > >
> > > Hmm, this needs to be ran from console (not X). Can someone with
> > > thinkpad try this?
> >
> > The version that doesn't sleep totally messes up keyboard input on my
> > T43. Some keypresses are totally ignored and the keys that are part of
> > the "numpad" sometimes generate crap, e.g. holding down "j"
> > results in j, 1 or ^[[4~
>
> Ok, I did not want to focus on "numpad" keys. Even normal keys
> misbehave for me, like being lost or duplicated. Strange.
That also happens here. The numpad keys were a special case, sorry if I
didn't make that clear enough.
Bj?rn
On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
> >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> >often. Launch the line above and try to do some typing...
>
> This used to work fine on my box last time I tried it (the switch
> itself is offloaded to a keventd and shoud not get in the way) but
> then they push all kind of ACPI/SMM crap together with KBC so who
> knows... I should try it again when I get home.
Err... in laptops, almost *always* the KDC is emulated by the embedded
controller, so I bet you're right on the money, there. It is not "a buggy
KDC", it is a buggy EC firmware and/or buggy SMBIOS which is a lot more
common.
And DoS'ing the EC is very high on the Don't Do That list on a laptop. If
the X60 is only losing keypresses and producing no bigger fireworks, that's
outstanding behavior (as far as I trust ThinkPad firmware, anyway).
So please throttle anything that might access the KDC way too much (as
compared to normal keyboard operation by an user).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Pavel Machek wrote:
[]
>>> pavel@amd:~$ while true; do setleds +num; setleds -num; done
>>> Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
>>>
>>> ...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
>>> often. Launch the line above and try to do some typing...
>> This used to work fine on my box last time I tried it (the switch
>> itself is offloaded to a keventd and shoud not get in the way) but
>> then they push all kind of ACPI/SMM crap together with KBC so who
>> knows... I should try it again when I get home.
>
> Hmm, this needs to be ran from console (not X). Can someone with
> thinkpad try this?
I don't have a thinkpad, but I tried it - just for fun - with my desktop
PC here. And it also shows some.. strangeness. Namely, after several
secounds, it starts spewing:
drivers/usb/input/hid-core.c: control queue full
drivers/usb/input/hid-core.c: control queue full
drivers/usb/input/hid-core.c: control queue full
messages on the screen on every setleds (above) invocation. Even if I
stop the loop and execute single setleds manually, it also shows this
same message. And the led isn't working anymore too - even if I press
NumLock key, NumLock mode activates/deactivates correctly, but not the
led -- ditto for other leds (CapsLock & ScrollLock). And it doesn't
restore when I switch to X and back.
(My keyboard is USB-connected).
I think it's something about count of setleds/etc operations. Rebooting
and counting from 0...
(2.6.21.3 here)
/mjt
On 6/4/07, Henrique de Moraes Holschuh <[email protected]> wrote:
> On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
> > >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> > >often. Launch the line above and try to do some typing...
> >
> > This used to work fine on my box last time I tried it (the switch
> > itself is offloaded to a keventd and shoud not get in the way) but
> > then they push all kind of ACPI/SMM crap together with KBC so who
> > knows... I should try it again when I get home.
>
> Err... in laptops, almost *always* the KDC is emulated by the embedded
> controller, so I bet you're right on the money, there. It is not "a buggy
> KDC", it is a buggy EC firmware and/or buggy SMBIOS which is a lot more
> common.
>
> And DoS'ing the EC is very high on the Don't Do That list on a laptop. If
> the X60 is only losing keypresses and producing no bigger fireworks, that's
> outstanding behavior (as far as I trust ThinkPad firmware, anyway).
>
> So please throttle anything that might access the KDC way too much (as
> compared to normal keyboard operation by an user).
What would be reasonable throttling? Once every 100 ms?
--
Dmitry
On Monday 04 June 2007 18:34, Henrique de Moraes Holschuh wrote:
> And DoS'ing the EC is very high on the Don't Do That list on a laptop. If
> the X60 is only losing keypresses and producing no bigger fireworks, that's
> outstanding behavior (as far as I trust ThinkPad firmware, anyway).
>
> So please throttle anything that might access the KDC way too much (as
> compared to normal keyboard operation by an user).
The io port accesses are already throttled and the blinking are quite slow in
computer time (talking about hundreds of milliseconds). It is hard to imagine
the EC is that slow.
-Andi
On Mon 2007-06-04 11:18:48, Dmitry Torokhov wrote:
> On 6/4/07, Pavel Machek <[email protected]> wrote:
> >
> >Hmm, this needs to be ran from console (not X). Can someone with
> >thinkpad try this?
>
> Are you saying it works OK when run in X?
setleds does not work in X, so there's no problem there.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2007-06-04 13:46:45, Dmitry Torokhov wrote:
> On 6/4/07, Henrique de Moraes Holschuh <[email protected]> wrote:
> >On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
> >> >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> >> >often. Launch the line above and try to do some typing...
> >>
> >> This used to work fine on my box last time I tried it (the switch
> >> itself is offloaded to a keventd and shoud not get in the way) but
> >> then they push all kind of ACPI/SMM crap together with KBC so who
> >> knows... I should try it again when I get home.
> >
> >Err... in laptops, almost *always* the KDC is emulated by the embedded
> >controller, so I bet you're right on the money, there. It is not "a buggy
> >KDC", it is a buggy EC firmware and/or buggy SMBIOS which is a lot more
> >common.
> >
> >And DoS'ing the EC is very high on the Don't Do That list on a laptop. If
> >the X60 is only losing keypresses and producing no bigger fireworks, that's
> >outstanding behavior (as far as I trust ThinkPad firmware, anyway).
> >
> >So please throttle anything that might access the KDC way too much (as
> >compared to normal keyboard operation by an user).
>
> What would be reasonable throttling? Once every 100 ms?
Well... this thread began with me having problems with leds blinking
once per ten seconds. I do not think throttling is going to help.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Henrique de Moraes Holschuh <[email protected]> wrote:
> On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
>> >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
>> >often. Launch the line above and try to do some typing...
>>
>> This used to work fine on my box last time I tried it (the switch
>> itself is offloaded to a keventd and shoud not get in the way) but
>> then they push all kind of ACPI/SMM crap together with KBC so who
>> knows... I should try it again when I get home.
>
> Err... in laptops, almost *always* the KDC is emulated by the embedded
> controller, so I bet you're right on the money, there. It is not "a buggy
> KDC", it is a buggy EC firmware and/or buggy SMBIOS which is a lot more
> common.
It happens on my desktop using an original IBM Model M PS/2 keyboard, too.
The keyboard controler is known to be too slow for 80286, you shouldn't be
surprised by that thing being too slow for modern PC, at least if you're
stroboscoping the LED.
--
knghtbrd:<JHM> AIX - the Unix from the universe where Spock has a beard.
Fri?, Spammer: [email protected] [email protected]
[email protected] [email protected] [email protected]
On Monday 04 June 2007 16:57, Pavel Machek wrote:
> On Mon 2007-06-04 13:46:45, Dmitry Torokhov wrote:
> > On 6/4/07, Henrique de Moraes Holschuh <[email protected]> wrote:
> > >On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
> > >> >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> > >> >often. Launch the line above and try to do some typing...
> > >>
> > >> This used to work fine on my box last time I tried it (the switch
> > >> itself is offloaded to a keventd and shoud not get in the way) but
> > >> then they push all kind of ACPI/SMM crap together with KBC so who
> > >> knows... I should try it again when I get home.
> > >
> > >Err... in laptops, almost *always* the KDC is emulated by the embedded
> > >controller, so I bet you're right on the money, there. It is not "a buggy
> > >KDC", it is a buggy EC firmware and/or buggy SMBIOS which is a lot more
> > >common.
> > >
> > >And DoS'ing the EC is very high on the Don't Do That list on a laptop. If
> > >the X60 is only losing keypresses and producing no bigger fireworks, that's
> > >outstanding behavior (as far as I trust ThinkPad firmware, anyway).
> > >
> > >So please throttle anything that might access the KDC way too much (as
> > >compared to normal keyboard operation by an user).
> >
> > What would be reasonable throttling? Once every 100 ms?
>
> Well... this thread began with me having problems with leds blinking
> once per ten seconds. I do not think throttling is going to help.
For what it worth I finally tried that setleds loop on my laptop. I am
not getting any lost keypresses/releases. But then I don't have EC
(or at least it is not exported via ACPI). This is an old Dell notebook.
--
Dmitry
On Tue, June 12, 2007 07:42, Dmitry Torokhov wrote:
> For what it worth I finally tried that setleds loop on my laptop. I am
> not getting any lost keypresses/releases. But then I don't have EC
> (or at least it is not exported via ACPI). This is an old Dell notebook.
Well, as I said before, I've the "stuck key"/repeated output too (as well
as a warping PS/2 mouse), but no blinking led problem, so I believe the
two things are totally unrelated.
Greetings,
Indan
Hi!
> > For what it worth I finally tried that setleds loop on my laptop. I am
> > not getting any lost keypresses/releases. But then I don't have EC
> > (or at least it is not exported via ACPI). This is an old Dell notebook.
>
> Well, as I said before, I've the "stuck key"/repeated output too (as well
> as a warping PS/2 mouse), but no blinking led problem, so I believe the
> two things are totally unrelated.
Well, after turning off CONFIG_BLINK, my problems went away, and with
a fast-blink done from userspace, I can make them way worse. They
_are_ related here.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, June 13, 2007 10:18, Pavel Machek wrote:
>> Well, as I said before, I've the "stuck key"/repeated output too (as well
>> as a warping PS/2 mouse), but no blinking led problem, so I believe the
>> two things are totally unrelated.
>
> Well, after turning off CONFIG_BLINK, my problems went away, and with
> a fast-blink done from userspace, I can make them way worse. They
> _are_ related here.
I missed you saying that before, so to me it looked like everyone just
assumed that.
So, just for fun, I tried running:
while true; do setleds +num; setleds -num; done
and it totally locked up my keyboard. Even SysRq didn't work. On the
bright side, the numlock LED was indeed blinking. Though running the
same with a sleep 0.1 added doesn't produce any problems. So maybe
my problem is indeed a bit related to this after all, somehow. Anyone
any ideas how to debug this problem?
Greetings,
Indan
On Wednesday 13 June 2007 10:09, Indan Zupancic wrote:
> On Wed, June 13, 2007 10:18, Pavel Machek wrote:
> >> Well, as I said before, I've the "stuck key"/repeated output too (as well
> >> as a warping PS/2 mouse), but no blinking led problem, so I believe the
> >> two things are totally unrelated.
> >
> > Well, after turning off CONFIG_BLINK, my problems went away, and with
> > a fast-blink done from userspace, I can make them way worse. They
> > _are_ related here.
>
> I missed you saying that before, so to me it looked like everyone just
> assumed that.
>
> So, just for fun, I tried running:
>
> while true; do setleds +num; setleds -num; done
>
> and it totally locked up my keyboard. Even SysRq didn't work.
Yeah, it does the same on my other laptop (newer HP as opposed
to an old Dell).
> On the
> bright side, the numlock LED was indeed blinking. Though running the
> same with a sleep 0.1 added doesn't produce any problems. So maybe
> my problem is indeed a bit related to this after all, somehow. Anyone
> any ideas how to debug this problem?
>
Does the patch below help?
--
Dmitry
Input: atkbd - throttle LED switching
On some boxes keyboard controllers are too slow to withstand
continuous flow of requests to turn keyboard LEDs on and off
and start losing some keypresses or even all of them.
Delay executing of LED switching request if we had another one
withing 50 ms thus easing load on the controller.
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/keyboard/atkbd.c | 40 ++++++++++++++++++++++++++--------------
1 files changed, 26 insertions(+), 14 deletions(-)
Index: work/drivers/input/keyboard/atkbd.c
===================================================================
--- work.orig/drivers/input/keyboard/atkbd.c
+++ work/drivers/input/keyboard/atkbd.c
@@ -219,7 +219,8 @@ struct atkbd {
unsigned long time;
unsigned long err_count;
- struct work_struct event_work;
+ struct delayed_work event_work;
+ unsigned long event_jiffies;
struct mutex event_mutex;
unsigned long event_mask;
};
@@ -565,7 +566,7 @@ static int atkbd_set_leds(struct atkbd *
static void atkbd_event_work(struct work_struct *work)
{
- struct atkbd *atkbd = container_of(work, struct atkbd, event_work);
+ struct atkbd *atkbd = container_of(work, struct atkbd, event_work.work);
mutex_lock(&atkbd->event_mutex);
@@ -579,12 +580,30 @@ static void atkbd_event_work(struct work
}
/*
+ * Schedule switch for execution. We need to throttle requests,
+ * otherwise keyboard may become unresponsive.
+ */
+static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
+{
+ unsigned long delay = msecs_to_jiffies(50);
+
+ if (time_after(jiffies, atkbd->event_jiffies + delay))
+ delay = 0;
+
+ atkbd->event_jiffies = jiffies;
+ set_bit(event_bit, &atkbd->event_mask);
+ wmb();
+ schedule_delayed_work(&atkbd->event_work, delay);
+}
+
+/*
* Event callback from the input module. Events that change the state of
* the hardware are processed here. If action can not be performed in
* interrupt context it is offloaded to atkbd_event_work.
*/
-static int atkbd_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
+static int atkbd_event(struct input_dev *dev,
+ unsigned int type, unsigned int code, int value)
{
struct atkbd *atkbd = input_get_drvdata(dev);
@@ -594,19 +613,12 @@ static int atkbd_event(struct input_dev
switch (type) {
case EV_LED:
- set_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask);
- wmb();
- schedule_work(&atkbd->event_work);
+ atkbd_schedule_event_work(atkbd, ATKBD_LED_EVENT_BIT);
return 0;
case EV_REP:
-
- if (!atkbd->softrepeat) {
- set_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask);
- wmb();
- schedule_work(&atkbd->event_work);
- }
-
+ if (!atkbd->softrepeat)
+ atkbd_schedule_event_work(atkbd, ATKBD_REP_EVENT_BIT);
return 0;
}
@@ -940,7 +952,7 @@ static int atkbd_connect(struct serio *s
atkbd->dev = dev;
ps2_init(&atkbd->ps2dev, serio);
- INIT_WORK(&atkbd->event_work, atkbd_event_work);
+ INIT_DELAYED_WORK(&atkbd->event_work, atkbd_event_work);
mutex_init(&atkbd->event_mutex);
switch (serio->id.type) {
On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
> Does the patch below help?
Didn't try it yet, but will tomorrow.
> Input: atkbd - throttle LED switching
>
> On some boxes keyboard controllers are too slow to withstand
> continuous flow of requests to turn keyboard LEDs on and off
> and start losing some keypresses or even all of them.
>
> Delay executing of LED switching request if we had another one
> withing 50 ms thus easing load on the controller.
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
> ---
>
> drivers/input/keyboard/atkbd.c | 40 ++++++++++++++++++++++++++--------------
> 1 files changed, 26 insertions(+), 14 deletions(-)
>
> Index: work/drivers/input/keyboard/atkbd.c
> ===================================================================
> --- work.orig/drivers/input/keyboard/atkbd.c
> +++ work/drivers/input/keyboard/atkbd.c
> @@ -219,7 +219,8 @@ struct atkbd {
> unsigned long time;
> unsigned long err_count;
>
> - struct work_struct event_work;
> + struct delayed_work event_work;
> + unsigned long event_jiffies;
> struct mutex event_mutex;
> unsigned long event_mask;
> };
> @@ -565,7 +566,7 @@ static int atkbd_set_leds(struct atkbd *
>
> static void atkbd_event_work(struct work_struct *work)
> {
> - struct atkbd *atkbd = container_of(work, struct atkbd, event_work);
> + struct atkbd *atkbd = container_of(work, struct atkbd, event_work.work);
>
> mutex_lock(&atkbd->event_mutex);
>
> @@ -579,12 +580,30 @@ static void atkbd_event_work(struct work
> }
>
> /*
> + * Schedule switch for execution. We need to throttle requests,
> + * otherwise keyboard may become unresponsive.
> + */
> +static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
> +{
> + unsigned long delay = msecs_to_jiffies(50);
> +
> + if (time_after(jiffies, atkbd->event_jiffies + delay))
> + delay = 0;
> +
> + atkbd->event_jiffies = jiffies;
> + set_bit(event_bit, &atkbd->event_mask);
> + wmb();
> + schedule_delayed_work(&atkbd->event_work, delay);
> +}
I don't know whether schedule_delayed_work() requeues event_work, or if
it adds more work, but both seem to give wrong behaviour: In the first case
event_work can be postponed forever if atkbd_schedule_event_work() is
called repeatedly each time within 50 ms, and for the second case there's a
delay added, but the number of times the LED is switched stays the same,
so it's not being throttled.
Greetings,
Indan
On Friday 15 June 2007 22:04, Indan Zupancic wrote:
> On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
> > /*
> > + * Schedule switch for execution. We need to throttle requests,
> > + * otherwise keyboard may become unresponsive.
> > + */
> > +static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
> > +{
> > + unsigned long delay = msecs_to_jiffies(50);
> > +
> > + if (time_after(jiffies, atkbd->event_jiffies + delay))
> > + delay = 0;
> > +
> > + atkbd->event_jiffies = jiffies;
> > + set_bit(event_bit, &atkbd->event_mask);
> > + wmb();
> > + schedule_delayed_work(&atkbd->event_work, delay);
> > +}
>
> I don't know whether schedule_delayed_work() requeues event_work, or if
> it adds more work, but both seem to give wrong behaviour:
Well, my advise would be to research the matter before saying that
it will not work.
> In the first case
> event_work can be postponed forever if atkbd_schedule_event_work() is
> called repeatedly each time within 50 ms, and for the second case there's a
> delay added, but the number of times the LED is switched stays the same,
> so it's not being throttled.
>
No, once work is queued for execution subsequent attempts to queue the
same work will be ignored (until work starts executing). Therefore first
time work will be scheduled for execution immediately and then execution
be spaced by ~50 ms.
--
Dmitry
On Sat, June 16, 2007 05:34, Dmitry Torokhov wrote:
> On Friday 15 June 2007 22:04, Indan Zupancic wrote:
>> On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
>> > /*
>> > + * Schedule switch for execution. We need to throttle requests,
>> > + * otherwise keyboard may become unresponsive.
>> > + */
>> > +static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
>> > +{
>> > + unsigned long delay = msecs_to_jiffies(50);
>> > +
>> > + if (time_after(jiffies, atkbd->event_jiffies + delay))
>> > + delay = 0;
>> > +
>> > + atkbd->event_jiffies = jiffies;
>> > + set_bit(event_bit, &atkbd->event_mask);
>> > + wmb();
>> > + schedule_delayed_work(&atkbd->event_work, delay);
>> > +}
>>
>> I don't know whether schedule_delayed_work() requeues event_work, or if
>> it adds more work, but both seem to give wrong behaviour:
>
> Well, my advise would be to research the matter before saying that
> it will not work.
Good advise. My advise to others is, that if you do research it, then don't
do it hastily like I did. ;-)
My quick search didn't find the exact behaviour of schedule_delayed_work(),
when looking in LDD, but I should've digged through to the description of
queue_delayed_work().
>> In the first case
>> event_work can be postponed forever if atkbd_schedule_event_work() is
>> called repeatedly each time within 50 ms, and for the second case there's a
>> delay added, but the number of times the LED is switched stays the same,
>> so it's not being throttled.
>>
>
> No, once work is queued for execution subsequent attempts to queue the
> same work will be ignored (until work starts executing). Therefore first
> time work will be scheduled for execution immediately and then execution
> be spaced by ~50 ms.
Thank you for the explanation.
I applied the patch, and it compiles and runs as expected, can't lockup the
keyboard anymore with it applied.
Greetings,
Indan
On Saturday 16 June 2007 07:54, Indan Zupancic wrote:
>
> I applied the patch, and it compiles and runs as expected, can't lockup the
> keyboard anymore with it applied.
>
Thank you for testing.
--
Dmitry