From nobody Tue Feb 08 22:34:10 2022 X-Original-To: freebsd-transport@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EEA7E19AB201 for ; Tue, 8 Feb 2022 22:34:23 +0000 (UTC) (envelope-from gallatin@netflix.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jtd9C1qnyz3DgJ for ; Tue, 8 Feb 2022 22:34:23 +0000 (UTC) (envelope-from gallatin@netflix.com) Received: by mail-ej1-x636.google.com with SMTP id fy20so2027077ejc.0 for ; Tue, 08 Feb 2022 14:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Au9xsy+ehRs5h04FOeeasEpySwPeowcqWUgC1TGlupo=; b=KZ1nQ/yV9Nl77/OSQVjE1pQTlzhA8mW4rzBq0jGVhv6wq5TFeojNHf/Ru9yw5DGGbO QldGLZThTX2wXFPXZb1vXrAX6rPsd3q6nVWX7MNsHrdGmuy2GxmaT9lW6YAFQWbzbblt DN5xgYp+wZAzzk67kUb0MPZQOjAdG5Aj1N3no= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Au9xsy+ehRs5h04FOeeasEpySwPeowcqWUgC1TGlupo=; b=2ePHJF4cqKRrYT90KTm3UlI19ZiI2v+mUpTAwNFvz+QMwJE5LgYVlxsK7AxRrEQ4NC FfIwxDYOPgnQrXpKLGAspTXq504TaTHknLA7BrYU0d1uBRGvMx5X3F3HX4YTuUhw56Lr i6IgWYM+nFnlKpeqlsCXqCxdJFHgAedjjI3YzGym2TTjZ9Iz/gA6xUk7qaSSqhGsRCYT HI9lbDJqhVZoGIzJdHp62PWJasjl6tr3vgdOB9iztJ/MWpQ4lVA7StTpWLKT8RCIx2cA XynwNHMvMx905XSPZtEHL26yy2TF+He1pcCGW5J/IcHK0zPd/cJTBn0jHNCvYMj1pVDs hf+g== X-Gm-Message-State: AOAM530YSpeBcApnsydU5Aj76hH4gJjarR8UKY2yxO7vSO6jm648d8oz znrZIr3Na0r0mEmCbqWDqwxkw3ktmmSKEGDv0c6z1s3oyw== X-Google-Smtp-Source: ABdhPJwCZ7MKrUE6KHzPhaByaqvOSn4IBVOwLEr4+2WFuNL/NXFL7JXzN088/ikgTJh/HG9WNiEp04eUSU4eidN1IWM= X-Received: by 2002:a17:906:1804:: with SMTP id v4mr5388570eje.512.1644359662172; Tue, 08 Feb 2022 14:34:22 -0800 (PST) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-transport List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-transport@freebsd.org X-BeenThere: freebsd-transport@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Drew Gallatin Date: Tue, 8 Feb 2022 17:34:10 -0500 Message-ID: Subject: Re: panic: syncache: mbuf too small To: "Bjoern A. Zeeb" Cc: freebsd-transport@freebsd.org Content-Type: multipart/alternative; boundary="0000000000008c7f2505d78951b3" X-Rspamd-Queue-Id: 4Jtd9C1qnyz3DgJ X-Spamd-Bar: ------------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netflix.com header.s=google header.b="KZ1nQ/yV"; dmarc=pass (policy=reject) header.from=netflix.com; spf=pass (mx1.freebsd.org: domain of gallatin@netflix.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=gallatin@netflix.com X-Spamd-Result: default: False [-12.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[netflix.com:s=google]; FREEFALL_USER(0.00)[gallatin]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-transport@freebsd.org]; NEURAL_SPAM_SHORT(0.32)[0.323]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[netflix.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; WHITELIST_DMARC(-7.00)[netflix.com:D:+]; DMARC_POLICY_ALLOW(-0.50)[netflix.com,reject]; MLMMJ_DEST(0.00)[freebsd-transport]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; WHITELIST_SPF_DKIM(-3.00)[netflix.com:d:+,netflix.com:s:+] X-ThisMailContainsUnwantedMimeParts: N --0000000000008c7f2505d78951b3 Content-Type: text/plain; charset="UTF-8" I don't think the size has changed recently. However, there is a size difference for pkthdrs (and hence MHLEN) on 32-bit platforms vs 64-bit platforms. There are a number of bad ways to handle this. Eg, don't permit Ipv6 on these interfaces, make these interfaces chain their headers, assuming they can do s/g dma, make them copy to a contiguous buffer. Make mbufs bigger. All of the things I can think of are ugly. On Tue, Feb 8, 2022 at 5:14 PM Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Tue, 8 Feb 2022, Drew Gallatin wrote: > > > I suspect that it's ic->ic_headroom, which seems to be driver dependent. > > And that its going kaboom because of the combo of IPv6 plus some driver > > with a large ic_headroom.. > > Yeah, one of the Realtek drivers I was looking at sets it to 40/48 > depending on chipset. > > Others vendor drivers are in the order of 26/28-ish max which would be > an exact fit (without UDP tunneling)... > > > It would be really unfortunate if we had to expand mbufs because of some > > wifi driver. Perhaps they could be taught to chain headers.. > > Realtek is doing a few "funny" things there; a lot of being single > segment DMAs up-to 12k-ish .. not being helpful at all. > > I'll go and see if I can figure it out for this one specifically > then *sigh*. For as long as no other drivers do similar things > I am happy to work around it. > > > Hmm bwi(4) is probably not much used anymore as from a quick glance > that is also going big (82 by manual counting) and bwn(4) even more? > > So either our size massively shrunk in mbufs or that problem was there > a decade ago already ... and we didn't notice? > > > /bz > > > > On Tue, Feb 8, 2022 at 2:45 PM Bjoern A. Zeeb < > > bzeeb-lists@lists.zabbadoz.net> wrote: > > > >> On Tue, 8 Feb 2022, Bjoern A. Zeeb wrote: > >> > >>> On Tue, 8 Feb 2022, Drew Gallatin wrote: > >>> > >>>> Can you examine max_linkhdr? > >>> > >>> Yes, was still sitting in ddb (thankfully watchdog got disabled): > >>> > >>> db> x max_linkhdr > >>> max_linkhdr: 58 > >>> > >>> And for consistency checks: > >>> > >>> db> x max_hdr > >>> max_hdr: 94 > >>> db> x max_datalen > >>> max_datalen: 14 > >>> db> x max_protohdr > >>> max_protohdr: 3c > >> > >> If I do the maths correctly: > >> > >> MHLEN = 168 (0x94 + 0x14) > >> > >> TCP_MAXHLEN = 60 - 24 = 36 TCP_MAXOLEN > >> > >> max_linkhdr = 88 > >> > >> 168 - 88 - 36 = 44 > >> > >> ipv6_hdr size = 40 > >> > >> Leaves us with 4 for the tcp_header again? Which would be 24? > >> > >> > >> Why would this not go kaboom all the time? > >> > >> Hmm I assume it's ieee80211_proto.c .. it changes max_linkhdr .. > >> > >> > >> > >> > >> > >>> db> show reg > >>> cs 0x20 > >>> ds 0x3b > >>> es 0x3b > >>> fs 0x13 > >>> gs 0x1b > >>> ss 0x28 > >>> rax 0x12 > >>> rcx 0x1 > >>> rdx 0xffffffff811f6d0a > >>> rbx 0xffffffff812e614c > >>> rsp 0xfffffe0007fa15a0 > >>> rbp 0xfffffe0007fa15b0 > >>> rsi 0x80 > >>> rdi 0xffffffff81e8cec0 cnputs_mtx > >>> r8 0x10 > >>> r9 0x1d0 > >>> r10 0xffffffff81cfa820 vga_conssoftc > >>> r11 0x10 > >>> r12 0xffffffff812961ab > >>> r13 0x28 > >>> r14 0x100 > >>> r15 0xfffffe000937a740 > >>> rip 0xffffffff80c545a7 kdb_enter+0x37 > >>> rflags 0x86 > >>> kdb_enter+0x37: movq $0,0x1283a5e(%rip) > >>> > >>> Found a console log; the system was idle, right after a boot for a few > >>> minutes. > >>> It's a lab machine having booted off IPv4 (grml) but also having IPv6 > on > >>> the network. > >>> > >>> According to terminal backlogs it was an incoming IPv6 ssh session > likely > >>> to have triggered this. Always great if things are "idle" and only few > >>> people > >>> to ask. > >>> > >>> it is amd64; main @ 773e3a71b2f11d422694495aca988d4c7143601b from Jan > >> 31st. > >>> > >>> /bz > >>> > >>> > >>>> Drew > >>>> > >>>> On Tue, Feb 8, 2022 at 1:58 PM Bjoern A. Zeeb < > >>>> bzeeb-lists@lists.zabbadoz.net> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I just came to a console finding this. The tree is from a few days > >> ago; > >>>>> is this known or should I investigate if it happens again? I sadly > >>>>> cannot > >>>>> dump on this machine. > >>>>> > >>>>> /bz > >>>>> > >>>>> db> show panic > >>>>> panic: syncache: mbuf too small > >>>>> db> where > >>>>> Tracing pid 0 tid 100014 td 0xfffffe000937a740 > >>>>> kdb_enter() at kdb_enter+0x37/frame 0xfffffe0007fa15b0 > >>>>> vpanic() at vpanic+0x1b0/frame 0xfffffe0007fa1600 > >>>>> panic() at panic+0x43/frame 0xfffffe0007fa1660 > >>>>> syncache_respond() at syncache_respond+0x777/frame 0xfffffe0007fa1730 > >>>>> syncache_add() at syncache_add+0xa71/frame 0xfffffe0007fa18c0 > >>>>> tcp_input_with_port() at tcp_input_with_port+0x14f5/frame > >>>>> 0xfffffe0007fa1a20 > >>>>> tcp6_input_with_port() at tcp6_input_with_port+0x69/frame > >>>>> 0xfffffe0007fa1a50 > >>>>> tcp6_input() at tcp6_input+0xb/frame 0xfffffe0007fa1a60 > >>>>> ip6_input() at ip6_input+0xc2f/frame 0xfffffe0007fa1b40 > >>>>> netisr_dispatch_src() at netisr_dispatch_src+0xaf/frame > >> 0xfffffe0007fa1ba0 > >>>>> ether_demux() at ether_demux+0x16e/frame 0xfffffe0007fa1bd0 > >>>>> ether_nh_input() at ether_nh_input+0x3fc/frame 0xfffffe0007fa1c30 > >>>>> netisr_dispatch_src() at netisr_dispatch_src+0xaf/frame > >> 0xfffffe0007fa1c90 > >>>>> ether_input() at ether_input+0x99/frame 0xfffffe0007fa1cf0 > >>>>> iflib_rxeof() at iflib_rxeof+0xcb3/frame 0xfffffe0007fa1e00 > >>>>> _task_fn_rx() at _task_fn_rx+0x7a/frame 0xfffffe0007fa1e40 > >>>>> gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa7/frame > >>>>> 0xfffffe0007fa1ec0 > >>>>> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame > >>>>> 0xfffffe0007fa1ef0 > >>>>> fork_exit() at fork_exit+0x80/frame 0xfffffe0007fa1f30 > >>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0007fa1f30 > >>>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > -- > Bjoern A. Zeeb r15:7 > --0000000000008c7f2505d78951b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think the size has changed recently.=C2= =A0 However, there is a size difference for pkthdrs (and hence MHLEN) on 32= -bit platforms vs 64-bit platforms.

There are = a number of bad ways to handle this.=C2=A0 Eg, don't permit Ipv6 on the= se interfaces, make these interfaces chain their headers, assuming they can= do s/g dma, make them copy to a contiguous buffer.=C2=A0 Make mbufs bigger= . =C2=A0 All of the things I can think of are ugly.

On Tue, Feb 8,= 2022 at 5:14 PM Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:<= br>
On Tue, 8 Feb 20= 22, Drew Gallatin wrote:

> I suspect that it's ic->ic_headroom, which seems to be driver d= ependent.
> And that its going kaboom because of the combo of IPv6 plus some drive= r
> with a large ic_headroom..

Yeah, one of the Realtek drivers I was looking at sets it to 40/48
depending on chipset.

Others vendor drivers are in the order of 26/28-ish max which would be
an exact fit (without UDP tunneling)...

> It would be really unfortunate if we had to expand mbufs because of so= me
> wifi driver.=C2=A0 =C2=A0Perhaps they could be taught to chain headers= ..

Realtek is doing a few "funny" things there; a lot of being singl= e
segment DMAs up-to 12k-ish .. not being helpful at all.

I'll go and see if I can figure it out for this one specifically
then *sigh*.=C2=A0 For as long as no other drivers do similar things
I am happy to work around it.


Hmm=C2=A0 bwi(4)=C2=A0 is probably not much used anymore as from a quick gl= ance
that is also going big (82 by manual counting) and bwn(4) even more?

So either our size massively shrunk in mbufs or that problem was there
a decade ago already ... and we didn't notice?


/bz


> On Tue, Feb 8, 2022 at 2:45 PM Bjoern A. Zeeb <
> bz= eeb-lists@lists.zabbadoz.net> wrote:
>
>> On Tue, 8 Feb 2022, Bjoern A. Zeeb wrote:
>>
>>> On Tue, 8 Feb 2022, Drew Gallatin wrote:
>>>
>>>> Can you examine max_linkhdr?
>>>
>>> Yes, was still sitting in ddb (thankfully watchdog got disable= d):
>>>
>>> db> x max_linkhdr
>>> max_linkhdr:=C2=A0 =C2=A0 58
>>>
>>> And for consistency checks:
>>>
>>> db> x max_hdr
>>> max_hdr:=C2=A0 =C2=A0 =C2=A0 =C2=A0 94
>>> db> x max_datalen
>>> max_datalen:=C2=A0 =C2=A0 14
>>> db> x max_protohdr
>>> max_protohdr:=C2=A0 =C2=A03c
>>
>> If I do the maths correctly:
>>
>> MHLEN =3D 168=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(0x94= =C2=A0 + 0x14)
>>
>> TCP_MAXHLEN =3D 60 - 24 =3D 36 TCP_MAXOLEN
>>
>> max_linkhdr =3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A088
>>
>> 168 - 88 - 36 =3D 44
>>
>> ipv6_hdr size =3D 40
>>
>> Leaves us with 4 for the tcp_header again?=C2=A0 Which would be 24= ?
>>
>>
>> Why would this not go kaboom all the time?
>>
>> Hmm I assume it's ieee80211_proto.c .. it changes max_linkhdr = ..
>>
>>
>>
>>
>>
>>> db> show reg
>>> cs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x20
>>> ds=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x3b
>>> es=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x3b
>>> fs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x13
>>> gs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x1b
>>> ss=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x28
>>> rax=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A00x12
>>> rcx=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x1
>>> rdx=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xffffffff811f6d0a
>>> rbx=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xffffffff812e614c
>>> rsp=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xfffffe0007fa15a0
>>> rbp=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xfffffe0007fa15b0
>>> rsi=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A00x80
>>> rdi=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xffffffff81e8cec0=C2=A0 = cnputs_mtx
>>> r8=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 0x10
>>> r9=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A00x1d0
>>> r10=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xffffffff81cfa820=C2=A0 = vga_conssoftc
>>> r11=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A00x10
>>> r12=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xffffffff812961ab
>>> r13=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A00x28
>>> r14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 0x100
>>> r15=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xfffffe000937a740
>>> rip=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xffffffff80c545a7=C2=A0 = kdb_enter+0x37
>>> rflags=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 0x86
>>> kdb_enter+0x37: movq=C2=A0 =C2=A0 $0,0x1283a5e(%rip)
>>>
>>> Found a console log;=C2=A0 the system was idle, right after a = boot for a few
>>> minutes.
>>> It's a lab machine having booted off IPv4 (grml) but also = having IPv6 on
>>> the network.
>>>
>>> According to terminal backlogs it was an incoming IPv6 ssh ses= sion likely
>>> to have triggered this.=C2=A0 Always great if things are "= ;idle" and only few
>>> people
>>> to ask.
>>>
>>> it is amd64;=C2=A0 main @ 773e3a71b2f11d422694495aca988d4c7143= 601b from Jan
>> 31st.
>>>
>>> /bz
>>>
>>>
>>>> Drew
>>>>
>>>> On Tue, Feb 8, 2022 at 1:58 PM Bjoern A. Zeeb <
>>>> bzeeb-lists@lists.zabbadoz.net> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I just came to a console finding this.=C2=A0 The tree = is from a few days
>> ago;
>>>>> is this known or should I investigate if it happens ag= ain?=C2=A0 =C2=A0I sadly
>>>>> cannot
>>>>> dump on this machine.
>>>>>
>>>>> /bz
>>>>>
>>>>> db> show panic
>>>>> panic: syncache: mbuf too small
>>>>> db> where
>>>>> Tracing pid 0 tid 100014 td 0xfffffe000937a740
>>>>> kdb_enter() at kdb_enter+0x37/frame 0xfffffe0007fa15b0=
>>>>> vpanic() at vpanic+0x1b0/frame 0xfffffe0007fa1600
>>>>> panic() at panic+0x43/frame 0xfffffe0007fa1660
>>>>> syncache_respond() at syncache_respond+0x777/frame 0xf= ffffe0007fa1730
>>>>> syncache_add() at syncache_add+0xa71/frame 0xfffffe000= 7fa18c0
>>>>> tcp_input_with_port() at tcp_input_with_port+0x14f5/fr= ame
>>>>> 0xfffffe0007fa1a20
>>>>> tcp6_input_with_port() at tcp6_input_with_port+0x69/fr= ame
>>>>> 0xfffffe0007fa1a50
>>>>> tcp6_input() at tcp6_input+0xb/frame 0xfffffe0007fa1a6= 0
>>>>> ip6_input() at ip6_input+0xc2f/frame 0xfffffe0007fa1b4= 0
>>>>> netisr_dispatch_src() at netisr_dispatch_src+0xaf/fram= e
>> 0xfffffe0007fa1ba0
>>>>> ether_demux() at ether_demux+0x16e/frame 0xfffffe0007f= a1bd0
>>>>> ether_nh_input() at ether_nh_input+0x3fc/frame 0xfffff= e0007fa1c30
>>>>> netisr_dispatch_src() at netisr_dispatch_src+0xaf/fram= e
>> 0xfffffe0007fa1c90
>>>>> ether_input() at ether_input+0x99/frame 0xfffffe0007fa= 1cf0
>>>>> iflib_rxeof() at iflib_rxeof+0xcb3/frame 0xfffffe0007f= a1e00
>>>>> _task_fn_rx() at _task_fn_rx+0x7a/frame 0xfffffe0007fa= 1e40
>>>>> gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa7/= frame
>>>>> 0xfffffe0007fa1ec0
>>>>> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc= 2/frame
>>>>> 0xfffffe0007fa1ef0
>>>>> fork_exit() at fork_exit+0x80/frame 0xfffffe0007fa1f30=
>>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffff= e0007fa1f30
>>>>> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 ---

--
Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7
--0000000000008c7f2505d78951b3--