Bug 66582 - cpqfc does not find drive(s) at boot
cpqfc does not find drive(s) at boot
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
2.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Coughlan
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-12 11:08 EDT by dnonno
Modified: 2007-11-30 17:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-25 10:14:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dnonno 2002-06-12 11:08:25 EDT
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
Comment 1 Tom Coughlan 2002-06-18 08:03:10 EDT
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.
Comment 2 Peter Bates 2002-09-11 11:55:18 EDT
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!

...

Comment 3 Tom Coughlan 2002-09-11 17:51:13 EDT
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...
Comment 4 Need Real Name 2002-10-09 14:38:48 EDT
I am having the same problem and I need to know if someone is working on it.
Thank you.
Comment 5 R P Herrold 2003-09-17 12:43:22 EDT
I am getting this the RHL 9, current kernel (kernel-2.4.20-20.9) as well
Comment 6 Tom Coughlan 2004-10-25 10:14:19 EDT
Cpmpaq/HP no longer maintains the cpqfc driver.  I suggest that you
continue to use the rmmod/insmod workaround for this problem.

Note You need to log in before you can comment on or make changes to this bug.