Current problem reports assigned to you

[Julian Elischer]

Barry Bouwsma wrote:

>On Tue, 11 Jan 2005 11:46:16 -0800, Julian Elischer wrote:
>
>  
>
>>>Could this be the same thing?  I have two WD disks, and they work, though
>>>there is a difference in reported size from USB and Firewire...  (add that
>>>to my list of USB problems)
>>>      
>>>
>
>  
>
>>the question is:  Which returns the wrong number, USB or SBP?
>>    
>>

yep the right number is 390721968
I have one here..
WDC WD2000BB-00DAA0 WD-WMACK1337522 186.31 GB (390721968 blocks)
(I have JBs as well as BBs buth they have the same number of blocks.)

>Apparently, USB, in both cases.  It seems to be a quirk of the chip
>that translates ATA to USB.  And if I read the Linux quirks right,
>the same problem affects the iPod, among other devices.
>
>A search shows another FreeBSD user with the same drive in a
>different housing getting the correct number of sectors.
>Aug  7 12:14:25 Crappy /kernel: umass0: Cypress Semiconductor USB2.0 Storage
>Device, rev 2.00/0.01, addr 2
>Aug  7 12:14:25 Crappy /kernel: umass0: Get Max Lun not supported (STALLED)
>Aug  7 12:14:32 Crappy /kernel: da0 at umass-sim0 bus 0 target 0 lun 0
>Aug  7 12:14:32 Crappy /kernel: da0: <WDC WD2000JB-00FUA0 \0000\0000> Fixed
>Direct Access SCSI-0 device
>Aug  7 12:14:32 Crappy /kernel: da0: 650KB/s transfers
>Aug  7 12:14:32 Crappy /kernel: da0: 190782MB (390721968 512 byte sectors:
>64H 32S/T 59710C)
>
>Someone else has a different housing and OpenBSD:
>   umass0: LaCie USB 2.0 LaCie d2 HD, rev 2.00/9a.bc, addr 2
>   umass0: using SCSI over Bulk-Only
>   scsibus1 at umass0: 2 targets
>   sd0 at scsibus1 targ 1 lun 0: <WDC WD20, 00LB-00EDA0, 15.0> SCSI4
>   0/direct fixed
>   sd0: 190782MB, 190782 cyl, 64 head, 32 sec, 512 bytes/sec, 390721968
>   sec
>
>Another data point comes from Linux:
>   Vendor: USB 2.0 Model: Storage Device Rev: 0100
>   Type: Direct-Access ANSI SCSI revision: 02
>   SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
>
>Nice vendor and model there, eh.  Not that I have any better:
>umass0: Generic USB 2.0 Storage Device, rev 2.00/0.01, addr 3
>pass1: <WDC WD20 00JB-00GVA0 08.0> Fixed Direct Access SCSI-0 device
>da1: 190782MB (390721969 512 byte sectors: 255H 63S/T 24321C)
>
>Thus it appears a quirk can be added for my USB vendor and product,
>which I've tried in umass.c, but I don't think this quite does the
>trick.
>
>I think I need to fix the volume size (sectors) in cam/scsi/da.c
>instead.  But do those quirk entries operate on the WDC string one
>sees above in the `pass1' line, and have nothing to do with the USB
>chip vendor/product IDs?
>
>
>Here's the USB info for the second drive I have with this problem:
>  port 4 addr 5: full speed, power 2 mA, config 1, product 0x3507(0x3507), ASSMA
>NN Electronic GmbH(0x067b), rev 0.01
>and the original:
>  port 2 addr 3: full speed, power 2 mA, config 1, USB 2.0 Storage Device(0x0082
>), Generic(0x0840), rev 0.01
>It's not just a single vendor/product with this problem.
>
>
>To repeat my question, can cam/scsi correct for a problem that is
>identified in the usb layer -- or is it possible for a usb quirk to
>reach over to cam/scsi?
>

I guess it is a problem in an OEM chip made by some 3rd party 
manufacturer. (ATA<->USB)
You certainly can not get CAM to fix it depending on the WD string as 
that would be triggered by
firewire too. or atapicam.

The USB umass layer intercepts a lot of commands.. maybe you should 
intercept this one too?

>
>
>thanks
>barry bouwsma
>
>_______________________________________________
>freebsd-usb at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>To unsubscribe, send any mail to "freebsd-usb-unsubscribe at freebsd.org"
>  
>