From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
When attempting to boot, the sym53c8xx SCSI module is loaded.
During initialization, domain validation fails. The sym53c8xx
module is uninitialized and boot fails with a panic of not being
able to find root partition. It appears similar to Bug 122572.
See below for patch to driver which provides a fix for this problem.
Chip sym53c825, device id 0x3, revision id 0x2
At PCI address 0000:01:08.0, IRQ 11
Min. period factor 25, Wide SCSI BUS
Max. started commands 448, max. commands per LUN 64
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: SX423451W Rev: 9E21
Type: Direct-Access ANSI SCSI revision: 02
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Attempt to boot kernel with sym53c825 controller with
LSI 4.18 SCSI BIOS, no nvram, and 23 Gigabyte Seagate
SX423451W. Initrd loads the following list of modules
(in this order) during boot:
Actual Results: Domain validation errors flood the console
screen, eventually stopping. The jbd and ext3 modules are then
loaded from initrd but the kernel panics when it can't mount root
Expected Results: Fedora boots and produces login prompt.
"Domain Validation" is the probing of the scsi bus to verify
that it can handle its design speed. SCSI specs only define DV
for Ultra3, Ultra160, and Ultra160+ SCSI. DV is undefined for
earlier versions of SCSI such as SCSI 1 and SCSI 2, and may
produce unexpected results in those cases (such as mine).
In truth, DV provides no benefit to correctly engineered working
systems. The only benefit of DV is for high SCSI speed systems
with poor bus termination or poor cabling. In such cases, DV
will reduce bus speed in order to establish communication.
In effect, DV is a sort of kludge work-around for hardware
problems. It is no substitute for correct engineering practices.
The Linux sym53c8xx driver has a long history of reliable
operation (which I can personally vouch for). All the NCR/Symbios
8xx drivers are now unified under the 2.6.x kernels. This
one driver is supposed to handle the whole gamut of sym53c8xx
controller chips from the earliest to the latest.
Unfortunately, automatically enabling domain validation, (instead
of making it a special feature with a boot time command line
option), defeats the purpose of general purpose unified device
driver. And as most literature on the subject correctly points
out, DV is not useful for single ended SCSI or for systems with
bus speeds of 20 MHz or less.
Until such time that a boot time option is provided, I suggest
the following patch which fixes the problem. This causes no
change in behavior other than disabling domain validation for
the sym53c8xx driver. Since the sym53c8xx driver only calls DV
during initialization anyway, disabling it will in no way affect
post-initialization driver behavior.
Those who own broken high speed hardware and wish to throttle
back SCSI bus speed can still manually choose their SCSI bus
speed with the existing sym53c8xx "sync:" command line option
at boot time.
---------------------- cut here 8< -----------------------------
diff -udwr linux-2.6.9-original/drivers/scsi/sym53c8xx_2/sym_glue.c
2004-11-02 02:50:50.447399288 -0500
2004-11-02 01:23:24.000000000 -0500
@@ -1118,8 +1118,15 @@
lp->s.scdev_depth = depth_to_use;
sym_tune_dev_queuing(np, device->id, device->lun, reqtags);
+ * Uncomment this if you have Ultra160 or Ultra3 SCSI
+ * and you would like to enable domain validation.
+ * Domain validation is not defined for earlier versions
+ * of SCSI and may or may not work. You have been warned.
Please fix this bug. Many scsi drives (my Atlas Quantum 18 for
example) do not support DV. This caused me no end of grief in
attempting to upgrade to FC2 from RH9.
(In reply to comment #1)
> Please fix this bug. Many scsi drives (my Atlas Quantum 18 for
> example) do not support DV.
I'm finally able to boot FC3 without any special hacks to the kernel.
Since the release of kernel 2.6.11-1.35 for FC3, I've been able
to boot FC3 without any problems. On FC4, kernels 2.6.11-1.1369
and 2.6.12-1.1387 work fine as well.
FC3: 2.6.10-1.741 FAILURE
2.6.11-1.27 ??? (untested)
FC4: 2.6.11-1.1369 SUCCESS
I hope others have the same new found success. Whatever the bug was,
for me it first appeared late in FC2 cycle, and remained through FC3
until the release of kernel 2.6.11-1.35.
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'.
ignore previous comment, it happened as part of a mass-update.
I'll close this based on your previous comment.
Thanks for testing.