From owner-freebsd-usb@FreeBSD.ORG Tue Apr 24 22:46:55 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D29E316A406 for ; Tue, 24 Apr 2007 22:46:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7F32813C46C for ; Tue, 24 Apr 2007 22:46:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l3OMRH5m000337; Tue, 24 Apr 2007 16:27:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <462E842C.9020807@samsco.org> Date: Tue, 24 Apr 2007 16:26:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <200704191213.21299.durian@shadetreesoftware.com> <200704242003.21153.hselasky@c2i.net> <200704241349.58604.durian@shadetreesoftware.com> <200704242304.13649.hselasky@c2i.net> In-Reply-To: <200704242304.13649.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 24 Apr 2007 16:27:17 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-usb@freebsd.org Subject: Re: umass0: BBB reset failed, TIMEOUT on internal card reader 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: Tue, 24 Apr 2007 22:46:55 -0000 Hans Petter Selasky wrote: > Hi, > > Scott, can you have a quick look at this? > > On Tuesday 24 April 2007 21:49, Mike Durian wrote: >> On Tuesday 24 April 2007, Hans Petter Selasky wrote: >>> On Friday 20 April 2007 17:36, Mike Durian wrote: >>>> On Friday 20 April 2007, Hans Petter Selasky wrote: >>>>> I would suggest you install the new USB stack from: >>>>> >>>>> http://www.turbocat.net/~hselasky/usb4bsd/ >>>>> >>>>> How to get the latest sources: >>>>> >>>>> svn --username anonsvn --password anonsvn \ >>>>> checkout svn://svn.turbocat.net/i4b >>>>> # >>>>> # The following commands will >>>>> # install the driver on FreeBSD: >>>>> # >>>>> cd i4b/trunk/i4b/FreeBSD.usb >>>>> make S=../src package >>>>> make install >>>>> >>>>> Install on FreeBSD 6.x . >>>>> >>>>> When you have rebooted your computer, then you turn on debugging: >>>>> >>>>> sysctl hw.usb.umass.debug=-1 >>>>> >>>>> Then post the dmesg you get. >>>>> >>>>> --HPS >>> I have found a small data-toggle bug in my EHCI driver. I assume that >>> your device is USB2.0. Could you do a "svn update", repeat the install >>> procedure, and then build a new kernel. >>> >>> Then send me the dmesg with "sysctl hw.usb.umass.debug=-1", when you plug >>> your device. >>> >>> --HPS >> Yes, it is a USB 2.0 device. Here is the debug output. > > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_STALLED, try 0 > umass0:umass_transfer_start: transfer index = 5 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 3: sig = 0x53425355 (valid), tag = 0x00000003, > res = 209, status = 0x00 (good) > > From what I can see it looks a little suspicious that the CAM command is all > zero. Is this Normal? Also the residue from the last command, "res = 209" > maybe confuses the CAM layer? > > umass0:umass_cam_action: 5:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 5:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 5:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 5:0:0:XPT_SET_TRAN_SETTINGS:. > umass0:umass_cam_action: 5:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b > data/32b sense > umass0:umass_bbb_dump_cbw: CBW 4: cmd = 6b (0x000000000000), data = 0b, lun = > 0, dir = out > > --HPS A 6 byte command of all 0x00 values is a TEST_UNIT_READY (TUR) command, a perfectly normal and expected command. CAM sends one to each target during probe to see if the target is there. The only data transfered back from the device for this command should be a status word. If the status is an error then the device should provide sense data, either automatically or in response to a REQUEST_SENSE command. I'm not familiar enough with umass to know which should be expected. Sense data is usually 18-32 bytes. I'm not sure why it would be sending back 209 bytes for any reason from a TUR. Scott