Description of Problem: Cuystomer has an CPX 1204 SCAR SCSI card, which uses the symbios 53c875 SCSI chip... Installer hangs when loading module. The updated sym53c8xx driver located at: http://people.redhat.com/arjanv/rhl71/ncrsym/ Also fails, I am posting user's comments below and am Ccing hi on this bug. How Reproducible: Every time. Steps to Reproduce: 1. Boot from CD 2. Loading driver hangs.... 3. Actual Results: Can't boot kernel... Expected Results: Wanted to install 7.1 -- is currently running 6.2 Additional Information: 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? answer yes 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. K, thanks! Johnray
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. Tom Brooks
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 serial_number_at_timeout=135 <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 of RH7.1. 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? Regards, /Soren
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 are running. I will pester you again when I get in trouble. Thanks, /Soren
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! Tom Brooks SE MCG
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? Regards, /Soren
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 out. Thanks, Jason
y jason.corley: please file a separate bug; doesn't look like the same bug.
CLosing. VA ones sound like the 440GX affair, the others seem cured