The coldplug scripts cannot properly setup a pre-plugged-in USB scanner because the information given to it by the 2.6 /sys interface is incorrect. A trace of the hotplug/coldplug has determined that the kernel isn't giving the right info out. For example, using the latest stable gentoo-dev-sources kernel, a Zaurus SL5500, and a USB Flashcard reader on the first USB port pair, a USB scanner on the second pair, the mapping is this in /proc/bus/usb: 001/001 The hub for the first two ports (exists in all hubs listed) 001/002 The Zaurus 001/003 The flash reader 002/001 Hub for the second two ports 002/002 USB Scanner 003/001 Hub for the third two ports (on my system, the front-side ports) When coldplug runs on startup, it starts /etc/hotplug/usb.rc, which runs it's own usb_boot_events(). It then determines that /sys/bus exists, and proceeds to take the USB info from that (otherwize it would step through /proc/bus/usb and actually work correctly). I'll concentrate on this one. When usb_boot_events() steps into the second root hub, and finds the scanner, it sees that something's plugged in already and builds the DEVICE variable. It grabs the link of where the USB bus is actually at (on the PCI bus), in /sys/bus/pci/PCIADDYHERE/usb2/, and reads in the file "devnum" (A) and "2-1/devnum" (B) as listed in there. DEVICE then gets build as /proc/bus/usb/A/B devnum (A) is always "1", no matter what root hub it is. It needs to be "2" for the second root hub, "3" for the third, etc... Is it just me or is coldplug being fooled and Kernel 2.6 has a bug? Reproducible: Always Steps to Reproduce: 1. emerge coldplug and sane-backends. 2. Put in a scanner at any USB port other than the first two ports. 3. Try to scan as user (listed in "scanner" group). I dare you! Actual Results: SANE reports no such scanner. Expected Results: SANE should scan normally. A cheap fix would be to disable the /sys section of /etc/hotplug/usb.rc, but it would be best to patch the kernel.
This is not a kernel issue, and is a duplicate. *** This bug has been marked as a duplicate of 50934 ***
I cannot accept that. While it may be a duplicate, I still belive it is a kernel issue for what I have described. Since DEVICE depends on the the kernel telling things correctly, here's a little one-line bash script which proves my point: for i in /sys/bus/pci/devices/*/usb[0-9]/devnum; do echo -n "$i: "; cat $i; done On my system (a MSI board for an Athlon XP 1600+), I get this: /sys/bus/pci/devices/0000:00:10.0/usb1/devnum: 1 /sys/bus/pci/devices/0000:00:10.1/usb2/devnum: 1 /sys/bus/pci/devices/0000:00:10.2/usb3/devnum: 1 Now, according to the hotplug and coldplug scripts as described above, I can deduce that these numbers should be 1-2-3, not 1-1-1 as experienced above. The /sys filesystem is provided by the 2.6 kernel (not the 2.4, as I'm running gentoo-dev-sources kernel). It's not sane's problem. Sane's USB scripts get the info straight from hotplug/coldplug's usb.agent. usb.agent gets it's info from /proc and /sys, and I've traced it to /sys. I've now proven that it's a kernel bug. Gentoo bug reopened.
No, the kernel is completly correct in this case. The sysfs 'devnum' file contains the USB number for that device. And in _all_ instances, the root hub will have USB device number 1. Your script proves this. Do not confuse USB Bus numbers (which describes which bus the device is on, in this case, it is 1, 2, and 3) and USB Device numbers (of which they are unique only for a specific Bus. So in this case, the device number is correct, and if you go to /proc/bus/usb/BUS_NUMBER/DEVICE_NUMBER that is the proper usbfs file your scanner should connect to. Hope this helps clear up the confusion.
You know, I recently got some notice on bug 50934... and I've reexamined everything. If coldplug is confusing device numbers as being bus numbers, then where in the kernel /sys is the bus number being reported? I look up and down the USB host device on the PCI bus in /sys... nope, not there. Not even in the PCI entry. It's just not being reported at all! There's nothing for coldplug to latch on to! It's a kernel bug. Reopening.
A Kernel Bugzilla entry has been created: http://bugzilla.kernel.org/show_bug.cgi?id=4062
The bus number _is_ in sysfs. It's the X in "usbX" as in usb0, usb1, usb2, and so on in the sysfs device path for the USB device. So, the kernel bugzilla entry is closed. Shall I close this entry again too? :)
Which means coldplug can't simply "devbus=`cat .../busnum`" and has to go through sed to pull the number out of a directory, right? I think coldplug would love to have the simple approach. You can close this one but keep the one in the Kernel open. I'm getting the feeling I have to delve into the kernel again (first time was to look into the magic sysrq keys).
coldplug is now obsolete. udev handles its functionality. Am closing because of this.
