Date: Tue, 24 Apr 2007 16:26:52 -0600 From: Scott Long <scottl@samsco.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: umass0: BBB reset failed, TIMEOUT on internal card reader Message-ID: <462E842C.9020807@samsco.org> In-Reply-To: <200704242304.13649.hselasky@c2i.net> References: <200704191213.21299.durian@shadetreesoftware.com> <200704242003.21153.hselasky@c2i.net> <200704241349.58604.durian@shadetreesoftware.com> <200704242304.13649.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?462E842C.9020807>