From owner-p4-projects@FreeBSD.ORG Tue Dec 16 18:27:34 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id C76021065675; Tue, 16 Dec 2008 18:27:33 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DF7106564A for ; Tue, 16 Dec 2008 18:27:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4D57A8FC18 for ; Tue, 16 Dec 2008 18:27:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mBGIRSKF015261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 10:27:29 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4947F310.5050403@freebsd.org> Date: Tue, 16 Dec 2008 10:27:28 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Hans Petter Selasky References: <200812122326.mBCNQX6w024511@repoman.freebsd.org> <200812141623.51473.hselasky@c2i.net> <494598B0.9090501@freebsd.org> <200812161722.06337.hselasky@c2i.net> In-Reply-To: <200812161722.06337.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Perforce Change Reviews Subject: Re: PERFORCE change 154573 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 18:27:34 -0000 Hans Petter Selasky wrote: > On Monday 15 December 2008, Sam Leffler wrote: > >> Hans Petter Selasky wrote: >> >>> On Saturday 13 December 2008, Sam Leffler wrote: >>> >>>> Hans Petter Selasky wrote: >>>> >>>>> On Saturday 13 December 2008, Sam Leffler wrote: >>>>> >>>> No. But if you are interested in helping debug the problem I'm happy to >>>> send you debug output. The controller rejects all cmds setting the >>>> ERRINT status bit. The qTD contents and xfer contents look fine but I >>>> haven't been able to identify the cause given the overlay qTD contents. >>>> I'm in the process of collecting comparative traces from linux where usb >>>> works. >>>> >>> Send me the EHCI traces and I will have a look at it. Have you tried >>> USB2? The patches which you need to apply should be similar. >>> >> This is what I get w/ sysctl hw.usb.ehci.debug=6 for the first cmd >> submitted after card insert: >> >> > > >> Subsequent cmds fail similarly. I don't see the issue and don't >> understand how to use the overlay qTD information to pinpoint the reason >> the controller is rejecting the request. >> >> This happens w/ either of the 2 USB ports (1 port / controller): >> >> > > Hi Sam, > > The overlay qTD is a copy of the last processed QTD. You might need to do a > cache invalidate on the memory region before reading it. > Yes, this is what the docs says about the overlay qTD but what do the 2nd and later words mean? They went from: buffer[0]=0x014b8a3c buffer[1]=0x00000000 buffer[2]=0x00000000 buffer[3]=0x00000000 buffer[4]=0x00000000 to: buffer[0]=0x014b8a3c buffer[1]=0x00000008 buffer[2]=0x00000000 buffer[3]=0x00000000 buffer[4]=0x00000000 All memory allocated to hold usb data structures are allocated coherent so should not require an invalidate. I have also inserted explicit dcache invalidates while debugging this issue "just in case". USB works fine on another xscale platform where the usb controller is on the pci bus so I'd expect any cache coherency issues to already be dealt with (I found the PIO cache invalidate issue I fixed a while back on this other board). > What I see: > > - The first TD completed successfully, and that TD had a lower physical memory > adddress than the one that failed. > > buffer[0]=0x01091fc8 > > vs: > > buffer[0]=0x014b8a3c > > - Halted usually means that that you had a STALL token sent from the device to > the host, which indicates that the contents of the SETUP packet (PID=2), in > the first TD did not contain valid data, possible due to a missing cache > flush. > > return ((status & EHCI_QTD_HALTED) ? > USB_ERR_STALLED : USB_ERR_NORMAL_COMPLETION); > > So maybe this answers one question I have; is this error from the device or the controller? Am I actually talking to the device? It appears the controller is functional as I get interrupts, get status for things like ports, etc. Remember this is a big-endian host. On another xscale platform the usb controller is on the pci bus and we setup xfers (dma+pio) to be swizzled by the byte lane hardware so everything just works wrt little-endian-ness. I've been searching for something byte-order related that is missing. The linux usb code swizzles descriptor contents on the host but I don't see it doing anything to the data sent to the device; it's still little-endian. Sam