keyboard sticking

Printable View

05-28-2008, 03:09 PM
alderon

keyboard sticking

Dunno exactlyyyyyy how to describe the problem but this sentence demonstrates it ppppppretty clearlyyyyy.

I'd like know how to describe the problem so I can search for it in google... words like sticky or erratic aren't getting me much. One thread I found suggested its a conflict between apm and acpi, but apm isn't installed in the systems I use.

I'm still noobish with Linux (less than a year) and the only sources I use are from Debian's main repo, updated regularly. The keys stick in all three systems but much less often in KDE. The proggggram doesn't matter; it happens using the arrow keys in aptitude or typing a url in Iceweasel. Doesn't affect the mouse.

Hasn't always been this way; started acting weird a month or so ago. Its not consistent in that it happens for a while and then most of the time, the keyboard works fine. I cannot think of what I did that likely precipitated the problem.

If someone knows what's going on and/or can give me a leg up in resolving this, I'd sure appreciate it.

Thanks!

Installed:
Etch KDE
Etch netinstall + fluxbox + rox
Lenny netinstall + fluxbox +rox (installed three days ago)

Its a desktop (P4, 2GHz, 768ram) that's about seven years old with newer 80G HD and video card.

lspci:
00:00.0 Host bridge: Intel Corporation 82845 845 [Brookdale] Chipset Host Bridge (rev 04)
00:01.0 PCI bridge: Intel Corporation 82845 845 [Brookdale] Chipset AGP Bridge (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 05)
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 05)
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller (rev 05)
00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev 05)
00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus Controller (rev 05)
00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev 05)
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio Controller (rev 05)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
02:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 03)
02:0a.0 Modem: Broadcom Corporation BCM4212 v.90 56k modem
02:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
02:0b.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)
05-28-2008, 03:13 PM
ph34r

Since it is a desktop, why not just swap out the keyboard for a different one?

I've seen this happen where someone has spilled something on the kb, but dried it before the owner knew. Also seen stuff like this with a bent/torqued PS2 connector, etc.
05-28-2008, 04:49 PM
alderon

Thanks, ph34r, trying out another keyboard would confirm whether the problem's actually this keyboard. Hafta ask around the neighborhood this evening cause there's no spare parts here. Don't recall anything ever spilled on it. I'll post the result one way or the other.
05-28-2008, 08:40 PM
alderon

Interesting... tried out a neighbor's keyboard and it worked fine. Plugged mine back in and it worked fine, too. Seems somewhere along the way the PS2 connector got unseated, like when I turned the box to connect the printer last month.

Thanks again, ph34r. Good call.
06-13-2008, 07:21 PM
alderon

A follow up:

Keyboard started sticking again a few days after my last post. I was in one of the netinstalls and had 'top' open at the time, and saw something was keeping the CPU at 95-99%. I used sysvconfig to disable some services like alsa-utils, cron, pppd-dns, rsync, and a few others.

The result: other than when starting apps or surfing, the CPU was usually around 1-3% and the keyboard worked fine for over a week. Did the same edit in the other two systems and haven't had any sticking since.
06-14-2008, 08:49 AM
bwkaz

Did you see what the process name was that was using that much CPU? You might be able to turn off just one service to get it back down to normal. Some of the services you mentioned are actually useful for things (e.g. the alsa service is most likely used to save and restore volume settings across reboots (and doesn't do anything else), cron is used to schedule tasks (some of which, like checking for package updates, are really good to leave enabled), etc.).

Of course rsync and pppd-dns are probably not needed; rsync is used to synchronize files between machines (or local directories maybe?), and I'm not sure what pppd-dns is. It sounds like it may be related to a PPPoE (DSL) or dial-up connection though.
06-15-2008, 09:46 PM
alderon

Quote:

Did you see what the process name was that was using that much CPU?

No, I didn't, mainly because the high CPU use was constant and didn't seem to be caused by any one process. When I was using Iceweasel, Iceweasel showed maybe 98%CPU. When in the terminal to mount another partition, xterm showed the same high %. After idling for a few moments it dropped back under 5%... but the minute I started using an app it jumped above 90%. I figured some process was causing the high CPU, which in turn, was glitching the keyboard... so I disabled some processes.

I googled "debian high CPU use" in the last 3 months and got 450K hits. Something may be going on; there are Debian bugs as well as posts describing problems with apache, samba, different processes and lots of apps. On the other hand, since editing the processes in sysvconfig, I haven't seen high CPU% usage in top.

Later in the day, after my last post, the keyboard started acting up again so I borrowed another neighbor's keyboard. Its a Compaq USB (my keyboard's PS/2), its maybe 4 yrs old and my neighbor never had a problem with it... but it, too, now skips/sticks on my system.

The processes I edited in sysvconfig... I figured I wouldn't need the alsa-utils because the sound has been set up for 6 months (Etch) and works fine. As for cron and rsync, I updddate and backup manually. The pppd-dns is (I believe) for dial-up and I've got dsl. I also turned off openbsd-inetd and exim4 because I use only web-based email and (from what I understand) don't need/use the server/mail services.

About three weeks ago I backed up a complete copy of both Etch systems to separate partitions. This morning I booted into them and the keyboard was erratic. I mention this because both of those systems start with all the default processes. It appears both keyboards intermittently glitch whether the services are on or off.

One other thing is all three systems (Etch, Etch, Lenny) have uswsusp and vbetool installed. After trying powernowd, hibernate, etc, s2ram was the only app which brought the screen back from sleep. I found some keyboard related bugs with uswsusp but they're about losing use of both mouse and keyboard. The keyboard glitch has occurred after resuming from s2ram as well as right after booting, so s2ram doesn't appear to be the cause. Also, as I wrote in the first post, the keyboard worked fine up until a month or so ago.

At this point, I don't know which way to turn to troubleshoot and I'm open to any suggestions.

Thanks!
06-16-2008, 04:12 PM
irlandes

Distro problems???

I have had that problem with PClinuxOS on one machine. I realize that may not be a valuable tip, but the distro made a difference on one machine, not on others.

Oh, wait, I think I had it on that same machine with CentOS also. Try a live CD and see if it changes.
06-16-2008, 06:52 PM
bwkaz

Quote:

Originally Posted by alderon

When I was using Iceweasel, Iceweasel showed maybe 98%CPU. When in the terminal to mount another partition, xterm showed the same high %. After idling for a few moments it dropped back under 5%... but the minute I started using an app it jumped above 90%.

Did it follow the focus then? Could you tell if it was related to painting, or keyboard input, or perhaps something else? It sounds like it may have been related to keyboard input, possibly.

Quote:

I figured some process was causing the high CPU, which in turn, was glitching the keyboard... so I disabled some processes.

Well, if you saw the xterm process using a lot of CPU, that means that some code that's running inside the xterm process is running often. It can't be due to some other process on the machine; it has to be something inside xterm.

Well, or some kernel code running on behalf of xterm. Can you easily install gkrellm? It has separate graphs for user code's CPU usage versus kernel (user CPU is blue or green; kernel CPU is orange). If you see lots of orange, then it's something weird going on inside the kernel. Otherwise, it's likely something weird going on in some widely-used library.

What it might have been, actually, is something related to either OpenGL (since a lot of that runs in the process that uses it), or X itself (since it loads a lot of code into each X-using program). I'm thinking perhaps a software rendered version of Xgl/Compiz/whatever-3D-desktop, where whenever you're interacting with any program, your machine is trying to do 3D graphics, but it has to do it on the CPU because your graphics card isn't able to? Just a thought.

It might also be slow font or pixmap rendering; some of this can be sped up with the right video card, driver, and options, with the "RENDER" extension. (Most drivers seem to support RENDER, but e.g. VESA generic drivers don't.)

Quote:

Later in the day, after my last post, the keyboard started acting up again so I borrowed another neighbor's keyboard. Its a Compaq USB (my keyboard's PS/2), its maybe 4 yrs old and my neighbor never had a problem with it... but it, too, now skips/sticks on my system.

I would suspect (but don't know for sure) that the issue is indeed the high CPU usage; it probably interferes with the kernel's ability to handle the input device interrupts. Strange.

Quote:

I figured I wouldn't need the alsa-utils because the sound has been set up for 6 months (Etch) and works fine.

I'm not exactly sure what that script does. But if it saves and restores your sound card channel volumes, it is definitely needed, and it doesn't run any code except at start and stop time. ;)

Quote:

As for cron and rsync, I updddate and backup manually. The pppd-dns is (I believe) for dial-up and I've got dsl. I also turned off openbsd-inetd and exim4 because I use only web-based email and (from what I understand) don't need/use the server/mail services.

That sounds OK. I'm not sure if pppd-dns is for dial-up only, though; if your DSL uses PPPoE, you might still need it. It also looks like it too only runs code at startup and shutdown, not all the time.

Quote:

At this point, I don't know which way to turn to troubleshoot and I'm open to any suggestions.

Are you running any kind of 3D desktop? Does disabling it (temporarily) help? What video card (and driver for it) are you using?
06-18-2008, 03:27 PM
alderon

@ irlandes

Quote:

Try a live CD and see if it changes.

Within the last two weeks I've booted Puppy and Slax CD's, and I don't recall a problem with the keyboard. Since the keyboard may work fine for a few days and then (for whatever reason) glitch, its not certain whether the keyboard would or wouldn't have glitched with the CD's.

@ bwkaz

Quote:

When I was using Iceweasel, Iceweasel showed maybe 98%CPU. When in the terminal to mount another partition, xterm showed the same high %. After idling for a few moments it dropped back under 5%... but the minute I started using an app it jumped above 90%.

Quote:

Did it follow the focus then? Could you tell if it was related to painting, or keyboard input, or perhaps something else? It sounds like it may have been related to keyboard input, possibly.

If by 'follow the focus' you mean the high CPU applied to whichever service/application was on the first line under %CPU, the answer is yes. After the service/application moved down to the 2nd or 3rd line, its CPU usage dropped to less than 5%.

I don't understand the question, "if it was related to painting, or keyboard input, or perhaps something else?"

Quote:

I figured some process was causing the high CPU, which in turn, was glitching the keyboard... so I disabled some processes.

Quote:

Well, if you saw the xterm process using a lot of CPU, that means that some code that's running inside the xterm process is running often. It can't be due to some other process on the machine; it has to be something inside xterm.

Would that hold true for konsole, the default terminal in KDE? That's what I use for mounting partitions, and for aptitude when updating and/or installing apps.

Quote:

Well, or some kernel code running on behalf of xterm. Can you easily install gkrellm? It has separate graphs for user code's CPU usage versus kernel (user CPU is blue or green; kernel CPU is orange). If you see lots of orange, then it's something weird going on inside the kernel. Otherwise, it's likely something weird going on in some widely-used library.

Yes, I installed gkrellm, and here's some readings from top and gkrellm.

In Etch KDE

Top: when I open konsole, the CPU for knosole is 13% then drops. When I invoke aptitude, aptitude initially shows 65% CPU then drops. When I continuously scroll in aptitude, aptitude shows 25% and xorg jumps to 36% CPU.

Gkrellm: when I open konsole, the blue CPU jumps to 97%, then to 38% and then drops to less than 5%. When I invoke aptitude, blue CPU initially shows 99% then quickly drops. When I continuously scroll in aptitude, blue CPU shows 30%, then 70%, and when scrolling stops, quickly drops to less than 5%.

In Etch netinstall:

Top: when I open xterm, the CPU is 2%. When I invoke aptitude, aptitude initially shows 57% CPU, then 12% and then drops. When I continuously scroll in aptitude, aptitude shows 25% CPU and xorg is maybe 5%.

Gkrellm: when I open xterm, the blue CPU jumps to 58% (other times to 37%), then drops to less than 2%. When I invoke aptitude, blue CPU shows 38%, then 99%, then 25% and then drops. When I continuously scroll in aptitude, blue CPU shows 22%, and when scrolling stops, drops to less than 2%.

As a comparison in gkrellm: when I open iceweasel, the blue CPU jumps to 97%, then 61%, then 0. Loading this site: CPU: 62%, 80%, 99%, 12%, 0.

For Proc (the orange graph):
Most of the time its at 0, with blips of 12.5k.
When starting these apps:
xterm: 406k (other times 205k)
aptitude: 139k
scrolling: 20k
iceweasel: 438k
loading JustLinuxForums page: 496k

Question: is it normal to see 95-100% CPU when starting aptitude or iceweasel?

Quote:

What it might have been, actually, is something related to either OpenGL (since a lot of that runs in the process that uses it), or X itself (since it loads a lot of code into each X-using program). I'm thinking perhaps a software rendered version of Xgl/Compiz/whatever-3D-desktop, where whenever you're interacting with any program, your machine is trying to do 3D graphics, but it has to do it on the CPU because your graphics card isn't able to? Just a thought.

Are you running any kind of 3D desktop? Does disabling it (temporarily) help? What video card (and driver for it) are you using?

I'm using the unaccelerated vesa driver because I haven't gotten the accelerated driver to work with s2ram... putting the system to sleep when I want is a higher priority than eye candy. So, no Compiz and no 3D graphics. The card is a GeForce FX 5200.

That said, your point is a good one. I just installed the accelerated Nvidia driver on the netinstall and will use it for a week. Be nice to find out if that's the issue.

Quote:

Later in the day, after my last post, the keyboard started acting up again so I borrowed another neighbor's keyboard. Its a Compaq USB (my keyboard's PS/2), its maybe 4 yrs old and my neighbor never had a problem with it... but it, too, now skips/sticks on my system.

Quote:

I would suspect (but don't know for sure) that the issue is indeed the high CPU usage; it probably interferes with the kernel's ability to handle the input device interrupts. Strange.

That's what it seems like to me when the keyboard starts skipping, but still being low on the learning curve, I've no specific knowledge/experience to base it on.

Quote:

I figured I wouldn't need the alsa-utils because the sound has been set up for 6 months (Etch) and works fine.

Quote:

I'm not exactly sure what that script does. But if it saves and restores your sound card channel volumes, it is definitely needed, and it doesn't run any code except at start and stop time.

Alsa-utils includes alsaconf to set up the sound card and alsactl to save the choice as the default. It also includes some CL utilities like the mixer and some others. I had some problems using alsactl and finally hand edited some files in /etc/modprobe.d to make my SBLive card the default. For the mixer, which I rarely use, I prefer alsamixergui. I think alsa-base has the actual sound device drivers, which is why I left it enabled.

Quote:

I'm not sure if pppd-dns is for dial-up only, though; if your DSL uses PPPoE, you might still need it. It also looks like it too only runs code at startup and shutdown, not all the time.

Disabling pppd-dns hasn't caused a problem (that I know of); I can access my web-based email (yahoo, gmail) through Iceweasel. I don't use an email client app (evolution, mutt). FWIW, I can use gmail to post to user lists.

I'll post an update next week (with the GLX installed) and let you know about the keyboard. If you have any thoughts on what else I might try, please holler out.

I really do appreciate you giving me a hand with this. Thanks!
06-18-2008, 07:19 PM
bwkaz

Quote:

Originally Posted by alderon

If by 'follow the focus' you mean the high CPU applied to whichever service/application was on the first line under %CPU,

No, I expected it to follow that. The reason is that top sorts by CPU usage. :p

I meant, did the program that had the focus (i.e. the program that received your keyboard input when you typed) always use lots of CPU?

Quote:

I don't understand the question, "if it was related to painting, or keyboard input, or perhaps something else?"

Does it happen when the program needs to change something in its window, or does it seem like it's caused when you type into a program, or can you see any other pattern?

Quote:

Would that hold true for konsole, the default terminal in KDE?

Yes -- it would hold for any terminal emulator. Actually, it would hold for any process on the system anywhere. ;)

Quote:

Top: when I open konsole, the CPU for knosole is 13% then drops. When I invoke aptitude, aptitude initially shows 65% CPU then drops. When I continuously scroll in aptitude, aptitude shows 25% and xorg jumps to 36% CPU.

That -- especially the high usage in xorg -- sounds like video related stuff. Drawing lots of pixels can get slow sometimes without hardware acceleration.

Quote:

Gkrellm: when I open konsole, the blue CPU jumps to 97%, then to 38% and then drops to less than 5%.

OK, but it's not orange, which means it's some kind of user-mode code, not kernel. :)

It's only taking a couple of seconds to stop, though, which -- I think -- means it's probably OK.

Quote:

When I invoke aptitude, blue CPU initially shows 99% then quickly drops. When I continuously scroll in aptitude, blue CPU shows 30%, then 70%, and when scrolling stops, quickly drops to less than 5%.

That all sounds fine. It might be video related, but if the high usage is short-lived, it's not usually a huge deal...

Quote:

In Etch netinstall:

Top: when I open xterm, the CPU is 2%. When I invoke aptitude, aptitude initially shows 57% CPU, then 12% and then drops. When I continuously scroll in aptitude, aptitude shows 25% CPU and xorg is maybe 5%.

That's slightly lower, but it does still follow the same type of pattern -- high as the process is loading and starting up, then down to nothing as it goes idle.

Quote:

Gkrellm: when I open xterm, the blue CPU jumps to 58% (other times to 37%), then drops to less than 2%. When I invoke aptitude, blue CPU shows 38%, then 99%, then 25% and then drops. When I continuously scroll in aptitude, blue CPU shows 22%, and when scrolling stops, drops to less than 2%.

Part of the discrepancy here might be the accounting methods that gkrellm uses versus top; if they use a different interface (or different rules for totals), they might get different CPU usage values. They do both follow a similar pattern, though; that means that the pattern is probably valid.

And the pattern is OK -- high CPU usage at startup isn't necessarily a huge problem. (Of course, if it's causing issues with the keyboard, it might be...)

Quote:

As a comparison in gkrellm: when I open iceweasel, the blue CPU jumps to 97%, then 61%, then 0. Loading this site: CPU: 62%, 80%, 99%, 12%, 0.

I'm not surprised that loading this site uses lots of CPU -- it's not all that simple of a rendering job. :) Iceweasel itself is quite a lot of files, too, so I'm not exactly surprised that loading it is slightly CPU-intensive.

Quote:

Question: is it normal to see 95-100% CPU when starting aptitude or iceweasel?

It's not necessarily a problem. I see the same type of pattern on this machine (although it generally lasts less than a second, not 2-5 seconds).

Quote:

I'm using the unaccelerated vesa driver

Ah ha. :)

Quote:

because I haven't gotten the accelerated driver to work with s2ram... The card is a GeForce FX 5200.

I'm surprised the nvidia driver doesn't work with s2ram. Hmm.

Quote:

Alsa-utils includes alsaconf to set up the sound card and alsactl to save the choice as the default.

Right, but something (at boot time) has to call back out to alsactl to re-load the mixer volume settings. ("alsactl restore", I think.)

Quote:

I had some problems using alsactl and finally hand edited some files in /etc/modprobe.d to make my SBLive card the default. For the mixer, which I rarely use, I prefer alsamixergui. I think alsa-base has the actual sound device drivers, which is why I left it enabled.

Yeah, I'm not sure how Debian sets up all that stuff.

Quote:

Disabling pppd-dns hasn't caused a problem (that I know of); I can access my web-based email (yahoo, gmail) through Iceweasel.

That's probably fine then.

Good luck... :)
06-25-2008, 12:12 PM
alderon

Quote:

When I continuously scroll in aptitude, aptitude shows 25% and xorg jumps to 36% CPU.

Quote:

That -- especially the high usage in xorg -- sounds like video related stuff. Drawing lots of pixels can get slow sometimes without hardware acceleration.

I think you nailed it, bwkaz.

I installed the nvidia-kernel/-glx in Etch netinstall, leaving both Lenny and Etch KDE unaccelerated. Spent the last week almost exclusively in the accelerated Etch and did not experience a keyboard problem.

Three days after I installed the accelerated driver, I used sysvconfig to change the services back to their defaults: no high CPU and no keyboard problem. The several times I booted into the others the same keyboard problem came up; not every time, but it still happened.

What remains is the s2ram/sleep issue I mentioned earlier. I've been rereading the docs and if I cannot get it working, I'll start a separate thread for it.

I think the keyboard issue can actually be considered resolved - Thank You!
06-26-2008, 06:56 PM
bwkaz

Quote:

Originally Posted by alderon

What remains is the s2ram/sleep issue I mentioned earlier. I've been rereading the docs and if I cannot get it working, I'll start a separate thread for it.

I think I saw a couple of wiki articles from various distros on how to get s2ram working with nvidia -- might be worth looking up a few of them if you haven't seen them already. I believe Googling for "s2ram nvidia" found most of them. :)
06-28-2008, 03:52 PM
irlandes

Since this thread may get google hits, I will add a mechanical problem I have had with my laptop keyboards. I live in a quarry town here in Mexico, and there is a large amount of marble dust blowing around in dry season.

Sometimes when I boot, there will be a keyboard problem. The first time it happened, I was visiting my son the medical student. He took his high powered air compressor and blew a lot of dust out and it worked. Usually, here in Mexico, I need to use an old tire pump and eventually get the job done with a lot of elbow grease.