Bug 3037

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.