Re: usb-storage and Motorola Z6

Re: usb-storage and Motorola Z6

[Alan Stern]

Can any SCSI experts explain what's going wrong here?

Alan Stern


---------- Forwarded message ----------
Date: Tue, 28 Aug 2007 22:13:16 +0200
From: Andreas Koenecke <akoenecke@akoenecke.de>
To: USB users list <linux-usb-users@lists.sourceforge.net>
Cc: akoenecke@akoencke.de
Subject: Re: [Linux-usb-users] usb-storage and Motorola Z6

* Dienstag, 28. August 2007 um 15:13 (-0400) schrieb Alan Stern:
> 
> > > Aug 28 09:54:33 kocom kernel: usb-storage: device scan complete
> > >
> > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:0: Direct-Access     Motorola MSnc.
> > >  PQ: 1 ANSI: 0 CCS
> > >
> > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:1: Direct-Access     Motorola MSnc.
> > >  PQ: 1 ANSI: 0 CCS
> > >
> > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:0: Attached scsi generic sg2 type 0
> > >
> > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:1: Attached scsi generic sg3 type 0
> > >
> > > Aug 28 10:02:47 kocom kernel: usb 3-1: USB disconnect, address 5
> > > ---------------------------------------------------------------------------------
> 
> Everything looks correct except that sd_mod isn't loaded.

sd_mod is build fix into the kernel because of the real SCSI card. All other
usb-storage devices (flash sticks, card reader and USB HDDs) are working
without problems.

I connected the phone to a complete different computer (my laptop: vendor
kernel, more modularized) and sd_mod is loading when I plug in, but
nevertheless no block-devices. The same behavior as on my desktop computer...
 

Andreas


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Re: usb-storage and Motorola Z6

[Matthew Wilcox]

On Tue, Aug 28, 2007 at 04:45:59PM -0400, Alan Stern wrote:
> Can any SCSI experts explain what's going wrong here?

It's the PQ 1 -- the device is telling us that it's not actually there
right now.

> > > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:0: Direct-Access     Motorola MSnc.
> > > >  PQ: 1 ANSI: 0 CCS
> > > >
> > > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:1: Direct-Access     Motorola MSnc.
> > > >  PQ: 1 ANSI: 0 CCS
> > > >
> > > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:0: Attached scsi generic sg2 type 0
> > > >
> > > > Aug 28 09:54:33 kocom kernel: scsi 4:0:0:1: Attached scsi generic sg3 type 0
> > > >
> > > > Aug 28 10:02:47 kocom kernel: usb 3-1: USB disconnect, address 5
> > > > ---------------------------------------------------------------------------------
> > 
> > Everything looks correct except that sd_mod isn't loaded.
> 
> sd_mod is build fix into the kernel because of the real SCSI card. All other
> usb-storage devices (flash sticks, card reader and USB HDDs) are working
> without problems.
> 
> I connected the phone to a complete different computer (my laptop: vendor
> kernel, more modularized) and sd_mod is loading when I plug in, but
> nevertheless no block-devices. The same behavior as on my desktop computer...
>  
> 
> Andreas
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Re: usb-storage and Motorola Z6

[Andreas Koenecke]

* Dienstag, 28. August 2007 um 14:48 (-0600) schrieb Matthew Wilcox:
> 
> On Tue, Aug 28, 2007 at 04:45:59PM -0400, Alan Stern wrote:
> > Can any SCSI experts explain what's going wrong here?
> 
> It's the PQ 1 -- the device is telling us that it's not actually there
> right now.

Is anything I can try?

Andreas


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Re: [Linux-usb-users] usb-storage and Motorola Z6

[Alan Stern]

On Tue, 28 Aug 2007, Andreas Koenecke wrote:

> * Dienstag, 28. August 2007 um 14:48 (-0600) schrieb Matthew Wilcox:
> > 
> > On Tue, Aug 28, 2007 at 04:45:59PM -0400, Alan Stern wrote:
> > > Can any SCSI experts explain what's going wrong here?
> > 
> > It's the PQ 1 -- the device is telling us that it's not actually there
> > right now.
> 
> Is anything I can try?

You can edit the source code of the SCSI core to make it ignore the PQ 
value.  In the file drivers/scsi/scsi_sysfs.c, find the 
scsi_bus_match() routine and change the last line from:

	return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;

to

	return 1;

Alan Stern

Re: usb-storage and Motorola Z6

[Andreas Koenecke]

* Mittwoch, 29. August 2007 um 10:07 (-0400) schrieb Alan Stern:
> 
> You can edit the source code of the SCSI core to make it ignore the PQ 
> value.  In the file drivers/scsi/scsi_sysfs.c, find the 
> scsi_bus_match() routine and change the last line from:
> 
> 	return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
> 
> to
> 
> 	return 1;

OK, I have done it. But there ist still no success.
When I connect the phone the messages are:
--------------------------------------------------------------------------------------------
Aug 31 20:14:53 kocom kernel: usb 3-1: new high speed USB device using ehci_hcd and address 2
Aug 31 20:14:53 kocom kernel: usb 3-1: configuration #1 chosen from 1 choice
Aug 31 20:14:53 kocom kernel: usbcore: registered new interface driver libusual
Aug 31 20:14:53 kocom kernel: Initializing USB Mass Storage driver...
Aug 31 20:14:53 kocom kernel: scsi3 : SCSI emulation for USB Mass Storage devices
Aug 31 20:14:53 kocom kernel: usb-storage: device found at 2
Aug 31 20:14:53 kocom kernel: usb-storage: waiting for device to settle before scanning
Aug 31 20:14:53 kocom kernel: usbcore: registered new interface driver usb-storage
Aug 31 20:14:53 kocom kernel: USB Mass Storage support registered.
Aug 31 20:14:58 kocom kernel: usb-storage: device scan complete
Aug 31 20:14:58 kocom kernel: scsi 3:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
Aug 31 20:14:58 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:14:58 kocom kernel: scsi 3:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
Aug 31 20:14:58 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:14:58 kocom kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
Aug 31 20:14:58 kocom kernel: sd 3:0:0:0: Attached scsi generic sg2 type 0
Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:14:59 kocom kernel: sd 3:0:0:1: [sdc] Attached SCSI removable disk
Aug 31 20:14:59 kocom kernel: sd 3:0:0:1: Attached scsi generic sg3 type 0
Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:01 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:02 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:02 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:02 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:02 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:03 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:03 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:03 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:07 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:07 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:08 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:08 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:08 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:08 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:09 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:11 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:13 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:15:13 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 31 20:17:06 kocom kernel: usb 3-1: USB disconnect, address 2
------------------------------------------------------------------------------------------------------------

/proc/partition and 'fdisk' show no sdb or sdc.
You can download the messages with debug-Output from
<http://www.akoenecke.de/moto/usb_debug.txt>

Andreas


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Re: [Linux-usb-users] usb-storage and Motorola Z6

[Alan Stern]

On Fri, 31 Aug 2007, Andreas Koenecke wrote:

> * Mittwoch, 29. August 2007 um 10:07 (-0400) schrieb Alan Stern:
> > 
> > You can edit the source code of the SCSI core to make it ignore the PQ 
> > value.  In the file drivers/scsi/scsi_sysfs.c, find the 
> > scsi_bus_match() routine and change the last line from:
> > 
> > 	return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
> > 
> > to
> > 
> > 	return 1;
> 
> OK, I have done it. But there ist still no success.
> When I connect the phone the messages are:
> --------------------------------------------------------------------------------------------
> Aug 31 20:14:53 kocom kernel: usb 3-1: new high speed USB device using ehci_hcd and address 2
> Aug 31 20:14:53 kocom kernel: usb 3-1: configuration #1 chosen from 1 choice
> Aug 31 20:14:53 kocom kernel: usbcore: registered new interface driver libusual
> Aug 31 20:14:53 kocom kernel: Initializing USB Mass Storage driver...
> Aug 31 20:14:53 kocom kernel: scsi3 : SCSI emulation for USB Mass Storage devices
> Aug 31 20:14:53 kocom kernel: usb-storage: device found at 2
> Aug 31 20:14:53 kocom kernel: usb-storage: waiting for device to settle before scanning
> Aug 31 20:14:53 kocom kernel: usbcore: registered new interface driver usb-storage
> Aug 31 20:14:53 kocom kernel: USB Mass Storage support registered.
> Aug 31 20:14:58 kocom kernel: usb-storage: device scan complete
> Aug 31 20:14:58 kocom kernel: scsi 3:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> Aug 31 20:14:58 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
> Aug 31 20:14:58 kocom kernel: scsi 3:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> Aug 31 20:14:58 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
> Aug 31 20:14:58 kocom kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
> Aug 31 20:14:58 kocom kernel: sd 3:0:0:0: Attached scsi generic sg2 type 0
> Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
> Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
> Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
> Aug 31 20:14:59 kocom kernel: sd 3:0:0:1: [sdc] Attached SCSI removable disk
> Aug 31 20:14:59 kocom kernel: sd 3:0:0:1: Attached scsi generic sg3 type 0

That's pretty much okay.  Apart from the resets, it indicates that the 
computer did detect and install the two logical drives, sdb and sdc.

> Aug 31 20:14:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
> Aug 31 20:15:01 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
...

All those reset messages are caused by a bug in the device.  Every 
command sent to the device is labelled with a "Tag" value; it shows up 
in the debugging log on each "Bulk Command" line as the number 
following the T.  For example:

	Bulk Command S 0x43425355 T 0x4 L 18 F 128 Trg 0 LUN 0 CL 6

Here the Tag is 0x4.  In its status response, the device must include a
matching Tag value to indicate which command the status is for.  If you
look at the debugging log, you'll see the status line for this
particular command was:

	Bulk Status S 0x53425355 T 0x3 R 0 Stat 0x0

The Tag is 0x3, which doesn't match!  The device made this mistake 15
times in 410 commands, apparently at random, and each time the computer
issued a reset to try and fix the problem.  That's a pretty serious 
bug in the Z6.

If you want to work around this bug, you can edit the file 
drivers/usb/storage/transport.c.  In the usb_stor_Bulk_transport() 
routine, edit this line:

        if (bcs->Tag != us->tag || bcs->Status > US_BULK_STAT_PHASE) {

and change it to:

        if (bcs->Status > US_BULK_STAT_PHASE) {

> /proc/partition and 'fdisk' show no sdb or sdc.

That's a separate matter.  The log shows that the computer sent 
numerous TEST UNIT READY commands to the device, and every time the 
device answered with a code that means "Not ready, medium not present".  
In other words, it's saying that it needs to have a memory card or 
something like that inserted.

Alan Stern

Re: usb-storage and Motorola Z6

[Andreas Koenecke]

* Freitag, 31. August 2007 um 16:56 (-0400) schrieb Alan Stern:
> 
> All those reset messages are caused by a bug in the device.  Every 
> command sent to the device is labelled with a "Tag" value; it shows up 
> in the debugging log on each "Bulk Command" line as the number 
> following the T.  For example:
> 
> 	Bulk Command S 0x43425355 T 0x4 L 18 F 128 Trg 0 LUN 0 CL 6
> 
> Here the Tag is 0x4.  In its status response, the device must include a
> matching Tag value to indicate which command the status is for.  If you
> look at the debugging log, you'll see the status line for this
> particular command was:
> 
> 	Bulk Status S 0x53425355 T 0x3 R 0 Stat 0x0
> 
> The Tag is 0x3, which doesn't match!  The device made this mistake 15
> times in 410 commands, apparently at random, and each time the computer
> issued a reset to try and fix the problem.  That's a pretty serious 
> bug in the Z6.
> 
> If you want to work around this bug, you can edit the file 
> drivers/usb/storage/transport.c.  In the usb_stor_Bulk_transport() 
> routine, edit this line:
> 
>         if (bcs->Tag != us->tag || bcs->Status > US_BULK_STAT_PHASE) {
> 
> and change it to:
> 
>         if (bcs->Status > US_BULK_STAT_PHASE) {

I' done this, too.
The non-debug-messages are now:
----------------------------------------------------------------------------
Sep  1 13:09:17 kocom kernel: usb 3-1: new high speed USB device using ehci_hcd and address 12
Sep  1 13:09:17 kocom kernel: usb 3-1: configuration #1 chosen from 1 choice
Sep  1 13:09:17 kocom kernel: Initializing USB Mass Storage driver...
Sep  1 13:09:17 kocom kernel: scsi7 : SCSI emulation for USB Mass Storage devices
Sep  1 13:09:17 kocom kernel: usb-storage: device found at 12
Sep  1 13:09:17 kocom kernel: usb-storage: waiting for device to settle before scanning
Sep  1 13:09:17 kocom kernel: usbcore: registered new interface driver usb-storage
Sep  1 13:09:17 kocom kernel: USB Mass Storage support registered.
Sep  1 13:09:22 kocom kernel: usb-storage: device scan complete
Sep  1 13:09:22 kocom kernel: scsi 7:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
Sep  1 13:09:22 kocom kernel: scsi 7:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk
Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0
Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: [sdc] Attached SCSI removable disk
Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: Attached scsi generic sg3 type 0
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Sep  1 13:09:28 kocom kernel:  sdb:
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] 128673 512-byte hardware sectors (66 MB)
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Write Protect is off
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Mode Sense: 03 00 00 00
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Assuming drive cache: write through
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] 128673 512-byte hardware sectors (66 MB)
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Write Protect is off
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Mode Sense: 03 00 00 00
Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Assuming drive cache: write through
Sep  1 13:09:28 kocom kernel:  sdc:
Sep  1 13:09:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
Sep  1 13:10:14 kocom kernel: usb 3-1: device descriptor read/64, error -110
Sep  1 13:10:29 kocom kernel: usb 3-1: device descriptor read/64, error -110
Sep  1 13:10:29 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
Sep  1 13:10:44 kocom kernel: usb 3-1: device descriptor read/64, error -110
Sep  1 13:11:00 kocom kernel: usb 3-1: device descriptor read/64, error -110
Sep  1 13:11:00 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
Sep  1 13:11:05 kocom kernel: usb 3-1: device descriptor read/8, error -110
------------------------------------------------------------------------------------------------

sdb and sdc appear in /proc/partitions, but trying to access with 'fdisk -l` or
'mount' freezes the phone.

I uploaded the debug-log to:
<http://www.akoenecke.de/moto/usb_debug2.txt>

The debug-log included 2 spontaneous reboots and 1 freeze (in this order) of
the phone without unplugging.

Andreas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Re: [Linux-usb-users] usb-storage and Motorola Z6

[Alan Stern]

On Sat, 1 Sep 2007, Andreas Koenecke wrote:

> I' done this, too.
> The non-debug-messages are now:
> ----------------------------------------------------------------------------
> Sep  1 13:09:17 kocom kernel: usb 3-1: new high speed USB device using ehci_hcd and address 12
> Sep  1 13:09:17 kocom kernel: usb 3-1: configuration #1 chosen from 1 choice
> Sep  1 13:09:17 kocom kernel: Initializing USB Mass Storage driver...
> Sep  1 13:09:17 kocom kernel: scsi7 : SCSI emulation for USB Mass Storage devices
> Sep  1 13:09:17 kocom kernel: usb-storage: device found at 12
> Sep  1 13:09:17 kocom kernel: usb-storage: waiting for device to settle before scanning
> Sep  1 13:09:17 kocom kernel: usbcore: registered new interface driver usb-storage
> Sep  1 13:09:17 kocom kernel: USB Mass Storage support registered.
> Sep  1 13:09:22 kocom kernel: usb-storage: device scan complete
> Sep  1 13:09:22 kocom kernel: scsi 7:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> Sep  1 13:09:22 kocom kernel: scsi 7:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: [sdc] Attached SCSI removable disk
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: Attached scsi generic sg3 type 0
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
> Sep  1 13:09:28 kocom kernel:  sdb:
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] 128673 512-byte hardware sectors (66 MB)
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Write Protect is off
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Mode Sense: 03 00 00 00
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Assuming drive cache: write through
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] 128673 512-byte hardware sectors (66 MB)
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Write Protect is off
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Mode Sense: 03 00 00 00
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Assuming drive cache: write through
> Sep  1 13:09:28 kocom kernel:  sdc:
> Sep  1 13:09:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
> Sep  1 13:10:14 kocom kernel: usb 3-1: device descriptor read/64, error -110
> Sep  1 13:10:29 kocom kernel: usb 3-1: device descriptor read/64, error -110
> Sep  1 13:10:29 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
> Sep  1 13:10:44 kocom kernel: usb 3-1: device descriptor read/64, error -110
> Sep  1 13:11:00 kocom kernel: usb 3-1: device descriptor read/64, error -110
> Sep  1 13:11:00 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
> Sep  1 13:11:05 kocom kernel: usb 3-1: device descriptor read/8, error -110
> ------------------------------------------------------------------------------------------------
> 
> sdb and sdc appear in /proc/partitions, but trying to access with 'fdisk -l` or
> 'mount' freezes the phone.
> 
> I uploaded the debug-log to:
> <http://www.akoenecke.de/moto/usb_debug2.txt>
> 
> The debug-log included 2 spontaneous reboots and 1 freeze (in this order) of
> the phone without unplugging.

The resets and disconnects occurred because of yet another bug in the 
phone.  It reports that sdc has 128673 sectors, but in fact it probably 
has only 128672.  The error occurred when the computer tried to read 
the (non-existent) last sector.  The phone failed to follow the proper 
protocol for reporting an error, so the computer reset it.

It's not surprising; other devicees from Motorola have the same bug.  
The patch below ought to help.  However considering the number of other 
bugs and problems in this device, it's not clear how far you should try 
to push it...

Alan Stern


Index: usb-2.6/drivers/usb/storage/unusual_devs.h
===================================================================
--- usb-2.6.orig/drivers/usb/storage/unusual_devs.h
+++ usb-2.6/drivers/usb/storage/unusual_devs.h
@@ -1481,6 +1481,13 @@ UNUSUAL_DEV(  0x22b8, 0x4810, 0x0001, 0x
 		US_SC_DEVICE, US_PR_DEVICE, NULL,
 		US_FL_FIX_CAPACITY),
 
+/* Reported by Andreas Koenecke <akoenecke@akoenecke.de> */
+UNUSUAL_DEV(  0x22b8, 0x6426, 0x0101, 0x0101,
+		"Motorola",
+		"MSnc Z6",
+		US_SC_DEVICE, US_PR_DEVICE, NULL,
+		US_FL_FIX_CAPACITY),
+
 /* Reported by Radovan Garabik <garabik@kassiopeia.juls.savba.sk> */
 UNUSUAL_DEV(  0x2735, 0x100b, 0x0000, 0x9999,
 		"MPIO",

Re: usb-storage and Motorola Z6

[Peter Rasmussen]

I'm sorry if this is a little late, but I had once had access to a Z6 
and believe I had it successfully connected to my Linux host, and was 
therefore puzzled by this message exchange.

I have now borrowed the device again for the weekend to check it out a 
little more.

Using Alan's patch below, otherwise my kernel is a standard 2.6.23-rc5 
(CONFIG_USB_STORAGE_DEBUG=y ) I got the following result after reboot 
and connecting the Z6.:

ohci_hcd 0000:00:02.0: auto-wakeup root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00010101 CSC 
PPS CCS
hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00100103 
PRSC PPS PES CCS
usb 1-1: new full speed USB device using ohci_hcd and address 2
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00100103 
PRSC PPS PES CCS
usb 1-1: default language 0x0409
usb 1-1: new device strings: Mfr=3, Product=2, SerialNumber=4
usb 1-1: Product: MS
usb 1-1: Manufacturer: Motorola Inc.
usb 1-1: SerialNumber: 9013555524BA0C2005
usb 1-1: uevent
usb 1-1: usb_probe_device
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
usb 1-1:1.0: uevent
usb 1-1:1.0: uevent
usb-storage 1-1:1.0: usb_probe_interface
usb-storage 1-1:1.0: usb_probe_interface - got id
usb-storage: USB Mass Storage device detected
usb-storage: -- associate_dev
usb-storage: Vendor: 0x22b8, Product: 0x6426, Revision: 0x0101
usb-storage: Interface Subclass: 0x06, Protocol: 0x50
usb-storage: Transport: Bulk
usb-storage: Protocol: Transparent SCSI
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: *** thread sleeping.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
drivers/usb/core/inode.c: creating file '002'
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00 len=1
usb-storage: GetMaxLUN command result is 1, data is 1
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage:  12 00 00 00 24 00
usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6
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 36 bytes, 1 entries
usb-storage: Status code 0; transferred 36/36
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
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 0x1 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
scsi 0:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 
ANSI: 0 CCS
scsi 0:0:0:0: Attached scsi generic sg0 type 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage:  12 00 00 00 24 00
usb-storage: Bulk Command S 0x43425355 T 0x2 L 36 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 36 bytes, 1 entries
usb-storage: Status code 0; transferred 36/36
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
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 0x2 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
scsi 0:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 
ANSI: 0 CCS
scsi 0:0:0:1: Attached scsi generic sg1 type 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad LUN (0:2)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (1:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (2:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (3:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (4:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (5:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (6:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (7:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: device scan complete

What I can't understand, however, is that as this mobile phone 
supposedly runs Linux. I can't see how Motorola could break it so badly 
that the USB connection now doesn't work with a PC running Linux?

And you say that this seems to be a more widespread problem with 
Motorola devices? Do you remember which ones, and do they run Linux as well?

The following is from connecting a Z3 that supposedly isn't based on 
Linux, but works all right (and this may have been the one I thought was 
the Z6 that I claimed worked):

ohci_hcd 0000:00:02.0: auto-wakeup root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00010101 CSC 
PPS CCS
hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00100103 
PRSC PPS PES CCS
usb 1-1: new full speed USB device using ohci_hcd and address 5
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00100103 
PRSC PPS PES CCS
usb 1-1: ep0 maxpacket = 8
usb 1-1: default language 0x0409
usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: Motorola Phone (Z3)
usb 1-1: Manufacturer: Motorola Inc.
usb 1-1: SerialNumber: 00440102299883
usb 1-1: uevent
usb 1-1: usb_probe_device
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
usb 1-1:1.0: uevent
usb 1-1:1.0: uevent
usb-storage 1-1:1.0: usb_probe_interface
usb-storage 1-1:1.0: usb_probe_interface - got id
usb-storage: USB Mass Storage device detected
usb-storage: -- associate_dev
usb-storage: Vendor: 0x22b8, Product: 0x4810, Revision: 0x0002
usb-storage: Interface Subclass: 0x06, Protocol: 0x50
usb-storage: Transport: Bulk
usb-storage: Protocol: Transparent SCSI
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: *** thread sleeping.
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
drivers/usb/core/inode.c: creating file '005'
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00 len=1
usb-storage: GetMaxLUN command result is 1, data is 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage:  12 00 00 00 24 00
usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6
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 36 bytes, 1 entries
usb-storage: Status code 0; transferred 36/36
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
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 0x1 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
scsi 3:0:0:0: Direct-Access     Motorola Z3               2.31 PQ: 0 ANSI: 2
usb-storage: queuecommand called
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 0x2 L 0 F 0 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: 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 0x2 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x3 L 8 F 128 Trg 0 LUN 0 CL 10
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 8 bytes, 1 entries
usb-storage: Status code 0; transferred 8/8
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
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 0x3 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 3:0:0:0: [sda] 494081 512-byte hardware sectors (253 MB)
usb-storage: queuecommand called
usb-storage: *** thread awakened.
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
ohci_hcd 0000:00:02.0: urb c360bf00 path 1 ep2in 93120000 cc 9 --> 
status -121
usb-storage: Status code -121; transferred 12/192
usb-storage: -- short read transfer
usb-storage: Bulk data transfer result 0x1
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 0x4 R 180 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 3:0:0:0: [sda] Write Protect is off
sd 3:0:0:0: [sda] Mode Sense: 0b 00 00 08
sd 3:0:0:0: [sda] Assuming drive cache: write through
usb-storage: queuecommand called
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 0x5 L 0 F 0 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: 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 0x5 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes)
usb-storage:  1e 00 00 00 01 00
usb-storage: Bulk Command S 0x43425355 T 0x6 L 0 F 0 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: 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 0x6 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
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 0x7 L 0 F 0 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: 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 0x7 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x8 L 8 F 128 Trg 0 LUN 0 CL 10
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 8 bytes, 1 entries
usb-storage: Status code 0; transferred 8/8
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
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 0x8 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 3:0:0:0: [sda] 494081 512-byte hardware sectors (253 MB)
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE (6 bytes)
usb-storage:  1a 00 3f 00 c0 00
usb-storage: Bulk Command S 0x43425355 T 0x9 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
ohci_hcd 0000:00:02.0: urb c360bf00 path 1 ep2in 92120000 cc 9 --> 
status -121
usb-storage: Status code -121; transferred 12/192
usb-storage: -- short read transfer
usb-storage: Bulk data transfer result 0x1
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 0x9 R 180 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 3:0:0:0: [sda] Write Protect is off
sd 3:0:0:0: [sda] Mode Sense: 0b 00 00 08
sd 3:0:0:0: [sda] Assuming drive cache: write through
 sda:<7>usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_10 (10 bytes)
usb-storage:  28 00 00 00 00 00 00 00 08 00
usb-storage: Bulk Command S 0x43425355 T 0xa L 4096 F 128 Trg 0 LUN 0 CL 10
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 4096 bytes, 1 entries
usb-storage: Status code 0; transferred 4096/4096
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
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 0xa R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
 sda1
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes)
usb-storage:  1e 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0xb L 0 F 0 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: 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 0xb R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 3:0:0:0: [sda] Attached SCSI removable disk
sd 3:0:0:0: Attached scsi generic sg0 type 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad LUN (0:1)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (1:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (2:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (3:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (4:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (5:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (6:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (7:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: device scan complete

I hope perhaps it can provide some comparison info now with a device 
that works and one that doesn't.

If Motorola actualy has made changes to the Linux kernel they use with 
the Z6, I suppose we should be able to get the actual code. Should I 
investigate that?

Peter

Alan Stern wrote:
> On Sat, 1 Sep 2007, Andreas Koenecke wrote:
>
>   
>> I' done this, too.
>> The non-debug-messages are now:
>> ----------------------------------------------------------------------------
>> Sep  1 13:09:17 kocom kernel: usb 3-1: new high speed USB device using ehci_hcd and address 12
>> Sep  1 13:09:17 kocom kernel: usb 3-1: configuration #1 chosen from 1 choice
>> Sep  1 13:09:17 kocom kernel: Initializing USB Mass Storage driver...
>> Sep  1 13:09:17 kocom kernel: scsi7 : SCSI emulation for USB Mass Storage devices
>> Sep  1 13:09:17 kocom kernel: usb-storage: device found at 12
>> Sep  1 13:09:17 kocom kernel: usb-storage: waiting for device to settle before scanning
>> Sep  1 13:09:17 kocom kernel: usbcore: registered new interface driver usb-storage
>> Sep  1 13:09:17 kocom kernel: USB Mass Storage support registered.
>> Sep  1 13:09:22 kocom kernel: usb-storage: device scan complete
>> Sep  1 13:09:22 kocom kernel: scsi 7:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
>> Sep  1 13:09:22 kocom kernel: scsi 7:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
>> Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk
>> Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0
>> Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: [sdc] Attached SCSI removable disk
>> Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: Attached scsi generic sg3 type 0
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
>> Sep  1 13:09:28 kocom kernel:  sdb:
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] 128673 512-byte hardware sectors (66 MB)
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Write Protect is off
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Mode Sense: 03 00 00 00
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Assuming drive cache: write through
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] 128673 512-byte hardware sectors (66 MB)
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Write Protect is off
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Mode Sense: 03 00 00 00
>> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] Assuming drive cache: write through
>> Sep  1 13:09:28 kocom kernel:  sdc:
>> Sep  1 13:09:59 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
>> Sep  1 13:10:14 kocom kernel: usb 3-1: device descriptor read/64, error -110
>> Sep  1 13:10:29 kocom kernel: usb 3-1: device descriptor read/64, error -110
>> Sep  1 13:10:29 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
>> Sep  1 13:10:44 kocom kernel: usb 3-1: device descriptor read/64, error -110
>> Sep  1 13:11:00 kocom kernel: usb 3-1: device descriptor read/64, error -110
>> Sep  1 13:11:00 kocom kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 12
>> Sep  1 13:11:05 kocom kernel: usb 3-1: device descriptor read/8, error -110
>> ------------------------------------------------------------------------------------------------
>>
>> sdb and sdc appear in /proc/partitions, but trying to access with 'fdisk -l` or
>> 'mount' freezes the phone.
>>
>> I uploaded the debug-log to:
>> <http://www.akoenecke.de/moto/usb_debug2.txt>
>>
>> The debug-log included 2 spontaneous reboots and 1 freeze (in this order) of
>> the phone without unplugging.
>>     
>
> The resets and disconnects occurred because of yet another bug in the 
> phone.  It reports that sdc has 128673 sectors, but in fact it probably 
> has only 128672.  The error occurred when the computer tried to read 
> the (non-existent) last sector.  The phone failed to follow the proper 
> protocol for reporting an error, so the computer reset it.
>
> It's not surprising; other devicees from Motorola have the same bug.  
> The patch below ought to help.  However considering the number of other 
> bugs and problems in this device, it's not clear how far you should try 
> to push it...
>
> Alan Stern
>
>
> Index: usb-2.6/drivers/usb/storage/unusual_devs.h
> ===================================================================
> --- usb-2.6.orig/drivers/usb/storage/unusual_devs.h
> +++ usb-2.6/drivers/usb/storage/unusual_devs.h
> @@ -1481,6 +1481,13 @@ UNUSUAL_DEV(  0x22b8, 0x4810, 0x0001, 0x
>  		US_SC_DEVICE, US_PR_DEVICE, NULL,
>  		US_FL_FIX_CAPACITY),
>  
> +/* Reported by Andreas Koenecke <akoenecke@akoenecke.de> */
> +UNUSUAL_DEV(  0x22b8, 0x6426, 0x0101, 0x0101,
> +		"Motorola",
> +		"MSnc Z6",
> +		US_SC_DEVICE, US_PR_DEVICE, NULL,
> +		US_FL_FIX_CAPACITY),
> +
>  /* Reported by Radovan Garabik <garabik@kassiopeia.juls.savba.sk> */
>  UNUSUAL_DEV(  0x2735, 0x100b, 0x0000, 0x9999,
>  		"MPIO",
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Linux-usb-users@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-users
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Re: [Linux-usb-users] usb-storage and Motorola Z6

[Alan Stern]

On Fri, 7 Sep 2007, Peter Rasmussen wrote:

> I'm sorry if this is a little late, but I had once had access to a Z6 
> and believe I had it successfully connected to my Linux host, and was 
> therefore puzzled by this message exchange.
> 
> I have now borrowed the device again for the weekend to check it out a 
> little more.
> 
> Using Alan's patch below, otherwise my kernel is a standard 2.6.23-rc5 
> (CONFIG_USB_STORAGE_DEBUG=y ) I got the following result after reboot 
> and connecting the Z6.:
...

In fact there was another patch from earlier in the email thread, which 
was needed to work around the PQ = 1 problem.  Since you didn't apply 
that patch, the SCSI disk driver wasn't bound to your Z6.

> What I can't understand, however, is that as this mobile phone 
> supposedly runs Linux. I can't see how Motorola could break it so badly 
> that the USB connection now doesn't work with a PC running Linux?

:-)  There's no necessary relation between the OS running on a device
like your phone and its interoperability with computers running the
same OS.

> And you say that this seems to be a more widespread problem with 
> Motorola devices? Do you remember which ones, and do they run Linux as well?

There were two problems.  First was the PQ = 1 problem; I have never
seen it before now (so only on the Z6).  The other problem was the
capacity, or last sector number; we know that the RAZR V3i and V3x both
suffer from it as well.  (I have no idea whether they run Linux.)  
Possibly other devices do too, and we just don't know about them.

> The following is from connecting a Z3 that supposedly isn't based on 
> Linux, but works all right (and this may have been the one I thought was 
> the Z6 that I claimed worked):
...

It looks normal.

> I hope perhaps it can provide some comparison info now with a device 
> that works and one that doesn't.
> 
> If Motorola actualy has made changes to the Linux kernel they use with 
> the Z6, I suppose we should be able to get the actual code. Should I 
> investigate that?

Sure, go ahead and try.  Maybe you can convince them to fix their bugs!  
Although that won't help all the units that have already been 
manufactured...

Alan Stern

Re: usb-storage and Motorola Z6

[Peter Rasmussen]

Alan Stern wrote:
> On Fri, 7 Sep 2007, Peter Rasmussen wrote:
>
>   
>> I'm sorry if this is a little late, but I had once had access to a Z6 
>> and believe I had it successfully connected to my Linux host, and was 
>> therefore puzzled by this message exchange.
>>
>> I have now borrowed the device again for the weekend to check it out a 
>> little more.
>>
>> Using Alan's patch below, otherwise my kernel is a standard 2.6.23-rc5 
>> (CONFIG_USB_STORAGE_DEBUG=y ) I got the following result after reboot 
>> and connecting the Z6.:
>>     
> ...
>
> In fact there was another patch from earlier in the email thread, which 
> was needed to work around the PQ = 1 problem.  Since you didn't apply 
> that patch, the SCSI disk driver wasn't bound to your Z6.
>
>   
Now I applied that patch, too, and it did make a difference, in drivers/scsi/scsi_sysfs.c I have:

static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
{
        struct scsi_device *sdp = to_scsi_device(dev);
        if (sdp->no_uld_attach)
                return 0;
        return 1;
//      return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
}

Before posting a lot of USB debug output, I'll explain a shorter version :-)

1.After reboot I connected the Z6 (incl. a micro-SD card) and got what looked good, if not the usual output from dmesg:

<snip>
scsi 0:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
<snip>
sd 0:0:0:0: [sda] Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
<snip>
scsi 0:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
<snip>
sd 0:0:0:1: [sdb] Attached SCSI removable disk
sd 0:0:0:1: Attached scsi generic sg1 type 0
<snip>

2.I could then mount the SCSI devices like this:

# mount /dev/sda /mnt/usb
# mount /dev/sdb /mnt/usb2

When I normally with a USB mass storage device do, eg.:

# mount /dev/sda1 /mnt/usb

3.I couldn't however, always mount the mentioned devices as I would sometimes get a 'mount: No medium found' error, and a message on the mobile will sometimes show "USB connected" and sometimes "USB disconnected" even though it didn't seem to correlate to successful connection between my PC and the Z6.

4.So, something seems to be inconsistent. I have tried it with a few different cables and I can't detect a difference.

5.Should I post a full log of eg. connecting the Z6, mounting it and the SD card, accessing it and then unmounting? 
  A full log may then include failed attempts, which will perhaps give some hints at what is wrong?
  Or do you already have a pretty good idea as to what is wrong, and find that such an exercise is not really useful?

>> What I can't understand, however, is that as this mobile phone 
>> supposedly runs Linux. I can't see how Motorola could break it so badly 
>> that the USB connection now doesn't work with a PC running Linux?
>>     
>
> :-)  There's no necessary relation between the OS running on a device
> like your phone and its interoperability with computers running the
> same OS.
>
>   
Well, I would have expected that they have similar methods to connect, even though different Linux kernel version of course may have introduced some differences. My A780 has a 2.4.20 kernel and I wouldn't be surprised if other Motorola mobiles also use the 2.4.* series of Linux kernels.

>> And you say that this seems to be a more widespread problem with 
>> Motorola devices? Do you remember which ones, and do they run Linux as well?
>>     
>
> There were two problems.  First was the PQ = 1 problem; I have never
> seen it before now (so only on the Z6).  The other problem was the
> capacity, or last sector number; we know that the RAZR V3i and V3x both
> suffer from it as well.  (I have no idea whether they run Linux.)  
> Possibly other devices do too, and we just don't know about them.
>
>   
I know that those two don't run Linux, but can they connect to a Linux host, or do they also have problems?

>> The following is from connecting a Z3 that supposedly isn't based on 
>> Linux, but works all right (and this may have been the one I thought was 
>> the Z6 that I claimed worked):
>>     
> ...
>
> It looks normal.
>
>   
>> I hope perhaps it can provide some comparison info now with a device 
>> that works and one that doesn't.
>>
>> If Motorola actualy has made changes to the Linux kernel they use with 
>> the Z6, I suppose we should be able to get the actual code. Should I 
>> investigate that?
>>     
>
> Sure, go ahead and try.  Maybe you can convince them to fix their bugs!  
> Although that won't help all the units that have already been 
> manufactured...
>
>   
Well, if they could provide an update, then people that have one and want to use it with Linux should be able to get some relief.

> Alan Stern
>
>   
Peter



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Re: usb-storage and Motorola Z6

[Alan Stern]

On Sat, 8 Sep 2007, Peter Rasmussen wrote:

> > In fact there was another patch from earlier in the email thread, which 
> > was needed to work around the PQ = 1 problem.  Since you didn't apply 
> > that patch, the SCSI disk driver wasn't bound to your Z6.
> >
> >   
> Now I applied that patch, too, and it did make a difference, in drivers/scsi/scsi_sysfs.c I have:
> 
> static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
> {
>         struct scsi_device *sdp = to_scsi_device(dev);
>         if (sdp->no_uld_attach)
>                 return 0;
>         return 1;
> //      return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
> }

Did you also make the change to usb-storage for ignoring wrong Tag 
values?

> Before posting a lot of USB debug output, I'll explain a shorter version :-)
> 
> 1.After reboot I connected the Z6 (incl. a micro-SD card) and got
> what looked good, if not the usual output from dmesg:
> 
> <snip>
> scsi 0:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> <snip>
> sd 0:0:0:0: [sda] Attached SCSI removable disk
> sd 0:0:0:0: Attached scsi generic sg0 type 0
> <snip>
> scsi 0:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> <snip>
> sd 0:0:0:1: [sdb] Attached SCSI removable disk
> sd 0:0:0:1: Attached scsi generic sg1 type 0
> <snip>

Evidently the phone didn't report that the micro-SD card was present.  
Otherwise you would have seen log entries describing the number of
sectors and the write-protect status.

> 2.I could then mount the SCSI devices like this:
> 
> # mount /dev/sda /mnt/usb
> # mount /dev/sdb /mnt/usb2
> 
> When I normally with a USB mass storage device do, eg.:
> 
> # mount /dev/sda1 /mnt/usb
> 
> 3.I couldn't however, always mount the mentioned devices as I would
> sometimes get a 'mount: No medium found' error, and a message on the
> mobile will sometimes show "USB connected" and sometimes "USB
> disconnected" even though it didn't seem to correlate to successful
> connection between my PC and the Z6.
> 
> 4.So, something seems to be inconsistent. I have tried it with a few
> different cables and I can't detect a difference.
> 
> 5.Should I post a full log of eg. connecting the Z6, mounting it and the SD card, accessing it and then unmounting? 
>   A full log may then include failed attempts, which will perhaps give some hints at what is wrong?
>   Or do you already have a pretty good idea as to what is wrong, and find that such an exercise is not really useful?

If you want to post a log, include only the initial connection and one 
failed mount attempt.  Also, you can remove linux-scsi from the CC: 
list above, since this bug no longer involves any SCSI-level issues.

> > :-)  There's no necessary relation between the OS running on a device
> > like your phone and its interoperability with computers running the
> > same OS.
> >
> >   
> Well, I would have expected that they have similar methods to
> connect, even though different Linux kernel version of course may
> have introduced some differences. My A780 has a 2.4.20 kernel and I
> wouldn't be surprised if other Motorola mobiles also use the 2.4.*
> series of Linux kernels.

Not at all -- the methods used for connecting are _completely_
different, because the phone connects as a peripheral whereas the
kernel expects to connect as a host.

> >> And you say that this seems to be a more widespread problem with 
> >> Motorola devices? Do you remember which ones, and do they run Linux as well?
> >>     
> >
> > There were two problems.  First was the PQ = 1 problem; I have never
> > seen it before now (so only on the Z6).  The other problem was the
> > capacity, or last sector number; we know that the RAZR V3i and V3x both
> > suffer from it as well.  (I have no idea whether they run Linux.)  
> > Possibly other devices do too, and we just don't know about them.

Plus the third (incorrect Tags) problem, which I forgot to mention
earlier.

> I know that those two don't run Linux, but can they connect to a
> Linux host, or do they also have problems?

They can connect to a Linux host with no problem, now that the 
appropriate quirks entries have been created.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users