Red Hat Bugzilla – Bug 161094
HP Netserver 8500 scsi mod load kudzu hang for sym53c8xx
Last modified: 2007-11-30 17:11:08 EST
Description of problem:
Stage 1 install hangs during (what I believe to be) kudzu loading kernel modules
for detected hardware. Hangs during loading of "sym53c8xx". Hardware is a
Netserver LXR 8500 with dual on-board SYMBIOS SCSI busses.
If I Alt-F3 I can see the first chipset detection and the SCSI drive detection
occur in the bus0, then it goes on to detect devices on 2nd chipset+bus and it
ends with the line:
???????? SCSI BUS has been reset.
Then nothing further happens. The install process does not complete the module
I believe the kernel has completed its module loading however kudzu does not
I believe this to be a regression as I believe previous versions of Linux and RH
were able to be install onto this hardware. However I can not cite any specific
version at this time.
Version-Release number of selected component (if applicable):
Fedora Code 3
Bootup on install disk 1, wait 2 minutes to get the problematic point. This
point occurs before any language selection occurs.
How can I pass sym53c8xx="" options to the installer module loader ?
I am thinking of trying: sym53c8xx="verb:2 debug:65535"
Does adding to the regular LILO kernel options do the trick ? I would not think
so as the module loading occurs later on and the modules options come from
/etc/modules.conf at that point in time ?
Another work around I maybe trying is to install the OS on another PIII SMP
class computer, compile install grade the kernel to see if its specific with 667smp
What are your recomendations to me to provide a work around / bug fix ?
There is an issue apparently with "hald" reading PCI config space that can cause
I site this so that maybe it is related, since the kernel seems to complete the
SCSI bus RESET before the install process stops and at this point in the install
process (module loading) I believe FC to be employing some sort of hardware
detection system to have found I have SYMBIOS hardware and then load the
The thread I quote above goes on to say that all^H^H^Hmost libsysfs usage
probably tickles this problem.
A homebrew Kernel 126.96.36.199 compiled with the /boot/config-2.6.9-667smp options
boots up find with this machine. Maybe its specific to 2.6.9.
I installed the OS in another similar spec computer (P3 SMP, SCSI based)
computer, installed a bunch of newer homebew kernels and transfered the HDD over
This issue is closed from my side, but I can't retest it for you unless there is
a new boot image made with a newer kernel for FC4 or something. I have in my
office for another 3 weeks to do that, then it gets deployed.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
Sorry my problem was the original FC3 Disk1 hung on bootup (before the install
process). There is no way to upgrade the kernel as the system is not installed yet.
I presume there is only ever one version of the FC3 Disk1, meaning that you dont
update/rebuild the master Disk1 with a new kernel version? So its no good to
test with. As the updates you talk about are packages updates after the initial
install is completed.
If you can confirm to me that the FC4 Disk1 uses a newer kernel version than
2.6.9, I will give that a try for you.
Otherwise I suspect the first version I can test with will be FC5, but I only
have the machine in my office for another week, then its being shipped to
yes, FC4 is based on a 2.6.12rc kernel.
FC4 Disk1 hangs as well. The kernel that is installed on the system that does
work is 188.8.131.52, so maybe there were changed between 2.6.12rc and 184.108.40.206 that
affect the driver ?
I no longer have the machine to do any more testing with, its been deployed into
The latest errata for FC3/FC4 is based on 220.127.116.11, so if that worked for you,
chances are this got fixed.