Bug 90716

Summary: [ia64] pc_keyb: controller jammed (0xFF)
Product: Red Hat Enterprise Linux 3 Reporter: James Laska <jlaska>
Component: kernelAssignee: Anil S Keshavamurthy <akeshava>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: glen.foster, grgustaf, jturner, kaccardi, lwoodman, peterm, petrides, sdenham
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:36:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Laska 2003-05-12 20:13:09 UTC
# TREE Taroon-re0512.A3.0.ENT
# ARCH ia64

During an install on an hpzx6000 ia64 machine, when the installer kernel is
booting I see the following message repeated a zillion times to the console:

pc_keyb: controller jammed (0xFF).
pc_keyb: controller jammed (0xFF).
pc_keyb: controller jammed (0xFF).
pc_keyb: controller jammed (0xFF). <--- repeats 1.2 zillion times
pc_keyb: controller jammed (0xFF).
Keyboard timed out[1]


Then, loader runs, loads necessary modules, and then the installer appears stuck
on the hardware ddcprobing section.  This does not happen on the other arches. 
It seems to have started on the Taroon-re0506 tree however it may have been in
earlier Taroon trees since I did not do installer testing prior to that.  This
machine has a usb keyboard+mouse.  I was not pressing keys at any time during
the boot cycle.

Comment 1 Rik van Riel 2003-05-14 14:55:34 UTC
reassign to ia64 maintainer

Comment 2 James Laska 2003-06-10 17:31:21 UTC
Confirmed on Taroon-re0610.nightly ia64 (only on hpzx2000)

Comment 3 James Laska 2003-06-13 21:17:42 UTC
Confirmed on Taroon-re0612.A4.0 ia64 (only on hpzx2000)

Comment 4 Glen A. Foster 2003-06-23 15:21:48 UTC
What output do you get at the EFI shell when you type "info fw"?

Comment 5 James Laska 2003-06-23 15:56:35 UTC
FIRMWARE INFORMATION

Firmware Revision: 80.10 [4216]

PAL Revision: 6.12

SAL Spec Revision: 50.10
SAL A Revision: 2.00
SAL B Revision: 50.10

EFI Spec Revision: 1.10
EFI Intel Drop Revision: 14.56
EFI Build Revision: 1.22

POSSE Revision: 0.09

ACPI Revision: 7.00

BMC Revision 0.16
IPMI Revision: 1.00
SMBIOS Revision: 2.3.2a
GSP Revision: 100.107


Comment 6 Glen A. Foster 2003-06-23 16:03:44 UTC
Oh my, the firmware is very, very old on this box.  Where is the system 
physically located, whom is the best contact for upgrading this box, and how 
best to get in touch with them?

Comment 7 Jay Turner 2003-06-23 16:17:34 UTC
The system is physically in Centennial (HQ) and I'll be the contact for getting
the firmware upgraded.  We should probably get the latest firmware on all of our
zx1 systems, as I doubt that much has been done since we received them.

Comment 8 Glen A. Foster 2003-06-23 16:34:25 UTC
It'll take a little while to pull together the instructions for the 
various firmware upgrades -- the Everest server (rx5670) has a different
set of firmware than the Wilson Peak (zx2000) and Longs Peak (rx2600 or
zx6000 -- depending on server or workstation, respectively).

I'll let you know when/where the ISO is available.  You can assign this
to me, or set the defect in NEEDINFO if needed.

Comment 9 Matt Wilson 2003-07-07 18:40:31 UTC
status?


Comment 10 Glen A. Foster 2003-07-07 18:55:42 UTC
Was out on vacation last week, and am pulling together explicit recipies for 
firmware upgrades -- between some version upgrades, very explicit things have 
to be done and I'm checking out all the docs before sending the code along.

Comment 11 dff 2003-07-10 21:56:19 UTC
Doesn't look like firmware update will be available in time to test before B1
release; Moving to B2 blocker list.

Comment 12 Arjan van de Ven 2003-08-15 21:41:20 UTC
closing due to inactivity

Comment 13 Jay Turner 2003-08-18 14:34:24 UTC
Reopening, as we still need firmware updates from HP in order to determine if
this issue is resolved with new firmware.  Appears that HP is waiting on an
inventory from Westford.

Comment 14 Arjan van de Ven 2003-08-18 15:15:47 UTC
no new info since early june...... this bug appears dead and it's not even known
if it is still an issue. Reducing severity

Comment 15 Matt Wilson 2003-09-15 14:51:21 UTC
if this does not get some forward motion we're going to have to close it


Comment 16 Glen A. Foster 2003-09-15 14:57:02 UTC
Adding Sue Denham to the cc: list.  This is a very old issue.

AFAICT, we are still waiting for the serial-number and firmware revision
inventory of the systems in Boston, so we know WHAT to put on the ISO image with
the firmware.  If Red Hat wants to close this bug, get the inventory containing
Model #, Serial #, and output of "info fw" at the EFI shell for each HP-IPF box,
and we'll construct whatever FW ISO image is needed to get all systems updated

Comment 18 RHEL Program Management 2007-10-19 19:36:14 UTC
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:
http://www.redhat.com/security/updates/errata/
 
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.