Re: mpt device shuffling

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Sat, 19 Oct 2013, Edgar Fuß wrote:

> Strictly speaking, this is not a NetBSD kernel issue.
> However, I hope that someone more familiar with mpt(4) has come accross that 
> MPT "feature" before:
> 
> One additional oddity I faced with Thursday's disc failure was that after 
> physically replacing the failed disc with a spare, the SAS controller decided 
> to assign a new pseudo target id to the new disc, skipping the old disc's 3
> and using 8 for the replacement (still at PHY 3). Since the kernel assigns 
> sd and, thus, dk numbers in the order of increasing SCSI target ids, this 
> meant 
> my RAIDframe components now became dk2, 6, 3, 4, 5 (not 2, 3, 4, 5, 6 as 
> before). Not a big deal, but somewhat confusing at midnight.
> I assume that's intentional behaviour to the benefit of some commercial 
> or GPL-licenced OS software. The renumbering was persistent accoss both a 
> hard 
> reset and a soft power cycle (I didn't try a hard power cycle).
> Is there a way of reverting to the old sequence or disabling that nonsense 
> in the first place?

Actually, it's for Windoze.

When I was at Sun we had lots of fun with this quirk of the mpt firmware.  

mpt pretends to be a SCSI HBA because most operating systems are not 
capable of handling SAS the way it's supposed to be, a fabric where you 
identify devices not by their location but by the GUID or disklabel.  In 
order to make it easier to write a driver, the mpt firmware does the job 
that the OS should be doing, keeping a table of device GUIDs and `device 
ID' mappings in PROM or NVRAM.  The `device ID' is what mpt uses to 
identify the disk to the driver.

There are several numbering schemes the firmware implements.  On of them 
assigns all the IDs based on the device's GUID.  Another one assigns the 
`device ID' based on the port number for directly attached devices.  That 
way if you swap out a broken device with a new one, the new one will have 
the same `device ID' as the one you removed.  It still falls back 
to the GUID for devices on the other side of a SAS switch.

There should be a way to alter the `device ID' assigned to a drive with 
both the mpt BIOS and the command line utility (who's name escapes me at 
the moment.)  There also should be a way to change the behavior for the 
assignment of `device ID's to directly attached devices by changing some 
values in the PROM, but this may be only possible with the command line 
utility.  And, of course, LSI kept changing how this worked across 
different versions of the MPT firmware so I can't give you details about 
how your particular setup works.

Eduardo