From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
Description of problem:
On Intel SE7500BR2 motherboard (with dual Xeon 2.0GHz, 2GB memory)
multiprocessor kernel loose keyboard during boot. Console and dmesg
says several times:
pc_keyb: controller jammed (0x1D).
Same problem was with all previous Enterprise Linux 3 ES smp kernels
(no such problem with uniprocessor kernel) and on two servers
(identical hardware), tested both PS/2 and USB keyboard.
There was no such problem with RedHat Linux 8.0 on these servers.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Choose smp kernel from grub bootloader
Actual Results: During kernel boot see 'pc_keyb: controller jammed'
messages, keyboard hangs (can not change any status LED)
Intel SE7500BR2 server motherboard (with latest BIOS)
dual Xeon 2.0GHz
4x512MB PC2100 ECC memory
sym53c1010-66 SCSI controller
4x36GB Hotswap Scsi
RedHat Enterprise Linux 3 ES update 1
I also have the same motherboard and am having the same issue.
Normal kernel works fine .. smp kernel gets jammed keyboard error.
OK I have my dual desktops working now...
I actually have the (SE7505VB2 intel motherboard w/latest bios).
If you go into the bios and turn off usb 1.1 and boot up with smp
kernel kudzu will ask to remove the configuration for root usb and 4
I removed the configuration, then rebooted into smp kernel, Kudzu
re-detected the root usb and 4 usb hubs and that was it.
Funny thing is, that if I put the bios back to the default
configuration and reinstall os again, the problem doesnt happen
We have been having very similar issues with Supermicro 1U's - 2 Xeon
CPUs, SCSI Controllers (either Adaptec or 3Ware), and USB keyboard.
When using the SMP kernel with RHEL 3 or 3 Update 1, and "Legacy USB
Support" on in the BIOS, sometimes I see the exact same error messages
concerning "pc_keyb: controller jammed (0x1D)" - but, if I see the
errors, the system seems to continue the boot and eventually all is OK.
However, sometimes the boot hangs - just before one of these messages
would be seen (if it were to continue booting). If I turn off the
"Legacy USB Support", I don't see the problems. If I use the UP
kernel, I don't see the problems. If I use an older version of Red
Hat (such as 7.3 or 9), I don't see the problems. If I use an IDE
based system (i.e. non-SCSI), I don't see the problems.
Any thoughts or comments ? Thanks ...
*** Bug 114202 has been marked as a duplicate of this bug. ***
Any status on this BUG? If is really bad for us here. We see this
exact same problem on our Supermicro boards (multiple models). Most
often we have to reboot the system many times to get it to come up. We
have two problems 1) Hang just after Hugetlb is displayed on the screen
[when it does pass this, next message is the keyboard jammed] or 2) We
boot up with many keyboard jammed messages and have not keyboard in
filesystem check or kudzu. After it boots all the way we usually have
the keyboard, but I would say 15% of the time we do not.
All systems are SCSI based Raid systems.
All systems are running the latest BIOS from Supermicro.
This happend with all version of the Enterprise 3 system (U1, U2 and
I also have this problem and am currently working around by disabling
"Legacy USB Support" from the BIOS.
PROBLEM: as mentioned above in SMP mode.
RedHat Enterprise ES 3 U3 (had problem with U2 also)
SuperMicro X5DPI-GG (Motherboard)
3.06 GHz Xeon ( Dual ) w/ Hyperthreading Enabled
2 GB ECC Memory
3Ware 9500 SATA RAID Controller ( boot device )
It looks that SMM gets involved, althogh I do not discount a plain old
bug in pc_keyb.c somewhere.
Aldo, Rod, Brett: please reboot with kernel parameter "usb-handoff".
Let me know if it fixes things.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.