From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 Description of problem: Advanced Server is install on a Compaq Proliant DL380 which is attached to a Compaq RA4100 SAN. The system does not find drives on the array at boot-up. If I rmmod the cpqfc module and insmod the cpqfc, then drives are found. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Reboot 2.cat /proc/scsi/scsi (no drives shown) 3.rmmod cpqfc 4.insmod cpqfc 5.cat /proc/scsi/scsi (drives are shown) Additional info: As a work-around, I have placed the following in /etc/rc.d/rc.local: rmmod cpqfc insmod cpqfc service cluster stop service cluster start
I took a look at the system log files, and I can see that there is apparently a race. In the successful case (an insmod after the system is up), the cpqfcTS starts to initialize, then there are a series of messages like the following for each port on the FC switch: kernel: PDISC Request from unknown WWN kernel: cpqfcTS: New FC port 000055h WWN: 500508B200505CA4 SCSI Chan/Trgt 0/0 Then the cpqfcTS finishes initializing, and the midlayer configures the SCSI LUNs with "Attached scsi disk sda at scsi0...". In the failing case (during boot), the cpqfc seems to finish initializing (gets through "GBIC detected...") without finding any SCSI targets. Then, very soon but apparently too late, the messages about "PDISC" and "New FC port" are printed. The Linux SCSI midlayer never configures the disks. I noticed that file drivers/scsi/cpqfc.Readme says: ---- Due to Fabric/switch delays, driver requires 4 seconds to initialize. If adapters are found, there will be a entries at /proc/scsi/cpqfcTS/* ---- It may be that when the system is booting the PDISC interaction with the FC switch is delayed, and so the devices are not configured automatically. I have sent this information to a person at Compaq/HP and am awaiting a reply.
Did you ever receive a reply from Compaq/HP about this issue? I'm currently encountering exactly the same problem with RH 7.3, and had reached the same conclusion regarding a fix, but trying to insmod cpqfc to mount the disks after boot isn't very useful if you're trying to actually boot off the SAN equipment in question! ...
No I never got a reply from Compaq. This appears to be a bug in their driver, and the comment in their Readme indicates that they are probably aware of it. I'll need to try again to get in touch with the right person there...
I am having the same problem and I need to know if someone is working on it. Thank you.
I am getting this the RHL 9, current kernel (kernel-2.4.20-20.9) as well
Cpmpaq/HP no longer maintains the cpqfc driver. I suggest that you continue to use the rmmod/insmod workaround for this problem.