From owner-freebsd-usb@FreeBSD.ORG Tue Mar 13 06:57:44 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 E90B1106566B; Tue, 13 Mar 2012 06:57:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 49ED08FC08; Tue, 13 Mar 2012 06:57:43 +0000 (UTC) Received: by wern13 with SMTP id n13so230230wer.13 for ; Mon, 12 Mar 2012 23:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ECVMu0Qi1AEeX36cr/ZKuZyCZlw2MluRBlpJrI+THlE=; b=ZLe4BF0AnDsG9j0uOdSn07NIzWKnKweuHy4xortW3PPw0aMUPkbRTLoj0pzAABeNDp 92j+n5DqNs9/LDlXmQvozsMLO9mB5HLEMHD/vocV/PdnNuSzloC0bg42wGbk8BiFJk74 xjce9Epbso8EkSQwVE2ZTEoM3ngMSVuFEr88bwESE4An/Q2jFT+C7h1m/t82zF42rnYP 8qMGSqkr4ol4kR+I5o04rRF2zZ3SaEHgidBz2tQWaE5iIKdn7s2FiehwbzCi01I4D505 hk8LrAGGP3W2ucoDyD6VPUpjGHsMVb3GZJgtik/nyJ68nDqdOzkCYpCkNKNaT9Y3cld4 6TaQ== Received: by 10.180.83.72 with SMTP id o8mr4574506wiy.5.1331621863368; Mon, 12 Mar 2012 23:57:43 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n15sm40630742wiw.6.2012.03.12.23.57.41 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 23:57:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F5EEFE4.2020402@FreeBSD.org> Date: Tue, 13 Mar 2012 08:57:40 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brandon Gooch References: <201203120915.18908.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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:57:45 -0000 On 03/13/12 05:37, 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? It is SCSI protocol that "down rev'ed", not USB. AFAIK this came from old SPI era when SCSI protocol version was same for device and controller, limited by transport type. At this moment, with many possible transports, I believe this message lost its informativeness. -- Alexander Motin