Bug 158327 - keyboard unresponsive after booting SMP kernel
Summary: keyboard unresponsive after booting SMP kernel
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: Jason Baron
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-20 15:27 UTC by Jeff Woods
Modified: 2013-03-06 05:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 16:19:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jeff Woods 2005-05-20 15:27:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Red Hat/1.0.3-1.4.1 Firefox/1.0.3

Description of problem:
When booting a Dell Precision 530 (dual processor workstation), I get the error:

i8042.c: Can't read CTR while initializing i8042

The boot continues normally, but the (PS/2) keyboard and (PS/2) mouse are unresponsive.

Version-Release number of selected component (if applicable):
kernel-smp-2.6.9-5.0.5.EL

How reproducible:
Always

Steps to Reproduce:
1. Boot the SMP kernel.
2.
3.
  

Actual Results:  Keyboard and mouse are unresponsive.

Expected Results:  keyboard and mouse should work.

Additional info:

This seems to be a duplicate of a number of existing bugs entered against Fedora, but I cannot find a solution to this problem.  I am working with RHWS 4.

Comment 1 Jeff Woods 2005-05-20 19:56:26 UTC
As a work-around, I can confirm that a USB keyboard and mouse work fine.

Comment 2 Jeff Woods 2005-05-20 19:57:34 UTC
Also works correctly if booted without the SMP kernel.

Comment 5 Gerald Teschl 2006-10-16 08:35:19 UTC
We have the same problem on all of our HP workstations. However it happens with
or without the smp kernel.

As a workaround we used to boot with "acpi=off" but the latest kernels
kernel-2.6.9-42.0.2.EL and kernel-2.6.9-42.0.3.EL will panic with this
option.

Another workaround is to type something while the kernel is booting, but
this isn't really an option for user workstations;-)

BTW, this seems a redhat only thing. I testet kunbuntu and knoppix which
both don't have this problem.


Comment 6 Jason Baron 2006-10-18 15:54:41 UTC
hmmm...are you suggesting that -42.EL boots fine with acpi=off?

Comment 7 Jason Baron 2006-10-18 22:16:50 UTC
i've also uploaded kernels to http://people.redhat.com/~jbaron/bz158327/i686/
which might address this issue. could you please test them. thanks.

Comment 8 Jason Baron 2006-10-24 22:13:18 UTC
any chance you can test these kernels? thanks.

Comment 9 Gerald Teschl 2006-10-26 12:42:19 UTC
(In reply to comment #6)
> hmmm...are you suggesting that -42.EL boots fine with acpi=off?

No, they panic immediately.

I will test your kernels. Thanks for your help.

Comment 10 Jason Baron 2006-10-26 17:35:42 UTC
ok. chaning to needinfo until i hear back about the test kernels. thanks.

Comment 11 Gerald Teschl 2006-11-02 14:23:10 UTC
Unfortunately kernel-2.6.9-42.19.EL.keyb.1 does not fix the problem.



Comment 12 Jason Baron 2006-12-05 23:23:41 UTC
can you please try passing "i8042.noacpi" on the command line for the
kernel-2.6.9-42.19.EL.keyb.1 and see if that fixes things?

thanks.

Comment 13 Gerald Teschl 2006-12-08 21:38:16 UTC
I don't have physical access to the boxes right now, but I booted with "i8042.noacpi"
and dmesg still gives me:

i8042: ACPI detection disabled
i8042.c: Can't read CTR while initializing i8042.

So I presume it is not working.

Comment 14 Gerald Teschl 2006-12-14 19:15:50 UTC
It is not working.

Comment 15 Jiri Pallich 2012-06-20 16:19:10 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.