Re: mpt device shuffling

2013-10-21 Thread Eduardo Horvath
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

mpt device shuffling

2013-10-19 Thread Edgar Fuß
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?