Re: JMicron 20337 (152d:2338) and 3TB
On Fri, Aug 31, 2012 at 12:08 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
I was trying to figure out if there can be automatic workaround based
on USB vendor:product... If these exposed at this point then a patch
can be written to effect only this device.
I never traced the scsi module, but scsi_device does contain vendor,
model and rev, maybe these can be mapped to the JMicron 20337 device
and apply the workaround.
Such a patch can be written. It would be more complicated than the
one I sent you, though, and I wanted to try the easier patch first.
Alan Stern
I modified the patch to the following to make sure my main disk is unaffected:
---
--- drivers/scsi/sd.c 2012-07-21 23:58:29.0 +0300
+++ drivers/scsi/sd.c.new 2012-08-31 19:47:15.822632952 +0300
@@ -1899,13 +1899,17 @@ static int sd_try_rc16_first(struct scsi
{
if (sdp-host-max_cmd_len 16)
return 0;
- if (sdp-try_rc_10_first)
- return 0;
+ if (sdp-try_rc_10_first) {
+ printk(@ALON: apply workaround 1);
+ /*return 0;*/
+ }
if (sdp-scsi_level SCSI_SPC_2)
return 1;
if (scsi_device_protection(sdp))
return 1;
- return 0;
+ printk(@ALON: apply workaround 2);
+ /*return 0;*/
+ return 1;
}
/*
---
This is what I get now, I guess detection is good now, but something
in the IO is wrong, when plugged to computer's sata it works
correctly.
---
Sep 2 11:42:55 localhost kernel: Initializing USB Mass Storage driver...
Sep 2 11:42:55 localhost kernel: scsi6 : usb-storage 2-1.1:1.0
Sep 2 11:42:55 localhost kernel: usbcore: registered new interface
driver usb-storage
Sep 2 11:42:55 localhost kernel: USB Mass Storage support registered.
Sep 2 11:42:56 localhost kernel: scsi 6:0:0:0: Direct-Access WDC
WD30 EZRX-00MMMB0 PQ: 0 ANSI: 5
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Sep 2 11:42:56 localhost kernel: @ALON: apply workaround 1
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] 5860533168
512-byte logical blocks: (3.00 TB/2.72 TiB)
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 28 00 00 00
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive
cache: write through
Sep 2 11:42:56 localhost kernel: @ALON: apply workaround 1
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present
Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive
cache: write through
Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] Unhandled error code
Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb]
Sep 2 11:42:57 localhost kernel: Result: hostbyte=0x07 driverbyte=0x00
Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] CDB:
Sep 2 11:42:57 localhost kernel: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00
Sep 2 11:42:57 localhost kernel: end_request: I/O error, dev sdb, sector 0
Sep 2 11:42:57 localhost kernel: Buffer I/O error on device sdb,
logical block 0
Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:58 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:58 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:58 localhost kernel: usb 2-1.1: reset high-speed USB
device number 7 using ehci_hcd
Sep 2 11:42:58 localhost kernel: sd 6:0:0:0: [sdb] Unhandled error code
Sep 2 11:42:58 localhost kernel: sd 6:0:0:0: [sdb]
Sep 2 11:42:58 localhost kernel: Result: hostbyte=0x07 driverbyte=0x00
Sep 2 11:42:58 localhost kernel: sd 6:0:0:0: [sdb] CDB:
Sep 2 11:42:58 localhost kernel: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00
Sep 2 11:42:58 localhost kernel: end_request: I/O error, dev sdb, sector 0
Sep 2 11:42:58 localhost kernel: Buffer I/O error on device sdb,
logical block 0
continue in a loop different blocks
---
Alon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, 2 Sep 2012, Alon Bar-Lev wrote: I modified the patch to the following to make sure my main disk is unaffected: This is what I get now, I guess detection is good now, but something in the IO is wrong, when plugged to computer's sata it works correctly. --- Sep 2 11:42:55 localhost kernel: Initializing USB Mass Storage driver... Sep 2 11:42:55 localhost kernel: scsi6 : usb-storage 2-1.1:1.0 Sep 2 11:42:55 localhost kernel: usbcore: registered new interface driver usb-storage Sep 2 11:42:55 localhost kernel: USB Mass Storage support registered. Sep 2 11:42:56 localhost kernel: scsi 6:0:0:0: Direct-Access WDC WD30 EZRX-00MMMB0 PQ: 0 ANSI: 5 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0 Sep 2 11:42:56 localhost kernel: @ALON: apply workaround 1 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) Is this the same as the number of blocks you get when the drive is plugged into a SATA port? Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 28 00 00 00 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Sep 2 11:42:56 localhost kernel: @ALON: apply workaround 1 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] Unhandled error code Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] Sep 2 11:42:57 localhost kernel: Result: hostbyte=0x07 driverbyte=0x00 Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] CDB: Sep 2 11:42:57 localhost kernel: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00 Sep 2 11:42:57 localhost kernel: end_request: I/O error, dev sdb, sector 0 Sep 2 11:42:57 localhost kernel: Buffer I/O error on device sdb, logical block 0 Yep, something is wrong. To find out what, capture a usbmon trace showing what happens when the drive is plugged in (see Documentation/usb/usbmon.txt for instructions). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, Sep 2, 2012 at 4:59 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 2 Sep 2012, Alon Bar-Lev wrote: I modified the patch to the following to make sure my main disk is unaffected: This is what I get now, I guess detection is good now, but something in the IO is wrong, when plugged to computer's sata it works correctly. --- Sep 2 11:42:55 localhost kernel: Initializing USB Mass Storage driver... Sep 2 11:42:55 localhost kernel: scsi6 : usb-storage 2-1.1:1.0 Sep 2 11:42:55 localhost kernel: usbcore: registered new interface driver usb-storage Sep 2 11:42:55 localhost kernel: USB Mass Storage support registered. Sep 2 11:42:56 localhost kernel: scsi 6:0:0:0: Direct-Access WDC WD30 EZRX-00MMMB0 PQ: 0 ANSI: 5 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0 Sep 2 11:42:56 localhost kernel: @ALON: apply workaround 1 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) Is this the same as the number of blocks you get when the drive is plugged into a SATA port? Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 28 00 00 00 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Sep 2 11:42:56 localhost kernel: @ALON: apply workaround 1 Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present Sep 2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:56 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:57 localhost kernel: usb 2-1.1: reset high-speed USB device number 7 using ehci_hcd Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] Unhandled error code Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] Sep 2 11:42:57 localhost kernel: Result: hostbyte=0x07 driverbyte=0x00 Sep 2 11:42:57 localhost kernel: sd 6:0:0:0: [sdb] CDB: Sep 2 11:42:57 localhost kernel: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00 Sep 2 11:42:57 localhost kernel: end_request: I/O error, dev sdb, sector 0 Sep 2 11:42:57 localhost kernel: Buffer I/O error on device sdb, logical block 0 Yep, something is wrong. To find out what, capture a usbmon trace showing what happens when the drive is plugged in (see Documentation/usb/usbmon.txt for instructions). Alan Stern --- Sep 2 11:53:23 alonbl2 kernel: [0.922566] scsi 1:0:0:0: Direct-Access ATA WDC WD30EZRX-00M 80.0 PQ: 0 ANSI: 5 Sep 2 11:53:23 alonbl2 kernel: [0.922753] sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) Sep 2 11:53:23 alonbl2 kernel: [0.922757] sd 1:0:0:0: [sdb] 4096-byte physical blocks Sep 2 11:53:23 alonbl2 kernel: [0.922789] sd 1:0:0:0: Attached scsi generic sg1 type 0 Sep 2 11:53:23 alonbl2 kernel: [0.922984] sd 1:0:0:0: [sdb] Write Protect is off Sep 2 11:53:23 alonbl2 kernel: [0.923041] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA --- Will do usbmon now. Thanks! Alon. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, 2 Sep 2012, Alon Bar-Lev wrote: Attached usbmon, I hope I've done this OK. The errors start here: 880112a12d80 3034504955 S Bo:2:009:2 -115 31 = 55534243 0a00 0010 8a28 0008 00 880112a12d80 3034505013 C Bo:2:009:2 0 31 880132074d80 3034505019 S Bi:2:009:1 -115 4096 880132074d80 3034505155 C Bi:2:009:1 -32 0 880112a12d80 3034505161 S Co:2:009:0 s 02 01 0081 0 880112a12d80 3034505298 C Co:2:009:0 0 0 880112a12d80 3034505308 S Bi:2:009:1 -115 13 880112a12d80 3034505441 C Bi:2:009:1 0 13 = 55534253 0a00 02 This shows the computer asking the drive to read 8 blocks starting at block 0. The drive (actually the JMicron USB interface, not the drive itself) returns an error code indicating that it thinks the command was not sent properly -- even though it was. I don't understand why the JMicron unit doesn't accept this command. It simply appears to be broken. Does it work if you plug it into a computer running Windows or Mac OS X? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about xhci bandwidth
On Wed, Aug 29, 2012 at 6:53 AM, loody milo...@gmail.com wrote: hi all: I saw there are 2 trbs about bandwidth as below: #define TRB_GET_BW 21 #define TRB_BANDWIDTH_EVENT 35 Would any one tell me where I can see driver use these 2 trbs for bandwidth checking, since I cannot grep the implementation in the driver. It's defined by xHCI spec but currently not used by driver. They're less important. Thanks, Andiry -- Thanks for your help, -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, Sep 2, 2012 at 8:57 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Sun, Sep 2, 2012 at 6:47 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 2 Sep 2012, Alon Bar-Lev wrote: Attached usbmon, I hope I've done this OK. The errors start here: 880112a12d80 3034504955 S Bo:2:009:2 -115 31 = 55534243 0a00 0010 8a28 0008 00 880112a12d80 3034505013 C Bo:2:009:2 0 31 880132074d80 3034505019 S Bi:2:009:1 -115 4096 880132074d80 3034505155 C Bi:2:009:1 -32 0 880112a12d80 3034505161 S Co:2:009:0 s 02 01 0081 0 880112a12d80 3034505298 C Co:2:009:0 0 0 880112a12d80 3034505308 S Bi:2:009:1 -115 13 880112a12d80 3034505441 C Bi:2:009:1 0 13 = 55534253 0a00 02 This shows the computer asking the drive to read 8 blocks starting at block 0. The drive (actually the JMicron USB interface, not the drive itself) returns an error code indicating that it thinks the command was not sent properly -- even though it was. I don't understand why the JMicron unit doesn't accept this command. It simply appears to be broken. Does it work if you plug it into a computer running Windows or Mac OS X? Alan Stern Hi, I don't know... I don't use these... and the disk is ext4... I have XP in qemu, I mapped the device and took usbmon (attached), so you probably see plugin within Linux, the plugout, then windows takes charge. I see the disk in device manager, but not in disk manager... don't know why. Maybe this will help... Thanks, Alon. Windows 7 does shows the drive properly, but it is not VM so I cannot usbmon it :( Alon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, 2 Sep 2012, Alon Bar-Lev wrote: This shows the computer asking the drive to read 8 blocks starting at block 0. The drive (actually the JMicron USB interface, not the drive itself) returns an error code indicating that it thinks the command was not sent properly -- even though it was. I don't understand why the JMicron unit doesn't accept this command. It simply appears to be broken. Does it work if you plug it into a computer running Windows or Mac OS X? Alan Stern Hi, I don't know... I don't use these... and the disk is ext4... I have XP in qemu, I mapped the device and took usbmon (attached), so you probably see plugin within Linux, the plugout, then windows takes charge. I see the disk in device manager, but not in disk manager... don't know why. Maybe this will help... Yes, this shows what the problem is. It's a bug in the JMicron device. The usbmon trace shows that Windows uses READ FORMAT CAPACITIES and READ CAPACITY(10) commands to determine the size of the drive. These commands are not capable of reporting sizes larger than 2 TB, but they also say what the drive's block size is. They both say that the block size is 4096 bytes. Without your patch, Linux would also use READ CAPACITY(10). When it sees that the size is larger than 2 TB, it issues a READ CAPACITY(16) command, which _is_ capable of reporting the correct size of the drive. (With your patch, Linux tries READ CAPACITY(16) right away.) At any rate, it accepts the READ CAPACITY(16) results. But... READ CAPACITY(16) reports that the block size is 512 bytes, not 4096! Linux believes this value, and so when it wants to read 4096 bytes, it asks for 8 blocks. That's why the JMicron refused to carry out the read -- it realized that 8 blocks would be 32768 bytes, not 4096 bytes. Windows, on the other hand, believes the results from the other two commands and therefore knows that the block size is 4096. Therefore it is able to use the drive properly (although the usbmon trace doesn't show any place where Windows determines the drive's actual size). I can't see any reasonable way of fixing this problem. Even if Linux did settle for the READ CAPACITY(10) value, it would then think that the drive was only 2 TB. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to handle delays in isochronous transfers?
How should the lower USB layers handle delays in transferring isochronous data? I'm asking you because the most common usages of isochronous transfers are for audio and video. Here's an example to illustrate what I mean. Typically an audio or video driver will keep a queue of around 10 ms of data submitted to an isochronous endpoint. I have seen reports from users where URB completion interrupts were delayed by as much as 50 ms. In one case the delay was caused by a bug in a wireless drivers that left interrupts disabled; in another case the cause was unknown -- it might have been a hardware problem. At any rate, when this happens the endpoint's queue drains completely. Clearly this will cause a glitch in the data stream. The question is: What should we do to recover and re-synchronize? I am not sure if feedback endpoint is implemented at our ISO-transfer class driver. If it is implemented, the class driver will take responsible to speed up/slow down transferring according to the device's feedback information. For non-supported feedback device, the device should take responsible for data loss or data too fast by changing codec clock freq or give up some data. Yes, the host controller may know if the data is really on the bus in time, and tell the class driver adjust the packet size, but device may have already changed its codec clock already or its behavior. Both host/device system high loading and clock not always the same between usb and codec at device side will cause the total payload is not the same between producer (host) and consumer (device) after sometime, so the feedback between device and host is the best way to keep data integrity. We could pretend nothing happened and continue to handle URBs normally, scheduling each submission for the next available slot. But for an isochronous-OUT transfer, this would mean that all the future data values are delayed by some 40 ms relative to the earlier data. If another glitch occurs then the following data will be delayed by even more. For some applications this might not matter, but for others (real-time things like voice) it could be quite bad. Similar problems arise with IN transfers. Alternatively, the host controller driver could fail the next 40 ms worth of isochronous URBs, so that the higher-level client catches up to where it should be. The failure could occur during submission, or the URBs could be accepted and then forced to complete immediately, with no data transferred. What's the right thing to do? My feeling is that the behavior should be decided not by the host controller driver but rather by the higher-level client. We could use the URB_ISO_ASAP flag for this purpose -- right now it is essentially useless. Or maybe we should do something else I haven't thought of. What would be the best approach for your purposes? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, 2 Sep 2012, Matthew Hall wrote: I can't see any reasonable way of fixing this problem. Even if Linux did settle for the READ CAPACITY(10) value, it would then think that the drive was only 2 TB. blasphemous_hack What about a quirk which gets the blocksize from the smaller commands and combines with the device size from the larger command? It's not quite that simple. The trace showed that two different commands gave the right block size, and we don't know which one Windows believed. I suppose we could figure out the answer to that. It might work. But the only justification would be That's the way Windows does it... which might not be strong enough. Especially since different versions of Windows might do it in different ways. /blasphemous_hack Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, Sep 02, 2012 at 10:43:25PM -0400, Alan Stern wrote: On Sun, 2 Sep 2012, Matthew Hall wrote: I can't see any reasonable way of fixing this problem. Even if Linux did settle for the READ CAPACITY(10) value, it would then think that the drive was only 2 TB. blasphemous_hack What about a quirk which gets the blocksize from the smaller commands and combines with the device size from the larger command? It's not quite that simple. The trace showed that two different commands gave the right block size, and we don't know which one Windows believed. I suppose we could figure out the answer to that. It might work. But the only justification would be That's the way Windows does it... which might not be strong enough. Especially since different versions of Windows might do it in different ways. /blasphemous_hack How about a dummy read which only can work when you've discovered the size correctly? You noticed one failed right that occurred due to the mismatch in the block size. Alan Stern Matthew. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
