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
Seen it on different systems
Steps to Reproduce:
1. Install Hampton (kernel 2.4.18-3) onto the PE4600 onboard scsi controller
2. Boot the smp kernel
3. system will hang when aic7xxx starts to load
To boot to smp kernel.
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
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
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
Fixed in Milan beta 3