voluntary-preempt-2.6.8-rc2-L2 PS2 keyboard gone south
Twice while using -L2 my IBM PS2 keyboard has become completely non-responsive. USB mouse and everything else seems to be fine, but no LEDs or anything from the keyboard.
On both occasions the last key I hit on the keyboard was numlock and the numlock did not come on and I had to reboot after that.
UP, x86, gcc 2.95, scsi + ide, bttv
Resolved in M5?
Regards,
Shane
Quoted 10 lines · Shane Shrybman
Twice while using -L2 my IBM PS2 keyboard has become completely non-responsive. USB mouse and everything else seems to be fine, but no LEDs or anything from the keyboard.
On both occasions the last key I hit on the keyboard was numlock and the numlock did not come on and I had to reboot after that.
UP, x86, gcc 2.95, scsi + ide, bttv
Resolved in M5?
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
echo 0 > /proc/irq/1/*/threaded
(this turns the IRQ 1 thread off.)
Ingo
Hi,
Quoted 9 lines · Ingo Molnar
Quoted 7 lines · Shane Shrybman
Twice while using -L2 my IBM PS2 keyboard has become completely non-responsive. USB mouse and everything else seems to be fine, but no LEDs or anything from the keyboard.
On both occasions the last key I hit on the keyboard was numlock and the numlock did not come on and I had to reboot after that.
Quoted 7 lines
Quoted 3 lines
UP, x86, gcc 2.95, scsi + ide, bttv
Resolved in M5?
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Quoted 2 lines
echo 0 > /proc/irq/1/*/threaded
I rebooted and tried the above command, but the keyboard became unresponsive again soon after starting X.
Quoted 4 lines
(this turns the IRQ 1 thread off.)
Ingo
Shane
Quoted 4 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
Quoted 5 lines · Felipe Alfaro Solana
Quoted 3 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Quoted 7 lines
Quoted 1 line
Ok, M5 locked up the whole machine within a few seconds of starting X.
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
It looks like this is a mouse problem, I have a PS/2 keyboard and USB mouse and have not had any problems yet with M5. I also found that with L2, I could toggle Caps Lock fast enough to get significantly 'ahead' of it, this no longer happens with M5.
Lee
Quoted 11 lines · Lee Revell
Quoted 10 lines · Felipe Alfaro Solana
Quoted 4 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
Quoted 7 lines
Quoted 2 lines
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
It looks like this is a mouse problem, I have a PS/2 keyboard and USB mouse and have not had any problems yet with M5. I also found that with L2, I could toggle Caps Lock fast enough to get significantly 'ahead' of it, this no longer happens with M5.
I have a PS/2 keyboard and a USB mouse.
Quoted 15 lines · Felipe Alfaro Solana
Quoted 14 lines · Lee Revell
Quoted 12 lines · Felipe Alfaro Solana
Quoted 4 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
Quoted 6 lines
Quoted 4 lines
It looks like this is a mouse problem, I have a PS/2 keyboard and USB mouse and have not had any problems yet with M5. I also found that with L2, I could toggle Caps Lock fast enough to get significantly 'ahead' of it, this no longer happens with M5.
I have a PS/2 keyboard and a USB mouse.
Weird. This is my setup also, and I have had no problems since installing M5.
Try:
Option "NoAccel"
in section "Device" of your XF86Config. Also try commenting out:
Load "dri"
in the "Module" section.
This will ensure that the X server is not accessing hardware directly. Normally this should not be a problem but a buggy video driver can cause problems. On my machine, having 2D acceleration enabled caused interrupts from other devices to be lost when dragging a window.
Also, is the machine pingable after it locks up?
Lee
Quoted 34 lines · Lee Revell
Quoted 15 lines · Felipe Alfaro Solana
Quoted 14 lines · Lee Revell
Quoted 12 lines · Felipe Alfaro Solana
Quoted 4 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
Quoted 6 lines
Quoted 4 lines
It looks like this is a mouse problem, I have a PS/2 keyboard and USB mouse and have not had any problems yet with M5. I also found that with L2, I could toggle Caps Lock fast enough to get significantly 'ahead' of it, this no longer happens with M5.
I have a PS/2 keyboard and a USB mouse.
Weird. This is my setup also, and I have had no problems since installing M5.
Try:
Option "NoAccel"
in section "Device" of your XF86Config. Also try commenting out:
Load "dri"
Quoted 8 lines
in the "Module" section.
This will ensure that the X server is not accessing hardware directly. Normally this should not be a problem but a buggy video driver can cause problems. On my machine, having 2D acceleration enabled caused interrupts from other devices to be lost when dragging a window.
Also, is the machine pingable after it locks up?
Curiously, the machine is pingable, but I can't ssh/telnet into it: no data is received from the locked machine.
Quoted 42 lines · Felipe Alfaro Solana
Quoted 41 lines · Lee Revell
Quoted 15 lines · Felipe Alfaro Solana
Quoted 14 lines · Lee Revell
Quoted 12 lines · Felipe Alfaro Solana
Quoted 4 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
Quoted 6 lines
Quoted 4 lines
It looks like this is a mouse problem, I have a PS/2 keyboard and USB mouse and have not had any problems yet with M5. I also found that with L2, I could toggle Caps Lock fast enough to get significantly 'ahead' of it, this no longer happens with M5.
I have a PS/2 keyboard and a USB mouse.
Weird. This is my setup also, and I have had no problems since installing M5.
Try:
Option "NoAccel"
in section "Device" of your XF86Config. Also try commenting out:
Load "dri"in the "Module" section.
This will ensure that the X server is not accessing hardware directly. Normally this should not be a problem but a buggy video driver can cause problems. On my machine, having 2D acceleration enabled caused interrupts from other devices to be lost when dragging a window.
Quoted 5 lines
Quoted 1 line
Also, is the machine pingable after it locks up?
Curiously, the machine is pingable, but I can't ssh/telnet into it: no data is received from the locked machine.
Hmm. Maybe the problem is filesystem or disk related. Is your root partition on IDE or SCSI? It could be a SCSI problem.
Are you running software or hardware RAID?
This is the same behavior you get when, for example, a disk dies.
Lee
Quoted 43 lines · Lee Revell
Quoted 42 lines · Felipe Alfaro Solana
Quoted 41 lines · Lee Revell
Quoted 15 lines · Felipe Alfaro Solana
Quoted 14 lines · Lee Revell
Quoted 12 lines · Felipe Alfaro Solana
Quoted 4 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
Quoted 6 lines
Quoted 4 lines
It looks like this is a mouse problem, I have a PS/2 keyboard and USB mouse and have not had any problems yet with M5. I also found that with L2, I could toggle Caps Lock fast enough to get significantly 'ahead' of it, this no longer happens with M5.
I have a PS/2 keyboard and a USB mouse.
Weird. This is my setup also, and I have had no problems since installing M5.
Try:
Option "NoAccel"
in section "Device" of your XF86Config. Also try commenting out:
Load "dri"in the "Module" section.
This will ensure that the X server is not accessing hardware directly. Normally this should not be a problem but a buggy video driver can cause problems. On my machine, having 2D acceleration enabled caused interrupts from other devices to be lost when dragging a window.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Also, is the machine pingable after it locks up?
Curiously, the machine is pingable, but I can't ssh/telnet into it: no data is received from the locked machine.
Hmm. Maybe the problem is filesystem or disk related. Is your root partition on IDE or SCSI? It could be a SCSI problem.
No SCSI. Only 2 IDE drives, 1 ATAPI DVD and 1 ATAPI CD-RW.
Quoted 1 line
Are you running software or hardware RAID?
No.
Quoted 1 line
This is the same behavior you get when, for example, a disk dies.
I have 2 identical UDMA 120GB Seagate disks which are 1 month old, so I guess it's not a problem with bad hardware.
It turns out that my lock ups where related to APIC. Disabling APIC seems to get rid of those lock ups.
Quoted 2 lines · Felipe Alfaro Solana
It turns out that my lock ups where related to APIC. Disabling APIC seems to get rid of those lock ups.
ah ... that makes sense. It is most likely level-triggered IO-APIC interrupts that break. Could you try to turn off redirection for every interrupt that says 'IO-APIC-level' in /proc/interrupts - does that stabilize things? (besides the 'noapic' workaround you already discovered.) How does your /proc/interrupts look like btw?
the 'XT-PIC' interrupt controller (i8259A) is fine for redirection. (and that's what i used for testing almost exclusively.)
Ingo
Quoted 8 lines · Lee Revell
Quoted 7 lines · Felipe Alfaro Solana
Quoted 4 lines · Shane Shrybman
Quoted 2 lines
M5 does that differently, yes - so could you try it? If you still get problems, does this fix it:
Ok, M5 locked up the whole machine within a few seconds of starting X.
Quoted 8 lines
Quoted 5 lines
Me too, with voluntary-preempt=3... It seems I can trigger this randomly by heavily moving the mouse around while logging in into my KDE session.
However, with voluntary-preempt=2 I've been unable to lock the machine yet.
It looks like this is a mouse problem, I have a PS/2 keyboard and USB mouse and have not had any problems yet with M5.
I have a usb mouse and PS/2 keyboard as well. The mouse kept functioning and the keyboard didn't, except when the whole machine hung. I am recompiling M5 from fresh sources to confirm the behaviour there.
Hmm, M5 still no go here. Keyboard and display updates stop working quickly once in X, although the mouse is able to keep moving. This was with voluntary-preempt=2 this time.
Shane
A message that is not in the archive (sent off-list or not yet received): 1091246621.1677.71.camel@mindpipe
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1091296615.1677.283.camel@mindpipe
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 38 lines · Felipe Alfaro Solana
Quoted 12 lines · Lee Revell
Quoted 10 lines · Felipe Alfaro Solana
Quoted 5 lines · Lee Revell
Shane & Felipe,
I am removing LKML and Ingo from the cc: list so we can compare hardware, as I definitely am not seeing this problem. Maybe we can track it down to a difference there. What hardware are you guys using?
I'm running 2.6.8-rc2-bk9 plus a bunch of other patches, like Con's Staircase Scheduler and Ingo's voluntary-preempt (of course). Kernel is compiled with ACPI + APIC.
Quoted 5 lines
Hmm. Maybe it's an ACPI/APIC problem? I do not have these enabled. It could also be an interaction between some other patch you have.
Have you tried with 2.6.8-rc2-M5, without the other patches? Booting with acpi=off?
OK, OK :-) I've been running 2.6.8-rc2-mm1-M5 with ACPI but without APIC for more than ten minutes), compiling kernels, sending mails with Evolution and it hasn't locked up yet. Crossfingers. Should we report this to Ingo and Andrew?
Anyways, I'll keep on running this puppy to see if this behavior is consistent.
# grep . /proc/irq/*/*/threaded /proc/irq/11/eth0/threaded:1 /proc/irq/12/Intel 82801BA-ICH2/threaded:1 /proc/irq/14/ide0/threaded:1 /proc/irq/15/ide1/threaded:1 /proc/irq/1/i8042/threaded:1 /proc/irq/5/uhci_hcd/threaded:1 /proc/irq/8/rtc/threaded:1 /proc/irq/9/acpi/threaded:1 /proc/irq/9/uhci_hcd/threaded:!
Quoted 3 lines
# grep . /proc/sys/kernel/*_preemption /proc/sys/kernel/voluntary_preemption:3 /proc/sys/kernel/preemption:1
The next thing I was going to suggest was the software RAID. You appear to have a RAID 0 or 1 with one disk on irq14 and one on irq15. I am not sure how interrupts are handled by Linux IDE RAID, but it seems like this would be tricky. I bet the threading is screwing up the synchronization between the devices, and you end up with one waiting forever for the other - the possibilities for lockup are endless.
However, I have no idea what you would do about this. You could try making those irqs non-threaded, but you'd have to do it one at a time, and I would *definitely* expect weird stuff with one threaded and one not.
I will have to defer to someone with more kernel expertise.
Lee
Quoted 23 lines · Lee Revell
Quoted 19 lines
OK, OK :-) I've been running 2.6.8-rc2-mm1-M5 with ACPI but without APIC for more than ten minutes), compiling kernels, sending mails with Evolution and it hasn't locked up yet. Crossfingers. Should we report this to Ingo and Andrew?
Anyways, I'll keep on running this puppy to see if this behavior is consistent.
# grep . /proc/irq/*/*/threaded /proc/irq/11/eth0/threaded:1 /proc/irq/12/Intel 82801BA-ICH2/threaded:1 /proc/irq/14/ide0/threaded:1 /proc/irq/15/ide1/threaded:1 /proc/irq/1/i8042/threaded:1 /proc/irq/5/uhci_hcd/threaded:1 /proc/irq/8/rtc/threaded:1 /proc/irq/9/acpi/threaded:1 /proc/irq/9/uhci_hcd/threaded:!Quoted 3 lines
# grep . /proc/sys/kernel/*_preemption /proc/sys/kernel/voluntary_preemption:3 /proc/sys/kernel/preemption:1
Quoted 6 lines
The next thing I was going to suggest was the software RAID. You appear to have a RAID 0 or 1 with one disk on irq14 and one on irq15. I am not sure how interrupts are handled by Linux IDE RAID, but it seems like this would be tricky. I bet the threading is screwing up the synchronization between the devices, and you end up with one waiting forever for the other - the possibilities for lockup are endless.
No, I'm not using any kind of RAID (eiher HW or SW) at all. Simply, two identical, independent 120GB drives that only have one thing in common:
they are attached to the same IDE channel (the primary IDE channel). The CD/RW and DVD are attached to the secondary IDE channel.
Quoted 9 lines · Shane Shrybman
Twice while using -L2 my IBM PS2 keyboard has become completely non-responsive. USB mouse and everything else seems to be fine, but no LEDs or anything from the keyboard.
On both occasions the last key I hit on the keyboard was numlock and the numlock did not come on and I had to reboot after that.
UP, x86, gcc 2.95, scsi + ide, bttv
This happened to me, also twice necessitating a reboot. I am pretty sure I did *not* hit Num Lock last, though the system was under load - multiple builds going on, jackd running, and video playback. I tried to toggle Num Lock to see if the machine was really locked hard, and it worked for a while (though it did not go on/off exactly once for each time I hit it), then stopped responding.
This happened with the timer + soundcard IRQs direct, and with timer + soundcard + RTC direct.
Lee
Quoted 11 lines · Lee Revell
Quoted 9 lines · Shane Shrybman
Twice while using -L2 my IBM PS2 keyboard has become completely non-responsive. USB mouse and everything else seems to be fine, but no LEDs or anything from the keyboard.
On both occasions the last key I hit on the keyboard was numlock and the numlock did not come on and I had to reboot after that.
UP, x86, gcc 2.95, scsi + ide, bttv
Quoted 7 lines
This happened to me, also twice necessitating a reboot. I am pretty sure I did *not* hit Num Lock last, though the system was under load - multiple builds going on, jackd running, and video playback. I tried to toggle Num Lock to see if the machine was really locked hard, and it worked for a while (though it did not go on/off exactly once for each time I hit it), then stopped responding.
Did this happen with both the rc2-L2 and rc2-M5 kernels for you too?
Ingo, I have been running a previous version ( -I1 I think ) of voluntary-preempt patch successfully for a few days, so I think the problem was introduced since the -I1 version.
Shane
Quoted 20 lines · Shane Shrybman
Quoted 11 lines · Lee Revell
Quoted 9 lines · Shane Shrybman
Twice while using -L2 my IBM PS2 keyboard has become completely non-responsive. USB mouse and everything else seems to be fine, but no LEDs or anything from the keyboard.
On both occasions the last key I hit on the keyboard was numlock and the numlock did not come on and I had to reboot after that.
UP, x86, gcc 2.95, scsi + ide, bttv
Quoted 7 lines
This happened to me, also twice necessitating a reboot. I am pretty sure I did *not* hit Num Lock last, though the system was under load - multiple builds going on, jackd running, and video playback. I tried to toggle Num Lock to see if the machine was really locked hard, and it worked for a while (though it did not go on/off exactly once for each time I hit it), then stopped responding.
Quoted 2 lines
Did this happen with both the rc2-L2 and rc2-M5 kernels for you too?
Have not tried M5 yet (still building). An improved fix was posted for the PS/2 problem recently which uses a semaphore and work queues rather than Ingo's original quick fix of just adding a lock-break. If the problem is indeed keyboard-related, this may help.
I also have not determined whether the system freezes completely or whether it is just the input layer that hangs. Next time this happens I will try to ssh in.
Lee