Bug 66582
Summary: | cpqfc does not find drive(s) at boot | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 2.1 | Reporter: | dnonno |
Component: | kernel | Assignee: | Tom Coughlan <coughlan> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2.1 | CC: | coughlan, herrold, robinson, soledad.escobar |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-25 14:14:19 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
dnonno
2002-06-12 15:08:25 UTC
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. |