Red Hat Bugzilla – Bug 51484
sym53c8xx fails to load when booting the installer...
Last modified: 2007-04-18 12:35:44 EDT
Description of Problem:
Cuystomer has an CPX 1204 SCAR SCSI card, which uses the symbios 53c875
Installer hangs when loading module. The updated sym53c8xx driver located
Also fails, I am posting user's comments below and am Ccing hi on this bug.
Steps to Reproduce:
1. Boot from CD
2. Loading driver hangs....
Can't boot kernel...
Wanted to install 7.1 -- is currently running 6.2
Here are user comments on updated driver:
I built the floppy and did both the "linux dd" and the "text dd" both with
the same results:
boot: text dd
You get a dialog box that asks Do you have a driver disk?
Insert your driver disk and press "OK" to continue.
Then you get a loading sym53c8xx message
Then you get the old loading sym53c8xx message and you hang indefinitely.
Difference is now you never time out.
Any chance this is a motherboard with a 440GX chipset ?
The Cpu complex is CPCI a Motorola Computer Group CPV5350. This card has a
Mobile Module MM2 PII as the CPU and a Southbridge of a PIIX4 82371EB. I have
built the Driver Floppy using the x686 gzip image according the the problem
report instructions. When I boot the system using the CD I type in either "text
dd" or "linux dd" as per the instructions. I get a response in the form of a
dialog box that indicates the driver floppy is being loaded. Right after that I
get a different dialog box that indicates that the same named driver is being
loaded and the CD access light indicates that it is being loaded from the CD.
After this a steady access to the CD blip occurs about every half second
forever. If I do not load the driver disk, I get essentially the same result
except that after a couple of minutes the installation will proceed, however,
the SCSI disk and the SCSI CD are nolonger an option. I have to choose from
FTP, HTTP, or NFS.
I have a similar problem on a machine I have. My controller is SYM53C875.
(I added this same comment to bug #37712 before I found this bug. The comment
probably fits better with this bug)
Linux tries to load the driver and eventually fails with a timeout.
I get the following in one of the log windows:
<4>scsi: Aborting command due to timeout : pid 0, scsi 0, channel 0, id 6, lun
0 0x12 00 00 00 ff 00
<4>sym53c8xx_abort: pid=0 serial_number=10 serial_number_at_timeout=10
<4> SCSI host 0 abort (pid 0) timed out - resetting
- The following lines are repeated over and over with only the serial_number
and serial_number_at_timeout values changing.
<4>sym53c8xx_reset: pid=0 resetflags=2 serial_number=133
<6>sym53c876-0: restart (scsi reset).
<4>sym53c876-0: Downloading SCSI SCRIPTS
<4>SCSI host 0 abort (pid 0) timed out - resetting
<4>SCSI bus is being reset for host 0 channel 0
I am seeing the same problem with an Asus SCSI card PCI-SC875 which uses the
symbios logic 53c875 chip.
I used to run RH6.2 without problems, but get a kernel panic during the install
I belive that RH6.2 was using the ncr53c8xx driver, not the sym53c8xx driver,
but I am not sure.
Ok, so now I have a redhat 7.0 system, with a 2.4.10-pre11 kernel running (the
latest I could get) and it does not have any problems (I have only been testing
for a day), so now I would like to install redhat 7.1.
How do I make an install disc that uses a custom kernel. I have been looking on
redhat's website for a HOWTO make the installation disc but to no avail. Does
anybody know how to make such a thing?
That's not trivial; basically you need to make a new kernel rpm (or take one
from the beta or from rawhide) and then make a new ISO set (which makes new
install images too). See the anaconda-runtime package for more info on that.
OK, I could not find any documentation on the anaconda thing, but
I took a look at the source, and it looks like a fairly simple thing
to do, so I will give it a try -- I REALLY need this box to be
running RH7.1 since it is what the rest of the production boxes
I will pester you again when I get in trouble.
All thanks for your attention to this matter. As is often the case when an OS
works with a set of hardware and another one does not the test casts a doubt
about the OS that is not working. What I have just proven today (9-20-01) is
that there is a hardware bug when doing D64 CPCI transfers in the MCG CPX1204
chassis. We, MCG, are looking into the root cause now. I do know that if I make
a hardware cut-and-jump to disable CPCI 64 bit transfers LINUX 7.1 will load
and run just fine.
At this point I believe that it is safe for RedHat to close this bug report as
I believe the indications are clear it is not a software issue.
Thanks for your help!
Well there might be hardware problems around, but the 2.4.3 kernel has problems
with some ncr/symbios based controllers, and it appears to be a kernel bug, not
a driver bug, and it appears to be fixed in what will become 2.4.10.
IBM has been reporting similar problems on their servers, even Alpha machines
have shown the same problem, and it appears that some of the recent kernel
changes has fixed the problem, but it is still not possible to install RH7.1
on these machines.
I understand if RedHat does not want to release a boot image that does not pass
their reliability tests, but I think this bug (or another one/a new one that
deals with the same problem) should remain open, untill it is fixed.
Given the summary to this bug, it might make sense to close this and open a
new one. Anyone?
I have the same problem mentioned by the Novell engineer earlier in the
comments. I have a bunch of VA Linux 1220s that were running the VA version of
Red Hat 6.2 which I'm trying to upgrade to Red Hat 7.2. It gets SCSI timeouts
when probing the sym53c1010-33 controller. I've tried to manually load the
older ncr53c8xx module as well as the generic ncr driver, all to no avail. When
I called Red Hat support they referenced this bug and told me someone was
working on it. I'm just attaching my name to this so I'll know when a fix comes
y firstname.lastname@example.org: please file a separate bug; doesn't look like
the same bug.
CLosing. VA ones sound like the 440GX affair, the others seem cured