I've got a Canon PowerShot A40 camera with a USB interface, and I've got a SunBlade 2000 desktop machine with USB interfaces, so I should be able to hook the camera up to the SunBlade and access my photos, right?

Well, it's not quite that simple. This is Solaris we're talking about, after all.

When I plug in the camera in 'upload' mode, these lines appear in /var/adm/messages:

usba: [ID 349649 kern.info] usba: no driver found for device Canon Inc. PowerShot A40 (interface 0, node name = interface)
usba: [ID 855233 kern.info] USB-device: device@1, usb_mid0 at bus address 4
usba: [ID 593373 kern.info] Canon Inc. PowerShot A40
genunix: [ID 936769 kern.info] usb_mid0 is /pci@8,700000/usb@5,3/device@1
genunix: [ID 408114 kern.info] /pci@8,700000/usb@5,3/device@1 (usb_mid0) online

So, at least the system detected the camera. That's a start.

Now, let's take a look at what prtconf -v has to say about the camera (output edited to a reasonable width):

SUNW,Sun-Blade-1000
    pci, instance #0
        usb, instance #0
            device, instance #0
                Driver properties:
                    name='pm-components' type=string items=3 dev=none
                        value='NAME= usb_mid0 Power' + '0=USB D3 State'
                           + '3=USB D0 State'
                    name='pm-want-child-notification?' type=boolean
                       dev=none
                Hardware properties:
                    name='configuration#' type=int items=1
                        value=00000001
                    name='usb-product-name' type=string items=1
                        value='PowerShot A40'
                    name='usb-vendor-name' type=string items=1
                        value='Canon Inc.'
                    name='usb-num-configs' type=int items=1
                        value=00000001
                    name='usb-revision-id' type=int items=1
                        value=00000001
                    name='usb-product-id' type=int items=1
                        value=00003058
                    name='usb-vendor-id' type=int items=1
                        value=000004a9
                    name='compatible' type=string items=9
                        value='usb4a9,3058.1' + 'usb4a9,3058' +
                          'usb4a9,classff.ff.ff' + 'usb4a9.classff.ff'
                          + 'usb4a9.classff' + 'usb,classff.ff.ff' +
                          'usb,classff.ff' + 'usb,classff' + 'usb,device'
                    name='reg' type=int items=1
                        value=00000001
                    name='assigned-address' type=int items=1
                        value=00000004
                interface (driver not attached)
                    Hardware properties:
                        name='interface' type=int items=1
                            value=00000000
                        name='compatible' type=string items=8
                            value='usbif4a9,3058.1.config1.0' +
                              'usbif4a9,3058.config1.0' +
                              'usbif4a9,classff.ff.ff' +
                              'usbif4a9,classff.ff' +
                              'usbif4a9,classff' +
                              'usbif,classff.ff.ff' +
                              'usbif,classff.ff' + 'usbif,classff'
                        name='reg' type=int items=2
                            value=00000000.00000001
                        name='assigned-address' type=int items=1
                            value=00000004

The key thing here is the first 'value' entry in the 'compatible' section. The string usb4a9,3058.1 identifies the camera. If I can get that associated with the correct USB driver, that should allow me to access the data in the camera from Solaris.

Looking in /etc/driver_aliases, I see several entries that reference USB:

hid "usbif,class3"
hubd "usbif,class9"
scsa2usb "usbif,class8"
usb_mid "usb,device"
usbprn "usbif,class7.1"
usb_ac "usbif,class1.1"
usb_as "usbif,class1.2"

One of the (many, confusing, out-of-date, and flatly inaccurate) Sun documents I'm looking at indicates that scsa2usb is the appropriate driver for USB storage devices (as opposed to other drivers that are used for keyboards, mice, audio, printers, and serial devices). So, I'm pleased to see scsa2usb in the list.

Another resource recommends this command to add the driver alias:

add_drv -m '* 0666 root sys' -i '"usb4a9,3058.1"' scsa2usb

No problem - the above link has this possibility covered. If that message is returned by add_drv, this command is recommended:

# update_drv -a -m '* 0666 root sys' -i '"usb4a9,3058.1"' scsa2usb

update_drv: illegal option -- a
Usage:  mod_drv -u [ -f | -v ] 

When I look at the man page for update_drv on the Solaris 9 machine, the syntax is pretty basic:

update_drv [-f] device_driver

Let's try the verbose flag on that add_drv command:

# add_drv -v -m '* 0666 root sys' -i '"usb4a9,3058.1"' scsa2usb
(scsa2usb) already in use as a driver or alias.

Hmmm... the 'cfgadm -vl' command shows that the system knows a camera is out there somewhere (output formatted into a table instead of the butt-ugly splatter from cfgadm):

This is encouraging - at least it's showing up alongside the USB keyboard and mouse entries.

This document set me on the trail of looking at the scsa2usb.conf file, which is located in the /kernel/drv directory. The sample entry provided (commented out) for a Sony DSC-S85 USB Digital camera looks like this:

# "vid=0x54c pid=0x10 rev=* subclass=ufi protocol=cb",

For my Canon camera, I got these values from 'prtconf -v':

Could it be as simple as adding these lines to the end of scsa2usb.conf and rebooting?

attribute-override-list =
"vid=0x4a9 pid=0x3058 rev=* subclass=ufi protocol=cb";

After the reboot, I got the same 'no driver found for device' lines from /var/adm/messages and the output from 'cfgadm -vl' was the same as before.

I'll try editing that line in scsa2usb.conf and taking out the '0x' prefixes. I assumed that was hexadecimal specification, but I'll try anything at this point.

Nope - no luck. I'm through fiddling with this for now.

Let's look at this some more...

Many of the documents I've seen tell me that vold does not play nice with USB hotplug devices, but I found one that offers a contrary opinion. It tells me that vold will automount the USB device under /rmdisk, but that the /rmdisk directory must exist beforehand for it to work.

I checked, and there was no /rmdisk directory on the system. I created one as root and set permissions to 777. This hasn't made a difference, so far - hotplugging the Canon camera produces the same set of messages ("no driver found") in /var/adm/messages.

Just for grins, I tried a different camera, a Pentax Optio 60. This camera is years newer than the old Canon A40. Here's what I see in /var/adm/messages when I plug it in and turn it on:

usba: [ID 593373 kern.info] /pci@8,700000/usb@5,3/storage@1 (scsa2usb0): invalid vendor id in scsa2usb conf file entry
usba: [ID 855233 kern.info] USB-device: storage@1, scsa2usb0 at bus address 4
usba: [ID 593373 kern.info]      PENTAX PENTAX Optio 60 0000000000000000
genunix: [ID 936769 kern.info] scsa2usb0 is /pci@8,700000/usb@5,3/storage@1
genunix: [ID 408114 kern.info] /pci@8,700000/usb@5,3/storage@1 (scsa2usb0) online
scsi: [ID 193665 kern.info] sd30 at scsa2usb0: target 0 lun 0
genunix: [ID 936769 kern.info] sd30 is /pci@8,700000/usb@5,3/storage@1/disk@0,0
genunix: [ID 408114 kern.info] /pci@8,700000/usb@5,3/storage@1/disk@0,0 (sd30) online
scsi: [ID 107833 kern.warning] WARNING: /pci@8,700000/usb@5,3/storage@1/disk@0,0 (sd30):
 disk not responding to selection
genunix: [ID 408114 kern.info] /pci@8,700000/usb@5,3/storage@1/disk@0,0 (sd30) offline
genunix: [ID 408114 kern.info] /pci@8,700000/usb@5,3/storage@1 (scsa2usb0) offline

This tells me a number of things. First, I think my last round of tinkering in scsa2usb.conf (removing the 0x prefixes from the values for the Canon) was misguided. I'll put the prefixes back in place and reboot the machine. Also, it looks like the Pentax was correctly associated with the scsa2usb driver, only to have problems accessing the "disk" ('not responding to selection'). I wonder if the problem is that Solaris is assuming the USB "disk" is a Solaris "disk" rather than a PC "disk?"

I fired up the Pentax again and tried to capture the output of 'prtconf -v' in a file, but the prtconf command seems to be taking a long time to run. I think some process is hanging, retrying, and/or timing out.

Still nothing after several minutes. I looked for the USB Vendor ID of the Pentax camera and found an unrelated message that lists the vendor ID for a different Pentax Optio model as 0x0a17, so I think I'll edit scsa2usb.conf and throw in a line that wildcards product and version to see what happens.

Oh, hang on - the prtconf command finally finished:

usb, instance #0
   System software properties:
       name='ddi-forceattach' type=int items=1
           value=00000001
   Driver properties:
       name='pm-want-child-notification?' type=boolean dev=none
   Hardware properties:
       name='root-hub' type=boolean
   storage, instance #0
       System software properties:
           name='attribute-override-list' type=string items=1
               value='vid=000004a9 pid=00003058 rev=*
                 subclass=ufi protocol=cb'
       Driver properties:
           name='pm-components' type=string items=3 dev=none
               value='NAME= scsa2usb0 Power' +
                 '0=USB D3 State' + '3=USB D0 State'
           name='scsi-selection-timeout' type=int items=1 dev=(201,0)
               value=000000fa
           name='scsi-options' type=int items=1 dev=(201,0)
               value=00001ff8
           name='scsi-watchdog-tick' type=int items=1 dev=(201,0)
               value=0000000a
           name='scsi-tag-age-limit' type=int items=1 dev=(201,0)
               value=00000002
           name='scsi-reset-delay' type=int items=1 dev=(201,0)
               value=00000bb8
           name='usb' type=int items=1 dev=none
               value=00000001
       Hardware properties:
           name='usb-product-name' type=string items=1
               value='PENTAX Optio 60'
           name='usb-vendor-name' type=string items=1
               value='PENTAX'
           name='usb-serialno' type=string items=1
               value='0000000000000000'
           name='usb-num-configs' type=int items=1
               value=00000001
           name='usb-revision-id' type=int items=1
               value=00000000
           name='usb-product-id' type=int items=1
               value=00000050
           name='usb-vendor-id' type=int items=1
               value=00000a17
           name='compatible' type=string items=8
               value='usba17,50.0' + 'usba17,50' +
                'usbifa17,class8.5.50' + 'usbifa17,class8.5' +
                'usbifa17,class8' + 'usbif,class8.5.50' +
                'usbif,class8.5' + 'usbif,class8'
           name='reg' type=int items=1
               value=00000001
           name='assigned-address' type=int items=1
               value=00000004
       disk, instance #30
           Driver properties:
               name='removable-media' type=boolean dev=none
               name='pm-components' type=string items=3 dev=none
                   value='NAME=spindle-motor' + '0=off' + '1=on'
               name='pm-hardware-state' type=string items=1 dev=none
                   value='needs-suspend-resume'
               name='ddi-failfast-supported' type=boolean dev=none
               name='ddi-kernel-ioctl' type=boolean dev=none
           Hardware properties:
               name='inquiry-revision-id' type=string items=1
                   value='0000'
               name='inquiry-product-id' type=string items=1
                   value='Optio 6000000000'
               name='inquiry-vendor-id' type=string items=1
                   value='PENTAX'
               name='inquiry-device-type' type=int items=1
                   value=00000000
               name='usb' type=boolean
               name='compatible' type=string items=1
                   value='sd'
               name='lun' type=int items=1
                   value=00000000
               name='target' type=int items=1
                   value=00000000

Sure enough, there it is! The vendor ID is confirmed as 0a17, and the product ID is 050 with a version of 0. I went back to scsa2usb.conf and added a wildcard line for the Pentax vendor ID and also put back the 0x prefix on the Canon line:

attribute-override-list =
"vid=0x0a17 pid=* rev=* subclass=ufi protocol=cb",
"vid=0x04a9 pid=0x03058 rev=* subclass=ufi protocol=cb";

AHA! Much better! Here are the messages from /var/adm/messages:

usba: [ID 855233 kern.info] USB-device: storage@1, scsa2usb0 at bus address 4
usba: [ID 593373 kern.info]      PENTAX PENTAX Optio 60 0000000000000000
genunix: [ID 936769 kern.info] scsa2usb0 is /pci@8,700000/usb@5,3/storage@1
usba: [ID 593373 kern.info] /pci@8,700000/usb@5,3/storage@1 (scsa2usb0): scsa2usb.conf override: vid=0x0a17 pid=* rev=* subclass=ufi protocol=cb
genunix: [ID 408114 kern.info] /pci@8,700000/usb@5,3/storage@1 (scsa2usb0) online

Still got nothing in /rmdisk, though. I do see links in /dev/rdsk that refer to USB devices now - so I think that's progress. I stopped and started /etc/init.d/volmgt but don't see any effect.

On a lark, I tried to mount the third partition:

# mount -F pcfs /dev/dsk/c3t0d0s2:c /mnt

The mount command is taking its own sweet time, but the system does not appear to be hung. The 'sar' utility tells me that the machine is 100% idle. Nothing so far in /var/adm/messages. The system is wedged but good, though - unplugging the Pentax doesn't even result in the 'offline' message in /var/adm/messages. This was not a good idea. Time for a reboot, and then I'll try killing vold before mounting the disk by hand.

Rebooted, killed vold with /etc/init.d/volmgt stop, and fired up the Pentax. Same set of messages in the messages log. Issued the mount command, and it's still taking forever to come back to the prompt.

Here's something odd that just popped up on the message log (don't know if it's related or not):

automountd[162]: [ID 784820 daemon.error] server brokerage not responding

All right, this is nuts. For one thing, I don't want to burn down the camera batteries while this machine diddles. I'm half convinced it's the network automounter that's screwed up stuff here.