From owner-freebsd-usb@FreeBSD.ORG Tue Mar 13 07:02:31 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 916AC106566C; Tue, 13 Mar 2012 07:02:31 +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 2668F8FC12; Tue, 13 Mar 2012 07:02:30 +0000 (UTC) Received: by ghrr20 with SMTP id r20so245670ghr.13 for ; Tue, 13 Mar 2012 00:02:30 -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=/EzSRB8/97Y/zqU2iqAav8fFkgvC/7iB5r2PDBQ0KCs=; b=qw+luqSKEn2D7h1NJiFLXuAHmpe1OZkUBOaOZqB2tnP//DmnPNQQnzcUcurfXAH580 FjmK3CwI9aqcyzfePd3D3zNPqPiN0Wlw3xDnXUGEDaqPRgGbplWUI6rvtSxoctryF5nc 9kwzFaG0gpwCR1jJVwKrYe/5bY/ti9AKWMwxn8u0hGpRXzzeLQGEZpWHXiCJUJGGkYeN aTV6c1+LCgkbh5VSQrzgkBaO5xAmkC4B64f3XoxDhhSMz1jhwQuL6/epqzNstPtAuenf DLJCNAqsiAgXT2hvjjv+20IeXFNOxWei1TUao624mjuA1bqa2i1dUGUQvgk8hwAcYg7l ZkOQ== MIME-Version: 1.0 Received: by 10.60.24.9 with SMTP id q9mr8942448oef.4.1331622150323; Tue, 13 Mar 2012 00:02:30 -0700 (PDT) Received: by 10.60.17.10 with HTTP; Tue, 13 Mar 2012 00:02:30 -0700 (PDT) In-Reply-To: <201203130722.48489.hselasky@c2i.net> References: <201203120915.18908.hselasky@c2i.net> <201203130722.48489.hselasky@c2i.net> Date: Tue, 13 Mar 2012 02:02:30 -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 07:02:31 -0000 On Tue, Mar 13, 2012 at 1:22 AM, Hans Petter Selasky wro= te: > 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 to= o. >> > >> > >> > In the beginning of the log I see that in the successful case we recei= ve >> > 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=3D0xffffff8460883180 -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"); break; >> > =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(). =A0However, 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? =A0Is this the >> USB protocol which is "down rev'ed"? =A0If 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 I'm curious what the "down reving" means, and whether it is a USB thing or something else. I wonder if it could be a clue to help figure out the actual issue I'm faci= ng. Also, the missing interrupt notion has come into play before while trying to investigate this in the past -- if you could come up with a method that could eliminate that as a cause altogether, I think it would a big step. Of course, a method to show that missing interrupts are absolutely the problem, that would be great too :) -Brandon