Red Hat Bugzilla – Bug 175767
Installer appears to hang when loading mptbase module
Last modified: 2007-11-30 17:07:09 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: When installing the SCSI driver mptbase the system looks like it is hung. Using Alt+LeftArrowKey I get to the virtual terminal. There I see the system scrolling messages. Fusion MPT base driver 2.06.16.01 Copyright (c) 1999-2005 LSI Logic mptbase: Initiating ioc0 bringup mptbase: ioc0: WARNING - Unexpected doorbell active! mptbase: ioc0: ERROR - Doorbell ACK timeout (count=499), InitStatus=ffffffff! mptbase: ioc0: WARNING - ResetHistory bit failed to clear! mptbase: ioc0: ERROR - Diagnostic reset FAILED (ffffffffh) mptbase: ioc0: NOT READY WARNING! mptbase: WARNING - ioc0 did not initialize properly! (-1) It goes through the same as above for ioc1, ioc2, ... Version-Release number of selected component (if applicable): Kernel-2.4.21-38.EL How reproducible: Always Steps to Reproduce: 1. Using the HP viper xw9300 hardware platform 2. Install RHEL3-U7-re1209.1 base distro that uses 2.4.21-38.EL Kernel Actual Results: System looks to be in a hung state while trying to load the mptbase driver. If you wait long enough (15 -20 min) the system will continue. But it failes to load the SCSI mptbase driver. Expected Results: RHEL-3 U6 installs this module and installs correctly. Additional info:
Created attachment 122246 [details] Sceen shot of the problem.
Just FYI: x86_64 kernel in viper with onboard MPT card -- works i386 kernel in viper with onboard MPT card -- fails i386 kernel in viper with add-on MPT card -- fails x86_64 kernel on non-HP (non-nVidia chipset) with add-on MPT card -- works i386 kernel on non-HP (non-nVidia chipset) with add-on MPT card -- works So it appears to be limited to MPT cards on the Viper when running the i386 kernel.
The removal of linux-2.4.21-fusion-backup-20511.patch should not have any effect. That is the old "backup" driver. It has a different name and is not loaded by default. I confirmed that it is not being loaded on the console log of a failing and a passing machine. Both are loading the current driver (which has not changed in U7, BTW). I am doing a kernel rebuild on beehive now.
Created attachment 122425 [details] .8 agp patch I went back through the 2.4.21-37.* kernels until I found the first one that fails: kernel-2.4.21-37.7.EL.i686.rpm - works kernel-2.4.21-37.8.EL.i686.rpm - fails The patch in .8 that seems to have caused the problem is: * Wed Nov 2 2005 Ernie Petrides <petrides@redhat.com> kernel-2.4.21-37.8.EL - add detection of PCI peer bridges on x86 for AGP tunnels (Brian Maly) When I remove this patch from .8, it boots on this box. Note that, according to Ernie's patch tracking file, some additional hunks were added to this patch in -37.9.EL to fix pci-pc.c build warnings. These do not appear to be relevant, since the failure first occurs in -37.8, and persists in -37.9 and -38. The exact patch that I backed out to get the system to boot is attached.
A fix for this problem has just been committed to the RHEL3 U7 patch pool this evening (in kernel version 2.4.21-39.EL).
*** Bug 179168 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0144.html