Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Feb 2005 16:05:43 +0100
From:      Thomas Pornin <pornin@bolet.org>
To:        freebsd-usb@freebsd.org
Subject:   quirks for USB keys
Message-ID:  <20050209150543.GA88239@cronos.bolet.org>

next in thread | raw e-mail | index | archive | help
Hello,


short version:

I have a USB key which is not supported by FreeBSD. As far as I
understand, in most cases, this is only a matter of specifying the
correct quirks in umass.c and/or scsi_da.c. But I don't really know what
quirks to try, or not. I am willing to help, and I am looking for some
guidance. Is this mailing-list the correct place to ask ? Should I fill
in a PR ?


long version:

I have a simple PC (Athlon XP, FreeBSD 5.3-STABLE from this morning
[Wed Feb 9, 2005]). Here are the kernel boot messages about the USB
system:

uhci0: <VIA 83C572 USB controller> port 0xe000-0xe01f irq 21 at device 16.0 on pci0
uhci0: [GIANT-LOCKED]
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub1: Iiyama product 0x0201, class 9/0, rev 1.10/1.10, addr 2
uhub1: 4 ports with 4 removable, self powered
ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 3, iclass 3/1
ums0: 3 buttons and Z dir.
uhci1: <VIA 83C572 USB controller> port 0xe400-0xe41f irq 21 at device 16.1 on pci0
uhci1: [GIANT-LOCKED]
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci2: <VIA 83C572 USB controller> port 0xe800-0xe81f irq 21 at device 16.2 on pci0
uhci2: [GIANT-LOCKED]
usb2: <VIA 83C572 USB controller> on uhci2
usb2: USB revision 1.0
uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered

The USB hub embedded in the CRT is connected to one of the USB ports
on the back of the machine, and a mouse is plugged to that hub. This
setting works: I can use my mouse under X11. And I have another USB
key (a PNY one) which works when plugged in that hub (detected as da0,
and accessible through a "mount" or mtools).

The kernel is close to GENERIC. The only differences are:
-- I changed the name "GENERIC";
-- I commented out I486_CPU and I586_CPU;
-- I reduced SCSI delay from 15000 to 5000 milliseconds;
-- I added option P1003_1B_SEMAPHORES.


I have a 256MB USB key from Intuix. When I plug that key into the hub
(or one of the free plugs at the rear of the box), I get this:

umass0: M-Sys DiskOnKey, rev 2.00/2.00, addr 4
umass0: BBB reset failed, TIMEOUT
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
umass0: BBB reset failed, TIMEOUT
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
(...)

The pattern of three timeouts is repeated five times; the "reset failed"
timeout appears after 130 seconds, then 65 more seconds lead to the
"bulk-in" timeout, then 65 more seconds for the "bulk-out". The whole
procedure thus blocks for 1300 seconds (5 * (130 + 65 + 65)). If I
try "usbdevs -v" during that 21'40'' delay, the process blocks.
However, after the delay, I can run "usbdevs -v", which, after a dozen
seconds, outputs this:

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00
 port 1 powered
 port 2 addr 2: full speed, self powered, config 1, product 0x0201(0x0201), Iiyama(0x04e1), rev 1.10
  port 1 powered
  port 2 powered
  port 3 addr 4: full speed, power 94 mA, config 1, product 0x0012(0x0012), M-Systems(0x08ec), rev 2.00
  port 4 addr 3: low speed, power 98 mA, config 1, product 0xc00e(0xc00e), Logitech(0x046d), rev 11.10
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00
 port 1 powered
 port 2 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00
 port 1 powered
 port 2 powered

Note that my mouse is frozen, both during the whole timeout procedure,
and also afterwards, even if I unplug the key. By unplugging the key
during the timeout delay, and rebooting, I got a kernel panic (kernel
page fault on behalf of the moused process).


I have made some searchs on the web and mailing-list, and my problem
seems relatively special, because I do not even get a virtual disk (no
"da0" line) and most reports talk about "STALLED", not "TIMEOUT".

sys/dev/usb/umass.c has quirks for M-Systems products 0x0010 and 0x0011
(DISKONKEY and DISKONKEY2); mine appears to have the 0x0012 id. I
tried to add that product definition in usbdevs:

product MSYSTEMS DISKONKEY3     0x0012  DiskOnKey

and this quirk in umass.c:

	{ USB_VENDOR_MSYSTEMS, USB_PRODUCT_MSYSTEMS_DISKONKEY3, RID_WILDCARD,
	  UMASS_PROTO_ATAPI | UMASS_PROTO_BBB,
	  NO_QUIRKS
	},

but to no avail. I copied that "quirk" from the DISKONKEY2, and I have
no idea whether UMASS_PROTO_ATAPI or NO_QUIRKS is correct (probably
not).

The key works in another machine, with Windows 2000 (IBM Thinkpad). So
this is probably not a hardware defect. Note: I am aware that the key
can operate with USB 2.0 and that my controller is 1.1 only. But this
works with the Thinkpad, and the Intuix excuse for a documentation
claims 1.1 compatibility, so I guess this is not a problem.


I can do some testing but I need some help. Thanks for any information.
Please send me a copy of each message: I am not subscribed to the list.


	--Thomas Pornin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050209150543.GA88239>