cvs commit: src/sys/dev/em if_em.c if_em.h
mattjreimer at gmail.com
Tue Aug 15 18:29:02 UTC 2006
On 8/15/06, John Baldwin <jhb at freebsd.org> wrote:
> On Tuesday 15 August 2006 02:49, Pyun YongHyeon wrote:
> > On Mon, Aug 14, 2006 at 01:30:37PM -0700, Matt Reimer wrote:
> > > On 8/13/06, Pyun YongHyeon <yongari at freebsd.org> wrote:
> > > >yongari 2006-08-14 01:50:54 UTC
> > > >
> > > > FreeBSD src repository
> > > >
> > > > Modified files:
> > > > sys/dev/em if_em.c if_em.h
> > > > Log:
> > > > Overhaul Rx path to recover from mbuf cluster allocation failure.
> > > > o Create one more spare DMA map for Rx handler to recover from
> > > > bus_dmamap_load_mbuf_sg(9) failure.
> > > > o Make sure to update status bit in Rx descriptors even if we failed
> > > > to allocate a new buffer. Previously it resulted in stuck condition
> > > > and em_handle_rxtx task took up all available CPU cycles.
> > > [snip]
> > >
> > > Is it possible that the RELENG_4 if_em driver would suffer from the
> > > same problems, particularly the stuck/CPU-chewing problem?
> > >
> > I think the problem exist in RELENG_4 too. If em_get_buf() fails em(4)
> > exits main Rx loop but still does not update status bits in the Rx
> > descriptor. I think you can easily experiment the problem with
> > "kern.ipc.nmbclusters".
> Hmm, well, I've already backported a lot of the changes in RELENG_6 to em(4)
> in RELENG_4 at work. I've got some more stuff to backport, but then I can
> apply this as well and see if folks want to test it.
I think I might have run into this bug last week. We have a couple of
production boxes running RELENG_4 that use em(4), so I'll have to be
careful, and I may not be able to test it immediately, but I'm willing
to give it a try.
More information about the cvs-src