SAS scsibus target numbering
I have a (mpt) SAS with seven discs connected. The discs attach as sd0..sd6, but the SCSI target numbers are 0..5 and 7. It appears to me that someone is skippig ID 6 for the controller. It doesn't hurt too much, but it took me a while to find out why detaching targets 2, 3, 4 and 5 worked and 6 didn't (of course, 7 worked). Is there a reason for this behaviour?
Re: SAS scsibus target numbering
On Thu, Jul 26, 2012 at 02:33:15PM +0200, Edgar Fu? wrote: > I have a (mpt) SAS with seven discs connected. > The discs attach as sd0..sd6, but the SCSI target numbers are 0..5 and 7. > It appears to me that someone is skippig ID 6 for the controller. > It doesn't hurt too much, but it took me a while to find out why detaching > targets 2, 3, 4 and 5 worked and 6 didn't (of course, 7 worked). The disks are simply enumerated in sequence, starting from 0, as they are discovered during autoconfig. If you want a particular target on a particular bus to probe as a particular sd unit, you must enforce this in your kernel config file, for example: scsibus0 at mpt* sd0 at scsibus0 id 0 sd1 at scsibus0 id 1 etc. Thor
Re: SAS scsibus target numbering
On Thu, 26 Jul 2012, Edgar Fu? wrote: > I have a (mpt) SAS with seven discs connected. > The discs attach as sd0..sd6, but the SCSI target numbers are 0..5 and 7. > It appears to me that someone is skippig ID 6 for the controller. > It doesn't hurt too much, but it took me a while to find out why detaching > targets 2, 3, 4 and 5 worked and 6 didn't (of course, 7 worked). > > Is there a reason for this behaviour? "target IDs" are assigned by the mpt firmware. You can change them arbitrarily by messing with mpt either from BIOS or their command line utilities. The idea is that they can emulate a SCSI bus and thus boot Windows. ISTR that the mpt interface is the same across their SAS and parallel SCSI adapters. With parallel SCSI, the HBA driver allocates itsel a SCSI ID, usually 6. This is meaningless for SAS. Some versions of the mpt firmware also support RAID. When a RAID volume is created by the firmware it is also allocated a target ID. The whole thing was a gigantic mess. When I was at Sun we switched from using the "target ID" to identify the drives to using a combination of PHY numbers for directly attaced devices and GUIDs for RAID volumes and devices on the other end of SAS switches. I can't say I know anything about the NetBSD mpt driver, but I figure if you don't like the way the "target IDs" are assigned, go into the firmware and swap them around until you're happy. Eduardo
Re: SAS scsibus target numbering
I don't understand. I wrote: > The discs attach as sd0..sd6, so nailing down the autoconfig wouldn't change anything. What I would like to change are the SCSI target numbers. I wrote: > but the SCSI target numbers are 0..5 and 7. but I would like those targets to be 0..6. So it looks like the mpt driver somehow skips target 6. The drives are connected to PHYs 0..6.
Re: SAS scsibus target numbering
> "target IDs" are assigned by the mpt firmware. I suspected that. > You can change them arbitrarily by messing with mpt > either from BIOS or their command line utilities. I tried the BIOS configuration (the one you get by typing Ctrl-C at the right time, but I couldn't anything to assign target IDs. Do you remember where to find the relevant setting? What exactly do you refer tp by "their command line utilities"?
Re: SAS scsibus target numbering
On Thu, 26 Jul 2012, Edgar Fu? wrote: > > You can change them arbitrarily by messing with mpt > > either from BIOS or their command line utilities. > I tried the BIOS configuration (the one you get by typing Ctrl-C > at the right time, but I couldn't anything to assign target IDs. > Do you remember where to find the relevant setting? Sorry, I don't remember. Most of the time I was using OpenBoot machines rather than BIOS. Also this works differently on different versions of their firmware. > What exactly do you refer tp by "their command line utilities"? LSI distributes some command line utilities for Solaris and Windows and I think they also have a GUI based config utility for Windows. Eduardo
re: SAS scsibus target numbering
> I have a (mpt) SAS with seven discs connected. > The discs attach as sd0..sd6, but the SCSI target numbers are 0..5 and 7. > It appears to me that someone is skippig ID 6 for the controller. > It doesn't hurt too much, but it took me a while to find out why detaching > targets 2, 3, 4 and 5 worked and 6 didn't (of course, 7 worked). > > Is there a reason for this behaviour? it's usual for the SCSI HBA to assign a targetID for itself. besides having to use a different number, is there any real reason you want to change them? perhaps a better solution would be to patch scsictl such that we can detach via autoconf name as well as scsi addresses. maybe we should do this anyway.. .mrg.
Re: SAS scsibus target numbering
> it's usual for the SCSI HBA to assign a targetID for itself. For real SCSI - ie, non-SAS - it's actually necessary; the protocols used for initiators and targets to speak with one another require a line for the initiator as well as for the target. But the host is usually ID 7. Perhaps this is a SAS difference? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: SAS scsibus target numbering
> besides having to use a different number, is there any real reason > you want to change them? Just trying to avoid confusion. I now have already have five different numbering scemes: ID2=sd2=dk0=component0=column 1. Fortunately two of then coincide and so I have three of them only differing by a constant. This works up to ID5=sd5=dk3=component3=column 4, but the last one is ID7=sd6=dk4=component4=column 5. > perhaps a better solution would be to patch scsictl > l such that we can detach via autoconf name Maybe yes, but how do I scan, then? all all?
Re: SAS scsibus target numbering
On Thu, 26 Jul 2012, Mouse wrote: > > it's usual for the SCSI HBA to assign a targetID for itself. > > For real SCSI - ie, non-SAS - it's actually necessary; the protocols > used for initiators and targets to speak with one another require a > line for the initiator as well as for the target. But the host is > usually ID 7. ISTR SPARC machines used an initiator address 6 for hysterical reasons. I forget why. > Perhaps this is a SAS difference? SAS doesn't use target IDs on the wire. The "target ID" is something LSI came up with to provide backwards compatibilty with parallel SCSI. Eduardo
Re: SAS scsibus target numbering
>>> it's usual for the SCSI HBA to assign a targetID for itself. >> For real SCSI - ie, non-SAS - it's actually necessary; [...]. But >> the host is usually ID 7. > ISTR SPARC machines used an initiator address 6 for hysterical > reasons. I forget why. That disagrees with my experience. The SPARCs I've worked with put the host at ID 7; when using SunOS, ID 6, if present, is usually expected to be a CD drive. (0, 1, 2, 3 were disk, 4 and 5 tape, and 6 CD, in Sun's default config.) On machines with OF (which includes most SPARCs I've seen), there usually is an OF setting for which ID the host should use, but (again, in my experience) the default is 7, and I'm not sure I've ever seen a machine with it set to anything else. Perhaps if someone were doing clustering with SCSI as the transport...but I don't know if typical SPARC SCSI interfaces are capable of being targets. >> Perhaps this is a SAS difference? > SAS doesn't use target IDs on the wire. The "target ID" is something > LSI came up with to provide backwards compatibilty with parallel > SCSI. "Compatability", feh. If I can't plug existing drives and machines into it, I don't consider it compatible, and indeed I consider calling it SCSI at all to be deliberately misleading. One of SCSI's major strengths is its extreme compatability; except for the brief fling with HVD, SCSI is pretty much "plug it in and it Just Works". At least in theory, and in my experience that theory is pretty close to practice. I've heard people rant about how touchy SCSI is, but that hasn't been how it's worked for me. (Another of SCSI's strengths is its symmetry; while I don't know enough to be sure, I expect SAS breaks that too.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: SAS scsibus target numbering
Eduardo Horvath wrote: > On Thu, 26 Jul 2012, Mouse wrote: > > > > it's usual for the SCSI HBA to assign a targetID for itself. > > > > For real SCSI - ie, non-SAS - it's actually necessary; the protocols > > used for initiators and targets to speak with one another require a > > line for the initiator as well as for the target. But the host is > > usually ID 7. > > ISTR SPARC machines used an initiator address 6 for hysterical reasons. I > forget why. Likewise for some early models of DECstation (2100 and 3100?). I never understood why. Cheers, Simon.
re: SAS scsibus target numbering
> > it's usual for the SCSI HBA to assign a targetID for itself. > > For real SCSI - ie, non-SAS - it's actually necessary; the protocols > used for initiators and targets to speak with one another require a > line for the initiator as well as for the target. But the host is > usually ID 7. > > Perhaps this is a SAS difference? i've seen ID 0 and ID 6 also used for the controller several times. perhaps the ID 6 was actually for a SAS controller, it's not always entirely clear from remote :-) .mrg.
Re: SAS scsibus target numbering
On Fri, Jul 27, 2012 at 07:35:19AM +1000, matthew green wrote: > > > I have a (mpt) SAS with seven discs connected. > > The discs attach as sd0..sd6, but the SCSI target numbers are 0..5 and 7. > > It appears to me that someone is skippig ID 6 for the controller. > > It doesn't hurt too much, but it took me a while to find out why detaching > > targets 2, 3, 4 and 5 worked and 6 didn't (of course, 7 worked). > > > > Is there a reason for this behaviour? > > it's usual for the SCSI HBA to assign a targetID for itself. > > besides having to use a different number, is there any real reason > you want to change them? perhaps a better solution would be to > patch scsictl such that we can detach via autoconf name as well > as scsi addresses. maybe we should do this anyway.. Depending on LSI firmware (I think), the LSI may re-number disks depending on how they present themselves, uuid, etc. Some people like this persistence (mainly Winders users, I imagine), it causes problems for others. To get around this, at work I used lsiutil to clear the NVRAM settings. Otherwise, switching out all the LSI-attached disks in one of the Open Connect Appliances made the drives present themselves as da33 to da64, rather than da1 to da32 - under FreeBSD, obviously. Regards, Alistair
Re: SAS scsibus target numbering
On Jul 26, 2012, at 9:07 PM, Alistair Crooks wrote: > On Fri, Jul 27, 2012 at 07:35:19AM +1000, matthew green wrote: >> >>> I have a (mpt) SAS with seven discs connected. >>> The discs attach as sd0..sd6, but the SCSI target numbers are 0..5 and 7. >>> It appears to me that someone is skippig ID 6 for the controller. >>> It doesn't hurt too much, but it took me a while to find out why detaching >>> targets 2, 3, 4 and 5 worked and 6 didn't (of course, 7 worked). >>> >>> Is there a reason for this behaviour? >> >> it's usual for the SCSI HBA to assign a targetID for itself. >> >> besides having to use a different number, is there any real reason >> you want to change them? perhaps a better solution would be to >> patch scsictl such that we can detach via autoconf name as well >> as scsi addresses. maybe we should do this anyway.. > > Depending on LSI firmware (I think), the LSI may re-number disks > depending on how they present themselves, uuid, etc. Some people like > this persistence (mainly Winders users, I imagine), it causes problems > for others. > > To get around this, at work I used lsiutil to clear the NVRAM > settings. Otherwise, switching out all the LSI-attached disks in one > of the Open Connect Appliances made the drives present themselves as > da33 to da64, rather than da1 to da32 - under FreeBSD, obviously. Of course, if NetBSD supported non-integer locators, then we could use WWNs (World Wide Names) as locators since really the bus is one possible path to the drive (think fibre-channel).
Re: SAS scsibus target numbering
On Fri, Jul 27, 2012 at 09:49:38AM +1000, Simon Burge wrote: > > > > ISTR SPARC machines used an initiator address 6 for hysterical reasons. I > > forget why. > > Likewise for some early models of DECstation (2100 and 3100?). I never > understood why. > Priorities. When negotiating for the bus the highest numbered device wins if there is an arbitration clash... iirc ids greater than 7 have a priority lower than id 0, I presume for compat reasons. So for a scsi ID 0 - 7 the highest wins, it makes sense that the controller is a high number (as Mouse said it is normally 7 on old sun hardware) so that it can grab the bus when it wants to talk. -- Brett Lymn "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer."
