From owner-freebsd-usb@FreeBSD.ORG Wed Jan 19 12:34:43 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76E5A16A4CE for ; Wed, 19 Jan 2005 12:34:43 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (84-72-27-104.dclient.hispeed.ch [84.72.27.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1A6143D46 for ; Wed, 19 Jan 2005 12:34:41 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [IPv6:2002:5448:1b68:0:206:28ff:fed8:8dcf]) (8.13.2/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id j0JCYbIe000675NO) for ; Wed, 19 Jan 2005 13:34:39 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.13.2/FNORD) id j0JCYasq000674; Wed, 19 Jan 2005 13:34:36 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 19 Jan 2005 13:34:36 +0100 (CET) Message-Id: <200501191234.j0JCYasq000674@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200501101103.j0AB3ENh095604@freefall.freebsd.org> <41E32B44.90807@elischer.org> <200501111205.j0BC53T2015903@Mail.NOSPAM.DynDNS.dK> <41E42D08.90407@elischer.org> To: freebsd-usb@freebsd.org Mail-Followup-To: freebsd-usb@freebsd.org Subject: Re: Current problem reports assigned to you X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barry Bouwsma List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2005 12:34:43 -0000 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: 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: 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: 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