diff options
author | mjacob <mjacob@FreeBSD.org> | 2002-07-08 17:33:37 +0000 |
---|---|---|
committer | mjacob <mjacob@FreeBSD.org> | 2002-07-08 17:33:37 +0000 |
commit | 8eccb6dabfa373fc80ebf6536d5a009fff5c806a (patch) | |
tree | 008d690c1d862f813d46d517bdb10f1e72b6ae65 | |
parent | ebfda4c0dd6bcd6c81042231fbc8f0a68f0cc7cf (diff) | |
download | FreeBSD-src-8eccb6dabfa373fc80ebf6536d5a009fff5c806a.zip FreeBSD-src-8eccb6dabfa373fc80ebf6536d5a009fff5c806a.tar.gz |
Remove the 'bogus registrant' hack for fabric searches. It really
turns out that there's something of a hole in our new fabric name
server stuff. We ask the name server for entities that have
registered as a specific type. That type is FC-SCSI. If the entity
hasn't performed a REGISTER FC4 TYPES, the fabric nameserver won't
return it.
This brings this driver to a bit of a fork in the road as to what
the right thing to do is. For servicing the needs of accessing
FC-SCSI devices, this method is fine, and to be preferred. It is
extremely unlikely we're interested in fabric devices that *don't*
register correctly. If I ever get around to adding an FC-IP stack,
then asking for devices that have registers as FC-IP types is also
the right thing to do.
So- asking the fabric nameserver for a specific type is fine, *as
long as you are only interested in specific types*. If, on the other
hand, you want to create (as for management tool support) a picture
of everything on the fabric, this is *not* so fine. There are a
large class of FC-SCSI *initiators* who *don't* correctly register,
so we never will *see* them.
Is this a problem? Yes, but only a little one. If we want to do such
management tool support, we should probably run a *different* fabric
nameserver query algorithm. Better yet, we should talk to the management
nameserver in Brocade switches instead of the standard FC-GS-2 fabric
nameserver (which can be unwieldy).
Other changes: if we've overrrides marked, don't set some default
values from reading NVRAM. This allows us to override things like
EXEC throttle without having to ignore NVRAM entirely.
MFC after: 1 week
-rw-r--r-- | sys/dev/isp/isp.c | 21 |
1 files changed, 9 insertions, 12 deletions
diff --git a/sys/dev/isp/isp.c b/sys/dev/isp/isp.c index 6d9e5d3..75abde4 100644 --- a/sys/dev/isp/isp.c +++ b/sys/dev/isp/isp.c @@ -2810,12 +2810,6 @@ isp_scan_fabric(struct ispsoftc *isp, int ftype) } FC_SCRATCH_RELEASE(isp); - /* - * XXX: Workaround for some bogus fabric registrants - */ - if (ftype) { - (void) isp_scan_fabric(isp, 0); - } fcp->isp_loopstate = LOOP_FSCAN_DONE; return (0); } @@ -5928,8 +5922,9 @@ isp_parse_nvram_1020(struct ispsoftc *isp, u_int8_t *nvram_data) ISP_NVRAM_FIFO_THRESHOLD(nvram_data) | (ISP_NVRAM_FIFO_THRESHOLD_128(nvram_data) << 2); - sdp->isp_initiator_id = - ISP_NVRAM_INITIATOR_ID(nvram_data); + if ((isp->isp_confopts & ISP_CFG_OWNLOOPID) == 0) + sdp->isp_initiator_id = + ISP_NVRAM_INITIATOR_ID(nvram_data); sdp->isp_bus_reset_delay = ISP_NVRAM_BUS_RESET_DELAY(nvram_data); @@ -6054,8 +6049,9 @@ isp_parse_nvram_1080(struct ispsoftc *isp, int bus, u_int8_t *nvram_data) sdp->isp_fifo_threshold = ISP1080_NVRAM_FIFO_THRESHOLD(nvram_data); - sdp->isp_initiator_id = - ISP1080_NVRAM_INITIATOR_ID(nvram_data, bus); + if ((isp->isp_confopts & ISP_CFG_OWNLOOPID) == 0) + sdp->isp_initiator_id = + ISP1080_NVRAM_INITIATOR_ID(nvram_data, bus); sdp->isp_bus_reset_delay = ISP1080_NVRAM_BUS_RESET_DELAY(nvram_data, bus); @@ -6145,8 +6141,9 @@ isp_parse_nvram_12160(struct ispsoftc *isp, int bus, u_int8_t *nvram_data) sdp->isp_fifo_threshold = ISP12160_NVRAM_FIFO_THRESHOLD(nvram_data); - sdp->isp_initiator_id = - ISP12160_NVRAM_INITIATOR_ID(nvram_data, bus); + if ((isp->isp_confopts & ISP_CFG_OWNLOOPID) == 0) + sdp->isp_initiator_id = + ISP12160_NVRAM_INITIATOR_ID(nvram_data, bus); sdp->isp_bus_reset_delay = ISP12160_NVRAM_BUS_RESET_DELAY(nvram_data, bus); |