From owner-freebsd-usb@FreeBSD.ORG Tue Mar 13 03:37:57 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 125E01065674; Tue, 13 Mar 2012 03:37:57 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1278FC1A; Tue, 13 Mar 2012 03:37:56 +0000 (UTC) Received: by ghrr20 with SMTP id r20so119330ghr.13 for ; Mon, 12 Mar 2012 20:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3VVIavyR9B7pfCBjt3VGsKot3Mdm5PL12JWRWXabHZ0=; b=G074OQH7b3OEAlJdDY9x3vwQh8mEH6ybztCUSdfpLk25hVY1sxdPW8kVAV0ESLwDe6 Y8qymJshjA2osX4WYamBgC91cdBFIr8y/Vqtjy6hWKQRloZHaFBdWxXmDfxUMHKGBTQD VU/OgCcfQAGz/pjPeM7RAu/PPCGwzsXLRZddYqnasNjIUa9K8N4Z8K/mKlqjDIzbgExc 9ghqXoEc7Yn9k4XoohPP+m5ciS9quWh2g43Xr2VnJwYo17a94ENVCcq1PzmTOqiQJt14 ndcChZT6GAGBT/c+potj27qy9aiVZsQMGxS6m+NCm/2COTvKdc4nv/8ZP0Jrft28irRO pWgA== MIME-Version: 1.0 Received: by 10.182.169.41 with SMTP id ab9mr10287979obc.4.1331609875612; Mon, 12 Mar 2012 20:37:55 -0700 (PDT) Received: by 10.60.17.10 with HTTP; Mon, 12 Mar 2012 20:37:55 -0700 (PDT) In-Reply-To: <201203120915.18908.hselasky@c2i.net> References: <201203120915.18908.hselasky@c2i.net> Date: Mon, 12 Mar 2012 22:37:55 -0500 Message-ID: From: Brandon Gooch To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 03:37:57 -0000 On Mon, Mar 12, 2012 at 3:15 AM, Hans Petter Selasky wro= te: >> >> 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=3D1 epno=3D3 remainder=3D13 status=3D6 > -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=3D1 > -xhci_setup_generic_chain_sub: LINK=3D0x82883180 > -xhci_setup_generic_chain_sub: NTRB=3D1 > -xhci_setup_generic_chain_sub: LINK=3D0x82883000 > -xhci_setup_generic_chain: first=3D0xffffff8460883300 last=3D0xffffff8460= 883180 > -xhci_device_generic_start: > -xhci_transfer_insert: qh_pos =3D 1 > -xhci_check_transfer: slot=3D1 epno=3D1 remainder=3D0 status=3D1 > -xhci_check_transfer: slot=3D1 epno=3D1 remainder=3D0 status=3D1 > -xhci_check_transfer: Following next TD > -xhci_check_transfer: slot=3D1 epno=3D1 remainder=3D0 status=3D1 > -xhci_check_transfer: slot=3D1 epno=3D1 remainder=3D0 status=3D1 > -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: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (i =3D=3D XHCI_MAX_EVENTS) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0j ^=3D 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* check for timeout */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!--t) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("XHCI: Timeout\n"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > > > 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? -Brandon