From owner-freebsd-usb@FreeBSD.ORG Tue Mar 13 06:24:40 2012 Return-Path: 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 B188D106564A; Tue, 13 Mar 2012 06:24:40 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 813A18FC14; Tue, 13 Mar 2012 06:24:38 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 249520573; Tue, 13 Mar 2012 07:24:31 +0100 From: Hans Petter Selasky To: Brandon Gooch Date: Tue, 13 Mar 2012 07:22:48 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201203120915.18908.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@ =?iso-8859-1?q?d2+AyewRX=7DmAm=3BYp=0A=09=7CU=5B?=@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y> =?iso-8859-1?q?Y=7Dk1C4TfysrsUI=0A=09-=25GU9V5=5DiUZF=26nRn9mJ=27=3F=26?=>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203130722.48489.hselasky@c2i.net> Cc: Alexander Motin , Nathan Whitehorn , "freebsd-usb@freebsd.org" Subject: Re: Ongoing battle with umass(4) and xhci(4) 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, 13 Mar 2012 06:24:40 -0000 On Tuesday 13 March 2012 04:37:55 Brandon Gooch wrote: > On Mon, Mar 12, 2012 at 3:15 AM, Hans Petter Selasky wrote: > >> Is there something fishy happening between the USB stack and CAM? > >> hmmm... > > > > No, > > > > It is not the CAM layer this time, though there are some bugs there too. > > > > > > In the beginning of the log I see that in the successful case we receive > > a stall event: > > > > -xhci_check_transfer: slot=1 epno=3 remainder=13 status=6 > > -xhci_check_transfer: TD is last > > -xhci_cmd_stop_ep: > > -xhci_check_command: Received command event > > -xhci_configure_reset_endpoint: Could not stop endpoint 3 > > -xhci_cmd_reset_ep: > > -xhci_check_command: Received command event > > -xhci_cmd_set_tr_dequeue_ptr: > > -xhci_check_command: Received command event > > -xhci_cmd_evaluate_ctx: > > -xhci_check_command: Received command event > > -xhci_cmd_configure_ep: > > -xhci_check_command: Received command event > > -xhci_configure_reset_endpoint: Could not configure endpoint 3 > > -xhci_ep_clear_stall: > > -xhci_device_generic_enter: > > -xhci_setup_generic_chain_sub: NTRB=1 > > -xhci_setup_generic_chain_sub: LINK=0x82883180 > > -xhci_setup_generic_chain_sub: NTRB=1 > > -xhci_setup_generic_chain_sub: LINK=0x82883000 > > -xhci_setup_generic_chain: first=0xffffff8460883300 > > last=0xffffff8460883180 -xhci_device_generic_start: > > -xhci_transfer_insert: qh_pos = 1 > > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > > -xhci_check_transfer: Following next TD > > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > > -xhci_check_transfer: TD is last > > > > > > This is not received in the failing case. > > > > Maybe this indicates a lost interrupt or something like that? > > > > In /sys/dev/usb/controller/xhci.c > > > > static void > > xhci_interrupt_poll(struct xhci_softc *sc) > > > > Add a printf: > > > > if (i == XHCI_MAX_EVENTS) { > > i = 0; > > j ^= 1; > > > > /* check for timeout */ > > if (!--t) { > > + printf("XHCI: > > Timeout\n"); break; > > } > > } > > > > > > See if what happens. > > > > Also change the xhci.c code to call > > > > xhci_interrupt_poll() two times instead of one. > > > > > > --HPS > > Unfortunately, the condition was never reached. > > I've started trying to dtrace xhci(4) function boundaries, and, well > there's a lot of recursion with xhci_interrupt_poll(). However, I > never see that function called from xhci_do_poll(), which is called > from xhci_interrupt() (to "catch any lost interrupts" according to the > comment). > > You may have already told me this, but what does "Down reving Protocol > Version from 2 to 0?" in the success case on my system? Is this the > USB protocol which is "down rev'ed"? If so, what USB level is this > flash drive running at? Hi, The XHCI supports all the wire USB protocols up to date. Is that what you ask? --HPS