Red Hat Bugzilla – Bug 122572
Installer hangs after attempting to load sym53c8xx SCSI driver
Last modified: 2015-01-04 17:05:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
With Fedora Core 2 test3, on an HP x4000 workstation (dual 1700MHz
Xeon), the installer hangs after displaying the message "Loading the
sym53c8xx SCSI driver". I tried this on two machines with the same
hardware. I also tried this using a minimal boot CD and the full disc #1.
I did not have this problem on this hardware with the test1 and test2
version of Fedora Core 2. Both of those versions installed successfully.
We also tried installing on an HP X4000 w/ dual 2400MHz Xeon. Same
Phoenix Bios version, same on-board symbios firmware version
(PCI-4.19.00). This installed correctly.
One other difference is the 2400 MHz system has an additional SCSI
interface (Adaptec) that loads its module prior to the sym53c8xx module
Perhaps there is some relation to SCSI-bus resets/timeouts?
Sym-chip is LSI53C1010R
Intel chipset: ICH2,860MCH,P64H>
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Insert Boot/Install CD #1
3.Hit return when prompted
4.Select US/English options
Actual Results: Screen says "Loading the sym53c8xx SCSI driver" and
Expected Results: Gone ont next step of install.
I found the same problem when I tried to install the official Fedora
*** Bug 124399 has been marked as a duplicate of this bug. ***
I see this error as well.
I have a Tekram Ultra 160 SCSI DC-390U3W SCSI controller, BIOS version
4-18.00. My PC currently runs Fedora Core 2 Test 2, and the sym53c8xx
module works fine. I originally installed Red Hat 8.0 in December
2002, and I've subsequently upgraded to Red Hat 9.0, then Fedora Core
2 Test 2 this spring, without any trouble.
My hard disk is a Quantum Atlas 10K II 18.4GB LVD/SE.
I own a Transcend TS-AKT4/A motherboard with VIA VT8363 KT133 chipset.
My CPU is AMD Athlon 1.0 GHz Socket A with 256 KB cache.
I get same problems - note that kernel logged messages are similar to
Bug 122476 on my system (I am not a an smp system).
This is preventing me install FC2 as my cdroms are SCSI drives.
I have attempted to do a boot from newer kernel eg latest 2.6.6 via
grub to initiate teh install but still no luck.
My system hangs on the Validation of my CDwriter, but before that my
CDreader runs through a number of bus resets etc as well but seems to
eventually recover to continue.
I managed to install FC2 on a server that has three SCSI adapters: two
Mylex cards (AcceleRAID 352/170/160 and eXtremeRAID 2000/3000; the
driver for both is DAC960) and one Symbios 53c1010 that uses
sym53c8xx. The OS is installed on an IDE drive that works without
problems. None of the SCSI adapters are detected during installation
and none show up in lspci or kudzu output. The DAC960 and sym53c8xx
modules can be loaded with modprobe once FC2 is up and running. The
modules do not give any error messages when they are loaded, by they
do not seem to see the SCSI devices at all either.
The kernel version is kernel-smp-2.6.6-1.435.2.3 running on a dual
PIII system with the ServerWorks CSB5 chipset.
Using the latest kernel-2.6.7-1.494.2.2 produces same problem. Lockup
on scsi CD-RW with same messages.
I have the same problem with a dual PIII 1GHZ Gateway 6400 server.
Motherboard is the OEM Asus CUR-DLS model.
Has dual symbios 53c1010 controllers onboard.
The module loaded is the 2nd version of sym53c8xx.ko along with other
necessary SCSI modules:
sym0: Symbois NVRAM, ID7, Fast-80, LVD, parity checking.
sym0: open drain IRQ line driver, using on-chip SRAM.
sym0: using LOAD/STORE-based firmware.
sym0; handling phase mismatch from SCRIPTS.
sym0; SCSI BUS has been reset.
Vendor: HITACHI Model: DK32CJ-18MC Rev: JBBB
Type: Direct-Access ANSI SCSI revision: 03
sym0:0:0 tagged command queing enabled, command queue depth 16
scsi(0:0:0:0): Beginning Domain Validation.
sym0:0 wide asynchronous.
sym0:0: FAST-80 WIDE SCSI 160.0 MB/s DT(12.5 ns, offset 62)
sym0:0:0 Abort operation started.
sym0:0:0 ABORT operatoin timed-out.
sym0:0:0 DEVICE RESET operation started.
sym0:0:0 DEVICE RESET operation timed-out
sym0:0:0 BUS RESET operation started.
sym0: SCSI Bus reset detected
sym0: SCSI Bus has been reset.
sym0:0:0 BUS RESET operation complete
sym0:0:0 ABORT operation started
sym0:0:0 ABORT operation timed-out.
sym0:0:0 HOST RESET operation started.
sym0: SCSI BUS has been reset
(and thats all folks, seems to hang here, think the kernel is
still running, but? )
Clarification of last post, had the same problem with install hang
on the Gateway 6400, so I built the SCSI disk in a different machine
and installed it in the Gateway, before doing so edited the initrd ?
file to load the correct SCSI modules (version 2 sym53c8xx.ko).
Made that kernel and init combination a separate selection in GRUB.
I was able to install and run Fedora Core 3 test 2 on my HP x4000
workstation without any problem, so it appears that the problem has
been fixed in a newer kernel.
I also have the HP x4000's deployed. I had this problem with the
Quantum Atlas 10KII hard drives, but not with seagate ST336607LW. We
can't kickstart these systems via PXE because of this.
Kevin Miller writes:
"so it appears that the problem has been fixed in a newer kernel."
I don't think it's fixed for all cases.
See my bug report Bug 137861 for a similar problem. I was not
able to boot an already installed and working FC3test3 system with
kernel-2.6.9-1.649. However, I discovered the problem was in the
source file sym_glue.c in its call to spi_dv_device(). This is
a call to a "domain validation" routine.
Read my explanation there. I also have a patch there which will
disable domain validation (no real harm in that). Now I can boot
with my sym53c825 and have not one problem. Domain validation should
only be implemented as a boot time command line option, and not
unconditionally as it is now.
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.