Bug 11640 (usbstick-once) - Usb stick mounts only once, upon writing non readable next connect.
Summary: Usb stick mounts only once, upon writing non readable next connect.
Status: CLOSED CODE_FIX
Alias: usbstick-once
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Greg Kroah-Hartman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-24 09:04 UTC by Monchi
Modified: 2008-09-26 07:12 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.4.x -> 2.6.x -> 2.6.27-rc7 ( most if not all )
Tree: Mainline
Regression: ---


Attachments
debug syslog under kernel 2.6.27-rc7 (15.22 KB, text/plain)
2008-09-24 09:05 UTC, Monchi
Details
snoopy pro binary log. (247.13 KB, application/octet-stream)
2008-09-25 05:28 UTC, Monchi
Details

Description Monchi 2008-09-24 09:04:25 UTC
Latest working kernel version: none
Earliest failing kernel version: all
Distribution: most
Hardware Environment: intel/powerpc
Software Environment:
Problem Description: Usb stick can be attached only once to linux system to be bricked for all linux systems. While being bricked for linux systems, the stick still works for windows macosx.

Steps to reproduce: Buy a stick based on prolific Vendor: 0x067b, Product: 0x2528, Revision: 0x0100 such as the Adata PD16. Insert in any linux system, mount read files write files to stick, repartition, sync, unmount everything nicely according to rules, then extract the stick. Now reinsert the stick, stick becomes unusable in linux, however stick works perfect under windows and macosx.
Comment 1 Monchi 2008-09-24 09:05:53 UTC
Created attachment 18005 [details]
debug syslog under kernel 2.6.27-rc7
Comment 2 Anonymous Emailer 2008-09-24 09:43:39 UTC
Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 24 Sep 2008 09:04:25 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=11640
> 
>            Summary: Usb stick mounts only once, upon writing non readable
>                     next connect.
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.4.x -> 2.6.x -> 2.6.27-rc7 ( most if not all )
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: USB
>         AssignedTo: greg@kroah.com
>         ReportedBy: kernel@axion.demon.nl
>                 CC: kernel@axion.demon.nl
> 
> 
> Latest working kernel version: none
> Earliest failing kernel version: all
> Distribution: most
> Hardware Environment: intel/powerpc
> Software Environment:
> Problem Description: Usb stick can be attached only once to linux system to
> be
> bricked for all linux systems. While being bricked for linux systems, the
> stick
> still works for windows macosx.
> 
> Steps to reproduce: Buy a stick based on prolific Vendor: 0x067b, Product:
> 0x2528, Revision: 0x0100 such as the Adata PD16. Insert in any linux system,
> mount read files write files to stick, repartition, sync, unmount everything
> nicely according to rules, then extract the stick. Now reinsert the stick,
> stick becomes unusable in linux, however stick works perfect under windows
> and
> macosx.
> 
Comment 3 Alan Stern 2008-09-24 11:17:46 UTC
On Wed, 24 Sep 2008, Andrew Morton wrote:

> On Wed, 24 Sep 2008 09:04:25 -0700 (PDT) bugme-daemon@bugzilla.kernel.org
> wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=11640
> > 
> >            Summary: Usb stick mounts only once, upon writing non readable
> >                     next connect.

> > Problem Description: Usb stick can be attached only once to linux system to
> be
> > bricked for all linux systems. While being bricked for linux systems, the
> stick
> > still works for windows macosx.
> > 
> > Steps to reproduce: Buy a stick based on prolific Vendor: 0x067b, Product:
> > 0x2528, Revision: 0x0100 such as the Adata PD16. Insert in any linux
> system,
> > mount read files write files to stick, repartition, sync, unmount
> everything
> > nicely according to rules, then extract the stick. Now reinsert the stick,
> > stick becomes unusable in linux, however stick works perfect under windows
> and
> > macosx.

I don't remember ever seeing anything quite like this.  Can you collect 
a SnoopyPro log under Windows for comparison with the Linux log?

Alan Stern
Comment 4 Monchi 2008-09-25 05:28:41 UTC
Created attachment 18030 [details]
snoopy pro binary log.

snoopy pro binary log.
Comment 5 Anonymous Emailer 2008-09-25 05:38:23 UTC
Reply-To: axion0@xs4all.nl

> On Wed, 24 Sep 2008, Andrew Morton wrote:
>
>> On Wed, 24 Sep 2008 09:04:25 -0700 (PDT)
>> bugme-daemon@bugzilla.kernel.org wrote:
>>
>> > http://bugzilla.kernel.org/show_bug.cgi?id=11640
>> >
>> >            Summary: Usb stick mounts only once, upon writing non
>> readable
>> >                     next connect.
>
>> > Problem Description: Usb stick can be attached only once to linux
>> system to be
>> > bricked for all linux systems. While being bricked for linux systems,
>> the stick
>> > still works for windows macosx.
>> >
>> > Steps to reproduce: Buy a stick based on prolific Vendor: 0x067b,
>> Product:
>> > 0x2528, Revision: 0x0100 such as the Adata PD16. Insert in any linux
>> system,
>> > mount read files write files to stick, repartition, sync, unmount
>> everything
>> > nicely according to rules, then extract the stick. Now reinsert the
>> stick,
>> > stick becomes unusable in linux, however stick works perfect under
>> windows and
>> > macosx.
>
> I don't remember ever seeing anything quite like this.  Can you collect
> a SnoopyPro log under Windows for comparison with the Linux log?
>
> Alan Stern
>
>

I posted a snoopypro binary usblog on bugzilla, way to big (250k) to reply
to all.
Please tell me if I it need to be the xml file format.
I have just now wiped the stick and am passing it through the wringer on a
kernel 2.6.27-rc7 system. Please stay tuned for log(s).


Monchi.
--
Comment 6 Alan Stern 2008-09-25 08:43:04 UTC
On Thu, 25 Sep 2008, axion wrote:

> >> > http://bugzilla.kernel.org/show_bug.cgi?id=11640

> I posted a snoopypro binary usblog on bugzilla, way to big (250k) to reply
> to all.
> Please tell me if I it need to be the xml file format.
> I have just now wiped the stick and am passing it through the wringer on a
> kernel 2.6.27-rc7 system. Please stay tuned for log(s).

The SnoopyPro log shows that the device took about 14.5 seconds to 
respond to the initial INQUIRY command.  By default Linux gives up 
after only 5 seconds.

You can change this timeout.  To make it 15 seconds, just do:

	echo 15 >/sys/module/scsi_mod/parameters/inq_timeout

Then the stick should work okay.

Alan Stern
Comment 7 Anonymous Emailer 2008-09-25 10:20:55 UTC
Reply-To: axion0@xs4all.nl

Thank you it worked.
Before I had no way of testing it out, becuase I used the old fix of
wiping the stick on a windows system. I was then experimenting trying to
get the stick to fail with fat32. But it just souldn,t fail, and I was
beginning to think the delay of the debugging messages might increase the
timeout.
But it wasn't untill I created an ext2 and a swap partition before the
stick started to fail again. Upon setting the inquery-timeout to 15 sec it
worked instantly. I would seem the stick is cheating when you are creating
partitions of a different type then fat32. ( even though I've had it fail
with a vfat partiton before.
Now if only this timeout could be the standard for the kernel so as to be
able to boot of the stick. Or in this respect I hope grub has no problems
with this.

Monchi.
--
ps.hitting my head agains the massive front door for forgetting to analyze
the snoopypro log myself.
> http://bugzilla.kernel.org/show_bug.cgi?id=11640
>
>
>
>
>
> ------- Comment #6 from stern@rowland.harvard.edu  2008-09-25 08:43
> -------
> On Thu, 25 Sep 2008, axion wrote:
>
>> >> > http://bugzilla.kernel.org/show_bug.cgi?id=11640
>
>> I posted a snoopypro binary usblog on bugzilla, way to big (250k) to
>> reply
>> to all.
>> Please tell me if I it need to be the xml file format.
>> I have just now wiped the stick and am passing it through the wringer on
>> a
>> kernel 2.6.27-rc7 system. Please stay tuned for log(s).
>
> The SnoopyPro log shows that the device took about 14.5 seconds to
> respond to the initial INQUIRY command.  By default Linux gives up
> after only 5 seconds.
>
> You can change this timeout.  To make it 15 seconds, just do:
>
>         echo 15 >/sys/module/scsi_mod/parameters/inq_timeout
>
> Then the stick should work okay.
>
> Alan Stern
>
>
> --
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
Comment 8 Anonymous Emailer 2008-09-25 10:27:11 UTC
Reply-To: axion0@xs4all.nl

The longer delay is due to the fact that the stick has the possibility to
be partitioned in two one of the partition would be a security partition.
While the other one could be any partition. I think that the stick
contains firmware that analyzes the partition table to look for the
"hidden" partition so it can "hide" it.


Monchi.
--
> http://bugzilla.kernel.org/show_bug.cgi?id=11640
>
>
>
>
>
> ------- Comment #7 from anonymous@kernel-bugs.osdl.org  2008-09-25 10:20
> -------
> Reply-To: axion0@xs4all.nl
>
> Thank you it worked.
> Before I had no way of testing it out, becuase I used the old fix of
> wiping the stick on a windows system. I was then experimenting trying to
> get the stick to fail with fat32. But it just souldn,t fail, and I was
> beginning to think the delay of the debugging messages might increase the
> timeout.
> But it wasn't untill I created an ext2 and a swap partition before the
> stick started to fail again. Upon setting the inquery-timeout to 15 sec it
> worked instantly. I would seem the stick is cheating when you are creating
> partitions of a different type then fat32. ( even though I've had it fail
> with a vfat partiton before.
> Now if only this timeout could be the standard for the kernel so as to be
> able to boot of the stick. Or in this respect I hope grub has no problems
> with this.
>
> Monchi.
> --
> ps.hitting my head agains the massive front door for forgetting to analyze
> the snoopypro log myself.
>> http://bugzilla.kernel.org/show_bug.cgi?id=11640
>>
>>
>>
>>
>>
>> ------- Comment #6 from stern@rowland.harvard.edu  2008-09-25 08:43
>> -------
>> On Thu, 25 Sep 2008, axion wrote:
>>
>>> >> > http://bugzilla.kernel.org/show_bug.cgi?id=11640
>>
>>> I posted a snoopypro binary usblog on bugzilla, way to big (250k) to
>>> reply
>>> to all.
>>> Please tell me if I it need to be the xml file format.
>>> I have just now wiped the stick and am passing it through the wringer
>>> on
>>> a
>>> kernel 2.6.27-rc7 system. Please stay tuned for log(s).
>>
>> The SnoopyPro log shows that the device took about 14.5 seconds to
>> respond to the initial INQUIRY command.  By default Linux gives up
>> after only 5 seconds.
>>
>> You can change this timeout.  To make it 15 seconds, just do:
>>
>>         echo 15 >/sys/module/scsi_mod/parameters/inq_timeout
>>
>> Then the stick should work okay.
>>
>> Alan Stern
>>
>>
>> --
>> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
>> ------- You are receiving this mail because: -------
>> You reported the bug, or are watching the reporter.
>>
>
>
> --
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
Comment 9 Alan Stern 2008-09-25 11:47:48 UTC
On grub's boot command line you should add:  scsi_mod.inq_timeout=15

If you're happy, you can go ahead and close out this bug report.
Comment 10 Monchi 2008-09-25 22:36:35 UTC
Could this longer inq timeout become part of a greylisted usb-stick chipset ?
Because many people on the corsair forum have the same problem. Different sick manufacturer same usb->flash controller.
Comment 11 Alan Stern 2008-09-26 07:12:26 UTC
I don't know -- the inq_timeout setting is global, affect every SCSI device added to the system, not just an individual USB device.  However testing shows that Windows XP uses a timeout of 20 seconds for USB storage devices.

I'll ask on the SCSI development mailing list.

Note You need to log in before you can comment on or make changes to this bug.