Bug 161094 - HP Netserver 8500 scsi mod load kudzu hang for sym53c8xx
HP Netserver 8500 scsi mod load kudzu hang for sym53c8xx
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Coughlan
Brian Brock
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-20 11:18 EDT by Odin Trisk
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-04 02:58:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Odin Trisk 2005-06-20 11:18:28 EDT
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
loading.

I believe the kernel has completed its module loading however kudzu does not
continue.

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


How reproducible:

Bootup on install disk 1, wait 2 minutes to get the problematic point.  This
point occurs before any language selection occurs.
Comment 1 Odin Trisk 2005-06-22 08:15:37 EDT
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 ?
Comment 2 Odin Trisk 2005-06-23 01:03:03 EDT
There is an issue apparently with "hald" reading PCI config space that can cause
card lockup.

http://lists.freedesktop.org/archives/hal/2005-May/002541.html

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
necessary driver.

The thread I quote above goes on to say that all^H^H^Hmost libsysfs usage
probably tickles this problem.
Comment 3 Odin Trisk 2005-07-08 20:06:29 EDT
A homebrew Kernel 2.6.12.2 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
to test.

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.
Comment 4 Dave Jones 2005-07-15 14:24:37 EDT
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'.

Thank you.
Comment 5 Odin Trisk 2005-07-15 14:57:46 EDT
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
another country.
Comment 6 Dave Jones 2005-07-15 18:37:24 EDT
yes, FC4 is based on a 2.6.12rc kernel.
Comment 7 Odin Trisk 2005-08-01 21:37:11 EDT
FC4 Disk1 hangs as well.  The kernel that is installed on the system that does
work is 2.6.12.2, so maybe there were changed between 2.6.12rc and 2.6.12.2 that
affect the driver ?

I no longer have the machine to do any more testing with, its been deployed into
service.
Comment 8 Dave Jones 2005-08-04 02:58:41 EDT
The latest errata for FC3/FC4 is based on 2.6.12.2, so if that worked for you,
chances are this got fixed.

Thanks.

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