Fw: Re: Elitegroup K7S5A + usb_storage problem

Fw: Re: Elitegroup K7S5A + usb_storage problem

[Pete Zaitcev]

On Sat, 6 Aug 2005 11:49:05 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:

> When asked what went wrong, the device says it didn't understand the 
> INQUIRY command.  This is a fatal error; if a device can't identify itself 
> there's no way for Linux to use it.
> 
> In short, your mp3stick is worthless.  Trade it in for one that works.

This is only true if usb-storage is used. The stick may work with ub.

Martin, please apply the attached patch and enable CONFIG_BLK_DEV_UB.
If you do not run a userland with udev, do this:

mknod /dev/uba b 180 0
mknod /dev/uba1 b 180 1

Let me know how it went.

-- Pete

diff -urp -X dontdiff linux-2.6.12/drivers/usb/storage/usb.c linux-2.6.12-lem/drivers/usb/storage/usb.c
--- linux-2.6.12/drivers/usb/storage/usb.c	2005-06-17 12:48:29.000000000 -0700
+++ linux-2.6.12-lem/drivers/usb/storage/usb.c	2005-07-25 22:12:53.000000000 -0700
@@ -150,7 +150,9 @@ static struct usb_device_id storage_usb_
 	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_QIC, US_PR_BULK) },
 	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_UFI, US_PR_BULK) },
 	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8070, US_PR_BULK) },
+#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
 	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_BULK) },
+#endif
 
 	/* Terminating entry */
 	{ }
@@ -224,8 +226,10 @@ static struct us_unusual_dev us_unusual_
 	  .useTransport = US_PR_BULK},
 	{ .useProtocol = US_SC_8070,
 	  .useTransport = US_PR_BULK},
+#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
 	{ .useProtocol = US_SC_SCSI,
 	  .useTransport = US_PR_BULK},
+#endif
 
 	/* Terminating entry */
 	{ NULL }

Re: Fw: Re: Elitegroup K7S5A + usb_storage problem

[Martin Maurer]

[-- Attachment #1.1: Type: text/plain, Size: 2825 bytes --]

Hi Pete,

when using ub with your patch i get a lot further:
the device is detected and uba+uba1 entries appear.
I can mount the device correctly.
Copying the files down and comparing them with the originals gives correct 
results.

but:
when i delete the files which are on the stick and do an umount/mount cycle, 
the files are there again. 
Copying files to the stick gives wrong results too.
Once the created file vanished after the remount,
and once it was there with a different name/size/date and garbage as content.

I didnt try ub without your patch (CONFIG_BLK_DEV_UB was disabled in my kernel 
configuration). Shall I try this too?

greetings
Martin


On Saturday, 6. August 2005 22:02, Pete Zaitcev wrote:
> On Sat, 6 Aug 2005 11:49:05 -0400 (EDT), Alan Stern 
<stern@rowland.harvard.edu> wrote:
> > When asked what went wrong, the device says it didn't understand the
> > INQUIRY command.  This is a fatal error; if a device can't identify
> > itself there's no way for Linux to use it.
> >
> > In short, your mp3stick is worthless.  Trade it in for one that works.
>
> This is only true if usb-storage is used. The stick may work with ub.
>
> Martin, please apply the attached patch and enable CONFIG_BLK_DEV_UB.
> If you do not run a userland with udev, do this:
>
> mknod /dev/uba b 180 0
> mknod /dev/uba1 b 180 1
>
> Let me know how it went.
>
> -- Pete
>
> diff -urp -X dontdiff linux-2.6.12/drivers/usb/storage/usb.c
> linux-2.6.12-lem/drivers/usb/storage/usb.c ---
> linux-2.6.12/drivers/usb/storage/usb.c	2005-06-17 12:48:29.000000000 -0700
> +++ linux-2.6.12-lem/drivers/usb/storage/usb.c	2005-07-25
> 22:12:53.000000000 -0700 @@ -150,7 +150,9 @@ static struct usb_device_id
> storage_usb_
>  	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_QIC, US_PR_BULK) },
>  	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_UFI, US_PR_BULK) },
>  	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8070, US_PR_BULK) },
> +#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
>  	{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_BULK) },
> +#endif
>
>  	/* Terminating entry */
>  	{ }
> @@ -224,8 +226,10 @@ static struct us_unusual_dev us_unusual_
>  	  .useTransport = US_PR_BULK},
>  	{ .useProtocol = US_SC_8070,
>  	  .useTransport = US_PR_BULK},
> +#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
>  	{ .useProtocol = US_SC_SCSI,
>  	  .useTransport = US_PR_BULK},
> +#endif
>
>  	/* Terminating entry */
>  	{ NULL }
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[-- Attachment #1.2: mp3stick_working.dmesg --]
[-- Type: text/plain, Size: 669 bytes --]

hub 1-1:1.0: state 5 ports 4 chg 0000 evt 0010
hub 1-1:1.0: port 4, status 0101, change 0001, 12 Mb/s
hub 1-1:1.0: debounce: port 4: total 100ms stable 100ms status 0x101
usb 1-1.4: new full speed USB device using ohci_hcd and address 7
usb 1-1.4: ep0 maxpacket = 32
usb 1-1.4: new device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1.4: hotplug
usb 1-1.4: adding 1-1.4:1.0 (config #1, interface 0)
usb 1-1.4:1.0: hotplug
ub 1-1.4:1.0: usb_probe_interface
ub 1-1.4:1.0: usb_probe_interface - got id
ub(1.7): GetMaxLUN returned 0 bytes
ub(1.7): GetMaxLUN returned 0 bytes
ub(1.7): GetMaxLUN returned 0 bytes
 uba: uba1
hub 1-1:1.0: state 5 ports 4 chg 0000 evt 0010

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fw: Re: Elitegroup K7S5A + usb_storage problem

[Pete Zaitcev]

On Sun, 7 Aug 2005 02:22:53 +0200, Martin Maurer <martinmaurer@gmx.at> wrote:

> when i delete the files which are on the stick and do an umount/mount
> cycle, the files are there again. 
> Copying files to the stick gives wrong results too.

Curious. First of all, I have a request: do not call this device a "stick".
It is terribly misleading word with which to call a fully-featured MP3
player. DNT uses it in a specific context, as a product name.

I'd like to have a usbmon trace of a session, from plugging, through
copying, through unplugging. Do not send it to the whole cc: list.
Do you need instructions?

-- Pete

Re: Fw: Re: Elitegroup K7S5A + usb_storage problem

[Alan Stern]

On Sun, 7 Aug 2005, Martin Maurer wrote:

> Hi Pete,
> 
> when using ub with your patch i get a lot further:
> the device is detected and uba+uba1 entries appear.
> I can mount the device correctly.
> Copying the files down and comparing them with the originals gives correct 
> results.
> 
> but:
> when i delete the files which are on the stick and do an umount/mount cycle, 
> the files are there again. 
> Copying files to the stick gives wrong results too.
> Once the created file vanished after the remount,
> and once it was there with a different name/size/date and garbage as content.

It sounds as though the device isn't actually carrying out the write 
operations.  Is it write-protected?

Alan Stern

Re: Fw: Elitegroup K7S5A + usb_storage problem

[Pete Zaitcev]

> when i delete the files which are on the stick and do an umount/mount cycle, 
> the files are there again. 
>[... other mail ...]

> I did the usbmon thing (hopefully correctly). Attached is the output.

Yes, that was perfect, thanks a lot. Unfortunately, I do not see a lot
of interesting things. The last write before the disconnect is a FAT
update:

c31650b8 1617078003 S Bo:006:01 -115 31 = 55534243 c6000000 00020000 00000a2a 00000000 30000001 00000000 000000
c31650b8 1617078987 C Bo:006:01 0 31 >
c31650b8 1617078997 S Bo:006:01 -115 512 = f8ffffff ffffffff ffffffff 00000000 00000000 00000000 00000000 00000000
c31650b8 1617080988 C Bo:006:01 0 512 >
c31650b8 1617080998 S Bi:006:02 -115 13 <
c31650b8 1617084987 C Bi:006:02 0 13 = 55534253 c6000000 00000000 00

Only one cluster was taken, when compared with the FAT that was read.
Everything seems to be in order. But the next trace (after replug -
see the device number changing from 6 to 7) shows FAT with old contents
being read (same block number 0x30):

> cd6960b8 1874976301 S Bo:007:01 -115 31 = 55534243 0b000000 00020000 80000a28 00000000 30000001 00000000 000000
> cd6960b8 1874977274 C Bo:007:01 0 31 >
> cd6960b8 1874977288 S Bi:007:02 -115 512 <
> cd6960b8 1874979271 C Bi:007:02 0 512 = f8ffffff ffffffff ffff0000 00000000 00000000 00000000 00000000 00000000
> cd6960b8 1874979282 S Bi:007:02 -115 13 <
> cd6960b8 1874981271 C Bi:007:02 0 13 = 55534253 0b000000 00000000 00

So, the device replies that writes were successful, but does not
actually commit them to the stable storage.

I suspect that this device may require some delays. I seem to recall
that we added delayes to usb-storage when we worked with Genesys
Logic. But ub contains no delays.

How about this:

--- linux-2.6.13-rc4/drivers/block/ub.c	2005-07-29 19:51:00.000000000 -0700
+++ linux-2.6.13-rc4-lem/drivers/block/ub.c	2005-08-07 13:48:11.000000000 -0700
@@ -1209,6 +1279,8 @@
 			return;
 		}
 
+		udelay(125);	// XXX for Martin Maurer <martinmaurer@gmx.at> 
+
 		UB_INIT_COMPLETION(sc->work_done);
 
 		if (cmd->dir == UB_DIR_READ)

Please try this patchlet and let us know how it went.

-- Pete