Description of problem: Observations of ub driver (from a userspace point of view :-) Version-Release number of selected component (if applicable): kernel-2.6.8-1.532 How reproducible: Always Actual results: The ub driver doesn't work with LiteON USB 2.0 optical drive (vid=0x0ecd, pid=0xa100); this works fine with usb-storage driver so it is a regression. It takes a long time to open(2) the device which makes hald (userspace daemon for hardware information) fail. The class tripplet of the single USB interface is (0x08, 0x06, 0x50). Expected results: The ub driver should work with this device Additional info: a. The ub driver doesn't claim my USB floppy drive, interface class tripplet (0x08, 0x04, 0x00), not sure if this is intentional? b. Only the first LUN of my 6in1 card reader is reported. Perhaps it would be useful to stick in a ub_device 'class device' that sits in /sys/devices between the USB mass storage interface and the actual block link. Today it looks like this ..usb1/1-1/1-1:1.0/block -> /sys/block/... what I'm suggesting is something like this ..usb1/1-1/1-1:1.0/ub_device1/block -> /sys/block/... so for a 6in1 reader you would have ..usb1/1-1/1-1:1.0/ub_device1/block -> /sys/block/... ..usb1/1-1/1-1:1.0/ub_device2/block -> /sys/block/... ..usb1/1-1/1-1:1.0/ub_device3/block -> /sys/block/... .... c. There is no metadata files in sysfs (or /proc) telling userspace about the type of storage device. With usb-storage you could look at e.g. /sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host1/1:0:0:0/type to infer whether it was a disk, tape or optical drive (have to lookup the kernel source to get the meaning of the integer). To infer whether something was a floppy required checks against either /proc/scsi/usb-storage/%d file and looking at the Protocol: line or looking at the interface class tripplet. A file in the sysfs directory mentioned in b. would be very useful here. d. The driver outputs lines like this Aug 30 12:16:14 laptop kernel: uba: was not changed everytime the drive is polled. Since hald polls the drives this occurs all the time (and everyone running rawhide has hald running). This should probably be removed or rate-limited somehow. e. I'm seeing problems like reported in bug 131204 only when hald is running polling the drive. If no polling occurs then it works fine. f. On the good side, polling for media change no longer makes my other USB card reader (vid=0x05dc, pid=0x0002) blink all the time if the media isn't mounted. Unfortunately I don't know if the ub driver detects media change because the reader powers off when I remove the media (unlike some other card readers). I got quite a few USB storage devices to test with if you need more information.
Yes this has to be improved on all counts, except the UFI (floppy) support. I have a vague plan to write ufi.c one day for that. The long open() time sounds bad. May I see a dmesg attached? Also, try this cat $(find /sys -name diag) > /tmp/diag then attach /tmp/diag to the bug. Please do not drop dmesg or diag to the comments box.
I think we can close this, because it's a compound bug. However, some aspects warrant bugs if ub makes it into the tree, in particular the device type RFE.