From owner-freebsd-usb@FreeBSD.ORG Thu Jun 28 16:32:15 2012 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 797951065670 for ; Thu, 28 Jun 2012 16:32:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 00CBC8FC17 for ; Thu, 28 Jun 2012 16:32:14 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so212784wib.13 for ; Thu, 28 Jun 2012 09:32:14 -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=2ZH/VZlkBp7j5QdCX8sr0L2yL1tmuDq/4s/AIp0kl9Y=; b=Cep0XRcm0QcMEuW4lSCAQuRjsozZgunUyelsHCwxT1W0SYn18lzsM6q5OQ0eFu2JOc V8sDemldwOAVvPUe7hN1qxzL0L2CjVuk1W/PHGPG1iuQ+t7MlKLiHQPnGnlpmq9dLoE+ r+AJDnu9N4mkFZ6+4KRoYVJ0q9+RFIuqXsGBuBJCYAl5yb6iH2YyFGPjJGHNLXLDs5Z2 RDEbOEgza4smaq2ro5w3CUlV+MYvZRhToB2Zi3TaP6mArfrRQJ/MGjkqofDXU5boBW0u LhzSLKwaBFjavcKL1GHblQegrj9JaAIONksP061dgn+AgRl8TsWFjmjrrqNgOC4X+dn5 MnEg== Received: by 10.180.102.228 with SMTP id fr4mr1400721wib.6.1340901133882; Thu, 28 Jun 2012 09:32:13 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id fu8sm991305wib.5.2012.06.28.09.32.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 09:32:12 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FEC8707.5030109@FreeBSD.org> Date: Thu, 28 Jun 2012 19:32:07 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <4FE9AB28.3070704@passap.ru> <201206272208.05877.hselasky@c2i.net> <4FEB77C3.2040803@FreeBSD.org> <201206280856.03751.hselasky@c2i.net> In-Reply-To: <201206280856.03751.hselasky@c2i.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: [usb] Kingston 8Gb is not usable 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: Thu, 28 Jun 2012 16:32:15 -0000 On 28.06.2012 09:56, Hans Petter Selasky wrote: > On Wednesday 27 June 2012 23:14:43 Alexander Motin wrote: >> On 27.06.2012 23:08, Hans Petter Selasky wrote: >>> On Wednesday 27 June 2012 19:51:15 Alexander Motin wrote: >>>> On 06/27/12 19:26, Hans Petter Selasky wrote: >>>>> On Wednesday 27 June 2012 18:15:24 Hans Petter Selasky wrote: >>>>>> ERR=STALLED >>>>> >>>>> Retrying might not work, until sense is cleared, due to stalled error. >>>>> >>>>> MAV: Maybe that failed prevent-allow medium removal left a sense error >>>>> that needs to be cleared. >>>> >>>> It should be cleared by fetching sense command. As I was assured by >>>> several people, it is SIM (controller driver, umass) obligation to fetch >>>> sense and respectively clear it when error detected. But not sure what >>>> should umass do if this device STALLs. May be should try to do it also. >>>> So far I haven't see any properly fetched sense from it in provided >>>> logs. >>> >>> Are you sure? And where should the sense output be sent? >> >> Sense output should be (and are now for working devices) sent within >> reply on the original command returning with the CHECK CONDITION SCSI >> status. In addition to general status fields there are space for sense >> data in struct scsiio: sense_data, sense_len and sense_resid fields. > > I see. UMASS already does the sense like you explain on errors, except if the > BULK endpoint is STALL'ed on a READ data. Anyway, I see that the next SCSI > command in the queue completes. And also that the previous one was successful. > So there should be no sense data to fetch. > > Even if UMASS gets the sense information, will the upper layers, in this case > CAM layer, retry the CAPACITY command, which seems required to workaround a > bug the stick's firmware? It depends on sense information (if present). Fatal errors like invalid command code are not retried. Temporal errors like device loading media could be retried many times with some delays between commands, Unknown errors like in this case are usually retried several times, depending on peripheral driver. In this case I see in logs that READ CAPACITY(10) command was unsuccessfully tried 5 times. -- Alexander Motin