Date: Fri, 17 Jan 2003 17:30:13 +0100 (CET) From: Harti Brandt <brandt@fokus.gmd.de> To: Thomas Moestl <tmm@freebsd.org> Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030117171317.F44530@beagle.fokus.gmd.de> In-Reply-To: <20030117160857.GB304@crow.dom2ip.de> References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Jan 2003, Thomas Moestl wrote:
TM>Can you please make try the attached patch? I mostly posted it to this
TM>list before it fixes some bogons which may be related (bugs in the
TM>lowaddr and boundary handling) and adds some diagnostics. I also fixed
TM>the two issues you noted below and KASSERT()ed that presz can't be 0.
TM>
TM>Can you also please post the exact map and tag creation calls?
if (bus_dma_tag_create(NULL, 1, 0,
BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL,
HE_MAX_PDU, 3 * HE_CONFIG_MAX_TPD_PER_PACKET, HE_MAX_PDU, 0,
&sc->tx_tag)) {
device_printf(dev, "could not allocate TX tag\n");
error = ENOMEM;
goto failed;
}
error = bus_dmamap_create(sc->tx_tag, 0, &t->map);
if (error != 0) {
HE_MAX_PDU is 65535 and HE_CONFIG_MAX_TPD_PER_PACKET is 11.
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.
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)'.
I try your patch and tell you the results.
Thanks,
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
brandt@fokus.gmd.de, brandt@fokus.fhg.de
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?20030117171317.F44530>