Bug 176611 - Keyboard doesn't work after boot
Summary: Keyboard doesn't work after boot
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-12-27 15:57 UTC by Troels Arvin
Modified: 2012-06-20 13:23 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 13:23:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
ugly patch for the problem (1.40 KB, patch)
2007-02-16 15:01 UTC, greg hosler
no flags Details | Diff

Description Troels Arvin 2005-12-27 15:57:27 UTC
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.

Comment 1 Troels Arvin 2005-12-27 15:59:33 UTC
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.)

Comment 2 Troels Arvin 2005-12-27 16:19:07 UTC
Update: Using a USB keyboard works.

Comment 3 Troels Arvin 2006-01-23 08:24:56 UTC
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).

Comment 4 Pete Zaitcev 2006-01-23 21:35:50 UTC
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.


Comment 5 Leonard den Ottolander 2006-02-02 08:55:23 UTC
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).


Comment 6 Leonard den Ottolander 2006-02-02 09:02:39 UTC
The report that I meant (about the reboot issue) is bug #151119.


Comment 7 Troels Arvin 2006-02-05 14:28:46 UTC
I tried upgrading the PC's BIOS
(http://h18007.www1.hp.com/support/files/hpcpqdt/us/download/23213.html), but it
didn't help.

Comment 8 greg hosler 2007-02-16 15:01:04 UTC
Created attachment 148197 [details]
ugly patch for the problem

Comment 9 greg hosler 2007-02-16 15:05:09 UTC
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


Comment 10 Troels Arvin 2009-03-10 07:55:40 UTC
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.

Comment 11 Jiri Pallich 2012-06-20 13:23:11 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.