LUN Discovery Algortihm

Graham, Simon Simon.Graham at stratus.com
Mon Sep 30 19:52:42 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Graham, Simon" <Simon.Graham at stratus.com>
*
Well, I suppose I should have explained a little more - I'm working in the
Windows driver space, using a SCSI adapter whose firmware I can't change -
when a disk is removed or added, I need to cause the bus to be rescanned by
Windows Plug and Play. 

Now, what we noticed was that when a disk is replaced, the inquiry data
returned to Windows would have each character in the hardware ID repeated
multiple times (SSSSEEEEAAAAGGGGAAAATTTTEEEE instead of SEAGATE for example)
-- in the end, I decided this had to be because the firmware in the adapter
cached the negotiated speed/width info and when the new disk was plugged in,
it would initialise itself to the slowest speed but the initiator firmware
wouldn't know this and the disk drive does not force renegotiation in
response to the initial INQUIRY (which I assume is because the asynch event
notification is not permitted in response to the INQUIRY).

Bottom line - the target and initiator fw we have doesn't renegotiate so I
need to find the right way to perform LU discovery such that negotiation
will be done; sending a TUR before the initial inquiry seems to work but I'd
like to know if this is the "right" way to proceed.

Thanks
Simon

-----Original Message-----
From: Matthew Jacob [mailto:mjacob at feral.com] 
Sent: Monday, September 30, 2002 6:06 PM
To: Graham, Simon
Cc: 'rtfrey at IEEE.org'; Pat LaVarre; t10 at t10.org
Subject: RE: LUN Discovery Algortihm



> A problem that I've encountered with this is IF you pull a disk and then
> hot-add a new disk (or even the same one) at the same target address, the
> initial INQUIRY returns bad data because the initiator doesn't know that
it
> needs to renegotiate transfer speed at al (I think because the target
can't
> return AEN to the initial INQUIRY) - thus the initial INQUIRY is likely to
> fail with an OVERRUN error and will certainly return invalid data leading
to
> all sorts of fun.

You always are supposed to renegotiate on every check condition because
of this possibility- this should be prior to any data phase,
irrespective of the command you want to use (Oh, I suppose it really
only need occur if you *expect* data movement).

Since negotiation isn't a property of lun discovery but of transport,
I'm a bit confused as to why you're bringing it up in the context of lun
discovery.


-matt

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list