On Tue, Jul 01, 2008 at 11:00:17PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jul 01, 2008 at 10:42:40PM +0200, Christoph Egger wrote:
> > Does this diff help ?
> > http://www.netbsd.org/~cegger/if_bnx.diff
>
> Given that the problem vanishes with UP, I would expect it to be the
> same problem cube fixed e.g. for msk(4).
I wonder about that. The problem I fixed in nfe(4), {m,}sk(4) and
(awaiting proper testing) wpi(4) is the following: the driver uses a
private pool for mbuf data allocation, and maintains a list of active
and inactive elements. As the function that releases said elements
might now run concurrently to the function retaining them when before
all this was protected by splnet() (whether the freeing function
doesn't run at splnet() anymore, and therefore can be interrupted by
the device, or must run on the other CPU in order to have concurrency
happening, that I don't know), the list has to be protected with a
mutex. So it's a very precise issue (there are probably still a few
drivers out there that need a similar treatment).
bnx(4) doesn't use a private pool. If the MTU is "normal", it uses
MCLGET(9), which is fine. In the other case, it uses MEXTMALLOC(9),
which actually doesn't seem very suitable for DMA operation, so I would
expect issues because of that, but it's definitely not the same issue as
in msk(4).
--
Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgp2giPKtOVBm.pgp
Description: PGP signature