Re: scanner claimed by usbfs

On Sun, Aug 25, 2013 at 2:13 AM, Chris Bannister <cbannister@slingshot.co.nz> wrote:

On Sat, Aug 24, 2013 at 12:40:36PM -0700, Ross Boylan wrote:
> I was briefly able to use my scanner, but while the scanner application
> (Skanlite) was running it became inaccessible. About that time the logs
> show
> Aug 24 11:46:03 tempserver kernel: [6950936.545558] usb 3-1.2: usbfs:
> interface 0 claimed by usbfs while 'skanlite' sets config #1
>
> Neither xsane nor subsequent launches of skanlite have been able to
> detect the scanner.
>
> I opened a bug
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720721), but I'm
> hoping someone here has some ideas. It looks as if the problem is not
> with skanlite or xsane, but something lower level.

Sorry I can't help, but does:

# udevadm trigger

help in the meantime. (while a fix is pending)

I physically disconnected and reconnected the USB cable and that helped. The scans have been working since then and so now the mystery is what triggered the original problem (I had thought that a period of inactivity was the key).

Perhaps you or someone else could explain to me the difference between

udevadm trigger
and

udevadm control --reload-rules

and the circumstances under which each is appropriate?

Also, I was a bit concerned that either command would disrupt my existing usb-connected disks; I've had problems in the past in which a temporary power outage to those disks led to them being permanently (i.e., until reboot) lost because when the power came back they were mapped to new names and the existing mounts were hosed. The disks are in a separate enclosure that lacked UPS; the physical USB connection is to the enclosure, a Vantec HX4.

The man page says
--reload-rules
Signal udevd to reload the rules files. The udev daemon detects changes automatically, this option is usually not needed. Reloading rules does not apply any changes to already existing devices.

which suggests it will not harm existing relations, and makes it sound like a no-op.