Re: [PATCH] usb: storage: Add ums-cros-aoa driver
e_init(cros_aoa_init);
> +module_exit(cros_aoa_exit);
> diff --git a/drivers/usb/storage/initializers.c
> b/drivers/usb/storage/initializers.c
> index f8f9ce8dc7102..3056db79cd1d9 100644
> --- a/drivers/usb/storage/initializers.c
> +++ b/drivers/usb/storage/initializers.c
> @@ -92,3 +92,37 @@ int usb_stor_huawei_e220_init(struct us_data *us)
> usb_stor_dbg(us, "Huawei mode set result is %d\n", result);
> return 0;
> }
> +
> +#if defined(CONFIG_USB_STORAGE_CROS_AOA) || \
> + defined(CONFIG_USB_STORAGE_CROS_AOA_MODULE)
> +/*
> + * Our VID/PID match grabs any Android device that was switched into Android
> + * Open Accessory mode. We only want to bind to the one that was switched by
> the
> + * ums-cros-aoa driver. There's no 100% way to identify the same device again
> + * (because it changes all descriptors), but checking that it is on the same
> bus
> + * with the same topology route should be a pretty good heuristic.
> + */
> +int usb_stor_cros_aoa_bind_busnum = -1;
> +EXPORT_SYMBOL(usb_stor_cros_aoa_bind_busnum);
> +u32 usb_stor_cros_aoa_bind_route;
> +EXPORT_SYMBOL(usb_stor_cros_aoa_bind_route);
> +
> +int usb_stor_cros_aoa_validate(struct us_data *us)
> +{
> + if (us->pusb_dev->bus->busnum != usb_stor_cros_aoa_bind_busnum ||
> + us->pusb_dev->route != usb_stor_cros_aoa_bind_route) {
> + dev_info(&us->pusb_intf->dev,
> +"ums-cros-aoa ignoring unknown AOA device\n");
> + return -ENODEV;
> + }
> +
> + /*
> +* Only interface 0 connects to the AOA app. Android devices that have
> +* ADB enabled also export an interface 1. We don't want it.
> +*/
> + if (us->pusb_intf->cur_altsetting->desc.bInterfaceNumber != 0)
> + return -ENODEV;
> +
> + return 0;
> +}
> +#endif /* defined(CONFIG_USB_STORAGE_CROS_AOA) || ... */
> diff --git a/drivers/usb/storage/initializers.h
> b/drivers/usb/storage/initializers.h
> index 2dbf9c7d97492..35fe9ef3247d6 100644
> --- a/drivers/usb/storage/initializers.h
> +++ b/drivers/usb/storage/initializers.h
> @@ -37,3 +37,7 @@ int usb_stor_ucr61s2b_init(struct us_data *us);
>
> /* This places the HUAWEI E220 devices in multi-port mode */
> int usb_stor_huawei_e220_init(struct us_data *us);
> +
> +extern int usb_stor_cros_aoa_bind_busnum;
> +extern u32 usb_stor_cros_aoa_bind_route;
> +int usb_stor_cros_aoa_validate(struct us_data *us);
> diff --git a/drivers/usb/storage/unusual_devs.h
> b/drivers/usb/storage/unusual_devs.h
> index ea0d27a94afe0..45fe9bbc6da18 100644
> --- a/drivers/usb/storage/unusual_devs.h
> +++ b/drivers/usb/storage/unusual_devs.h
> @@ -2259,6 +2259,24 @@ UNUSUAL_DEV( 0x1e74, 0x4621, 0x, 0x,
> USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> US_FL_BULK_IGNORE_TAG | US_FL_MAX_SECTORS_64 ),
>
> +/*
> + * Using an Android phone as USB storage back-end for Chrome OS recovery. See
> + * usb/storage/cros-aoa.c for details.
> + */
> +#if defined(CONFIG_USB_STORAGE_CROS_AOA) || \
> + defined(CONFIG_USB_STORAGE_CROS_AOA_MODULE)
> +UNUSUAL_DEV( 0x18d1, 0x2d00, 0x, 0x,
> + "Google",
> + "Chrome OS Recovery via AOA",
> + USB_SC_SCSI, USB_PR_BULK, usb_stor_cros_aoa_validate,
> + US_FL_SINGLE_LUN | US_FL_CAPACITY_OK),
> +UNUSUAL_DEV( 0x18d1, 0x2d01, 0x, 0x,
> + "Google",
> + "Chrome OS Recovery via AOA (with ADB)",
> + USB_SC_SCSI, USB_PR_BULK, usb_stor_cros_aoa_validate,
> + US_FL_SINGLE_LUN | US_FL_CAPACITY_OK),
> +#endif /* defined(CONFIG_USB_STORAGE_CROS_AOA) || ... */
> +
> /* Supplied with some Castlewood ORB removable drives */
> UNUSUAL_DEV( 0x2027, 0xa001, 0x, 0x,
> "Double-H Technology",
> --
> 2.20.1
>
--
Matthew Dharm
Former Maintainer, USB Mass Storage driver for Linux
Re: [BUG] usb: USB Mass Storage - USB cable is bad warning
FYI, this message is *not* coming from usb-storage. While your device
happens to be a storage device, this message comes from a lower USB
layer.
Matt
On Sat, Sep 22, 2018 at 2:06 PM Barry Grussling wrote:
>
> When I plug my USB reader (11b0:6348) into my computer (MSI X399
> Carbon Pro, Threadripper 1900X),
> I get warnings about a bad usb cable:
> Sep 22 11:11:51 ciri kernel: usb 5-3.3-port4: Cannot enable. Maybe the
> USB cable is bad?
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: new high-speed USB device
> number 15 using xhci_hcd
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: New USB device found,
> idVendor=11b0, idProduct=6348, bcdDevice= 1.11
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: New USB device strings:
> Mfr=1, Product=2, SerialNumber=3
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: Product: USB3.0 Media Reader
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: Manufacturer: Kingston
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: SerialNumber: 201402131335
> Sep 22 11:11:52 ciri kernel: usb-storage 5-3.3.4:1.0: USB Mass Storage
> device detected
> Sep 22 11:11:52 ciri kernel: scsi host11: usb-storage 5-3.3.4:1.0
>
> This warning shows up on all USB3 ports that I plug it in to (tried 3
> of them directly off the MB).
> I have also tried it using on the other side of a USB3 hub (2109:8110)
> and still receive the
> same message. I have tried 3 different USB cables and all report the
> same warning.
>
> If I instead plug into one of the USB2 only ports ("console ports" on
> MB) I get no warning:
> Sep 22 11:37:15 ciri kernel: usb 1-12: new high-speed USB device
> number 8 using xhci_hcd
> Sep 22 11:37:15 ciri kernel: usb 1-12: New USB device found,
> idVendor=11b0, idProduct=6348, bcdDevice= 1.11
> Sep 22 11:37:15 ciri kernel: usb 1-12: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> Sep 22 11:37:15 ciri kernel: usb 1-12: Product: USB3.0 Media Reader
> Sep 22 11:37:15 ciri kernel: usb 1-12: Manufacturer: Kingston
> Sep 22 11:37:15 ciri kernel: usb 1-12: SerialNumber: 201402131335
> Sep 22 11:37:15 ciri kernel: usb-storage 1-12:1.0: USB Mass Storage
> device detected
> Sep 22 11:37:15 ciri kernel: scsi host11: usb-storage 1-12:1.0
>
> The warning appears to be mostly benign, as functionality appears to
> be unaffected. It did
> result in me purchasing a few replacement USB cables in an attempt to
> remove the warning.
>
> Anything I can do to "fix" this? I have verified the USB reader
> (FCR-HS3) is running the latest
> firmware from Kingston.
>
> I am running Linux v4.19-rc4-89-g6ad49fa1993d.
>
> Thanks,
>
> Barry
>
> (Opened https://bugzilla.kernel.org/show_bug.cgi?id=201209 before
> being redirected here).
--
Matthew Dharm
Former Maintainer, USB Mass Storage driver for Linux
Re: [PATCH] Add Apple Carplay driver
Why is this a kernel-level driver, rather than a userspace application that uses libusb to send the single vendor-specific command required? Since this command would be applicable to many CarPlay devices, with many different VID/PIDs, it would seem to make more sense as a userspace app that took a reference to a USB device or VID/PID. Matt On Tue, Mar 13, 2018 at 11:02 PM, Chunfeng Yun wrote: > From bf48dcd9cb254576cfea373c9a5d2ab996408895 Mon Sep 17 00:00:00 2001 > From: Chunfeng Yun > Date: Tue, 13 Mar 2018 11:47:38 +0800 > Subject: [PATCH] Add Apple Carplay driver > > Some Apple devices which support Carplay can enter USB Host Mode from USB > Device Mode after receiving a specific USB Vendor Request. There is a > requirement apply to accesssories that support the USB dual role switch > feature, and must have a USB-A receptacle that is capable of functioning > in both USB Host and USB Device roles. > It means that the driver should supports manual Dual-Role switch, due to > no IDDIG pin is avaliable. > > There is no suitable place to add this spicific USB Vendor Request, so > here I extract a single driver which allow user force to send it by a debug > interface when need it, and keep it independent on USB Dual-Role Controller > Drivers. > But to implement carplay feature, there are some requirments for USB Dual-Role > Driver: > 1. supports manual dual-role switch, such as, by a debug interface; > 2. keep vbus alive even when switch host into device mode; > > More information please refer to "Chapter 46. USB Role Switch" in > MFI Accessroy Interface Specification.pdf > > Chunfeng Yun (1): > usb: misc: supports Apple Carplay driver > > drivers/usb/misc/Kconfig |9 +++ > drivers/usb/misc/Makefile |1 + > drivers/usb/misc/carplay.c | 193 > > 3 files changed, 203 insertions(+) > create mode 100644 drivers/usb/misc/carplay.c > > -- > 1.7.9.5 > > > -- > 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 -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux -- 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: [BUG] USB mass storage device incomplete read command sequence
The TUR commands come from the sd_mod (I think). Definitely not from usb-storage. So I would take it up at that level. Matt On Wed, Jan 3, 2018 at 4:25 PM, Eduardo Trápani wrote: > Usually the kernel reads the pendrive like this: > > TEST UNIT READY > READ(10) > ... > READ(10) > TEST UNIT READY > > But under some conditions, the last TEST UNIT READY is not being sent > and because of that, on this device: Kingston DT 101 G2, the drive's > activity light keeps on blinking even though nothing is being done (no > read/writes/inquiries). > > When that happens, manually sending a TEST UNIT READY stops the blinking > and turns off the light. > > # sg_turs /dev/sdc > > For example this works alright (light blinks for a moment and then it's > off): > > # dd if=/dev/sdc of=/dev/null bs=512 count=96 > > But this doesn't (the light keeps on blinking forever) > > # dd if=/dev/sdb of=/dev/null bs=512 count=97 > > I checked with usbmon and I noticed the lack of the final TEST UNIT > READY in the cases where the light keeps on blinking. > > For the tests the drive was unmounted. As soon as I mount it and start > working on it, the light will blink non-stop. > > I also tested this with a Raspberry (Linux frambo 4.1.17+ #838 Tue Feb 9 > 12:57:10 GMT 2016 armv6l GNU/Linux), and the device behaves normally, > that is, blinking stops as soon as traffic stops. > > > Find attached the pcap file for both cases and part of the kernel dmesg. > This is the kernel with the problem: Linux arbo 4.9.0-4-amd64 #1 SMP > Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 GNU/Linux > > Eduardo. > -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH 2/9] USB: storage: Remove redundant license text
Alan, this might also be a good time to remove the "Please see [...] for more information" bits also. That URL hasn't worked for well, a very very long time. Matt On Fri, Nov 3, 2017 at 7:45 AM, Alan Stern wrote: > On Fri, 3 Nov 2017, Greg Kroah-Hartman wrote: > >> Now that the SPDX tag is in all USB files, that identifies the license >> in a specific and legally-defined manner. So the extra GPL text wording >> can be removed as it is no longer needed at all. >> >> This is done on a quest to remove the 700+ different ways that files in >> the kernel describe the GPL license text. And there's unneeded stuff >> like the address (sometimes incorrect) for the FSF which is never >> needed. >> >> No copyright headers or other non-license-description text was removed. >> >> Cc: Alan Stern >> Cc: Oliver Neukum >> Signed-off-by: Greg Kroah-Hartman >> --- > > Acked-by: 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 -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux -- 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: CPU lock-ups with 4.12.0+ kernels related to usb_storage
; Jul 11 06:48:41 localhost kernel: [ 8178.540466] ? > __blk_mq_complete_request+0xd7/0x170 > Jul 11 06:48:41 localhost kernel: [ 8178.540467] ? > usb_stor_control_thread+0xf0/0x250 [usb_storage] > Jul 11 06:48:41 localhost kernel: [ 8178.540469] ? > fill_inquiry_response+0x20/0x20 [usb_storage] > Jul 11 06:48:41 localhost kernel: [ 8178.540470] ? kthread+0x118/0x130 > Jul 11 06:48:41 localhost kernel: [ 8178.540472] ? > kthread_create_on_node+0x70/0x70 > Jul 11 06:48:41 localhost kernel: [ 8178.540473] ? ret_from_fork+0x25/0x30 > Jul 11 06:48:41 localhost kernel: [ 8178.540473] Code: 39 c2 74 a5 89 c2 89 > d0 66 31 c0 41 39 c0 74 ea 4d 85 c9 c6 07 01 74 21 41 c7 41 08 01 00 00 00 > eb 87 41 ff c9 75 04 f3 c3 f3 90 <8b> 07 84 c0 75 f8 66 c7 07 01 00 c3 f3 90 > 4c 8b 09 4d 85 c9 74 > > I'm happy to supply extra configuration information and run tests. > > If it is worthwhile doing a git-bisect on usb-storage I could do that also. > > Arthur. -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH] usb-storage: MAINTAINERS: Alan Stern is the new maintainer
On Tue, Aug 30, 2016 at 10:19 AM, Greg KH wrote: > On Thu, Aug 25, 2016 at 08:52:38AM -0700, Matthew Dharm wrote: >> On Thu, Aug 25, 2016 at 8:30 AM, Alan Stern >> wrote: >> > At Matt Dharm's request, I am taking over maintainership of the >> > usb-storage driver. >> >> > Signed-off-by: Alan Stern >> Acked-by: Matthew Dharm > > Thanks Matthew for all of your work on the driver and the USB stack over > the years, I hope you aren't going to run away, we can always use your > help :) Oh, I think I'll keep lurking like I have been for a few years now. I recognize that I've got a lot of historical perspective, and every so often someone asks about why a particular design decision was made. I'm also still hosting the usb-storage list, which doesn't get much traffic, but occasionally people go there for help; I'll continue to do that for as long as it's reasonably possible. Matt -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH] usb-storage: MAINTAINERS: Alan Stern is the new maintainer
On Thu, Aug 25, 2016 at 8:30 AM, Alan Stern wrote: > At Matt Dharm's request, I am taking over maintainership of the > usb-storage driver. Alan is being too modest. I think he's been the de facto maintainer already for quite some time; he's certainly much more active with responding to questions and bug reports on the mailing lists. This change just makes it official. It's something I've been thinking about doing for a long time, and a recent e-mail from a project noting that there are maintainers who have not submitted any patches in at least 3 years finally got me off-the-bubble. > Signed-off-by: Alan Stern Acked-by: Matthew Dharm > > --- > > > [as1811] > > > MAINTAINERS |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: usb-4.x/MAINTAINERS > === > --- usb-4.x.orig/MAINTAINERS > +++ usb-4.x/MAINTAINERS > @@ -12163,7 +12163,7 @@ S: Maintained > F: drivers/net/usb/lan78xx.* > > USB MASS STORAGE DRIVER > -M: Matthew Dharm > +M: Alan Stern > L: linux-usb@vger.kernel.org > L: usb-stor...@lists.one-eyed-alien.net > S: Maintained > -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux -- 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:
The delay is present because we discovered many usb-storage devices that were not ready to accept commands immediately after insertion. We studied the behavior of Microsoft Windows and discovered it used a small delay before sending commands to the device, and thus we also implemented a delay. Some devices will work with delay_use = 0. Some will not. Matt On Thu, Mar 3, 2016 at 4:24 AM, Lipengcheng wrote: > Hi, > >Please tell me why the process to delay to call in the 1s? The delay_use > = 0, we also found no side effects.So we can set the delay_use = 0? > > > > drivers/usb/storage/usb.c > > > > Best Regards, > > Pengcheng Li -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: LogiLink USB SATA HDD 2x docking station
bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 8 Mass Storage > bInterfaceSubClass 6 SCSI > bInterfaceProtocol 80 Bulk-Only > iInterface 6 MSC Bulk-Only Transfer > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 15 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 15 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 1 > bNumEndpoints 4 > bInterfaceClass 8 Mass Storage > bInterfaceSubClass 6 SCSI > bInterfaceProtocol 98 > iInterface 10 MSC BOT/UAS Transfer > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Command pipe (0x01) > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > MaxStreams 32 > Status pipe (0x02) > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 15 > MaxStreams 32 > Data-in pipe (0x03) > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x04 EP 4 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 15 > MaxStreams 32 > Data-out pipe (0x04) > Binary Object Store Descriptor: > bLength 5 > bDescriptorType15 > wTotalLength 22 > bNumDeviceCaps 2 > USB 2.0 Extension Device Capability: > bLength 7 > bDescriptorType16 > bDevCapabilityType 2 > bmAttributes 0x0f0e > Link Power Management (LPM) Supported > SuperSpeed USB Device Capability: > bLength10 > bDescriptorType16 > bDevCapabilityType 3 > bmAttributes 0x00 > wSpeedsSupported 0x000e > Device can operate at Full Speed (12Mbps) > Device can operate at High Speed (480Mbps) > Device can operate at SuperSpeed (5Gbps) > bFunctionalitySupport 1 > Lowest fully-functional device speed is Full Speed (12Mbps) > bU1DevExitLat 10 micro seconds > bU2DevExitLat 32 micro seconds > Device Status: 0x000d > Self Powered > U1 Enabled > U2 Enabled > > The issue is Linux specific, because the same machine when booted in Windows > 7 > detects both disks without installing any vendor drivers: > http://imgur.com/Fakviqk > > Any ideas? > Could it be that Linux does not detect the second storage device > because LogiLink provides the same SerialNumber for both disks? > > -- > 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 -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH] usb: storage: scsiglue: increase transfer size limit
IIRC, the sysfs attribute doesn't exist until after the device is probed, and the SCSI probing might fail (can't read partition tables, leading to errors, catastrophic failure) if the max-sectors is too high during probing. While I agree 20-25% performance gain is significant, a high failure-rate is also significant. And, while it's been many years, do *you* want to field all the e-mails from people who say the device they've been using for years is suddenly dead? I think the best compromise is to only adjust the limit up for USB 3 devices. That pretty much guarantees a "newer" device, which should hopefully behave better. Matt On Thu, Oct 29, 2015 at 1:56 PM, Felipe Balbi wrote: > > Hi, > > Alan Stern writes: >> On Thu, 29 Oct 2015, Matthew Dharm wrote: >> >>> Uhh... I think this is a bad idea. The 120K limit was chosen based on >>> seeing a lot of devices which broke if you tried to transfer more. At >>> least, that's my memory. Otherwise, it's a really goofy number. >>> >>> I certainly wouldn't mind you increasing it in the case of a USB 3.x >>> device, but not globally. >> >> That's what I remember also. Besides, we have a sysfs interface for >> changing this value, so the number in the driver doesn't have to be >> permanent for every device. > > We can't really expect users to fiddle with sysfs to get better > throughput, right ? :-) > > Moreover, the same way that we can use sysfs to increase max_sectors, we > can use it to decrease everytime we find a broken device. I really > wonder if they still are available in the market. So, wouldn't a better > default be 2048 and we decrease this as quirk flags when people complain > about regressions ? I mean, 20~25% improvement is quite considerable > >> In fact, there are quite a few USB storage devices which break if you >> try to transfer more than 64 KB at a time. That's what Windows uses by >> default (although maybe they use a larger value for USB-3 devices). > > I have no idea what MS uses as default so I'll just take your word for > it, unless you have some evidence of this statement somewhere. > > I just tested this with 3 other devices I have around and they behaved > with either setting. I wonder if the original breakage could've been due > to a bug in the SCSI layer which has long been fixed ? I mean, how many > years ago are we talking about here ? 10 ? > > cheers > > -- > balbi -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH] usb: storage: scsiglue: increase transfer size limit
(Resend, as I forgot to switch to plain-text for linux-usb@vger rules).
Uhh... I think this is a bad idea. The 120K limit was chosen based on
seeing a lot of devices which broke if you tried to transfer more. At
least, that's my memory. Otherwise, it's a really goofy number.
I certainly wouldn't mind you increasing it in the case of a USB 3.x
device, but not globally.
Matt
On Thu, Oct 29, 2015 at 1:21 PM, Felipe Balbi wrote:
> Instead of using only 120K for transfer size, let's
> increase it to 1024K. This has a very noticeable
> impact on USB3 storage devices.
>
> The following measurements were done with v4.2 on
> the host side and latest linux-next available at the
> time (20151022). Following are results with default
> and modified max_sectors. Each number is the average
> of 100 measurements with each of the two settings.
>
> Pre 244.87
> Post322.10
>
> That's a 24% increase in throughput by just allowing
> more sectors to transferred in a single
> request. Considering there are other SCSI devices
> using 2048 (and sometimes more) max_sectors, this
> shouldn't bring any surprises to anybody other than
> the extra memory used.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/storage/scsiglue.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index dba51362d2e2..36450111e8b8 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -565,8 +565,8 @@ static const struct scsi_host_template
> usb_stor_host_template = {
> /* lots of sg segments can be handled */
> .sg_tablesize = SCSI_MAX_SG_CHAIN_SEGMENTS,
>
> - /* limit the total size of a transfer to 120 KB */
> - .max_sectors = 240,
> + /* limit the total size of a transfer to 1024 KB */
> + .max_sectors = 2048
>
> /* merge commands... this seems to help performance, but
> * periodically someone should test to see which setting is more
> --
> 2.6.2
>
--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
--
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: [PATCH] usb-storage: ignore ZTE MF 823 in mode 0x1225
On Wed, Jul 1, 2015 at 8:36 AM, Lars Melin wrote: > On 2015-07-01 19:24, Oliver Neukum wrote: >> >> This device automatically switches itself to another mode (0x1405) >> unless the specific access pattern of Windows is followed in its >> initial mode. That makes a dirty unmount of the internal storage >> devices inevitable if they are mounted. So the devices should >> be ignored. >> > The storage device is a virtual cd-rom drive in the dongles internal > flash rom, why do you care if non-writable storage is unmounted dirty? > > Prohibiting the usb-storage driver to bind makes it impossible for > usb_modeswitch to switch the device to one of its other id's.. Lars -- In a separate thread, it was discussed that this device has a SD reader in it. Thus, it's possible to mount the SD card and get it dirty and then have it yanked-out from underneath us by this unprompted mode switch that the device does. -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: External USB3 HDD: logical sector size incorrectly detected on first connect
billion 512-byte blocks. Then the >> computer sends READ CAPACITY(16), and the drive responds by saying that >> it has 732566645 (less than 4 billion!) 4096-byte blocks. There's no >> way to know why it changes its mind about the block size. >> >> When the computer sends another READ CAPACITY(10) command later on, the >> drive says the block size is 4096. It really does send different >> responses to the same command at different times. > > OK, so obviously the drive is doing something wrong. I'm just confused about > why one way works and not the other: > > - Boot up the computer with the drive attached: failure. > > - Boot up the computer without the drive attached, load the required kernel > modules, and plug it in: success. > > I would think that, if it's solely the drive's fault, neither case would work, > since in both cases I'm plugging the drive in for the first time and it has > not spun up yet, and in both cases the uas and usb-storage modules are loaded > beforehand (albeit with a larger delay in the second case). That is: what is > the difference from the drive's perspective? > > (Also, why does Windows, without any manually installed drivers, work, then?) > > This, and all the other situations I described where the drive worked fine > (such as turning the drive off for several hours), make me wonder whether you > or anybody else on this list know of any drives/usb adapters that behave in > strange ways when they are connected at boot up like this (for example, I read > of older drives that would initially announce themselves as CD-ROM drives). > > Of course, if the diagnosis is definitely "the drive did it", then I'm willing > to resign myself to the notion that nothing can be done about it, however > disappointing that would be. > > -- > Marc Joliet > -- > "People who think they know everything really annoy those of us who know we > don't" - Bjarne Stroustrup -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH][RFC] storage: Reject bogus max LUN values
Is there a constant we can pull from a SCSI header, instead of having
a "magic number" in the code?
Matt
On Sun, Oct 12, 2014 at 5:54 PM, Alan Stern wrote:
> On Sun, 12 Oct 2014, Mark Knibbs wrote:
>
>> --- linux-3.17/drivers/usb/storage/transport.c.orig 2014-10-05
>> 20:12:36.0 +0100
>> +++ linux-3.17/drivers/usb/storage/transport.c2014-10-12
>> 13:11:38.0 +0100
>> @@ -1035,9 +1035,20 @@ int usb_stor_Bulk_max_lun(struct us_data
>> usb_stor_dbg(us, "GetMaxLUN command result is %d, data is %d\n",
>>result, us->iobuf[0]);
>>
>> - /* if we have a successful request, return the result */
>> - if (result > 0)
>> - return us->iobuf[0];
>> + /*
>> + * If we have a successful request, return the result if valid. The
>> + * CBW LUN field is 4 bits wide, so the value reported by the device
>> + * should fit into that.
>> + */
>> + if (result > 0) {
>> + if (!(us->iobuf[0] & 0xf0)) {
>
> Since the Max-LUN value is just a plain old number (with no special
> interpretations for the individual bits), it is easier to understand if
> the code treats it that way. Simply say:
>
> if (us->iobuf[0] < 16) {
>
>> + return us->iobuf[0];
>> + } else {
>> + dev_info(&us->pusb_intf->dev,
>> + "Max LUN %d is not valid, using 0 instead",
>> + us->iobuf[0]);
>> + }
>> + }
>>
>> /*
>>* Some devices don't like GetMaxLUN. They may STALL the control
>
> Apart from that minor issue,
>
> Acked-by: 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
--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
--
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: Iomega SCSI-to-USB cable problem
I seem to recall that the Iomega-branded versions of these are limited to only working with Iomega drives. You need the generic-branded version to work with any drive. Matt On Tue, Sep 2, 2014 at 6:18 AM, Mark wrote: > Hi, > > I have an Iomega SCSI-to-USB cable, model# SCSI USBA. Iomega called it the > Jaz USB Adapter; see > http://www.iomega.com/europe/support/english/manuals/jazusb/home.html > Picture: http://ecx.images-amazon.com/images/I/31Q4Z3PMT5L.jpg > > My cable has USB ID 059B:0040. It is identical in appearance to the > Microtech XpressSCSI, which does work with Linux. Both are probably OEM > products manufactured by Shuttle Technology/SCM Microsystems. > > I haven't been able to get my cable to work, though I only tested it with > non-Iomega drives. Has anyone used this cable with non-Iomega drives? > Either mine is faulty, or its firmware is designed to only work with > Iomega drives. (I think it's most likely faulty.) > > I get this dmesg output on powering on the SCSI device, inserting then > eventually disconnecting the USB cable: > [ 5908.360421] usb 7-1: new full speed USB device number 4 using uhci_hcd > [ 5910.564219] scsi8 : usb-storage 7-1:1.0 > [ 5913.704183] usb 7-1: reset full speed USB device number 4 using uhci_hcd > [ 5918.032207] usb 7-1: reset full speed USB device number 4 using uhci_hcd > [ 5922.348444] usb 7-1: reset full speed USB device number 4 using uhci_hcd > [ 5924.916423] usb 7-1: reset full speed USB device number 4 using uhci_hcd > [ 5965.296235] usb 7-1: USB disconnect, device number 4 > > I created usbmon and Wireshark captures when doing that. If anyone feels > like investigating, I have uploaded them (~5KB archive) to > http://www.mediafire.com/download/uw4d4dmcq8qfbwg/Iomega_SCSI-USB_problem.tar.gz > > -- > 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 -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Sat, Aug 30, 2014 at 2:15 PM, Alan Stern wrote: > On Fri, 29 Aug 2014, Matthew Dharm wrote: > >> Is there an 'easy' way to override the detected size of a storage >> device from userspace? If we had that, someone could write a helper >> application which looked for this particular fubar and try to Do The >> Right Thing(tm), or at least offer the user some options. > > You mean, force a Media Change event and override the capacity reported > by the hardware? I'm not aware of any API for doing that, although it > probably wouldn't be too hard to add one. > > How would the user know what value to put in for the capacity? Unless > the drive had been hooked up to a different computer and the user > manually noted the correct capacity and typed it in, it would have to > be guesswork. I didn't say it would be easy to figure out the right value, but at least it would be possible. I was thinking of something that could notice a USB device which is formatted NTFS and has a partition table and filesystem that indicates a much bigger capacity than what the drive reports. Under this circumstances, you could do something like pop-up a dialog box saying "this drive is confused -- is it 2TB or 3TB?" Well, maybe that would say "Drive capacity is not consistent with partition table. This can happen with certain USB drives designed for use with Windows. Override drive capacity (emulating Windows)?" You could imagine increasing complex heuristics to try to detect this scenario. Even without an automated helper program to do it, if there was a sysfs interface then when we got the periodic e-mails reporting this same type of problem, we could offer a quick-and-clean solution. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. Matt On Fri, Aug 29, 2014 at 2:07 PM, Dale R. Worley wrote: >> From: Alan Stern > >> If you try to repartition the drive under Windows using the deficient >> adapter, you'll see that the problem still exists. It just doesn't >> show up during normal use. > > So in summary, the Windows workaround is icky, but it allows any use > but repartitioning to be one on the attached disk. > > Dale > -- > 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 -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [GIT pull for 3.14 v3] xhci streams and uas fixes + usbfs streams support
I'm okay with these patches. No need to resend to the USB Storage list, tho I would appreciate such in the future. Acked-By: Matthew Dharm Matt On Wed, Dec 4, 2013 at 3:58 PM, Sarah Sharp wrote: > On Mon, Nov 18, 2013 at 03:39:05PM +0100, Hans de Goede wrote: >> Hi Sarah et al, > > Hi Hans, > >> Here is v3 of my patch-series / pull-req for you to pull into your xhci tree >> for 3.14. > > I was just about to start testing the code I merged from you, when I > realized the last round of patches didn't Cc the usb-storage mailing > list or Matthew Dharm. Since four of the patches interact with > usb-storage, it would be good to get his ACK on those: > > https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-queue&id=07f652720e3f > https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-queue&id=dda9e7db4e29 > https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-queue&id=91a4c4b94a40 > https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-queue&id=326aff723f82 > > Matthew, any objections to these patches? Do you want Hans to resend > the entire 70 patch set to the USB storage mailing list, or do you think > sending it to the USB mailing list was good enough? > > Sarah Sharp > >> New this version is that the "uas: Use proper packet size when submitting >> reponse urbs" patch has been dropped. As Gerd rightfully pointed out we >> won't know if we get a sense or response iu on the status endpoint when >> using usb-2, so the urb must be large enough to receive the largest iu >> type, which is the sense iu. So the old code was correct. >> >> The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: >> >> USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) >> >> are available in the git repository at: >> >> git://linuxtv.org/hgoede/gspca.git usb-next-for-sarah >> >> for you to fetch changes up to 8d0f187e6c19ed23e7df4b2f0b943ee784c7f1b2: >> >> uas: Remove comment about registering a uas scsi controller for each usb >> bus (2013-11-18 15:13:35 +0100) >> >> >> Gerd Hoffmann (6): >> xhci: fix usb3 streams >> uas: properly reinitialize in uas_eh_bus_reset_handler >> uas: make work list per-device >> uas: add dead request list >> uas: replace BUG_ON() + WARN_ON() with WARN_ON_ONCE() >> uas: remove BROKEN >> >> Hans de Goede (62): >> xhci: Free streams when they are still allocated on a set_interface >> call >> xhci: Check size rather then number of streams when allocating stream >> ctxs >> xhci: For streams the css flag most be read from the stream-ctx on ep >> stop >> xhci: Set SCT field for Set TR dequeue on streams >> xhci: For streams the dequeue ptr must be read from the stream ctx >> xhci: use usb_ss_max_streams in xhci_check_streams_endpoint >> usb-core: Fix usb_free_streams return value documentation >> usb-core: Move USB_MAXENDPOINTS definitions to usb.h >> usb-core: Track if an endpoint has streams >> usb-core: Free bulk streams on interface release >> usbfs: Kill urbs on interface before doing a set_interface >> usbfs: proc_do_submiturb use a local variable for number_of_packets >> usbfs: Add support for bulk stream ids >> usbfs: Add ep_to_host_endpoint helper function >> usbfs: Add support for allocating / freeing streams >> uas: Urbs must be anchored before submitting them >> uas: Properly set interface to altsetting 0 on probe failure >> uas: Avoid unnecessary unlock / lock calls around unlink_data_urbs >> uas: uas_alloc_cmd_urb: drop unused stream_id parameter >> uas: Fix uas not working when plugged into an ehci port >> uas: Fix reset locking >> uas: Fix reset handling for externally triggered reset >> uas: s/response_ui/response_iu/ >> uas: Fix response iu struct definition >> uas: Pack iu struct definitions >> uas: Use all available stream ids >> uas: Add a uas_find_uas_alt_setting helper function >> uas: Move uas detect code to uas-detect.h >> xhci: xhci_mem_cleanup: make sure cmd_ring_reserved_trbs really is 0 >> xhci: The trb_address_map radix tree expects 1KB segment memory >> aligment >> xhci: Handle MaxPSASize == 0 >> usb: Clear host_en
Re: [RFC] USB: storage: in-kernel modeswitching is deprecated
I'm happy with it, modulo Sergi's grammer comment. ACKed-by: Matthew Dharm mdharm-...@one-eyed-alien.net Matt On Mon, Mar 4, 2013 at 1:57 PM, Bjørn Mork wrote: > Signed-off-by: Bjørn Mork > --- > So, is something like this good enough? > > > Bjørn > > drivers/usb/storage/unusual_devs.h |8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/usb/storage/unusual_devs.h > b/drivers/usb/storage/unusual_devs.h > index d305a5a..1e03a45 100644 > --- a/drivers/usb/storage/unusual_devs.h > +++ b/drivers/usb/storage/unusual_devs.h > @@ -53,6 +53,14 @@ > * as opposed to devices that do something strangely or wrongly. > */ > > +/* In-kernel mode switching is deprecated. Do not add new devices to > + * this list for the sole purpose of switching to them to a different > + * mode. Existing userspace solutions are superior. > + * > + * New mode switching devices should instead be added to the database > + * maintained at http://www.draisberghof.de/usb_modeswitch/ > + */ > + > #if !defined(CONFIG_USB_STORAGE_SDDR09) && \ > !defined(CONFIG_USB_STORAGE_SDDR09_MODULE) > #define NO_SDDR09 > -- > 1.7.10.4 > -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH] USB: storage: fix Huawei mode switching regression
Frankly, I consider it appropriate. The question is not one of reminding me of what I said earlier it's one of pointing people in the right direction. Frankly, some of the fault for this patch lies with Greg and myself for letting it through. I had just assumed that the Huawei guys had already been in touch with usb-modeswitch for some reason, and that this was just an optimization of existing logic (not an expansion). And, frankly, I was just a bit tired of fighting this fight over and over again; having something in the file which says "here's the right and official way to do this" would be good. I also asked the Huawei guys about the possibility of affecting other devices than the one listed I guess one of us either wasn't clear or mis-understood the request. The fact that there are devices out there failing now illustrates that. Avoiding breaking existing systems is one of the highest priorities Who is maintaining usb-modeswitch these days, anyway? The comment in the file should point people directly there And, as of now, I would really like to see as many of these devices migrated (albeit slowly) to using usb-modeswitch wherever possible. I know there are a few devices for which that might not be possible, but I am DONE dealing with this same issue over and over and over again. It will certainly be work to migrate support; maybe we should wrap all the relevant unusual_devs.h entires with CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a transition period? Matt On Mon, Mar 4, 2013 at 8:47 AM, Bjørn Mork wrote: > Ben Hutchings writes: >> On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote: >> [...] >>> In-kernel mode switching was deprecated years ago with the >>> development of the more user friendly userspace alternatives. The >>> existing list of devices in usb-storage was only kept to prevent >>> breaking already working systems. The long term plan is to remove >>> the list, not to add to it. Ref: >>> http://permalink.gmane.org/gmane.linux.usb.general/28543 >> [...] >> >> Can you add a comment to this effect? > > In the table in unusual_devs.h, you mean? Sure, I can do that. > > But it feels a bit strange since I can only quote and/or refer to what > Matthew and Greg said about the issue years ago. Putting a comment in > the code to remind the current maintainers about their own statements > could be considered out of line? Or is this appropriate here? > > > Bjørn -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH] USB Storage: add support for Maxtor One-Touch button
An interesting catch. The test on line 249 should probably be (maxp > ONETOUCH_PKT_LEN ? ONETOUCH_PKT_LEN : maxp) -- in other words, limit the interrupt transfer to the smaller of 2 or max packet size for the endpoint. There is a similar (correctly done) test in usb_stor_intr_transfer in transport.c Care to submit a patch to Greg? Matt On Wed, Feb 27, 2013 at 4:33 AM, Dan Carpenter wrote: > Hello Matthew Dharm, > > This is an old warning but it looks like it might be valid. > > The patch 34008dbfe8c0: "[PATCH] USB Storage: add support for Maxtor > One-Touch button" from Jul 28, 2005, leads to the following Smatch > warning: > "drivers/usb/storage/onetouch.c:248 onetouch_connect_input() > error: usb_fill_int_urb() 'onetouch->data' too small (2 vs 9)" > > [ This requires some database configuration to get this warning ]. > > > drivers/usb/storage/onetouch.c >197 maxp = usb_maxpacket(udev, pipe, usb_pipeout(pipe)); > > maxp depends on the end point. > >198 >199 onetouch = kzalloc(sizeof(struct usb_onetouch), GFP_KERNEL); >200 input_dev = input_allocate_device(); >201 if (!onetouch || !input_dev) >202 goto fail1; >203 >204 onetouch->data = usb_alloc_coherent(udev, ONETOUCH_PKT_LEN, > ^^ > ONETOUCH_PKT_LEN is 0x02 so we are ->data is 2 bytes. > >205 GFP_KERNEL, > &onetouch->data_dma); >206 if (!onetouch->data) >207 goto fail1; >208 > > [ snip ]. > >245 input_dev->open = usb_onetouch_open; >246 input_dev->close = usb_onetouch_close; >247 >248 usb_fill_int_urb(onetouch->irq, udev, pipe, onetouch->data, >249 (maxp > 8 ? 8 : maxp), > ^^^ > If we use 8 as the transfer size and ->data is only 2 bytes then it > could corrupt memory. (Smatch incorrectly thinks this parameter can > be 9, but even 8 would be too high). > >250 usb_onetouch_irq, onetouch, > endpoint->bInterval); >251 onetouch->irq->transfer_dma = onetouch->data_dma; >252 onetouch->irq->transfer_flags |= URB_NO_TRANSFER_DMA_MAP; >253 > > regards, > dan carpenter > -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [usb-storage] Issue with mini-SaS to eSATA to USB 3.0 setup
s >> >> /var/log/messages >> >> Jan 27 18:00:28 localhost kernel: usb 7-1: New USB device found, >> idVendor=2109, idProduct=0810 >> Jan 27 18:00:28 localhost kernel: usb 7-1: New USB device strings: >> Mfr=1, Product=2, SerialNumber=0 >> Jan 27 18:00:28 localhost kernel: usb 7-1: Product: 4-Port USB 3.0 Hub >> Jan 27 18:00:28 localhost kernel: usb 7-1: Manufacturer: VIA Labs, Inc. >> Jan 27 18:00:28 localhost kernel: usb 7-1: configuration #1 chosen from 1 >> choice >> Jan 27 18:00:28 localhost kernel: hub 7-1:1.0: USB hub found >> Jan 27 18:00:28 localhost kernel: hub 7-1:1.0: 4 ports detected >> >> Jan 28 21:32:02 localhost kernel: usb 7-1.1: new SuperSpeed USB device >> number 9 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: PCI INT A -> >> GSI 16 (level, low) -> IRQ 16 >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: xHCI Host Controller >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: new USB bus >> registered, assigned bus number 6 >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: irq 16, io >> mem 0xdfe0 >> Jan 28 21:32:56 localhost kernel: usb usb6: Manufacturer: Linux >> 2.6.32-279.19.1.el6.i686 xhci_hcd >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: xHCI Host Controller >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: new USB bus >> registered, assigned bus number 7 >> Jan 28 21:32:56 localhost kernel: usb usb7: Manufacturer: Linux >> 2.6.32-279.19.1.el6.i686 xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1: new SuperSpeed USB device >> number 2 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.1: new SuperSpeed USB device >> number 3 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.2: new SuperSpeed USB device >> number 4 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.3: new SuperSpeed USB device >> number 5 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.4: new SuperSpeed USB device >> number 6 using xhci_hcd > > > -- > You received this message because you are subscribed to the Google Groups > "USB Mass Storage on Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to usb-storage+unsubscr...@lists.one-eyed-alien.net. > To post to this group, send email to usb-stor...@lists.one-eyed-alien.net. > Visit this group at > http://groups.google.com/a/lists.one-eyed-alien.net/group/usb-storage/?hl=en. > For more options, visit > https://groups.google.com/a/lists.one-eyed-alien.net/groups/opt_out. > > -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [usb-storage + sd] Driver fails to read e-reader av (autovision) 606
Ronald -- A quick review on the verbose log shows a few interesting things: 1) The device claims to use the USB Mass Storage Class, so it should work with usb-storage. 2) The device identifies itself to the SCSI layer as "rockchip rk28 sdk demo" -- a string like that is not very encouraging to me in terms of believing this is a released and fully-tested prodcut. 3) The device should appear as /dev/sdb according to the logs 4) Something in your system is polling the device, waiting for it to become "ready". HOWEVER, the device is continually answering with "Not Ready: Medium not present" Matt On Thu, Feb 14, 2013 at 10:47 PM, Ronald wrote: >> This e-mail is a follow-up as requested in this bug[1]. I will repost >> everything so far in this e-mail. Please CC me as I'm not subscribed >> to your list. >> >> We have acquired an e-reader which says: 'AV Autovision AV606'. I have >> confirmed with the distributer that it uses the usb-storage driver >> (not MTP). Did try that though, didn't work. >> >> Attached: >> [2] lsusb -v >> [3] kernel spew of v3.4 kernel the spawned sg[0-3] nodes all fail to mount >> >> Any direction, suggestion on how to proceed? I cannot provide more >> info as I don't know what to provide anymore. Please tell. Would like >> to use this e-reader with Linux. Otherwise an alternative OS is being >> preferred by it's daily users... :( >> >> I Would like to reassure you that I tested this with 3.8.0-rc7+ + the >> latest nouveau tree. These patches are not intrusive. I have v3.4 >> kernel output here since I tried a liveCD (Gentoo based linux >> rescuecd). It's kernel seems to have more debug options enabled. >> >> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=53891 >> [2]: Attachment 'E-reader lsusb output.txt' >> [3]: Attachment 'E-reader dmesg output.txt' > > I attached a new document[1] with verbose USB logging while connecting > the E-reader. This is with today's kernel git + nouveau git of today > (v3.8-rc7+). It's pretty big btw... > > I also enabled verbose SCSI logging, but didn't see some of that come > back in the logs. -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH 1/2]linux-usb:Define a new macro for USB storage match rules
On Fri, Jan 25, 2013 at 6:05 PM, Greg KH wrote:
> On Sat, Jan 26, 2013 at 01:39:50AM +, Fangxiaozhi (Franko) wrote:
>>
>>
>> > -Original Message-
>> > From: Greg KH [mailto:g...@kroah.com]
>> > Sent: Saturday, January 26, 2013 1:45 AM
>> > To: Fangxiaozhi (Franko)
>> > Cc: Sergei Shtylyov; linux-usb@vger.kernel.org;
>> > linux-ker...@vger.kernel.org;
>> > Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger,
>> > Credit);
>> > Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
>> > sebast...@breakpoint.cc
>> > Subject: Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match
>> > rules
>> >
>> > On Fri, Jan 25, 2013 at 04:18:34PM +0400, Sergei Shtylyov wrote:
>> > > Hello.
>> > >
>> > > On 25-01-2013 6:44, fangxiaozhi 00110321 wrote:
>> > >
>> > > >From: fangxiaozhi
>> > >
>> > > >1. Define a new macro for USB storage match rules:
>> > > > matching with Vendor ID and interface descriptors.
>> > >
>> > > >Signed-off-by: fangxiaozhi
>> > > >
>> > > >
>> > > > diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c
>> > > >linux-3.8-rc4/drivers/usb/storage/usb.c
>> > > >--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c 2013-01-22
>> > > >14:12:42.595238727 +0800
>> > > >+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22
>> > > >+++ 14:16:01.398250305 +0800
>> > > >@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, "supplemental l
>> > > > .useTransport = use_transport, \
>> > > > }
>> > > >
>> > > >+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
>> > > >+ vendor_name, product_name, use_protocol, use_transport, \
>> > > >+ init_function, Flags) \
>> > > >+{ \
>> > > >+ .vendorName = vendor_name, \
>> > > >+ .productName = product_name, \
>> > > >+ .useProtocol = use_protocol, \
>> > > >+ .useTransport = use_transport, \
>> > > >+ .initFunction = init_function, \
>> > > >+}
>> > >
>> > > Shouldn't the field initilaizers be indented with tab, not space?
>> >
>> > Yes it must. fangxiaozhi, please always run your patches through the
>> > scripts/checkpatch.pl tool before sending them out (note, you will have to
>> > ignore the CamelCase warnings your patch produces, but not the other
>> > ones.)
>> >
>> -What's wrong with it?
>> -I have checked the patches with scripts/checkpatch.pl before sending.
>> -There is no other warning or error in my patches except CamelCase
>> warnings.
>> -So what's wrong now?
>
> Then your email client messed up the patches and put spaces in the code
> instead of tabs. Try looking at the message on the mailing list and run
> that through checkpatch, it will show you the problems.
>
> What I received isn't ok, sorry.
Fangxiaozhi --
According to the headers of your E-mail, you are using MS Outlook to
send your patches. Outlook commonly mangles patches, unfortunately.
It is not a very good e-mail client.
I suggest one of two options:
1) Setup an alternative mail client. There are many to choose from
which will not damage your patches. I personally like 'mutt' (which
you should be able to install on your linux machine). Others may be
able to recommend ones that work for them; in general, I think you
will find that most e-mail clients that run on Linux will be suitable.
2) If you plan on contributing to the linux kernel in the future, it
may be worth your time to setup a repo on github that Greg can then
directly pull from. All you would need to do is send Greg a "pull
request" indicating the URL of the branch in your repo that he should
pull from. Greg can then pull directly from your repo, bypassing this
issue entirely.
Matt
--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
--
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: [PATCH] USB: storage: avoid scanning other targets for single target device
Let me try this again... It looks fine to me. Acked-by: Matthew Dharm Matt On Sat, Jan 19, 2013 at 10:47 AM, Alan Stern wrote: > On Sat, 19 Jan 2013, Ming Lei wrote: > >> This patch sets scsi_host->max_id as 1 if the device's quirk >> flag of US_FL_SCM_MULT_TARG isn't set, because there are only 6 >> mass storage devices marked as mutiple targets from unusual_devs.h. >> >> This patch is a small optimization about scanning targets, and >> avoid scanning other 7 non-existed targets for single target >> device. >> >> Signed-off-by: Ming Lei > > This seems like a good optimization. Of course, it's up to Matt. > > Alan Stern > -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: usb card reader broken
Unfortunately, there is no good way to programmatically detect this failure condition. It's only obvious when you know that it's SD-like media (no way to detect that), that the media is large (no way to detect that), and you see one of several unusual behaviors (not all of which are detectable). As for recognizing the vendor -- there are 3 separate places where this information is encoded. One is as the idVendor value, which you can see in lsusb; I don't recall if lsusb will translate that number into names (ala lspci), but you should address this with the lsusb people. The 2nd place is in the device descriptor strings. Those appear to be blank on this device. The 3rd place is in the INQUIRY command response. Those appear to say "Direct Access" as the vendor name (which is not terribly uncommon). Matt On Sun, Dec 23, 2012 at 1:24 PM, rh wrote: > On Sun, 23 Dec 2012 11:45:31 -0800 > Matthew Dharm > wrote: > >> The breakpoint between SDSC and SDHC is, in fact, 4GB for 512-byte >> sectors. So, your data supports my theory that your cardreader is >> non-SDHC compatible. > > I tried the 4GB microSD and the symptoms were the same as for the > 16GB. It's not graceful but at least it doesn't crash the box. > Trying to mount just hangs there for a long time. Might be merciful > to print out a useful message when this situation is encountered, > if that's possible. > > Why isn't the vendor recognized? It was in the past. > i.e. plugging in the card reader with no cards inserted returned > the correct vendor in the past. > >> >> Matt >> >> On Sun, Dec 23, 2012 at 11:19 AM, rh >> wrote: >> > On Sun, 23 Dec 2012 11:01:28 -0800 >> > Matthew Dharm >> > >> > wrote: >> > >> >> If I had to guess, it looks like you have an SDHC card in an older >> >> SDSC reader. The older readers can't read the higher-capacity SDHC >> >> cards. >> >> >> >> Try the reader/card combo on a recent windows system to see if they >> >> are compatible. Or, look for a specific SDHC or SDXC compatibility >> >> marking on the reader. >> > >> > I tried to read it on a mac but "disk utility" wasn't able to do >> > anything. I forget the specifics but I could do nothing with it on >> > the mac. >> > >> > But I was able to read a 2GB microSD so is it a ~4GB issue? >> > Hmm I might have a 4GB microSD, will try that. >> > >> > Something else I realized is that at some point in the past the >> > kernel recognized the vendor as Phison but does not anymore. >> > >> > >> >> >> >> Matt >> >> >> >> On Sun, Dec 23, 2012 at 10:26 AM, rh >> >> wrote: >> >> > I don't use this device often so I don't know if this combination >> >> > ever worked in previous kernels. I was trying to read a 16GB >> >> > microSD card. The hub claims to be able to read MicroDrive, >> >> > SmartMedia, CompactFlash, Memory Stick, Multimedia and Secure >> >> > Digital. (reading from the label on the device) >> >> > >> >> > FWIW 16GB == 16*1000*1000*1000 >> >> > >> >> > From http://www.linux-usb.org/usb.ids: >> >> > (couldn't find this in the kernel source) >> >> > >> >> > 0d7d Phison Electronics Corp. >> >> > 0240 I/O-Magic/Transcend 6-in-1 Card Reader >> >> > >> >> > >> >> > kernel version 3.6.7 >> >> > >> >> > [367851.023224] usb 3-1: new full-speed USB device number 13 >> >> > using ohci_hcd [367851.180145] usb 3-1: New USB device found, >> >> > idVendor=0d7d, idProduct=0240 [367851.180145] usb 3-1: New USB >> >> > device strings: Mfr=1, Product=2, SerialNumber=3 [367851.180145] >> >> > usb 3-1: Product: USB Reader [367851.180145] usb 3-1: >> >> > Manufacturer: >> >> > >> >> > [367851.183145] scsi7 : usb-storage 3-1:1.0 >> >> > [367852.191812] scsi 7:0:0:0: Direct-Access USB Card >> >> > Reader 1.01 PQ: 0 ANSI: 0 CCS [367852.199885] scsi 7:0:0:1: >> >> > Direct-Access USB Card Reader 1.01 PQ: 0 ANSI: 0 >> >> > CCS [367852.207145] scsi 7:0:0:2: Direct-Access USB >> >> > Card Reader 1.01 PQ: 0 ANSI: 0 CCS [367852.214146] scsi 7:0:0:3: >> >> > Direct-Access USB Card Reader 1.01 PQ: 0 ANSI
Re: usb card reader broken
The breakpoint between SDSC and SDHC is, in fact, 4GB for 512-byte sectors. So, your data supports my theory that your cardreader is non-SDHC compatible. Matt On Sun, Dec 23, 2012 at 11:19 AM, rh wrote: > On Sun, 23 Dec 2012 11:01:28 -0800 > Matthew Dharm > wrote: > >> If I had to guess, it looks like you have an SDHC card in an older >> SDSC reader. The older readers can't read the higher-capacity SDHC >> cards. >> >> Try the reader/card combo on a recent windows system to see if they >> are compatible. Or, look for a specific SDHC or SDXC compatibility >> marking on the reader. > > I tried to read it on a mac but "disk utility" wasn't able to do anything. > I forget the specifics but I could do nothing with it on the mac. > > But I was able to read a 2GB microSD so is it a ~4GB issue? > Hmm I might have a 4GB microSD, will try that. > > Something else I realized is that at some point in the past the kernel > recognized the vendor as Phison but does not anymore. > > >> >> Matt >> >> On Sun, Dec 23, 2012 at 10:26 AM, rh >> wrote: >> > I don't use this device often so I don't know if this combination >> > ever worked in previous kernels. I was trying to read a 16GB microSD >> > card. The hub claims to be able to read MicroDrive, SmartMedia, >> > CompactFlash, Memory Stick, Multimedia and Secure Digital. >> > (reading from the label on the device) >> > >> > FWIW 16GB == 16*1000*1000*1000 >> > >> > From http://www.linux-usb.org/usb.ids: >> > (couldn't find this in the kernel source) >> > >> > 0d7d Phison Electronics Corp. >> > 0240 I/O-Magic/Transcend 6-in-1 Card Reader >> > >> > >> > kernel version 3.6.7 >> > >> > [367851.023224] usb 3-1: new full-speed USB device number 13 using >> > ohci_hcd [367851.180145] usb 3-1: New USB device found, >> > idVendor=0d7d, idProduct=0240 [367851.180145] usb 3-1: New USB >> > device strings: Mfr=1, Product=2, SerialNumber=3 [367851.180145] >> > usb 3-1: Product: USB Reader [367851.180145] usb 3-1: Manufacturer: >> > >> > [367851.183145] scsi7 : usb-storage 3-1:1.0 >> > [367852.191812] scsi 7:0:0:0: Direct-Access USB Card >> > Reader 1.01 PQ: 0 ANSI: 0 CCS [367852.199885] scsi 7:0:0:1: >> > Direct-Access USB Card Reader 1.01 PQ: 0 ANSI: 0 CCS >> > [367852.207145] scsi 7:0:0:2: Direct-Access USB Card >> > Reader 1.01 PQ: 0 ANSI: 0 CCS [367852.214146] scsi 7:0:0:3: >> > Direct-Access USB Card Reader 1.01 PQ: 0 ANSI: 0 CCS >> > [367852.216145] sd 7:0:0:0: Attached scsi generic sg2 type 0 >> > [367852.216565] sd 7:0:0:1: Attached scsi generic sg3 type 0 >> > [367852.216565] sd 7:0:0:2: Attached scsi generic sg4 type 0 >> > [367852.216565] sd 7:0:0:3: Attached scsi generic sg5 type 0 >> > [367856.886551] sd 7:0:0:2: [sdd] 1 512-byte logical blocks: (512 >> > B/512 B) [367856.923227] sd 7:0:0:2: [sdd] Write Protect is on >> > [367856.923227] sd 7:0:0:2: [sdd] Mode Sense: 43 00 80 00 >> > [367856.963227] sd 7:0:0:2: [sdd] No Caching mode page present >> > [367856.963227] sd 7:0:0:2: [sdd] Assuming drive cache: write >> > through [367856.987033] sd 7:0:0:0: [sdb] Attached SCSI removable >> > disk [367857.026551] sd 7:0:0:1: [sdc] Attached SCSI removable disk >> > [367857.046033] sd 7:0:0:3: [sde] Attached SCSI removable disk >> > [367857.073217] sd 7:0:0:2: [sdd] No Caching mode page present >> > [367857.073217] sd 7:0:0:2: [sdd] Assuming drive cache: write >> > through [367888.136553] usb 3-1: reset full-speed USB device number >> > 13 using ohci_hcd [367903.259389] usb 3-1: device descriptor >> > read/64, error -110 [367918.479883] usb 3-1: device descriptor >> > read/64, error -110 [367918.705930] usb 3-1: reset full-speed USB >> > device number 13 using ohci_hcd [367933.823216] usb 3-1: device >> > descriptor read/64, error -110 [367949.046547] usb 3-1: device >> > descriptor read/64, error -110 [367949.269880] usb 3-1: reset >> > full-speed USB device number 13 using ohci_hcd [367954.286566] usb >> > 3-1: device descriptor read/8, error -110 [367959.406541] usb 3-1: >> > device descriptor read/8, error -110 [367959.626547] usb 3-1: reset >> > full-speed USB device number 13 using ohci_hcd [367964.643891] usb >> > 3-1: device descriptor read/8, error -110 [367969.760640] usb 3-1: >> > device descriptor read/8, error -110 [367969.863211] usb 3-1: USB >> &
Re: usb card reader broken
ead/8, error -110 > [368038.334981] usb 3-1: device descriptor read/8, error -62 > [368038.489866] hub 3-0:1.0: unable to enumerate USB device on port 1 > > -- > 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 -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
On Wed, Dec 19, 2012 at 12:34 AM, Sebastian Andrzej Siewior wrote: > On Wed, Dec 19, 2012 at 03:13:32AM +, Fangxiaozhi (Franko) wrote: >> > And shouldn't you read something from the us->recv_bulk_pipe after >> > that? >> Well, because our device will re-connect to switch the ports if it >> receives the command. >> So it is not necessary to read the response of the command. > > Hmm. I guess this for Matthew / Greg to decide, I don't insist on anything. > Maybe a comment would be nice because now it looks, atleast to me, that > something is missing. I think an unusual situation like that deserves a comment that explains that the device is about to disconnect / reconnect, so reading status is not necessary. I am also concerned about the error of using &bcbw instead of bcbw. I doubt this code would have worked with that typo in place. How was this patch tested? Also, the dongles_pid function is really just a different implementation of the unusual_devs.h table. I think that it is much easier for people to add new entries to the table, rather than edit your code, when new dongles are released. BUT, your code includes many more PIDs than the table did. Again, how was this tested for the new PIDs covered? At a minimum, some comment in dongles_pid is required to highlight this area of code for possible future expansion as new devices are released. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: problem with USB DVD drive, can't find root fs on some drives
If I had to guess, I'd say it was a timing issue. The CD-ROM that doesn't work is taking slightly longer to discover and maybe longer to get ready. Most "LiveCD" type distros I've seen load an initrd which has a wait-loop in it to wait for the real root device to appear before mount/chroot. Matt On Tue, Dec 4, 2012 at 2:13 PM, Chris Friesen wrote: > > Hi, > > I hope this is the right place to send this, if not please let me know where > would be more appropriate. > > We distribute a 2.6.27-based software load on bootable DVD. It's intended > to boot on a system that has no internal DVD drive, so we use USB DVD drives. > > With most drives we have no problems, but I've received a complaint from > someone that has a drive that won't boot our software and I can't figure > out why. The same drive will boot a RHEL install disc. > > Any suggestions you might have would be great. > > > The non-working drive is a Sony, and the relevant boot logs look like this: > > usb 1-1.6.1: new high speed USB device using ehci_hcd and address 5 > scsi9 : usb-storage 1-1.6.1:1.0 > scsi 9:0:0:0: Direct-Access Generic Ultra HS-COMBO 2.01 PQ: 0 ANSI: 0 > sd 9:0:0:0: Attached scsi generic sg2 type 0 > sd 9:0:0:0: [sdc] Attached SCSI removable disk > scsi 9:0:0:1: Direct-Access Generic Ultra HS-SD/MMC2 2.01 PQ: 0 ANSI: 0 > sd 9:0:0:1: Attached scsi generic sg3 type 0 > sd 9:0:0:1: [sdd] Attached SCSI removable disk > scsi 8:0:0:0: CD-ROMSONY DVD RW DRU-840A SS01 PQ: 0 ANSI: 0 > sr0: scsi3-mmc drive: 12x/40x writer dvd-ram cd/rw xa/form2 cdda tray > Uniform CD-ROM driver Revision: 3.20 > sr 8:0:0:0: Attached scsi generic sg4 type 5 > md: Waiting for all devices to be available before autodetect > md: If you don't use raid, use raid=noautodetect > md: Autodetecting RAID arrays. > md: Scanned 0 and added 0 devices. > md: autorun ... > md: ... autorun DONE. > VFS: Cannot open root device "sr0" or unknown-block(11,0) > Please append a correct "root=" boot option; here are the available > partitions: > 0810 879087384 sdb driver: sd > 0800 879087384 sda driver: sd > 0b00 1048575 sr0 driver: sr > VFS: Unable to mount root fs on unknown-block(11,0) > User configuration error - no valid root filesystem found > > > I'm confused why it can't open sr0 when it clearly lists sr0 as one of the > available partitions. > > > On a working Lite-On drive plugged into the same system with the same install > media, the equivalent logs are: > > usb 1-1.6.1: new high speed USB device using ehci_hcd and address 5 > scsi9 : usb-storage 1-1.6.1:1.0 > scsi 8:0:0:0: CD-ROMSlimtype eSAU208 2 ML05 PQ: 0 ANSI: 0 > sr0: scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda pop-up > Uniform CD-ROM driver Revision: 3.20 > sr 8:0:0:0: Attached scsi generic sg2 type 5 > scsi 9:0:0:0: Direct-Access Generic Ultra HS-COMBO 2.01 PQ: 0 ANSI: 0 > sd 9:0:0:0: Attached scsi generic sg3 type 0 > sd 9:0:0:0: [sdc] Attached SCSI removable disk > scsi 9:0:0:1: Direct-Access Generic Ultra HS-SD/MMC2 2.01 PQ: 0 ANSI: 0 > sd 9:0:0:1: Attached scsi generic sg4 type 0 > sd 9:0:0:1: [sdd] Attached SCSI removable disk > md: Waiting for all devices to be available before autodetect > md: If you don't use raid, use raid=noautodetect > md: Autodetecting RAID arrays. > md: Scanned 0 and added 0 devices. > md: autorun ... > md: ... autorun DONE. > VFS: Mounted root (iso9660 filesystem) readonly on device 11:0. > devtmpfs: mounted > Freeing unused kernel memory: 656k freed > > = > Transferring basename: typhoon-unit0 > Sourcing > isolinux/tftpboot/cnp/x86_ng/7.0.0/targets/sb_rms/common//etc/sysconfig/pivotroot > Setting up rootfs... > > > Chris -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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: [usb-storage] usb-storage and S.M.A.R.T.
On Thu, Feb 14, 2008 at 06:19:46PM +0100, René Rebe wrote: > Hi all, > > due to some failing dics I got myself a JMicro USB<->ATA,SATA > cable for data recovery and co. > > However, I was quite suprised that the SMART (...) status querries > would not go thru. > > # smartctl -a /dev/sdb > smartctl version 5.37 [x86_64-t2-linux-gnu] Copyright (C) 2002-6 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > Device: SAMSUNG SP1654N Version: 0-37 > Device type: disk > Local Time is: Thu Feb 14 18:19:09 2008 CET > Device does not support SMART > > Error Counter logging not supported > Device does not support Self Test logging > > > As I do not know the underlying protocols off-hand, is that a driver / > sub-system limitation or not possible to get thru this USB mass > storage protocol? It's a limitation of the particular USB/ATA bridge device you're using. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgp7cxaAuQAtw.pgp Description: PGP signature
Re: usb-storage and S.M.A.R.T.
On Thu, Feb 14, 2008 at 06:19:46PM +0100, René Rebe wrote: > Hi all, > > due to some failing dics I got myself a JMicro USB<->ATA,SATA > cable for data recovery and co. > > However, I was quite suprised that the SMART (...) status querries > would not go thru. > > # smartctl -a /dev/sdb > smartctl version 5.37 [x86_64-t2-linux-gnu] Copyright (C) 2002-6 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > Device: SAMSUNG SP1654N Version: 0-37 > Device type: disk > Local Time is: Thu Feb 14 18:19:09 2008 CET > Device does not support SMART > > Error Counter logging not supported > Device does not support Self Test logging > > > As I do not know the underlying protocols off-hand, is that a driver / > sub-system limitation or not possible to get thru this USB mass > storage protocol? The protocol will carry the commands just fine. The problem is that most USB/ATA converter chips won't translate the command properly. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgplpvJ1RKlRd.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, Feb 12, 2008 at 03:51:22PM -0500, Alan Stern wrote: > On Sat, 2 Feb 2008, Matthew Dharm wrote: > > > On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote: > > > IMO this indicates we shouldn't issue any clear-halts at all unless the > > > device actually needs it. In general it's not a good idea to do a > > > clear-halt for an endpoint that isn't actually halted; devices are > > > prone to misinterpret the request. > > > > > > And since the only device we know of that does need the clear-halts is > > > long obsolete, the simplest strategy is just to leave them out. That > > > ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN > > > flag for it, since the Get-Max-LUN is never issued when that flag is > > > set. > > > > My only issue is that we're effectively dropping support for a device that > > currently works. An obsolete device, I admit, but a device we currently > > support nevertheless. > > > > I suppose that really is the best option, tho. We just need to be on the > > lookout for reports of very old ZIP-100 drives breaking. > > I found the original thread where we diagnosed the problem with the old > ZIP-100. This message is near the end of the thread, but it includes > the descriptor values for the device: > > https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-March/51.html > > Interestingly, the bcdUSB value is 0x0100 -- USB 1.0 rather than 1.1. > Maybe we should automatically set the SINGLE_LUN flag for any device > with that value? Or would we be better off with an explicit > unusual_devs entry for this ZIP-100 model? We should have as narrow a scope of influence as possible. A single entry would be best. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Why am I talking to a toilet brush? -- CEO User Friendly, 4/30/1998 pgpLQIsveifdm.pgp Description: PGP signature
Re: Unusual device? (USB HD)
On Sun, Feb 10, 2008 at 10:55:14PM -0500, Alan Stern wrote: > On Sun, 10 Feb 2008, Peter Rasmussen wrote: > > > I mean, I do have trouble decoding these lines: > > > > usb-storage: Command INQUIRY (6 bytes) > > usb-storage: 12 00 00 00 24 00 > > usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6 > > > > But then, what do I know :-) > > Well, sure... That log output was never meant for casual users like > yourself. It's debugging information, meant for use by developers. > That's one reason why it doesn't appear unless you enable > CONFIG_USB_STORAGE_DEBUG. So... every so often this does come up. People want to understand. So, for the sake of the list archives, here's a quick decoder: > > usb-storage: Command INQUIRY (6 bytes) > > usb-storage: 12 00 00 00 24 00 This is the beginning of a command. The SCSI mid-layer passes us an struct scsi_request, which contains an array of command bytes (up to 16). Only some of the bytes are valid (indicated by a field in the structure). The command decodes to INQUIRY. You only get that if you have the SCSI debug tables (which have the text names for all the commands) compiled in. The command indicates that 6 bytes of the command array are valid. The next line are the command bytes in question. If you grab a copy of the SCSI specification, you can decode these directly. Next: > > usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6 USB Storage basically breaks everything down into 3 phases: command, data (optional), and status. There are a few ways to pack these phases onto the wire; the most common is officially called "Bulk-only". In the bulk-only transport, commands are sent to the device in a particular structure. This line breaks out the fields of that structure. Specifically, these are: S - Signature T - Tag L - Requested transfer length F - flags Trg - Target number LUN - Logical Unit Number CL - command length Some of these fields are constant. The rest are derived in some way from the struct scsi_request. Anyway, that's the 'executive summary'. If you want to see data flowing back-and-forth from your device, the debug gives you a pretty good low-level view of how that flow is controlled, but not the data itself. usb-storage never actually dumps out the data blocks being exchanged, only the transport framing and packing of those exchanges. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgpiGyUpZM8Hx.pgp Description: PGP signature
Re: Unusual device? (USB HD)
On Sun, Feb 10, 2008 at 11:00:33PM +0100, Peter Rasmussen wrote: > Is it possible to distinguish such a failure from a bad implementation > of a device's USB stack? > If it is, it would be great to also be told in some way that doesn't > require me to know USB so intimately. Not really. You can make an educated guess based on the aggregate information, but there is no solid way to tell the difference. In this case, I find a bad cable unlikely. The cable would have to be flakey only during the data phase of a command. > E.g.: Connection Error: You seem to have a bad cable > Registration Error: There are problems with registering the > device. It may have a bad XYZ command processing There are some messages like that for errors that generally only happen with bad cables. This is not one of those. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999 pgpiuyb8UysVC.pgp Description: PGP signature
Re: Unusual device? (USB HD)
On Sun, Feb 10, 2008 at 02:35:50PM +0100, Peter Rasmussen wrote: > The following output is taken from dmesg with a 2.6.24 kernel with the > mass storage debug flag set. > > This is my first attempt at using an external USB-HD, and for whatever > reason my kernel won't give me a device to mount. > > I have borrowed the device from a friend that runs Windows, and the > format is NTFS, but I have build my kernel with read-support for that, > so that shouldn't be a problem, but I am not even at the filesystem yet. > > Anyone got a clue? According to your log, the device is accepting a command, failing to transfer any data, and then reporting a severe error which requires a reset. My best guess is that it needs to be initialized somehow. You say the device runs under windows (without extra drivers, I presume)? Perhaps a usb snoopy trace of htat would shed some light on this Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What the hell are you? -- Pitr to Dust Puppy User Friendly, 12/3/1997 pgpOgZjGjVXDL.pgp Description: PGP signature
Re: [Bugme-new] [Bug 9925] New: PROBLEM: Card Reader Detected but won't connect to system
On Sun, Feb 10, 2008 at 02:50:02PM -0500, Felipe Balbi wrote: > On Sat, Feb 09, 2008 at 10:55:17PM -0800, Andrew Morton wrote: > > On Sat, 9 Feb 2008 18:08:14 -0800 (PST) [EMAIL PROTECTED] wrote: > > > > > /dev > > > root # ls -al ub* > > > brw-rw 1 root video 180, 0 2008-02-09 15:21 "uba" > > > brw-rw 1 root video 180, 8 2008-02-09 15:21 "ubb" > > > brw-rw 1 root video 180, 16 2008-02-09 15:21 "ubc" > > > brw-rw 1 root video 180, 24 2008-02-09 15:21 "ubd" > > > brw-r- 1 root disk 180, 32 2008-02-09 15:23 "ube" > > > > > > I tried a normal 1GB SD card (leaving out SDHC for the moment) > > > > > > mount -t vfat /dev/ude1 /media/sddisk/ > > > mount: special device /dev/ude1 does not exist > > Shouldn't it be /dev/ube1 instead of ude1 ?? > > In any case, a full dmesg output with CONFIG_USB_STORAGE_DEBUG enabled > would be great. That probably wouldn't help; it looks like he's using the ub driver, not usb-storage. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I see you've been reading alt.sex.chubby.sheep voraciously. -- Tanya User Friendly, 11/24/97 pgpEWi8MsQlfT.pgp Description: PGP signature
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Wed, Feb 06, 2008 at 03:23:39PM -0500, Alan Stern wrote: > On Tue, 5 Feb 2008, Matthew Dharm wrote: > > > Six of one and a half-dozen of the other. All we're arguing over is the > > definition of "correct behavior" here. You want to change the API so that > > overrun is acceptable and handled; I prefer calling it a Bad Thing(tm). > > > > We both agree that the code shouldn't run off the end of the s-g list. > > > > Since you've already committed to updating the patch, then we can do it > > your way. Just make sure it's very very clear in the comments. > > Okay, here's my version. It makes some significant changes to the > interface for usb_stor_access_xfer_buf() -- in particular, the context > information is now stored in an opaque structure rather than in ad-hoc > local variables. All the callers are updated to use the new interface. Maybe this is a crazy question, but... Why is this not in the SCSI core? It's hardly USB-specific, and I'm willing to bet that there are other HCDs (at least spb2) which need to do this sort of thing... Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver YOU SEE!!?? It's like being born with only one nipple! -- Erwin User Friendly, 10/19/1998 pgpAKeMJkPMW1.pgp Description: PGP signature
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Mon, Feb 04, 2008 at 03:05:58PM -0500, Alan Stern wrote: > On Sun, 3 Feb 2008, Matthew Dharm wrote: > > I think the correct approach is to modify those routines so that they > will never overrun the s-g buffer (like Boaz has done), and _document_ > this behavior. Then the callers can feel free to try and transfer as > much as they want, knowing that an overrun can't occur. There won't > be any need for a WARN_ON or anything else. Six of one and a half-dozen of the other. All we're arguing over is the definition of "correct behavior" here. You want to change the API so that overrun is acceptable and handled; I prefer calling it a Bad Thing(tm). We both agree that the code shouldn't run off the end of the s-g list. Since you've already committed to updating the patch, then we can do it your way. Just make sure it's very very clear in the comments. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgpRWES13MJJo.pgp Description: PGP signature
Re: wrong cylinders of kingston usb pendrive [intel 82801DB]
On Sun, Feb 03, 2008 at 05:59:38PM -0800, Greg KH wrote: > On Mon, Feb 04, 2008 at 01:50:37AM +0100, Patrick Ringl wrote: > > Hello, > > > > I am suffering from the following (usb-related?) problem: > > > > I have several different mashines - all x86 architecture - just lets call > > them mashineA, mashineB and mashineC. > > Is the kernel the same on all of these machines? I'm not sure it matters... usb-storage has no knowledge of CHS geometery. It deals entirely in LBA. Does anyone know where the kernel gets the CHS geometery equivalent from? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgp8mGGs3KeiP.pgp Description: PGP signature
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
One more comment on the patch...
On Sun, Feb 03, 2008 at 06:28:48PM +0200, Boaz Harrosh wrote:
> + /* Check for overflow */
> + if (buflen > scsi_bufflen(srb)) {
This really should have an unlikely() around it. This is an often-executed
code path, and we want to optimize it as much as possible.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Type "format c:" That should fix everything.
-- Greg
User Friendly, 12/18/1997
pgpg0qLfBYeeo.pgp
Description: PGP signature
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Sun, Feb 03, 2008 at 06:28:48PM +0200, Boaz Harrosh wrote: > >From 3610cfa93c990bbbafb296134ac01ef6d426eb8d Mon Sep 17 00:00:00 2001 > From: Boaz Harrosh <[EMAIL PROTECTED]> > Date: Thu, 31 Jan 2008 21:31:31 +0200 > Subject: [PATCH] bugfix for an overflow condition in usb storage & isd200.c > > scsi_scan is issuing a 36-byte INQUIRY request to llds. isd200 would > volunteer 96 bytes of INQUIRY. This caused an overflow condition in > protocol.c usb_stor_access_xfer_buf(). So first fix is to > usb_stor_access_xfer_buf() to properly handle overflow/underflow conditions. > Then usb_stor_set_xfer_buf() should report this condition as cmnd->result == > (DID_BAD_TARGET << 16). > > Then also isd200.c is fixed to only return the type of INQUIRY && SENSE > the upper layer asked for. > > Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> > --- > drivers/usb/storage/isd200.c |7 +-- > drivers/usb/storage/protocol.c | 20 > 2 files changed, 21 insertions(+), 6 deletions(-) Looking at this again, I think I see Alan's point. The modifications to ISD200 code aren't really needed. Or, put another way, if you're going to modify the ISD200 code, you should fix up all the other users of usb_stor_access_xfer_buf() -- there are over a dozen or so, and it looks like none of them have sanity checks for length (but the happen to work right now). But, the modifications to usb_stor_access_xfer_buf() look good -- no request from a sub-driver should be allowed to scribble into memory. The current code does make the implicit assumption that there is enough storage, and will walk right off the end of the sg list if there isn't. I'm not sure I like the mods to usb_stor_set_xfer_buf(). Any place we set a status that we know is going to be thrown away is an invitation for a problem later if someone changes the code to preserve that status. It's a jack-in-the-box, waiting to spring open in our face later. The limit check (which mirrors the usb_stor_access_xfer_buf modification) and WARN_ON() are probably good. In a strictly technical sense, the change to protocol.c are sufficient. That is, they will prevent a serious error. There is a justification tho to fix all of the users of usb_stor_access_buf() to not attempt to use more SCSI buffer than exists. My opinion is this: Let's make the protocol.c mods (modulo my comments about setting useless status bits) now. Then, let's decide if we're going to patch all the other users of the usb_stor_*_xfer_buf() functions as a separate discussion. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: They kicked your ass, didn't they? S: They were cheating! -- The Chief and Stef User Friendly, 11/19/1997 pgpScEb9oYZ0W.pgp Description: PGP signature
Re: [usb-storage] request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, Feb 02, 2008 at 10:30:51PM -0500, Alan Stern wrote: > On Sat, 2 Feb 2008, Matthew Dharm wrote: > > > On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote: > > > IMO this indicates we shouldn't issue any clear-halts at all unless the > > > device actually needs it. In general it's not a good idea to do a > > > clear-halt for an endpoint that isn't actually halted; devices are > > > prone to misinterpret the request. > > > > > > And since the only device we know of that does need the clear-halts is > > > long obsolete, the simplest strategy is just to leave them out. That > > > ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN > > > flag for it, since the Get-Max-LUN is never issued when that flag is > > > set. > > > > My only issue is that we're effectively dropping support for a device that > > currently works. An obsolete device, I admit, but a device we currently > > support nevertheless. > > > > I suppose that really is the best option, tho. We just need to be on the > > lookout for reports of very old ZIP-100 drives breaking. > > If we add an unusual_devs entry for the old ZIP-100 with > US_FL_SINGLE_LUN then it should continue to work okay. But we can't do > that without the proper ID values. Maybe they're buried somewhere in > the mailing list archives, or maybe Pat Lavarre can provide them. Pat left Iomega several years ago. I doubt he has access to that data. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It's not that hard. No matter what the problem is, tell the customer to reinstall Windows. -- Nurse User Friendly, 3/22/1998 pgpHosf2PYVBo.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote: > IMO this indicates we shouldn't issue any clear-halts at all unless the > device actually needs it. In general it's not a good idea to do a > clear-halt for an endpoint that isn't actually halted; devices are > prone to misinterpret the request. > > And since the only device we know of that does need the clear-halts is > long obsolete, the simplest strategy is just to leave them out. That > ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN > flag for it, since the Get-Max-LUN is never issued when that flag is > set. My only issue is that we're effectively dropping support for a device that currently works. An obsolete device, I admit, but a device we currently support nevertheless. I suppose that really is the best option, tho. We just need to be on the lookout for reports of very old ZIP-100 drives breaking. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 pgps8Umt5SEwf.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, Feb 02, 2008 at 12:22:14AM +0100, Robert Spitzenpfeil wrote: > Alan Stern wrote: > >On Fri, 1 Feb 2008, Robert Spitzenpfeil wrote: > > > >>Alan Stern wrote: > >>>So Robert, this suggests an experiment for you to try. First remove > >>>the US_FL_FIX_INQUIRY flag in your unusual_devs entry, of course. But > >>>then edit transport.c, and in usb_stor_Bulk_max_lun() replace the two > >>>lines saying > >>> > >>> usb_stor_clear_halt(us, us->recv_bulk_pipe); > >>> usb_stor_clear_halt(us, us->send_bulk_pipe); > >>> > >>>with a single line saying > >>> > >>> usb_stor_clear_halt(us, us->send_ctrl_pipe); > >>> > >>>This should duplicate Windows' actions, except for the two retries. > >>>Maybe then the device will work... > >>> > >>> > >>> > >>IT WORKS. > >> > > > >And just out of curiousity, what happens if you remove the > >usb_stor_clear_halt() entirely? > > > > > still works :-) What happens if you do all three usb_stor_clear_halt() calls? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998 pgpFxgF8sWKoH.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, Feb 01, 2008 at 08:40:41PM +0100, Oliver Neukum wrote: > Am Freitag, 1. Februar 2008 20:16:05 schrieb Alan Stern: > > I'm speculating that the device doesn't need the clear-halt for ep0 at > > all; Robert should be able to check whether that's true or not. It > > seems clear that the clear-halts for the bulk endpoints are causing > > problems. > > What's clear about that? The available traces would also be compatible > with the device needing a clear halt on ep0. We should investigate whether > the device can cope with clearing halts on all endpoints before we talk > additional quirks. This is my position exactly. I speculate that the windows-issued clear-halt on ep0 is required by the device. There's no way to know until Robert tests with no clear-halt at all. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Hi. I have my back hairs caught in my computer fan. -- Customer User Friendly, 8/20/1998 pgpN7i2Sz2Xu6.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, Feb 01, 2008 at 11:59:56AM -0500, Alan Stern wrote: > On Fri, 1 Feb 2008, Matthew Dharm wrote: > > > On Fri, Feb 01, 2008 at 10:17:24AM -0500, Alan Stern wrote: > > > On Thu, 31 Jan 2008, David Brownell wrote: > > > > > > > On Thursday 31 January 2008, Alan Stern wrote: > > > > > The interesting difference lay in what Windows did when the > > > > > Get-Max-LUN > > > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > > > > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > > > trace and that's what happened under Linux). This was in response to > > > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > > > are permitted not to support that request if they have only one LUN. > > > > > > Right now usb-storage responds to this stall by clearing the halt > > > feature from the bulk-in and bulk-out endpoints, not because the spec > > > says to do so but because one ancient device (a ZIP-100) requires it. > > > Now it looks as though we've found a device which can't handle it. > > > Time for another quirk? > > > > Do we really need another quirk? If the 'popular' OS does it, it's likely > > safe to do for all deveices when GetMaxLUN fails... > > You missed the point. Windows does _not_ do it -- i.e., does not clear > a halt on either bulk endpoint. Linux does so only because somebody > (either Pete Zaitcev or Pat Lavarre, I can't remember which) pointed > out that the ZIP-100 drive needs it. > > The clear-halt for endpoint 0 probably isn't needed by anything; I > don't know why Windows does it. Anything except this device, that is. I thought we had traces of Windows issuing a clear-halt to endpoint 0 after a failed GetMaxLUN. Or did I read the thread wrong? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 pgpakLrLf2mi6.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, Feb 01, 2008 at 10:17:24AM -0500, Alan Stern wrote: > On Thu, 31 Jan 2008, David Brownell wrote: > > > On Thursday 31 January 2008, Alan Stern wrote: > > > The interesting difference lay in what Windows did when the Get-Max-LUN > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > trace and that's what happened under Linux). This was in response to > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > are permitted not to support that request if they have only one LUN. > > Right now usb-storage responds to this stall by clearing the halt > feature from the bulk-in and bulk-out endpoints, not because the spec > says to do so but because one ancient device (a ZIP-100) requires it. > Now it looks as though we've found a device which can't handle it. > Time for another quirk? Do we really need another quirk? If the 'popular' OS does it, it's likely safe to do for all deveices when GetMaxLUN fails... Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 pgp418LiNMzoV.pgp Description: PGP signature
Re: [PATCH 2.6.24] bugfix for an overflow condition in usb storage & isd200.c
On Thu, Jan 31, 2008 at 10:05:19PM +0200, Boaz Harrosh wrote: > On Thu, Jan 31 2008 at 21:49 +0200, Matthew Dharm <[EMAIL PROTECTED]> wrote: > > No. No no no. > > Please re-inspect the code again. > There is no device involved here. The code completely emulates this commands > with a driver made up information. the send_to_device is Zero. > (Nothing to bounce) Okay, I see what you're doing there, and I can live with that. > The negative resid is returned by iscsi for ages so I would say the scsi-ml > is fine with it. But if you want I can reset the resid and mark an overflow > condition in cmnd->status. I'd be fine if one of the SCSI guru's would comment on this as being acceptable. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Hey Chief. We've figured out how to save the technical department. We need to be committed. -- The Techs User Friendly, 1/22/1998 pgp5Aml1rCtCh.pgp Description: PGP signature
Re: [PATCH 2.6.24] bugfix for an overflow condition in usb storage & isd200.c
No. No no no.
The ISD200 code was written by the ISD200 developers. I really don't want
to go mucking about changing what commands actually get send to the ISD200
parts. We have no idea if the will reliably accept a 36-byte INQUIRY.
Just because it happens to work for a couple of people doesn't mean it
works in the general case. Without guidance from In-System, this is a bad
idea.
The way to deal with this is to do this via bounce buffering. The two
commands affected (INQUIRY and MODE_SENSE) are low-performance items.
Discarding data from the end of them is also perfectly legal per spec.
Also, the entire idea of a negative resid makes my head hurt. That sort of
change is in the category of "likely to break something else" which only
expects positive resid values.
Matt
On Thu, Jan 31, 2008 at 09:37:13PM +0200, Boaz Harrosh wrote:
> Greg KH <[EMAIL PROTECTED]> rote:
> > As this is a regression and hits 2.6.24, can you send the final version
> > of this patch to the [EMAIL PROTECTED] address so we can get it into the
> > 2.6.24.y tree?
> >
> > thanks,
> >
> > greg k-h
>
> Mark - This is for you on top of vanila v2.6.24 kernel from Linus.
>
> ---
>
> scsi_scan is issuing a 36-byte INQUIRY request to llds. isd200 would
> volunteer 96 bytes of INQUIRY. This caused an overflow condition in
> protocol.c usb_stor_access_xfer_buf(). So first fix is to
> usb_stor_access_xfer_buf() to properly handle overflow/underflow conditions.
> Then usb_stor_set_xfer_buf() should report this condition as a negative
> resid. Should we also set cmnd->status in the overflow condition?
>
> Then also isd200.c is fixed to only return the type of INQUIRY && SENSE
> the upper layer asked for.
>
> Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
> ---
> drivers/usb/storage/isd200.c |7 +--
> drivers/usb/storage/protocol.c | 13 +
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
> index 49ba6c0..8186e93 100644
> --- a/drivers/usb/storage/isd200.c
> +++ b/drivers/usb/storage/isd200.c
> @@ -1238,6 +1238,7 @@ static int isd200_scsi_to_ata(struct scsi_cmnd *srb,
> struct us_data *us,
> unsigned long lba;
> unsigned long blockCount;
> unsigned char senseData[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> + unsigned xfer_len;
>
> memset(ataCdb, 0, sizeof(union ata_cdb));
>
> @@ -1247,8 +1248,9 @@ static int isd200_scsi_to_ata(struct scsi_cmnd *srb,
> struct us_data *us,
> US_DEBUGP(" ATA OUT - INQUIRY\n");
>
> /* copy InquiryData */
> + xfer_len = min(sizeof(info->InquiryData), scsi_bufflen(srb));
> usb_stor_set_xfer_buf((unsigned char *) &info->InquiryData,
> - sizeof(info->InquiryData), srb);
> + xfer_len, srb);
> srb->result = SAM_STAT_GOOD;
> sendToTransport = 0;
> break;
> @@ -1257,7 +1259,8 @@ static int isd200_scsi_to_ata(struct scsi_cmnd *srb,
> struct us_data *us,
> US_DEBUGP(" ATA OUT - SCSIOP_MODE_SENSE\n");
>
> /* Initialize the return buffer */
> - usb_stor_set_xfer_buf(senseData, sizeof(senseData), srb);
> + xfer_len = min(sizeof(senseData), scsi_bufflen(srb));
> + usb_stor_set_xfer_buf(senseData, xfer_len, srb);
>
> if (info->DeviceFlags & DF_MEDIA_STATUS_ENABLED)
> {
> diff --git a/drivers/usb/storage/protocol.c b/drivers/usb/storage/protocol.c
> index 889622b..038a284 100644
> --- a/drivers/usb/storage/protocol.c
> +++ b/drivers/usb/storage/protocol.c
> @@ -194,7 +194,7 @@ unsigned int usb_stor_access_xfer_buf(unsigned char
> *buffer,
>* and the starting offset within the page, and update
>* the *offset and *index values for the next loop. */
> cnt = 0;
> - while (cnt < buflen) {
> + while (cnt < buflen && sg) {
> struct page *page = sg_page(sg) +
> ((sg->offset + *offset) >> PAGE_SHIFT);
> unsigned int poff =
> @@ -248,9 +248,14 @@ void usb_stor_set_xfer_buf(unsigned char *buffer,
> {
> unsigned int offset = 0;
> struct scatterlist *sg = NULL;
> + unsigned count;
>
> - usb_stor_access_xfer_buf(buffer, buflen, srb, &sg, &offset,
> + count = usb_stor_access_xfer_buf(buffer, buflen, srb, &sg, &offset,
> TO_XFER
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 08:15:04PM +0100, Jens Axboe wrote: > On Tue, Jan 29 2008, Matthew Dharm wrote: > > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL > > > > > > > PROTECTED]> wrote: > > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > >> Greg KH wrote: > > > > > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > > > get_transport() > > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. > > > > > > > This will > > > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' > > > > > > and > > > > > > transport is 'Bulk' > > > > > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > > > CONFIG_STORAGE_DEBUG > > > > > That should tell the reason for the resets. > > > > > > > > Sure, I'll do that. Will post the results tonight. > > > > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > > > in the device, waited 10 seconds or so and pulled it out. These are the > > > messages. > > > > > > It all looks good until the MODE_SENSE command, where it only transfers > > > 4 of 192 bytes. > > > > No, that's not the problem. This is the problem: > > It's where the problem starts, otherwise there would not be a need to > sense :-) MODE_SENSE has nothing to do with it. A short MODE_SENSE response is perfectly valid, and the log shows it was handled correctly and subsequent commands worked just fine. It's not until the TUR fails that we get the problem. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgpEH3vMJSy1y.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > On Tue, Jan 29 2008, Jens Axboe wrote: > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > >> Greg KH wrote: > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > get_transport() > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This > > > > > will > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and > > > > transport is 'Bulk' > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > CONFIG_STORAGE_DEBUG > > > That should tell the reason for the resets. > > > > Sure, I'll do that. Will post the results tonight. > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > in the device, waited 10 seconds or so and pulled it out. These are the > messages. > > It all looks good until the MODE_SENSE command, where it only transfers > 4 of 192 bytes. No, that's not the problem. This is the problem: > usb-storage: *** thread awakened. > usb-storage: Command TEST_UNIT_READY (6 bytes) > usb-storage: 00 00 00 00 00 00 > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: Attempting to get CSW... > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > usb-storage: Status code 0; transferred 13/13 > usb-storage: -- transfer complete > usb-storage: Bulk status result = 0 > usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > usb-storage: -- transport indicates command failure > usb-storage: Issuing auto-REQUEST_SENSE > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > usb-storage: usb_sg_init returned -22 > usb-storage: Bulk data transfer result 0x4 > usb-storage: -- auto-sense failure > usb-storage: storage_pre_reset > ehci_hcd :00:1d.7: port 1 high speed > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > ehci_hcd :00:1d.7: port 1 high speed > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT > usb-storage: storage_post_reset > usb-storage: usb_reset_composite_device returns 0 > usb-storage: scsi cmd done, result=0x7 > usb-storage: *** thread sleeping. For some reason, usb_sg_init is boned during auto-sense. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpIDALbvcdPw.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 02:15:15PM +0200, Boaz Harrosh wrote: > Greg KH wrote: > > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > >> Hi, > >> > >> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > >> connecting my cf usb storage device yields and endless stream of: > >> > >> Initializing USB Mass Storage driver... > >> scsi6 : SCSI emulation for USB Mass Storage devices > >> usb-storage: device found at 2 > >> usb-storage: waiting for device to settle before scanning > >> usbcore: registered new interface driver usb-storage > >> USB Mass Storage support registered. > >> scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sdb: sdb1 > >> sd 6:0:0:0: [sdb] Attached SCSI removable disk > >> sd 6:0:0:0: Attached scsi generic sg1 type 0 > >> scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> [...] > >> > >> until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > >> I'm attaching boot messages and my .config. > > > > That's a bit wierd, as we haven't added any USB patches to the -git tree > > yet after 2.6.24 :) > > > > Could this be caused by some scsi changes perhaps? > > > > thanks, > > > > greg k-h > > - > Yes it is ;) > > Jens could you test the patch below? if it works I'll submit a proper > patch. Please forgive me for the bug. > > Matthew, Greg, Is there a way to extract from messages the usb storage > transport > used? I'm guessing it is freecom do to the fact that I find a bug there. The freecom transport is exceptionally rare these days. It's primary user was a device made by a company that went out of business. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Way to go, lava boy. -- Stef to Greg User Friendly, 3/26/1998 pgpRal0Re4Vnd.pgp Description: PGP signature
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
ACKed-by: Matthew Dharm <[EMAIL PROTECTED]> Matt On Fri, Jan 25, 2008 at 11:12:21AM -0600, James Bottomley wrote: > On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote: > > On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote: > > > Greg KH wrote: > > > > I just am worried that we are > > > > now suddenly keeping access from the last sector for devices that > > > > currently did work just fine. > > > > > > This new workaround doesn't prevent access to the last sector. It only > > > breaks up a multi-sector access which would also reach the last sector > > > into several (two? I'm too lazy to look back in the mail thread) > > > accesses, in order to access the last sector in a dedicated > > > single-sector access. > > > > > > So that's very differently to the fix-capacity workaround. The > > > fix-capacity workaround manipulates the READ CAPACITY parameter data. > > > Therefore the fix-capacity workaround is unsafe for non-buggy devices. > > > > > > The last-sector-(access-)bug workaround _only_ modifies the command > > > stream which is sent to the device. A dangerous command is replaced by > > > equivalent safe commands. These commands are luckily safe for _all_ > > > devices, buggy and non-buggy ones. The only cost of this workaround is > > > (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for > > > accesses which reach the last sector. > > > > Ok, thanks for explaining it better. I have no objection to this change > > anymore. > > So, for forms sake to take this through the SCSI tree I need at least > one USB person to ack it ... > > James > -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgp2JcUXGwDbZ.pgp Description: PGP signature
Re: USB_SC_* vs USB_PR_* in unusual_dev.h
On Sat, Jan 19, 2008 at 09:25:57PM -0700, Grant Grundler wrote:
> Hi,
> I'm slightly confused by this declaration in drivers/usb/storage/usb.c:
> #define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
> vendorName, productName,useProtocol, useTransport, \
> initFunction, flags) \
> ...
>
> and in unusual.h:
> UAL_DEV( 0x03eb, 0x2002, 0x0100, 0x0100,
> "ATMEL",
> "SND1 Storage",
> US_SC_DEVICE, US_PR_DEVICE, NULL,
> US_FL_IGNORE_RESIDUE),
>
> So US_SC_DEVICE ("Sub Classes" per include/linux/usb_usual.h) is used as a
> wild card for useProtocol and US_PR_DEVICE ("Protocols") is the wildcard for
> useTransport?
No, they aren't wildcards.
The value means "use whatever the device presents". It's not used as a
matching parameter. Matching only happens on VID/PID and revision.
Also, the naming is goofy for a reason. The USB spec calls the numbers
"SubClass" and "Protocol". However, the way they are used, the SubClass
defines the protocol (i.e. language) the device uses; the "Protocol"
defines the transport (i.e. how messages are packed for exchange).
There is no USB-spec field named 'Transport'.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
You were using cheat codes too. You guys suck.
-- Greg to General Studebaker
User Friendly, 12/16/1997
pgpAEZt1U8r7p.pgp
Description: PGP signature
Re: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote: > > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: > > We may be able to convince the SCSI people to enable it for all devices, > > regardless of HCD. > > No ... I'm not particularly keen to have enterprise vendors after my > blood ... Fair enough. Tho, we should probably just enable this blindly for all usb-storage devices. Otherwise, this is just going to become an unusual_devs.h nightmare. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgps8kgiJqubH.pgp Description: PGP signature
Re: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote: > Guillaume Bedot wrote: > >But it fixes only two models. > >Do you think other devices (hp or not) can be impacted ? > >There are hundreds of models with card readers only for hp : > >http://hplip.sourceforge.net/supported_devices/combined.html > > > >Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without > >recompiling a kernel ? > > > > This is not possible AFAIK, I've already wrote a blog post about this > asking for people to test this, but got no responses. Once the patches are accepted by the SCSI people, one of the things we can consider doing is enabling this quirk for all USB devices. It should be pretty harmless to all properly working devices, and the performance hit should be pretty minimal. We may be able to convince the SCSI people to enable it for all devices, regardless of HCD. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What the hell are you? -- Pitr to Dust Puppy User Friendly, 12/3/1997 pgpRWo6penKzA.pgp Description: PGP signature
Re: [usb-storage] PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
On Fri, Jan 11, 2008 at 09:14:00PM +0100, Hans de Goede wrote: > Boaz Harrosh wrote: > >Yes, you're right. in ULDs it is a much proper way to do this. > > > >So I guess you'll have to do that special host flag or device > >flag, and add a check for it in sd.c. You'll see that sd.c is > >already doing bufflen truncation at sd_prep_fn(), just add one > >more case. > > > > Done, thanks for the hint. Patch implementing my fix this way attached, > please apply. Well, I can't say that I'm really a big fan of matching a multi-interface device based on the interface class code, but I don't see a better solution that isn't a major coding project. This approach looks pretty reasonable to me. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver SP: I sell software for Microsoft. Can you set me free? DP: Natural Selection says I shouldn't. -- MS Salesman and Dust Puppy User Friendly, 4/2/1998 pgp9FJvB3odLe.pgp Description: PGP signature
Re: [linux-usb-devel] Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
On Wed, Jan 09, 2008 at 10:44:49PM +0100, Hans de Goede wrote: > First of all sorry for the somewhat massive cross-posting, I've spend a > significant amount of time hunting down this bug, and so far the response > has been less the overwhelming. > The cardreader of the multi function printers will "crash" and from that > moment on no longer communicate in any sane way, if you try to read the > last sector of an sdcard* in a read that is more then 1 sector, so trying > to read 8 sectors starting at sector capicity-8 will crash it, as will > reading 2 sectors starting at sector capicity-2, however reading the last > sector in a one 1 sector read will succeed! (* xdcards seem to be fine). To continue the history on this we over in usb-storage land looked at this and think it belongs in the SCSI layer. We don't like changing commands in-flight; it has, historically, caused us all sorts of issues in the past. Furthermore, this seems like the likely sort of off-by-one bug that can affect many types of devices, not just USB. I'd really like to see this in sd_mod -- I have no objection to requiring an HCD to set a flag to indicate that it should be used, if really desired. But, it seems to me to be a much easier change to make where the command originated rather than in mid-flight. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgpDVIBta4H5k.pgp Description: PGP signature
Re: WD My Book 500G external drive: error -110
On Tue, Jan 08, 2008 at 09:21:43PM -0800, Pete Zaitcev wrote: > On Tue, 08 Jan 2008 18:56:03 -0500, Sean Darcy <[EMAIL PROTECTED]> wrote: > > > head -20 /tmp/1.mon.out > > 810037f38d80 3045534577 S Ii:2:001:1 -115:128 2 < > > 81000fe64cc0 3045534596 S Ci:2:001:0 s a3 00 0001 0004 4 < > > 20 lines is never sufficient with usbmon. It's more like 20 thousand. > But never mind that, I think the -110 you're getting is a clear > indication that interrupts are not routed for the device. > > As such it has nothing to do with USB. I agree. The usb-storage driver isn't even getting bound to the device, which is a different problem than was being reported in the URL Sean provided. That URL showed a device enumerating at least somewhat successfully and then failing during a SCSI reset. Do other USB devices work on this machine? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Would you mind not using our Web server? We're trying to have a game of Quake here. -- Greg User Friendly, 5/11/1998 pgpri47Ni0S0G.pgp Description: PGP signature
Re: hangs swapping on usb storage
On Mon, Jan 07, 2008 at 03:51:39PM +0100, Oliver Neukum wrote: > I am using my usb flash stick as a swap space. If I use a few hundred mb > I get a hang in about 30% of the tests. Can anybody replicate this result? I've never tried it, but it doesn't suprise me. There are memory allocation calls in the URB submission paths. I would expect those calls to fail when under memory pressure. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Oh BAY-bee. -- Dust Puppy to Greg User Friendly, 12/13/1997 pgpS74UIXtGY9.pgp Description: PGP signature
Re: WD My Book 500G external drive: error -110
On Sun, Jan 06, 2008 at 05:00:08PM -0500, sean darcy wrote: > It's a dual boot desktop. XP sees the usb hard drive, and I can run the > WD extended diagnostics on the drive. > googling did show some other reports, e.g. > http://forum.freespire.org/archive/index.php/t-6479.html, but no solutions. > > Any linux diagnostics that would be useful? Looking at that link, it seems likely that you cut too much from your logs. Can you show us more? Specifically, the link shows some SCSI messages that you do not... Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK -- Greg User Friendly, 3/27/1998 pgpm220bh9rsq.pgp Description: PGP signature
Re: WD My Book 500G external drive: error -110
On Sun, Jan 06, 2008 at 05:00:08PM -0500, sean darcy wrote: > Alan Stern wrote: > >On Sat, 5 Jan 2008, seandarcy wrote: > > > >>I'm running Fedora 8: > >> > >>uname -r > >>2.6.23.8-63.fc8 > >> > >>I connected my new Western Digital My Book 500G external drive to the > >>usb port. > >> > >>syslog: > >> > >>Jan 5 21:53:35 testbox kernel: usb 1-4: new high speed USB device using > >>ehci_hcd and address 2 > >>Jan 5 21:53:50 testbox kernel: usb 1-4: device descriptor read/64, > >>error -110 > >>Jan 5 21:54:05 testbox kernel: usb 1-4: device descriptor read/64, > >>error -110 > >>Jan 5 21:54:05 testbox kernel: usb 1-4: new high speed USB device using > >>ehci_hcd and address 3 > >>Jan 5 21:54:20 testbox kernel: usb 1-4: device descriptor read/64, > >>error -110 > >>Jan 5 21:54:36 testbox kernel: usb 1-4: device descriptor read/64, > >>error -110 > >>Jan 5 21:54:36 testbox kernel: usb 1-4: new high speed USB device using > >>ehci_hcd and address 4 > >>Jan 5 21:54:41 testbox kernel: usb 1-4: device descriptor read/8, error > >>-110 > >>. > >> > >>Any help apprecoated. > > > >It certainly looks like either the disk drive's USB interface or your > >computer's USB controller isn't working. > > > >You can try attaching the drive to a different computer or attaching > >different high-speed USB devices to your computer. That should > >indicate which component is at fault. > > > >Alan Stern > > > > It's a dual boot desktop. XP sees the usb hard drive, and I can run the > WD extended diagnostics on the drive. > googling did show some other reports, e.g. > http://forum.freespire.org/archive/index.php/t-6479.html, but no solutions. > > Any linux diagnostics that would be useful? Try rmmod'ing ehci_hcd. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A: The most ironic oxymoron wins ... DP: "Microsoft Works" A: Uh, okay, you win. -- A.J. & Dust Puppy User Friendly, 1/18/1998 pgpXMLwLXvZAm.pgp Description: PGP signature
Re: SD card reader problem
On Mon, Dec 31, 2007 at 04:55:21PM -0500, Alan Stern wrote: > On Mon, 31 Dec 2007, Bruce Schultz wrote: > > > Hi, > > > > I have a USB SD card reader which has never worked properly and finally got > > me > > annoyed enough to try to do something about it. Using a 2.6.22 kernel > > (gentoo), I get the following output in dmesg when I plug it in (with a > > 128MB > > SD card inserted): > > > > sd 8:0:0:0: [sdb] 248320 512-byte hardware sectors (127 MB) > > sd 8:0:0:0: [sdb] Write Protect is off > > sd 8:0:0:0: [sdb] Mode Sense: 03 00 00 00 > > sd 8:0:0:0: [sdb] Assuming drive cache: write through > > sd 8:0:0:0: [sdb] 248320 512-byte hardware sectors (127 MB) > > sd 8:0:0:0: [sdb] Write Protect is off > > sd 8:0:0:0: [sdb] Mode Sense: 03 00 00 00 > > sd 8:0:0:0: [sdb] Assuming drive cache: write through > > sdb: sdb1 > > end_request: I/O error, dev sdb, sector 248313 > ... > > After a bit of googling, I tried patching unusual_devs.h, which got me far > > enough to be able to mount /dev/sdb1 and I seem to be able to read/write to > > the SD card, but with errors in the dmesg output still. So I guess I'm on > > the > > right track, but maybe there's something else I'm missing? Any pointers out > > there? > > You need to do a low-level format of the card. Delete and then > recreate the first partition. And then of course you'll have to > recreate the VFAT filesystem on it. That will work, but I don't think it's optimal. Looking at the logs provided, I think this might be one of those devices that doesn't like reading the last sector if it's part of a multi-sector request. Didn't we add a new flag type recently to cope with this condition? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver God, root, what is difference? -- Pitr User Friendly, 11/11/1999 pgpiduyazyuZh.pgp Description: PGP signature
Re: Problem with Sandisk Micro 4GB
Looks like sd_mod isn't loaded. You need to figure out why that is; it's usually done by udev in response to a direct-access device being detected. Matt On Tue, Jan 01, 2008 at 01:19:20PM -0500, Genera Guillory wrote: > I have a Sandisk Micro Flash Drive and I have removed the U3 stuff > using the Sandisk tool and reformated the drive from Windows. Windows > has no problem seeing the drive. Now when I switch to Linux 2.6.18 > and plug in the device it is recognized - here is what shows up in the > logs > > Jan 1 12:33:59 firewall kernel: usb 1-1: new high speed USB device > using ehci_hcd and address 3 > Jan 1 12:33:59 firewall kernel: usb 1-1: configuration #1 chosen from 1 > choice > Jan 1 12:33:59 firewall kernel: scsi1 : SCSI emulation for USB Mass > Storage devices > Jan 1 12:34:04 firewall kernel: Vendor: SanDisk Model: U3 Cruzer > Micro Rev: 4.05 > Jan 1 12:34:04 firewall kernel: Type: Direct-Access >ANSI SCSI revision: 02 > Jan 1 12:34:04 firewall kernel: scsi 1:0:0:0: Attached scsi generic sg0 type > 0 > > lsmod shows usb_storage loaded > > usblp 12800 0 > usb_storage32900 0 > scsi_mod 92168 4 sr_mod,sg,ide_scsi,usb_storage > usbcore 109572 5 usblp,usb_storage,uhci_hcd,ehci_hcd > > > lsscsi -g just gives > > [1:0:0:0]diskSanDisk U3 Cruzer Micro 4.05 - /dev/sg0 > > and the /dev directory only has the devices /dev/sg0 and /dev/sg1 no > /dev/sda or /dev/sdb entries. So the scsi generic device is created > and associated, but the corresponding block device is not created or > associated and hance there is nothing I can mount. Any clues on what > to do would be greatly appreciated. > - > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver You are needink to look more evil. You likink very strong coffee? -- Pitr to Dust Puppy User Friendly, 10/16/1998 pgp8YROicUejS.pgp Description: PGP signature
Re: Issue with USB thumb drives on gumstix port
Autoloading depends on your distro configuration. The kernel won't request
the module automatically, but my udev has the following:
ACTION=="add", SUBSYSTEM=="scsi_device", SYSFS{type}=="0|7|14", \
RUN+="modprobe sd_mod"
My udev is older than yours (095-17) so I would assume that you have the
same rule. But, it could have been added by my distro.
Matt
On Sat, Dec 22, 2007 at 06:39:52AM -0800, Steve Sakoman wrote:
> Matt,
>
> You hit it on the first try! Everything works if I manually load
> sd_mod.
>
> Should sd_mod be loading automatically? Or should I add it
> to /etc/modules? Currently I'm only autoloading ohci-hcd and everything
> else USB needs seems to be pulled in as needed.
>
> Thanks!
>
> Steve
>
> On Sat, 2007-12-22 at 00:05 -0800, Matthew Dharm wrote:
> > Is sd_mod getting loaded? What happens if you load it manually?
> >
> > Matt
> >
> > On Fri, Dec 21, 2007 at 11:51:42PM -0800, Steve Sakoman wrote:
> > > I'm working on an OpenEmbedded port for gumstix modules (PXA270 based)
> > > and running into an issue with USB storage devices.
> > >
> > > I am using a 2.6.21 kernel and udev-115.
> > >
> > > Other devices seem to work fine: USB keyboards, Bluetooth dongles, etc.
> > >
> > > However when I insert a USB storage device the mount process doesn't
> > > quite complete:
> > >
> > > <6>usb 1-2.3: new full speed USB device using pxa27x-ohci and address 6
> > > <6>usb 1-2.3: configuration #1 chosen from 1 choice
> > > <6>scsi2 : SCSI emulation for USB Mass Storage devices
> > > <7>usb-storage: device found at 6
> > > <7>usb-storage: waiting for device to settle before scanning
> > > <5>scsi 2:0:0:0: Direct-Access USB 2.0 Flash Drive 0.00 PQ: 0
> > > ANSI: 2
> > > <7>usb-storage: device scan complete
> > >
> > > And nothing further--the expected sda device is never created.
> > >
> > > This is new territory for me. Any advice on where I should begin
> > > looking? Is this a udev thing?
> > >
> > > Thanks!
> > >
> > > Steve
> > >
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > > the body of a message to [EMAIL PROTECTED]
> > > 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 [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Dudes! May the Open Source be with you.
-- Eric S. Raymond
User Friendly, 12/3/1998
pgpi1SRr2S1XI.pgp
Description: PGP signature
Re: Issue with USB thumb drives on gumstix port
Is sd_mod getting loaded? What happens if you load it manually? Matt On Fri, Dec 21, 2007 at 11:51:42PM -0800, Steve Sakoman wrote: > I'm working on an OpenEmbedded port for gumstix modules (PXA270 based) > and running into an issue with USB storage devices. > > I am using a 2.6.21 kernel and udev-115. > > Other devices seem to work fine: USB keyboards, Bluetooth dongles, etc. > > However when I insert a USB storage device the mount process doesn't > quite complete: > > <6>usb 1-2.3: new full speed USB device using pxa27x-ohci and address 6 > <6>usb 1-2.3: configuration #1 chosen from 1 choice > <6>scsi2 : SCSI emulation for USB Mass Storage devices > <7>usb-storage: device found at 6 > <7>usb-storage: waiting for device to settle before scanning > <5>scsi 2:0:0:0: Direct-Access USB 2.0 Flash Drive 0.00 PQ: 0 > ANSI: 2 > <7>usb-storage: device scan complete > > And nothing further--the expected sda device is never created. > > This is new territory for me. Any advice on where I should begin > looking? Is this a udev thing? > > Thanks! > > Steve > > > - > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: They kicked your ass, didn't they? S: They were cheating! -- The Chief and Stef User Friendly, 11/19/1997 pgp6TLBF5lhIG.pgp Description: PGP signature
