On 07/07/2010 18:22, Alan Stern wrote:
On Wed, 7 Jul 2010, Paul Mortier wrote:
Hi,
apologies if this is wrong place to ask, but I've got a problem with
a USB dongle appearing then disappearing in /dev/bus/usb. The dongle is
an authentication dongle for some software that runs on WindowsXP, which
I would like to have running in a virtual machine, but the file need to
be present so that it can be passed through to the virtual machine.
The problem first showed itself in that there is an LED on the dongle
which in Windows flickers briefly when the dongle is inserted, then
stays lit except for the occasional flicker whilst the software is
running. When inserted in Linux it instead continuously flickers. I've
captured the USB activity in a WireShark log, dmesg log and a separate
usbmon text output. Looking at that it seems that the dongle almost
connects correctly, but that after having read the strings at locations
0, 2, 1 and 3, then setting the configuration. It then tries to read a
string from location 4 which gets some valid data back. Finally the
host tries to read from location 5 and gets an error. Sometime during
that the host creates the /dev/bus/usb file, but shortly (0.1s or so)
after that there's a disconnect, followed by the dongle reconnecting and
starting the loop over again. I'm guessing that the dongle isn't
handling the read request correctly and resetting itself.
With a bit of luck I captured the lsusb output for the split second the
file existed, which shows the information that has been read before the
disconnect happens. The dongle has vendor:product 04b4:0526
I've tried this under kernel 2.6.35-rc4 and the current debian testing
kernel 2.6.32 package, both for x86-64 (processor is Intel core2 duo),
and also 2.6.22-3-486 on an old p200 with the same result.
I'm aware that this is a problem most likely caused by the dongle not
following standards, given that I haven't had any other USB problems,
but I was wondering if anyone could help point toward a possible
solution that stops the extra string reads for this device that I think
are causing the problem? If the disconnect could be avoided then it
might be possible to pass the file through the virtual machine for the
Windows-only dongle drivers to handle. I hope I've provided enough
useful information, please let me know if there's anything else I could
provide,
According to the usbmon log, your diagnosis is correct. The device
fails when asked for its interface string descriptor.
You can prevent the kernel from getting the configuration and interface
string descriptors by adding an entry to the drivers/usb/core/quirks.c
file. It should look like the Saitek Cyborg Gold Joystick entry, with
the USB_QUIRK_CONFIG_INTF_STRINGS flag set (except of course that you
must specify the dongle's own vendor and product IDs).
If you don't feel up to making this change yourself, I can send a
patch.
Alan Stern
Hi Alan,
fantastic, worked perfectly, now I just get a log note letting me
know it's a quirky device (USB quirks for this device: 8) and it stays
connected. Adding the device to qemu now connects properly to the
virtual machine, the windows drivers install and the software can run.
Thanks very much for your help,
Paul.
--- quirks_old.c 2010-07-07 21:57:31.000000000 +0100
+++ quirks.c 2010-07-07 21:57:38.000000000 +0100
@@ -41,6 +41,10 @@
/* Philips PSC805 audio device */
{ USB_DEVICE(0x0471, 0x0155), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Artisman Watchdog Dongle */
+ { USB_DEVICE(0x04b4, 0x0526), .driver_info =
+ USB_QUIRK_CONFIG_INTF_STRINGS },
+
/* Roland SC-8820 */
{ USB_DEVICE(0x0582, 0x0007), .driver_info = USB_QUIRK_RESET_RESUME },
