From owner-freebsd-usb@FreeBSD.ORG Sun Feb 10 13:44:32 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5424C16A41B; Sun, 10 Feb 2008 13:44:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id A64CE13C455; Sun, 10 Feb 2008 13:44:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 1D68143CCA7; Sun, 10 Feb 2008 15:44:29 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Rn3nV829RCaM; Sun, 10 Feb 2008 15:44:28 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id CD34243CACC; Sun, 10 Feb 2008 15:44:27 +0200 (EET) Message-ID: <47AEFFAF.1010403@icyb.net.ua> Date: Sun, 10 Feb 2008 15:44:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-usb@freebsd.org, Warner Losh References: <46C44170.3040108@icyb.net.ua> <4798996A.8090205@icyb.net.ua> In-Reply-To: <4798996A.8090205@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------020405070009000409020001" Cc: Subject: Re: scsi_da quirk for a device with "no name" X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2008 13:44:32 -0000 This is a multi-part message in MIME format. --------------020405070009000409020001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [sorry for top-quoting, but I think that this should be more convenient since I am following up on my own posts] Warner, list, please consider the attached patch. umass.c part of it is intended to put some meaningful data into inquiry response if a device return completely empty identification. This is useful when cam/scsi layer needs to have a quirk for such a device. scsi_da.c part of it utilizes this new feature to handle ASUS P535 smartphone (phone+pda) configured to act as a mass storage device for USB connection. Another possible alternative to the umass.c patch is to have a new quirk to force some inquiry data instead of dynamic inquiry response checking, but I am not sure if that would be any better. Would it be more convenient for everybody if I file a PR on this ? Thank you for your attention. on 24/01/2008 15:58 Andriy Gapon said the following: > This is me again on the issue of a weird umass device that reports empty > strings to SCSI inquiry command. Currently the only way to specify some > SCSI-level quirk for such a device is to create a quirk entry with all > fields set to wildcard "*", but apparently such a quirk would be applied > to many more devices. > A suggestion: what about umass intercepting a response of inquiry > command and generating some names in such a case. E.g. vendor and > product identification could be generated from the USB ids like > Vendor_abcd, Product_1234. > In this case we would get some sufficient identification for such devices. > > P.S. it also seems that if NO_INQUIRY umass quirk is specified for a > device, then its identification will be empty as well. I think that this > is not good because, for example, scsi_da quirks are troublesome then. > > P.P.S. it is currently impossible to have scsi_da quirk entries with > empty fields (""), they get ignored. > > on 16/08/2007 15:22 Andriy Gapon said the following: >> I have ASUS P535 PPC+phone with Windows Mobile 5 on it. >> It has an option to act as a USB mass storage (instead of attempting >> acivesync). >> >> When I tried it, it first got recognized by umass and then it >> immediately panicked my system. >> >> From messages: >> kernel: umass0: ASUS Generic Mass Storage, rev 2.00/0.00, addr 3 >> kernel: da0 at umass-sim0 bus 0 target 0 lun 0 >> kernel: da0: < > Removable Direct Access SCSI-0 device >> kernel: da0: 1.000MB/s transfers >> kernel: da0: 1952MB (3998720 512 byte sectors: 255H 63S/T 248C) >> >> From panic (typed from memory): >> umass0: Invalid CSW: tag 7 should be 8 >> (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x0, scsi >> status == 0x4 >> >> I googled up several reports of similar and not so similar panics. >> Here's a small overview that is not directly related to a question that >> I really want to ask: >> >> 1. Invalid CSW problems where a signature is wrong, I see that >> WRONG_CSWSIG umass quirk is recommended for that; >> 2. Invalid CSW problems where a tag is wrong and the values are very >> different, I see that one person attempted to cure that with a new >> hand-rolled quirk to simply ignore the mismatch; >> 3. Invalid CSW problems where a tag is wrong and the difference is >> exactly one. I don't know if there is anything special about that, but >> it looks the most interesting of all the cases. >> >> In some cases but not all "Invalid CSW" comes together with "Synchronize >> cache failed" and DA_Q_NO_SYNC_CACHE scsi_da quirk is recommended for that. >> >> So I attempted the latter quirk and it helped me! But there is one not >> good thing about the way I did that - I used wild cards ("*") for all >> three of vendor, product and revision. This is because they all appear >> to be empty/unset. This is shown in both kernel messages and by >> camcontrol devlist and by camcontrol inquiry. >> I am not sure if there are any risks of applying the quirk to all >> possible da devices, there will be only umass ones in my case, but I >> still would like to do something more specific to the device in question. >> >> Will empty patterns work ? I mean if I put "", "", "" entry into the >> quirk array. Actually, I can test this myself soon, but not today. >> >> Thank you. >> >> P.S. some links to the problems that others have reported: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=114916&cat= >> http://osdir.com/ml/os.freebsd.devel.usb/2005-12/msg00039.html >> http://lists.freebsd.org/pipermail/freebsd-bugs/2004-November/010483.html >> http://lists.freebsd.org/pipermail/freebsd-bugs/2004-January/005170.html >> http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html >> http://lists.freebsd.org/mailman/htdig/freebsd-usb/2005-February/000660.html >> > > -- Andriy Gapon --------------020405070009000409020001 Content-Type: text/x-patch; name="p535.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="p535.diff" --- sys/dev/usb/umass.c 2008-02-10 15:30:23.000000000 +0200 +++ sys/dev/usb/umass.c 2008-02-10 15:02:43.000000000 +0200 @@ -3063,6 +3059,12 @@ maxsector = scsi_4btoul(rcap->addr) - 1; scsi_ulto4b(maxsector, rcap->addr); } + else if (csio->cdb_io.cdb_bytes[0] == INQUIRY && + csio->data_ptr[8] == '\0' && csio->data_ptr[16] == '\0') { + usb_device_descriptor_t *dd = usbd_get_device_descriptor(sc->sc_udev); + sprintf(&csio->data_ptr[8], "%04x", UGETW(dd->idVendor)); + sprintf(&csio->data_ptr[16], "%04x", UGETW(dd->idProduct)); + } xpt_done(ccb); break; --- sys/cam/scsi/scsi_da.c 2008-02-10 12:40:43.000000000 +0200 +++ sys/cam/scsi/scsi_da.c 2008-02-10 15:09:05.000000000 +0200 @@ -535,6 +535,13 @@ {T_DIRECT, SIP_MEDIA_REMOVABLE, "ChipsBnk", "USB*", "*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE }, + { + /* + * ASUS P535 in umass device mode + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "0b05*", "422f*", + "*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE + }, }; static disk_strategy_t dastrategy; --------------020405070009000409020001--