From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 11:24:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 333DD106564A; Sat, 31 Mar 2012 11:24:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4F22A8FC1B; Sat, 31 Mar 2012 11:24:21 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1252770wgb.31 for ; Sat, 31 Mar 2012 04:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ytzp3Ra3tRbkYAnsd2r3oznVKTId/MxGaZfw8jCgkzg=; b=OrGltmQItgYI6dcvZvubeSaIBzQf4jbKFrymh8JGgE/8wPNienujSKxSI/igBp4NsP 9l1Evk66dgKD9thBpBdeHbx1P2X2PTFMb9KpEvLw88kyC4tduMlJPKLr6u4fyvvrLV0D WHZ0Z8baMfnLAQrNQp859Oo4cb29aCqUiw+xSsJATfnCBV6mhr16BQEwbmarJT6wCTwI dLuPI3uhJ4AE7WENeGsHRJp1XX18ynSkWtV6kC4PSfpyxTQTUwOZCkGOba/Mn1XjJfZZ 1UYrzJP8/Y21ocz0Nohe4LXfosudhB2/kD8D/J3vCxgXniwQek0pyK66tkpJWeZmxQRH 3yjw== Received: by 10.180.96.228 with SMTP id dv4mr6252056wib.14.1333193060735; Sat, 31 Mar 2012 04:24:20 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id bx13sm15140041wib.10.2012.03.31.04.24.18 (version=SSLv3 cipher=OTHER); Sat, 31 Mar 2012 04:24:19 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F76E961.5000009@FreeBSD.org> Date: Sat, 31 Mar 2012 14:24:17 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Kaho Toshikazu References: <201203230825.32954.hselasky@c2i.net> <17628.1332555469@pf2.ed.niigata-u.ac.jp> <4F6D9672.4050201@FreeBSD.org> <2087.1332651759@pf2.ed.niigata-u.ac.jp> <4F6EF03E.6060001@FreeBSD.org> <1782.1332719733@pf2.ed.niigata-u.ac.jp> <4F75F8E5.9000508@FreeBSD.org> <8850.1333169871@elam.kais.kyoto-u.ac.jp> <4F76D965.80102@FreeBSD.org> <1742.1333190406@pf2.ed.niigata-u.ac.jp> In-Reply-To: <1742.1333190406@pf2.ed.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, day1234@hotmail.com, freebsd-usb@FreeBSD.org, Andriy Gapon , Hans Petter Selasky Subject: Re: USB Flash drive problem with 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 11:24:23 -0000 On 03/31/12 13:40, Kaho Toshikazu wrote: > Your patch solves the problem. Thank you. Committed to HEAD at r233746. >> On 03/31/12 07:57, Kaho Toshikazu wrote: >>>> Could you collect more information about what's exactly happens >>>> with the device? Can you execute some camcontrol inquiry or >>>> camcontrol readcap commands after kernel misdetected size with >>>> "READ CAPACITY(16)"? >>>> >>>> If yes (device is still alive), could you run these commands >>>> (with proper device name) and send me the output files: >>>> camcontrol cmd da0 -E -v -c "12 00 00 00 80 00" -i 128 -> INQ.res >>>> camcontrol cmd da0 -E -v -c "9e 10 00 00 00 00 00 00 00 00 00 00 >>>> 00 20 00 00" -i 32 -> RC16.result >>> >>> usbconfig -d 0.3 dump_device_desc >>> >>> ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON >>> >>> bLength = 0x0012 >>> bDescriptorType = 0x0001 >>> bcdUSB = 0x0200 >>> bDeviceClass = 0x0000 >>> bDeviceSubClass = 0x0000 >>> bDeviceProtocol = 0x0000 >>> bMaxPacketSize0 = 0x0040 >>> idVendor = 0x8564 >>> idProduct = 0x1000 >>> bcdDevice = 0x1100 >>> iManufacturer = 0x0001 >>> iProduct = 0x0002 >>> iSerialNumber = 0x0003<83CA7S8M3LD8UGSF> >>> bNumConfigurations = 0x0001 >>> >>> -- dmesg without any quirks -- >>> ugen0.3: at usbus0 >>> umass0: on usbus0 >>> da0 at umass-sim0 bus 0 scbus11 target 0 lun 0 >>> da0: Removable Direct Access SCSI-4 device >>> da0: 40.000MB/s transfers >>> da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C) >>> >>> hexdump -Cv RC16.result >>> 00000000 00 ff 00 00 00 00 00 00 00 00 02 00 00 00 00 00 |................| >>> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >>> 00000020 >>> >>> `hexdump -Cv INQ.res` >>> 00000000 00 80 04 02 1f 73 6d 69 4a 65 74 46 6c 61 73 68 |.....smiJetFlash| >>> 00000010 54 72 61 6e 73 63 65 6e 64 20 31 36 47 42 20 20 |Transcend 16GB | >>> 00000020 31 31 30 30 00 80 02 00 00 00 00 00 00 00 00 00 |1100............| >>> 00000030 00 00 00 00 00 00 28 00 03 01 82 06 00 3f 00 00 |......(......?..| >>> 00000040 00 00 28 32 00 00 00 00 00 00 00 50 50 00 00 00 |..(2.......PP...| >>> 00000050 30 50 50 00 00 00 00 00 00 00 00 21 84 84 21 1e |0PP........!..!.| >>> 00000060 00 03 48 00 00 c0 00 00 00 00 00 00 00 00 00 00 |..H..@..........| >>> 00000070 00 00 00 00 00 00 01 00 24 15 01 09 00 00 00 00 |........$.......| >>> 00000080 >>> >>> -- dmesg with UQ_MSC_NO_INQUIRY -- >>> ugen0.3: at usbus0 >>> umass0: on usbus0 >>> da0 at umass-sim0 bus 0 scbus11 target 0 lun 0 >>> da0:< > Removable Direct Access SCSI-2 device >>> da0: 40.000MB/s transfers >>> da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C) >>> >>> >>> Hmm, "READ CAPACITY(16)" can be used and device is alive. >>> With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally. >>> Without UQ_MSC_NO_INQUIRY, camcontrol can return something, >>> but dd can not be usable. >> >> Thank you. >> >> I see number of inconsistencies there. Device reports support >> for SPC-2 >> spec, but has PROTECT bit set in INQUIRY data, which is defined >> only since SPC-3 and reserved in SPC-2. Protection information, >> same as READ CAPACITY(16) command, defined only from >> SPC-3. SPC-2 devices should not know about it, returning error, >> but this device doesn't return error, instead returning >> something strange (correct sector size, but wrong number of >> sectors). >> >> I see the only clean solution in following specs more closely >> and not checking PROTECT bit for pre-SPC-3 devices. I don't know >> why Linux does for all SCSI-3/SPC devices, but for this device >> result is fatal. >> >> Please try the following patch. It should disable use of READ >> CAPACITY(16) in your case. >> >> --- scsi_da.c (revision 233697) >> +++ scsi_da.c (working copy) >> @@ -1631,9 +1631,7 @@ >> softc->minimum_cmd_size = 16; >> >> /* Predict whether device may support READ CAPACITY(16). */ >> - if (SID_ANSI_REV(&cgd->inq_data)>= SCSI_REV_SPC3 || >> - (SID_ANSI_REV(&cgd->inq_data)>= SCSI_REV_SPC&& >> - (cgd->inq_data.spc3_flags& SPC3_SID_PROTECT))) { >> + if (SID_ANSI_REV(&cgd->inq_data)>= SCSI_REV_SPC3) { >> softc->flags |= DA_FLAG_CAN_RC16; >> softc->state = DA_STATE_PROBE2; >> } >> -- Alexander Motin