From owner-p4-projects@FreeBSD.ORG Tue Dec 16 18:44:26 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 9A6B51065677; Tue, 16 Dec 2008 18:44:26 +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 5EE721065673 for ; Tue, 16 Dec 2008 18:44:26 +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 1F8868FC17 for ; Tue, 16 Dec 2008 18:44:26 +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 mBGIiN9j015405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 10:44:23 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4947F707.4090309@freebsd.org> Date: Tue, 16 Dec 2008 10:44:23 -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> <4947F310.5050403@freebsd.org> In-Reply-To: <4947F310.5050403@freebsd.org> 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:44:26 -0000 Sam Leffler wrote: > 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. > Er, scratch the "dma" byte swizzle comment, it's just pio that's handled by the byte lane h/w in the pci-ahb bus glue. Sam