Date: Wed, 07 Jan 2009 19:58:27 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: Mark Tinguely <tinguely@casselton.net> Cc: arm@freebsd.org, alfred@freebsd.org Subject: Re: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... Message-ID: <4964FB53.8040607@semihalf.com> In-Reply-To: <200901071846.n07IkE41053149@casselton.net> References: <200901071846.n07IkE41053149@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Tinguely wrote: >> On Wed, 7 Jan 2009 17:51:48 +0100 >> Hans Petter Selasky <hselasky@c2i.net> mentioned: >> >> > >> > cpu_idcache_wbinv_all(); /* and this line */ >> > >> > bus_dmamap_sync(pc->tag, pc->map, >> > BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); >> > } >> > >> > Then everything worked. >> > >> > I think the ones that have been working on busdma & cache sync issues recently >> > are to blame. I will try to investigate more. >> > >> >> Hmm, this might be the same problem with duplicate dcache entries raj reported >> recently on arm@. I tried replacing cpu_idcache_wbinv_all with busdma PREREAD >> and PREWRITE sync, but this doesn't work. >> >> BTW, even with cpu_idcache_wbinv_all change I'm still observing some CAM >> request retires under high load, so we really seem to have a generic cache >> issue somewhere. >> >> - -- >> Stanislav Sedov >> ST4096-RIPE > > It could be the same problem if there is a duplicate kernel mapping. If > there is no duplicate kernel mapping, then there is another cache leak > somewhere. > > Because a duplicate kernel mapping currently does not turn off the > caches in either mapping, even the wb/inv trick is a cache russian rollette > situation. > > If someone wants to look at very rough code - I don't have a current box > to even compile it, I don't know anyone besides myself and Olivier Houchard > that is up on the ARM pmap code, but I am looking for someone who will > give this an eyeball. There can be consequences to adding pv_entrys where none > existed before. I don't want people to blindly download and attempt to run it. Mark, I'd like to look at your code, I guess also Grzegorz (CC'd) who knows ARM pmap code very well will be much interested in your thoughts on resolving the multiple virtual mappings issue, once and for all. How can we access your said proto/rough attempts? Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4964FB53.8040607>