Thursday Sep 04, 2008

Its a brave new world for the mpt scsi driver.

I remember that when you wanted to add a driver to control a scsi device you added the driver to the right directory, created a driver.conf file, edited that file to select what  target/lun combination you wanted and maybe set some properties  or address filters, ran devfsadm or did a boot -r and it all just worked... 

Now it appears I am old fashioned and that the mpt scsi driver became one of these new fangled "self identifying"  HBA devices with the solaris 10 mpt patch 125081-09 and later revisions that are now in the Kernel patch and hence in the latest updates to solaris 10.

 We did document this in the scsi(4) manual page its just I don't think we really documented that mpt had changed type.

So  if you add a SL500 tape changer device to a mpt scsi bus a /devices node will be created by mpt  now rather than the target driver. As mpt has no idea what driver will attach to that it uses the name "sgen" for scsiclass 08, st for scsiclass 01, sd for scsi classes 00,03,05. This is the big difference previously the /devices node would only have appeared when your target driver attached it and it would have used the name of your driver so you could search for it with find during your solutions install script and put a nice simple entry in /etc/ to get a /dev symbolic link.

Now you will always get a  /devices node called sgen@XXX for a changer device attached to mpt as soon as mpt attaches and probes the bus,  without any modification to sgen.conf  sgen will attach to it. so how do I get my "foo" driver to attach to it?

"man -s4 scsi" says that you will get a list of compatible properties attached to the /devices node, ranging from some very specific strings though to very generic strings. The sgen driver picks up on the very generic entry, but you can use  update_drv -a -i "specific compat property" foo to insert the association ahead of sgen. At this point sgen should let go of the device and the foo driver will attach to it. You can undo this association by using update_drv -d -i "specific compat property" foo to delete the association and allow sgen to re-attach to the changer device.

So for my sl500 how do i see these compatible properties.. 

prtconf -v | grep -i stk

                                            value='scsiclass,08R.vSTK.pSL500.r1126' + 'scsiclass,08.vSTK.pSL500.r1126' + 'scsiclass,08R.vSTK.pSL500' + 'scsiclass,08.vSTK.pSL500' + 'scsa,08.bmpt' + 'scsiclass,08R' + 'scsiclass,08' + 'scsiclass'

so to add my foo driver ahead of sgen and take control of all scsi class 08 changers attached to STK SL500's I used

update_drv  -a -i '"scsiclass,08.vSTK.pSL500"'  foo

and to get symbolic links under /dev/foo I added this line ( tab not spaces) to /etc/

type=ddi_pseudo;name=sgen;      foo/\\M0

instead of the old fashioned form ...

 type=ddi_pseudo;name=foo;        foo/\\M0

all without editing a single  driver.conf file...

Of course the old /dev links for sgen will still be there under /dev/scsi/changer/  but they can be removed with a devfsadm -C

The same would have to be done for the SL500's tape devices  but they would show up under /devices as a node with a name like st@XXXX and you would have to add an alias for them using update_drv -a and a line in /etc/ using name=st; my_driver

certainly some installation programs and solutions will come unstuck when faced with this new mpt behaviour. Hopefully this will help explain what you are seeing.

Friday May 30, 2008

Using makedevice() in a drivers open routine and choosing minor numbers.

A customer reported that the close() function in his driver wasn't called as often as the open() routine. We had the normal discussion about what last close means but it became clear that something odd was going on. Based on an email discussion I wrote a driver with simple open and close entry points. The attach entry point made a device node in the filesystem thus ..

int minor = 0;
ddi_create_minor_node(dip, "ctrl", S_IFCHR, minor, DDI_PSEUDO, 0);

As in all the examples I used 0 for the minor number, so an ls -alL showed 238,0 as the major and minor for my device.
Then in the open routine I then changed the minor number ( under a mutex) using makedevice() . I used a range of 4 minor numbers starting from 0.

static int
cd_open(dev_t \*devp, int flag, int otyp, cred_t \*credp)
/\* select minor \*/
\*devp = makedevice(getmajor(\*devp),minor);


after a sequence of open and closes minor 0 was stuck open.

The answer is do not hand out the same minor number in open as you used in the attach. In my example I should have used minor number 4 in the attach and handed out minors 0 to 3 in the open. That would also allow me to differentiate between a close on the filesystem device node and a close on one of the dynamic minor numbers.



« June 2016

No bookmarks in folder


No bookmarks in folder