Norman Diamond | 1 May 10:16 2012
Picon

JMicron 20337 (152d:2338) and 3TB

When a 3TB SATA drive is connected through a JMicron JMS539 (USB3.0 to SATA Bridge, 152d:0539), Windows
sees 3TB and Linux sees 3TB.

When the same drive is connected through a JMicron 20337 (152d:2338), Windows sees 3TB but Linux sees
800GB.  (Fortunately Linux avoids mounting the truncated partitions.)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Oliver Neukum | 1 May 10:18 2012

Re: JMicron 20337 (152d:2338) and 3TB

Am Dienstag, 1. Mai 2012, 10:16:18 schrieb Norman Diamond:
> When a 3TB SATA drive is connected through a JMicron JMS539 (USB3.0 to SATA Bridge, 152d:0539), Windows
sees 3TB and Linux sees 3TB.
> 
> When the same drive is connected through a JMicron 20337 (152d:2338), Windows sees 3TB but Linux sees
800GB.  (Fortunately Linux avoids mounting the truncated partitions.)

Windows trusts partition tables. Linux does not.
It is possible that the device suffers an overflow in its handler
for querying medium size but handles medium access just fine.

	Regards
		Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Norman Diamond | 1 May 11:03 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Oliver Neukum wrote:

> Am Dienstag, 1. Mai 2012, 10:16:18 schrieb Norman Diamond:
>> When a 3TB SATA drive is connected through a JMicron JMS539 (USB3.0 to SATA Bridge, 152d:0539), Windows
sees 3TB and Linux sees 3TB.
>> 
>> When the same drive is connected through a JMicron 20337 (152d:2338), Windows sees 3TB but Linux sees
800GB.  (Fortunately Linux avoids mounting the truncated partitions.)
> 
> Windows trusts partition tables. Linux does not.

I don't think so.  When a drive had partitions created and then was DCO'ed to a smaller size, so that DCO
truncated the last partition, Windows refused to mount the partition.  Windows trusted the drive's
reported size before trusting the partition.  When I un-DCO'ed the drive, Windows mounted the partition
(so did Linux).

Windows really saw the full size of the 3TB drive.

> It is possible that the device suffers an overflow in its handler
> for querying medium size but handles medium access just fine.

That is why I tested the bridge in Windows too.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alan Stern | 1 May 16:13 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Tue, 1 May 2012, Norman Diamond wrote:

> When a 3TB SATA drive is connected through a JMicron JMS539 (USB3.0
> to SATA Bridge, 152d:0539), Windows sees 3TB and Linux sees 3TB.
> 
> When the same drive is connected through a JMicron 20337 (152d:2338),
> Windows sees 3TB but Linux sees 800GB.  (Fortunately Linux avoids
> mounting the truncated partitions.)

For debugging issues like this, usbmon is your friend.  See 
Documentation/usb/usbmon.txt.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Norman Diamond | 2 May 07:17 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Alan Stern wrote:
> On Tue, 1 May 2012, Norman Diamond wrote:
>> When a 3TB SATA drive is connected through a JMicron JMS539 (USB3.0
>> to SATA Bridge, 152d:0539), Windows sees 3TB and Linux sees 3TB.
>> 
>> When the same drive is connected through a JMicron 20337 (152d:2338),
>> Windows sees 3TB but Linux sees 800GB.  (Fortunately Linux avoids
>> mounting the truncated partitions.)
> 
> For debugging issues like this, usbmon is your friend.

OK, quoted below is usbmon for donnection and disconnection through the JMicron 20337.

Do you also need usbmon for the JMicron JMS539 which is handled properly?

Meanwhile I tested my Prolific bridge again too, with an additional PATA-to-SATA adapter.  Windows sees 3TB but Linux sees 800GB minus one block.  Do you need usbmon for that?

usbmon for the JMicron 20337 is around 2000 lines, which seemed like enough for one mail message.

eccac500 3637920462 S Ci:2:001:0 s a3 00 0000 0001 0004 4 <
eccac500 3637920476 C Ci:2:001:0 0 4 = 07050000
eccac500 3637920480 S Ci:2:001:0 s a3 00 0000 0002 0004 4 <
eccac500 3637920487 C Ci:2:001:0 0 4 = 00010000
eccac500 3637920489 S Ci:2:001:0 s a3 00 0000 0003 0004 4 <
eccac500 3637920495 C Ci:2:001:0 0 4 = 00010000
f43ed380 3637920497 S Ii:2:001:1 -115:2048 4 <
f43ed380 3640121357 C Ii:2:001:1 -2:2048 0
f1cdf480 3640121365 S Ci:2:001:0 s a3 00 0000 0001 0004 4 <
f1cdf480 3640121480 C Ci:2:001:0 0 4 = 03050400
f1cdf480 3640121484 S Ci:2:001:0 s a3 00 0000 0002 0004 4 <
(Continue reading)

Alan Stern | 2 May 22:37 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Wed, 2 May 2012, Norman Diamond wrote:

> Alan Stern wrote:
> > On Tue, 1 May 2012, Norman Diamond wrote:
> >> When a 3TB SATA drive is connected through a JMicron JMS539 (USB3.0
> >> to SATA Bridge, 152d:0539), Windows sees 3TB and Linux sees 3TB.
> >> 
> >> When the same drive is connected through a JMicron 20337 (152d:2338),
> >> Windows sees 3TB but Linux sees 800GB. (Fortunately Linux avoids
> >> mounting the truncated partitions.)
> > 
> > For debugging issues like this, usbmon is your friend.
> 
> OK, quoted below is usbmon for donnection and disconnection through
> the JMicron 20337.
> 
> Do you also need usbmon for the JMicron JMS539 which is handled properly?

No.

> Meanwhile I tested my Prolific bridge again too, with an additional
> PATA-to-SATA adapter.  Windows sees 3TB but Linux sees 800GB minus
> one block.  Do you need usbmon for that?

Probably the two bridges have the same bug.

> usbmon for the JMicron 20337 is around 2000 lines, which seemed like
> enough for one mail message.

Here's the interesting part:
(Continue reading)

Norman Diamond | 3 May 01:32 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Alan Stern wrote:
> On Wed, 2 May 2012, Norman Diamond wrote:
>> OK, quoted below is usbmon for donnection and disconnection through
>> the JMicron 20337.
>> 
>> Do you also need usbmon for the JMicron JMS539 which is handled properly?
> 
> No.
> 
>> Meanwhile I tested my Prolific bridge again too, with an additional
>> PATA-to-SATA adapter.  Windows sees 3TB but Linux sees 800GB minus
>> one block.  Do you need usbmon for that?
> 
> Probably the two bridges have the same bug.

I agree, "Probably".

>> usbmon for the JMicron 20337 is around 2000 lines, which seemed like
>> enough for one mail message.
> 
> Here's the interesting part:
> 
>> edb17580 3641398166 S Bo:2:003:2 -115 31 = 55534243 03000000 08000000 80000a25 00000000 00000000
00000000 000000
>> edb17580 3641398233 C Bo:2:003:2 0 31 >
>> edb17c80 3641398246 S Bi:2:003:1 -115 8 <
>> edb17c80 3641398357 C Bi:2:003:1 0 8 = 5d50a3af 00000200
>> edb17580 3641398444 S Bi:2:003:1 -115 13 <
>> edb17580 3641398608 C Bi:2:003:1 0 13 = 55534253 03000000 00000000 00
> 
(Continue reading)

Alan Stern | 3 May 03:12 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, 3 May 2012, Norman Diamond wrote:

> >> Meanwhile I tested my Prolific bridge again too, with an additional
> >> PATA-to-SATA adapter. Windows sees 3TB but Linux sees 800GB minus
> >> one block. Do you need usbmon for that?
> > 
> > Probably the two bridges have the same bug.
> 
> I agree, "Probably".

If you want to find out for certain, collect a usbmon trace with the 
Prolific bridge.

> > It looks like the bridge is sending just the least-significant 32 bits 
> > of the capacity. What it should have done is reply with 0xffffffff. 
> > Then the kernel would know to try again with a READ CAPACITY(16) 
> > command, which is capable of retrieving values larger than 32 bits.
> 
> You are right, bridges' failures to reply with 0xffffffff are
> bridges' bugs.  Obviously Windows proceeded to try a READ
> CAPACITY(16) regardless.

Don't be so sure.  I have seen reports from others indicating quite 
clearly that Windows would believe a partition table even when it 
contradicted a device's reported capacity.  For example, early card 
readers can handle SD cards but not SDHC.  When an SDHC card is 
inserted in such a reader, the reported capacity is too small.  Windows 
would nevertheless believe the partition information.  Interestingly, 
when the user would try to repartition the card, Windows would not 
allow a new partition to exceed the reported capacity.
(Continue reading)

Norman Diamond | 3 May 04:45 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Alan Stern wrote:
> On Thu, 3 May 2012, Norman Diamond wrote:
>>> It looks like the bridge is sending just the least-significant 32 bits 
>>> of the capacity.  What it should have done is reply with 0xffffffff. 
>>> Then the kernel would know to try again with a READ CAPACITY(16) 
>>> command, which is capable of retrieving values larger than 32 bits.
>> 
>> You are right, bridges' failures to reply with 0xffffffff are
>> bridges' bugs.  Obviously Windows proceeded to try a READ
>> CAPACITY(16) regardless.
> 
> Don't be so sure.  I have seen reports from others indicating quite 
> clearly that Windows would believe a partition table even when it 
> contradicted a device's reported capacity.

Yes, but Windows didn't see the entire asserted partition, Windows saw the reported size of the drive and
the asserted size the partition and the accessible area of the partition.

In the test mentioned here, Windows saw the entire drive size, which had to come from READ CAPACITY(16).

As mentioned earlier in this thread, in an earlier test I had taken a drive that had an NTFS partition and had
subsequently been DCO'ed down to a size that truncated the NTFS partition.  Windows saw the drive's
reported size, saw the partition table, and refused to mount the partition.  In that situation the DCO had
cut off part of the NTFS structure that is mirrored at the end of the partition so Windows knew that the
partition was not properly accessible.

I have another different bridge, incredibly stupidly convolutedly designed to break its eSATA
capability but with working USB3 capability.  When using that incredibly stupidly convolutedly broken
eSATA capability, Windows did not see the entire drive size.  Windows saw the partition table but could not
access partitions that were located beyond the visible drive size.
(Continue reading)

Alan Stern | 3 May 22:08 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, 3 May 2012, Norman Diamond wrote:

> Alan Stern wrote:
> > On Thu, 3 May 2012, Norman Diamond wrote:
> >>> It looks like the bridge is sending just the least-significant 32 bits 
> >>> of the capacity.  What it should have done is reply with 0xffffffff. 
> >>> Then the kernel would know to try again with a READ CAPACITY(16) 
> >>> command, which is capable of retrieving values larger than 32 bits.
> >> 
> >> You are right, bridges' failures to reply with 0xffffffff are
> >> bridges' bugs. Obviously Windows proceeded to try a READ
> >> CAPACITY(16) regardless.
> > 
> > Don't be so sure. I have seen reports from others indicating quite 
> > clearly that Windows would believe a partition table even when it 
> > contradicted a device's reported capacity.
> 
> Yes, but Windows didn't see the entire asserted partition, Windows
> saw the reported size of the drive and the asserted size the
> partition and the accessible area of the partition.

Presumably you are referring here to your own experience rather the
reports from others mentioned above.

> In the test mentioned here, Windows saw the entire drive size, which
> had to come from READ CAPACITY(16).

Perhaps so.  I'd feel a lot more confident about that conclusion if
there was a USB trace.

(Continue reading)

Norman Diamond | 4 May 00:21 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Alan Stern wrote:
> On Thu, 3 May 2012, Norman Diamond wrote:
>> Alan Stern wrote:
>>> On Thu, 3 May 2012, Norman Diamond wrote:
>>>>> It looks like the bridge is sending just the least-significant 32 bits 
>>>>> of the capacity.  What it should have done is reply with 0xffffffff. 
>>>>> Then the kernel would know to try again with a READ CAPACITY(16) 
>>>>> command, which is capable of retrieving values larger than 32 bits.
>>>> 
>>>> You are right, bridges' failures to reply with 0xffffffff are
>>>> bridges' bugs.  Obviously Windows proceeded to try a READ
>>>> CAPACITY(16) regardless.
>>> 
>>> Don't be so sure.  I have seen reports from others indicating quite 
>>> clearly that Windows would believe a partition table even when it 
>>> contradicted a device's reported capacity.
>> 
>> Yes, but Windows didn't see the entire asserted partition, Windows
>> saw the reported size of the drive and the asserted size the
>> partition and the accessible area of the partition.
> 
> Presumably you are referring here to your own experience rather the
> reports from others mentioned above.

There is no contradiction.  I observed that Windows saw the asserted size of the partition, and that Windows
used the accessible area of the partition when such use was not prevented by truncation at the drive's
reported capacity.

When Windows needed to access the trailing sectors of the partition but they were inaccessible due to the
drive being smaller, Windows did not mount the partition.  Now this part of it is my experience, but you
(Continue reading)

Alan Stern | 4 May 16:27 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Fri, 4 May 2012, Norman Diamond wrote:

> Alan Stern wrote:
> > On Thu, 3 May 2012, Norman Diamond wrote:
> >> Alan Stern wrote:
> >>> On Thu, 3 May 2012, Norman Diamond wrote:
> >>>>> It looks like the bridge is sending just the least-significant 32 bits 
> >>>>> of the capacity. What it should have done is reply with 0xffffffff. 
> >>>>> Then the kernel would know to try again with a READ CAPACITY(16) 
> >>>>> command, which is capable of retrieving values larger than 32 bits.
> >>>> 
> >>>> You are right, bridges' failures to reply with 0xffffffff are
> >>>> bridges' bugs.  Obviously Windows proceeded to try a READ
> >>>> CAPACITY(16) regardless.
> >>> 
> >>> Don't be so sure.  I have seen reports from others indicating quite 
> >>> clearly that Windows would believe a partition table even when it 
> >>> contradicted a device's reported capacity.
> >> 
> >> Yes, but Windows didn't see the entire asserted partition, Windows
> >> saw the reported size of the drive and the asserted size the
> >> partition and the accessible area of the partition.
> > 
> > Presumably you are referring here to your own experience rather the
> > reports from others mentioned above.
> 
> There is no contradiction.  I observed that Windows saw the asserted
> size of the partition, and that Windows used the accessible area of
> the partition when such use was not prevented by truncation at the
> drive's reported capacity.
(Continue reading)

Reartes Guillermo | 5 May 00:49 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Hi all,

I also have one "JMicron Technology Corp. / JMicron USA Technology
Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge (152d:2338)

Sadly, i do not have any 3 tb hard disk.
If there is something i can do to help with the quirks handling of
these devices, please tell.
I just tested with a spare old hdd, with no important data. I have
other bigger hard disks.

# sg_raw -r 32 /dev/sg2 9e 10 0 0 0 0 0 0 0 0 0 0 0 20 0 0
SCSI Status: Good

Sense Information:
sense buffer empty

Received 32 bytes of data:
 00     00 00 00 00 0d f9 4b af  00 00 02 00 00 00 00 00    ......K.........
 10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................

usb 1-2: new high speed USB device using ehci_hcd and address 5
usb 1-2: configuration #1 chosen from 1 choice
scsi13 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
  Vendor: WDC WD12  Model: 00JS-00MHB0       Rev:
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sdc: 234441648 512-byte hdwr sectors (120034 MB)
sdc: Write Protect is off
(Continue reading)

Norman Diamond | 7 May 07:02 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

 =====
DO NOT PATCH IT THIS WAY!
 =====

--- On Fri, 2012/5/4, Alan Stern <stern@...> wrote:
> On Thu, 3 May 2012, Norman Diamond wrote:
>> Alan Stern wrote:
>>> On Thu, 3 May 2012, Norman Diamond wrote:
>>>>> It looks like the bridge is sending just the least-significant 32 bits 
>>>>> of the capacity.  What it should have done is reply with 0xffffffff. 
>>>>> Then the kernel would know to try again with a READ CAPACITY(16) 
>>>>> command, which is capable of retrieving values larger than 32 bits.
>>>> 
>>>> You are right, bridges' failures to reply with 0xffffffff are
>>>> bridges' bugs.  Obviously Windows proceeded to try a READ
>>>> CAPACITY(16) regardless.
>>> 
>>> Don't be so sure.

I am pretty sure that Windows XP did not try a READ CAPACITY(16) in that case but Windows 7 did.  I cannot be
completely sure because I found two free USB snoopers, one of which worked on Windows XP but is documented
as not working on Windows 7, and one of which didn't even work on Windows XP or at least did not work as
documented.  But it doesn't matter.  At least two broken bridges are broken worse than that.

Quoting your proposed patch for the purpose of discussion:

> Index: usb-3.4/drivers/scsi/sd.c
> ===================================================================
> --- usb-3.4.orig/drivers/scsi/sd.c
> +++ usb-3.4/drivers/scsi/sd.c
(Continue reading)

Alan Stern | 7 May 16:36 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Mon, 7 May 2012, Norman Diamond wrote:

>  =====
> DO NOT PATCH IT THIS WAY!
>  =====

I wasn't going to.  :-)  That was just for purposes of testing.

> I am pretty sure that Windows XP did not try a READ CAPACITY(16) in
> that case but Windows 7 did.  I cannot be completely sure because I
> found two free USB snoopers, one of which worked on Windows XP but is
> documented as not working on Windows 7, and one of which didn't even
> work on Windows XP or at least did not work as documented.  But it
> doesn't matter.  At least two broken bridges are broken worse than
> that.
> 
> Quoting your proposed patch for the purpose of discussion:
> 
> > Index: usb-3.4/drivers/scsi/sd.c
> > ===================================================================
> > --- usb-3.4.orig/drivers/scsi/sd.c
> > +++ usb-3.4/drivers/scsi/sd.c
> >  <at>  <at>  -1902,7 +1902,7  <at>  <at>  static int sd_try_rc16_first(struct scsi
> >    return 1;
> >   if (scsi_device_protection(sdp))
> >    return 1;
> > - return 0;
> > + return 1;
> >  }
> >  
(Continue reading)

Norman Diamond | 8 May 01:00 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Mon, 2012/5/7, Alan Stern wrote:
> On Mon, 7 May 2012, Norman Diamond wrote:
>> I am pretty sure that Windows XP did not try a READ CAPACITY(16) in
>> that case but Windows 7 did.  I cannot be completely sure because I
>> found two free USB snoopers, one of which worked on Windows XP but is
>> documented as not working on Windows 7, and one of which didn't even
>> work on Windows XP or at least did not work as documented.  But it
>> doesn't matter.  At least two broken bridges are broken worse than
>> that.
>> 
>> Quoting your proposed patch for the purpose of discussion:
>> 
>>> Index: usb-3.4/drivers/scsi/sd.c
>>> ===================================================================
>>> --- usb-3.4.orig/drivers/scsi/sd.c
>>> +++ usb-3.4/drivers/scsi/sd.c
>>>  <at>  <at>  -1902,7 +1902,7  <at>  <at>  static int sd_try_rc16_first(struct scsi
>>>          return 1;
>>>      if (scsi_device_protection(sdp))
>>>          return 1;
>>> -    return 0;
>>> +    return 1;
>>>  }
>>>  
>>>  /*
>>> 
>>> 
>> 
> > That accords with what I think Windows does.
> 
(Continue reading)

Alan Stern | 8 May 04:59 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Tue, 8 May 2012, Norman Diamond wrote:

> In my case there is no other way that a host (PC or other, any OS or
> driver) could obtain a reported capacity past the 2.2TB mark.  
> Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of
> an ATA Identify command though I haven't seen one.

There definitely are some bridges which handle ATA passthru correctly.

> >> I have a feeling we have to do both READ CAPACITY(10) and READ
> >> CAPACITY(16), and if we see wraparound then we should either truncate
> >> the drive to 2.2TB or avoid the drive entirely. I think truncation
> >> is safe enough at this point -- if a partition gets truncated then
> >> subsequent attempts to mount will fail, so any existing but
> >> inaccessible data will be safe from harm, while accessible data will
> >> be read and written correctly.
> > 
> > That sounds like the best approach. You would want to do this for all 
> > USB drives? Or only those known to be (S)ATA bridges?
> 
> I think it's needed with [S]ATA bridges, whether or not we know that
> they're bridges.  I think it's probably not needed with anything
> else, but it probably doesn't hurt to do it with anything else.  
> Therefore it's probably safest to do it with all USB drives.

Except that READ CAPACITY(16) might cause some buggy devices to crash.  
I guess there wasn't much point in asking the question...

Putting everything together, it looks like you're asking for three new 
flags:
(Continue reading)

Norman Diamond | 8 May 05:17 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Alan Stern wrote:
> On Tue, 8 May 2012, Norman Diamond wrote:
>> In my case there is no other way that a host (PC or other, any OS or
>> driver) could obtain a reported capacity past the 2.2TB mark.  
>> Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of
>> an ATA Identify command though I haven't seen one.
> 
> There definitely are some bridges which handle ATA passthru correctly.

Oh, please can you suggest some.  I search occasionally but have never found one that was described as
obeying ATA passthru.  Of course I can't command my users to use such bridges, but I would like to use one or two.

> Except that READ CAPACITY(16) might cause some buggy devices to crash.

Instead of rejecting the command as not handled?

> Putting everything together, it looks like you're asking for three new 
> flags:
> 
>     CAPACITY_10_AND_16: Issue both READ CAPACITY and READ 
>     CAPACITY(16), and if READ CAPACITY(16) gives a result > 2 TB 
>     and READ CAPACITY doesn't give 0xffffffff, truncate the size to 
>     2 TB;
> 
>     CAPACITY_HEURISTICS_63: Don't decrement the capacity if
>     the reported capacity is a multiple of 63, but otherwise behave
>     like CAPACITY_HEURISTICS;
> 
>     TEST_CAPACITY: Try to do a single-block read of the last 
>     reported block.
(Continue reading)

Alan Stern | 8 May 17:23 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Tue, 8 May 2012, Norman Diamond wrote:

> Alan Stern wrote:
> > On Tue, 8 May 2012, Norman Diamond wrote:
> >> In my case there is no other way that a host (PC or other, any OS or
> >> driver) could obtain a reported capacity past the 2.2TB mark. 
> >> Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of
> >> an ATA Identify command though I haven't seen one.
> > 
> > There definitely are some bridges which handle ATA passthru correctly.
> 
> Oh, please can you suggest some.  I search occasionally but have
> never found one that was described as obeying ATA passthru.  Of
> course I can't command my users to use such bridges, but I would like
> to use one or two.

The only ones I'm aware of are the entries marked with the SANE_SENSE
quirk in unusual_devs.h: the HP Personal Media Drive (03f0:070c), the
Genesys Logic bridge (05e3:0723), the Seagate FreeAgent Pro
(0bc2:3010), the Maxtor bridge (0d49:7310), the Western Digital bridge
(1058:0704), and a different JMicron bridge (152d:2329).  Of course,
the fact that the flag is set doesn't necessarily mean the device
really does have SAT support.

Ben, do you know of any other good examples?

> > Except that READ CAPACITY(16) might cause some buggy devices to crash.
> 
> Instead of rejecting the command as not handled?

(Continue reading)

Norman Diamond | 9 May 02:12 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Wed, 2012/5/9, Alan Stern wrote:
> On Tue, 8 May 2012, Norman Diamond wrote:
>> Alan Stern wrote:
>>> On Tue, 8 May 2012, Norman Diamond wrote:
>>>> In my case there is no other way that a host (PC or other, any OS or
>>>> driver) could obtain a reported capacity past the 2.2TB mark.  
>>>> Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of
>>>> an ATA Identify command though I haven't seen one.
>>> 
>>> There definitely are some bridges which handle ATA passthru correctly.
>> 
>> Oh, please can you suggest some.  I search occasionally but have
>> never found one that was described as obeying ATA passthru.  Of
>> course I can't command my users to use such bridges, but I would like
>> to use one or two.
> 
> The only ones I'm aware of are the entries marked with the SANE_SENSE
> quirk in unusual_devs.h: the HP Personal Media Drive (03f0:070c), the
> Genesys Logic bridge (05e3:0723), the Seagate FreeAgent Pro
> (0bc2:3010), the Maxtor bridge (0d49:7310), the Western Digital bridge
> (1058:0704), and a different JMicron bridge (152d:2329).  Of course,
> the fact that the flag is set doesn't necessarily mean the device
> really does have SAT support.

Among those, the Genesys and JMicron ones look like they have a chance of being used in adapters sold
separately from Seagate and Western Digital external drives.  By any chance do you know of cables or
docking stations that use them?

>>> Except that READ CAPACITY(16) might cause some buggy devices to crash.
>> 
(Continue reading)

Alan Stern | 9 May 16:37 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Wed, 9 May 2012, Norman Diamond wrote:

> >>> There definitely are some bridges which handle ATA passthru correctly.
> >> 
> >> Oh, please can you suggest some. I search occasionally but have
> >> never found one that was described as obeying ATA passthru. Of
> >> course I can't command my users to use such bridges, but I would like
> >> to use one or two.
> > 
> > The only ones I'm aware of are the entries marked with the SANE_SENSE
> > quirk in unusual_devs.h: the HP Personal Media Drive (03f0:070c), the
> > Genesys Logic bridge (05e3:0723), the Seagate FreeAgent Pro
> > (0bc2:3010), the Maxtor bridge (0d49:7310), the Western Digital bridge
> > (1058:0704), and a different JMicron bridge (152d:2329). Of course,
> > the fact that the flag is set doesn't necessarily mean the device
> > really does have SAT support.
> 
> Among those, the Genesys and JMicron ones look like they have a
> chance of being used in adapters sold separately from Seagate and
> Western Digital external drives.  By any chance do you know of cables
> or docking stations that use them?

Unfortunately I don't.  Maybe somebody on the mailing list can suggest 
something.

> >>>  CAPACITY_10_AND_16: Issue both READ CAPACITY and READ 
> >>>  CAPACITY(16), and if READ CAPACITY(16) gives a result > 2 TB 
> >>>  and READ CAPACITY doesn't give 0xffffffff, truncate the size to 
> >>>  2 TB;
> >>> 
(Continue reading)

Alon Bar-Lev | 30 Aug 11:07 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB


Hello,

Is there anything new in this regard?
I have the same issue with 3T drive.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alan Stern | 30 Aug 16:29 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, 30 Aug 2012, Alon Bar-Lev wrote:

> Hello,
> 
> Is there anything new in this regard?
> I have the same issue with 3T drive.

What are you referring to?  What issue?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alon Bar-Lev | 30 Aug 19:25 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, Aug 30, 2012 at 5:29 PM, Alan Stern
<stern@...> wrote:
>
> On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>
> > Hello,
> >
> > Is there anything new in this regard?
> > I have the same issue with 3T drive.
>
> What are you referring to?  What issue?
>
> Alan Stern
>

Thanks for replying!

This[1] thread.

I am experiencing the same issue, and could not understand if this is
software or hardware issue.

Regards,
Alon Bar-Lev.

[1] http://comments.gmane.org/gmane.linux.usb.general/62798
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Alan Stern | 30 Aug 20:49 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, 30 Aug 2012, Alon Bar-Lev wrote:

> On Thu, Aug 30, 2012 at 5:29 PM, Alan Stern
<stern@...> wrote:
> >
> > On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
> >
> > > Hello,
> > >
> > > Is there anything new in this regard?
> > > I have the same issue with 3T drive.
> >
> > What are you referring to?  What issue?
> >
> > Alan Stern
> >
> 
> Thanks for replying!
> 
> This[1] thread.
> 
> I am experiencing the same issue, and could not understand if this is
> software or hardware issue.
> 
> Regards,
> Alon Bar-Lev.
> 
> [1] http://comments.gmane.org/gmane.linux.usb.general/62798

In the end it turns out to be caused by problems in both software and 
(Continue reading)

Alon Bar-Lev | 30 Aug 20:55 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, Aug 30, 2012 at 9:49 PM, Alan Stern
<stern@...> wrote:
> On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>
>> On Thu, Aug 30, 2012 at 5:29 PM, Alan Stern
<stern@...> wrote:
>> >
>> > On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>> >
>> > > Hello,
>> > >
>> > > Is there anything new in this regard?
>> > > I have the same issue with 3T drive.
>> >
>> > What are you referring to?  What issue?
>> >
>> > Alan Stern
>> >
>>
>> Thanks for replying!
>>
>> This[1] thread.
>>
>> I am experiencing the same issue, and could not understand if this is
>> software or hardware issue.
>>
>> Regards,
>> Alon Bar-Lev.
>>
>> [1] http://comments.gmane.org/gmane.linux.usb.general/62798
(Continue reading)

Alan Stern | 30 Aug 22:28 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, 30 Aug 2012, Alon Bar-Lev wrote:

> On Thu, Aug 30, 2012 at 9:49 PM, Alan Stern
<stern@...> wrote:
> > On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
> >
> >> On Thu, Aug 30, 2012 at 5:29 PM, Alan Stern
<stern@...> wrote:
> >> >
> >> > On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
> >> >
> >> > > Hello,
> >> > >
> >> > > Is there anything new in this regard?
> >> > > I have the same issue with 3T drive.
> >> >
> >> > What are you referring to?  What issue?
> >> >
> >> > Alan Stern
> >> >
> >>
> >> Thanks for replying!
> >>
> >> This[1] thread.
> >>
> >> I am experiencing the same issue, and could not understand if this is
> >> software or hardware issue.
> >>
> >> Regards,
> >> Alon Bar-Lev.
(Continue reading)

Alon Bar-Lev | 30 Aug 22:35 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, Aug 30, 2012 at 11:28 PM, Alan Stern
<stern@...> wrote:
> On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>
>> On Thu, Aug 30, 2012 at 9:49 PM, Alan Stern
<stern@...> wrote:
>> > On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>> >
>> >> On Thu, Aug 30, 2012 at 5:29 PM, Alan Stern
<stern@...> wrote:
>> >> >
>> >> > On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>> >> >
>> >> > > Hello,
>> >> > >
>> >> > > Is there anything new in this regard?
>> >> > > I have the same issue with 3T drive.
>> >> >
>> >> > What are you referring to?  What issue?
>> >> >
>> >> > Alan Stern
>> >> >
>> >>
>> >> Thanks for replying!
>> >>
>> >> This[1] thread.
>> >>
>> >> I am experiencing the same issue, and could not understand if this is
>> >> software or hardware issue.
>> >>
(Continue reading)

Alan Stern | 30 Aug 22:47 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, 30 Aug 2012, Alon Bar-Lev wrote:

> Thank you!
> 
> I will test this and report back.
> 
> As this is in scsi layer, I guess it does not get the USB
> vendor:product to automatically apply this workaround... :(

I don't entirely understand this comment.  But it is true that the
patch will affect every USB storage device, not just the JMicron 20337.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alon Bar-Lev | 30 Aug 22:56 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, Aug 30, 2012 at 11:47 PM, Alan Stern
<stern@...> wrote:
> On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>
>> Thank you!
>>
>> I will test this and report back.
>>
>> As this is in scsi layer, I guess it does not get the USB
>> vendor:product to automatically apply this workaround... :(
>
> I don't entirely understand this comment.  But it is true that the
> patch will affect every USB storage device, not just the JMicron 20337.
>
> Alan Stern
>

I was trying to figure out if there can be automatic workaround based
on USB vendor:product... If these exposed at this point then a patch
can be written to effect only this device.

I never traced the scsi module, but scsi_device does contain vendor,
model and rev, maybe these can be mapped to the JMicron 20337 device
and apply the workaround.

Just a though...

Thank you very much,
Alon
--
(Continue reading)

Alan Stern | 30 Aug 23:08 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Thu, 30 Aug 2012, Alon Bar-Lev wrote:

> I was trying to figure out if there can be automatic workaround based
> on USB vendor:product... If these exposed at this point then a patch
> can be written to effect only this device.
> 
> I never traced the scsi module, but scsi_device does contain vendor,
> model and rev, maybe these can be mapped to the JMicron 20337 device
> and apply the workaround.

Such a patch can be written.  It would be more complicated than the 
one I sent you, though, and I wanted to try the easier patch first.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alon Bar-Lev | 2 Sep 10:56 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Fri, Aug 31, 2012 at 12:08 AM, Alan Stern
<stern@...> wrote:
>
> On Thu, 30 Aug 2012, Alon Bar-Lev wrote:
>
> > I was trying to figure out if there can be automatic workaround based
> > on USB vendor:product... If these exposed at this point then a patch
> > can be written to effect only this device.
> >
> > I never traced the scsi module, but scsi_device does contain vendor,
> > model and rev, maybe these can be mapped to the JMicron 20337 device
> > and apply the workaround.
>
> Such a patch can be written.  It would be more complicated than the
> one I sent you, though, and I wanted to try the easier patch first.
>
> Alan Stern
>

I modified the patch to the following to make sure my main disk is unaffected:
---
--- drivers/scsi/sd.c   2012-07-21 23:58:29.000000000 +0300
+++ drivers/scsi/sd.c.new       2012-08-31 19:47:15.822632952 +0300
 <at>  <at>  -1899,13 +1899,17  <at>  <at>  static int sd_try_rc16_first(struct scsi
 {
        if (sdp->host->max_cmd_len < 16)
                return 0;
-       if (sdp->try_rc_10_first)
-               return 0;
+       if (sdp->try_rc_10_first) {
(Continue reading)

Alan Stern | 2 Sep 15:59 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, 2 Sep 2012, Alon Bar-Lev wrote:

> I modified the patch to the following to make sure my main disk is unaffected:

> This is what I get now, I guess detection is good now, but something
> in the IO is wrong, when plugged to computer's sata it works
> correctly.
> 
> ---
> Sep  2 11:42:55 localhost kernel: Initializing USB Mass Storage driver...
> Sep  2 11:42:55 localhost kernel: scsi6 : usb-storage 2-1.1:1.0
> Sep  2 11:42:55 localhost kernel: usbcore: registered new interface
> driver usb-storage
> Sep  2 11:42:55 localhost kernel: USB Mass Storage support registered.
> Sep  2 11:42:56 localhost kernel: scsi 6:0:0:0: Direct-Access     WDC
> WD30 EZRX-00MMMB0          PQ: 0 ANSI: 5
> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
> Sep  2 11:42:56 localhost kernel:  <at> ALON: apply workaround 1
> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] 5860533168
> 512-byte logical blocks: (3.00 TB/2.72 TiB)

Is this the same as the number of blocks you get when the drive is
plugged into a SATA port?

> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 28 00 00 00
> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present
> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive
> cache: write through
> Sep  2 11:42:56 localhost kernel:  <at> ALON: apply workaround 1
(Continue reading)

Alon Bar-Lev | 2 Sep 16:09 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, Sep 2, 2012 at 4:59 PM, Alan Stern <stern@...> wrote:
> On Sun, 2 Sep 2012, Alon Bar-Lev wrote:
>
>> I modified the patch to the following to make sure my main disk is unaffected:
>
>> This is what I get now, I guess detection is good now, but something
>> in the IO is wrong, when plugged to computer's sata it works
>> correctly.
>>
>> ---
>> Sep  2 11:42:55 localhost kernel: Initializing USB Mass Storage driver...
>> Sep  2 11:42:55 localhost kernel: scsi6 : usb-storage 2-1.1:1.0
>> Sep  2 11:42:55 localhost kernel: usbcore: registered new interface
>> driver usb-storage
>> Sep  2 11:42:55 localhost kernel: USB Mass Storage support registered.
>> Sep  2 11:42:56 localhost kernel: scsi 6:0:0:0: Direct-Access     WDC
>> WD30 EZRX-00MMMB0          PQ: 0 ANSI: 5
>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
>> Sep  2 11:42:56 localhost kernel:  <at> ALON: apply workaround 1
>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] 5860533168
>> 512-byte logical blocks: (3.00 TB/2.72 TiB)
>
> Is this the same as the number of blocks you get when the drive is
> plugged into a SATA port?
>
>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 28 00 00 00
>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present
>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Assuming drive
>> cache: write through
(Continue reading)

Alon Bar-Lev | 2 Sep 16:57 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, Sep 2, 2012 at 5:09 PM, Alon Bar-Lev <alon.barlev@...> wrote:
> On Sun, Sep 2, 2012 at 4:59 PM, Alan Stern
<stern@...> wrote:
>> On Sun, 2 Sep 2012, Alon Bar-Lev wrote:
>>
>>> I modified the patch to the following to make sure my main disk is unaffected:
>>
>>> This is what I get now, I guess detection is good now, but something
>>> in the IO is wrong, when plugged to computer's sata it works
>>> correctly.
>>>
>>> ---
>>> Sep  2 11:42:55 localhost kernel: Initializing USB Mass Storage driver...
>>> Sep  2 11:42:55 localhost kernel: scsi6 : usb-storage 2-1.1:1.0
>>> Sep  2 11:42:55 localhost kernel: usbcore: registered new interface
>>> driver usb-storage
>>> Sep  2 11:42:55 localhost kernel: USB Mass Storage support registered.
>>> Sep  2 11:42:56 localhost kernel: scsi 6:0:0:0: Direct-Access     WDC
>>> WD30 EZRX-00MMMB0          PQ: 0 ANSI: 5
>>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
>>> Sep  2 11:42:56 localhost kernel:  <at> ALON: apply workaround 1
>>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] 5860533168
>>> 512-byte logical blocks: (3.00 TB/2.72 TiB)
>>
>> Is this the same as the number of blocks you get when the drive is
>> plugged into a SATA port?
>>
>>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
>>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 28 00 00 00
>>> Sep  2 11:42:56 localhost kernel: sd 6:0:0:0: [sdb] No Caching mode page present
(Continue reading)

Alan Stern | 2 Sep 17:47 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, 2 Sep 2012, Alon Bar-Lev wrote:

> Attached usbmon, I hope I've done this OK.

The errors start here:

> ffff880112a12d80 3034504955 S Bo:2:009:2 -115 31 = 55534243 0a000000 00100000 80000a28 00000000
00000008 00000000 000000
> ffff880112a12d80 3034505013 C Bo:2:009:2 0 31 >
> ffff880132074d80 3034505019 S Bi:2:009:1 -115 4096 <
> ffff880132074d80 3034505155 C Bi:2:009:1 -32 0
> ffff880112a12d80 3034505161 S Co:2:009:0 s 02 01 0000 0081 0000 0
> ffff880112a12d80 3034505298 C Co:2:009:0 0 0
> ffff880112a12d80 3034505308 S Bi:2:009:1 -115 13 <
> ffff880112a12d80 3034505441 C Bi:2:009:1 0 13 = 55534253 0a000000 00000000 02

This shows the computer asking the drive to read 8 blocks starting at
block 0.  The drive (actually the JMicron USB interface, not the drive
itself) returns an error code indicating that it thinks the command 
was not sent properly -- even though it was.

I don't understand why the JMicron unit doesn't accept this command.  
It simply appears to be broken.  Does it work if you plug it into a 
computer running Windows or Mac OS X?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
(Continue reading)

Alon Bar-Lev | 2 Sep 19:57 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, Sep 2, 2012 at 6:47 PM, Alan Stern <stern@...> wrote:
>
> On Sun, 2 Sep 2012, Alon Bar-Lev wrote:
>
> > Attached usbmon, I hope I've done this OK.
>
> The errors start here:
>
> > ffff880112a12d80 3034504955 S Bo:2:009:2 -115 31 = 55534243 0a000000
> > 00100000 80000a28 00000000 00000008 00000000 000000
> > ffff880112a12d80 3034505013 C Bo:2:009:2 0 31 >
> > ffff880132074d80 3034505019 S Bi:2:009:1 -115 4096 <
> > ffff880132074d80 3034505155 C Bi:2:009:1 -32 0
> > ffff880112a12d80 3034505161 S Co:2:009:0 s 02 01 0000 0081 0000 0
> > ffff880112a12d80 3034505298 C Co:2:009:0 0 0
> > ffff880112a12d80 3034505308 S Bi:2:009:1 -115 13 <
> > ffff880112a12d80 3034505441 C Bi:2:009:1 0 13 = 55534253 0a000000
> > 00000000 02
>
> This shows the computer asking the drive to read 8 blocks starting at
> block 0.  The drive (actually the JMicron USB interface, not the drive
> itself) returns an error code indicating that it thinks the command
> was not sent properly -- even though it was.
>
> I don't understand why the JMicron unit doesn't accept this command.
> It simply appears to be broken.  Does it work if you plug it into a
> computer running Windows or Mac OS X?
>
> Alan Stern
>
(Continue reading)

Alon Bar-Lev | 2 Sep 20:07 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, Sep 2, 2012 at 8:57 PM, Alon Bar-Lev <alon.barlev@...> wrote:
> On Sun, Sep 2, 2012 at 6:47 PM, Alan Stern
<stern@...> wrote:
>>
>> On Sun, 2 Sep 2012, Alon Bar-Lev wrote:
>>
>> > Attached usbmon, I hope I've done this OK.
>>
>> The errors start here:
>>
>> > ffff880112a12d80 3034504955 S Bo:2:009:2 -115 31 = 55534243 0a000000
>> > 00100000 80000a28 00000000 00000008 00000000 000000
>> > ffff880112a12d80 3034505013 C Bo:2:009:2 0 31 >
>> > ffff880132074d80 3034505019 S Bi:2:009:1 -115 4096 <
>> > ffff880132074d80 3034505155 C Bi:2:009:1 -32 0
>> > ffff880112a12d80 3034505161 S Co:2:009:0 s 02 01 0000 0081 0000 0
>> > ffff880112a12d80 3034505298 C Co:2:009:0 0 0
>> > ffff880112a12d80 3034505308 S Bi:2:009:1 -115 13 <
>> > ffff880112a12d80 3034505441 C Bi:2:009:1 0 13 = 55534253 0a000000
>> > 00000000 02
>>
>> This shows the computer asking the drive to read 8 blocks starting at
>> block 0.  The drive (actually the JMicron USB interface, not the drive
>> itself) returns an error code indicating that it thinks the command
>> was not sent properly -- even though it was.
>>
>> I don't understand why the JMicron unit doesn't accept this command.
>> It simply appears to be broken.  Does it work if you plug it into a
>> computer running Windows or Mac OS X?
>>
(Continue reading)

Alan Stern | 2 Sep 22:57 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, 2 Sep 2012, Alon Bar-Lev wrote:

> > This shows the computer asking the drive to read 8 blocks starting at
> > block 0.  The drive (actually the JMicron USB interface, not the drive
> > itself) returns an error code indicating that it thinks the command
> > was not sent properly -- even though it was.
> >
> > I don't understand why the JMicron unit doesn't accept this command.
> > It simply appears to be broken.  Does it work if you plug it into a
> > computer running Windows or Mac OS X?
> >
> > Alan Stern
> >
> 
> Hi,
> 
> I don't know... I don't use these... and the disk is ext4...
> 
> I have XP in qemu, I mapped the device and took usbmon (attached), so
> you probably see plugin within Linux, the plugout, then windows takes
> charge.
> 
> I see the disk in device manager, but not in disk manager... don't know why.
> 
> Maybe this will help...

Yes, this shows what the problem is.  It's a bug in the JMicron device.

The usbmon trace shows that Windows uses READ FORMAT CAPACITIES and 
READ CAPACITY(10) commands to determine the size of the drive.  These 
(Continue reading)

Alon Bar-Lev | 3 Sep 08:04 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, Sep 2, 2012 at 11:57 PM, Alan Stern
<stern@...> wrote:
> On Sun, 2 Sep 2012, Alon Bar-Lev wrote:
>
>> > This shows the computer asking the drive to read 8 blocks starting at
>> > block 0.  The drive (actually the JMicron USB interface, not the drive
>> > itself) returns an error code indicating that it thinks the command
>> > was not sent properly -- even though it was.
>> >
>> > I don't understand why the JMicron unit doesn't accept this command.
>> > It simply appears to be broken.  Does it work if you plug it into a
>> > computer running Windows or Mac OS X?
>> >
>> > Alan Stern
>> >
>>
>> Hi,
>>
>> I don't know... I don't use these... and the disk is ext4...
>>
>> I have XP in qemu, I mapped the device and took usbmon (attached), so
>> you probably see plugin within Linux, the plugout, then windows takes
>> charge.
>>
>> I see the disk in device manager, but not in disk manager... don't know why.
>>
>> Maybe this will help...
>
> Yes, this shows what the problem is.  It's a bug in the JMicron device.
>
(Continue reading)

Alan Stern | 4 Sep 16:25 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Sun, 2 Sep 2012, Alon Bar-Lev wrote:

> I modified the patch to the following to make sure my main disk is unaffected:
> ---
> --- drivers/scsi/sd.c   2012-07-21 23:58:29.000000000 +0300
> +++ drivers/scsi/sd.c.new       2012-08-31 19:47:15.822632952 +0300
>  <at>  <at>  -1899,13 +1899,17  <at>  <at>  static int sd_try_rc16_first(struct scsi
>  {
>         if (sdp->host->max_cmd_len < 16)
>                 return 0;
> -       if (sdp->try_rc_10_first)
> -               return 0;
> +       if (sdp->try_rc_10_first) {
> +               printk(" <at> ALON: apply workaround 1");
> +               /*return 0;*/
> +       }
>         if (sdp->scsi_level > SCSI_SPC_2)
>                 return 1;
>         if (scsi_device_protection(sdp))
>                 return 1;
> -       return 0;
> +       printk(" <at> ALON: apply workaround 2");
> +       /*return 0;*/
> +       return 1;
>  }

If you still have the JMicron device, can you post a usbmon trace
showing what happens without any patches at all?  I'm curious to see
how the device gets handled.

(Continue reading)

Alon Bar-Lev | 4 Sep 16:32 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Tue, Sep 4, 2012 at 5:25 PM, Alan Stern <stern@...> wrote:
>
> On Sun, 2 Sep 2012, Alon Bar-Lev wrote:
>
> > I modified the patch to the following to make sure my main disk is
> > unaffected:
> > ---
> > --- drivers/scsi/sd.c   2012-07-21 23:58:29.000000000 +0300
> > +++ drivers/scsi/sd.c.new       2012-08-31 19:47:15.822632952 +0300
> >  <at>  <at>  -1899,13 +1899,17  <at>  <at>  static int sd_try_rc16_first(struct scsi
> >  {
> >         if (sdp->host->max_cmd_len < 16)
> >                 return 0;
> > -       if (sdp->try_rc_10_first)
> > -               return 0;
> > +       if (sdp->try_rc_10_first) {
> > +               printk(" <at> ALON: apply workaround 1");
> > +               /*return 0;*/
> > +       }
> >         if (sdp->scsi_level > SCSI_SPC_2)
> >                 return 1;
> >         if (scsi_device_protection(sdp))
> >                 return 1;
> > -       return 0;
> > +       printk(" <at> ALON: apply workaround 2");
> > +       /*return 0;*/
> > +       return 1;
> >  }
>
> If you still have the JMicron device, can you post a usbmon trace
(Continue reading)

Alon Bar-Lev | 6 Sep 11:42 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

On Tue, Sep 4, 2012 at 5:32 PM, Alon Bar-Lev <alon.barlev@...> wrote:
> Going to try out this one[1][2], but now I go to the store and test it
> on site before buying.
>
> Alon
>
> [1] http://a.slickdeals.net/attachment.php?attachmentid=84784&d=...
> [2]
> http://www.zhuzhuchina.com/store/esata_to_usb_2_0_external_adapter_spif225a_serial_ata.html

Got it, and it is working[1]!

152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp.
transcend storejet 25P

[1] http://en.gentoo-wiki.com/wiki/USB_SATA_SPIF225A
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Robert Hancock | 31 Aug 07:20 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB


On 05/08/2012 06:12 PM, Norman Diamond wrote:
> On Wed, 2012/5/9, Alan Stern wrote:
>> On Tue, 8 May 2012, Norman Diamond wrote:
>>> Alan Stern wrote:
>>>> On Tue, 8 May 2012, Norman Diamond wrote:
>>>>> In my case there is no other way that a host (PC or other, any OS or
>>>>> driver) could obtain a reported capacity past the 2.2TB mark.
>>>>> Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of
>>>>> an ATA Identify command though I haven't seen one.
>>>>
>>>> There definitely are some bridges which handle ATA passthru correctly.
>>>
>>> Oh, please can you suggest some.  I search occasionally but have
>>> never found one that was described as obeying ATA passthru.  Of
>>> course I can't command my users to use such bridges, but I would like
>>> to use one or two.
>>
>> The only ones I'm aware of are the entries marked with the SANE_SENSE
>> quirk in unusual_devs.h: the HP Personal Media Drive (03f0:070c), the
>> Genesys Logic bridge (05e3:0723), the Seagate FreeAgent Pro
>> (0bc2:3010), the Maxtor bridge (0d49:7310), the Western Digital bridge
>> (1058:0704), and a different JMicron bridge (152d:2329).  Of course,
>> the fact that the flag is set doesn't necessarily mean the device
>> really does have SAT support.
>
> Among those, the Genesys and JMicron ones look like they have a chance of being used in adapters sold
separately from Seagate and Western Digital external drives.  By any chance do you know of cables or
docking stations that use them?

(Continue reading)

Norman Diamond | 1 Sep 07:33 2012
Picon

Re: JMicron 20337 (152d:2338) and 3TB

Robert Hancock wrote:
> On 05/08/2012 06:12 PM, Norman Diamond wrote:
>> On Wed, 2012/5/9, Alan Stern wrote:
>>> On Tue, 8 May 2012, Norman Diamond wrote:
>>>> Alan Stern wrote:
>>>>> On Tue, 8 May 2012, Norman Diamond wrote:
>>>>>>
>>>>>> Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of
>>>>>> an ATA Identify command though I haven't seen one.
>>>>>
>>> The only ones I'm aware of are the entries marked with the SANE_SENSE
>>> quirk in unusual_devs.h: the HP Personal Media Drive (03f0:070c), the
>>> Genesys Logic bridge (05e3:0723), the Seagate FreeAgent Pro
>>> (0bc2:3010), the Maxtor bridge (0d49:7310), the Western Digital bridge
>>> (1058:0704), and a different JMicron bridge (152d:2329).  Of course,
>>> the fact that the flag is set doesn't necessarily mean the device
>>> really does have SAT support.
>
> I have a Vantex NexStar TX 2.5" SATA enclosure that uses:
>
> Bus 001 Device 006: ID 152d:2329 JMicron Technology Corp. / JMicron USA 
> Technology Corp. JM20329 SATA Bridge
>
> and ATA pass-through seems to work (at least as far as commands like 
> hdparm -I and smartctl).

Thank you.  I will buy the following device for experiments:
http://dx.com/p/jmicron-usb-sata-adapter-dongle-12213

I'm not holding my breath expecting it to work with a drive larger than 
(Continue reading)


Gmane