Date: Thu, 16 Sep 2004 04:07:50 -0000 From: Dennis Berger <db@nipsi.de> To: pf4freebsd@freelists.org Subject: [pf4freebsd] Re: if_fxp.c.patch Message-ID: <40D88EC8.2070809@nipsi.de> In-Reply-To: <200406222150.30587.max@love2party.net> References: <40D760E5.7000903@nipsi.de> <200406222003.36024.max@love2party.net> <40D88B97.5090207@nipsi.de> <200406222150.30587.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier wrote: >On Tuesday 22 June 2004 21:42, Dennis Berger wrote: > > >>Max Laier wrote: >> >> >>>On Tuesday 22 June 2004 10:59, Dennis Berger wrote: >>><...> >>> >>> >>> >>>>>Spoken too quick ... I am able to reprocure and have a dump now, thanks >>>>>for the head up ... I'll inform you when I have a conclusion. Thanks. >>>>> >>>>> >>>Okay ... good news - should be fixed now/was not lock related at all. Bad >>>news - it was plain stupidity. I forgot to check whether IFQ_DRV_DEQUEUE >>>was >>> >>> >>so a check around IFQ_DRV_DEQUEUE was needed, why is this check needed >>by the way? >>does IF_DEQUEUE check this normally? >> >> > >No ... IF_DEQUEUE would just "always" succeed. IFQ_DEQUEUE can fail even if >not IFQ_IS_EMPTY (under rate limiting e.g.). Most drivers already do this >check (as w/ kernel threads one could remove a packet from the queue even w/ >the old macros) - so maybe this can be considered a bug in if_fxp.c (which >will be fixed with the altq transformation.) > > > ahh good to know >>>really able to give us an mbuf. >>> >>>Please check out the new diff and test again. Thanks and sorry. >>> >>> >>I'll do that >> >> > >Thanks > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40D88EC8.2070809>