Date: Tue, 22 Apr 2008 20:00:51 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Mark Tinguely <tinguely@casselton.net> Cc: freebsd-arm@freebsd.org, jhb@freebsd.org Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit (more) Message-ID: <200804222000.55016.hselasky@c2i.net> In-Reply-To: <200804221650.m3MGol5o081637@casselton.net> References: <200804221650.m3MGol5o081637@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark, On Tuesday 22 April 2008, Mark Tinguely wrote: > > I've found a new issue :-( > > > > The OHCI driver does not work in 8-current when using the USB P4 > > project. I get garbage data when I do USB transfers. I suspect that there > > is something wrong with the cache flush and invalidate stuff in relation > > to bus_dma. I have carefully reviewed the OHCI driver and it uses the > > "bus_dmamap_sync" function properly. > > > > Using my USB patchset to build the same USB code on 7-current does not > > yield these problems. > > > > I see that there has been a lot of changes to "sys/arm/arm/pmap.c" for > > example. > > I quickly looked at the new_usb_1_7_3 code and noticed that it should be > allocation memory with BUS_DMA_COHERENT flag set. What this means is > after the memory is allocated, a new, non-cachable VM address is allocated > and used in the place of the original address. That is the NetBSD specific part of the code. In the FreeBSD specific part of the code I have: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb/usb%5fsubr.c&REV=104 Line 2730: /* allocate memory */ if (bus_dmamem_alloc( utag->tag, &ptr, (BUS_DMA_WAITOK | BUS_DMA_COHERENT), &map)) { goto error; } > > I *think* this new address lives in DMA S/G lists and should not be mapped > into an address space except to temporarily to copy data in/out. I will > assume this assumption is incorrect and look through the pmap code all over > again. Is there a function I can call that will tell if the memory I get is in cache enabled memory or not ? If there are any prints you want me to add in the kernel code I can easily do that within short time. > > > Do you have a clue about what is causing this ? > > > > --HPS > > > > Output from 7-current: > > > > usb0: 12Mbps Full Speed USB v1.0 > > uhub0: <Atmel OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usb0 > > uhub0: 2 ports with 2 removable, self powered > > uplcom0: <Prolific Technology Inc. USB-Serial Controller D, class 0/0, > > rev 1.10/4.00, addr 2> on usb0 > > usbd_alloc_device: set address 3 failed (ignored) > > usbd_alloc_device: getting device descriptor at addr 3 failed! > > uhub0:uhub_reattach_port: could not allocate new device! > > mmc0: setting transfer rate to 30.000MHz > > > > Output from 8-current: > > > > uplcom0: <???????? ????????, class 0/0, rev 1.10/4.00, addr 2> on usb1 > > uplcom0: failed to set configuration, error=USBD_ERR_SHORT_XFER > > device_attach: uplcom0 attach returned 6 > > There are two clues of short transfers - could that be a clue? > 1) attach's descriptor string is only 17 character rather than > expected 48 - and the 17 characters are not Unicode. I think what has happend is that when the USB code is reading back the OHCI transfer descriptors after that the transfer has completed we are still looking at the old length field which then tells the USB stack that the transfer is short. It is not "SET_CONFIG" that fails, but probably reading the USB descriptors. > 2) set configuration has a USBD_ERR_SHORT_XFER error. > > I don't know if turning on USB debug printing will give more clues. If I turn on full debugging the problem disappears, which I think is because the CPU cache is used up due to the excessive prints which the following debug level settings cause: sysctl hw.usb.ohci.debug=16 sysctl hw.usb.debug=15 > > I will look through the pmap code and see if I can chase up something. I see one problem: "malloc" is used by BUS-DMA to allocate DMA memory having a size less than PAGE_SIZE. What happens when you have multiple DMA allocations in the same PAGE and you then turn on/off the CPU caching on a per allocation/free basis ? Mark, I really appreciate that you look into this. --HPS PS: If you need to talk I have AIM/ICQ/MSN/Jabber/IRC and SIP.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804222000.55016.hselasky>