Re: [BUG] 2.6.24-git usb reset problems
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.
Thanks
Boaz
---
drivers/usb/storage/freecom.c |4 ++--
drivers/usb/storage/transport.c | 12 +---
drivers/usb/storage/transport.h |3 ++-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c
index f5a4e8d..8d77603 100644
--- a/drivers/usb/storage/freecom.c
+++ b/drivers/usb/storage/freecom.c
@@ -132,7 +132,7 @@ freecom_readdata (struct scsi_cmnd *srb, struct us_data *us,
/* Now transfer all of our blocks. */
US_DEBUGP("Start of read\n");
- result = usb_stor_bulk_srb(us, ipipe, srb);
+ result = usb_stor_bulk_srb_length(us, ipipe, srb, count);
US_DEBUGP("freecom_readdata done!\n");
if (result > USB_STOR_XFER_SHORT)
@@ -165,7 +165,7 @@ freecom_writedata (struct scsi_cmnd *srb, struct us_data
*us,
/* Now transfer all of our blocks. */
US_DEBUGP("Start of write\n");
- result = usb_stor_bulk_srb(us, opipe, srb);
+ result = usb_stor_bulk_srb_length(us, opipe, srb, count);
US_DEBUGP("freecom_writedata done!\n");
if (result > USB_STOR_XFER_SHORT)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..5072235 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
* Common used function. Transfer a complete command
* via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
*/
-int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
- struct scsi_cmnd* srb)
+int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
+ struct scsi_cmnd* srb, unsigned length)
{
unsigned int partial;
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
- scsi_sg_count(srb), scsi_bufflen(srb),
+ scsi_sg_count(srb), length,
&partial);
scsi_set_resid(srb, scsi_bufflen(srb) - partial);
return result;
}
+int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
+ struct scsi_cmnd* srb)
+{
+ return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
+}
+
/*
* Transfer an entire SCSI command's worth of data payload over the bulk
* pipe.
diff --git a/drivers/usb/storage/transport.h b/drivers/usb/storage/transport.h
index ada7c2f..03e395d 100644
--- a/drivers/usb/storage/transport.h
+++ b/drivers/usb/storage/transport.h
@@ -139,8 +139,9 @@ extern int usb_stor_bulk_transfer_buf(s
Re: [BUG] 2.6.24-git usb reset problems
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: > >>> 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. > > > > 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' -- Jens Axboe - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 17:36 +0200, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>
>> --- a/drivers/usb/storage/transport.c
>> +++ b/drivers/usb/storage/transport.c
>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
>> us_data *us, unsigned int pipe,
>> * Common used function. Transfer a complete command
>> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>> */
>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>> - struct scsi_cmnd* srb)
>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
>> + struct scsi_cmnd* srb, unsigned length)
>> {
>> unsigned int partial;
>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>> - scsi_sg_count(srb), scsi_bufflen(srb),
>> + scsi_sg_count(srb), length,
>>&partial);
>>
>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>> return result;
>> }
>>
>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>> +struct scsi_cmnd* srb)
>> +{
>> +return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
>> +}
>> +
>
> I don't like this patch very much. Why add another layer of
> indirection when the two subroutines do hardly any work? Leave
> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
> and scsi_set_resid().
>
> BTW, the standard coding style calls for a blank line after the list of
> local variables at the start of a function or block.
>
> Alan Stern
>
> -
Me neither, it's not a proper patch just a shut to try and find the reported
bug. I will submit a proper bug later.
Thanks for the review, you are right on all accounts
Boaz
-
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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>
> > --- a/drivers/usb/storage/transport.c
> > +++ b/drivers/usb/storage/transport.c
> > @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
> > us_data *us, unsigned int pipe,
> > * Common used function. Transfer a complete command
> > * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> > */
> > -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > - struct scsi_cmnd* srb)
> > +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> > + struct scsi_cmnd* srb, unsigned length)
> > {
> > unsigned int partial;
> > int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> > - scsi_sg_count(srb), scsi_bufflen(srb),
> > + scsi_sg_count(srb), length,
> > &partial);
> >
> > scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> > return result;
> > }
> >
> > +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > + struct scsi_cmnd* srb)
> > +{
> > + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> > +}
> > +
>
> I don't like this patch very much. Why add another layer of
> indirection when the two subroutines do hardly any work? Leave
> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
> and scsi_set_resid().
>
> BTW, the standard coding style calls for a blank line after the list of
> local variables at the start of a function or block.
There's another bug in the transport.c conversion in that the residuals
are updated with bogus data in several error cases, since
usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
is actually sent.
I'm not sure if this is is the solution to the problem at hand, but it
definitely fixes another bug in the code.
James
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..bab0858 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
struct scsi_cmnd* srb)
{
- unsigned int partial;
+ unsigned int partial = scsi_get_resid(srb);
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
scsi_sg_count(srb), scsi_bufflen(srb),
&partial);
-
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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 16:31 +0200, Oliver Neukum <[EMAIL PROTECTED]> 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. > > Regards > Oliver > - I can not see what it is. Yes CONFIG_USB_STORAGE_DEBUG will help. I have a device here that uses the same trasport/protocol I'll try to reproduce the failure here. Boaz - 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
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, 29 Jan 2008, Robert Spitzenpfeil wrote: > --- linux/drivers/usb/storage/unusual_devs.h.orig 2007-07-03 > 18:44:59.0 +0100 > +++ linux/drivers/usb/storage/unusual_devs.h2007-07-03 > 19:01:47.0 +0100 > @@ -1317,6 +1317,16 @@ > US_SC_DEVICE, US_PR_DEVICE, NULL, > US_FL_IGNORE_RESIDUE | US_FL_GO_SLOW | > US_FL_MAX_SECTORS_64), > > +/* Patch by Leonid Petrov mail at lpetrov.net > + * http://www.qbik.ch/usb/devices/showdev.php?id=1705 > + * Updated to 103 device by MJ Ray mjr at phonecoop.coop > + */ > +UNUSUAL_DEV( 0x0f19, 0x0103, 0x0100, 0x0100, > + "Oracom Co., Ltd", > + "ORC-200M", > +US_SC_DEVICE, US_PR_DEVICE, NULL, > +US_FL_IGNORE_RESIDUE | US_FL_FIX_INQUIRY), > + The US_FL_FIX_INQUIRY flag almost certainly isn't needed. Can you verify that the device works okay without that flag? Alan Stern - 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
Re: [BUG] 2.6.24-git usb reset problems
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. Regards Oliver - 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
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, Jan 29, 2008 at 11:34:24AM +0100, Robert Spitzenpfeil wrote: > greetings, > > opensuse people wanted me to forward this patch to the list: > > > The new patch for linux-2.6.21.5 is: Can you resend this, your email client ate all the tabs for lunch and spit out spaces instead and then decided to line-wrap the patch as well :( Also, we need a "Signed-off-by:" line as per the Documentation/SubmittingPatches file, as well as the output of /proc/bus/usb/devices with this device plugged in. thanks, greg k-h - 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
[patch v6 3/4] USB: add Cypress c67x00 OTG controller HCD driver
This patch adds HCD support for the Cypress c67x00 family of devices.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
drivers/usb/Makefile |2
drivers/usb/c67x00/Makefile| 11
drivers/usb/c67x00/c67x00-drv.c| 13
drivers/usb/c67x00/c67x00-hcd.c| 410
drivers/usb/c67x00/c67x00-hcd.h| 152
drivers/usb/c67x00/c67x00-ll-hpi.c | 75 ++
drivers/usb/c67x00/c67x00-sched.c | 1194 +
drivers/usb/c67x00/c67x00.h|9
drivers/usb/host/Kconfig | 12
9 files changed, 1878 insertions(+)
Index: linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
@@ -0,0 +1,410 @@
+/*
+ * c67x00-hcd.c: Cypress C67X00 USB Host Controller Driver
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+
+#include "c67x00.h"
+#include "c67x00-hcd.h"
+
+/* --
+ * Root Hub Support
+ */
+
+static __u8 c67x00_hub_des[] = {
+ 0x09, /* __u8 bLength; */
+ 0x29, /* __u8 bDescriptorType; Hub-descriptor */
+ 0x02, /* __u8 bNbrPorts; */
+ 0x00, /* __u16 wHubCharacteristics; */
+ 0x00, /* (per-port OC, no power switching) */
+ 0x32, /* __u8 bPwrOn2pwrGood; 2ms */
+ 0x00, /* __u8 bHubContrCurrent; 0 mA */
+ 0x00, /* __u8 DeviceRemovable; ** 7 Ports max ** */
+ 0xff, /* __u8 PortPwrCtrlMask; ** 7 ports max ** */
+};
+
+static void c67x00_hub_reset_host_port(struct c67x00_sie *sie, int port)
+{
+ struct c67x00_hcd *c67x00 = sie->private_data;
+ unsigned long flags;
+
+ c67x00_ll_husb_reset(sie, port);
+
+ spin_lock_irqsave(&c67x00->lock, flags);
+ c67x00_ll_husb_reset_port(sie, port);
+ spin_unlock_irqrestore(&c67x00->lock, flags);
+
+ c67x00_ll_set_husb_eot(sie->dev, DEFAULT_EOT);
+}
+
+static int c67x00_hub_status_data(struct usb_hcd *hcd, char *buf)
+{
+ struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
+ struct c67x00_sie *sie = c67x00->sie;
+ u16 status;
+ int i;
+
+ *buf = 0;
+ status = c67x00_ll_usb_get_status(sie);
+ for (i = 0; i < C67X00_PORTS; i++)
+ if (status & PORT_CONNECT_CHANGE(i))
+ *buf |= (1 << i);
+
+ /* bit 0 denotes hub change, b1..n port change */
+ *buf <<= 1;
+
+ return !!*buf;
+}
+
+static int c67x00_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+ u16 wIndex, char *buf, u16 wLength)
+{
+ struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
+ struct c67x00_sie *sie = c67x00->sie;
+ u16 status, usb_status;
+ int len = 0;
+ unsigned int port = wIndex-1;
+ u16 wPortChange, wPortStatus;
+
+ switch (typeReq) {
+
+ case GetHubStatus:
+ *(__le32 *) buf = cpu_to_le32(0);
+ len = 4;/* hub power */
+ break;
+
+ case GetPortStatus:
+ if (wIndex > C67X00_PORTS)
+ return -EPIPE;
+
+ status = c67x00_ll_usb_get_status(sie);
+ usb_status = c67x00_ll_get_usb_ctl(sie);
+
+ wPortChange = 0;
+ if (status & PORT_CONNECT_CHANGE(port))
+ wPortChange |= USB_PORT_STAT_C_CONNECTION;
+
+ wPortStatus = USB_PORT_STAT_POWER;
+ if (!(status & PORT_SE0_STATUS(port)))
+ wPortStatus |= USB_PORT_STAT_CONNECTION;
+ if (usb_status & LOW_SPEED_PORT(port)) {
+ wPortStatus |= USB_PORT_STAT_LOW_SPEED;
+ c67x00->low_speed_ports |= (1 << port);
+ } else
+ c67x00->low_speed_ports &= ~(1 << port);
[patch v6 4/4] USB: add Cypress c67x00 OTG controller gadget driver
This patch adds USB gadget support for the Cypress c67x00 family of devices.
This is work in progress and not ready to be committed yet. I'm posting this
to show how it fits with the rest of the driver and to collect feedback.
The driver works good enought to use g_serial, but there are still issues
to be solved. The biggest issue is that endpoint 0 is currently handled by
the BIOS inside the c67x00, so the gadget stack never sees the data.
The BIOS also has other deficiencies, E.G. see the patching done in
c67x00_ll_susb_init().
---
drivers/usb/Kconfig|2
drivers/usb/Makefile |2
drivers/usb/c67x00/Kconfig | 21
drivers/usb/c67x00/Makefile|7
drivers/usb/c67x00/c67x00-drv.c| 11
drivers/usb/c67x00/c67x00-ll-hpi.c | 201
drivers/usb/c67x00/c67x00-udc.c| 905 +
drivers/usb/c67x00/c67x00-udc.h| 50 ++
drivers/usb/c67x00/c67x00.h| 21
drivers/usb/gadget/Kconfig |7
drivers/usb/gadget/gadget_chips.h |8
drivers/usb/host/Kconfig | 12
12 files changed, 1232 insertions(+), 15 deletions(-)
Index: linux-2.6/drivers/usb/c67x00/c67x00-udc.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-udc.c
@@ -0,0 +1,905 @@
+/*
+ * c67x00-udc.c: Cypress C67X00 USB device controller
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple device controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "c67x00.h"
+#include "c67x00-udc.h"
+
+/* Defined in DEVICE n ENDPOINT STATUS REGISTERS */
+#define OVERFLOW_FLG 0x0800 /* Receive overflow */
+#define UNDERFLOW_FLG 0x0400 /* Receive underflow */
+#define OUT_EXCEPTION_FLG 0x0200 /* OUT received when armed for IN */
+#define IN_EXCEPTION_FLG 0x0100 /* IN received when armed for OUT */
+#define STALL_FLG 0x0080 /* Stall sent */
+#define NAK_FLG0x0040 /* NAK sent */
+#define LENGTH_EXCEPT_FLG 0x0020 /* Overflow or Underflow occured */
+#define SETUP_FLG 0x0010 /* SETUP packet received */
+#define SEQ_STAT 0x0008 /* Last Data Toggle Sequence bit sent
+ or received */
+#define TIMEOUT_FLG0x0004 /* Last transmission timed out */
+#define ERROR_FLG 0x0002 /* CRC Err detected in last
+ reception*/
+#define ACK_FLG0x0001 /* Last transaction ACK'D (sent
+ or received) */
+
+/* Defined in DEVICE n ENDPOINT CONTROL REGISTERS */
+#define DIR_SEL_IN 0x0004 /* Last transmission timed out */
+#define EP_ENABLE 0x0002 /* Enable Endpoint */
+
+
+
+struct c67x00_request {
+ struct usb_request req;
+ struct list_head queue;
+};
+
+
+
+struct c67x00_udc_ep {
+ struct usb_ep ep;
+ struct c67x00_udc *udc;
+
+ struct list_head queue;
+ int ep_num;
+ int is_ep_in;
+ int enable;
+ int stopped;
+ int start_io;
+};
+
+#define C67X00_MAX_NB_END_POINTS 8
+
+struct c67x00_udc {
+ spinlock_t lock;
+ struct c67x00_sie *sie;
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct c67x00_udc_ep ep[C67X00_MAX_NB_END_POINTS];
+ struct work_struct io_work;
+ int config_nr;
+ /* The highest string descriptor entry
+ (used to retrieve descriptors from gadget driver) */
+ int top_str_id;
+ u16 string_desc_addr;
+};
+
+const static unsigned char get_descriptor_device[] = {
+ USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ USB_REQ_GET_DESCRIPTOR,
+ 0x00,
+ USB_DT_DEVICE,
+ 0x00,
+ 0x00,
+ 0x12,
+ 0x00
+};
+
+const static unsigned char get_descriptor_config[] = {
+ USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ USB_REQ_GET_DESCRIPTOR,
+ 0x00,
+ USB_DT_CONFIG,
+ 0x00,
+ 0x00,
+
[patch v6 1/4] USB: add Cypress c67x00 low level interface code
This patch adds the low level support code for the Cypress c67x00 family of OTG controllers. The low level code is responsible for register access and implements the software protocol for communicating with the 16bit microcontroller inside the c67x00 device. Communication is done over the HPI interface (16bit SRAM-like parallel bus). Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> --- drivers/usb/c67x00/c67x00-ll-hpi.c | 410 + drivers/usb/c67x00/c67x00.h| 285 + 2 files changed, 695 insertions(+) Index: linux-2.6/drivers/usb/c67x00/c67x00.h === --- /dev/null +++ linux-2.6/drivers/usb/c67x00/c67x00.h @@ -0,0 +1,285 @@ +/* + * c67x00.h: Cypress C67X00 USB register and field definitions + * + * Copyright (C) 2006-2008 Barco N.V. + *Derived from the Cypress cy7c67200/300 ezusb linux driver and + *based on multiple host controller drivers inside the linux kernel. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA. + */ + +#ifndef _USB_C67X00_H +#define _USB_C67X00_H + +#include +#include +#include +#include + +/* - + * Cypress C67x00 register definitions + */ + +/* Hardware Revision Register */ +#define HW_REV_REG 0xC004 + +/* General USB registers */ +/* = */ + +/* USB Control Register */ +#define USB_CTL_REG(x) ((x) ? 0xC0AA : 0xC08A) + +#define LOW_SPEED_PORT(x) ((x) ? 0x0800 : 0x0400) +#define HOST_MODE 0x0200 +#define PORT_RES_EN(x) ((x) ? 0x0100 : 0x0080) +#define SOF_EOP_EN(x) ((x) ? 0x0002 : 0x0001) + +/* USB status register - Notice it has different content in hcd/udc mode */ +#define USB_STAT_REG(x)((x) ? 0xC0B0 : 0xC090) + +#define EP0_IRQ_FLG0x0001 +#define EP1_IRQ_FLG0x0002 +#define EP2_IRQ_FLG0x0004 +#define EP3_IRQ_FLG0x0008 +#define EP4_IRQ_FLG0x0010 +#define EP5_IRQ_FLG0x0020 +#define EP6_IRQ_FLG0x0040 +#define EP7_IRQ_FLG0x0080 +#define RESET_IRQ_FLG 0x0100 +#define SOF_EOP_IRQ_FLG0x0200 +#define ID_IRQ_FLG 0x4000 +#define VBUS_IRQ_FLG 0x8000 + +/* USB Host only registers */ +/* === */ + +/* Host n Control Register */ +#define HOST_CTL_REG(x)((x) ? 0xC0A0 : 0xC080) + +#define PREAMBLE_EN0x0080 /* Preamble enable */ +#define SEQ_SEL0x0040 /* Data Toggle Sequence Bit Select */ +#define ISO_EN 0x0010 /* Isochronous enable */ +#define ARM_EN 0x0001 /* Arm operation */ + +/* Host n Interrupt Enable Register */ +#define HOST_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C) + +#define SOF_EOP_IRQ_EN 0x0200 /* SOF/EOP Interrupt Enable */ +#define SOF_EOP_TMOUT_IRQ_EN 0x0800 /* SOF/EOP Timeout Interrupt Enable */ +#define ID_IRQ_EN 0x4000 /* ID interrupt enable */ +#define VBUS_IRQ_EN0x8000 /* VBUS interrupt enable */ +#define DONE_IRQ_EN0x0001 /* Done Interrupt Enable */ + +/* USB status register */ +#define HOST_STAT_MASK 0x02FD +#define PORT_CONNECT_CHANGE(x) ((x) ? 0x0020 : 0x0010) +#define PORT_SE0_STATUS(x) ((x) ? 0x0008 : 0x0004) + +/* Host Frame Register */ +#define HOST_FRAME_REG(x) ((x) ? 0xC0B6 : 0xC096) + +#define HOST_FRAME_MASK0x07FF + +/* USB Peripheral only registers */ +/* = */ + +/* Device n Port Sel reg */ +#define DEVICE_N_PORT_SEL(x) ((x) ? 0xC0A4 : 0xC084) + +/* Device n Interrupt Enable Register */ +#define DEVICE_N_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C) + +#define DEVICE_N_ENDPOINT_N_CTL_REG(dev, ep) ((dev) \ +? (0x0280 + (ep << 4)) \ +: (0x0200 + (ep << 4))) +#define DEVICE_N_ENDPOINT_N_STAT_REG(dev, ep) ((dev) \ +? (0x0286 + (ep << 4)) \ +: (0x0206 + (ep << 4))) + +#define DEVICE_N_ADDRESS(dev) ((dev) ? (0xC0
[patch v6 2/4] USB: add Cypress c67x00 OTG controller core driver
This patch add the core driver for the c67x00 USB OTG controller. The core
driver is responsible for the platform bus binding and creating either
USB HCD or USB Gadget instances for each of the serial interface engines
on the chip.
This driver does not directly implement the HCD or gadget behaviours; it
just controls access to the chip.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
MAINTAINERS |6 +
drivers/usb/c67x00/c67x00-drv.c | 232
include/linux/usb/c67x00.h | 48
3 files changed, 286 insertions(+)
Index: linux-2.6/drivers/usb/c67x00/c67x00-drv.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-drv.c
@@ -0,0 +1,232 @@
+/*
+ * c67x00-drv.c: Cypress C67X00 USB Common infrastructure
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+/*
+ * This file implements the common infrastructure for using the c67x00.
+ * It is both the link between the platform configuration and subdrivers and
+ * the link between the common hardware parts and the subdrivers (e.g.
+ * interrupt handling).
+ *
+ * The c67x00 has 2 SIE's (serial interface engine) wich can be configured
+ * to be host, device or OTG (with some limitations, E.G. only SIE1 can be
OTG).
+ *
+ * Depending on the platform configuration, the SIE's are created and
+ * the corresponding subdriver is initialized (c67x00_probe_sie).
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "c67x00.h"
+
+static void c67x00_probe_sie(struct c67x00_sie *sie,
+struct c67x00_device *dev, int sie_num)
+{
+ spin_lock_init(&sie->lock);
+ sie->dev = dev;
+ sie->sie_num = sie_num;
+ sie->mode = c67x00_sie_config(dev->pdata->sie_config, sie_num);
+
+ switch (sie->mode) {
+ case C67X00_SIE_UNUSED:
+ dev_info(sie_dev(sie),
+"Not using SIE %d as requested\n", sie->sie_num);
+ break;
+
+ default:
+ dev_err(sie_dev(sie),
+ "Unsupported configuration: 0x%x for SIE %d\n",
+ sie->mode, sie->sie_num);
+ break;
+ }
+}
+
+static void c67x00_remove_sie(struct c67x00_sie *sie)
+{
+}
+
+static irqreturn_t c67x00_irq(int irq, void *__dev)
+{
+ struct c67x00_device *c67x00 = __dev;
+ struct c67x00_sie *sie;
+ u16 msg, int_status;
+ int i, count = 8;
+
+ int_status = c67x00_ll_hpi_status(c67x00);
+ if (!int_status)
+ return IRQ_NONE;
+
+ while (int_status != 0 && (count-- >= 0)) {
+ c67x00_ll_irq(c67x00, int_status);
+ for (i = 0; i < C67X00_SIES; i++) {
+ sie = &c67x00->sie[i];
+ msg = 0;
+ if (int_status & SIEMSG_FLG(i))
+ msg = c67x00_ll_fetch_siemsg(c67x00, i);
+ if (sie->irq)
+ sie->irq(sie, int_status, msg);
+ }
+ int_status = c67x00_ll_hpi_status(c67x00);
+ }
+
+ if (int_status)
+ dev_warn(&c67x00->pdev->dev, "Not all interrupts handled! "
+"status = 0x%04x\n", int_status);
+
+ return IRQ_HANDLED;
+}
+
+/* - */
+
+static int __devinit c67x00_drv_probe(struct platform_device *pdev)
+{
+ struct c67x00_device *c67x00;
+ struct c67x00_platform_data *pdata;
+ struct resource *res, *res2;
+ int ret, i;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res2)
+ return -ENODEV;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata)
+ return -ENODEV;
+
+ c67x00 = kzalloc(sizeof(*c67x00), GFP_KERNEL);
+ if (!c67x00)
+ return -ENOMEM;
[patch v6 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
USB controllers. This patch series implements a HCD driver and shows the
work-in-progress status of a gadget driver.
I believe patch 1..3 are ready, and I would like to see them queued up for
2.6.25.
Changes since v5:
- Merged c67x00_ll_{get,set}_siemsg() into c67x00_ll_fetch_siemsg().
- Fix for interrupt race condition at probe time (reported by Grant)
Changes since v4:
- Addressed Grant's comments (c67x00_dev->c67x00_hcd_dev, label indent)
- Moved c67x00_ll_set_ep_{ctrl,packet_size}_reg() to patch 4 as they are
only needed for gadget support.
- Added c67x00_ prefix to struct lcp_int_data
Changes since v3:
- Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
- The dummy platform_device's created per serial engine are gone.
- Gadget driver (WIP)
--
Bye, Peter Korsgaard
-
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
request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
greetings, opensuse people wanted me to forward this patch to the list: The new patch for linux-2.6.21.5 is: --- linux/drivers/usb/storage/unusual_devs.h.orig 2007-07-03 18:44:59.0 +0100 +++ linux/drivers/usb/storage/unusual_devs.h2007-07-03 19:01:47.0 +0100 @@ -1317,6 +1317,16 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE | US_FL_GO_SLOW | US_FL_MAX_SECTORS_64), +/* Patch by Leonid Petrov mail at lpetrov.net + * http://www.qbik.ch/usb/devices/showdev.php?id=1705 + * Updated to 103 device by MJ Ray mjr at phonecoop.coop + */ +UNUSUAL_DEV( 0x0f19, 0x0103, 0x0100, 0x0100, + "Oracom Co., Ltd", + "ORC-200M", +US_SC_DEVICE, US_PR_DEVICE, NULL, +US_FL_IGNORE_RESIDUE | US_FL_FIX_INQUIRY), + /* David Kuehling <[EMAIL PROTECTED]>: * for MP3-Player AVOX WSX-300ER (bought in Japan). Reports lots of SCSI * errors when trying to write. would be great if it were included in the vanilla kernel. cheers, r. spitzenpfeil - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
> *us, unsigned int pipe,
> * Common used function. Transfer a complete command
> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> */
> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> - struct scsi_cmnd* srb)
> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb, unsigned length)
> {
> unsigned int partial;
> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> - scsi_sg_count(srb), scsi_bufflen(srb),
> + scsi_sg_count(srb), length,
> &partial);
>
> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> return result;
> }
>
> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb)
> +{
> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> +}
> +
I don't like this patch very much. Why add another layer of
indirection when the two subroutines do hardly any work? Leave
usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
and scsi_set_resid().
BTW, the standard coding style calls for a blank line after the list of
local variables at the start of a function or block.
Alan Stern
-
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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 16:11 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > 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: > 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. >>> 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' > Sorry for the other noise. Thanks I'll have a look. - 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
Re: [BUG] 2.6.24-git usb reset problems
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: >>> 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. > > 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. Thanks for testing Boaz - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, 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. No difference, still just a lot of resets. -- Jens Axboe - 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
Re: Blackberry through a TT hub
On Sat, 26 Jan 2008, Pete Zaitcev wrote: > My question is, do you have one of those things? Would you hook > it to a hub, check what happens then? I suspect the Berry manages > to detect that it's on a hub (how?!) and supplies wrong descriptors. In theory that isn't possible. Or to put it another way, any device trying to tell the difference between a root hub and an external hub will sometimes be wrong. Alan Stern - 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
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, 29 Jan 2008, Robert Spitzenpfeil wrote: > as per request, I've checked whether the patch works WITHOUT the > "US_FL_FIX_INQUIRY" flag. > result: NO, only works with said flag included. (2.6.22.13-0.3-default > #1 SMP - opensuse 10.3) Really? That's very strange... Devices needing that flag won't work with Windows, as far as I know. Could you please send a usbmon trace (see the instructions in the kernel source file Documentation/usb/usbmon.txt) showing what happens when you plug the device in and the US_FL_FIX_INQUIRY flag isn't set? Alan Stern - 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
Re: [BUG] 2.6.24-git usb reset problems
Am Dienstag, 29. Januar 2008 16:50:35 schrieb Boaz Harrosh: > On Tue, Jan 29 2008 at 16:31 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote: > I can not see what it is. Yes CONFIG_USB_STORAGE_DEBUG will help. > I have a device here that uses the same trasport/protocol I'll > try to reproduce the failure here. This is the most common combination of transport and protocol. If it were broken in a larger number of cases, we'd hear more reports. You'll probably need the debug output to figure out what's wrong. Regards Oliver - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 16:06 +0200, Boaz Harrosh <[EMAIL PROTECTED]> 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:
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.
>> 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.
>
>From inspection of code it should be in /proc/scsi somewhere look for:
SPRINTF(" Protocol: %s\n", us->protocol_name);
SPRINTF("Transport: %s\n", us->transport_name);
(it's proc_info() in drivers/usb/storage/scsiglue.c)
Thanks
Boaz
-
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
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: [BUG] 2.6.24-git usb reset problems
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. -- Jens Axboe - 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
Re: [patch v6 3/4] USB: add Cypress c67x00 OTG controller HCD driver
On Tue, 29 Jan 2008, Peter Korsgaard wrote:
> This patch adds HCD support for the Cypress c67x00 family of devices.
> --- /dev/null
> +++ linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
> +int c67x00_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
> +{
> + struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
> + unsigned long flags;
> + int rc;
> +
> + spin_lock_irqsave(&c67x00->lock, flags);
> + rc = usb_hcd_check_unlink_urb(hcd, urb, status);
> + if (rc)
> + goto done;
> +
> + c67x00_release_urb(c67x00, urb);
> + usb_hcd_unlink_urb_from_ep(hcd, urb);
> + spin_unlock_irqrestore(&c67x00->lock, flags);
> +
> + usb_hcd_giveback_urb(hcd, urb, status);
This is wrong. usb_hcd_giveback_urb() must be called with local
interrupts disabled.
> +/*
> + * pre: urb != NULL and c67x00 locked, urb unlocked
> + */
> +static inline void
> +c67x00_giveback_urb(struct c67x00_hcd *c67x00, struct urb *urb, int status)
> +{
> + struct c67x00_urb_priv *urbp;
> +
> + if (!urb)
> + return;
Since you have the documented precondition that urb != NULL, and since
this routine is never called in a context where urb could be NULL,
there's no need for this test. Also, I doubt that this routine really
needs to be inline (and besides, the compiler is better at making such
decisions than we are).
> +static void c67x00_sched_done(unsigned long __c67x00)
> +{
> + struct c67x00_hcd *c67x00 = (struct c67x00_hcd *)__c67x00;
> + struct c67x00_urb_priv *urbp, *tmp;
> + struct urb *urb;
> +
> + spin_lock(&c67x00->lock);
> +
> + /* Loop over the done list and give back all the urbs */
> + list_for_each_entry_safe(urbp, tmp, &c67x00->done_list, hep_node) {
> + urb = urbp->urb;
> + c67x00_release_urb(c67x00, urb);
> + if (!usb_hcd_check_unlink_urb(c67x00_hcd_to_hcd(c67x00),
> + urb, urbp->status)) {
The function call above is completely wrong. It is meant to be used only
from within the dequeue method.
> + usb_hcd_unlink_urb_from_ep(c67x00_hcd_to_hcd(c67x00),
> +urb);
> + spin_unlock(&c67x00->lock);
> + usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb,
> + urbp->status);
> + spin_lock(&c67x00->lock);
> + }
> + }
> + spin_unlock(&c67x00->lock);
> +}
Is there some reason this routine needs to run in a tasklet? Why not
just call it directly?
Also, the fact that it is in a tasklet means that it runs with
interrupts enabled. Hence your spin_lock() and spin_unlock() calls
will not do the right thing.
Alan Stern
-
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
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
as per request, I've checked whether the patch works WITHOUT the "US_FL_FIX_INQUIRY" flag. result: NO, only works with said flag included. (2.6.22.13-0.3-default #1 SMP - opensuse 10.3) as per request, I resubmit the patch with outputs of "/proc/bus/usb/devices/" "lsusb" "lsusb -v" (only relevant sections included). as I did not develop the patch, but only found it on the web and tested it on my system I will only add "Acked-by:", if I understand the docs right ! --- cut here --- Acked-by: [EMAIL PROTECTED] From: [EMAIL PROTECTED] --- --- unusual_devs.h2008-01-29 17:30:04.0 +0100 +++ ./oracom/unusual_devs.h2008-01-29 17:34:54.0 +0100 @@ -1354,6 +1354,16 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE | US_FL_GO_SLOW | US_FL_MAX_SECTORS_64), +/* Patch by Leonid Petrov mail at lpetrov.net + * http://www.qbik.ch/usb/devices/showdev.php?id=1705 + * Updated to 103 device by MJ Ray mjr at phonecoop.coop + */ +UNUSUAL_DEV( 0x0f19, 0x0103, 0x0100, 0x0100, + "Oracom Co., Ltd", + "ORC-200M", +US_SC_DEVICE, US_PR_DEVICE, NULL, +US_FL_IGNORE_RESIDUE | US_FL_FIX_INQUIRY), + /* David Kuehling <[EMAIL PROTECTED]>: * for MP3-Player AVOX WSX-300ER (bought in Japan). Reports lots of SCSI * errors when trying to write. --- cut here --- /proc/bus/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs= 1 P: Vendor=0f19 ProdID=0103 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 98mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=1ms lsusb: Bus 001 Device 004: ID 0f19:0103 Oracom Co., Ltd lsusb -v: Bus 001 Device 004: ID 0f19:0103 Oracom Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize032 idVendor 0x0f19 Oracom Co., Ltd idProduct 0x0103 bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Device Status: 0x (Bus Powered) - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, 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 :-) > > > > 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. > > My guess would be that sg == NULL, hence the -EINVAL. Yep, trace below: WARNING: at drivers/usb/storage/transport.c:426 usb_stor_bulk_transfer_sglist() Pid: 12536, comm: usb-storage Not tainted 2.6.24 #74 [<7810541a>] show_trace_log_lvl+0x1a/0x30 [<78105e82>] show_trace+0x12/0x20 [<7810689c>] dump_stack+0x6c/0x80 [] usb_stor_bulk_transfer_sglist+0x14e/0x160 [usb_storage] [] usb_stor_bulk_srb_length+0x30/0x50 [usb_storage] [] usb_stor_bulk_srb+0x12/0x20 [usb_storage] [] usb_stor_Bulk_transport+0x190/0x3d0 [usb_storage] [] usb_stor_invoke_transport+0x1b6/0x320 [usb_storage] [] usb_stor_transparent_scsi_command+0x8/0x10 [usb_storage] [] usb_stor_control_thread+0x143/0x2c0 [usb_storage] [<7813bc02>] kthread+0x42/0x70 [<78104fab>] kernel_thread_helper+0x7/0x1c === usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries, sg usb-storage: usb_sg_init returned -22 -- Jens Axboe - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote:
> > Your new code does
> >
> > int partial; <- stack uninitialised
> > sb_stor_bulk_transfer_sglist(..., &partial, ...);
> > scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> >
> > If the function doesn't touch partial, as it doesn't in the error legs,
> > resid now gets set with rubbish.
> >
> > Actually, my code is still wrong .. we have to set it to
> > scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
> > left untouched.
> >
> >> I have such a device and I get one reset but then every thing works nice.
> >> This is with debug on. I'll try to make it fail.
> >
> > James
> >
> >
> Sorry I still don't see it.
>
> original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
>
> but sb_stor_bulk_transfer_sg does the:
> int partial; <- stack uninitialised
> sb_stor_bulk_transfer_sglist(..., &partial, ...);
>
> and then unconditionally sets *residual = length_left;
> I do not see an "error legs" case in sb_stor_bulk_transfer_sg().
This is really programming 101. This:
static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned
int pipe,
struct scatterlist *sg, int num_sg, unsigned int length,
unsigned int *act_len)
{
int result;
/* don't submit s-g requests during abort/disconnect processing */
if (us->flags & ABORTING_OR_DISCONNECTING)
return USB_STOR_XFER_ERROR;
The return USB_STOR_XFER_ERROR; is called an error leg. It returns
without updating *act_len thus leaving &partial uninitialised.
James
-
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
Re: [BUG] 2.6.24-git usb reset problems
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 :-) > > 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. My guess would be that sg == NULL, hence the -EINVAL. -- Jens Axboe - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 20:48 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote:
>> On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <[EMAIL PROTECTED]>
>> wrote:
>>> On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
> us_data *us, unsigned int pipe,
> * Common used function. Transfer a complete command
> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> */
> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> - struct scsi_cmnd* srb)
> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb, unsigned length)
> {
> unsigned int partial;
> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> - scsi_sg_count(srb), scsi_bufflen(srb),
> + scsi_sg_count(srb), length,
> &partial);
>
> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> return result;
> }
>
> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb)
> +{
> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> +}
> +
I don't like this patch very much. Why add another layer of
indirection when the two subroutines do hardly any work? Leave
usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
and scsi_set_resid().
BTW, the standard coding style calls for a blank line after the list of
local variables at the start of a function or block.
>>> There's another bug in the transport.c conversion in that the residuals
>>> are updated with bogus data in several error cases, since
>>> usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
>>> is actually sent.
>>>
>>> I'm not sure if this is is the solution to the problem at hand, but it
>>> definitely fixes another bug in the code.
>>>
>>> James
>>>
>>> diff --git a/drivers/usb/storage/transport.c
>>> b/drivers/usb/storage/transport.c
>>> index d9f4912..bab0858 100644
>>> --- a/drivers/usb/storage/transport.c
>>> +++ b/drivers/usb/storage/transport.c
>>> @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
>>> *us, unsigned int pipe,
>>> int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> struct scsi_cmnd* srb)
>>> {
>>> - unsigned int partial;
>>> + unsigned int partial = scsi_get_resid(srb);
>>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>>> scsi_sg_count(srb), scsi_bufflen(srb),
>>> &partial);
>>>
>>>
>>> -
>> But then this is weird because it is not what usb_stor_bulk_transfer_sg() is
>> doing
>> which was the one called before.
>
> Um, yes it was. The original code did this
>
> sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
>
> Which was at liberty not to touch resid, which it chose not to do in the
> error legs.
>
> Your new code does
>
> int partial; <- stack uninitialised
> sb_stor_bulk_transfer_sglist(..., &partial, ...);
> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>
> If the function doesn't touch partial, as it doesn't in the error legs,
> resid now gets set with rubbish.
>
> Actually, my code is still wrong .. we have to set it to
> scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
> left untouched.
>
>> I have such a device and I get one reset but then every thing works nice.
>> This is with debug on. I'll try to make it fail.
>
> James
>
>
Sorry I still don't see it.
original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
but sb_stor_bulk_transfer_sg does the:
int partial; <- stack uninitialised
sb_stor_bulk_transfer_sglist(..., &partial, ...);
and then unconditionally sets *residual = length_left;
I do not see an "error legs" case in sb_stor_bulk_transfer_sg().
I have just cut and pasted the !use_sg from sb_stor_bulk_transfer_sg names
and all
Boaz
-
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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, 2008-01-29 at 21:06 +0100, Jens Axboe wrote: > > I will ... but it will cause an explosion in the bidirectional tree > > again. I think the bidi updates also fix this. However, give me time > > to rebase and verify. > > OK thanks, just wanted to make sure that we didn't both expect each > other to handle it :-) Yes, confirm that; I think this is already fixed in scsi-misc-2.6. Could you pull from master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git and verify with your device? Thanks, James - 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
Problem with USB Keyboard installing RHEL51
I want to install RedHat Enterprise 5.1 on IBM Server x3650 (Model 797921U). This server only has USB ports (It doesn´t have PS/2 ports) I boot DVD without problems and USB keyboard works fine. (I use it in BIOS, and in RedHat boot command line) When I begin with the installation process (after anaconda) the USB keyboard doesn´t work anymore. How can I solve this problem ? Can I use kernel parameters at boot time ? Which one ? Thanks in advance. Leandro. Yahoo! Encuentros. Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 22:24 +0200, James Bottomley <[EMAIL PROTECTED]> wrote: > On Tue, 2008-01-29 at 21:06 +0100, Jens Axboe wrote: >>> I will ... but it will cause an explosion in the bidirectional tree >>> again. I think the bidi updates also fix this. However, give me time >>> to rebase and verify. >> OK thanks, just wanted to make sure that we didn't both expect each >> other to handle it :-) > > Yes, confirm that; I think this is already fixed in scsi-misc-2.6. > Could you pull from > > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git > > and verify with your device? > > Thanks, > > James > > I still don't see these changes, I wanted to check, make sure... Are there mirrors on the way to here? James I would like to remind you that one small piece is missing from the bidi tree, as I saw it from here, it's the few patches from scsi-pending. Mainly arm will break which is a grate loss. I'm going home now, I'll review all the patches tomorrow and compare to what I have, to make sure nothing was forgotten. What a waste of a day I pulled from Linus this morning apparently minutes before the merge, and chased a none existent bug in my tree. Sigh Bye Boaz - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 22:13 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Tue, Jan 29 2008, Boaz Harrosh wrote: >>> Ok this is not in Linus tree is it? Hence I did not have that failure. >>> >>> Boaz >>> >>> >> actually James bidi tree has a fix for this in the scsi_data_buffer patch. >> >> what you sent is not enough there are other places. look at this patch I >> sent to the list. >> >> http://www.spinics.net/lists/linux-scsi/msg21938.html > > Hard to compare, since its on different bases. Yes in this patchset I have taken your sg branch at the time, and rebased it ontop of scsi_data_buffer patch. Because I felt that it is more natural for this patch to come after the scsi total cleanup that is scsi_data_buffer. Then the extraction to sg_table is simple and trivial. What I meant to point out with this patch is that all the exact same places that are touched there should be fixed when moving to sg_table. Look at it. It is a revised version of your patch. > >> Could we take the 2 SG patches and submit them through the scsi >> bidi tree? It is much more natural to have them in one tree as one >> patchset then try coordinate with git-merge. Actually if you look at it, >> the biggest change is to SCSI. So I think it is more natural this way > > What 2 sg patches do you mean? > I mean the patches that where in sg branch of the linux-block tree, But I see that it is now to late, and that they are in Linus already James the most simple is to submit the scsi_data_buff patch that fixes all these places. If not do you want that I send in fixes? Boaz - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote: > >> > > Ok this is not in Linus tree is it? Hence I did not have that failure. > > > > Boaz > > > > > > actually James bidi tree has a fix for this in the scsi_data_buffer patch. > > what you sent is not enough there are other places. look at this patch I > sent to the list. > > http://www.spinics.net/lists/linux-scsi/msg21938.html Hard to compare, since its on different bases. > Could we take the 2 SG patches and submit them through the scsi > bidi tree? It is much more natural to have them in one tree as one > patchset then try coordinate with git-merge. Actually if you look at it, > the biggest change is to SCSI. So I think it is more natural this way What 2 sg patches do you mean? -- Jens Axboe - 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
Re: [BUG] 2.6.24-git usb reset problems
>> > Ok this is not in Linus tree is it? Hence I did not have that failure. > > Boaz > > actually James bidi tree has a fix for this in the scsi_data_buffer patch. what you sent is not enough there are other places. look at this patch I sent to the list. http://www.spinics.net/lists/linux-scsi/msg21938.html Could we take the 2 SG patches and submit them through the scsi bidi tree? It is much more natural to have them in one tree as one patchset then try coordinate with git-merge. Actually if you look at it, the biggest change is to SCSI. So I think it is more natural this way Boaz - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 29 2008, Jens Axboe wrote:
>> On Tue, Jan 29 2008, James Bottomley wrote:
>>> On Tue, 2008-01-29 at 11:10 -0800, 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:
> 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.
>>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
>>> code ... that was also an update in 2.6.24
>> yeah, already found the bug - it's assuming ->request_buffer holds the
>> sglist, oops. Preparing a fix.
>
> ok here goes, this saves and restores the sg table correctly. it also
> fixes the usb bug for me.
>
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 547e85a..12770ef 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
> scsi_eh_save *ses,
> ses->use_sg = scmd->use_sg;
> ses->resid = scmd->resid;
> ses->result = scmd->result;
> + memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
>
> if (sense_bytes) {
> scmd->request_bufflen = min_t(unsigned,
> SCSI_SENSE_BUFFERSIZE, sense_bytes);
> sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> scmd->request_bufflen);
> - scmd->request_buffer = &ses->sense_sgl;
> + scmd->sg_table.sgl = &ses->sense_sgl;
> + scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
> scmd->sc_data_direction = DMA_FROM_DEVICE;
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, James Bottomley wrote: > On Tue, 2008-01-29 at 11:10 -0800, 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: > > > > > 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. > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense > code ... that was also an update in 2.6.24 yeah, already found the bug - it's assuming ->request_buffer holds the sglist, oops. Preparing a fix. -- Jens Axboe - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, 2008-01-29 at 11:10 -0800, 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: > > > 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. OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense code ... that was also an update in 2.6.24 James - 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
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 20:39 +0200, Jens Axboe <[EMAIL PROTECTED]> 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. > > usb-storage: Command MODE_SENSE (6 bytes) > usb-storage: 1a 00 3f 00 c0 00 > usb-storage: Bulk Command S 0x43425355 T 0x4 L 192 F 128 Trg 0 LUN 0 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 192 bytes, 1 entries > usb-storage: Status code -121; transferred 4/192 > usb-storage: -- short read transfer > usb-storage: Bulk data transfer result 0x1 > usb-storage: Attempting to get CSW... I get something similar but better: usb-storage: Command MODE_SENSE (6 bytes) usb-storage: 1a 00 3f 00 c0 00 usb-storage: Bulk Command S 0x43425355 T 0x6 L 192 F 128 Trg 0 LUN 0 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 192 bytes, 1 entries usb-storage: Status code -121; transferred 36/192 usb-storage: -- short read transfer usb-storage: Bulk data transfer result 0x1 usb-storage: Attempting to get CSW... So I get 36 bytes, then code goes on into one reset, and every thing is then fine. Could you put us out of our mesery and revert that patch: [SCSI] usb: transport - convert to accessors and !use_sg code path removal (6d416e6173394defda5933e419e805b696681b7e) to make sure this is it. I hate to do this to you, but I cannot reproduce the failure down here. If it works please send a log with the debugs on perhaps we can compare. You will need to configure out the CONFIG_USB_STORAG_* they will not compile you should have only have CONFIG_USB_STORAGE & CONFIG_USB_STORAGE_DEBUG. it should support your HW. Thanks Jens Boaz - 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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
>> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>>
>>> --- a/drivers/usb/storage/transport.c
>>> +++ b/drivers/usb/storage/transport.c
>>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
>>> us_data *us, unsigned int pipe,
>>> * Common used function. Transfer a complete command
>>> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>>> */
>>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> - struct scsi_cmnd* srb)
>>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
>>> + struct scsi_cmnd* srb, unsigned length)
>>> {
>>> unsigned int partial;
>>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>>> - scsi_sg_count(srb), scsi_bufflen(srb),
>>> + scsi_sg_count(srb), length,
>>> &partial);
>>>
>>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>> return result;
>>> }
>>>
>>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> + struct scsi_cmnd* srb)
>>> +{
>>> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
>>> +}
>>> +
>> I don't like this patch very much. Why add another layer of
>> indirection when the two subroutines do hardly any work? Leave
>> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
>> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
>> and scsi_set_resid().
>>
>> BTW, the standard coding style calls for a blank line after the list of
>> local variables at the start of a function or block.
>
> There's another bug in the transport.c conversion in that the residuals
> are updated with bogus data in several error cases, since
> usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
> is actually sent.
>
> I'm not sure if this is is the solution to the problem at hand, but it
> definitely fixes another bug in the code.
>
> James
>
> diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
> index d9f4912..bab0858 100644
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
> *us, unsigned int pipe,
> int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> struct scsi_cmnd* srb)
> {
> - unsigned int partial;
> + unsigned int partial = scsi_get_resid(srb);
> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> scsi_sg_count(srb), scsi_bufflen(srb),
> &partial);
>
>
> -
But then this is weird because it is not what usb_stor_bulk_transfer_sg() is
doing
which was the one called before.
I have such a device and I get one reset but then every thing works nice.
This is with debug on. I'll try to make it fail.
Boaz
-
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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote:
> On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
> >> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> >>
> >>> --- a/drivers/usb/storage/transport.c
> >>> +++ b/drivers/usb/storage/transport.c
> >>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
> >>> us_data *us, unsigned int pipe,
> >>> * Common used function. Transfer a complete command
> >>> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> >>> */
> >>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> >>> - struct scsi_cmnd* srb)
> >>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> >>> + struct scsi_cmnd* srb, unsigned length)
> >>> {
> >>> unsigned int partial;
> >>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> >>> - scsi_sg_count(srb), scsi_bufflen(srb),
> >>> + scsi_sg_count(srb), length,
> >>> &partial);
> >>>
> >>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> >>> return result;
> >>> }
> >>>
> >>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> >>> + struct scsi_cmnd* srb)
> >>> +{
> >>> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> >>> +}
> >>> +
> >> I don't like this patch very much. Why add another layer of
> >> indirection when the two subroutines do hardly any work? Leave
> >> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
> >> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
> >> and scsi_set_resid().
> >>
> >> BTW, the standard coding style calls for a blank line after the list of
> >> local variables at the start of a function or block.
> >
> > There's another bug in the transport.c conversion in that the residuals
> > are updated with bogus data in several error cases, since
> > usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
> > is actually sent.
> >
> > I'm not sure if this is is the solution to the problem at hand, but it
> > definitely fixes another bug in the code.
> >
> > James
> >
> > diff --git a/drivers/usb/storage/transport.c
> > b/drivers/usb/storage/transport.c
> > index d9f4912..bab0858 100644
> > --- a/drivers/usb/storage/transport.c
> > +++ b/drivers/usb/storage/transport.c
> > @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
> > *us, unsigned int pipe,
> > int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > struct scsi_cmnd* srb)
> > {
> > - unsigned int partial;
> > + unsigned int partial = scsi_get_resid(srb);
> > int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> > scsi_sg_count(srb), scsi_bufflen(srb),
> > &partial);
> >
> >
> > -
> But then this is weird because it is not what usb_stor_bulk_transfer_sg() is
> doing
> which was the one called before.
Um, yes it was. The original code did this
sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
Which was at liberty not to touch resid, which it chose not to do in the
error legs.
Your new code does
int partial; <- stack uninitialised
sb_stor_bulk_transfer_sglist(..., &partial, ...);
scsi_set_resid(srb, scsi_bufflen(srb) - partial);
If the function doesn't touch partial, as it doesn't in the error legs,
resid now gets set with rubbish.
Actually, my code is still wrong .. we have to set it to
scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
left untouched.
> I have such a device and I get one reset but then every thing works nice.
> This is with debug on. I'll try to make it fail.
James
-
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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 21:17 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote:
>>> Your new code does
>>>
>>> int partial; <- stack uninitialised
>>> sb_stor_bulk_transfer_sglist(..., &partial, ...);
>>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>>
>>> If the function doesn't touch partial, as it doesn't in the error legs,
>>> resid now gets set with rubbish.
>>>
>>> Actually, my code is still wrong .. we have to set it to
>>> scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
>>> left untouched.
>>>
I have such a device and I get one reset but then every thing works nice.
This is with debug on. I'll try to make it fail.
>>> James
>>>
>>>
>> Sorry I still don't see it.
>>
>> original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
>>
>> but sb_stor_bulk_transfer_sg does the:
>> int partial; <- stack uninitialised
>> sb_stor_bulk_transfer_sglist(..., &partial, ...);
>>
>> and then unconditionally sets *residual = length_left;
>> I do not see an "error legs" case in sb_stor_bulk_transfer_sg().
>
> This is really programming 101. This:
>
> static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned
> int pipe,
> struct scatterlist *sg, int num_sg, unsigned int length,
> unsigned int *act_len)
> {
> int result;
>
> /* don't submit s-g requests during abort/disconnect processing */
> if (us->flags & ABORTING_OR_DISCONNECTING)
> return USB_STOR_XFER_ERROR;
>
> The return USB_STOR_XFER_ERROR; is called an error leg. It returns
> without updating *act_len thus leaving &partial uninitialised.
>
> James
>
Yes you are right this is a bug, but it is a bug that was there before.
perhaps the stack is just different now then what it used to be.
Jens could you please try that:
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..b18a5e6 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
struct scsi_cmnd* srb)
{
- unsigned int partial;
+ unsigned int partial = 0;
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
scsi_sg_count(srb), scsi_bufflen(srb),
&partial);
-
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
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Jens Axboe wrote:
> On Tue, Jan 29 2008, James Bottomley wrote:
> > On Tue, 2008-01-29 at 11:10 -0800, 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:
> > >
> > > > 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.
> >
> > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > code ... that was also an update in 2.6.24
>
> yeah, already found the bug - it's assuming ->request_buffer holds the
> sglist, oops. Preparing a fix.
ok here goes, this saves and restores the sg table correctly. it also
fixes the usb bug for me.
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 547e85a..12770ef 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
scsi_eh_save *ses,
ses->use_sg = scmd->use_sg;
ses->resid = scmd->resid;
ses->result = scmd->result;
+ memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
if (sense_bytes) {
scmd->request_bufflen = min_t(unsigned,
SCSI_SENSE_BUFFERSIZE, sense_bytes);
sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
scmd->request_bufflen);
- scm
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote:
> On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 29 2008, Jens Axboe wrote:
> >> On Tue, Jan 29 2008, James Bottomley wrote:
> >>> On Tue, 2008-01-29 at 11:10 -0800, 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:
>
> > 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.
> >>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> >>> code ... that was also an update in 2.6.24
> >> yeah, already found the bug - it's assuming ->request_buffer holds the
> >> sglist, oops. Preparing a fix.
> >
> > ok here goes, this saves and restores the sg table correctly. it also
> > fixes the usb bug for me.
> >
> > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > index 547e85a..12770ef 100644
> > --- a/drivers/scsi/scsi_error.c
> > +++ b/drivers/scsi/scsi_error.c
> > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
> > scsi_eh_save *ses,
> > ses->use_sg = scmd->use_sg;
> > ses->resid = scmd->resid;
> > ses->result = scmd->result;
> > + memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
> >
> > if (sense_bytes) {
> > scmd->request_bufflen = min_t(unsigned,
> >SCSI_SENSE_BUFFERSIZE, sense_bytes);
> > sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> >scmd->request_bufflen);
> > -
Re: [BUG] 2.6.24-git usb reset problems
On Tue, 2008-01-29 at 21:03 +0100, Jens Axboe wrote:
> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > >> On Tue, Jan 29 2008, James Bottomley wrote:
> > >>> On Tue, 2008-01-29 at 11:10 -0800, 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:
> >
> > > 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.
> > >>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > >>> code ... that was also an update in 2.6.24
> > >> yeah, already found the bug - it's assuming ->request_buffer holds the
> > >> sglist, oops. Preparing a fix.
> > >
> > > ok here goes, this saves and restores the sg table correctly. it also
> > > fixes the usb bug for me.
> > >
> > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > > index 547e85a..12770ef 100644
> > > --- a/drivers/scsi/scsi_error.c
> > > +++ b/drivers/scsi/scsi_error.c
> > > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd,
> > > struct scsi_eh_save *ses,
> > > ses->use_sg = scmd->use_sg;
> > > ses->resid = scmd->resid;
> > > ses->result = scmd->result;
> > > + memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
> > >
> > > if (sense_bytes) {
> > >
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, James Bottomley wrote: > On Tue, 2008-01-29 at 21:03 +0100, Jens Axboe wrote: > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > >> On Tue, Jan 29 2008, James Bottomley wrote: > > > >>> On Tue, 2008-01-29 at 11:10 -0800, 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: > > > > > > > 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. > > > >>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense > > > >>> code ... that was also an update in 2.6.24 > > > >> yeah, already found the bug - it's assuming ->request_buffer holds the > > > >> sglist, oops. Preparing a fix. > > > > > > > > ok here goes, this saves and restores the sg table correctly. it also > > > > fixes the usb bug for me. > > > > > > > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > > > > index 547e85a..12770ef 100644 > > > > --- a/drivers/scsi/scsi_error.c > > > > +++ b/drivers/scsi/scsi_error.c > > > > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct s
Re: Problem with USB Keyboard installing RHEL51
On Tue, Jan 29, 2008 at 01:03:42PM -0800, Leandro LATTANZIO wrote: > > I want to install RedHat Enterprise 5.1 on IBM Server x3650 (Model 797921U). > This server only has USB ports (It doesn?t have PS/2 ports) > > I boot DVD without problems and USB keyboard works fine. > (I use it in BIOS, and in RedHat boot command line) > > When I begin with the installation process (after anaconda) > the USB keyboard doesn?t work anymore. > > How can I solve this problem ? As this is a Red Hat specific question, I think the best audience for this is on a Red Hat specific mailing list. Also, with RHEL, you do get free installation support, you might just try contacting Red Hat directly :) good luck, greg k-h - 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
