armani also pointed out the same issue with
my MCLGETI diff for xl(4).
I've adapted bluhm's patch and it works fine
here.
Any feedback ?
Index: src/sys/dev/ic/xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.99
di
The timeout seems like a very large amount of time.
All the drivers used to contain reuse-the-last-mbuf tricks. With
MCLGETI, this hack is removed because MCLGETI should provide at least
1 mbuf. But... what if the actual total mbuf pressure is so high that
MCLGETI can't get it. Then a driver w
On Wed, Mar 23, 2011 at 08:17:11AM +0100, Mark Kettenis wrote:
> > From: David Gwynne
> > Date: Wed, 23 Mar 2011 14:21:19 +1000
> >
> > makes sense to me.
>
> While it is a potential solution for the problem at hand (and one I
> didn't consider yet) can we step back and think whether this is a
>
> From: David Gwynne
> Date: Wed, 23 Mar 2011 14:21:19 +1000
>
> makes sense to me.
While it is a potential solution for the problem at hand (and one I
didn't consider yet) can we step back and think whether this is a
solution that will work for *all* our ethernet drivers?
> On 23/03/2011, at 1
makes sense to me.
On 23/03/2011, at 10:28 AM, Alexander Bluhm wrote:
> Hi,
>
> When the kernel runs out of mbuf clusters, the hme receive ring may
> become empty. In that case, the hme driver cannot recover as the
> ring is only filled after receiving data. My fix is to fill an
> empty receiv
Hi,
When the kernel runs out of mbuf clusters, the hme receive ring may
become empty. In that case, the hme driver cannot recover as the
ring is only filled after receiving data. My fix is to fill an
empty receive ring every second.
ok?
bluhm
Index: dev/ic/hme.c
=
