Date: Fri, 17 Jan 2003 18:11:11 +0100 From: Thomas Moestl <tmm@freebsd.org> To: Harti Brandt <brandt@fokus.gmd.de> Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030117171111.GC304@crow.dom2ip.de> In-Reply-To: <20030117171317.F44530@beagle.fokus.gmd.de> References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de> <20030117171317.F44530@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2003/01/17 at 17:30:13 +0100, Harti Brandt wrote: > On Fri, 17 Jan 2003, Thomas Moestl wrote: > TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to > TM>see what would cause presz to be 0 in the first place in your example - > TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845. > TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all > TM>else would be a bogus tag. > > Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and > maxpres. > > On a related topic. I just got a panic when actually using the map. There > are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These > seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k > PDU is segmented into 32 or more mbufs. I think, that NSEGS should be > large enough to handle 64k PDUs so it should probably be 40 or so. BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only thing to limit is the stack space used by the segment array. In the current setting, 272 bytes are used at most, which is less than 1.5 minimal function frames. Values such as 64 should still be OK. > The other problem is, that bus_dmamap_load_mbuf happily will try to load > such a PDU. There is a check in iommu_dvmamap_load_buffer for the segment > count and it sets error to EFBIG, but the function than fails to check > that error. The return at the end should probably read 'return (error)'. Bah, that's what you get when you reorganize code too much. It should just return (EFBIG) instead of setting error. > I try your patch and tell you the results. Thanks. Looking at the code you pasted above, I'm afraid that they won't help though. The only possibility for a simple map creation to break things in that way is that it changes the available DVMA space and may cause this or other maps to be pruned. In both cases, another driver must be using DMA already or do load or unload operations for this to take any effect. So, can you please tell me which other DMA-using devices you have in that box, so that I can try to figure out the possible interactions? - Thomas -- Thomas Moestl <tmoestl@gmx.net> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030117171111.GC304>