Description of Problem: Hampton smp kernel (2.5.18-3smp) hangs the system right after it starts to load the aic7xxx driver on PE4600. Version-Release number of selected component (if applicable): Hampton smp kernel 2.4.18-3smp How Reproducible: Seen it on different systems Steps to Reproduce: 1. Install Hampton (kernel 2.4.18-3) onto the PE4600 onboard scsi controller (7899) 2. Boot the smp kernel 3. system will hang when aic7xxx starts to load Actual Results: Systme hangs Expected Results: To boot to smp kernel. Additional Information: I saw this on two systems so far. When the old aic7xxx (aic7xxx_old) driver is used in initrd, the system boots fine. I was not able to reproduce this issue on other PE4600 with the same configuration.
Does the 4600 use the 450NX motherboard chipset? If so, try passing the option aic7xxx=no_probe to the new aic7xxx driver and see if that solves the problem.
I added "options aic7xxx=no_probe" line right after the "alias scsi_hostadapter aic7xxx" line in /etc/modules.conf, remake the SMP initrd image, rebooted to this new SMP image, and the problem still exists.
System is NOT 450NX based.
Tried a few things: Hampton Beta3 and Pensacola gold works. Hampton Beta4 and Gold have this issue. 2.4.18-3.1smp kernel also shows this issue. The motherboard rev that is failing is A06.
Does Dell have contacts with Adaptec? We upgraded the driver rather late on the urgent request of Adaptec......
Created attachment 56305 [details] Driver Update Diskette for aic7xxx 6.2.7 under RH7.3 GM
There are two issues with 6.2.5 that we are aware of that might be causing this problem. 1) On certain fast machines (we only know of one and have not replicated this locally), the method used to reset the SCSI controller can allow chip accesses before the controller is ready to handle them. 2) The io_request_lock is aquired by the SCSI mid-layer prior to calling into the aic7xxx driver's detect routine. Under PPC, some of the PCI methods the driver calls may also acquire spinlocks. Should any spin-lock acquisition fail, the result would be a hang. It may also be that under x86, there are some bits of code the driver calls into that also suffer from this issue. Unfortunately, the semantics of the io_request_lock are not well defined. In this case, only drivers with new error recovery have their detect routine called with the io_request_lock held. Both of these issues are resolved in 6.2.7. For number 2, the driver simply drops the io_request_lock in its detect routine and reacquires it prior to calling back into or returning to the SCSI mid-layer.
The issue occurs with the secondary scsi controller AIC-7890. The primary scsi controller AIC-7899 works fine when the secondary controller is disabled from BIOS. I set the primary controller as ROMB (RAID0), installed, booted to smp, insmod aic7xxx, and the system didn't hang.
The driver disk seems to fix the issue (at least my initial test indicates that).
Fixed in Milan beta 3