Howdy, I've got this frustrating problem with a USB HID device not playing nice with linux. The device is an Imation "Disc Stakka". Its basically a CD storage unit for 100 CDs. It doesn't come with any Linux drivers hence I thought I'd look at writing my own. I've managed to reverse engineer the protocol enough by examining the traffic between my Windows box and the unit. However I ran in to a small hurdle..
Whenever the device is plugged into a linux box it continually connects and disconnects. Heres a short dump from dmesg: usb 1-2: new low speed USB device using ohci_hcd and address 2 hiddev96: USB HID v1.00 Device [Opdicom Disc Stakka] on usb-0000:00:03.0-2 usb 1-2: USB disconnect, address 2 usb 1-2: new low speed USB device using ohci_hcd and address 3 hiddev96: USB HID v1.00 Device [Opdicom Disc Stakka] on usb-0000:00:03.0-2 usb 1-2: USB disconnect, address 3 usb 1-2: new low speed USB device using ohci_hcd and address 4 hiddev96: USB HID v1.00 Device [Opdicom Disc Stakka] on usb-0000:00:03.0-2 usb 1-2: USB disconnect, address 4 usb 1-2: new low speed USB device using ohci_hcd and address 5 hiddev96: USB HID v1.00 Device [Opdicom Disc Stakka] on usb-0000:00:03.0-2 Analysis of the USB traffic indicates that, for some reason, the Linux box decides to reset the unit - ie, there is no failed request or strange traffic on the USB interface prior to the reset. Everything looks great then boom, reset. The reset period is roughly every second. I've tried this on a variety of kernel versions: 2.4.27, 2.6.8, 2.6.10 (both debian and stock), and they all respond the same. I've also blacklisted usbhid with the result being the dmesg output is identical to the above minus the lines starting with hiddev... suggesting that the problem does not lie within the HID code. (note I did the same test with my USB mouse and despite the device not registering with a hid interface the mouse was not sent a reset) Using a USB protocol analyser I have confirmed that - The device does not need or expect any firmware to be sent to it. - Windows and Linux perform in pretty much the same manner right up to reboot. I have also thought that perhaps the problem revolved around there not being a driver which will support this device so I used usb-skeleton to write a quick module specifically for this device - the dmesg output was still the same indicating that either I didn't do it properly or the problem lies before the module gets loaded (since the hiddev driver was still being used I would assume I didn't do it properly) For what its worth here are the details for the Disc Stakka, USB1.0 Device Class/subclass/protocol = 0 Vendor = 0x0718 (Imation) Product = 0xD000 1 Interface Interface Class = 3 (HID) Interface subclass = 0 Protocol = 0 So does anyone have any ideas why the unit is being reset? Currently I'm investigating the following... - Perhaps the ohci_hcd module doesn't receive a response in time and decides the unit is AWOL? Possible but the USB traffic capture doesn't suggest this is happening - Perhaps the module doesn't like having a interface subclass of 0? - Perhaps this unit doesn't fit into some model/standard the ohci_hcd module expects all USB HID devices to conform to? - Perhaps I'm doing something incredibly stupid and I can't see the forrest for the trees. I'd appreciate any assistance anyone can give. If you require any further information let me know and I'll be happy to oblige. -- Eddie Cornejo ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
