James.Smart@xxxxxxxxxx wrote:
currently I'm trying to use the new transport_fc to read the
very often changing FibreChannel configuration in a test system.
To avoid a growing list of consistent binding entries (which
make no sense in this special case), I tried to switch off this
feature by
"echo none > /sys/class/fc_host/host1/tgtid_bind_type"
Unfortunately, the system stalls immediately, I guess the reason
is store_fc_private_host_tgtid_bind_type() calling
fc_rport_terminate() while holding host_lock.
Yep. A rather blatant lock bug that slipped through due to testing
on a non-smp box. Try the attached patch.
Thank you, it works fine.
If I understand the code correctly, even if tgtid_bind_type
would work correctly, still the rport-nummer and scsi-target-id
would count up on configuration changes. In the lpfc-driver, I
saw:
#define MAX_FCP_TARGET 256 /* max num of FCP
targets supported */
Will this result in problems after 256 configuration changes?
If so, what could I do?
Yes, it will. Once the target id assignment became larger than 256,
scsi scans won't see the remote port.
I admit, a more difficult implementation is possible if this is a
goal. In general, a production system will always manage devices
by wwpn assignments, and will usually use fabric zoning to minimize
it's view. Thus, a configuration such as yours, with high variability
in the fabric, is unusual.
I'm open to a different implementation if deemed necessary.
Meanwhile I understood, that using "port_id" instead of "none"
does the trick for us. Now the scsi target numbers are restricted to
the number of fabric-ports used in the test. That always is less than
256 in our configuration.
So, for me there is no need to change anything.
BTW: My Emulex boards do not recognize a change behind the
FibreChannel switch. So I force them to scan the configuration
using "echo [01] >/sys/class/scsi_host/host1/board_online".
Is there a better way to do this?
This is an issue worth noting. The lpfc driver registers for RSCN
events, so it should be seeing changes. There could be switch issues
in not posting the RSCN's (rare, long-time ago). The driver does
qualify it's nameserver request by FC4 type of FCP. Is the device in
question registering as an FCP type device with the fabric ?
Please follow up on this. This should not be happening.
Also - tweaking the lpfc-specific board_online attribute is a little
odd to make things scan. It resets and restarts the entire adapter.
For a link rescan, we recommend that bounce the link via
"echo 1 > sys/class/scsi_host/host1/issue_lip". If all you needed was
a scsi scan - try "echo "- - -" > /sys/class/scsi_host/host2/scan ".
Thank you for the explanations. We tested a bit more and found out, that
one has to wait lpfc_nodev_tmo seconds between disconnecting one target
from the fabric and connecting the other.
As this might be done quite fast in our tests, we now set lpfc_nodev_tmo
to 1, and it seems to work fine. Is there any risk with such a short
timer?
For my understanding: what is "echo 1 > sys/class/scsi_host/host1/issue_lip"?
When we used it after not having waited for nodev_tmo, it didn't cause a
rescan (i.e., the target still had the old wwpn).
BTW: at least once when we disconnected one target and connected the other
without waiting for nodev_tmo, we saw the situation, that the new target was
accessible, while sysfs still showed us the old wwpn.
Bodo
-- James
Regards
Bodo
P.S.: Please CC me, I'm not on the list.
-
: send the line "unsubscribe
linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
