Date: Wed, 2 Jul 2003 16:28:30 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Maxime Henrion <mux@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/fatm if_fatm.c Message-ID: <20030702162128.S30117@beagle.fokus.fraunhofer.de> In-Reply-To: <20030702140500.GJ42121@elvis.mu.org> References: <200307021353.h62Drfvp083130@repoman.freebsd.org> <20030702140500.GJ42121@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Jul 2003, Maxime Henrion wrote: MH>Hartmut Brandt wrote: MH>> harti 2003/07/02 06:53:41 PDT MH>> MH>> FreeBSD src repository MH>> MH>> Modified files: MH>> sys/dev/fatm if_fatm.c MH>> Log: MH>> Make the bus_dma_tag_create use NULL for the lock arguments. We are MH>> careful to call all map_load calls with BUS_DMA_NOWAIT because we MH>> really don't want some PDUs to wait while others go out - ATM guarantees MH>> the ordering of cells and also of PDUs (within one VC, that is). With MH>> BUS_DMA_NOWAIT bus_dmamap_load should never return EINPROGRESS. MH> MH>FWIW, this is true since yesterday only, because I updated all the other MH>busdma backends which use bounce pages to behave this way. Previously, MH>this was only true for x86 and amd64. When locking through all the bus_dma implementations I always wonder whether it is possible to factor out the common code (except for sparc64). They all lock the same, just with different small bugs... MH>I'll document the BUS_DMA_NOWAIT flag for bus_dmamap_load() in bus_dma.9 MH>soon. That is nice to hear. Someone with enough bus_dma- and man- knowledge could also have a look at docs/53271 and docs/53751. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030702162128.S30117>