Current problem reports assigned to you
julian at elischer.org
Wed Jan 19 12:32:18 PST 2005
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
>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
>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
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?
>freebsd-usb at freebsd.org mailing list
>To unsubscribe, send any mail to "freebsd-usb-unsubscribe at freebsd.org"
More information about the freebsd-usb