Hide Forgot
# 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.
reassign to ia64 maintainer
Confirmed on Taroon-re0610.nightly ia64 (only on hpzx2000)
Confirmed on Taroon-re0612.A4.0 ia64 (only on hpzx2000)
What output do you get at the EFI shell when you type "info fw"?
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
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?
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.
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.
status?
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.
Doesn't look like firmware update will be available in time to test before B1 release; Moving to B2 blocker list.
closing due to inactivity
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.
no new info since early june...... this bug appears dead and it's not even known if it is still an issue. Reducing severity
if this does not get some forward motion we're going to have to close it
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
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.