Current problem reports assigned to you

[Barry Bouwsma]

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?

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 WD20 00JB-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?


thanks
barry bouwsma