Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Jan 2001 22:52:56 +0100 (CET)
From:      =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        freebsd-alpha@FreeBSD.ORG
Subject:   Re: bus_dmamap_load 
Message-ID:  <Pine.LNX.4.10.10101042232100.405-100000@linux.local>
In-Reply-To: <14932.59983.360316.243974@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help


On Thu, 4 Jan 2001, Andrew Gallatin wrote:

> G=E9rard Roudier writes:
>  > Btw, you missed the `de' driver that also performs bus_dmamap_load() o=
n
>  > mbuf's as a possible candidate.
>  >=20
>=20
> Does it actually do this?  I see all the code protected by:
>=20
> =09#if defined(TULIP_BUS_DMA)
>=20
> But I do not see TULIP_BUS_DMA defined anywhered.  I think it was
> inherited from NetBSD and the define was clobbered in

Indeed. I missed that.

But the sym driver only calls bus_dmamap_load() in 2 places:

1) Using an hardcoded value for buflen (1 PAGE) for internal data
  structures allocation.

2) Using `csio->dxfer_len' when preparing an IO for the DMA.

Place (1) is unlikely to lead to a size problem, and (2) is provided by
CAM or upper layer. If there is a driver bug in driver code path (2), then
it should likely have already triggerred, in my opinion.

  G=E9rard.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10101042232100.405-100000>