Re: panic: assertion failed in iflib_txq_drain()

From: Michael Tuexen <tuexen_at_FreeBSD.org>
Date: Sat, 18 Apr 2026 20:06:17 UTC
> On 18. Apr 2026, at 21:51, Drew Gallatin <gallatin@freebsd.org> wrote:
> 
> 
> That is indeed the proper fix.   I just reviewed & tested it.  Thank you so much!
Thanks for the quick review.
The fix is committed in:
https://cgit.FreeBSD.org/src/commit/?id=cca22c36c306dfabe13b1d1de10e8d27ef3c3bce <https://cgit.freebsd.org/src/commit/?id=cca22c36c306dfabe13b1d1de10e8d27ef3c3bce>

Best regards
Michael
> 
> Until it lands, another workaround is to use the new, cheaper, faster, simpler iflib transmit routine by setting the tunable
> 
> dev.$NIC.$UNIT.iflib.simple_tx=1
> 
> Eg, dev.bnxt.0.iflib.simple_tx=1
> 
> In loader.conf
> 
> I plan to deprecate the current complex transmit routine (mp_ring) in favor of the simple mechanism, and I confess that I sometimes don't test "straightforward" changes like this on mp_ring.  I'll try to get better about that.
> 
> Drew
> 
> On Sat, Apr 18, 2026, at 3:12 PM, Michael Tuexen wrote:
>> 
>> 
>> > On 18. Apr 2026, at 21:09, Drew Gallatin <gallatin@freebsd.org> wrote:
>> > 
>> > Sorry, looking into this now.  I did not test this change with the mp_ring path.. i don't see how fixing the counters could cause this panic.   Looking at it now..
>> Hi Drew,
>> 
>> I think https://reviews.freebsd.org/D56509 fixes it.
>> 
>> Best regards
>> Michael
>> > 
>> > Drew
>> > 
>> > On Sat, Apr 18, 2026, at 1:38 PM, Michael Tuexen wrote:
>> >> 
>> >> 
>> >> > On 18. Apr 2026, at 19:14, David Wolfskill <david@catwhisker.org> wrote:
>> >> > 
>> >> > On Sat, Apr 18, 2026 at 03:53:33PM +0200, Michael Tuexen wrote:
>> >> >> ...
>> >> >>> So... one of the machines on which I track head got this, as well -- my
>> >> >>> (mostly-)headless build machine.  (2 laptops, updated in sync with the
>> >> >>> build machine, did not panic.  One of those also uses a wired NIC.)
>> >> >> Do the network drivers of the machines not being affected use iflib?
>> >> > 
>> >> > Apparently not -- they are em(4), iwm(4), & iwn(4), while the panicking
>> >> > machine uses igb(4).
>> >> > 
>> >> >> I do see the problem also on one of my machines and local testing shows that
>> >> >> https://cgit.FreeBSD.org/src/commit/?id=3fade68cfdf95ee0b517b5d69b270bd8da633404 <https://cgit.freebsd.org/src/commit/?id=3fade68cfdf95ee0b517b5d69b270bd8da633404>
>> >> >> is the problem. At least reverting it locally resolves the problem.
>> >> >> Can you confirm this?
>> >> > 
>> >> > I can, and do:  after reverting main-n285140-3fade68cfdf9 & rebuilding,
>> >> > I am able to ssh in without issue; the machine reports:
>> >> > 
>> >> > freebeast(16.0-C)[2] uname -aUK
>> >> > FreeBSD freebeast.catwhisker.org 16.0-CURRENT FreeBSD 16.0-CURRENT #549 main-n285180-23a84efeb191: Sat Apr 18 17:01:25 UTC 2026     root@freebeast.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1600015 1600015
>> >> > 
>> >> > Thanks!
>> >> You could also disable TSO. I will put up a review for a fix soon.
>> >> 
>> >> Best regards
>> >> Michael
>> >> > 
>> >> > Peace,
>> >> > david
>> >> > -- 
>> >> > David H. Wolfskill                              david@catwhisker.org
>> >> > 
>> >> > See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>> >> 
>> >> 
>> >> 
>> > 
>> 
>> 
>