From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Description of problem: Trying to install RHEL 4 (update 2) from ISOs downloaded (and verified) from RHN. Hardware: HP Business PC, model dc7600. Keyboard works at the boot prompt, i.e. I can enter "linux mediacheck", etc. However, as soon as the OS is running, the keyboard doesn't work. I cannot even turn num lock on/off. Consequence: I cannot get past any installation step which requires keyboard interaction. When booting on a recent Knoppix, I see the same problem: I can boot in to GUI mode (default) and use the mouse to start programs, etc. So I assume that the keyboard problems are not simply a result of a freezed system. Also tried: Booting on first CDs of FC4. Booting on first CD of RHEL update 1 (official CD-set). Neither allowed me past an installation step requiring keyboard interaction. Also tried: Unplugging+plugging keyboard cable (ps2-style). No luck. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Grab a "HP Compaq dc7600 Convertible Minitower" PC. 2. Try installing RHEL 4, or try "linux mediacheck", e.g. Actual Results: After the OS has booted during initial install phase, installation stops as soon as keyboard interaction is required. Additional info: I contacted HP Support (via their online support chat), but they say that only Windows is supported on the PC... When the PC is running Windows or FreeDOS, the keyboard works well.
By the way: I tried turning off hyper threading and "I/O APIC Mode" in the BIOS. No combination of these settings make a difference with regard to the keyboard problem. (One combination seemed to make Knoppix freeze totally; at least neither keyboard nor mouse worked in Knoppix' X mode.)
Update: Using a USB keyboard works.
The problem still exists after upgrading to kernel 2.6.9-22.0.2 (and temporarily switching the keyboard to a PS/2 connected one).
Right, maybe I should take over from Alan. The most likely culprit is the BIOS as usual. One possible cause may be that the board actually has a hardware i8042, but the BIOS decides to emulate anyway. The right fix would be a BIOS update. But in case it is not feasible, we may look for workarounds. Our handoff happens very early, before the PS/2 driver. Maybe that will make the problem go away on U3. I recommend testing U3 with "usb-handoff" option and see what happens. If that fails, then we'll try getting dmesg and so on... No guarantee though.
This is probably a widely know issue with the i8042 driver and the 2.6.9 kernel. I've never seen it being mentioned as being a BIOS problem but it could be. Issue is assumingly fixed in 2.6.13. On other AMD x86_64 boxes it causes reboot to fail. I thought I'd seen such a bug report in this bugzilla, but can't find it right now. There is a patch floating around that inverts the value of i8042_crt (http://www.ussg.iu.edu/hypermail/linux/kernel/0408.1/1500.html) but I'm not sure that is the fix used for 2.6.13. This is probably a dup of bug #158327 (as in not specifically related to SMP).
The report that I meant (about the reboot issue) is bug #151119.
I tried upgrading the PC's BIOS (http://h18007.www1.hp.com/support/files/hpcpqdt/us/download/23213.html), but it didn't help.
Created attachment 148197 [details] ugly patch for the problem
I'm doing some onsite training, and as luck would have it, I'm teaching a RHD236 kernel internals, and the customer has EXACTLY these pc's. This comment contains some additional information relating to the problem, some additional information about workarounds, and a patch (which doesn't really address the problem, but allows the device to work. First. Not every dc7600 will exhibit this problem. The problem ONLY happens on dc7600's that have USB keyboard, and usb mouse. Switching either the keyboard to USB, or the mouse to ps/2 eliminates the problem. Next. If you type on the keyboard just after the grub messages, as the kernel is initializing, teh problem goes away. As a corrollary, if you set a grub password, the problem also goes away. As an additional data point, if you just go into grub, and then boot from within grub, after typing something (I guess including "just the 'b'"), the problem ALSO goes away. Next. If you watch the kernel boot messages, you will see this line: i8042.c: Can't read CTR while initializing i8042. This is coming from drivers/input/serio/i8042.c, from initialization routine: static int i8042_controller_init(void) Next. I tried a U4 kernel. Problem still happens. So I then decided to explore the code a bit. The text that is failing is: if (i8042_command(&i8042_ctr, I8042_CMD_CTL_RCTR)) { This is apparently returning a non-zero return (I did not look to see what was being returned. I'll do that tomorrow.) I then inserted the following just before this line, and also just inside the conditional: unsigned char str; str = i8042_read_status(); printk(KERN_ERR "i8042.c: initializing i8042. Status reg: %02x\n", str); I then booted the patched kernel to see what reading the status register says. When I boot in a known successful configuration (USB mouse unplugged, teh status that is read from the controller is: 0x1d (I have no idea what the bit positions are) When I boot with the problematic settings (usb mouse plugged in), the status register returns 0x1c. And finally. If I simply ignore the error and continue, the keyboard will work as per normal. The attached patch basically updates the i8042.c file to 2.6.20 (which by itself does NOT fix the problem). This patch also prints out the status register, and also disables the return on error (i.e. it deliberately ignored the read error during module initialization). In general, that doesn't sound to me like a good idea (e.g. if the device doesn't exist, but perhaps that is filtered out earlier in the initialization?) (attachment is above, (id=148197) -Greg
I no longer have access to the system where I saw this problem. So from my point of view, the bug may be closed with status "gave up"/"discontinued", or whatever status is suitable; then someone else could re-open it if it's seen again.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.