Bug 90716 - [ia64] pc_keyb: controller jammed (0xFF)
Summary: [ia64] pc_keyb: controller jammed (0xFF)
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: ia64 Linux
medium
medium
Target Milestone: ---
Assignee: Anil S Keshavamurthy
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-12 20:13 UTC by James Laska
Modified: 2007-11-30 22:06 UTC (History)
8 users (show)

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: ---


Attachments (Terms of Use)

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 Product and 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.


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