Re: kernel status, "Elitegroup K7S5A"

Re: kernel status, "Elitegroup K7S5A"

[Pete Zaitcev]

On Mon, 5 Sep 2005 13:55:46 -0700, Andrew Morton <akpm@osdl.org> wrote:

> Re: Elitegroup K7S5A + usb_storage problem
> [linux-usb-devel] Fw: Re: Elitegroup K7S5A + usb_storage problem

This appears to be stuck. It has to have someone with a lot of patience
to play with the device.

Martin collected me a good USB trace from Windows, but I was unable
to figure out what we do differently. The device accepts writes,
everything looks fine, but if unplugged and plugged back, it returns
old data. All commands appear basically the same.

The device, BTW, is called "Fun" and "Stick". Has nothing to do with
memory sticks, of course. Stupid DNT. Anyway, a European Linux hacker
has to get his hands on one of these before any progress can be made:
 http://www.dnt.de/index.php?dir=details&pid=53038&cat=mp3-128&m_id=mp3-128&h_curr=

-- Pete

Re: kernel status, "Elitegroup K7S5A" SOLVED

[Martin Maurer]

[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]

Hi all,

I recently got an E-Mail from Axel Strübing who had the same problem and 
solved it (together with some kernel developpers).
He pointed me to their discussion at 
http://www.spinics.net/lists/usb/msg00694.html which included a solution to 
this problem.

citing http://www.spinics.net/lists/usb/msg00725.html :
------------------------------------------------------------
> test this by editing the source code for 2.6.7.  In the file 
> drivers/usb/storage/transport.c, locate the subroutine 
> usb_stor_Bulk_max_lun() and comment out the two lines that call 
> usb_stor_clear_halt().
------------------------------------------------------------

this solved my problem too. I tried a case where i copied all mp3 files of my 
mp3 player, formatted it, copied all files back, unmounted, replugged, 
mounted again and did a diff on all files and it was successful.
Therefore it looks like this mp3 player works without problems again.
(i tested with a vanilla kernel 2.6.14).

greetings
Martin Maurer

On Thursday, 8. September 2005 06:13, you wrote:
> On Mon, 5 Sep 2005 13:55:46 -0700, Andrew Morton <akpm@osdl.org> wrote:
> > Re: Elitegroup K7S5A + usb_storage problem
> > [linux-usb-devel] Fw: Re: Elitegroup K7S5A + usb_storage problem
>
> This appears to be stuck. It has to have someone with a lot of patience
> to play with the device.
>
> Martin collected me a good USB trace from Windows, but I was unable
> to figure out what we do differently. The device accepts writes,
> everything looks fine, but if unplugged and plugged back, it returns
> old data. All commands appear basically the same.
>
> The device, BTW, is called "Fun" and "Stick". Has nothing to do with
> memory sticks, of course. Stupid DNT. Anyway, a European Linux hacker
> has to get his hands on one of these before any progress can be made:
> 
> http://www.dnt.de/index.php?dir=details&pid=53038&cat=mp3-128&m_id=mp3-128&
>h_curr=
>
> -- Pete
> -
> 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 #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: kernel status, "Elitegroup K7S5A" SOLVED

[Pete Zaitcev]

On Sun, 6 Nov 2005 19:22:12 +0100, Martin Maurer <martinmaurer@gmx.at> wrote:

> > test this by editing the source code for 2.6.7.  In the file 
> > drivers/usb/storage/transport.c, locate the subroutine 
> > usb_stor_Bulk_max_lun() and comment out the two lines that call 
> > usb_stor_clear_halt().

> this solved my problem too. [...]
> (i tested with a vanilla kernel 2.6.14).

I would like to see a real patch instead of verbal descriptions, because
what you say is not easily believable. I suspect a language barrier.

The difficulty is, in 2.6.14, both ub and usb-storage clear halts when
the device stalls (in ub_probe and usb_stor_Bulk_max_lun). It may be
incorrect, because it's a stall on the control pipe, not a bulk pipe.
But I have no idea what the proper recovery procedure is (e.g. what
happens if we just ignore stalls of control transfers?)

If someone like Pat explaned me what to do, I could code it.

-- Pete