For the longest time now (many months), after switching from FC1 to FC3 (yum upgrade), my numlock LED will turn itself off for no apparent reason while I am working, usually several times a day. It's usually while I'm typing, and I can't seem to put my finger on exactly what's triggering it -- it seems very random. Lately it appears to be around when I am holding left-shift down to do some capital letters, but I can't know for sure. It's just the LED shutting off. Numlock is still in effect. If I press caps lock, then the numlock key will come back on to indicate its correct status. If I press numlock after the numlock LED has turned off, then the numlock LED stays off (again showing that numlock indeed was still on). If I press numlock again, the LED will come back on (as expected). I'm using Driver "kbd" in my xorg.conf file. I have had issues in the past with Driver "keyboard" and am still using kbd for that reason. I have no idea if this is related. Also listed at bugzilla.redhat.com # 151779
I also get this problem. Running Fedora Core 4. Is there any information I can collect to help get this bug fixed?
Funny, but on FC3 -- fully updated -- I haven't seen this problem occur in a VERY long time -- like months. I'm not sure if an update fixed it or what else might have changed. If it happens again I'll be sure to report back. I was thinking it might be a problem with my DLink KVM switch, but that switch is still in place and the problem seems to have gone. I also never see this behaviour on the Windows XP side of my KVM, though I don't spend 1/100th the time in XP as I do in Linux. Are you running a KVM switch? Have you updated to all the latest FC4 packages (especially Xorg)?
Hmm no I'm not running a KVM. I update the system several times a week. The relevant part of my xorg.conf is: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection I have no idea what causes it... It happens around once every day for me.
That's pretty much the same xorg.conf voodoo as I use (driver = kbd). It used to hit me about once a day also, and drove me batty. I hadn't thought about it in a long time and your post made me realize I haven't seen the bug in a very long time. I'm thinking hard about what I may have changed in my system but I can't think of anything. OS is still FC3. KVM still there. Keyboard still the same. I *think* I changed my mouse from a 3-year-old IBM MO18B (PS2 w/USB convertor) to a brand new MO18B in this time period (scroll knob was starting to get touchy). I'm not sure how a mouse would affect numlock though. I also removed the 4 IDE drive RAID 5 md array I had in the box (with a Promise TX100 card) to put it in a separate file server box. If it's an interrupt mask issue, perhaps the heavy drive usage might have caused it? The user of my new server (with 10 drives now!) has not complained of this problem, but I will keep a close eye on it. That's all I can think of. If you have anything unique to your situation or similar to the above, please let us know. If it is a hardware related problem then finding a common theme will help.
Ok I think I may have found (one of) the causes. When I switch to a terminal with Ctrl+Alt+F1, depending on whether Numlock is on or off for that terminal I get the following behaviour after switching back to X (Ctrl+Alt+F7): If Numlock is off in terminal, switching back to X causes the numlock to come on, then it mysteriously goes off again after a few seconds (but it's really still 'on'). If Numlock is on in the terminal, switching back to X causes it to turn off. (Though once again, it's still 'on' in terms of functionality).
But I *never* switch to console or other virt terminals -- ever. And I used to get this problem all the time. I'm sure you can confirm that you get this bug even on days where you don't switch virt terminals, right? Perhaps we are dealing with 2 different bugs, perhaps related, perhaps not.
(In reply to comment #5) > Ok I think I may have found (one of) the causes. > When I switch to a terminal with Ctrl+Alt+F1, depending on whether Numlock is on > or off for that terminal I get the following behaviour after switching back to X > (Ctrl+Alt+F7): > If Numlock is off in terminal, switching back to X causes the numlock to come > on, then it mysteriously goes off again after a few seconds (but it's really > still 'on'). > If Numlock is on in the terminal, switching back to X causes it to turn off. > (Though once again, it's still 'on' in terms of functionality). I also noticed this, but this seems random, sometimes, numlock led stays on, when switching with Ctrl+Alt+F$ sometimes not. I'd like numlock to keep its state, on a given DISPLAY, even if I switch to terminal, or to an other display, when I'm back on the first display, I should find numlock how it was before. So is it a bug, or a missing feature?
Further to my comment #2, I have not seen this bug since that time. Last month I upgraded to FC5 and I have not seen the behaviour there either (xorg-x11-server-Xorg-1.0.1-9.fc5.5). I believe this problem may have been fixed somewhere in FC3 late-life updates (and so in later FC4 updates and hence FC5). Unless someone can dispute, I would say it is closed.
I am still getting this bug with FC5 and xorg 7.0. After switching back from a vt the numlock light comes on momentarily then goes off again (though it is still "on" in that the keypad works, and pressing it twice is required to make the light come back on).
As per my original opening description, I have NOT seen this bug since late-update FC3 as per comment #8. The bug as originally described had nothing to do with VT's. I didn't use VT's. Whether the VT issue is the same bug or a different bug, should be made clear so the devs know what they are dealing with. My guess is the bugs are related, but certainly random behaviour when you're switching VT's is better than random behaviour when you're just using X normally (without VT's)! If no one can confirm the original bug in late FC3, late FC4 or FC5 then the bug as originally reported is probably fixed. Obviously the VT bug remains. I just wanted to make the issue clear.
This is possibly a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=1530
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Trevor Cordes Do you still experience this issue with newer soft ? Please check the status of your issue.
I haven't seen this bug in forever, so it must have been fixed along the line, closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.