mbuf pool allocator can sleep in interrupt context?

[Thor Simon]

We have a very busy system (it is a load test target) which continually
has several thousand TCP connections open and often has bursts of thousands
of nearly simultaneous connection requests. It's running a netbsd-5 branch
i386 kernel.

We have been seeing LOCKDEBUG panics. They appear to result from the wm
driver attempting to get an mbuf in its receive interrupt handler. There
are none available in the pool (or it's below its low water mark) so it
tries to allocate. This causes a sleep lock attempt in interupt context
and over-the-side we go.

Has anyone else seen this? Is there an obvious fix? I don't really want
to go turning sleep locks to spin locks if I don't have to.

[Darren Reed]

Post by Thor Simon
We have a very busy system (it is a load test target) which continually
has several thousand TCP connections open and often has bursts of thousands
of nearly simultaneous connection requests. It's running a netbsd-5 branch
i386 kernel.
We have been seeing LOCKDEBUG panics. They appear to result from the wm
driver attempting to get an mbuf in its receive interrupt handler. There
are none available in the pool (or it's below its low water mark) so it
tries to allocate. This causes a sleep lock attempt in interupt context
and over-the-side we go.
Has anyone else seen this? Is there an obvious fix? I don't really want
to go turning sleep locks to spin locks if I don't have to.

Is something using M_WAIT where it should not?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de