From owner-freebsd-net@freebsd.org Sun Sep 27 21:00:23 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B567AA0ABFE
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 27 Sep 2015 21:00:23 +0000 (UTC)
(envelope-from bugzilla-noreply@FreeBSD.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 8B11F227
for <freebsd-net@FreeBSD.org>; Sun, 27 Sep 2015 21:00:23 +0000 (UTC)
(envelope-from bugzilla-noreply@FreeBSD.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8RL0NKe078291
for <freebsd-net@FreeBSD.org>; Sun, 27 Sep 2015 21:00:23 GMT
(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <201509272100.t8RL0NKe078291@kenobi.freebsd.org>
From: bugzilla-noreply@FreeBSD.org
To: freebsd-net@FreeBSD.org
Subject: Problem reports for freebsd-net@FreeBSD.org that need special
attention
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
Date: Sun, 27 Sep 2015 21:00:23 +0000
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Sep 2015 21:00:23 -0000
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.
Status | Bug Id | Description
------------+-----------+---------------------------------------------------
Open | 194515 | Fatal Trap 12 Kernel with vimage
Open | 199136 | [if_tap] Added down_on_close sysctl variable to t
2 problems total for which you should take action.
From owner-freebsd-net@freebsd.org Sun Sep 27 22:41:38 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2FA6A0B071
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 27 Sep 2015 22:41:38 +0000 (UTC)
(envelope-from garmitage@swin.edu.au)
Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 27C9BFCA
for <freebsd-net@freebsd.org>; Sun, 27 Sep 2015 22:41:37 +0000 (UTC)
(envelope-from garmitage@swin.edu.au)
Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37])
by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t8RMfR1O019249
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 28 Sep 2015 08:41:28 +1000
From: grenville armitage <garmitage@swin.edu.au>
Subject: AQMs for FreeBSD
To: freebsd-net@freebsd.org
Message-ID: <56087097.3040007@swin.edu.au>
Date: Mon, 28 Sep 2015 08:41:27 +1000
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Sep 2015 22:41:38 -0000
All,
With the support of a small grant from Comcast's TechFund, I and one of my students will soon start working with over the next 6+ months to implement codel, PIE, fq_codel and fq_PIE in FreeBSD's dummynet. We're doing this in large part test the clarity of the IETF's documentation, feed back into the IETF process, and help bring FreeBSD up to par with Linux in this particular area.
I know there's been some previous FreeBSD work (e.g. with codel), so we're happy to hear about (and build on) previous BSD-licensed work in this space.
cheers,
gja
--
http://caia.swin.edu.au/cv/garmitage
From owner-freebsd-net@freebsd.org Sun Sep 27 23:51:49 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B546CA0BD0F
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 27 Sep 2015 23:51:49 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 9AF3BE9
for <freebsd-net@freebsd.org>; Sun, 27 Sep 2015 23:51:49 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id t8RNpfnF044558;
Sun, 27 Sep 2015 16:51:45 -0700 (PDT)
(envelope-from truckman@FreeBSD.org)
Message-Id: <201509272351.t8RNpfnF044558@gw.catspoiler.org>
Date: Sun, 27 Sep 2015 16:51:41 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: AQMs for FreeBSD
To: garmitage@swin.edu.au
cc: freebsd-net@freebsd.org
In-Reply-To: <56087097.3040007@swin.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Sep 2015 23:51:49 -0000
On 28 Sep, grenville armitage wrote:
> All,
>
> With the support of a small grant from Comcast's TechFund, I and one
> of my students will soon start working with over the next 6+ months to
> implement codel, PIE, fq_codel and fq_PIE in FreeBSD's dummynet. We're
> doing this in large part test the clarity of the IETF's documentation,
> feed back into the IETF process, and help bring FreeBSD up to par with
> Linux in this particular area.
Very cool! This is something that I've been wanting for a while.
Something else that Linux has that we don't is the ability to account
for the overhead of ATM encapsulation.
> I know there's been some previous FreeBSD work (e.g. with codel), so
> we're happy to hear about (and build on) previous BSD-licensed work in
> this space.
ALTQ in -HEAD has codel, but it is basically undocumented. I've been
thinking about using it, but I also want to be able to limit the
bandwidth of inbound TCP traffic, but ALTQ only handles outbound
traffic.
From owner-freebsd-net@freebsd.org Mon Sep 28 08:00:11 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5487A0BBCD
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 08:00:11 +0000 (UTC)
(envelope-from girgen@FreeBSD.org)
Received: from mail.pingpong.net (mail.pingpong.net [79.136.116.202])
by mx1.freebsd.org (Postfix) with ESMTP id 61AF51C0D;
Mon, 28 Sep 2015 08:00:10 +0000 (UTC)
(envelope-from girgen@FreeBSD.org)
Received: from [10.0.0.143] (citron2.pingpong.net [195.178.173.68])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.pingpong.net (Postfix) with ESMTPSA id D231BE5A9;
Mon, 28 Sep 2015 10:00:02 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Kernel panics in tcp_twclose
From: Palle Girgensohn <girgen@FreeBSD.org>
In-Reply-To: <9529CF41-E4B9-4AC5-9703-945EC35924BC@FreeBSD.org>
Date: Mon, 28 Sep 2015 10:00:02 +0200
Cc: freebsd-net@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DB44C89-F985-41BC-A7FB-E2D180FC60E3@FreeBSD.org>
References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org>
<55FC1809.3070903@freebsd.org> <20150918160605.GN67105@kib.kiev.ua>
<55FFBE01.6060706@freebsd.org>
<3721F099-F45D-4DCD-8AB3-84D1ABC44145@FreeBSD.org>
<73856F2B-3E70-483C-9988-C84E798CEB44@FreeBSD.org>
<44EBAC98-4761-4E47-8E47-5032430A1C8A@FreeBSD.org>
<56019AF8.8000705@freebsd.org>
<F9D29C16-502B-43A1-BE2C-D2AD30F0B9EF@FreeBSD.org>
<5601CF2D.9030307@freebsd.org>
<E09DF89D-AAC5-48FD-8B75-EEAB937A5C32@FreeBSD.org>
<5602E90A.9050504@freebsd.org>
<0931591A-23EC-40CB-A109-72E9308B1A2D@pingpong.net>
<5602F044.5010606@freebsd.org>
<54767991-9D3B-4ECB-A07E-CFA21A54BBDD@pingpong.net>
<4E148E2E-F8D2-41C2-B232-9FD1548AA20B@pingpong.net>
<30AD333B-EC8B-4EEF-8FE2-8EA8C216601E@FreeBSD.org>
<5603A03B.4060002@freebsd.org> <5603ACF7.7040403@freebsd.org>
<97E97774-842B-440A-BBA4-808FF821EC98@FreeBSD.org>
<6BA42863-E584-4552-8D73-7471616ADC6D@FreeBSD.org>
<9529CF41-E4B9-4AC5-9703-945EC35924BC@FreeBSD.org>
To: Julien Charbon <jch@FreeBSD.org>
X-Mailer: Apple Mail (2.2104)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 08:00:12 -0000
> 25 sep 2015 kl. 16:19 skrev Palle Girgensohn <girgen@FreeBSD.org>:
>=20
>>=20
>> 25 sep 2015 kl. 16:14 skrev Palle Girgensohn <girgen@FreeBSD.org>:
>>=20
>>>=20
>>> 24 sep 2015 kl. 11:39 skrev Palle Girgensohn <girgen@FreeBSD.org>:
>>>=20
>>>=20
>>>> 24 sep 2015 kl. 09:57 skrev Julien Charbon <jch@FreeBSD.org>:
>>>>=20
>>>>=20
>>>> Hi -net,
>>>>=20
>>>> On 24/09/15 09:03, Julien Charbon wrote:
>>>>> On 24/09/15 08:55, Palle Girgensohn wrote:
>>>>>>> 24 sep 2015 kl. 07:51 skrev Palle Girgensohn
>>>>>>> <girgen@pingpong.net>:
>>>>>>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn
>>>>>>>> <girgen@pingpong.net>:
>>>>>>>>> 23 sep 2015 kl. 20:32 skrev Julien Charbon <jch@freebsd.org>:=20=
>>>>>>>>> On 23/09/15 20:26, Palle Girgensohn wrote:
>>>>>>>> Kernels and userland are updated to 10.2-p3 with the patch
>>>>>>>> removing the suspicous KASSERT.
>>>>>>>> dtrace running continously redirecting to a log file.
>>>>>> Just had a crash. Unfortunately, the kernel was stuck at the db>
>>>>>> prompt, and the remote keyboard was unresponsive (HP ILO, not
>>>>>> impressed). So I had to reset the power and never got a core =
dump...
>>>>>>=20
>>>>>> panic: tcp_tw_2msl_stop: inp should not be released here
>>>>>> cpuid =3D 0
>>>>>> KDB: stack backtrace:
>>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>>>> 0xfffffe175acd16a0 kdb_backtrace() at kdb_backtrace+0x39/frame
>>>>>> 0xfffffe175acd1750 vpanic() at vpanic+0x126/frame =
0xfffffe175acd1790
>>>>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe175acd1800
>>>>>> tcp_twclose() at tcp_twclose+0x2cb/frame 0xfffffe175acd1850
>>>>>> tcp_tw_2msl_scan() at tcp_tw_2msl_scan+0x13b/frame
>>>>>> 0xfffffe175acd1890 tcp_slowtimo() at tcp_slowtimo+0x68/frame
>>>>>> 0xfffffe175acd18c0 pfslowtimo() at pfslowtimo+0x54/frame
>>>>>> 0xfffffe175acd18f0 softclock_call_cc() at
>>>>>> softclock_call_cc+0x193/frame 0xfffffe175acd19d0 softclock() at
>>>>>> softclock+0x47/frame 0xfffffe175acd19f0 =
intr_event_execute_handlers()
>>>>>> at intr_event_execute_handlers+0x93/frame 0xfffffe 175acd1a30
>>>>>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe175acd1a70
>>>>>> fork_exit() at fork_exit+0x84/frame 0xfffffe175acd1ab0
>>>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe175acd1ab0
>>>>>> --- trap 0, rip =3D 0, rsp =3D 0xfffffe175acd1b70, rbp =3D 0 ---
>>>>>> KDB: enter: panic
>>>>>> [ thread pid 12 tid 100043 ]
>>>>>> Stopped at kdb_enter+0x3e: movq $0,kdb_why
>>>>>> db>
>>>>>=20
>>>>> Thanks a log for this backstrace. This is what at expected, when
>>>>> tcp_close() in call in INP_TIMEWAIT case, in_pcbfree() can be =
called one
>>>>> extra time that leads to:
>>>>>=20
>>>>> tcp_tw_2msl_stop: inp should not be released here
>>>>>=20
>>>>> Let me try to come with a tentative fix for this case.
>>>>=20
>>>> See joined my tentative patch for these case. It is only a first
>>>> tentative patch as I am still waiting on -net feedbacks on what =
should
>>>> be the rule here.
>>>>=20
>>>> By the way:
>>>>=20
>>>> - I see nothing specific to VIMAGE here
>>>>=20
>>>> - Anyone aware of tcp_close() (or tcp_drop()) calls =
modified/introduced
>>>> recently in 10.2 that could explained why this issue only appears =
only now?
>>>>=20
>>>> --
>>>> Julien
>>>> <tcp-close-fix-v1.patch>
>>>=20
>>>=20
>>> Running a machine with the patch now (it just crashed and rebooted =
with the new kernel).
>>>=20
>>> Hoping it will have a "soothing" effect... ;-)
>>>=20
>>>=20
>>> dtrace running as previously. No output yet, though.
>>>=20
>>>=20
>>=20
>> Hello -net & Julien!
>>=20
>> First of, loud cheers and a big *thank you* to Julien for helping us =
get our systems to stop crashing. This really means a lot to us! Thank =
you!
>>=20
>> We have been running more than 24 hours with no crash, so I'm getting =
more and more confident that the change acually makes the system stable.
>>=20
>> Dtrace still shows nothing.
>>=20
>> Palle
>=20
>=20
> Secondly, is this error related? This is *not* VIMAGE, *not* jail. It =
is a binary installed GENERIC from freebsd-update. 10.1-RELEASE-p19. It =
just crashed today, and we did not get any core dump, but I found this =
core.txt from a crash in August that I was not aware of (I was on =
holiday then... :)
>=20
> Since it is installed binary, I have no kernel.debug.
>=20
> ...
>=20
> panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf =
0xfffff800b4a36800 clashing
>=20
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and =
you are
> welcome to change it and/or distribute copies of it under certain =
conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for =
details.
> This GDB was configured as "amd64-marcel-freebsd"...
>=20
> Unread portion of the kernel message buffer:
> panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf =
0xfffff800b4a36800 clashing
> cpuid =3D 1
> KDB: stack backtrace:
> #0 0xffffffff80963000 at kdb_backtrace+0x60
> #1 0xffffffff80928125 at panic+0x155
> #2 0xffffffff8099c180 at sbdroprecord_locked+0
> #3 0xffffffff80ac8c9c at tcp_output+0xdbc
> #4 0xffffffff80ac6a95 at tcp_do_segment+0x3045
> #5 0xffffffff80ac2e04 at tcp_input+0xd04
> #6 0xffffffff80a54fc7 at ip_input+0x97
> #7 0xffffffff809f4f73 at swi_net+0x143
> #8 0xffffffff808faf4b at intr_event_execute_handlers+0xab
> #9 0xffffffff808fb396 at ithread_loop+0x96
> #10 0xffffffff808f8b6a at fork_exit+0x9a
> #11 0xffffffff80d0b67e at fork_trampoline+0xe
> Uptime: 21d0h54m53s
> Dumping 2005 out of 32709 =
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>=20
> Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
> Loaded symbols for /boot/kernel/accf_data.ko.symbols
> Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
> Loaded symbols for /boot/kernel/accf_http.ko.symbols
> Reading symbols from /boot/kernel/oce.ko.symbols...done.
> Loaded symbols for /boot/kernel/oce.ko.symbols
> Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/nullfs.ko.symbols
> Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/linprocfs.ko.symbols
> Reading symbols from /boot/kernel/linux.ko.symbols...done.
> Loaded symbols for /boot/kernel/linux.ko.symbols
> Reading symbols from /boot/kernel/zfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/zfs.ko.symbols
> Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
> Loaded symbols for /boot/kernel/opensolaris.ko.symbols
> #0 doadump (textdump=3D<value optimized out>) at pcpu.h:219
> 219 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0 doadump (textdump=3D<value optimized out>) at pcpu.h:219
> #1 0xffffffff80927da2 in kern_reboot (howto=3D260)
> at /usr/src/sys/kern/kern_shutdown.c:452
> #2 0xffffffff80928164 in panic (fmt=3D<value optimized out>)
> at /usr/src/sys/kern/kern_shutdown.c:759
> #3 0xffffffff8099c180 in sbsndptr (sb=3D<value optimized out>,=20
> off=3D<value optimized out>, len=3D<value optimized out>,=20
> moff=3D<value optimized out>) at =
/usr/src/sys/kern/uipc_sockbuf.c:1011
> #4 0xffffffff80ac8c9c in tcp_output (tp=3D0xfffff80312ef5800)
> at /usr/src/sys/netinet/tcp_output.c:870
> #5 0xffffffff80ac6a95 in tcp_do_segment (m=3D<value optimized out>,=20=
> th=3D<value optimized out>, so=3D<value optimized out>,=20
> tp=3D<value optimized out>, drop_hdrlen=3D<value optimized out>, =
tlen=3D0,=20
> iptos=3D<value optimized out>, ti_locked=3DCannot access memory at =
address 0x1
> )
> at /usr/src/sys/netinet/tcp_input.c:3018
> #6 0xffffffff80ac2e04 in tcp_input (m=3D<value optimized out>,=20
> off0=3D<value optimized out>) at =
/usr/src/sys/netinet/tcp_input.c:1377
> #7 0xffffffff80a54fc7 in ip_input (m=3D0xfffff800b4516600)
> at /usr/src/sys/netinet/ip_input.c:734
> #8 0xffffffff809f4f73 in swi_net (arg=3D0xffffffff81988880)
> at /usr/src/sys/net/netisr.c:765
> #9 0xffffffff808faf4b in intr_event_execute_handlers (
> p=3D<value optimized out>, ie=3D0xfffff800093ac600)
> at /usr/src/sys/kern/kern_intr.c:1263
> #10 0xffffffff808fb396 in ithread_loop (arg=3D0xfffff80009388e40)
> at /usr/src/sys/kern/kern_intr.c:1276
> #11 0xffffffff808f8b6a in fork_exit (
> callout=3D0xffffffff808fb300 <ithread_loop>, =
arg=3D0xfffff80009388e40,=20
> frame=3D0xfffffe083c3e3ac0) at /usr/src/sys/kern/kern_fork.c:996
> #12 0xffffffff80d0b67e in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:606
> #13 0x0000000000000000 in ?? ()
> Current language: auto; currently minimal
> (kgdb)=20
Hi Julien and -net,
A sunny Monday, no crashes since the patch was applied. Great! Big =
thanks again!
We still have nothing in the dtrace log, though.
And I wonder if the above crash could possibly be a result of hitting =
that same bug?
Palle
From owner-freebsd-net@freebsd.org Mon Sep 28 08:08:28 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 343FCA082C6
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 08:08:28 +0000 (UTC)
(envelope-from emeric.poupon@stormshield.eu)
Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1])
by mx1.freebsd.org (Postfix) with ESMTP id F1933109D
for <freebsd-net@freebsd.org>; Mon, 28 Sep 2015 08:08:27 +0000 (UTC)
(envelope-from emeric.poupon@stormshield.eu)
Received: from work.netasq.com (localhost.localdomain [127.0.0.1])
by work.netasq.com (Postfix) with ESMTP id 64FA22705605
for <freebsd-net@freebsd.org>; Mon, 28 Sep 2015 10:08:26 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by work.netasq.com (Postfix) with ESMTP id 373AB2705297
for <freebsd-net@freebsd.org>; Mon, 28 Sep 2015 10:08:26 +0200 (CEST)
Received: from work.netasq.com ([127.0.0.1])
by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id FImJ1cWc9PJ2 for <freebsd-net@freebsd.org>;
Mon, 28 Sep 2015 10:08:26 +0200 (CEST)
Received: from work.netasq.com (localhost.localdomain [127.0.0.1])
by work.netasq.com (Postfix) with ESMTP id 086CC2700716
for <freebsd-net@freebsd.org>; Mon, 28 Sep 2015 10:08:26 +0200 (CEST)
Date: Mon, 28 Sep 2015 10:08:25 +0200 (CEST)
From: Emeric POUPON <emeric.poupon@stormshield.eu>
To: FreeBSD Net <freebsd-net@freebsd.org>
Message-ID: <1049417046.2997430.1443427705821.JavaMail.zimbra@stormshield.eu>
In-Reply-To: <868621474.11105551.1439798865541.JavaMail.zimbra@stormshield.eu>
References: <868621474.11105551.1439798865541.JavaMail.zimbra@stormshield.eu>
Subject: Re: IPsec: question on the sysctl preferred_oldsa
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: IPsec: question on the sysctl preferred_oldsa
Thread-Index: IeXRZTKnQSSas6XdJUVl2KQ2WmNtSjhrDka+
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 08:08:28 -0000
Hello,
No idea on this question?
To sum up the potential problems:
- strongSwan does not expect the kernel to destroy a SA, and produces error=
s after that (it cannot find the expected SA in the kernel since it has bee=
n deleted)
- racoon uses the "delete" event from the kernel and creates a ISAKMP DELET=
E message to the remote host, with the relevant SPI. In some situations, bo=
th endpoints negotiate a pair of SA at the same time, and keep deleting the=
ir old SA and renegotiate. I suspect this behavior to be related to this sy=
sctl.
What do you think?
Emeric
----- Mail original -----
De: "Emeric POUPON" <emeric.poupon@stormshield.eu>
=C3=80: "FreeBSD Net" <freebsd-net@freebsd.org>
Envoy=C3=A9: Lundi 17 Ao=C3=BBt 2015 10:07:45
Objet: IPsec: question on the sysctl preferred_oldsa
Hello,
I have some questions about the sysctl "net.key.preferred_oldsa":
https://svnweb.freebsd.org/base/head/sys/netipsec/key.c?view=3Dmarkup#l971
When I set the net.key.preferred_oldsa to 0 (similar to Linux's behavior, a=
ccording to what I have read so far):
- why does the kernel delete itself the old SA ? Why not just selecting the=
newest one?
- why does it delete the old SA only if it has been created in another "sec=
ond" of time?
strongSwan does not expect that behavior and I can see a lot of errors in i=
ts logs: the SA has been deleted but it does not know about that (strongSwa=
n wants to control the SA installation/deletion itself).
Two pairs of SA may be negotiated and installed at the same time due to hig=
h load, bidirectional traffic. It seems to be quite questionable to delete =
the old one in that case.
What do you think?
Emeric
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
From owner-freebsd-net@freebsd.org Mon Sep 28 08:23:18 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0235A08CBA
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 08:23:17 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com
[209.85.212.194])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 7FBAE199E;
Mon, 28 Sep 2015 08:23:17 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: by wicuu12 with SMTP id uu12so16096299wic.0;
Mon, 28 Sep 2015 01:23:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to:content-type;
bh=f/02x2pG/fujEiineUxzMBKDOIpCXPGnPhZW2XSNKEk=;
b=MDGyyexp1PmK+QPBVbbp9vufmTrmuu1qCgAJchH4YBAJpeOUUT80SfEwAQDqaSMnIe
L0Ic2Owd6jwjATniDnlvUXX705l1k7PlcyzY2VxHE6JvnLWxWAbSPThptDw4ISQkHbJA
sXxq5rmNPI2yKm614+ilgkaVHhj//KZ8EZ4kTKNWMqWsED1JD4+VhDbYnf6+TYQdib58
6TRXAukHqsfKh2ZkzJ//NvIeI89l7tRArfxvD8/twhm238KJyrkQdMQL8QRAcj9fbAFu
0EQmjXYmwnakyyy0hKY67dcT4c3fOVrZmf9Ffftiz1QfAld0TmxM9avOTxmNYeywe1jl
HVzQ==
X-Received: by 10.180.36.193 with SMTP id s1mr29076wij.84.1443427680104;
Mon, 28 Sep 2015 01:08:00 -0700 (PDT)
Received: from fri2pmaresca-l1.vcorp.ad.vrsn.com ([217.30.88.7])
by smtp.googlemail.com with ESMTPSA id d8sm21576634wiy.1.2015.09.28.01.07.58
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 28 Sep 2015 01:07:59 -0700 (PDT)
Subject: Re: Kernel panics in tcp_twclose
To: Palle Girgensohn <girgen@FreeBSD.org>
References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org>
<55FC1809.3070903@freebsd.org> <20150918160605.GN67105@kib.kiev.ua>
<55FFBE01.6060706@freebsd.org>
<3721F099-F45D-4DCD-8AB3-84D1ABC44145@FreeBSD.org>
<73856F2B-3E70-483C-9988-C84E798CEB44@FreeBSD.org>
<44EBAC98-4761-4E47-8E47-5032430A1C8A@FreeBSD.org>
<56019AF8.8000705@freebsd.org>
<F9D29C16-502B-43A1-BE2C-D2AD30F0B9EF@FreeBSD.org>
<5601CF2D.9030307@freebsd.org>
<E09DF89D-AAC5-48FD-8B75-EEAB937A5C32@FreeBSD.org>
<5602E90A.9050504@freebsd.org>
<0931591A-23EC-40CB-A109-72E9308B1A2D@pingpong.net>
<5602F044.5010606@freebsd.org>
<54767991-9D3B-4ECB-A07E-CFA21A54BBDD@pingpong.net>
<4E148E2E-F8D2-41C2-B232-9FD1548AA20B@pingpong.net>
<30AD333B-EC8B-4EEF-8FE2-8EA8C216601E@FreeBSD.org>
<5603A03B.4060002@freebsd.org> <5603ACF7.7040403@freebsd.org>
<97E97774-842B-440A-BBA4-808FF821EC98@FreeBSD.org>
<6BA42863-E584-4552-8D73-7471616ADC6D@FreeBSD.org>
Cc: freebsd-net@freebsd.org
From: Julien Charbon <jch@freebsd.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <5608F559.3020702@freebsd.org>
Date: Mon, 28 Sep 2015 10:07:53 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <6BA42863-E584-4552-8D73-7471616ADC6D@FreeBSD.org>
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="rDa8W47rW3h7JrJo0ArH56mGJNH7euvOr"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 08:23:18 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rDa8W47rW3h7JrJo0ArH56mGJNH7euvOr
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi Palle,
On 25/09/15 16:14, Palle Girgensohn wrote:
>> 24 sep 2015 kl. 11:39 skrev Palle Girgensohn <girgen@FreeBSD.org>:
>>> 24 sep 2015 kl. 09:57 skrev Julien Charbon <jch@FreeBSD.org>: On
>>> 24/09/15 09:03, Julien Charbon wrote:
>>>> On 24/09/15 08:55, Palle Girgensohn wrote:
>>>>>> 24 sep 2015 kl. 07:51 skrev Palle Girgensohn=20
>>>>>> <girgen@pingpong.net>:
>>>>>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn=20
>>>>>>> <girgen@pingpong.net>:
>>>>>>>> 23 sep 2015 kl. 20:32 skrev Julien Charbon
>>>>>>>> <jch@freebsd.org>: On 23/09/15 20:26, Palle Girgensohn
>>>>>>>> wrote:
>>>>>>> Kernels and userland are updated to 10.2-p3 with the
>>>>>>> patch removing the suspicous KASSERT. dtrace running
>>>>>>> continously redirecting to a log file.
>>>>> Just had a crash. Unfortunately, the kernel was stuck at the
>>>>> db> prompt, and the remote keyboard was unresponsive (HP ILO,
>>>>> not impressed). So I had to reset the power and never got a
>>>>> core dump...
>>>>>=20
>>>>> panic: tcp_tw_2msl_stop: inp should not be released here=20
>>>>> cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at
>>>>> db_trace_self_wrapper+0x2b/frame 0xfffffe175acd16a0
>>>>> kdb_backtrace() at kdb_backtrace+0x39/frame=20
>>>>> 0xfffffe175acd1750 vpanic() at vpanic+0x126/frame
>>>>> 0xfffffe175acd1790 kassert_panic() at
>>>>> kassert_panic+0x139/frame 0xfffffe175acd1800 tcp_twclose() at
>>>>> tcp_twclose+0x2cb/frame 0xfffffe175acd1850 tcp_tw_2msl_scan()
>>>>> at tcp_tw_2msl_scan+0x13b/frame 0xfffffe175acd1890
>>>>> tcp_slowtimo() at tcp_slowtimo+0x68/frame 0xfffffe175acd18c0
>>>>> pfslowtimo() at pfslowtimo+0x54/frame 0xfffffe175acd18f0
>>>>> softclock_call_cc() at softclock_call_cc+0x193/frame
>>>>> 0xfffffe175acd19d0 softclock() at softclock+0x47/frame
>>>>> 0xfffffe175acd19f0 intr_event_execute_handlers() at
>>>>> intr_event_execute_handlers+0x93/frame 0xfffffe 175acd1a30=20
>>>>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe175acd1a70=20
>>>>> fork_exit() at fork_exit+0x84/frame 0xfffffe175acd1ab0=20
>>>>> fork_trampoline() at fork_trampoline+0xe/frame
>>>>> 0xfffffe175acd1ab0 --- trap 0, rip =3D 0, rsp =3D
>>>>> 0xfffffe175acd1b70, rbp =3D 0 --- KDB: enter: panic [ thread
>>>>> pid 12 tid 100043 ] Stopped at kdb_enter+0x3e: movq
>>>>> $0,kdb_why db>
>>>>=20
>>>> Thanks a log for this backstrace. This is what at expected,
>>>> when tcp_close() in call in INP_TIMEWAIT case, in_pcbfree() can
>>>> be called one extra time that leads to:
>>>>=20
>>>> tcp_tw_2msl_stop: inp should not be released here
>>>>=20
>>>> Let me try to come with a tentative fix for this case.
>>>=20
>>> See joined my tentative patch for these case. It is only a
>>> first tentative patch as I am still waiting on -net feedbacks on
>>> what should be the rule here.
>>>=20
>>> By the way:
>>>=20
>>> - I see nothing specific to VIMAGE here
>>>=20
>>> - Anyone aware of tcp_close() (or tcp_drop()) calls
>>> modified/introduced recently in 10.2 that could explained why
>>> this issue only appears only now?
>>=20
>> Running a machine with the patch now (it just crashed and rebooted
>> with the new kernel).
>>=20
>> Hoping it will have a "soothing" effect... ;-)
>>=20
>> dtrace running as previously. No output yet, though.
>=20
> First of, loud cheers and a big *thank you* to Julien for helping us
> get our systems to stop crashing. This really means a lot to us!
> Thank you!
Glab to see your system more stable now. You are welcome, thanks to
you for reporting this issue with accuracy. We got lucky than it took
/only/ three different kernel panics to get a good overview. This part
of the code being quite tricky as you have three entangled layers that
tries to clean up theirs things the right way: socket, inp and tcptw.
> Dtrace still shows nothing.
I will try to provide you more generic Dtrace script, it seem the
current one is too specific.
--
Julien
--rDa8W47rW3h7JrJo0ArH56mGJNH7euvOr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWCPVeAAoJEKVlQ5Je6dhxrFsH/3wQHFmAqMr0iRzO9iRJIChW
wYahDsA4TjezATlZMmraU130h6BXyRSzunLky+QVrY+BMDTjAn5T7+jYsA9xpaCW
vdBUHyAQQy5jaddfHZrtx0ZumSIYNI3TIqUvhmbyhWtGfPrvVkx0P3qQpwV60M7N
XAPrFFn5LdqcdUVT9/D/YOe13C4dxlYvRdWtpdC1z7cZBPBGzaRq+R+6dD3H24AU
SEJdDEfijvRu0iLykYQ5QOr/5l0DobojE3X9lZmUa7nZfOwknLuQCzcr5Hwylm6T
X0nMdt1HHzunW0mJcCWpxhxcx2Ga0MTXtr9A97X/2bh8sLXAX4H5bAcyc5LKCHw=
=rpsy
-----END PGP SIGNATURE-----
--rDa8W47rW3h7JrJo0ArH56mGJNH7euvOr--
From owner-freebsd-net@freebsd.org Mon Sep 28 08:23:46 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B3CAA08D1A
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 08:23:46 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
[209.85.212.173])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id C25011A3F;
Mon, 28 Sep 2015 08:23:45 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: by wicge5 with SMTP id ge5so93562120wic.0;
Mon, 28 Sep 2015 01:23:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to:content-type;
bh=dvPgEBpRCPY1J62RvQB+xYvnP4WJP1NlIrWoQCuxoG8=;
b=FjoEnqRTM7fNVySRfh9AnsGzvC/vevGplFMFxqrm+qVb4Zc8Wl2KhudSS4CnYAvjiK
Ay8vBWAdielPNbxdcUcupFTLDqevitPFvEe6xBVNA7rnnR5B69nIWI3VkZ0Sz6MCRLw0
KhdZdduDnhudVZHOiMT2XiRFHHtF4F2h44UXxD+N8XfK4NN89Bxha07BeLy0Dm0Rmz+A
m4JRg5OnStgLeoAMUGRmaYY68v8EsjFjtjk3HBPID7ujAeG66BqsQ2wJ7VVjd3sc84/o
tQK8PoRjtRFo4SO5d8Tpzbu9nVknpDnIRwWmpZt5ZxOqUnoF2Y6+Cmi/7DZL3GIT+DU9
Bi7Q==
X-Received: by 10.195.11.40 with SMTP id ef8mr20276596wjd.103.1443428617857;
Mon, 28 Sep 2015 01:23:37 -0700 (PDT)
Received: from fri2pmaresca-l1.vcorp.ad.vrsn.com ([217.30.88.7])
by smtp.googlemail.com with ESMTPSA id ju6sm2518340wid.9.2015.09.28.01.23.36
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 28 Sep 2015 01:23:37 -0700 (PDT)
Subject: panic: sbsndptr: sockbuf and mbuf clashing [was: Re: Kernel panics in
tcp_twclose]
To: Palle Girgensohn <girgen@FreeBSD.org>
References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org>
<55FC1809.3070903@freebsd.org> <20150918160605.GN67105@kib.kiev.ua>
<55FFBE01.6060706@freebsd.org>
<3721F099-F45D-4DCD-8AB3-84D1ABC44145@FreeBSD.org>
<73856F2B-3E70-483C-9988-C84E798CEB44@FreeBSD.org>
<44EBAC98-4761-4E47-8E47-5032430A1C8A@FreeBSD.org>
<56019AF8.8000705@freebsd.org>
<F9D29C16-502B-43A1-BE2C-D2AD30F0B9EF@FreeBSD.org>
<5601CF2D.9030307@freebsd.org>
<E09DF89D-AAC5-48FD-8B75-EEAB937A5C32@FreeBSD.org>
<5602E90A.9050504@freebsd.org>
<0931591A-23EC-40CB-A109-72E9308B1A2D@pingpong.net>
<5602F044.5010606@freebsd.org>
<54767991-9D3B-4ECB-A07E-CFA21A54BBDD@pingpong.net>
<4E148E2E-F8D2-41C2-B232-9FD1548AA20B@pingpong.net>
<30AD333B-EC8B-4EEF-8FE2-8EA8C216601E@FreeBSD.org>
<5603A03B.4060002@freebsd.org> <5603ACF7.7040403@freebsd.org>
<97E97774-842B-440A-BBA4-808FF821EC98@FreeBSD.org>
<6BA42863-E584-4552-8D73-7471616ADC6D@FreeBSD.org>
<9529CF41-E4B9-4AC5-9703-945EC35924BC@FreeBSD.org>
Cc: freebsd-net@freebsd.org
From: Julien Charbon <jch@freebsd.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <5608F8FA.4080707@freebsd.org>
Date: Mon, 28 Sep 2015 10:23:22 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <9529CF41-E4B9-4AC5-9703-945EC35924BC@FreeBSD.org>
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="qOao8OgbiATi9NtlKORhLKlkskxrBEPuT"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 08:23:46 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qOao8OgbiATi9NtlKORhLKlkskxrBEPuT
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi Palle,
On 25/09/15 16:19, Palle Girgensohn wrote:
> [...]
> Secondly, is this error related? This is *not* VIMAGE, *not* jail.
> It is a binary installed GENERIC from freebsd-update. 10.1-RELEASE-p19.=
It
> just crashed today, and we did not get any core dump, but I found this
> core.txt from a crash in August that I was not aware of (I was on
> holiday then... :)
>=20
> Since it is installed binary, I have no kernel.debug.
>=20
> panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf
> 0xfffff800b4a36800 clashing
>=20
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and yo=
u are
> welcome to change it and/or distribute copies of it under certain condi=
tions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for deta=
ils.
> This GDB was configured as "amd64-marcel-freebsd"...
>=20
> Unread portion of the kernel message buffer:
> panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf 0xfffff800b4a36800=
clashing
> cpuid =3D 1
> KDB: stack backtrace:
> #0 0xffffffff80963000 at kdb_backtrace+0x60
> #1 0xffffffff80928125 at panic+0x155
> #2 0xffffffff8099c180 at sbdroprecord_locked+0
> #3 0xffffffff80ac8c9c at tcp_output+0xdbc
> #4 0xffffffff80ac6a95 at tcp_do_segment+0x3045
> #5 0xffffffff80ac2e04 at tcp_input+0xd04
> #6 0xffffffff80a54fc7 at ip_input+0x97
> #7 0xffffffff809f4f73 at swi_net+0x143
> #8 0xffffffff808faf4b at intr_event_execute_handlers+0xab
> #9 0xffffffff808fb396 at ithread_loop+0x96
> #10 0xffffffff808f8b6a at fork_exit+0x9a
> #11 0xffffffff80d0b67e at fork_trampoline+0xe
> Uptime: 21d0h54m53s
> Dumping 2005 out of 32709 MB:..1%..11%..21%..31%..41%..51%..61%..71%..8=
1%..91%
>=20
> #0 doadump (textdump=3D<value optimized out>) at pcpu.h:219
> 219 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0 doadump (textdump=3D<value optimized out>) at pcpu.h:219
> #1 0xffffffff80927da2 in kern_reboot (howto=3D260)
> at /usr/src/sys/kern/kern_shutdown.c:452
> #2 0xffffffff80928164 in panic (fmt=3D<value optimized out>)
> at /usr/src/sys/kern/kern_shutdown.c:759
> #3 0xffffffff8099c180 in sbsndptr (sb=3D<value optimized out>,=20
> off=3D<value optimized out>, len=3D<value optimized out>,=20
> moff=3D<value optimized out>) at /usr/src/sys/kern/uipc_sockbuf.c:1=
011
> #4 0xffffffff80ac8c9c in tcp_output (tp=3D0xfffff80312ef5800)
> at /usr/src/sys/netinet/tcp_output.c:870
> #5 0xffffffff80ac6a95 in tcp_do_segment (m=3D<value optimized out>,=20
> th=3D<value optimized out>, so=3D<value optimized out>,=20
> tp=3D<value optimized out>, drop_hdrlen=3D<value optimized out>, tl=
en=3D0,=20
> iptos=3D<value optimized out>, ti_locked=3DCannot access memory at =
address 0x1
> )
> at /usr/src/sys/netinet/tcp_input.c:3018
> #6 0xffffffff80ac2e04 in tcp_input (m=3D<value optimized out>,=20
> off0=3D<value optimized out>) at /usr/src/sys/netinet/tcp_input.c:1=
377
> #7 0xffffffff80a54fc7 in ip_input (m=3D0xfffff800b4516600)
> at /usr/src/sys/netinet/ip_input.c:734
> #8 0xffffffff809f4f73 in swi_net (arg=3D0xffffffff81988880)
> at /usr/src/sys/net/netisr.c:765
> #9 0xffffffff808faf4b in intr_event_execute_handlers (
> p=3D<value optimized out>, ie=3D0xfffff800093ac600)
> at /usr/src/sys/kern/kern_intr.c:1263
> #10 0xffffffff808fb396 in ithread_loop (arg=3D0xfffff80009388e40)
> at /usr/src/sys/kern/kern_intr.c:1276
> #11 0xffffffff808f8b6a in fork_exit (
> callout=3D0xffffffff808fb300 <ithread_loop>, arg=3D0xfffff80009388e=
40,=20
> frame=3D0xfffffe083c3e3ac0) at /usr/src/sys/kern/kern_fork.c:996
> #12 0xffffffff80d0b67e in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:606
> #13 0x0000000000000000 in ?? ()
> Current language: auto; currently minimal
> (kgdb)=20
It is unlikely to be related as:
- It happens quite far away from inp/tcptw code
- As inp are allocated in their own uma zone, double free-ing a inp
will corrupt only other inps
Not completely impossible but unlikely. That said you can add your own
information to this old (July 2010) but still relevant bug report:
[panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr:
sockbuf _ and mbuf _ clashing"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D148807
My 2 cents.
--
Julien
--qOao8OgbiATi9NtlKORhLKlkskxrBEPuT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWCPkJAAoJEKVlQ5Je6dhxT5IIAMv4L17HO2F5Qln5cC/nb9h7
0RyLT31MXypUr+x89308Sf7a/80ZL+3CUKiA7g2CBgAp27+5B89EjFkntYhZDTRs
VzE6IlHGLanD57qnr07cnWIjJpWOrXgWQET8PIhxiTmZP6aaqadvS3zwVx4LvmRY
iVa90XLrcBLmVIOHxhBKf7vuQhSiJYFMYzBvzQQJ6TMA3EW06PASeOHFrFGwq7t8
3J2aVtebrsl1qvXT75mLKYBUVsxgQLQDreoxQvIEd0jOIv/Vfjg5WCf1VH/eNDrO
p/frOpW0kXfUBKeBtOUgZ7US3Hk5WZZWier4eghH8KsMddDdUCqjzVSSiu/XgzM=
=MK1o
-----END PGP SIGNATURE-----
--qOao8OgbiATi9NtlKORhLKlkskxrBEPuT--
From owner-freebsd-net@freebsd.org Mon Sep 28 09:08:56 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31099A0B184
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 09:08:56 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id C32FC1F32;
Mon, 28 Sep 2015 09:08:55 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: by wicgb1 with SMTP id gb1so94255073wic.1;
Mon, 28 Sep 2015 02:08:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=from:subject:to:references:cc:message-id:date:user-agent
:mime-version:in-reply-to:content-type;
bh=QDk2oDQoi0qAbfN75+dsqtX8XcAQN00MWqSG23Wru5A=;
b=HCY5VaH5jrz2HgfN1UyruazlLZUN1ZvxNVHDpZR/A9kECxPA38okA1S8PUtPx20trb
dKs3bkYN7s1PnnljC6vnQQQRrtOhZ72zzCy6+kompmk5hvWUHMZJcGrv3Fo5rlN6bHvG
mh4IzRHHkp+Otedkjagc4n+40fghITW/a838oFPv0JFDhZdZeAta0PclqXruLk2guhvg
llv1hEZRwdgnJLSZNuyVzPLzlcongWN4C8/61RGYlNPSIkWC4d0RAtcyMBY9WhoSXEOo
pzalufYXYTxDprM5AhtmXoGBPstolqdc2qlvh/9PkpOfwZpaFx+h1YOfaRdyV4P/VogZ
ljiA==
X-Received: by 10.194.121.40 with SMTP id lh8mr23271383wjb.115.1443431327763;
Mon, 28 Sep 2015 02:08:47 -0700 (PDT)
Received: from fri2jcharbon-m1.vcorp.ad.vrsn.com ([217.30.88.7])
by smtp.googlemail.com with ESMTPSA id lv4sm16467305wjb.43.2015.09.28.02.08.47
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 28 Sep 2015 02:08:47 -0700 (PDT)
From: Julien Charbon <jch@freebsd.org>
Subject: Re: Can tcp_close() be called in INP_TIMEWAIT case
To: John Baldwin <jhb@freebsd.org>
References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org>
<5602BB7A.9010504@freebsd.org> <5603E8E4.5030406@freebsd.org>
<2216936.QIvWsOndvU@ralph.baldwin.cx>
Cc: Palle Girgensohn <girgen@freebsd.org>, freebsd-net@freebsd.org
X-Enigmail-Draft-Status: N1110
Message-ID: <56090398.2070309@freebsd.org>
Date: Mon, 28 Sep 2015 11:08:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <2216936.QIvWsOndvU@ralph.baldwin.cx>
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="vwr74Sb8IPl79CrqbqNTJRdLVuT0ekrIh"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 09:08:56 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vwr74Sb8IPl79CrqbqNTJRdLVuT0ekrIh
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi John,
On 25/09/15 18:42, John Baldwin wrote:
> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>> So the issue is:
>>
>> - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT
>> state and sets the INP_DROPPED flag,
>> - tcp_detach() is called when the last reference on socket is dropped=
>>
>> then now in_pcbfree() can be called twice instead of once:
>>
>> 1. First in tcp_detach():
>>
>> static void
>> tcp_detach(struct socket *so, struct inpcb *inp)
>> {
>> struct tcpcb *tp;
>> tp =3D intotcpcb(inp);
>>
>> if (inp->inp_flags & INP_TIMEWAIT) {
>> if (inp->inp_flags & INP_DROPPED) {
>> in_pcbdetach(inp);
>> in_pcbfree(inp); <--
>> }
>>
>> 2. Second when tcptw expires here:
>>
>> void
>> tcp_twclose(struct tcptw *tw, int reuse)
>> {
>> struct socket *so;
>> struct inpcb *inp;
>>
>> inp =3D tw->tw_inpcb;
>>
>> tcp_tw_2msl_stop(tw, reuse);
>> inp->inp_ppcb =3D NULL;
>> in_pcbdrop(inp);
>>
>> so =3D inp->inp_socket;
>> if (so !=3D NULL) {
>> ...
>> } else {
>> in_pcbfree(inp); <--
>> }
>>
>> This behavior is backed by Palle kernel panic backstraces and coredum=
ps.
>>
>> o Solutions:
>>
>> Long: Forbid to call tcp_close() when inp is in INP_TIMEWAIT state,
>> the TCP stack rule being:
>>
>> - if !INP_TIMEWAIT: Call tcp_close()
>> - if INP_TIMEWAIT: Call tcp_twclose() (or call nothing, the tcptw wil=
l
>> expire/be recycled anyway)
>>
>> Short:
>> if INP_TIMEWAIT & INP_DROPPED:
>> Do not call in_pcbfree(inp) in tcp_detach() unless tcptw is alread=
y
>> discarded.
>>
>> The long solution seems cleaner, backed by tcp_detach() old comments
>> and most of current tcp_close() calls but I won't take that longer pat=
h
>> without -net approval first.
>=20
> I prefer the longer solution if it keeps tcp_detach() simpler by avoidi=
ng
> an extra condition. Please just document it via assertions in tcp_clos=
e()
> (or is this the assertion that fired and triggered the reported panic? =
If so,
> then you obviously don't need to add it. :-P)
Thanks for your answer. And indeed tcp_detach() will be kept simpler
with the longer solution, I will introduce the new assertion in
tcp_close(), something like :
struct tcpcb *
tcp_close(struct tcpcb *tp)
{
...
/*
* tcp_close() should not called on TIME_WAIT connections.
* These connections should be either teardown using
* tcp_twclose(), or left alone waiting for TIME_WAIT timeout
* expiration.
*/
KASSERT((inpb->inp_flags & INP_TIMEWAIT) =3D=3D 0,
("tcp_close cannot be called on TIME_WAIT connections"));
And I will fix all paths that could lead to calling tcp_close() on TCP
TIME_WAIT connections (that is why this solution will be longer). I
found three potential paths so far.
--
Julien
--vwr74Sb8IPl79CrqbqNTJRdLVuT0ekrIh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWCQOeAAoJEKVlQ5Je6dhxn7cIAJbwLeCyeewBpBaHNaHMuNUl
n1M9mpFG9EpzwP2TFjsSaTGq3UinsVnVAGOweNWGv31oM8izBw3QVB6BKXB5WyPI
aVAin0xF4deEFljGdFYjUgFbu4eZ4Ce8TFXnsnhk7PPdrpNWdUwYA/8XBfyzFGkK
h3mviAT+IZuJSQA32WuNe4B/7z4TEeh3D/o7HKKz7aL1NkvSNd1bWvL2v2trWHun
HoZoiiW6iehUXOHGjtMyTw8s3Q2EDXwCwKnzlKYCW3vNorWR+hNzZlwBxIS3c5nf
Ic8jm1skKN0sELzb9gD90GXFSsbBURWPxFdfMtK65eLumoF+ld9VNbSIsfb4TUs=
=ELxz
-----END PGP SIGNATURE-----
--vwr74Sb8IPl79CrqbqNTJRdLVuT0ekrIh--
From owner-freebsd-net@freebsd.org Mon Sep 28 09:59:25 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2C5CA0B96E
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 09:59:25 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com
[IPv6:2a00:1450:400c:c05::22a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 548361EF1;
Mon, 28 Sep 2015 09:59:25 +0000 (UTC)
(envelope-from julien.charbon@gmail.com)
Received: by wicfx3 with SMTP id fx3so93049499wic.0;
Mon, 28 Sep 2015 02:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to:content-type;
bh=Hl7cxn4SrmFDFMi5Br2Nj5y872TkMqzH4sAUtMko8eY=;
b=cr2JrgVSB/8Ab85iZbuSaDHm9b+hwrN47xgVO8d5bJbD63uZ/+P1NaImkkv+oCAxW+
gbCDKhMPTvmU7QxbRi0JexQcaonQ1GtKbl+9GC7wj0RYm5PIj8KCmBQ4HQWJlbUisA0C
xJxw9SfqROne+c+ikuZtf7P3mKnc9Rhsaqi0dgpHUhkT82rE3mWSWOA/1tAabMf8hCeh
d0PFX4O4p+XPMgV4BYlS7djCU3UFri07mEqZ+UfnkUzzHme0f/sgzi8wCP6pvLX8926a
iZuX87mkcdKGSn1ekbRWhypNjWUesgAsSWEyMEAB1nK7KH61gc9Wzy0Yc/Blyi6nXW7a
KBYg==
X-Received: by 10.180.87.102 with SMTP id w6mr18681202wiz.88.1443434363870;
Mon, 28 Sep 2015 02:59:23 -0700 (PDT)
Received: from fri2jcharbon-m1.vcorp.ad.vrsn.com ([217.30.88.7])
by smtp.googlemail.com with ESMTPSA id l1sm17460771wjx.13.2015.09.28.02.59.23
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 28 Sep 2015 02:59:23 -0700 (PDT)
Subject: Re: Can tcp_close() be called in INP_TIMEWAIT case
To: hiren panchasara <hiren@strugglingcoder.info>
References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org>
<5602BB7A.9010504@freebsd.org> <5603E8E4.5030406@freebsd.org>
<2216936.QIvWsOndvU@ralph.baldwin.cx>
<20150925224635.GR46700@strugglingcoder.info>
Cc: freebsd-net@freebsd.org, Palle Girgensohn <girgen@freebsd.org>
From: Julien Charbon <julien.charbon@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56090F6E.3000700@gmail.com>
Date: Mon, 28 Sep 2015 11:59:10 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150925224635.GR46700@strugglingcoder.info>
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="G0VmSHuAHNFtkf8Alj94KjV62nLmgpbs4"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 09:59:25 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--G0VmSHuAHNFtkf8Alj94KjV62nLmgpbs4
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi Hiren,
On 26/09/15 00:46, hiren panchasara wrote:
> On 09/25/15 at 09:42P, John Baldwin wrote:
>> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>>> So the issue is:
>>>
>>> - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT=
>>> state and sets the INP_DROPPED flag,
>>> - tcp_detach() is called when the last reference on socket is droppe=
d
>>>
>>> then now in_pcbfree() can be called twice instead of once:
>>>
>>> 1. First in tcp_detach():
>>>
>>> static void
>>> tcp_detach(struct socket *so, struct inpcb *inp)
>>> {
>>> struct tcpcb *tp;
>>> tp =3D intotcpcb(inp);
>>>
>>> if (inp->inp_flags & INP_TIMEWAIT) {
>>> if (inp->inp_flags & INP_DROPPED) {
>>> in_pcbdetach(inp);
>>> in_pcbfree(inp); <--
>>> }
>>>
>>> 2. Second when tcptw expires here:
>>>
>>> void
>>> tcp_twclose(struct tcptw *tw, int reuse)
>>> {
>>> struct socket *so;
>>> struct inpcb *inp;
>>>
>>> inp =3D tw->tw_inpcb;
>>>
>>> tcp_tw_2msl_stop(tw, reuse);
>>> inp->inp_ppcb =3D NULL;
>>> in_pcbdrop(inp);
>>>
>>> so =3D inp->inp_socket;
>>> if (so !=3D NULL) {
>>> ...
>>> } else {
>>> in_pcbfree(inp); <--
>>> }
>>>
>>> This behavior is backed by Palle kernel panic backstraces and coredu=
mps.
>>>
>>> o Solutions:
>>>
>>> Long: Forbid to call tcp_close() when inp is in INP_TIMEWAIT state,=
>>> the TCP stack rule being:
>>>
>>> - if !INP_TIMEWAIT: Call tcp_close()
>>> - if INP_TIMEWAIT: Call tcp_twclose() (or call nothing, the tcptw wi=
ll
>>> expire/be recycled anyway)
>>>
>>> Short:
>>> if INP_TIMEWAIT & INP_DROPPED:
>>> Do not call in_pcbfree(inp) in tcp_detach() unless tcptw is alrea=
dy
>>> discarded.
>>>
>>> The long solution seems cleaner, backed by tcp_detach() old comments=
>>> and most of current tcp_close() calls but I won't take that longer pa=
th
>>> without -net approval first.
>>
>> I prefer the longer solution if it keeps tcp_detach() simpler by avoid=
ing
>> an extra condition. Please just document it via assertions in tcp_clo=
se()
>> (or is this the assertion that fired and triggered the reported panic?=
If so,
>> then you obviously don't need to add it. :-P)
>=20
> I also like the longer solution because it seems cleaner and more
> readable/followable.
Thanks for your answer. Will do this change and create a review for it.=
> Julien, nice work on investigation and follow-up. :-)
Thanks!
--
Julien
--G0VmSHuAHNFtkf8Alj94KjV62nLmgpbs4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWCQ96AAoJEKVlQ5Je6dhxDxIIALop6JagdDm5QhBOvdpX0hXz
pjTV+vCp6V8rNVD2VGVhFpNz8xk3Z9YPvNr63nK8o1LdYNJs6s9+V1CqhaGNqulF
g/lRnjedRSNnV415968PttIbepYLmnBE/4lVSQ8TET7XiT+b6bolUzXXl4AzZvQD
+cTFm4hqu5jKr5tBjI3uqR4OwKFf7rf5LSIQjskRYEs1w6ZI//svk807PTX6MGhR
9kf0eMvwX+bDbIp9X6TIvodbzc5tTLssV3Egs5TbjUKLCkbkqN7KqrHA704ZSQQH
SBqEtTZo0bRE195u9IW++FUgswCfjYT13pBKpnRZrfjEUvzp1Xrsi7jRJpUAwFA=
=Tx4I
-----END PGP SIGNATURE-----
--G0VmSHuAHNFtkf8Alj94KjV62nLmgpbs4--
From owner-freebsd-net@freebsd.org Mon Sep 28 11:19:54 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC78BA029B4
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 11:19:54 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id A94041FAA
for <freebsd-net@FreeBSD.org>; Mon, 28 Sep 2015 11:19:54 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8SBJsZA079745
for <freebsd-net@FreeBSD.org>; Mon, 28 Sep 2015 11:19:54 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203409] page fault in tcp_do_segment (r287759 suspected)
Date: Mon, 28 Sep 2015 11:19:54 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: avg@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc assigned_to
Message-ID: <bug-203409-2472-sfiLUQVZAz@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203409-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203409-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 11:19:54 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203409
Andriy Gapon <avg@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gnn@FreeBSD.org
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Mon Sep 28 11:34:32 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96FC0A03413
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 11:34:32 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 8393619E3
for <freebsd-net@FreeBSD.org>; Mon, 28 Sep 2015 11:34:32 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8SBYWwJ005465
for <freebsd-net@FreeBSD.org>; Mon, 28 Sep 2015 11:34:32 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203409] page fault in tcp_do_segment (r287759 suspected)
Date: Mon, 28 Sep 2015 11:34:32 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: avg@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-203409-2472-rycyl2glmW@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203409-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203409-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 11:34:32 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203409
--- Comment #1 from Andriy Gapon <avg@FreeBSD.org> ---
Created attachment 161483
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161483&action=edit
fix / work-around
The attached trivial patch seems to make the issue go away.
But I am not sure if that's a correct fix as not firing the probe at all could
result in an incomplete event trail.
As a side note, in my opinion the use of mtod() with the SDT probes in
tcp_do_segment() is slightly against the recommended SDT usage. Typically an
SDT probe's arguments are values that are actually used near the probe and thus
have a high chance of being in CPU registers or in the L1 cache. In
tcp_do_segment() there does not seem to be any access to m_data, so the probes
have a bigger overhead because of the extra memory access. m_data's value
might still be in the L1 cache, though.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Mon Sep 28 16:47:59 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1D0BA0BE00
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 28 Sep 2015 16:47:59 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 8EA291C97
for <freebsd-net@FreeBSD.org>; Mon, 28 Sep 2015 16:47:59 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8SGlxKQ098884
for <freebsd-net@FreeBSD.org>; Mon, 28 Sep 2015 16:47:59 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203409] page fault in tcp_do_segment (r287759 suspected)
Date: Mon, 28 Sep 2015 16:47:59 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: hiren@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: gnn@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-203409-2472-P5raRAYRuB@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203409-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203409-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 16:47:59 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203409
Hiren Panchasara <hiren@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-net@FreeBSD.org |gnn@FreeBSD.org
--- Comment #2 from Hiren Panchasara <hiren@FreeBSD.org> ---
(In reply to Andriy Gapon from comment #1)
Assigning this bug to George.
Andriy: Your patch is any day better than hitting page faults. :-)
I'd say go ahead and commit this patch if George/others don't have any
immediate better fix.
You raise a good/valid point about the efficiency. I hope we could
prove/disprove the theory somehow.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Tue Sep 29 06:23:01 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B90CA0B55C
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 29 Sep 2015 06:23:01 +0000 (UTC)
(envelope-from xiaojin2630@163.com)
Received: from m13-145.163.com (m13-145.163.com [220.181.13.145])
by mx1.freebsd.org (Postfix) with ESMTP id 58FB913AE
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 06:22:59 +0000 (UTC)
(envelope-from xiaojin2630@163.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=jdXuQ
EWZK5CEybOBbaFo4wkn/wd5KHDJAlFaT9mgf5o=; b=cWpPJcvUSCwOR8N31+Ygy
iDbEY5903UHtQSSz566uz0/QbPPCPI5Ap24KnS3ov6DdG/lbwAX6Xu9By0CKGOVW
XPGyb+Id9OaYcOJ6BHnjmyn5L0Hd/VuHMOcJhv0N1msHqqr6jh6LqxFSyiLEQbOx
qMSLcuj9h2MsIR++aHHuDs=
Received: from xiaojin2630$163.com ( [61.191.204.248, 176.34.63.150,
10.144.1.72] ) by ajax-webmail-wmsvr145 (Coremail) ; Tue, 29 Sep 2015
14:07:41 +0800 (CST)
X-Originating-IP: [61.191.204.248, 176.34.63.150, 10.144.1.72]
Date: Tue, 29 Sep 2015 14:07:41 +0800 (CST)
From: wang <xiaojin2630@163.com>
To: freebsd-net@FreeBSD.org
Cc: 267357206@qq.com
Subject: pkt-gen unable work with three interfaces simultaneously in my
freebsd system
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
20150911(74783.7961) Copyright (c) 2002-2015 www.mailtech.cn 163com
X-CM-CTRLDATA: +PzMZ2Zvb3Rlcl9odG09MTI1Njk6NTY=
MIME-Version: 1.0
Message-ID: <4fa0a783.726.15017b6b59a.Coremail.xiaojin2630@163.com>
X-CM-TRANSID: kcGowEDpv0WuKgpWEfqVAA--.2652W
X-CM-SenderInfo: p0ld0ytlqsljqq6rljoofrz/1tbiQBuEFFSILa2EYgABsw
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 06:23:01 -0000
aGksIGV2ZXJ5b25lOgoKCkkgcmVjZW50bHkgdW5kZXIgRnJlZUJTRCwgd2FudCB0byBhY2hpZXZl
IHBrdC1nZW4gY2FuIHNlbmQgbW9yZSB0cmFmZmljLCBiZWNhdXNlIEkgZGlkIG5vdCBpeGdiIGNh
cmQsIG9ubHkgYSBwbHVyYWxpdHkgb2YgaWdiLCB3YW50IHRvIGFjaGlldmUgcHJvZHVjZSA0LDVH
YnBzIGZsb3cgdGVzdCBzZXJ2ZXIuIEJ1dCBJIGVuY291bnRlcmVkIHNvbWUgcHJvYmxlbXMuCgoK
MS4gT3BlbiB0aGUgZmlyc3Qgb25lIHByb2Nlc3MsIHdvcmtzIHdlbGwsIHRoZSBmbG93IHJlYWNo
ZXMgZnVsbCBiYW5kd2lkdGgKcm9vdCBAIHRlc3QgW35dICMgLi9wa3QtZ2VuIC1mIHR4IC1pIGln
YjEgLWQgMTkyLjE2OC41My4yNyAtRCA2QzogNjI6IDZEOiA2NjogN0E6IEU1IC1hIDIKMTA0LjY3
MDE4OSBtYWluIFsxODU3XSBpbnRlcmZhY2UgaXMgaWdiMQoxMDQuNjcwMjEzIG1haW4gWzE5Njhd
IHJ1bm5pbmcgb24gMSBjcHVzIChoYXZlIDgpCjEwNC42NzAyNzYgZXh0cmFjdF9pcF9yYW5nZSBb
MzYyXSByYW5nZSBpcyAxMC4wLjAuMTowIHRvIDEwLjAuMC4xOjAKMTA0LjY3MDI4MyBleHRyYWN0
X2lwX3JhbmdlIFszNjJdIHJhbmdlIGlzIDE5Mi4xNjguNTMuMjc6MCB0byAxOTIuMTY4LjUzLjI3
OjAKMTA0LjY3MDMwOCBtYWluIFsyMDQ3XSBnLmlmbmFtZSA9IG5ldG1hcDogaWdiMQoxMDUuMDE2
OTI2IG1haW4gWzIwNzBdIG1hcHBlZCAxMTQwMDBLQiBhdCAweDI4YzAwMDAwCjEwNS4wMTY5NDkg
bWFpbiBbMjA3Ml0gbm1yZXE6IHNsb3Q6IHR4ID0gMTAyNCwgcnggPSAxMDI0OyByaW5nOiB0eCA9
IDgsIHJ4ID0gOApTZW5kaW5nIG9uIG5ldG1hcDogaWdiMTogOCBxdWV1ZXMsIDEgdGhyZWFkcyBh
bmQgMSBjcHVzLgoxMC4wLjAuMSAtPiAxOTIuMTY4LjUzLjI3ICgwMDogMDA6IDAwOiAwMDogMDA6
IDAwIC0+IDZDOiA2MjogNkQ6IDY2OiA3QTogRTUpCjEwNS4wMTY5OTAgbWFpbiBbMjE1OF0gU2Vu
ZGluZyA1MTIgcGFja2V0cyBldmVyeSAwLjAwMDAwMDAwMCBzCjEwNS4wMTY5OTMgbWFpbiBbMjE2
MF0gV2FpdCAyIHNlY3MgZm9yIHBoeSByZXNldAoxMDcuMDU0MDMwIG1haW4gWzIxNjJdIFJlYWR5
IC4uLgoxMDcuMDU0MTUyIHNlbmRlcl9ib2R5IFsxMTQ3XSBzdGFydCwgZmQgMyBtYWluX2ZkIDMK
MTA3LjA1NDI4MiBzZW5kZXJfYm9keSBbMTE4M10gYmVmb3JlIGdvdG8gd2hpbGU6IG4gPSAwLCBz
ZW50ID0gMAoxMDcuMTIxNzA2IHNlbmRlcl9ib2R5IFsxMjIyXSBkcm9wIGNvcHkKMTA4LjA1NDk0
NSBtYWluX3RocmVhZCBbMTY0N10gMTQ4NzY0NyBwcHMgKDEuNDg5IE1wa3RzIDEuMDAwIEdicHMg
aW4gMTAwMDc5OCB1c2VjKSAyLjI1IGF2Z19iYXRjaAoxMDkuMDU1OTQyIG1haW5fdGhyZWFkIFsx
NjQ3XSAxNDg4MTc0IHBwcyAoMS40OTAgTXBrdHMgMS4wMDEgR2JwcyBpbiAxMDAwOTk3IHVzZWMp
IDIuMjEgYXZnX2JhdGNoCjExMC4wNTY5NDIgbWFpbl90aHJlYWQgWzE2NDddIDE0ODgxNzEgcHBz
ICgxLjQ5MCBNcGt0cyAxLjAwMSBHYnBzIGluIDEwMDEwMDEgdXNlYykgMi4yMSBhdmdfYmF0Y2gK
MTExLjA1Nzk0NSBtYWluX3RocmVhZCBbMTY0N10gMTQ4ODE2NiBwcHMgKDEuNDkwIE1wa3RzIDEu
MDAxIEdicHMgaW4gMTAwMTAwMiB1c2VjKSAyLjIxIGF2Z19iYXRjaAoKCjIuIE9wZW4gdGhlIGZp
cnN0IHR3byBwcm9jZXNzZXMsIHdvcmsKcm9vdCBAIHRlc3QgW35dICMgLi9wa3QtZ2VuIC1mIHR4
IC1pIGlnYjIgLWQgMTkyLjE2OC41My4yNyAtRCA2QzogNjI6IDZEOiA2NjogN0E6IEU1IC1hIDMK
MTEzLjIyNjc4NiBtYWluIFsxODU3XSBpbnRlcmZhY2UgaXMgaWdiMgoxMTMuMjI2ODA5IG1haW4g
WzE5NjhdIHJ1bm5pbmcgb24gMSBjcHVzIChoYXZlIDgpCjExMy4yMjY4ODMgZXh0cmFjdF9pcF9y
YW5nZSBbMzYyXSByYW5nZSBpcyAxMC4wLjAuMTowIHRvIDEwLjAuMC4xOjAKMTEzLjIyNjg5MiBl
eHRyYWN0X2lwX3JhbmdlIFszNjJdIHJhbmdlIGlzIDE5Mi4xNjguNTMuMjc6MCB0byAxOTIuMTY4
LjUzLjI3OjAKMTEzLjIyNjkyMSBtYWluIFsyMDQ3XSBnLmlmbmFtZSA9IG5ldG1hcDogaWdiMgox
MTMuMjQ0OTA4IG1haW4gWzIwNzBdIG1hcHBlZCAxMTQwMDBLQiBhdCAweDI4YzAwMDAwCjExMy4y
NDQ5MTkgbWFpbiBbMjA3Ml0gbm1yZXE6IHNsb3Q6IHR4ID0gMTAyNCwgcnggPSAxMDI0OyByaW5n
OiB0eCA9IDgsIHJ4ID0gOApTZW5kaW5nIG9uIG5ldG1hcDogaWdiMjogOCBxdWV1ZXMsIDEgdGhy
ZWFkcyBhbmQgMSBjcHVzLgoxMC4wLjAuMSAtPiAxOTIuMTY4LjUzLjI3ICgwMDogMDA6IDAwOiAw
MDogMDA6IDAwIC0+IDZDOiA2MjogNkQ6IDY2OiA3QTogRTUpCjExMy4yNDQ5NTUgbWFpbiBbMjE1
OF0gU2VuZGluZyA1MTIgcGFja2V0cyBldmVyeSAwLjAwMDAwMDAwMCBzCjExMy4yNDQ5NTkgbWFp
biBbMjE2MF0gV2FpdCAyIHNlY3MgZm9yIHBoeSByZXNldAoxMTUuMjQ1OTQ0IG1haW4gWzIxNjJd
IFJlYWR5IC4uLgoxMTUuMjQ2MDgxIHNlbmRlcl9ib2R5IFsxMTQ3XSBzdGFydCwgZmQgMyBtYWlu
X2ZkIDMKMTE1LjI0NjIyMiBzZW5kZXJfYm9keSBbMTE4M10gYmVmb3JlIGdvdG8gd2hpbGU6IG4g
PSAwLCBzZW50ID0gMAoxMTUuMzEzODIyIHNlbmRlcl9ib2R5IFsxMjIyXSBkcm9wIGNvcHkKMTE2
LjI0Njk0MiBtYWluX3RocmVhZCBbMTY0N10gMTQ4NzM4OSBwcHMgKDEuNDg5IE1wa3RzIDEuMDAw
IEdicHMgaW4gMTAwMDg2MiB1c2VjKSAyLjQ3IGF2Z19iYXRjaAoxMTcuMjQ4OTM5IG1haW5fdGhy
ZWFkIFsxNjQ3XSAxNDg4MTc3IHBwcyAoMS40OTEgTXBrdHMgMS4wMDIgR2JwcyBpbiAxMDAxOTk4
IHVzZWMpIDIuNDMgYXZnX2JhdGNoCjExOC4yNTA5NDMgbWFpbl90aHJlYWQgWzE2NDddIDE0ODgx
NjAgcHBzICgxLjQ5MSBNcGt0cyAxLjAwMiBHYnBzIGluIDEwMDIwMDQgdXNlYykgMi40MyBhdmdf
YmF0Y2gKMTE5LjI1MjkzOCBtYWluX3RocmVhZCBbMTY0N10gMTQ4ODE4NiBwcHMgKDEuNDkxIE1w
a3RzIDEuMDAyIEdicHMgaW4gMTAwMTk5NSB1c2VjKSAyLjQzIGF2Z19iYXRjaAoKCjMuIFR1cm4g
b24gdGhlIGZpcnN0IHRocmVlIHByb2Nlc3NlcywgZG9lcyBub3Qgd29yawpyb290IEAgdGVzdCBb
fl0gIyAuL3BrdC1nZW4gLWYgdHggLWkgaWdiMyAtZCAxOTIuMTY4LjUzLjI3IC1EIDZDOiA2Mjog
NkQ6IDY2OiA3QTogRTUgLWEgNAozNDkuNzE1MDMxIG1haW4gWzE4NTddIGludGVyZmFjZSBpcyBp
Z2IzCjM0OS43MTUwNTUgbWFpbiBbMTk2OF0gcnVubmluZyBvbiAxIGNwdXMgKGhhdmUgOCkKMzQ5
LjcxNTEzMCBleHRyYWN0X2lwX3JhbmdlIFszNjJdIHJhbmdlIGlzIDEwLjAuMC4xOjAgdG8gMTAu
MC4wLjE6MAozNDkuNzE1MTQyIGV4dHJhY3RfaXBfcmFuZ2UgWzM2Ml0gcmFuZ2UgaXMgMTkyLjE2
OC41My4yNzowIHRvIDE5Mi4xNjguNTMuMjc6MAozNDkuNzE1MTcxIG1haW4gWzIwNDddIGcuaWZu
YW1lID0gbmV0bWFwOiBpZ2IzCjM0OS43MTgxNzYgbm1fb3BlbiBbODA4XSBOSU9DUkVHSUYgZmFp
bGVkOiBDYW4gbm90IGFsbG9jYXRlIG1lbW9yeSBpZ2IzCjM0OS43MTgxODQgbWFpbiBbMjA1MF0g
VW5hYmxlIHRvIG9wZW4gbmV0bWFwOiBpZ2IzOiBDYW4gbm90IGFsbG9jYXRlIG1lbW9yeQozNDku
NzE4MTkwIG1haW4gWzIxMjNdIGFib3J0aW5nClVzYWdlOgpwa3QtZ2VuIGFyZ3VtZW50cwotaSBp
bnRlcmZhY2UgaW50ZXJmYWNlIG5hbWUKLWYgZnVuY3Rpb24gdHggcnggcGluZyBwb25nCi1uIGNv
dW50IG51bWJlciBvZiBpdGVyYXRpb25zIChjYW4gYmUgMCkKLXQgcGt0c190b19zZW5kIGFsc28g
Zm9yY2VzIHR4IG1vZGUKLXIgcGt0c190b19yZWNlaXZlIGFsc28gZm9yY2VzIHJ4IG1vZGUKLWwg
cGt0X3NpemUgaW4gYnl0ZXMgZXhjbHVkaW5nIENSQwotZCBkc3RfaXAgWzogcG9ydCBbLWRzdF9p
cDogcG9ydF1dIHNpbmdsZSBvciByYW5nZQotcyBzcmNfaXAgWzogcG9ydCBbLXNyY19pcDogcG9y
dF1dIHNpbmdsZSBvciByYW5nZQotRCBEc3QtbWFjCgoKVGlwIENhbiBub3QgYWxsb2NhdGUgbWVt
b3J5LCBJIHdvdWxkIGxpa2UgdG8gYWNoaWV2ZSBpZ2IxLCBpZ2IyLCBpZ2IzLCBpZ2I0IHdvcmsg
c2ltdWx0YW5lb3VzbHksIGJ1dCBub3cgb25seSB0d28gaW50ZXJmYWNlcyBhdCB0aGUgc2FtZSB0
aW1lIHdvcmssIHRoZSBmaXJzdCB0aHJlZSBpbnRlcmZhY2VzIHdpbGwgbm90IHdvcmssIGFuZCB3
aGVyZSBpcyB0aGUgcHJvYmxlbSwgcGxlYXNlIGhlbHAgdG8gc29sdmUgdGhpcyBwcm9ibGVtLCBU
aGFuayB5b3UgdmVyeSBtdWNoLgoKCgoKSGVyZSBpcyB0aGUgdG9wIG91dHB1dApsYXN0IHBpZDog
Mzk4MTQ7IGxvYWQgYXZlcmFnZXM6IDAuNDAsIDAuMTMsIDAuMDkKMzAgcHJvY2Vzc2VzOiAzIHJ1
bm5pbmcsIDI3IHNsZWVwaW5nCkNQVTogMS4zJSB1c2VyLCAwLjAlIG5pY2UsIDIyLjYlIHN5c3Rl
bSwgMy4zJSBpbnRlcnJ1cHQsIDcyLjklIGlkbGUKTWVtOiA1NjQ0SyBBY3RpdmUsIDI1Mk0gSW5h
Y3QsIDMxN00gV2lyZWQsIDkwTSBCdWYsIDI0MTdNIEZyZWUKU3dhcDogMzgyTSBUb3RhbCwgMzgy
TSBGcmVlCgoKUElEIFVTRVJOQU1FIFRIUiBQUkkgTklDRSBTSVpFIFJFUyBTVEFURSBDIFRJTUUg
V0NQVSBDT01NQU5ECjM5ODA0IHJvb3QgMiA5MiAwIDEyNU0gMTg1MTZLIFJVTiAyIDA6MTIgNjku
NzglIHBrdC1nZW4KMzk4MDkgcm9vdCAyIDkwIDAgMTI1TSAxODUxNksgQ1BVMyAzIDA6MTAgNjIu
NzAlIHBrdC1nZW4KMTYxMiByb290IDEgMjAgMCAxNTkxNksgNjc5Nksgc2VsZWN0IDYgMDoxMCAw
LjAwJSBodHRwZAoxNjI5IHJvb3QgMSAyMCAwIDEwMTY0SyAxOTIwSyBuYW5zbHAgNiAwOjAyIDAu
MDAlIGNyb24KMTQwNCByb290IDEgMjAgMCAxMDEyOEsgMTc2NEsgc2VsZWN0IDcgMDowMiAwLjAw
JSBzeXNsb2dkCgoKCgp0ZXN0IGVudmlyb25tZW50Cj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09Cm9wZXJhdGluZyBzeXN0ZW06CiAgICByb290IEAgdGVzdCBbbmV0bWFwLmdpdF0gIyB1bmFt
ZSAtc2EKRnJlZUJTRCB0ZXN0IDEwLjEtUkVMRUFTRSBGcmVlQlNEIDEwLjEtUkVMRUFTRSAjIDA6
IFdlZCBBdWcgMTkgMTI6Mzk6MDcgQ1NUIDIwMTUgcm9vdCBAIHZtdDogLyB1c3IgLyBzcmMgLyBz
eXMgLyBpMzg2IC8gY29tcGlsZSAvIEdFTkVSSUNfTkVUTUFQIGkzODYKcm9vdCBAIHRlc3QgW25l
dG1hcC5naXRdICMgc3lzY3RsIC1hIHwgZ3JlcCBody5tbwpody5tb2RlbDogSW50ZWwgKFIpIFhl
b24gKFIpIENQVSBFNTYwNiBAIDIuMTNHSHogKDgtY29yZSkKCgpyb290IEAgdGVzdCBbbmV0bWFw
LmdpdF0gIyBzeXNjdGwgLWEgfCBncmVwIG1lbQprZXJuLmlwYy5tYXhtYnVmbWVtOiAyMTYwMDY2
NTYKZGV2aWNlIG1lbQp2bS5rbWVtX3NpemU6IDQzMjAxMzMxMgp2bS5rbWVtX3ptYXg6IDY1NTM2
CnZtLmttZW1fc2l6ZV9taW46IDEyNTgyOTEyCnZtLmttZW1fc2l6ZV9tYXg6IDQzMjAxMzMxMgp2
bS5rbWVtX3NpemVfc2NhbGU6IDMKdm0ua21lbV9tYXBfc2l6ZTogMTU0OTM5MzkyCnZtLmttZW1f
bWFwX2ZyZWU6IDI3NzA3MzkyMAp2bS5sb3dtZW1fcGVyaW9kOiAxMAp2ZnMudWZzLmRpcmhhc2hf
bWF4bWVtOiAyMDk3MTUyCnZmcy51ZnMuZGlyaGFzaF9tZW06IDEyMjQ1NjMKdmZzLnVmcy5kaXJo
YXNoX2xvd21lbWNvdW50OiAwCmh3LnBoeXNtZW06IDMxOTA3NzU4MDgKaHcudXNlcm1lbTogMjg3
NTk5MDAxNgpody5yZWFsbWVtOiA0MTk0MzA0Cmh3LmNiYi5zdGFydF9tZW1vcnk6IDIyODE3MDEz
NzYKaHcucGNpLmhvc3RfbWVtX3N0YXJ0OiAyMTQ3NDgzNjQ4CnAxMDAzXzFiLm1lbWxvY2s6IDAK
cDEwMDNfMWIubWVtbG9ja19yYW5nZTogMApwMTAwM18xYi5tZW1vcnlfcHJvdGVjdGlvbjogMApw
MTAwM18xYi5zaGFyZWRfbWVtb3J5X29iamVjdHM6IDIwMDExMgpkZXYueGVuLmJhbGxvb24ubG93
X21lbTogMApkZXYueGVuLmJhbGxvb24uaGlnaF9tZW06IDAKCgpyb290IEAgdGVzdCBbfl0gIyBp
ZmNvbmZpZwppZ2IwOiBmbGFncyA9IDg4NDIgPEJST0FEQ0FTVCwgUlVOTklORywgU0lNUExFWCwg
TVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMApvcHRpb25zID0gNDAzYmIgPFJYQ1NVTSwgVFhD
U1VNLCBWTEFOX01UVSwgVkxBTl9IV1RBR0dJTkcsIEpVTUJPX01UVSwgVkxBTl9IV0NTVU0sIFRT
TzQsIFRTTzYsIFZMQU5fSFdUU08+CmV0aGVyIGIwOiA1MTogOGU6IDAwOiBhNTogMWUKbmQ2IG9w
dGlvbnMgPSAyOSA8UEVSRk9STU5VRCwgSUZESVNBQkxFRCwgQVVUT19MSU5LTE9DQUw+Cm1lZGlh
OiBFdGhlcm5ldCBhdXRvc2VsZWN0ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikKc3RhdHVzOiBh
Y3RpdmUKaWdiMTogZmxhZ3MgPSA4ODQyIDxCUk9BRENBU1QsIFJVTk5JTkcsIFNJTVBMRVgsIE1V
TFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKb3B0aW9ucyA9IDQwM2JiIDxSWENTVU0sIFRYQ1NV
TSwgVkxBTl9NVFUsIFZMQU5fSFdUQUdHSU5HLCBKVU1CT19NVFUsIFZMQU5fSFdDU1VNLCBUU080
LCBUU082LCBWTEFOX0hXVFNPPgpldGhlciBiMDogNTE6IDhlOiAwMDogYTU6IDFmCm5kNiBvcHRp
b25zID0gMjkgPFBFUkZPUk1OVUQsIElGRElTQUJMRUQsIEFVVE9fTElOS0xPQ0FMPgptZWRpYTog
RXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAwMGJhc2VUIDxmdWxsLWR1cGxleD4pCnN0YXR1czogYWN0
aXZlCmlnYjI6IGZsYWdzID0gODg0MiA8QlJPQURDQVNULCBSVU5OSU5HLCBTSU1QTEVYLCBNVUxU
SUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCm9wdGlvbnMgPSA0MDNiYiA8UlhDU1VNLCBUWENTVU0s
IFZMQU5fTVRVLCBWTEFOX0hXVEFHR0lORywgSlVNQk9fTVRVLCBWTEFOX0hXQ1NVTSwgVFNPNCwg
VFNPNiwgVkxBTl9IV1RTTz4KZXRoZXIgYjA6IDUxOiA4ZTogMDA6IGE1OiAyMApuZDYgb3B0aW9u
cyA9IDI5IDxQRVJGT1JNTlVELCBJRkRJU0FCTEVELCBBVVRPX0xJTktMT0NBTD4KbWVkaWE6IEV0
aGVybmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+KQpzdGF0dXM6IGFjdGl2
ZQppZ2IzOiBmbGFncyA9IDg4NDIgPEJST0FEQ0FTVCwgUlVOTklORywgU0lNUExFWCwgTVVMVElD
QVNUPiBtZXRyaWMgMCBtdHUgMTUwMApvcHRpb25zID0gNDAzYmIgPFJYQ1NVTSwgVFhDU1VNLCBW
TEFOX01UVSwgVkxBTl9IV1RBR0dJTkcsIEpVTUJPX01UVSwgVkxBTl9IV0NTVU0sIFRTTzQsIFRT
TzYsIFZMQU5fSFdUU08+CmV0aGVyIGIwOiA1MTogOGU6IDAwOiBhNTogMjEKbmQ2IG9wdGlvbnMg
PSAyOSA8UEVSRk9STU5VRCwgSUZESVNBQkxFRCwgQVVUT19MSU5LTE9DQUw+Cm1lZGlhOiBFdGhl
cm5ldCBhdXRvc2VsZWN0ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikKc3RhdHVzOiBhY3RpdmUK
aWdiNDogZmxhZ3MgPSA4YzAyIDxCUk9BRENBU1QsIE9BQ1RJVkUsIFNJTVBMRVgsIE1VTFRJQ0FT
VD4gbWV0cmljIDAgbXR1IDE1MDAKb3B0aW9ucyA9IDQwM2JiIDxSWENTVU0sIFRYQ1NVTSwgVkxB
Tl9NVFUsIFZMQU5fSFdUQUdHSU5HLCBKVU1CT19NVFUsIFZMQU5fSFdDU1VNLCBUU080LCBUU082
LCBWTEFOX0hXVFNPPgpldGhlciBiMDogNTE6IDhlOiAwMDogYTc6IDk2Cm5kNiBvcHRpb25zID0g
MjkgPFBFUkZPUk1OVUQsIElGRElTQUJMRUQsIEFVVE9fTElOS0xPQ0FMPgptZWRpYTogRXRoZXJu
ZXQgYXV0b3NlbGVjdCAoMTAwMGJhc2VUIDxmdWxsLWR1cGxleD4pCnN0YXR1czogYWN0aXZlCmln
YjU6IGZsYWdzID0gOGMwMiA8QlJPQURDQVNULCBPQUNUSVZFLCBTSU1QTEVYLCBNVUxUSUNBU1Q+
IG1ldHJpYyAwIG10dSAxNTAwCm9wdGlvbnMgPSA0MDNiYiA8UlhDU1VNLCBUWENTVU0sIFZMQU5f
TVRVLCBWTEFOX0hXVEFHR0lORywgSlVNQk9fTVRVLCBWTEFOX0hXQ1NVTSwgVFNPNCwgVFNPNiwg
VkxBTl9IV1RTTz4KZXRoZXIgYjA6IDUxOiA4ZTogMDA6IGE3OiA5NwpuZDYgb3B0aW9ucyA9IDI5
IDxQRVJGT1JNTlVELCBJRkRJU0FCTEVELCBBVVRPX0xJTktMT0NBTD4KbWVkaWE6IEV0aGVybmV0
IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+KQpzdGF0dXM6IGFjdGl2ZQppZ2I2
OiBmbGFncyA9IDhjMDIgPEJST0FEQ0FTVCwgT0FDVElWRSwgU0lNUExFWCwgTVVMVElDQVNUPiBt
ZXRyaWMgMCBtdHUgMTUwMApvcHRpb25zID0gNDAzYmIgPFJYQ1NVTSwgVFhDU1VNLCBWTEFOX01U
VSwgVkxBTl9IV1RBR0dJTkcsIEpVTUJPX01UVSwgVkxBTl9IV0NTVU0sIFRTTzQsIFRTTzYsIFZM
QU5fSFdUU08+CmV0aGVyIGIwOiA1MTogOGU6IDAwOiBhNzogOTgKbmQ2IG9wdGlvbnMgPSAyOSA8
UEVSRk9STU5VRCwgSUZESVNBQkxFRCwgQVVUT19MSU5LTE9DQUw+Cm1lZGlhOiBFdGhlcm5ldCBh
dXRvc2VsZWN0CnN0YXR1czogbm8gY2FycmllcgppZ2I3OiBmbGFncyA9IDhjMDIgPEJST0FEQ0FT
VCwgT0FDVElWRSwgU0lNUExFWCwgTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMApvcHRpb25z
ID0gNDAzYmIgPFJYQ1NVTSwgVFhDU1VNLCBWTEFOX01UVSwgVkxBTl9IV1RBR0dJTkcsIEpVTUJP
X01UVSwgVkxBTl9IV0NTVU0sIFRTTzQsIFRTTzYsIFZMQU5fSFdUU08+CmV0aGVyIGIwOiA1MTog
OGU6IDAwOiBhNzogOTkKbmQ2IG9wdGlvbnMgPSAyOSA8UEVSRk9STU5VRCwgSUZESVNBQkxFRCwg
QVVUT19MSU5LTE9DQUw+Cm1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CnN0YXR1czogbm8gY2Fy
cmllcgplbTA6IGZsYWdzID0gODg0MyA8VVAsIEJST0FEQ0FTVCwgUlVOTklORywgU0lNUExFWCwg
TVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMApvcHRpb25zID0gNDIxOWIgPFJYQ1NVTSwgVFhD
U1VNLCBWTEFOX01UVSwgVkxBTl9IV1RBR0dJTkcsIFZMQU5fSFdDU1VNLCBUU080LCBXT0xfTUFH
SUMsIFZMQU5fSFdUU08+CmV0aGVyIDAwOiAyNTogOTA6IDYyOiAwNjogODQKaW5ldCAxNzIuMTYu
MTIuMjUxIG5ldG1hc2sgMHhmZmZmMDAwMCBicm9hZGNhc3QgMTcyLjE2LjI1NS4yNTUKaW5ldCAx
OTIuMTY4LjEwMC4yNTEgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxOTIuMTY4LjEwMC4y
NTUKbmQ2IG9wdGlvbnMgPSAyOSA8UEVSRk9STU5VRCwgSUZESVNBQkxFRCwgQVVUT19MSU5LTE9D
QUw+Cm1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikK
c3RhdHVzOiBhY3RpdmUKZW0xOiBmbGFncyA9IDg4NDMgPFVQLCBCUk9BRENBU1QsIFJVTk5JTkcs
IFNJTVBMRVgsIE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKb3B0aW9ucyA9IDQyMTliIDxS
WENTVU0sIFRYQ1NVTSwgVkxBTl9NVFUsIFZMQU5fSFdUQUdHSU5HLCBWTEFOX0hXQ1NVTSwgVFNP
NCwgV09MX01BR0lDLCBWTEFOX0hXVFNPPgpldGhlciAwMDogMjU6IDkwOiA2MjogMDY6IDg1Cm5k
NiBvcHRpb25zID0gMjkgPFBFUkZPUk1OVUQsIElGRElTQUJMRUQsIEFVVE9fTElOS0xPQ0FMPgpt
ZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdApzdGF0dXM6IG5vIGNhcnJpZXIKbG8wOiBmbGFncyA9
IDgwNDkgPFVQLCBMT09QQkFDSywgUlVOTklORywgTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYz
ODQKb3B0aW9ucyA9IDYwMDAwMyA8UlhDU1VNLCBUWENTVU0sIFJYQ1NVTV9JUFY2LCBUWENTVU1f
SVBWNj4KaW5ldDYgOjogMSBwcmVmaXhsZW4gMTI4CmluZXQ2IGZlODAgOjogMSUgbG8wIHByZWZp
eGxlbiA2NCBzY29wZWlkIDB4YgppbmV0IDEyNy4wLjAuMSBuZXRtYXNrIDB4ZmYwMDAwMDAKbmQ2
IG9wdGlvbnMgPSAyMSA8UEVSRk9STU5VRCwgQVVUT19MSU5LTE9DQUw+CgoKTXkgcGt0LWdlbiB2
ZXJzaW9uIGlzOgpyb290IEAgdGVzdCBbbmV0bWFwLmdpdF0gIyBnaXQgbG9nCiAKY29tbWl0IGQ0
YmY4OWMwODA0ZmNkMjIyZjM3Y2ZlYmYxY2U5MjBiZjA4ZTQ0ZjkKQXV0aG9yOiBMdWlnaSBSaXp6
byA8cml6em9AaWV0LnVuaXBpLml0PgpEYXRlOiBTYXQgQXVnIDE1IDE4OjEyOjMyIDIwMTUgLTA3
MDAKCgphY3R1YWxseSBjYXRjaCBwYWNrZXRzIGZyb20gdGhlIGhvc3Qgc3RhY2sKLi4uLi4gCgoK
CgoKCgoKIA==
From owner-freebsd-net@freebsd.org Tue Sep 29 13:05:44 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 234DDA0C8AC
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 29 Sep 2015 13:05:44 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::50:5])
by mx1.freebsd.org (Postfix) with ESMTP id 0931A1A9F
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 13:05:44 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: by mailman.ysv.freebsd.org (Postfix)
id 085CCA0C8AA; Tue, 29 Sep 2015 13:05:44 +0000 (UTC)
Delivered-To: net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1E91A0C8A9;
Tue, 29 Sep 2015 13:05:43 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id BE8FD1A9C;
Tue, 29 Sep 2015 13:05:42 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id t8TD5Yw0029633;
Tue, 29 Sep 2015 06:05:34 -0700 (PDT)
(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
by albert.catwhisker.org (8.15.2/8.15.2/Submit) id t8TD5YBN029632;
Tue, 29 Sep 2015 06:05:34 -0700 (PDT) (envelope-from david)
Date: Tue, 29 Sep 2015 06:05:34 -0700
From: David Wolfskill <david@catwhisker.org>
To: current@freebsd.org, net@freebsd.org
Subject: head/amd64 @r288358: panic: lock (sleep mutex) iwn0_com_lock not
locked @ /usr/src/sys/dev/iwn/if_iwn.c:5356
Message-ID: <20150929130534.GI1125@albert.catwhisker.org>
Mail-Followup-To: David Wolfskill <david@catwhisker.org>,
current@freebsd.org, net@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="mlnxvmnLyWgus2CN"
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 13:05:44 -0000
--mlnxvmnLyWgus2CN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
No known/observed issues with:
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #197 r288335M/288335:1=
100079: Mon Sep 28 04:14:47 PDT 2015 root@localhost:/common/S4/obj/usr/=
src/sys/CANARY amd64
on my laptop, but:
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #198 r288358M/288358:1=
100079: Tue Sep 29 04:46:49 PDT 2015 root@localhost:/common/S4/obj/usr/=
src/sys/CANARY amd64
was OK up to the point of attempting to establish a link using the
wlan0 interface (the underlying hardware for which is iwn on the laptop).
I was able to get a crash dump, and am presently copying it to
<http://www.catwhisker.org/~david/FreeBSD/head> (along with the
core.txt, which has already made it over). (I am 3 time zones east
of home, and will be spending the bulk of the day returning home
-- and thus, without ability to respond to email for a while).
Here's an excerpt from the core.txt.5:
localhost dumped core - see /var/crash/vmcore.5
Tue Sep 29 05:14:30 PDT 2015
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #198 r288358M/288358:1=
100079: Tue Sep 29 04:46:49 PDT 2015 root@localhost:/common/S4/obj/usr/=
src/sys/CANARY amd64
panic: lock (sleep mutex) iwn0_com_lock not locked @ /usr/src/sys/dev/iwn/i=
f_iwn.c:5356
GNU gdb 6.1.1 [FreeBSD]
=2E..
Unread portion of the kernel message buffer:
d:
ACPI: SSDT 0xFFFFF80006E30800 0005AA (v01 PmRef ApIst 00003000 INTL 201=
20711)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFFFFF800067F6A00 000119 (v01 PmRef ApCst 00003000 INTL 201=
20711)
random: harvesting attach, 8 bytes (4 bits) from cpu1
cpu2: Processor \_PR_.CPU2 (ACPI ID 3) -> APIC ID 4
cpu2: <ACPI CPU> on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu2
cpu3: Processor \_PR_.CPU3 (ACPI ID 4) -> APIC ID 6
cpu3: <ACPI CPU> on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu3
cpu4: Processor \_PR_.CPU4 (ACPI ID 5) -> APIC ID 1
cpu4: <ACPI CPU> on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu4
cpu5: Processor \_PR_.CPU5 (ACPI ID 6) -> APIC ID 3
cpu5: <ACPI CPU> on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu5
cpu6: Processor \_PR_.CPU6 (ACPI ID 7) -> APIC ID 5
cpu6: <ACPI CPU> on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu6
cpu7: Processor \_PR_.CPU7 (ACPI ID 8) -> APIC ID 7
cpu7: <ACPI CPU> on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu7
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route
hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic
hpet0: t1: irqs 0x00f00000 (0), MSI
hpet0: t2: irqs 0x00f00800 (0), MSI
hpet0: t3: irqs 0x00f01000 (0), MSI
hpet0: t4: irqs 0x00000000 (0), MSI
hpet0: t5: irqs 0x00000000 (0), MSI
hpet0: t6: irqs 0x00000000 (0), MSI
hpet0: t7: irqs 0x00000000 (0), MSI
Timecounter "HPET" frequency 14318180 Hz quality 950
msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
msi: routing MSI-X IRQ 257 to local APIC 0 vector 50
msi: routing MSI-X IRQ 258 to local APIC 0 vector 51
msi: routing MSI-X IRQ 259 to local APIC 0 vector 52
msi: routing MSI-X IRQ 260 to local APIC 0 vector 53
msi: routing MSI-X IRQ 261 to local APIC 0 vector 54
msi: routing MSI-X IRQ 262 to local APIC 0 vector 55
msi: routing MSI-X IRQ 263 to local APIC 0 vector 56
Event timer "HPET" frequency 14318180 Hz quality 550
random: harvesting attach, 8 bytes (4 bits) from hpet0
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment=
0.500000000s)
ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57
Event timer "RTC" frequency 32768 Hz quality 0
random: harvesting attach, 8 bytes (4 bits) from atrtc0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58
Event timer "i8254" frequency 1193182 Hz quality 100
random: harvesting attach, 8 bytes (4 bits) from attimer0
ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_timer0
acpi_ec0: <Embedded Controller: GPE 0x10> port 0x930,0x934 on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_ec0
pci_link0: Index IRQ Rtd Ref IRQs
Initial Probe 0 11 N 0 3 4 5 6 10 11 12 14 15
Validation 0 11 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link0
pci_link1: Index IRQ Rtd Ref IRQs
Initial Probe 0 10 N 0 3 4 5 6 10 11 12 14 15
Validation 0 10 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link1
pci_link2: Index IRQ Rtd Ref IRQs
Initial Probe 0 10 N 0 3 4 5 6 10 11 12 14 15
Validation 0 10 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link2
pci_link3: Index IRQ Rtd Ref IRQs
Initial Probe 0 5 N 0 3 4 5 6 10 11 12 14 15
Validation 0 5 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link3
pci_link4: Index IRQ Rtd Ref IRQs
Initial Probe 0 3 N 0 3 4 5 6 10 11 12 14 15
Validation 0 3 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link4
pci_link5: Index IRQ Rtd Ref IRQs
Initial Probe 0 5 N 0 3 4 5 6 10 11 12 14 15
Validation 0 5 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link5
pci_link6: Index IRQ Rtd Ref IRQs
Initial Probe 0 11 N 0 3 4 5 6 10 11 12 14 15
Validation 0 11 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link6
pci_link7: Index IRQ Rtd Ref IRQs
Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15
Validation 0 255 N 0 3 4 5 6 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link7
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pcib0: decoding 5 range 0-0x3e
pcib0: decoding 4 range 0-0xcf7
pcib0: decoding 4 range 0xd00-0xffff
pcib0: decoding 3 range 0xa0000-0xbffff
pcib0: decoding 3 range 0xdc000-0xdffff
pcib0: decoding 3 range 0xe0000-0xe3fff
pcib0: decoding 3 range 0xe4000-0xe7fff
pcib0: decoding 3 range 0xd0000000-0xfeafffff
pci0: <ACPI PCI bus> on pcib0
pci0: domain=3D0, physical bus=3D0
found-> vendor=3D0x8086, dev=3D0x0c04, revid=3D0x06
domain=3D0, bus=3D0, slot=3D0, func=3D0
class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
found-> vendor=3D0x8086, dev=3D0x0c01, revid=3D0x06
domain=3D0, bus=3D0, slot=3D1, func=3D0
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.1.INTA
pcib0: slot 1 INTA hardwired to IRQ 16
secbus=3D1, subbus=3D1
found-> vendor=3D0x8086, dev=3D0x8c31, revid=3D0x04
domain=3D0, bus=3D0, slot=3D20, func=3D0
class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 2 supports D0 D3 current D0
MSI supports 8 messages, 64 bit
map[10]: type Memory, range 64, base 0xf7120000, size 16, enabled
pcib0: allocated type 3 (0xf7120000-0xf712ffff) for rid 10 of pci0:0:20:0
pcib0: matched entry for 0.20.INTA
pcib0: slot 20 INTA hardwired to IRQ 16
found-> vendor=3D0x8086, dev=3D0x8c3a, revid=3D0x04
domain=3D0, bus=3D0, slot=3D22, func=3D0
class=3D07-80-00, hdrtype=3D0x00, mfdev=3D1
cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 3 supports D0 D3 current D0
MSI supports 1 message, 64 bit
map[10]: type Memory, range 64, base 0xf713c000, size 4, enabled
pcib0: allocated type 3 (0xf713c000-0xf713c00f) for rid 10 of pci0:0:22:0
pcib0: matched entry for 0.22.INTA
pcib0: slot 22 INTA hardwired to IRQ 16
found-> vendor=3D0x8086, dev=3D0x153a, revid=3D0x04
domain=3D0, bus=3D0, slot=3D25, func=3D0
class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D3
powerspec 2 supports D0 D3 current D0
MSI supports 1 message, 64 bit
map[10]: type Memory, range 32, base 0xf7100000, size 17, enabled
pcib0: allocated type 3 (0xf7100000-0xf711ffff) for rid 10 of pci0:0:25:0
map[14]: type Memory, range 32, base 0xf7139000, size 12, enabled
pcib0: allocated type 3 (0xf7139000-0xf7139fff) for rid 14 of pci0:0:25:0
map[18]: type I/O Port, range 32, base 0xf040, size 5, enabled
pcib0: allocated type 4 (0xf040-0xf05f) for rid 18 of pci0:0:25:0
pcib0: matched entry for 0.25.INTA
pcib0: slot 25 INTA hardwired to IRQ 20
found-> vendor=3D0x8086, dev=3D0x8c2d, revid=3D0x04
domain=3D0, bus=3D0, slot=3D26, func=3D0
class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 32, base 0xf7138000, size 10, enabled
pcib0: allocated type 3 (0xf7138000-0xf71383ff) for rid 10 of pci0:0:26:0
pcib0: matched entry for 0.26.INTA
pcib0: slot 26 INTA hardwired to IRQ 16
ehci early: SMM active, request owner change
found-> vendor=3D0x8086, dev=3D0x8c20, revid=3D0x04
domain=3D0, bus=3D0, slot=3D27, func=3D0
class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 2 supports D0 D3 current D0
MSI supports 1 message, 64 bit
map[10]: type Memory, range 64, base 0xf7130000, size 14, enabled
pcib0: allocated type 3 (0xf7130000-0xf7133fff) for rid 10 of pci0:0:27:0
pcib0: matched entry for 0.27.INTA
pcib0: slot 27 INTA hardwired to IRQ 22
found-> vendor=3D0x8086, dev=3D0x8c10, revid=3D0xd4
domain=3D0, bus=3D0, slot=3D28, func=3D0
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTA
pcib0: slot 28 INTA hardwired to IRQ 16
secbus=3D2, subbus=3D2
found-> vendor=3D0x8086, dev=3D0x8c14, revid=3D0xd4
domain=3D0, bus=3D0, slot=3D28, func=3D2
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Dc, irq=3D10
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTC
pcib0: slot 28 INTC hardwired to IRQ 18
secbus=3D3, subbus=3D3
found-> vendor=3D0x8086, dev=3D0x8c16, revid=3D0xd4
domain=3D0, bus=3D0, slot=3D28, func=3D3
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Dd, irq=3D5
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTD
pcib0: slot 28 INTD hardwired to IRQ 19
secbus=3D4, subbus=3D7
found-> vendor=3D0x8086, dev=3D0x8c18, revid=3D0xd4
domain=3D0, bus=3D0, slot=3D28, func=3D4
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTA
pcib0: slot 28 INTA hardwired to IRQ 16
secbus=3D8, subbus=3D8
found-> vendor=3D0x8086, dev=3D0x8c1c, revid=3D0xd4
domain=3D0, bus=3D0, slot=3D28, func=3D6
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Dc, irq=3D10
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTC
pcib0: slot 28 INTC hardwired to IRQ 18
secbus=3D9, subbus=3D16
found-> vendor=3D0x8086, dev=3D0x8c1e, revid=3D0xd4
domain=3D0, bus=3D0, slot=3D28, func=3D7
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Dd, irq=3D5
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTD
pcib0: slot 28 INTD hardwired to IRQ 19
secbus=3D17, subbus=3D17
found-> vendor=3D0x8086, dev=3D0x8c26, revid=3D0x04
domain=3D0, bus=3D0, slot=3D29, func=3D0
class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D5
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 32, base 0xf7137000, size 10, enabled
pcib0: allocated type 3 (0xf7137000-0xf71373ff) for rid 10 of pci0:0:29:0
pcib0: matched entry for 0.29.INTA
pcib0: slot 29 INTA hardwired to IRQ 21
ehci early: SMM active, request owner change
found-> vendor=3D0x8086, dev=3D0x8c4f, revid=3D0x04
domain=3D0, bus=3D0, slot=3D31, func=3D0
class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
found-> vendor=3D0x8086, dev=3D0x282a, revid=3D0x04
domain=3D0, bus=3D0, slot=3D31, func=3D2
class=3D01-04-00, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Db, irq=3D5
powerspec 3 supports D0 D3 current D0
MSI supports 1 message
map[10]: type I/O Port, range 32, base 0xf090, size 3, enabled
pcib0: allocated type 4 (0xf090-0xf097) for rid 10 of pci0:0:31:2
map[14]: type I/O Port, range 32, base 0xf080, size 2, enabled
pcib0: allocated type 4 (0xf080-0xf083) for rid 14 of pci0:0:31:2
map[18]: type I/O Port, range 32, base 0xf070, size 3, enabled
pcib0: allocated type 4 (0xf070-0xf077) for rid 18 of pci0:0:31:2
map[1c]: type I/O Port, range 32, base 0xf060, size 2, enabled
pcib0: allocated type 4 (0xf060-0xf063) for rid 1c of pci0:0:31:2
map[20]: type I/O Port, range 32, base 0xf020, size 5, enabled
pcib0: allocated type 4 (0xf020-0xf03f) for rid 20 of pci0:0:31:2
map[24]: type Memory, range 32, base 0xf7136000, size 11, enabled
pcib0: allocated type 3 (0xf7136000-0xf71367ff) for rid 24 of pci0:0:31:2
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x04
domain=3D0, bus=3D0, slot=3D31, func=3D3
class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0003, statreg=3D0x0280, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Dc, irq=3D10
map[10]: type Memory, range 64, base 0xf7135000, size 8, enabled
pcib0: allocated type 3 (0xf7135000-0xf71350ff) for rid 10 of pci0:0:31:3
map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled
pcib0: allocated type 4 (0xf000-0xf01f) for rid 20 of pci0:0:31:3
pcib0: matched entry for 0.31.INTC
pcib0: slot 31 INTC hardwired to IRQ 18
random: harvesting attach, 8 bytes (4 bits) from hostb0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib1
pcib0: allocated type 3 (0xf4000000-0xf50fffff) for rid 20 of pcib1
pcib0: allocated type 3 (0xe0000000-0xf1ffffff) for rid 24 of pcib1
pcib1: domain 0
pcib1: secondary bus 1
pcib1: subordinate bus 1
pcib1: I/O decode 0xe000-0xefff
pcib1: memory decode 0xf4000000-0xf50fffff
pcib1: prefetched decode 0xe0000000-0xf1ffffff
pcib1: special decode VGA
pci1: <ACPI PCI bus> on pcib1
pcib1: allocated bus range (1-1) for rid 0 of pci1
pci1: domain=3D0, physical bus=3D1
found-> vendor=3D0x10de, dev=3D0x0ff6, revid=3D0xa1
domain=3D0, bus=3D1, slot=3D0, func=3D0
class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1
cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D11
powerspec 3 supports D0 D3 current D0
MSI supports 1 message, 64 bit
map[10]: type Memory, range 32, base 0xf4000000, size 24, enabled
pcib1: allocated memory range (0xf4000000-0xf4ffffff) for rid 10 of pci0:1:=
0:0
map[14]: type Prefetchable Memory, range 64, base 0xe0000000, size =
28, enabled
pcib1: allocated prefetch range (0xe0000000-0xefffffff) for rid 14 of pci0:=
1:0:0
map[1c]: type Prefetchable Memory, range 64, base 0xf0000000, size =
25, enabled
pcib1: allocated prefetch range (0xf0000000-0xf1ffffff) for rid 1c of pci0:=
1:0:0
map[24]: type I/O Port, range 32, base 0xe000, size 7, enabled
pcib1: allocated I/O port range (0xe000-0xe07f) for rid 24 of pci0:1:0:0
pcib1: matched entry for 1.0.INTA
pcib1: slot 0 INTA hardwired to IRQ 16
found-> vendor=3D0x10de, dev=3D0x0e1b, revid=3D0xa1
domain=3D0, bus=3D1, slot=3D0, func=3D1
class=3D04-03-00, hdrtype=3D0x00, mfdev=3D1
cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Db, irq=3D10
powerspec 3 supports D0 D3 current D0
MSI supports 1 message, 64 bit
map[10]: type Memory, range 32, base 0xf5080000, size 14, enabled
pcib1: allocated memory range (0xf5080000-0xf5083fff) for rid 10 of pci0:1:=
0:1
pcib1: matched entry for 1.0.INTB
pcib1: slot 0 INTB hardwired to IRQ 17
vgapci0: <VGA-compatible display> port 0xe000-0xe07f mem 0xf4000000-0xf4fff=
fff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff irq 16 at device 0.0 on pci1
nvidia0: <Quadro K1100M> on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 264 to local APIC 0 vector 59
vgapci0: using IRQ 264 for MSI
vgapci0: child nvidia0 requested pci_enable_io
random: harvesting attach, 8 bytes (4 bits) from nvidia0
vgapci0: Boot video device
random: harvesting attach, 8 bytes (4 bits) from vgapci0
hdac0: <NVIDIA (0x0e1b) HDA Controller> mem 0xf5080000-0xf5083fff irq 17 at=
device 0.1 on pci1
hdac0: PCI card vendor: 0x1028, device: 0x05cc
hdac0: HDA Driver Revision: 20120126_0002
hdac0: Config options: on=3D0x00000000 off=3D0x00000000
hdac0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 265 to local APIC 0 vector 60
hdac0: using IRQ 265 for MSI
hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 4, 64bit, CORB 256, RIRB 256
random: harvesting attach, 8 bytes (4 bits) from hdac0
random: harvesting attach, 8 bytes (4 bits) from pci1
random: harvesting attach, 8 bytes (4 bits) from pcib1
xhci0: <Intel Lynx Point USB 3.0 controller> mem 0xf7120000-0xf712ffff irq =
16 at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: attempting to allocate 1 MSI vectors (8 supported)
msi: routing MSI IRQ 266 to local APIC 0 vector 61
xhci0: using IRQ 266 for MSI
xhci0: MSI enabled
xhci0: Port routing mask set to 0xffffffff
usbus0 on xhci0
xhci0: usbpf: Attached
random: harvesting attach, 8 bytes (4 bits) from usbus0
random: harvesting attach, 8 bytes (4 bits) from xhci0
pci0: <simple comms> at device 22.0 (no driver attached)
em0: <Intel(R) PRO/1000 Network Connection 7.4.2> port 0xf040-0xf05f mem 0x=
f7100000-0xf711ffff,0xf7139000-0xf7139fff irq 20 at device 25.0 on pci0
em0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 267 to local APIC 0 vector 62
em0: using IRQ 267 for MSI
em0: Using an MSI interrupt
em0: bpf attached
em0: Ethernet address: 34:e6:d7:3c:4a:93
em0: netmap queues/slots: TX 1/1024, RX 1/1024
random: harvesting attach, 8 bytes (4 bits) from em0
ehci0: <Intel Lynx Point USB 2.0 controller USB-B> mem 0xf7138000-0xf71383f=
f irq 16 at device 26.0 on pci0
ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 63
usbus1: EHCI version 1.0
usbus1 on ehci0
ehci0: usbpf: Attached
random: harvesting attach, 8 bytes (4 bits) from usbus1
random: harvesting attach, 8 bytes (4 bits) from ehci0
hdac1: <Intel Lynx Point HDA Controller> mem 0xf7130000-0xf7133fff irq 22 a=
t device 27.0 on pci0
hdac1: PCI card vendor: 0x1028, device: 0x05cc
hdac1: HDA Driver Revision: 20120126_0002
hdac1: Config options: on=3D0x00000000 off=3D0x00000000
hdac1: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 268 to local APIC 0 vector 64
hdac1: using IRQ 268 for MSI
hdac1: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256
random: harvesting attach, 8 bytes (4 bits) from hdac1
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pcib2: domain 0
pcib2: secondary bus 2
pcib2: subordinate bus 2
pci2: <ACPI PCI bus> on pcib2
pcib2: allocated bus range (2-2) for rid 0 of pci2
pci2: domain=3D0, physical bus=3D2
random: harvesting attach, 8 bytes (4 bits) from pci2
random: harvesting attach, 8 bytes (4 bits) from pcib2
pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pcib0: allocated type 3 (0xf7000000-0xf70fffff) for rid 20 of pcib3
pcib3: domain 0
pcib3: secondary bus 3
pcib3: subordinate bus 3
pcib3: memory decode 0xf7000000-0xf70fffff
pci3: <ACPI PCI bus> on pcib3
pcib3: allocated bus range (3-3) for rid 0 of pci3
pci3: domain=3D0, physical bus=3D3
found-> vendor=3D0x8086, dev=3D0x4232, revid=3D0x00
domain=3D0, bus=3D3, slot=3D0, func=3D0
class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D10
powerspec 3 supports D0 D3 current D0
MSI supports 1 message, 64 bit
map[10]: type Memory, range 64, base 0xf7000000, size 13, enabled
pcib3: allocated memory range (0xf7000000-0xf7001fff) for rid 10 of pci0:3:=
0:0
pcib3: matched entry for 3.0.INTA
pcib3: slot 0 INTA hardwired to IRQ 18
iwn0: <Intel WiFi Link 5100> mem 0xf7000000-0xf7001fff irq 18 at device 0.0=
on pci3
iwn0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 269 to local APIC 0 vector 65
iwn0: using IRQ 269 for MSI
iwn0: MIMO 1T2R, MoW, address 00:24:d6:7a:03:ce
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp=
s 36Mbps 48Mbps 54Mbps
iwn0: 1T2R
iwn0: 11na MCS 20MHz
iwn0: MCS 0-7: 6.5Mbps - 65Mbps
iwn0: 11na MCS 20MHz SGI
iwn0: MCS 0-7: 7Mbps - 72Mbps
iwn0: 11na MCS 40MHz:
iwn0: MCS 0-7: 13.5Mbps - 135Mbps
iwn0: 11na MCS 40MHz SGI:
iwn0: MCS 0-7: 15Mbps - 150Mbps
iwn0: 11ng MCS 20MHz
iwn0: MCS 0-7: 6.5Mbps - 65Mbps
iwn0: 11ng MCS 20MHz SGI
iwn0: MCS 0-7: 7Mbps - 72Mbps
iwn0: 11ng MCS 40MHz:
iwn0: MCS 0-7: 13.5Mbps - 135Mbps
iwn0: 11ng MCS 40MHz SGI:
iwn0: MCS 0-7: 15Mbps - 150Mbps
random: harvesting attach, 8 bytes (4 bits) from iwn0
random: harvesting attach, 8 bytes (4 bits) from pci3
random: harvesting attach, 8 bytes (4 bits) from pcib3
pcib4: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib4
pcib0: allocated type 3 (0xf6500000-0xf6efffff) for rid 20 of pcib4
pcib0: allocated type 3 (0xf3500000-0xf3efffff) for rid 24 of pcib4
pcib4: domain 0
pcib4: secondary bus 4
pcib4: subordinate bus 7
pcib4: I/O decode 0xd000-0xdfff
pcib4: memory decode 0xf6500000-0xf6efffff
pcib4: prefetched decode 0xf3500000-0xf3efffff
pci4: <ACPI PCI bus> on pcib4
pcib4: allocated bus range (4-4) for rid 0 of pci4
pci4: domain=3D0, physical bus=3D4
random: harvesting attach, 8 bytes (4 bits) from pci4
random: harvesting attach, 8 bytes (4 bits) from pcib4
pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
pcib0: allocated type 4 (0xc000-0xcfff) for rid 1c of pcib5
pcib0: allocated type 3 (0xf5b00000-0xf64fffff) for rid 20 of pcib5
pcib0: allocated type 3 (0xf2b00000-0xf34fffff) for rid 24 of pcib5
pcib5: domain 0
pcib5: secondary bus 8
pcib5: subordinate bus 8
pcib5: I/O decode 0xc000-0xcfff
pcib5: memory decode 0xf5b00000-0xf64fffff
pcib5: prefetched decode 0xf2b00000-0xf34fffff
pci5: <ACPI PCI bus> on pcib5
pcib5: allocated bus range (8-8) for rid 0 of pci5
pci5: domain=3D0, physical bus=3D8
random: harvesting attach, 8 bytes (4 bits) from pci5
random: harvesting attach, 8 bytes (4 bits) from pcib5
pcib6: <ACPI PCI-PCI bridge> irq 18 at device 28.6 on pci0
pcib0: allocated type 4 (0xa000-0xbfff) for rid 1c of pcib6
pcib0: allocated type 3 (0xf5100000-0xf5afffff) for rid 20 of pcib6
pcib0: allocated type 3 (0xf2100000-0xf2afffff) for rid 24 of pcib6
pcib6: domain 0
pcib6: secondary bus 9
pcib6: subordinate bus 16
pcib6: I/O decode 0xa000-0xbfff
pcib6: memory decode 0xf5100000-0xf5afffff
pcib6: prefetched decode 0xf2100000-0xf2afffff
pci6: <ACPI PCI bus> on pcib6
pcib6: allocated bus range (9-9) for rid 0 of pci6
pci6: domain=3D0, physical bus=3D9
random: harvesting attach, 8 bytes (4 bits) from pci6
random: harvesting attach, 8 bytes (4 bits) from pcib6
pcib7: <ACPI PCI-PCI bridge> irq 19 at device 28.7 on pci0
pcib0: allocated type 3 (0xf6f00000-0xf6ffffff) for rid 20 of pcib7
pcib7: domain 0
pcib7: secondary bus 17
pcib7: subordinate bus 17
pcib7: memory decode 0xf6f00000-0xf6ffffff
pci7: <ACPI PCI bus> on pcib7
pcib7: allocated bus range (17-17) for rid 0 of pci7
pci7: domain=3D0, physical bus=3D17
found-> vendor=3D0x1217, dev=3D0x8520, revid=3D0x01
domain=3D0, bus=3D17, slot=3D0, func=3D0
class=3D08-05-01, hdrtype=3D0x00, mfdev=3D0
cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)
intpin=3Da, irq=3D5
powerspec 3 supports D0 D3 current D0
MSI supports 1 message, 64 bit, vector masks
map[10]: type Memory, range 32, base 0xf6f01000, size 12, enabled
pcib7: allocated memory range (0xf6f01000-0xf6f01fff) for rid 10 of pci0:17=
:0:0
map[14]: type Memory, range 32, base 0xf6f00000, size 11, enabled
pcib7: allocated memory range (0xf6f00000-0xf6f007ff) for rid 14 of pci0:17=
:0:0
pcib7: matched entry for 17.0.INTA
pcib7: slot 0 INTA hardwired to IRQ 19
sdhci_pci0: <Generic SD HCI> mem 0xf6f01000-0xf6f01fff,0xf6f00000-0xf6f007f=
f irq 19 at device 0.0 on pci7
sdhci_pci0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 270 to local APIC 0 vector 66
sdhci_pci0: using IRQ 270 for MSI
sdhci_pci0: Hardware doesn't specify timeout clock frequency, setting BROKE=
N_TIMEOUT quirk.
sdhci_pci0-slot0: 50MHz HS 1bit 3.3V 1.8V DMA
sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUMP =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00000603
sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000
sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci_pci0-slot0: Present: 0x00080000 | Host ctl: 0x00000000
sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000
sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000002
sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000
sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci_pci0-slot0: Caps: 0x25fe3280 | Max curr: 0x005800c8
sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
sdhci_pci0: 1 slot(s) allocated
random: harvesting attach, 8 bytes (4 bits) from sdhci_pci0
random: harvesting attach, 8 bytes (4 bits) from pci7
random: harvesting attach, 8 bytes (4 bits) from pcib7
ehci1: <Intel Lynx Point USB 2.0 controller USB-A> mem 0xf7137000-0xf71373f=
f irq 21 at device 29.0 on pci0
ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 67
usbus2: EHCI version 1.0
usbus2 on ehci1
ehci1: usbpf: Attached
random: harvesting attach, 8 bytes (4 bits) from usbus2
random: harvesting attach, 8 bytes (4 bits) from ehci1
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
random: harvesting attach, 8 bytes (4 bits) from isa0
random: harvesting attach, 8 bytes (4 bits) from isab0
ahci0: <Intel ICH8M AHCI SATA controller> port 0xf090-0xf097,0xf080-0xf083,=
0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xf7136000-0xf71367ff irq 19 =
at device 31.2 on pci0
ahci0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 271 to local APIC 0 vector 68
ahci0: using IRQ 271 for MSI
ahci0: AHCI v1.30 with 5 6Gbps ports, Port Multiplier not supported
ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM eSATA 5=
ports
ahci0: Caps2: APST
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich0: Caps:
random: harvesting attach, 8 bytes (4 bits) from ahcich0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich1: Caps: HPCP MPSP
random: harvesting attach, 8 bytes (4 bits) from ahcich1
ahcich2: <AHCI channel> at channel 2 on ahci0
ahcich2: Caps: ESP
random: harvesting attach, 8 bytes (4 bits) from ahcich2
ahcich3: <AHCI channel> at channel 3 on ahci0
ahcich3: Caps: ESP
random: harvesting attach, 8 bytes (4 bits) from ahcich3
ahcich4: not probed (disabled)
ahciem0: <AHCI enclosure management bridge> on ahci0
ahciem0: Caps: ALHD XMT SMB LED
random: harvesting attach, 8 bytes (4 bits) from ahciem0
random: harvesting attach, 8 bytes (4 bits) from ahci0
ichsmb0: <Intel Lynx Point SMBus controller> port 0xf000-0xf01f mem 0xf7135=
000-0xf71350ff irq 18 at device 31.3 on pci0
ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 69
smbus0: <System Management Bus> on ichsmb0
smb0: <SMBus generic I/O> on smbus0
random: harvesting attach, 8 bytes (4 bits) from smb0
random: harvesting attach, 8 bytes (4 bits) from smbus0
random: harvesting attach, 8 bytes (4 bits) from ichsmb0
random: harvesting attach, 8 bytes (4 bits) from pci0
random: harvesting attach, 8 bytes (4 bits) from pcib0
acpi_lid0: <Control Method Lid Switch> on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_lid0
acpi_button0: <Power Button> on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_button0
acpi_button1: <Sleep Button> on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_button1
acpi_acad0: <AC Adapter> on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_acad0
battery0: <ACPI Control Method Battery> on acpi0
random: harvesting attach, 8 bytes (4 bits) from battery0
battery1: <ACPI Control Method Battery> on acpi0
random: harvesting attach, 8 bytes (4 bits) from battery1
acpi_tz0: <Thermal Zone> on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_tz0
random: harvesting attach, 8 bytes (4 bits) from atdma0
random: harvesting attach, 8 bytes (4 bits) from fpupnp0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0065
atkbd: keyboard ID 0x41ab (2)
<7>kbdc: RESET_KBD return code:00fa
<7>kbdc: RESET_KBD status:00aa
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000
ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 70
atkbd0: [GIANT-LOCKED]
random: harvesting attach, 8 bytes (4 bits) from atkbd0
psm0: unable to allocate IRQ
random: harvesting attach, 8 bytes (4 bits) from atkbdc0
psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0065
<7>kbdc: TEST_AUX_PORT status:0000
<7>kbdc: RESET_AUX return code:00fa
<7>kbdc: RESET_AUX status:00aa
<7>kbdc: RESET_AUX ID:0000
<7>kbdc: RESET_AUX return code:00fa
<7>kbdc: RESET_AUX status:00aa
<7>kbdc: RESET_AUX ID:0000
<7>psm: status 00 02 64
<7>psm: status 00 00 64
<7>psm: status 00 03 64
<7>psm: status 00 03 64
<7>psm: data 08 00 00
<7>psm: status 00 00 14
<7>psm: status 73 03 0a
<7>psm: status 00 02 64
psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 71
psm0: [GIANT-LOCKED]
psm0: model GlidePoint, device ID 0-00, 2 buttons
psm0: config:00004000, flags:00000008, packet size:3
psm0: syncmask:c0, syncbits:00
random: harvesting attach, 8 bytes (4 bits) from psm0
random: harvesting attach, 8 bytes (4 bits) from psmcpnp0
ppc1: using extended I/O port range
ACPI: Enabled 2 GPEs in block 00 to 3F
random: harvesting attach, 8 bytes (4 bits) from acpi0
random: harvesting attach, 8 bytes (4 bits) from apic0
acpi0: wakeup code va 0xfffffe060bb12000 pa 0x88000
random: harvesting attach, 8 bytes (4 bits) from nexus0
ahc_isa_identify 0: ioport 0xc00 alloc failed
ahc_isa_identify 1: ioport 0x1c00 alloc failed
ahc_isa_identify 2: ioport 0x2c00 alloc failed
ahc_isa_identify 3: ioport 0x3c00 alloc failed
ahc_isa_identify 4: ioport 0x4c00 alloc failed
ahc_isa_identify 5: ioport 0x5c00 alloc failed
ahc_isa_identify 6: ioport 0x6c00 alloc failed
ahc_isa_identify 7: ioport 0x7c00 alloc failed
ahc_isa_identify 8: ioport 0x8c00 alloc failed
ahc_isa_identify 9: ioport 0x9c00 alloc failed
ahc_isa_identify 10: ioport 0xac00 alloc failed
ahc_isa_identify 11: ioport 0xbc00 alloc failed
ahc_isa_identify 12: ioport 0xcc00 alloc failed
ahc_isa_identify 13: ioport 0xdc00 alloc failed
ahc_isa_identify 14: ioport 0xec00 alloc failed
pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0
pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0
pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0
pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0
pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0
pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0
pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0
pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0
pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 0 of orm0
pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xdd800-0xddfff) for rid 0 of orm0
pcib0: allocated type 3 (0xde000-0xde7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xde800-0xdefff) for rid 0 of orm0
pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 0 of orm0
pcib0: allocated type 3 (0xdf800-0xdffff) for rid 0 of orm0
pcib0: allocated type 3 (0xe0000-0xe07ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe0800-0xe0fff) for rid 0 of orm0
pcib0: allocated type 3 (0xe1000-0xe17ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe1800-0xe1fff) for rid 0 of orm0
pcib0: allocated type 3 (0xe2000-0xe27ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe2800-0xe2fff) for rid 0 of orm0
pcib0: allocated type 3 (0xe3000-0xe37ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe3800-0xe3fff) for rid 0 of orm0
pcib0: allocated type 3 (0xe4000-0xe47ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe4800-0xe4fff) for rid 0 of orm0
pcib0: allocated type 3 (0xe5000-0xe57ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe5800-0xe5fff) for rid 0 of orm0
pcib0: allocated type 3 (0xe6000-0xe67ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe6800-0xe6fff) for rid 0 of orm0
pcib0: allocated type 3 (0xe7000-0xe77ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe7800-0xe7fff) for rid 0 of orm0
isa_probe_children: disabling PnP devices
atkbdc: atkbdc0 already exists; skipping it
atrtc: atrtc0 already exists; skipping it
attimer: attimer0 already exists; skipping it
sc: sc0 already exists; skipping it
isa_probe_children: probing non-PnP devices
sc0 failed to probe on isa0
vga0 failed to probe on isa0
pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0
pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0
fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
ppc0: cannot reserve I/O port range
ppc0 failed to probe at irq 7 on isa0
pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0
uart0 failed to probe at port 0x3f8 irq 4 on isa0
pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 of uart1
uart1 failed to probe at port 0x2f8 irq 3 on isa0
wbwd0 failed to probe on isa0
isa_probe_children: probing PnP devices
random: harvesting attach, 8 bytes (4 bits) from acpi_perf0
random: harvesting attach, 8 bytes (4 bits) from acpi_perf1
random: harvesting attach, 8 bytes (4 bits) from acpi_perf2
random: harvesting attach, 8 bytes (4 bits) from acpi_perf3
random: harvesting attach, 8 bytes (4 bits) from acpi_perf4
random: harvesting attach, 8 bytes (4 bits) from acpi_perf5
random: harvesting attach, 8 bytes (4 bits) from acpi_perf6
random: harvesting attach, 8 bytes (4 bits) from acpi_perf7
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
coretemp0: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
random: harvesting attach, 8 bytes (4 bits) from cpufreq0
random: harvesting attach, 8 bytes (4 bits) from est0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
coretemp1: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp1
est1: <Enhanced SpeedStep Frequency Control> on cpu1
random: harvesting attach, 8 bytes (4 bits) from cpufreq1
random: harvesting attach, 8 bytes (4 bits) from est1
coretemp2: <CPU On-Die Thermal Sensors> on cpu2
coretemp2: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp2
est2: <Enhanced SpeedStep Frequency Control> on cpu2
random: harvesting attach, 8 bytes (4 bits) from cpufreq2
random: harvesting attach, 8 bytes (4 bits) from est2
coretemp3: <CPU On-Die Thermal Sensors> on cpu3
coretemp3: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp3
est3: <Enhanced SpeedStep Frequency Control> on cpu3
random: harvesting attach, 8 bytes (4 bits) from cpufreq3
random: harvesting attach, 8 bytes (4 bits) from est3
coretemp4: <CPU On-Die Thermal Sensors> on cpu4
coretemp4: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp4
est4: <Enhanced SpeedStep Frequency Control> on cpu4
random: harvesting attach, 8 bytes (4 bits) from cpufreq4
random: harvesting attach, 8 bytes (4 bits) from est4
coretemp5: <CPU On-Die Thermal Sensors> on cpu5
coretemp5: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp5
est5: <Enhanced SpeedStep Frequency Control> on cpu5
random: harvesting attach, 8 bytes (4 bits) from cpufreq5
random: harvesting attach, 8 bytes (4 bits) from est5
coretemp6: <CPU On-Die Thermal Sensors> on cpu6
coretemp6: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp6
est6: <Enhanced SpeedStep Frequency Control> on cpu6
random: harvesting attach, 8 bytes (4 bits) from cpufreq6
random: harvesting attach, 8 bytes (4 bits) from est6
coretemp7: <CPU On-Die Thermal Sensors> on cpu7
coretemp7: Setting TjMax=3D100
random: harvesting attach, 8 bytes (4 bits) from coretemp7
est7: <Enhanced SpeedStep Frequency Control> on cpu7
random: harvesting attach, 8 bytes (4 bits) from cpufreq7
random: harvesting attach, 8 bytes (4 bits) from est7
Device configuration finished.
procfs registered
lapic: Divisor 2, Frequency 49885587 Hz
Timecounters tick every 1.000 msec
vlan: initialized, using hash tables with chaining
Linux ELF exec handler installed
tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536
IPsec: Initialized Security Association Processing.
ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to deny, l=
ogging disabled
DUMMYNET 0 with IPv6 initialized (100409)
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched WF2Q+ loaded
lo0: bpf attached
load_dn_sched dn_sched FIFO loaded
load_dn_sched dn_sched PRIO loaded
hptrr: no controller detected.
hptnr: no controller detected.
hdacc0: <NVIDIA (0x0042) HDA CODEC> at cad 0 on hdac0
hdaa0: <NVIDIA (0x0042) Audio Function Group> at nid 1 on hdacc0
hdaa0: Subsystem ID: 0x102805cc
hdaa0: NumGPIO=3D0 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D0
hdaa0: Original pins configuration:
hdaa0: nid 0x as seq device conn jack loc color misc
hdaa0: 4 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0
hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0
hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
hdaa0: Patched pins configuration:
hdaa0: nid 0x as seq device conn jack loc color misc
hdaa0: 4 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0 D=
ISA
hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0 D=
ISA
hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
hdaa0: 2 associations found:
hdaa0: Association 0 (15) out:
hdaa0: Pin nid=3D5 seq=3D0
hdaa0: Association 1 (15) out:
hdaa0: Pin nid=3D7 seq=3D0
hdaa0: Tracing association 0 (15)
hdaa0: Pin 5 traced to DAC 8
hdaa0: Association 0 (15) trace succeeded
hdaa0: Tracing association 1 (15)
hdaa0: Pin 7 traced to DAC 9
hdaa0: Association 1 (15) trace succeeded
hdaa0: Looking for additional DAC for association 0 (15)
hdaa0: Looking for additional DAC for association 1 (15)
hdaa0: Tracing input monitor
hdaa0: Tracing other input monitors
hdaa0: Tracing beeper
hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref
pcm0: <NVIDIA (0x0042) (HDMI/DP 8ch)> at nid 5 on hdaa0
pcm0: Playback:
pcm0: Stream cap: 0x00000005 AC3 PCM
pcm0: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 KHz
pcm0: DAC: 8
pcm0:=20
pcm0: nid=3D5 [pin: Digital-out (Jack)]
pcm0: + <- nid=3D8 [audio output] [src: pcm]
pcm0:=20
pcm0: Mixer "vol" -> "none": child=3D0x00000010
pcm0: Mixer "pcm": parent=3D"vol"
pcm0: Soft PCM mixer ENABLED
pcm0: Playback channel matrix is: unknown, assuming 7.1 (disconnected)
random: harvesting attach, 8 bytes (4 bits) from pcm0
pcm1: <NVIDIA (0x0042) (HDMI/DP 8ch)> at nid 7 on hdaa0
pcm1: Playback:
pcm1: Stream cap: 0x00000005 AC3 PCM
pcm1: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 KHz
pcm1: DAC: 9
pcm1:=20
pcm1: nid=3D7 [pin: Digital-out (Jack)]
pcm1: + <- nid=3D9 [audio output] [src: pcm]
pcm1:=20
pcm1: Mixer "vol" -> "none": child=3D0x00000010
pcm1: Mixer "pcm": parent=3D"vol"
pcm1: Soft PCM mixer ENABLED
pcm1: Playback channel matrix is: unknown, assuming 7.1 (disconnected)
random: harvesting attach, 8 bytes (4 bits) from pcm1
random: harvesting attach, 8 bytes (4 bits) from hdaa0
random: harvesting attach, 8 bytes (4 bits) from hdacc0
hdacc1: <Realtek ALC292 HDA CODEC> at cad 0 on hdac1
hdaa1: <Realtek ALC292 Audio Function Group> at nid 1 on hdacc1
hdaa1: Subsystem ID: 0x102805cc
hdaa1: NumGPIO=3D5 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D1
hdaa1: GPIO0: disabled
hdaa1: GPIO1: disabled
hdaa1: GPIO2: disabled
hdaa1: GPIO3: disabled
hdaa1: GPIO4: disabled
hdaa1: Original pins configuration:
hdaa1: nid 0x as seq device conn jack loc color misc
hdaa1: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1
hdaa1: 19 411111f0 15 0 Speaker None 1/8 Rear Black 1
hdaa1: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1
hdaa1: 21 0221401f 1 15 Headphones Jack 1/8 Front Green 0
hdaa1: 22 01014020 2 0 Line-out Jack 1/8 Rear Green 0
hdaa1: 24 02a19031 3 1 Mic Jack 1/8 Front Pink 0
hdaa1: 25 01a1903e 3 14 Mic Jack 1/8 Rear Pink 0
hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1
hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1
hdaa1: 29 40700001 0 1 Modem-handset None Unknown 0x00 Unknown 0
hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1
hdaa1: Patching widget caps nid=3D29 0x00400400 -> 0x00700400
hdaa1: Patched pins configuration:
hdaa1: nid 0x as seq device conn jack loc color misc
hdaa1: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1
hdaa1: 19 411111f0 15 0 Speaker None 1/8 Rear Black 1 D=
ISA
hdaa1: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1
hdaa1: 21 0221401f 1 15 Headphones Jack 1/8 Front Green 0
hdaa1: 22 01014020 2 0 Line-out Jack 1/8 Rear Green 0
hdaa1: 24 02a19031 3 1 Mic Jack 1/8 Front Pink 0
hdaa1: 25 01a1903e 3 14 Mic Jack 1/8 Rear Pink 0
hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 D=
ISA
hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 D=
ISA
hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 D=
ISA
hdaa1: 4 associations found:
hdaa1: Association 0 (1) out:
hdaa1: Pin nid=3D20 seq=3D0
hdaa1: Pin nid=3D21 seq=3D15
hdaa1: Association 1 (2) out:
hdaa1: Pin nid=3D22 seq=3D0
hdaa1: Association 2 (3) in:
hdaa1: Pin nid=3D24 seq=3D1
hdaa1: Pin nid=3D25 seq=3D14
hdaa1: Association 3 (4) in:
hdaa1: Pin nid=3D18 seq=3D0
hdaa1: Tracing association 0 (1)
hdaa1: Pin 20 traced to DAC 2
hdaa1: Pin 21 traced to DAC 2 and hpredir 0
hdaa1: Association 0 (1) trace succeeded
hdaa1: Tracing association 1 (2)
hdaa1: Pin 22 traced to DAC 3
hdaa1: Association 1 (2) trace succeeded
hdaa1: Tracing association 2 (3)
hdaa1: Pin 24 traced to ADC 8
hdaa1: Pin 25 traced to ADC 8
hdaa1: Association 2 (3) trace succeeded
hdaa1: Tracing association 3 (4)
hdaa1: Pin 18 traced to ADC 9
hdaa1: Association 3 (4) trace succeeded
hdaa1: Looking for additional DAC for association 0 (1)
hdaa1: Looking for additional DAC for association 1 (2)
hdaa1: Looking for additional ADC for association 2 (3)
hdaa1: Looking for additional ADC for association 3 (4)
hdaa1: Tracing input monitor
hdaa1: Tracing nid 11 to out
hdaa1: nid 11 is input monitor
hdaa1: Tracing other input monitors
hdaa1: Tracing nid 18 to out
hdaa1: Tracing nid 24 to out
hdaa1: Tracing nid 25 to out
hdaa1: Tracing beeper
hdaa1: Headphones redirection for association 0 nid=3D21 using unsolicited =
responses.
hdaa1: Redirect output to: main
hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref
pcm2: <Realtek ALC292 (Analog 2.0+HP/2.0)> at nid 20,21 and 24,25 on hdaa1
pcm2: Playback:
pcm2: Stream cap: 0x00000001 PCM
pcm2: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
pcm2: DAC: 2
pcm2:=20
pcm2: nid=3D20 [pin: Speaker (Fixed)]
pcm2: + <- nid=3D12 [audio mixer] [src: pcm, mix]
pcm2: + <- nid=3D2 [audio output] [src: pcm]
pcm2: + <- nid=3D11 [audio mixer] [src: mix]
pcm2:=20
pcm2: nid=3D21 [pin: Headphones (Green Jack)]
pcm2: + <- nid=3D12 [audio mixer] [src: pcm, mix]
pcm2: + <- nid=3D2 [audio output] [src: pcm]
pcm2: + <- nid=3D11 [audio mixer] [src: mix]
pcm2:=20
pcm2: Record:
pcm2: Stream cap: 0x00000001 PCM
pcm2: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
pcm2: ADC: 8
pcm2:=20
pcm2: nid=3D8 [audio input]
pcm2: + <- nid=3D35 [audio selector] [src: speaker, line, mic, mix]
pcm2: + <- nid=3D24 [pin: Mic (Pink Jack)] [src: mic]
pcm2: + <- nid=3D25 [pin: Mic (Pink Jack)] [src: line]
pcm2: + <- nid=3D29 [beep widget] [src: speaker]
pcm2: + <- nid=3D11 [audio mixer] [src: mix]
pcm2:=20
pcm2: Input Mix:
pcm2:=20
pcm2: nid=3D11 [audio mixer]
pcm2: + <- nid=3D24 [pin: Mic (Pink Jack)] [src: mic]
pcm2: + <- nid=3D25 [pin: Mic (Pink Jack)] [src: line]
pcm2: + <- nid=3D29 [beep widget] [src: speaker]
pcm2:=20
pcm2: Master Volume (OSS: vol): -65/0dB
pcm2: +- ctl 1 (nid 2 out): -65/0dB (88 steps)
pcm2: +- ctl 10 (nid 12 in 0): mute
pcm2: +- ctl 11 (nid 12 in 1): mute
pcm2: +- ctl 18 (nid 20 in ): mute
pcm2: +- ctl 19 (nid 21 in ): mute
pcm2:=20
pcm2: PCM Volume (OSS: pcm): -65/0dB
pcm2: +- ctl 1 (nid 2 out): -65/0dB (88 steps)
pcm2: +- ctl 10 (nid 12 in 0): mute
pcm2:=20
pcm2: Microphone Volume (OSS: mic): 0/30dB
pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
pcm2: +- ctl 5 (nid 11 in 0): -34/12dB (32 steps) + mute
pcm2: +- ctl 22 (nid 24 out): 0/30dB (4 steps)
pcm2:=20
pcm2: Line-in Volume (OSS: line): 0/36dB
pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
pcm2: +- ctl 6 (nid 11 in 1): -34/12dB (32 steps) + mute
pcm2: +- ctl 23 (nid 25 out): 0/36dB (4 steps)
pcm2:=20
pcm2: Speaker/Beep Volume (OSS: speaker): -17/12dB
pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
pcm2: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute
pcm2:=20
pcm2: Recording Level (OSS: rec): -17/30dB
pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
pcm2:=20
pcm2: Input Mix Level (OSS: mix): -17/30dB
pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
pcm2: +- ctl 11 (nid 12 in 1): mute
pcm2:=20
pcm2: Input Monitoring Level (OSS: igain): 0/0dB
pcm2: +- ctl 11 (nid 12 in 1): mute
pcm2:=20
pcm2: Mixer "vol":
pcm2: Mixer "pcm":
pcm2: Mixer "speaker":
pcm2: Mixer "line":
pcm2: Mixer "mic":
pcm2: Mixer "mix":
pcm2: Mixer "rec":
pcm2: Mixer "igain":
pcm2: Mixer "ogain":
pcm2: Playback channel set is: Front Left, Front Right,=20
pcm2: Playback channel matrix is: 2.0 (unknown)
pcm2: Recording channel set is: Front Left, Front Right,=20
pcm2: Recording channel matrix is: 2.0 (disconnected)
random: harvesting attach, 8 bytes (4 bits) from pcm2
pcm3: <Realtek ALC292 (Analog)> at nid 22 and 18 on hdaa1
pcm3: Playback:
pcm3: Stream cap: 0x00000001 PCM
pcm3: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
pcm3: DAC: 3
pcm3:=20
pcm3: nid=3D22 [pin: Line-out (Green Jack)]
pcm3: + <- nid=3D13 [audio mixer] [src: pcm, mix]
pcm3: + <- nid=3D3 [audio output] [src: pcm]
pcm3: + <- nid=3D11 [audio mixer] [src: mix]
pcm3:=20
pcm3: Record:
pcm3: Stream cap: 0x00000001 PCM
pcm3: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
pcm3: ADC: 9
pcm3:=20
pcm3: nid=3D9 [audio input]
pcm3: + <- nid=3D34 [audio selector] [src: speaker, monitor]
pcm3: + <- nid=3D29 [beep widget] [src: speaker]
pcm3: + <- nid=3D18 [pin: Mic (Fixed)] [src: monitor]
pcm3:=20
pcm3: Master Volume (OSS: vol): -65/0dB
pcm3: +- ctl 2 (nid 3 out): -65/0dB (88 steps)
pcm3: +- ctl 12 (nid 13 in 0): mute
pcm3: +- ctl 13 (nid 13 in 1): mute
pcm3: +- ctl 20 (nid 22 in ): mute
pcm3:=20
pcm3: PCM Volume (OSS: pcm): -65/0dB
pcm3: +- ctl 2 (nid 3 out): -65/0dB (88 steps)
pcm3: +- ctl 12 (nid 13 in 0): mute
pcm3:=20
pcm3: Microphone2 Volume (OSS: monitor): 0/36dB
pcm3: +- ctl 4 (nid 9 in 0): -17/30dB (64 steps) + mute
pcm3: +- ctl 16 (nid 18 out): 0/36dB (4 steps)
pcm3:=20
pcm3: Speaker/Beep Volume (OSS: speaker)
pcm3: +- ctl 4 (nid 9 in 0): -17/30dB (64 steps) + mute
pcm3:=20
pcm3: Recording Level (OSS: rec): -17/30dB
pcm3: +- ctl 4 (nid 9 in 0): -17/30dB (64 steps) + mute
pcm3: +- ctl 16 (nid 18 out): 0/36dB (4 steps)
pcm3:=20
pcm3: Input Mix Level (OSS: mix)
pcm3: +- ctl 13 (nid 13 in 1): mute
pcm3:=20
pcm3: Input Monitoring Level (OSS: igain): 0/0dB
pcm3: +- ctl 13 (nid 13 in 1): mute
pcm3:=20
pcm3: Mixer "vol":
pcm3: Mixer "pcm":
pcm3: Mixer "rec":
pcm3: Mixer "igain":
pcm3: Mixer "ogain":
pcm3: Mixer "monitor":
pcm3: Playback channel set is: Front Left, Front Right,=20
pcm3: Playback channel matrix is: 2.0 (disconnected)
pcm3: Automatically set rec source to: monitor
pcm3: Recording channel set is: Front Left, Front Right,=20
pcm3: Recording channel matrix is: 2.0 (unknown)
random: harvesting attach, 8 bytes (4 bits) from pcm3
random: harvesting attach, 8 bytes (4 bits) from hdaa1
random: harvesting attach, 8 bytes (4 bits) from hdacc1
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 480Mbps High Speed USB v2.0
usbus2: 480Mbps High Speed USB v2.0
ugen0.1: <0x8086> at usbus0
ugen1.1: <Intel> at usbus1
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
ugen2.1: <Intel> at usbus2
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
ahcich0: AHCI reset...
ahcich0: SATA connect time=3D900us status=3D00000123
ahcich0: AHCI reset: device found
ahcich0: AHCI reset: device ready after 0ms
ahcich1: AHCI reset...
ahcich1: SATA connect time=3D1000us status=3D00000113
ahcich1: AHCI reset: device found
ahcich1: AHCI reset: device ready after 0ms
ahcich2: AHCI reset...
ahcich2: SATA connect timeout time=3D10000us status=3D00000000
ahcich2: AHCI reset: device not found
ahcich3: AHCI reset...
ahcich3: SATA connect timeout time=3D10000us status=3D00000000
ahcich3: AHCI reset: device not found
acpi_acad0: acline initialization start
battery0: battery initialization start
battery1: battery initialization start
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
GEOM: new disk ada0
ada0: <ST750LX003-1AC154 HPM1> ATA8-ACS SATA 2.x device
ada0: Serial Number W200TLZD
ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4
pass0 at ahcich0 bus 0 scbus0 target 0 lun 0
pass0: <ST750LX003-1AC154 HPM1> ATA8-ACS SATA 2.x device
pass0: Serial Number W200TLZD
pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
pass0: Command Queueing enabled
pass1 at ahcich1 bus 0 scbus1 target 0 lun 0
pass1: <HL-DT-ST DVD+-RW GS40N A100> Removable CD-ROM SCSI device
pass1: Serial Number K0121171240
pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
pass2 at ahciem0 bus 0 scbus4 target 0 lun 0
pass2: acpi_acad0: On Line
<AHCI SGPIO Enclosure 1.00 0001> SEMB S-E-S 2.00 device
acpi_acad0: GEOM_PART: partition 1 on (ada0, MBR) is not aligned on 4096 by=
tes
GEOM_PART: partition 2 on (ada0, MBR) is not aligned on 4096 bytes
GEOM_PART: partition 3 on (ada0, MBR) is not aligned on 4096 bytes
acline initialization done, tried 1 times
ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
ses0: <AHCI SGPIO Enclosure 1.00 0001> SEMB S-E-S 2.00 device
ses0: SEMB SES Device
ses0: Generation Code 0x0 has 1 SubEnclosures
ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offse=
t 8
ses0: WWN: 0
ses0: Type Desc[0]: Type 0x17, MaxElt 5, In Subenc 0, Text Length 0:=20
Netvsc initializing... done!
lapic7: CMCI unmasked
lapic6: CMCI unmasked
lapic3: CMCI unmasked
lapic2: CMCI unmasked
lapic4: CMCI unmasked
lapic5: CMCI unmasked
SMP: AP CPU #1 Launched!
cpu1 AP:
ID: 0x00000001 VER: 0x01060015 LDR: 0x00000002 DFR: 0x00000000 x2API=
C: 1
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
cmci: 0x000100f2
SMP: AP CPU #4 Launched!
cpu4 AP:
ID: 0x00000004 VER: 0x01060015 LDR: 0x00000010 DFR: 0x00000000 x2API=
C: 1
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
cmci: 0x000000f2
SMP: AP CPU #7 Launched!
cpu7 AP:
ID: 0x00000007 VER: 0x01060015 LDR: 0x00000080 DFR: 0x00000000 x2API=
C: 1
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
cmci: 0x000000f2
SMP: AP CPU #5 Launched!
cpu5 AP:
ID: 0x00000005 VER: 0x01060015 LDR: 0x00000020 DFR: 0x00000000 x2API=
C: 1
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
cmci: 0x000000f2
SMP: AP CPU #3 Launched!
cpu3 AP:
ID: 0x00000003 VER: 0x01060015 LDR: 0x00000008 DFR: 0x00000000 x2API=
C: 1
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
cmci: 0x000000f2
SMP: AP CPU #6 Launched!
cpu6 AP:
ID: 0x00000006 VER: 0x01060015 LDR: 0x00000040 DFR: 0x00000000 x2API=
C: 1
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
cmci: 0x000000f2
SMP: AP CPU #2 Launched!
cpu2 AP:
ID: 0x00000002 VER: 0x01060015 LDR: 0x00000004 DFR: 0x00000000 x2API=
C: 1
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
cmci: 0x000000f2
ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 2 vector 48
ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 4 vector 48
ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 48
ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 49
ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 4 vector 49
msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 48
Sleeping on "acmtx" with the following non-sleepable locks held:
exclusive sleep mutex intr sources (intr sources) r =3D 0 (0xffffffff81b673=
c0) locked @ /usr/src/sys/x86/x86/intr_machdep.c:540
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0x2=
b/frame 0xffffffff82c126f0
witness_warn() at 0xffffffff80a4489f =3D witness_warn+0x4af/frame 0xfffffff=
f82c127c0
_sleep() at cd0 at ahcich1 bus 0 scbus1 target 0 lun 0
cd0: <HL-DT-ST DVD+-RW GS40N A100> Removable CD-ROM SCSI device
0xcd0: Serial Number K0121171240
ffffffff809cd0: 150.000MB/s transfersf (1SATA 1.x, efUDMA5, dATAPI 12bytes,=
PIO 8192bytes=3D)=20
_cd0: cd present [1 x 0 byte records]
sleep+0x6d/frame 0xffffffff82c12860
AcpiOsAcquireMutex() at 0xffffffff8038b97f =3D AcpiOsAcquireMutex+0x17f/fra=
me 0xffffffff82c128c0
AcpiUtAcquireMutex() at 0xffffffff803639ca =3D AcpiUtAcquireMutex+0x3a/fram=
e 0xffffffff82c128f0
AcpiExEnterInterpreter() at 0xffffffff803517bb =3D AcpiExEnterInterpreter+0=
xb/frame 0xffffffff82c12900
AcpiEvaluateObject() at 0xffffffff803588ad =3D AcpiEvaluateObject+0x24d/fra=
me 0xffffffff82c12960
acpi_GetInteger() at 0xffffffff8038c4bd =3D acpi_GetInteger+0x3d/frame 0xff=
ffffff82c129c0
dmar_find_hpet() at 0xffffffff80ecb3e1 =3D dmar_find_hpet+0x81/frame 0xffff=
ffff82c12a00
iommu_map_msi_intr() at 0xffffffff80ed3d1d =3D iommu_map_msi_intr+0x2d/fram=
e 0xffffffff82c12a50
msi_map() at 0xffffffff80ee9241 =3D msi_map+0x171/frame 0xffffffff82c12a90
hpet_remap_intr() at 0xffffffff80dc0095 =3D hpet_remap_intr+0xb5/frame 0xff=
ffffff82c12ae0
msi_assign_cpu() at 0xffffffff80ee88f0 =3D msi_assign_cpu+0x1c0/frame 0xfff=
fffff82c12b30
intr_shuffle_irqs() at 0xffffffff80edfb83 =3D intr_shuffle_irqs+0x73/frame =
0xffffffff82c12b50
mi_startup() at 0xffffffff8098a918 =3D mi_startup+0x118/frame 0xffffffff82c=
12b70
btext() at 0xffffffff802f902c =3D btext+0x2c
lock order reversal: (Giant after non-sleepable)
1st 0xffffffff81b673c0 intr sources (intr sources) @ /usr/src/sys/x86/x86/=
intr_machdep.c:540
2nd 0xffffffff81bbcb10 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:244
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0x2=
b/frame 0xffffffff82c126f0
witness_checkorder() at 0xffffffff80a434ca =3D witness_checkorder+0xe7a/fra=
me 0xffffffff82c12770
__mtx_lock_flags() at 0xffffffff809ccc48 =3D __mtx_lock_flags+0xa8/frame 0x=
ffffffff82c127c0
_sleep() at 0xffffffff809f226a =3D _sleep+0x3da/frame 0xffffffff82c12860
AcpiOsAcquireMutex() at 0xffffffff8038b97f =3D AcpiOsAcquireMutex+0x17f/fra=
me 0xffffffff82c128c0
AcpiUtAcquireMutex() at 0xffffffff803639ca =3D AcpiUtAcquireMutex+0x3a/fram=
e 0xffffffff82c128f0
AcpiExEnterInterpreter() at 0xffffffff803517bb =3D AcpiExEnterInterpreter+0=
xb/frame 0xffffffff82c12900
AcpiEvaluateObject() at 0xffffffff803588ad =3D AcpiEvaluateObject+0x24d/fra=
me 0xffffffff82c12960
acpi_GetInteger() at 0xffffffff8038c4bd =3D acpi_GetInteger+0x3d/frame 0xff=
ffffff8
2c129c0
dmar_find_hpet() at 0xffffffff80ecb3e1 =3D dmar_find_hpet+0x81/frame 0xffff=
ffff82c12a00
iommu_map_msi_intr() at 0xffffffff80ed3d1d =3D iommu_map_msi_intr+0x2d/fram=
e 0xffffffff82c12a50
msi_map() at 0xffffffff80ee9241 =3D msi_map+0x171/frame 0xffffffff82c12a90
GEOM: new disk cd0
hpet_remap_intr() at 0xffffffff80dc0095 =3D hpet_remap_intr+0xb5/frame 0xff=
ffffff82c12ae0
msi_assign_cpu() at 0xffffffff80ee88f0 =3D msi_assign_cpu+0x1c0/frame 0xfff=
fffff82c12b30
intr_shuffle_irqs() at 0xffffffff80edfb83 =3D intr_shuffle_irqs+0x73/frame =
0xffffffff82c12b50
mi_startup() at 0xffffffff8098a918 =3D mi_startup+0x118/frame 0xffffffff82c=
12b70
btext() at 0xffffffff802f902c =3D btext+0x2c
GEOM_PART: partition 1 on (diskid/DISK-W200TLZD, MBR) is not aligned on 409=
6 bytes
GEOM_PART: partition 2 on (diskid/DISK-W200TLZD, MBR) is not aligned on 409=
6 bytes
GEOM_PART: partition 3 on (diskid/DISK-W200TLZD, MBR) is not aligned on 409=
6 bytes
Expensive timeout(9) function: 0xffffffff80883770(0xffffffff817648c8) 0.004=
70876
8 s
msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50
Sleeping on "acmtx" with the following non-sleepable locks held:
exclusive sleep mutex intr sources (intr sources) r =3D 0 (0xffffffff81b673=
c0) locked @ /usr/src/sys/x86/x86/intr_machdep.c:540
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0x2=
b/frame 0xffffffff82c126b0
witness_warn() at 0xffffffff80a4489f =3D witness_warn+0x4af/frame 0xfffffff=
f82c12780
_sleep() at 0xffffffff809f1efd =3D _sleep+0x6d/frame 0xffffffff82c12820
AcpiOsAcquireMutex() at 0xffffffff8038b97f =3D AcpiOsAcquireMutex+0x17f/fra=
me 0xffffffff82c12880
AcpiUtAcquireMutex() at 0xffffffff803639ca =3D AcpiUtAcquireMutex+0x3a/fram=
e 0xffffffff82c128b0
AcpiExEnterInterpreter() at 0xffffffff803517bb =3D AcpiExEnterInterpreter+0=
xb/frame 0xffffffff82c128c0
AcpiNsEvaluate() at 0xffffffff8035539b =3D AcpiNsEvaluate+0x1cb/frame 0xfff=
fffff82c12900
AcpiEvaluateObject() at 0xffffffff803587ca =3D AcpiEvaluateObject+0x16a/fra=
me 0xffffffff82c12960
acpi_GetInteger() at 0xffffffff8038c4bd =3D acpi_GetInteger+0x3d/frame 0xff=
ffffff8
2c129c0
dmar_find_hpet() at 0xffffffff80ecb3e1 =3D dmar_find_hpet+0x81/frame 0xffff=
ffff82c12a00
iommu_map_msi_intr() at 0xffffffff80ed3d1d =3D iommu_map_msi_intr+0x2d/fram=
e 0xffffffff82c12a50
msi_map() at 0xffffffff80ee9241 =3D msi_map+0x171/frame 0xffffffff82c12a90
hpet_remap_intr() at 0xffffffff80dc0095 =3D hpet_remap_intr+0xb5/frame 0xff=
ffffff82c12ae0
msi_assign_cpu() at 0xffffffff80ee88f0 =3D msi_assign_cpu+0x1c0/frame 0xfff=
fffff82c12b30
intr_shuffle_irqs() at 0xffffffff80edfb83 =3D intr_shuffle_irqs+0x73/frame =
0xffffffff82c12b50
mi_startup() at 0xffffffff8098a918 =3D mi_startup+0x118/frame 0xffffffff82c=
12b70
btext() at 0xffffffff802f902c =3D btext+0x2c
msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 48
msi: Assigning MSI-X IRQ 260 to local APIC 4 vector 50
msi: Assigning MSI-X IRQ 261 to local APIC 5 vector 48
msi: Assigning MSI-X IRQ 262 to local APIC 6 vector 49
msi: Assigning MSI-X IRQ 263 to local APIC 7 vector 48
msi: Assigning MSI IRQ 264 to local APIC 6 vector 50
msi: Assigning MSI IRQ 266 to local APIC 2 vector 51
msi: Assigning MSI IRQ 267 to local APIC 4 vector 51
msi: Assigning MSI IRQ 268 to local APIC 6 vector 51
msi: Assigning MSI IRQ 270 to local APIC 2 vector 52
msi: Assigning MSI IRQ 271 to local APIC 4 vector 52
SMP: passed TSC synchronization test
TSC timecounter discards lower 1 bit(s)
Timecounter "TSC-low" frequency 1396796100 Hz quality 1000
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
battery0: battery initialization done, tried 1 times
Root mount waiting for: usbus2 usbus1 usbus0
uhub1: 2 ports with 2 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub1
uhub2: 2 ports with 2 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub2
uhub0: 21 ports with 21 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub0
ugen2.2: <vendor 0x8087> at usbus2
uhub3: <vendor 0x8087 product 0x8000, class 9/0, rev 2.00/0.04, addr 2> on =
usbus2
ugen1.2: <vendor 0x8087> at usbus1
uhub4: <vendor 0x8087 product 0x8008, class 9/0, rev 2.00/0.04, addr 2> on =
usbus1
Root mount waiting for: usbus2 usbus1
uhub4: 6 ports with 6 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub4
uhub3: 8 ports with 8 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub3
ugen2.3: <Broadcom Corp> at usbus2
ugen1.3: <CN0767N972487515BSJWA01> at usbus1
Trying to mount root from ufs:/dev/ada0s4a [rw]...
WARNING: / was not properly dismounted
start_init: trying /sbin/init
<118>Setting hostuuid: 3482a31e-f7d5-11e4-beac-34e6d73c4a93.
<118>Setting hostid: 0x7ed217e0.
<118>Starting file system checks:
<118>/dev/ada0s1a: 5398 files, 316995 used, 444252 free (1516 frags, 55342 =
blocks, 0.2% fragmentation)
<118>/dev/ada0s1d: 175475 files, 947886 used, 1335905 free (14809 frags, 16=
5137 blocks, 0.6% fragmentation)
<118>/dev/ada0s2a: 5403 files, 317180 used, 444067 free (659 frags, 55426 b=
locks, 0.1% fragmentation)
<118>/dev/ada0s2d: 174957 files, 943282 used, 1340509 free (749 frags, 1674=
70 blocks, 0.0% fragmentation)
<118>/dev/ada0s3a: 7218 files, 476323 used, 284924 free (364 frags, 35570 b=
locks, 0.0% fragmentation)
<118>/dev/ada0s3d: 205182 files, 1103572 used, 1180219 free (347 frags, 147=
484 b
locks, 0.0% fragmentation)
<118>/dev/ada0s4a: 5646 files, 299863 used, 461384 free (968 frags, 57552 b=
locks, 0.1% fragmentation)
<118>/dev/ada0s4d: 208393 files, 1295230 used, 988561 free (13225 frags, 12=
1917 blocks, 0.6% fragmentation)
<118>/dev/ada0s4e: 10478 files, 1167526 used, 1368345 free (2025 frags, 170=
790 blocks, 0.1% fragmentation)
battery1: battery initialization failed, giving up
<118>/dev/ada0s4f: 1343217 files, 11547082 used, 20950605 free (11133 frags=
, 2617434 blocks, 0.0% fragmentation)
<118>/dev/ada0s4g: 1850789 files, 22060589 used, 10437098 free (250314 frag=
s, 1273348 blocks, 0.8% fragmentation)
<118>/dev/ada0s4h: 56713 files, 23911910 used, 8585777 free (209 frags, 107=
3196 blocks, 0.0% fragmentation)
<118>/dev/ada0s4i: 545090 files, 3812474 used, 1264325 free (19925 frags, 1=
55550 blocks, 0.4% fragmentation)
<118>Mounting local file systems:
linprocfs registered
<118>.
<118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/l=
ocal/lib/compat/pkg /usr/local/lib/R/lib /usr/local/lib/compat /usr/local/l=
ib/gcc48 /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/lib=
xul /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/pth /usr/local/l=
ib/qt4 /usr/local/lib/virtualbox /usr/local/llvm35/lib /usr/local/llvm36/lib
<118>32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32 /usr/l=
ocal/lib32/compat /usr/local/lib32/wine
<118>Setting hostname: localhost.
<118>Setting up harvesting:[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,=
NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
<118>Feeding entropy:.
wlan0: bpf attached
wlan0: bpf attached
wlan0: Ethernet address: 00:24:d6:7a:03:ce
<118>Created wlan(4) interfaces: wlan0.
<118>Starting dhclient.
<118>em0: no link .............. giving up
<118>/etc/rc.d/dhclient: WARNING: failed to start dhclient
<118>Starting wpa_supplicant.
<118>Starting dhclient.
<118>wlan0: no link ...
iwn0: iwn_read_firmware: ucode rev=3D0x08530501
<118>.
panic: lock (sleep mutex) iwn0_com_lock not locked @ /usr/src/sys/dev/iwn/i=
f_iwn.c:5356
cpuid =3D 2
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0x2=
b/frame 0xfffffe060ad34850
vpanic() at 0xffffffff809e9119 =3D vpanic+0x189/frame 0xfffffe060ad348d0
kassert_panic() at 0xffffffff809e8f82 =3D kassert_panic+0x132/frame 0xfffff=
e060ad34940
__mtx_unlock_flags() at 0xffffffff809cd161 =3D __mtx_unlock_flags+0x71/fram=
e 0xfffffe060ad34980
iwn_updateedca() at 0xffffffff8058c9da =3D iwn_updateedca+0x15a/frame 0xfff=
ffe060ad349e0
taskqueue_run_locked() at 0xffffffff80a36ad0 =3D taskqueue_run_locked+0xf0/=
frame 0xfffffe060ad34a40
taskqueue_thread_loop() at 0xffffffff80a375f8 =3D taskqueue_thread_loop+0x8=
8/frame 0xfffffe060ad34a70
fork_exit() at 0xffffffff809af194 =3D fork_exit+0x84/frame 0xfffffe060ad34a=
b0
fork_trampoline() at 0xffffffff80d9a9be =3D fork_trampoline+0xe/frame 0xfff=
ffe060ad34ab0
--- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 ---
KDB: enter: panic
Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /usr/l=
ib/debug//boot/kernel/geom_eli.ko.debug...done.
done.
Loaded symbols for ...
=2E..
Loaded symbols for /boot/kernel/linprocfs.ko
#0 doadump (textdump=3D0) at pcpu.h:221
221 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump (textdump=3D0) at pcpu.h:221
#1 0xffffffff8037af3e in db_dump (dummy=3D<value optimized out>, dummy2=3D=
false,=20
dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533
#2 0xffffffff8037aab1 in db_command (cmd_table=3D0x0)
at /usr/src/sys/ddb/db_command.c:440
#3 0xffffffff8037a744 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:493
#4 0xffffffff8037d2fb in db_trap (type=3D<value optimized out>, code=3D0)
at /usr/src/sys/ddb/db_main.c:251
#5 0xffffffff80a26264 in kdb_trap (type=3D3, code=3D0, tf=3D<value optimiz=
ed out>)
at /usr/src/sys/kern/subr_kdb.c:654
#6 0xffffffff80dba2c3 in trap (frame=3D0xfffffe060ad34780)
at /usr/src/sys/amd64/amd64/trap.c:549
#7 0xffffffff80d9a48a in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:234
#8 0xffffffff80a2593e in kdb_enter (why=3D0xffffffff812a93ee "panic",=20
msg=3D0xffffffff80a2bb90 "UH\211<E5>AWAVATSH\203<EC>PI\211<F7>A\211<FE>=
H\213\004%<D0><E8><A9>\201H\211E<D8>\201<%x<F8><A9>\201") at cpufunc.h:63
#9 0xffffffff809e9139 in vpanic (fmt=3D<value optimized out>,=20
ap=3D<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:746
#10 0xffffffff809e8f82 in kassert_panic (fmt=3D<value optimized out>)
at /usr/src/sys/kern/kern_shutdown.c:643
#11 0xffffffff809cd161 in __mtx_unlock_flags (c=3D0xfffffe03d7ed0070, opts=
=3D0,=20
file=3D0xffffffff80fcedd8 "/usr/src/sys/dev/iwn/if_iwn.c", line=3D5356)
at /usr/src/sys/kern/kern_mutex.c:245
#12 0xffffffff8058c9da in iwn_updateedca (ic=3D<value optimized out>)
at /usr/src/sys/dev/iwn/if_iwn.c:5356
#13 0xffffffff80a36ad0 in taskqueue_run_locked (queue=3D0xfffff80006f62300)
at /usr/src/sys/kern/subr_taskqueue.c:430
#14 0xffffffff80a375f8 in taskqueue_thread_loop (arg=3D<value optimized out=
>)
at /usr/src/sys/kern/subr_taskqueue.c:683
#15 0xffffffff809af194 in fork_exit (
callout=3D0xffffffff80a37570 <taskqueue_thread_loop>,=20
arg=3D0xfffffe03d7ed0118, frame=3D0xfffffe060ad34ac0)
at /usr/src/sys/kern/kern_fork.c:1006
#16 0xffffffff80d9a9be in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:609
#17 0x0000000000000000 in ?? ()
Current language: auto; currently minimal
(kgdb)=20
------------------------------------------------------------------------
ps -axlww
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
0 0 0 0 -16 0 0 0 swapin DLs - 0:00.00 [kernel]
0 1 0 0 20 0 5320 140 wait DLs - 0:00.00 [init]
0 2 0 0 -16 0 0 0 - DL - 0:00.00 [rand_harvestq]
0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto]
0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto return=
s]
0 5 0 0 -16 0 0 0 - RL - 0:00.00 [cam]
0 6 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator]
0 7 0 0 -16 0 0 0 idle DL - 0:00.00 [enc_daemon0]
0 8 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon]
0 9 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon]
0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit]
0 11 0 0 155 0 0 0 - RL - 0:00.00 [idle]
0 12 0 0 -64 0 0 0 - WL - 0:00.00 [intr]
0 13 0 0 -8 0 0 0 - DL - 0:00.00 [geom]
0 14 0 0 -68 0 0 0 - DL - 0:00.00 [usb]
0 15 0 0 -16 0 0 0 tzpoll DL - 0:00.00 [acpi_thermal]
0 16 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero]
0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon]
0 18 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer]
0 19 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru]
0 20 1 0 52 0 13056 2008 wait Ds+ - 0:00.00 [sh]
0 192 20 0 52 0 13056 2500 wait D+ - 0:00.00 [sh]
0 343 1 0 46 0 20036 6288 - Rs - 0:00.00 [wpa_supplican=
t]
0 346 192 0 52 0 13064 3300 wait D+ - 0:00.00 [sh]
0 353 346 0 45 0 10532 2364 nanslp D+ - 0:00.00 [dhclient]
------------------------------------------------------------------------
[Above was the second try (which is why all the fsck output is
present), and was a verbose boot.]
As I type, vmcore.5 is about half-copied over. I need to relocate
shortly, so I may end up starting the copy over.
Peace,
david
--=20
David H. Wolfskill david@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous coward=
s.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
--mlnxvmnLyWgus2CN
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJWCoyeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4
QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7yGMP/2BXyXD6nFjtADgOC6q4AdXj
w17X11jmqQNghuXH+yCP2RT78Wa3Xhp6L6i+ENpzwwchn1U0lsdeYJuCponeiue7
VL4ZteFFW7EvmFSfEX9EtgWTzc262BwDiCZN+/Vt6bsQ76fwaH8OKYxz5QHvBIi6
cM1Fie7ZarapFTwaJtXe1ew/WbuVuMdC8KY7tMTKzWYonOWcPPGM4aJjKLH38XCq
agtmJg7sZ30lxt8LNnx9EGukpXNeykeENIYRuvEOFCA7PY7bwLbh8KPtG97bISVk
x9ukDKh7gJTz2/4aYCEisA996Rcmo5tq9FZWOb6JPbkp6UzRaIDe2oATZvNLzSdi
H9t40ZpHyf2MqrgfYi0ZTezpyRSzIggiiqD4MwnX2j0xncWGvZ7VO1zPSMebF3ic
O6nnPowz7R2sfyYdtgWbCLxEOA4goa4cPj6ojw6SHKkVNyfGfQl0iH4n+LyJaOXy
GUw2XWHmuSHrA/TrXd5LF/Yn/In8HSqF9io7p/WVyWFX5DQqr882oTRp9buz0KqK
7fOLUjgnsT9WNlcW9lvQP/HmJ27OKe4C7aURuJG6nFEtL80V68rlijDbDjvw7bPY
ZbROZfHWZJQmEehnw78HsS6WTZLc/wu2cokSLimUjLbF3468EL8FlI+MNMvdwO7A
gjhvx/KFO7KuahJRMSgI
=xD15
-----END PGP SIGNATURE-----
--mlnxvmnLyWgus2CN--
From owner-freebsd-net@freebsd.org Tue Sep 29 19:04:54 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0B79A0B2BD
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 29 Sep 2015 19:04:54 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id AD5B312A8
for <freebsd-net@FreeBSD.org>; Tue, 29 Sep 2015 19:04:54 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8TJ4sux018209
for <freebsd-net@FreeBSD.org>; Tue, 29 Sep 2015 19:04:54 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203422] mpd/ppoe not working with re(4) with revision 285177
Date: Tue, 29 Sep 2015 19:04:54 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.2-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc assigned_to
Message-ID: <bug-203422-2472-tduSRcuEAm@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203422-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203422-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 19:04:54 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203422
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marius@FreeBSD.org
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
--- Comment #1 from Mark Linimon <linimon@FreeBSD.org> ---
Cc: committer of the MFC.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Tue Sep 29 19:12:03 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D231A0B962
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 29 Sep 2015 19:12:03 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::50:5])
by mx1.freebsd.org (Postfix) with ESMTP id 6A65818B8
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 19:12:03 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: by mailman.ysv.freebsd.org (Postfix)
id 67566A0B95F; Tue, 29 Sep 2015 19:12:03 +0000 (UTC)
Delivered-To: net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E24BA0B95E;
Tue, 29 Sep 2015 19:12:03 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com
[IPv6:2607:f8b0:4001:c05::22d])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 1100A18B5;
Tue, 29 Sep 2015 19:12:03 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: by igbkq10 with SMTP id kq10so87949227igb.0;
Tue, 29 Sep 2015 12:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=jXSgqf8hm2g3iqldOVV1gzjI1QrJ/jKUSoFbTZ/dVLQ=;
b=NFvEy0dZxQeICl5jqedp/KiPvYyqRvNdU+LnfU3Y62PS/QVRvGmtEbfH5+l5HZC/iV
31DIbOXdJmSs2pz4nV5B+c7xOuD0qnfkvhd5FqNrJ5w+zdIFMaSCFOO0j+eDIH18ApEe
5WzQnE2N8qD+t+1cCZx3XHVFJcfh6FqVMlWtPRDuMBWyeqwjqLDHWGWaL/hhB2bIdf7P
chAxbyV4xpYghORuHbNiynr9rwVDrrUDbT6BNALyN8SmcPY1Pck6Is9TzjbR/Q4LkvN9
gPXrJFHXr7gEzASt/BrMvjFVKbSgQHYRr6W5ylaSPB2cKa0RlYly5IiS20Q5BQ9umAon
lbsQ==
MIME-Version: 1.0
X-Received: by 10.50.60.3 with SMTP id d3mr394092igr.37.1443553922173; Tue, 29
Sep 2015 12:12:02 -0700 (PDT)
Received: by 10.36.46.15 with HTTP; Tue, 29 Sep 2015 12:12:02 -0700 (PDT)
In-Reply-To: <20150929130534.GI1125@albert.catwhisker.org>
References: <20150929130534.GI1125@albert.catwhisker.org>
Date: Tue, 29 Sep 2015 12:12:02 -0700
Message-ID: <CAJ-Vmo=NESAxpv8X=KPA6EOhnkFcojwSEWYDcAL=tFqq4T3R2w@mail.gmail.com>
Subject: Re: head/amd64 @r288358: panic: lock (sleep mutex) iwn0_com_lock not
locked @ /usr/src/sys/dev/iwn/if_iwn.c:5356
From: Adrian Chadd <adrian.chadd@gmail.com>
To: David Wolfskill <david@catwhisker.org>,
"current@freebsd.org" <current@freebsd.org>,
"net@freebsd.org" <net@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 19:12:03 -0000
hi
(please subscribe and email freebsd-wireless@ these things, I'm more
likely to notice!)
It looks due to my recent taskqueue change for updateedca. I'll go fix
that today.
Thanks,
-a
On 29 September 2015 at 06:05, David Wolfskill <david@catwhisker.org> wrote=
:
> No known/observed issues with:
> FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #197 r288335M/288335=
:1100079: Mon Sep 28 04:14:47 PDT 2015 root@localhost:/common/S4/obj/us=
r/src/sys/CANARY amd64
>
> on my laptop, but:
> FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #198 r288358M/288358=
:1100079: Tue Sep 29 04:46:49 PDT 2015 root@localhost:/common/S4/obj/us=
r/src/sys/CANARY amd64
>
> was OK up to the point of attempting to establish a link using the
> wlan0 interface (the underlying hardware for which is iwn on the laptop).
>
> I was able to get a crash dump, and am presently copying it to
> <http://www.catwhisker.org/~david/FreeBSD/head> (along with the
> core.txt, which has already made it over). (I am 3 time zones east
> of home, and will be spending the bulk of the day returning home
> -- and thus, without ability to respond to email for a while).
>
> Here's an excerpt from the core.txt.5:
>
> localhost dumped core - see /var/crash/vmcore.5
>
> Tue Sep 29 05:14:30 PDT 2015
>
> FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #198 r288358M/288358=
:1100079: Tue Sep 29 04:46:49 PDT 2015 root@localhost:/common/S4/obj/us=
r/src/sys/CANARY amd64
>
> panic: lock (sleep mutex) iwn0_com_lock not locked @ /usr/src/sys/dev/iwn=
/if_iwn.c:5356
>
> GNU gdb 6.1.1 [FreeBSD]
> ...
> Unread portion of the kernel message buffer:
> d:
> ACPI: SSDT 0xFFFFF80006E30800 0005AA (v01 PmRef ApIst 00003000 INTL 2=
0120711)
> ACPI: Dynamic OEM Table Load:
> ACPI: SSDT 0xFFFFF800067F6A00 000119 (v01 PmRef ApCst 00003000 INTL 2=
0120711)
> random: harvesting attach, 8 bytes (4 bits) from cpu1
> cpu2: Processor \_PR_.CPU2 (ACPI ID 3) -> APIC ID 4
> cpu2: <ACPI CPU> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from cpu2
> cpu3: Processor \_PR_.CPU3 (ACPI ID 4) -> APIC ID 6
> cpu3: <ACPI CPU> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from cpu3
> cpu4: Processor \_PR_.CPU4 (ACPI ID 5) -> APIC ID 1
> cpu4: <ACPI CPU> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from cpu4
> cpu5: Processor \_PR_.CPU5 (ACPI ID 6) -> APIC ID 3
> cpu5: <ACPI CPU> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from cpu5
> cpu6: Processor \_PR_.CPU6 (ACPI ID 7) -> APIC ID 5
> cpu6: <ACPI CPU> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from cpu6
> cpu7: Processor \_PR_.CPU7 (ACPI ID 8) -> APIC ID 7
> cpu7: <ACPI CPU> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from cpu7
> hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
> hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route
> hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic
> hpet0: t1: irqs 0x00f00000 (0), MSI
> hpet0: t2: irqs 0x00f00800 (0), MSI
> hpet0: t3: irqs 0x00f01000 (0), MSI
> hpet0: t4: irqs 0x00000000 (0), MSI
> hpet0: t5: irqs 0x00000000 (0), MSI
> hpet0: t6: irqs 0x00000000 (0), MSI
> hpet0: t7: irqs 0x00000000 (0), MSI
> Timecounter "HPET" frequency 14318180 Hz quality 950
> msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
> msi: routing MSI-X IRQ 257 to local APIC 0 vector 50
> msi: routing MSI-X IRQ 258 to local APIC 0 vector 51
> msi: routing MSI-X IRQ 259 to local APIC 0 vector 52
> msi: routing MSI-X IRQ 260 to local APIC 0 vector 53
> msi: routing MSI-X IRQ 261 to local APIC 0 vector 54
> msi: routing MSI-X IRQ 262 to local APIC 0 vector 55
> msi: routing MSI-X IRQ 263 to local APIC 0 vector 56
> Event timer "HPET" frequency 14318180 Hz quality 550
> random: harvesting attach, 8 bytes (4 bits) from hpet0
> atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
> atrtc0: Warning: Couldn't map I/O.
> atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustme=
nt 0.500000000s)
> ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57
> Event timer "RTC" frequency 32768 Hz quality 0
> random: harvesting attach, 8 bytes (4 bits) from atrtc0
> attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58
> Event timer "i8254" frequency 1193182 Hz quality 100
> random: harvesting attach, 8 bytes (4 bits) from attimer0
> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
> random: harvesting attach, 8 bytes (4 bits) from acpi_timer0
> acpi_ec0: <Embedded Controller: GPE 0x10> port 0x930,0x934 on acpi0
> random: harvesting attach, 8 bytes (4 bits) from acpi_ec0
> pci_link0: Index IRQ Rtd Ref IRQs
> Initial Probe 0 11 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 11 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link0
> pci_link1: Index IRQ Rtd Ref IRQs
> Initial Probe 0 10 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 10 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link1
> pci_link2: Index IRQ Rtd Ref IRQs
> Initial Probe 0 10 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 10 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link2
> pci_link3: Index IRQ Rtd Ref IRQs
> Initial Probe 0 5 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 5 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link3
> pci_link4: Index IRQ Rtd Ref IRQs
> Initial Probe 0 3 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 3 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link4
> pci_link5: Index IRQ Rtd Ref IRQs
> Initial Probe 0 5 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 5 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link5
> pci_link6: Index IRQ Rtd Ref IRQs
> Initial Probe 0 11 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 11 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link6
> pci_link7: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15
> Validation 0 255 N 0 3 4 5 6 10 11 12 14 15
> After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15
> random: harvesting attach, 8 bytes (4 bits) from pci_link7
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pcib0: decoding 5 range 0-0x3e
> pcib0: decoding 4 range 0-0xcf7
> pcib0: decoding 4 range 0xd00-0xffff
> pcib0: decoding 3 range 0xa0000-0xbffff
> pcib0: decoding 3 range 0xdc000-0xdffff
> pcib0: decoding 3 range 0xe0000-0xe3fff
> pcib0: decoding 3 range 0xe4000-0xe7fff
> pcib0: decoding 3 range 0xd0000000-0xfeafffff
> pci0: <ACPI PCI bus> on pcib0
> pci0: domain=3D0, physical bus=3D0
> found-> vendor=3D0x8086, dev=3D0x0c04, revid=3D0x06
> domain=3D0, bus=3D0, slot=3D0, func=3D0
> class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> found-> vendor=3D0x8086, dev=3D0x0c01, revid=3D0x06
> domain=3D0, bus=3D0, slot=3D1, func=3D0
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> pcib0: matched entry for 0.1.INTA
> pcib0: slot 1 INTA hardwired to IRQ 16
> secbus=3D1, subbus=3D1
> found-> vendor=3D0x8086, dev=3D0x8c31, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D20, func=3D0
> class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 2 supports D0 D3 current D0
> MSI supports 8 messages, 64 bit
> map[10]: type Memory, range 64, base 0xf7120000, size 16, enabled
> pcib0: allocated type 3 (0xf7120000-0xf712ffff) for rid 10 of pci0:0:20:0
> pcib0: matched entry for 0.20.INTA
> pcib0: slot 20 INTA hardwired to IRQ 16
> found-> vendor=3D0x8086, dev=3D0x8c3a, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D22, func=3D0
> class=3D07-80-00, hdrtype=3D0x00, mfdev=3D1
> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message, 64 bit
> map[10]: type Memory, range 64, base 0xf713c000, size 4, enabled
> pcib0: allocated type 3 (0xf713c000-0xf713c00f) for rid 10 of pci0:0:22:0
> pcib0: matched entry for 0.22.INTA
> pcib0: slot 22 INTA hardwired to IRQ 16
> found-> vendor=3D0x8086, dev=3D0x153a, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D25, func=3D0
> class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D3
> powerspec 2 supports D0 D3 current D0
> MSI supports 1 message, 64 bit
> map[10]: type Memory, range 32, base 0xf7100000, size 17, enabled
> pcib0: allocated type 3 (0xf7100000-0xf711ffff) for rid 10 of pci0:0:25:0
> map[14]: type Memory, range 32, base 0xf7139000, size 12, enabled
> pcib0: allocated type 3 (0xf7139000-0xf7139fff) for rid 14 of pci0:0:25:0
> map[18]: type I/O Port, range 32, base 0xf040, size 5, enabled
> pcib0: allocated type 4 (0xf040-0xf05f) for rid 18 of pci0:0:25:0
> pcib0: matched entry for 0.25.INTA
> pcib0: slot 25 INTA hardwired to IRQ 20
> found-> vendor=3D0x8086, dev=3D0x8c2d, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D26, func=3D0
> class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 2 supports D0 D3 current D0
> map[10]: type Memory, range 32, base 0xf7138000, size 10, enabled
> pcib0: allocated type 3 (0xf7138000-0xf71383ff) for rid 10 of pci0:0:26:0
> pcib0: matched entry for 0.26.INTA
> pcib0: slot 26 INTA hardwired to IRQ 16
> ehci early: SMM active, request owner change
> found-> vendor=3D0x8086, dev=3D0x8c20, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D27, func=3D0
> class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 2 supports D0 D3 current D0
> MSI supports 1 message, 64 bit
> map[10]: type Memory, range 64, base 0xf7130000, size 14, enabled
> pcib0: allocated type 3 (0xf7130000-0xf7133fff) for rid 10 of pci0:0:27:0
> pcib0: matched entry for 0.27.INTA
> pcib0: slot 27 INTA hardwired to IRQ 22
> found-> vendor=3D0x8086, dev=3D0x8c10, revid=3D0xd4
> domain=3D0, bus=3D0, slot=3D28, func=3D0
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> pcib0: matched entry for 0.28.INTA
> pcib0: slot 28 INTA hardwired to IRQ 16
> secbus=3D2, subbus=3D2
> found-> vendor=3D0x8086, dev=3D0x8c14, revid=3D0xd4
> domain=3D0, bus=3D0, slot=3D28, func=3D2
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Dc, irq=3D10
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> pcib0: matched entry for 0.28.INTC
> pcib0: slot 28 INTC hardwired to IRQ 18
> secbus=3D3, subbus=3D3
> found-> vendor=3D0x8086, dev=3D0x8c16, revid=3D0xd4
> domain=3D0, bus=3D0, slot=3D28, func=3D3
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Dd, irq=3D5
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> pcib0: matched entry for 0.28.INTD
> pcib0: slot 28 INTD hardwired to IRQ 19
> secbus=3D4, subbus=3D7
> found-> vendor=3D0x8086, dev=3D0x8c18, revid=3D0xd4
> domain=3D0, bus=3D0, slot=3D28, func=3D4
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> pcib0: matched entry for 0.28.INTA
> pcib0: slot 28 INTA hardwired to IRQ 16
> secbus=3D8, subbus=3D8
> found-> vendor=3D0x8086, dev=3D0x8c1c, revid=3D0xd4
> domain=3D0, bus=3D0, slot=3D28, func=3D6
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Dc, irq=3D10
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> pcib0: matched entry for 0.28.INTC
> pcib0: slot 28 INTC hardwired to IRQ 18
> secbus=3D9, subbus=3D16
> found-> vendor=3D0x8086, dev=3D0x8c1e, revid=3D0xd4
> domain=3D0, bus=3D0, slot=3D28, func=3D7
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Dd, irq=3D5
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> pcib0: matched entry for 0.28.INTD
> pcib0: slot 28 INTD hardwired to IRQ 19
> secbus=3D17, subbus=3D17
> found-> vendor=3D0x8086, dev=3D0x8c26, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D29, func=3D0
> class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D5
> powerspec 2 supports D0 D3 current D0
> map[10]: type Memory, range 32, base 0xf7137000, size 10, enabled
> pcib0: allocated type 3 (0xf7137000-0xf71373ff) for rid 10 of pci0:0:29:0
> pcib0: matched entry for 0.29.INTA
> pcib0: slot 29 INTA hardwired to IRQ 21
> ehci early: SMM active, request owner change
> found-> vendor=3D0x8086, dev=3D0x8c4f, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D31, func=3D0
> class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> found-> vendor=3D0x8086, dev=3D0x282a, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D31, func=3D2
> class=3D01-04-00, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Db, irq=3D5
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message
> map[10]: type I/O Port, range 32, base 0xf090, size 3, enabled
> pcib0: allocated type 4 (0xf090-0xf097) for rid 10 of pci0:0:31:2
> map[14]: type I/O Port, range 32, base 0xf080, size 2, enabled
> pcib0: allocated type 4 (0xf080-0xf083) for rid 14 of pci0:0:31:2
> map[18]: type I/O Port, range 32, base 0xf070, size 3, enabled
> pcib0: allocated type 4 (0xf070-0xf077) for rid 18 of pci0:0:31:2
> map[1c]: type I/O Port, range 32, base 0xf060, size 2, enabled
> pcib0: allocated type 4 (0xf060-0xf063) for rid 1c of pci0:0:31:2
> map[20]: type I/O Port, range 32, base 0xf020, size 5, enabled
> pcib0: allocated type 4 (0xf020-0xf03f) for rid 20 of pci0:0:31:2
> map[24]: type Memory, range 32, base 0xf7136000, size 11, enabled
> pcib0: allocated type 3 (0xf7136000-0xf71367ff) for rid 24 of pci0:0:31:2
> pcib0: matched entry for 0.31.INTB
> pcib0: slot 31 INTB hardwired to IRQ 19
> found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x04
> domain=3D0, bus=3D0, slot=3D31, func=3D3
> class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0003, statreg=3D0x0280, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Dc, irq=3D10
> map[10]: type Memory, range 64, base 0xf7135000, size 8, enabled
> pcib0: allocated type 3 (0xf7135000-0xf71350ff) for rid 10 of pci0:0:31:3
> map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled
> pcib0: allocated type 4 (0xf000-0xf01f) for rid 20 of pci0:0:31:3
> pcib0: matched entry for 0.31.INTC
> pcib0: slot 31 INTC hardwired to IRQ 18
> random: harvesting attach, 8 bytes (4 bits) from hostb0
> pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
> pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib1
> pcib0: allocated type 3 (0xf4000000-0xf50fffff) for rid 20 of pcib1
> pcib0: allocated type 3 (0xe0000000-0xf1ffffff) for rid 24 of pcib1
> pcib1: domain 0
> pcib1: secondary bus 1
> pcib1: subordinate bus 1
> pcib1: I/O decode 0xe000-0xefff
> pcib1: memory decode 0xf4000000-0xf50fffff
> pcib1: prefetched decode 0xe0000000-0xf1ffffff
> pcib1: special decode VGA
> pci1: <ACPI PCI bus> on pcib1
> pcib1: allocated bus range (1-1) for rid 0 of pci1
> pci1: domain=3D0, physical bus=3D1
> found-> vendor=3D0x10de, dev=3D0x0ff6, revid=3D0xa1
> domain=3D0, bus=3D1, slot=3D0, func=3D0
> class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1
> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D11
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message, 64 bit
> map[10]: type Memory, range 32, base 0xf4000000, size 24, enabled
> pcib1: allocated memory range (0xf4000000-0xf4ffffff) for rid 10 of pci0:=
1:0:0
> map[14]: type Prefetchable Memory, range 64, base 0xe0000000, siz=
e 28, enabled
> pcib1: allocated prefetch range (0xe0000000-0xefffffff) for rid 14 of pci=
0:1:0:0
> map[1c]: type Prefetchable Memory, range 64, base 0xf0000000, siz=
e 25, enabled
> pcib1: allocated prefetch range (0xf0000000-0xf1ffffff) for rid 1c of pci=
0:1:0:0
> map[24]: type I/O Port, range 32, base 0xe000, size 7, enabled
> pcib1: allocated I/O port range (0xe000-0xe07f) for rid 24 of pci0:1:0:0
> pcib1: matched entry for 1.0.INTA
> pcib1: slot 0 INTA hardwired to IRQ 16
> found-> vendor=3D0x10de, dev=3D0x0e1b, revid=3D0xa1
> domain=3D0, bus=3D1, slot=3D0, func=3D1
> class=3D04-03-00, hdrtype=3D0x00, mfdev=3D1
> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Db, irq=3D10
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message, 64 bit
> map[10]: type Memory, range 32, base 0xf5080000, size 14, enabled
> pcib1: allocated memory range (0xf5080000-0xf5083fff) for rid 10 of pci0:=
1:0:1
> pcib1: matched entry for 1.0.INTB
> pcib1: slot 0 INTB hardwired to IRQ 17
> vgapci0: <VGA-compatible display> port 0xe000-0xe07f mem 0xf4000000-0xf4f=
fffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff irq 16 at device 0.0 on p=
ci1
> nvidia0: <Quadro K1100M> on vgapci0
> vgapci0: child nvidia0 requested pci_enable_io
> vgapci0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 264 to local APIC 0 vector 59
> vgapci0: using IRQ 264 for MSI
> vgapci0: child nvidia0 requested pci_enable_io
> random: harvesting attach, 8 bytes (4 bits) from nvidia0
> vgapci0: Boot video device
> random: harvesting attach, 8 bytes (4 bits) from vgapci0
> hdac0: <NVIDIA (0x0e1b) HDA Controller> mem 0xf5080000-0xf5083fff irq 17 =
at device 0.1 on pci1
> hdac0: PCI card vendor: 0x1028, device: 0x05cc
> hdac0: HDA Driver Revision: 20120126_0002
> hdac0: Config options: on=3D0x00000000 off=3D0x00000000
> hdac0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 265 to local APIC 0 vector 60
> hdac0: using IRQ 265 for MSI
> hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 4, 64bit, CORB 256, RIRB 256
> random: harvesting attach, 8 bytes (4 bits) from hdac0
> random: harvesting attach, 8 bytes (4 bits) from pci1
> random: harvesting attach, 8 bytes (4 bits) from pcib1
> xhci0: <Intel Lynx Point USB 3.0 controller> mem 0xf7120000-0xf712ffff ir=
q 16 at device 20.0 on pci0
> xhci0: 32 bytes context size, 64-bit DMA
> xhci0: attempting to allocate 1 MSI vectors (8 supported)
> msi: routing MSI IRQ 266 to local APIC 0 vector 61
> xhci0: using IRQ 266 for MSI
> xhci0: MSI enabled
> xhci0: Port routing mask set to 0xffffffff
> usbus0 on xhci0
> xhci0: usbpf: Attached
> random: harvesting attach, 8 bytes (4 bits) from usbus0
> random: harvesting attach, 8 bytes (4 bits) from xhci0
> pci0: <simple comms> at device 22.0 (no driver attached)
> em0: <Intel(R) PRO/1000 Network Connection 7.4.2> port 0xf040-0xf05f mem =
0xf7100000-0xf711ffff,0xf7139000-0xf7139fff irq 20 at device 25.0 on pci0
> em0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 267 to local APIC 0 vector 62
> em0: using IRQ 267 for MSI
> em0: Using an MSI interrupt
> em0: bpf attached
> em0: Ethernet address: 34:e6:d7:3c:4a:93
> em0: netmap queues/slots: TX 1/1024, RX 1/1024
> random: harvesting attach, 8 bytes (4 bits) from em0
> ehci0: <Intel Lynx Point USB 2.0 controller USB-B> mem 0xf7138000-0xf7138=
3ff irq 16 at device 26.0 on pci0
> ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 63
> usbus1: EHCI version 1.0
> usbus1 on ehci0
> ehci0: usbpf: Attached
> random: harvesting attach, 8 bytes (4 bits) from usbus1
> random: harvesting attach, 8 bytes (4 bits) from ehci0
> hdac1: <Intel Lynx Point HDA Controller> mem 0xf7130000-0xf7133fff irq 22=
at device 27.0 on pci0
> hdac1: PCI card vendor: 0x1028, device: 0x05cc
> hdac1: HDA Driver Revision: 20120126_0002
> hdac1: Config options: on=3D0x00000000 off=3D0x00000000
> hdac1: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 268 to local APIC 0 vector 64
> hdac1: using IRQ 268 for MSI
> hdac1: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256
> random: harvesting attach, 8 bytes (4 bits) from hdac1
> pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
> pcib2: domain 0
> pcib2: secondary bus 2
> pcib2: subordinate bus 2
> pci2: <ACPI PCI bus> on pcib2
> pcib2: allocated bus range (2-2) for rid 0 of pci2
> pci2: domain=3D0, physical bus=3D2
> random: harvesting attach, 8 bytes (4 bits) from pci2
> random: harvesting attach, 8 bytes (4 bits) from pcib2
> pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
> pcib0: allocated type 3 (0xf7000000-0xf70fffff) for rid 20 of pcib3
> pcib3: domain 0
> pcib3: secondary bus 3
> pcib3: subordinate bus 3
> pcib3: memory decode 0xf7000000-0xf70fffff
> pci3: <ACPI PCI bus> on pcib3
> pcib3: allocated bus range (3-3) for rid 0 of pci3
> pci3: domain=3D0, physical bus=3D3
> found-> vendor=3D0x8086, dev=3D0x4232, revid=3D0x00
> domain=3D0, bus=3D3, slot=3D0, func=3D0
> class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D10
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message, 64 bit
> map[10]: type Memory, range 64, base 0xf7000000, size 13, enabled
> pcib3: allocated memory range (0xf7000000-0xf7001fff) for rid 10 of pci0:=
3:0:0
> pcib3: matched entry for 3.0.INTA
> pcib3: slot 0 INTA hardwired to IRQ 18
> iwn0: <Intel WiFi Link 5100> mem 0xf7000000-0xf7001fff irq 18 at device 0=
.0 on pci3
> iwn0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 269 to local APIC 0 vector 65
> iwn0: using IRQ 269 for MSI
> iwn0: MIMO 1T2R, MoW, address 00:24:d6:7a:03:ce
> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24M=
bps 36Mbps 48Mbps 54Mbps
> iwn0: 1T2R
> iwn0: 11na MCS 20MHz
> iwn0: MCS 0-7: 6.5Mbps - 65Mbps
> iwn0: 11na MCS 20MHz SGI
> iwn0: MCS 0-7: 7Mbps - 72Mbps
> iwn0: 11na MCS 40MHz:
> iwn0: MCS 0-7: 13.5Mbps - 135Mbps
> iwn0: 11na MCS 40MHz SGI:
> iwn0: MCS 0-7: 15Mbps - 150Mbps
> iwn0: 11ng MCS 20MHz
> iwn0: MCS 0-7: 6.5Mbps - 65Mbps
> iwn0: 11ng MCS 20MHz SGI
> iwn0: MCS 0-7: 7Mbps - 72Mbps
> iwn0: 11ng MCS 40MHz:
> iwn0: MCS 0-7: 13.5Mbps - 135Mbps
> iwn0: 11ng MCS 40MHz SGI:
> iwn0: MCS 0-7: 15Mbps - 150Mbps
> random: harvesting attach, 8 bytes (4 bits) from iwn0
> random: harvesting attach, 8 bytes (4 bits) from pci3
> random: harvesting attach, 8 bytes (4 bits) from pcib3
> pcib4: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
> pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib4
> pcib0: allocated type 3 (0xf6500000-0xf6efffff) for rid 20 of pcib4
> pcib0: allocated type 3 (0xf3500000-0xf3efffff) for rid 24 of pcib4
> pcib4: domain 0
> pcib4: secondary bus 4
> pcib4: subordinate bus 7
> pcib4: I/O decode 0xd000-0xdfff
> pcib4: memory decode 0xf6500000-0xf6efffff
> pcib4: prefetched decode 0xf3500000-0xf3efffff
> pci4: <ACPI PCI bus> on pcib4
> pcib4: allocated bus range (4-4) for rid 0 of pci4
> pci4: domain=3D0, physical bus=3D4
> random: harvesting attach, 8 bytes (4 bits) from pci4
> random: harvesting attach, 8 bytes (4 bits) from pcib4
> pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
> pcib0: allocated type 4 (0xc000-0xcfff) for rid 1c of pcib5
> pcib0: allocated type 3 (0xf5b00000-0xf64fffff) for rid 20 of pcib5
> pcib0: allocated type 3 (0xf2b00000-0xf34fffff) for rid 24 of pcib5
> pcib5: domain 0
> pcib5: secondary bus 8
> pcib5: subordinate bus 8
> pcib5: I/O decode 0xc000-0xcfff
> pcib5: memory decode 0xf5b00000-0xf64fffff
> pcib5: prefetched decode 0xf2b00000-0xf34fffff
> pci5: <ACPI PCI bus> on pcib5
> pcib5: allocated bus range (8-8) for rid 0 of pci5
> pci5: domain=3D0, physical bus=3D8
> random: harvesting attach, 8 bytes (4 bits) from pci5
> random: harvesting attach, 8 bytes (4 bits) from pcib5
> pcib6: <ACPI PCI-PCI bridge> irq 18 at device 28.6 on pci0
> pcib0: allocated type 4 (0xa000-0xbfff) for rid 1c of pcib6
> pcib0: allocated type 3 (0xf5100000-0xf5afffff) for rid 20 of pcib6
> pcib0: allocated type 3 (0xf2100000-0xf2afffff) for rid 24 of pcib6
> pcib6: domain 0
> pcib6: secondary bus 9
> pcib6: subordinate bus 16
> pcib6: I/O decode 0xa000-0xbfff
> pcib6: memory decode 0xf5100000-0xf5afffff
> pcib6: prefetched decode 0xf2100000-0xf2afffff
> pci6: <ACPI PCI bus> on pcib6
> pcib6: allocated bus range (9-9) for rid 0 of pci6
> pci6: domain=3D0, physical bus=3D9
> random: harvesting attach, 8 bytes (4 bits) from pci6
> random: harvesting attach, 8 bytes (4 bits) from pcib6
> pcib7: <ACPI PCI-PCI bridge> irq 19 at device 28.7 on pci0
> pcib0: allocated type 3 (0xf6f00000-0xf6ffffff) for rid 20 of pcib7
> pcib7: domain 0
> pcib7: secondary bus 17
> pcib7: subordinate bus 17
> pcib7: memory decode 0xf6f00000-0xf6ffffff
> pci7: <ACPI PCI bus> on pcib7
> pcib7: allocated bus range (17-17) for rid 0 of pci7
> pci7: domain=3D0, physical bus=3D17
> found-> vendor=3D0x1217, dev=3D0x8520, revid=3D0x01
> domain=3D0, bus=3D17, slot=3D0, func=3D0
> class=3D08-05-01, hdrtype=3D0x00, mfdev=3D0
> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns=
)
> intpin=3Da, irq=3D5
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message, 64 bit, vector masks
> map[10]: type Memory, range 32, base 0xf6f01000, size 12, enabled
> pcib7: allocated memory range (0xf6f01000-0xf6f01fff) for rid 10 of pci0:=
17:0:0
> map[14]: type Memory, range 32, base 0xf6f00000, size 11, enabled
> pcib7: allocated memory range (0xf6f00000-0xf6f007ff) for rid 14 of pci0:=
17:0:0
> pcib7: matched entry for 17.0.INTA
> pcib7: slot 0 INTA hardwired to IRQ 19
> sdhci_pci0: <Generic SD HCI> mem 0xf6f01000-0xf6f01fff,0xf6f00000-0xf6f00=
7ff irq 19 at device 0.0 on pci7
> sdhci_pci0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 270 to local APIC 0 vector 66
> sdhci_pci0: using IRQ 270 for MSI
> sdhci_pci0: Hardware doesn't specify timeout clock frequency, setting BRO=
KEN_TIMEOUT quirk.
> sdhci_pci0-slot0: 50MHz HS 1bit 3.3V 1.8V DMA
> sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM=
P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00000603
> sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000
> sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
> sdhci_pci0-slot0: Present: 0x00080000 | Host ctl: 0x00000000
> sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000
> sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000002
> sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000
> sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
> sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
> sdhci_pci0-slot0: Caps: 0x25fe3280 | Max curr: 0x005800c8
> sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> sdhci_pci0: 1 slot(s) allocated
> random: harvesting attach, 8 bytes (4 bits) from sdhci_pci0
> random: harvesting attach, 8 bytes (4 bits) from pci7
> random: harvesting attach, 8 bytes (4 bits) from pcib7
> ehci1: <Intel Lynx Point USB 2.0 controller USB-A> mem 0xf7137000-0xf7137=
3ff irq 21 at device 29.0 on pci0
> ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 67
> usbus2: EHCI version 1.0
> usbus2 on ehci1
> ehci1: usbpf: Attached
> random: harvesting attach, 8 bytes (4 bits) from usbus2
> random: harvesting attach, 8 bytes (4 bits) from ehci1
> isab0: <PCI-ISA bridge> at device 31.0 on pci0
> isa0: <ISA bus> on isab0
> random: harvesting attach, 8 bytes (4 bits) from isa0
> random: harvesting attach, 8 bytes (4 bits) from isab0
> ahci0: <Intel ICH8M AHCI SATA controller> port 0xf090-0xf097,0xf080-0xf08=
3,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xf7136000-0xf71367ff irq 1=
9 at device 31.2 on pci0
> ahci0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 271 to local APIC 0 vector 68
> ahci0: using IRQ 271 for MSI
> ahci0: AHCI v1.30 with 5 6Gbps ports, Port Multiplier not supported
> ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM eSATA=
5ports
> ahci0: Caps2: APST
> ahcich0: <AHCI channel> at channel 0 on ahci0
> ahcich0: Caps:
> random: harvesting attach, 8 bytes (4 bits) from ahcich0
> ahcich1: <AHCI channel> at channel 1 on ahci0
> ahcich1: Caps: HPCP MPSP
> random: harvesting attach, 8 bytes (4 bits) from ahcich1
> ahcich2: <AHCI channel> at channel 2 on ahci0
> ahcich2: Caps: ESP
> random: harvesting attach, 8 bytes (4 bits) from ahcich2
> ahcich3: <AHCI channel> at channel 3 on ahci0
> ahcich3: Caps: ESP
> random: harvesting attach, 8 bytes (4 bits) from ahcich3
> ahcich4: not probed (disabled)
> ahciem0: <AHCI enclosure management bridge> on ahci0
> ahciem0: Caps: ALHD XMT SMB LED
> random: harvesting attach, 8 bytes (4 bits) from ahciem0
> random: harvesting attach, 8 bytes (4 bits) from ahci0
> ichsmb0: <Intel Lynx Point SMBus controller> port 0xf000-0xf01f mem 0xf71=
35000-0xf71350ff irq 18 at device 31.3 on pci0
> ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 69
> smbus0: <System Management Bus> on ichsmb0
> smb0: <SMBus generic I/O> on smbus0
> random: harvesting attach, 8 bytes (4 bits) from smb0
> random: harvesting attach, 8 bytes (4 bits) from smbus0
> random: harvesting attach, 8 bytes (4 bits) from ichsmb0
> random: harvesting attach, 8 bytes (4 bits) from pci0
> random: harvesting attach, 8 bytes (4 bits) from pcib0
> acpi_lid0: <Control Method Lid Switch> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from acpi_lid0
> acpi_button0: <Power Button> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from acpi_button0
> acpi_button1: <Sleep Button> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from acpi_button1
> acpi_acad0: <AC Adapter> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from acpi_acad0
> battery0: <ACPI Control Method Battery> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from battery0
> battery1: <ACPI Control Method Battery> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from battery1
> acpi_tz0: <Thermal Zone> on acpi0
> random: harvesting attach, 8 bytes (4 bits) from acpi_tz0
> random: harvesting attach, 8 bytes (4 bits) from atdma0
> random: harvesting attach, 8 bytes (4 bits) from fpupnp0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> atkbd: the current kbd controller command byte 0065
> atkbd: keyboard ID 0x41ab (2)
> <7>kbdc: RESET_KBD return code:00fa
> <7>kbdc: RESET_KBD status:00aa
> kbd0 at atkbd0
> kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000
> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 70
> atkbd0: [GIANT-LOCKED]
> random: harvesting attach, 8 bytes (4 bits) from atkbd0
> psm0: unable to allocate IRQ
> random: harvesting attach, 8 bytes (4 bits) from atkbdc0
> psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
> psm0: current command byte:0065
> <7>kbdc: TEST_AUX_PORT status:0000
> <7>kbdc: RESET_AUX return code:00fa
> <7>kbdc: RESET_AUX status:00aa
> <7>kbdc: RESET_AUX ID:0000
> <7>kbdc: RESET_AUX return code:00fa
> <7>kbdc: RESET_AUX status:00aa
> <7>kbdc: RESET_AUX ID:0000
> <7>psm: status 00 02 64
> <7>psm: status 00 00 64
> <7>psm: status 00 03 64
> <7>psm: status 00 03 64
> <7>psm: data 08 00 00
> <7>psm: status 00 00 14
> <7>psm: status 73 03 0a
> <7>psm: status 00 02 64
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 71
> psm0: [GIANT-LOCKED]
> psm0: model GlidePoint, device ID 0-00, 2 buttons
> psm0: config:00004000, flags:00000008, packet size:3
> psm0: syncmask:c0, syncbits:00
> random: harvesting attach, 8 bytes (4 bits) from psm0
> random: harvesting attach, 8 bytes (4 bits) from psmcpnp0
> ppc1: using extended I/O port range
> ACPI: Enabled 2 GPEs in block 00 to 3F
> random: harvesting attach, 8 bytes (4 bits) from acpi0
> random: harvesting attach, 8 bytes (4 bits) from apic0
> acpi0: wakeup code va 0xfffffe060bb12000 pa 0x88000
> random: harvesting attach, 8 bytes (4 bits) from nexus0
> ahc_isa_identify 0: ioport 0xc00 alloc failed
> ahc_isa_identify 1: ioport 0x1c00 alloc failed
> ahc_isa_identify 2: ioport 0x2c00 alloc failed
> ahc_isa_identify 3: ioport 0x3c00 alloc failed
> ahc_isa_identify 4: ioport 0x4c00 alloc failed
> ahc_isa_identify 5: ioport 0x5c00 alloc failed
> ahc_isa_identify 6: ioport 0x6c00 alloc failed
> ahc_isa_identify 7: ioport 0x7c00 alloc failed
> ahc_isa_identify 8: ioport 0x8c00 alloc failed
> ahc_isa_identify 9: ioport 0x9c00 alloc failed
> ahc_isa_identify 10: ioport 0xac00 alloc failed
> ahc_isa_identify 11: ioport 0xbc00 alloc failed
> ahc_isa_identify 12: ioport 0xcc00 alloc failed
> ahc_isa_identify 13: ioport 0xdc00 alloc failed
> ahc_isa_identify 14: ioport 0xec00 alloc failed
> pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0
> pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 0 of orm0
> pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xdd800-0xddfff) for rid 0 of orm0
> pcib0: allocated type 3 (0xde000-0xde7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xde800-0xdefff) for rid 0 of orm0
> pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xdf800-0xdffff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe0000-0xe07ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe0800-0xe0fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe1000-0xe17ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe1800-0xe1fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe2000-0xe27ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe2800-0xe2fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe3000-0xe37ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe3800-0xe3fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe4000-0xe47ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe4800-0xe4fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe5000-0xe57ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe5800-0xe5fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe6000-0xe67ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe6800-0xe6fff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe7000-0xe77ff) for rid 0 of orm0
> pcib0: allocated type 3 (0xe7800-0xe7fff) for rid 0 of orm0
> isa_probe_children: disabling PnP devices
> atkbdc: atkbdc0 already exists; skipping it
> atrtc: atrtc0 already exists; skipping it
> attimer: attimer0 already exists; skipping it
> sc: sc0 already exists; skipping it
> isa_probe_children: probing non-PnP devices
> sc0 failed to probe on isa0
> vga0 failed to probe on isa0
> pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0
> pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0
> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
> ppc0: cannot reserve I/O port range
> ppc0 failed to probe at irq 7 on isa0
> pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0
> uart0 failed to probe at port 0x3f8 irq 4 on isa0
> pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 of uart1
> uart1 failed to probe at port 0x2f8 irq 3 on isa0
> wbwd0 failed to probe on isa0
> isa_probe_children: probing PnP devices
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf0
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf1
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf2
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf3
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf4
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf5
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf6
> random: harvesting attach, 8 bytes (4 bits) from acpi_perf7
> coretemp0: <CPU On-Die Thermal Sensors> on cpu0
> coretemp0: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> random: harvesting attach, 8 bytes (4 bits) from cpufreq0
> random: harvesting attach, 8 bytes (4 bits) from est0
> coretemp1: <CPU On-Die Thermal Sensors> on cpu1
> coretemp1: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp1
> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> random: harvesting attach, 8 bytes (4 bits) from cpufreq1
> random: harvesting attach, 8 bytes (4 bits) from est1
> coretemp2: <CPU On-Die Thermal Sensors> on cpu2
> coretemp2: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp2
> est2: <Enhanced SpeedStep Frequency Control> on cpu2
> random: harvesting attach, 8 bytes (4 bits) from cpufreq2
> random: harvesting attach, 8 bytes (4 bits) from est2
> coretemp3: <CPU On-Die Thermal Sensors> on cpu3
> coretemp3: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp3
> est3: <Enhanced SpeedStep Frequency Control> on cpu3
> random: harvesting attach, 8 bytes (4 bits) from cpufreq3
> random: harvesting attach, 8 bytes (4 bits) from est3
> coretemp4: <CPU On-Die Thermal Sensors> on cpu4
> coretemp4: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp4
> est4: <Enhanced SpeedStep Frequency Control> on cpu4
> random: harvesting attach, 8 bytes (4 bits) from cpufreq4
> random: harvesting attach, 8 bytes (4 bits) from est4
> coretemp5: <CPU On-Die Thermal Sensors> on cpu5
> coretemp5: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp5
> est5: <Enhanced SpeedStep Frequency Control> on cpu5
> random: harvesting attach, 8 bytes (4 bits) from cpufreq5
> random: harvesting attach, 8 bytes (4 bits) from est5
> coretemp6: <CPU On-Die Thermal Sensors> on cpu6
> coretemp6: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp6
> est6: <Enhanced SpeedStep Frequency Control> on cpu6
> random: harvesting attach, 8 bytes (4 bits) from cpufreq6
> random: harvesting attach, 8 bytes (4 bits) from est6
> coretemp7: <CPU On-Die Thermal Sensors> on cpu7
> coretemp7: Setting TjMax=3D100
> random: harvesting attach, 8 bytes (4 bits) from coretemp7
> est7: <Enhanced SpeedStep Frequency Control> on cpu7
> random: harvesting attach, 8 bytes (4 bits) from cpufreq7
> random: harvesting attach, 8 bytes (4 bits) from est7
> Device configuration finished.
> procfs registered
> lapic: Divisor 2, Frequency 49885587 Hz
> Timecounters tick every 1.000 msec
> vlan: initialized, using hash tables with chaining
> Linux ELF exec handler installed
> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536
> IPsec: Initialized Security Association Processing.
> ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to deny,=
logging disabled
> DUMMYNET 0 with IPv6 initialized (100409)
> load_dn_sched dn_sched QFQ loaded
> load_dn_sched dn_sched RR loaded
> load_dn_sched dn_sched WF2Q+ loaded
> lo0: bpf attached
> load_dn_sched dn_sched FIFO loaded
> load_dn_sched dn_sched PRIO loaded
> hptrr: no controller detected.
> hptnr: no controller detected.
> hdacc0: <NVIDIA (0x0042) HDA CODEC> at cad 0 on hdac0
> hdaa0: <NVIDIA (0x0042) Audio Function Group> at nid 1 on hdacc0
> hdaa0: Subsystem ID: 0x102805cc
> hdaa0: NumGPIO=3D0 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D0
> hdaa0: Original pins configuration:
> hdaa0: nid 0x as seq device conn jack loc color m=
isc
> hdaa0: 4 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0
> hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
> hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0
> hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
> hdaa0: Patched pins configuration:
> hdaa0: nid 0x as seq device conn jack loc color m=
isc
> hdaa0: 4 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0=
DISA
> hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
> hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0=
DISA
> hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0
> hdaa0: 2 associations found:
> hdaa0: Association 0 (15) out:
> hdaa0: Pin nid=3D5 seq=3D0
> hdaa0: Association 1 (15) out:
> hdaa0: Pin nid=3D7 seq=3D0
> hdaa0: Tracing association 0 (15)
> hdaa0: Pin 5 traced to DAC 8
> hdaa0: Association 0 (15) trace succeeded
> hdaa0: Tracing association 1 (15)
> hdaa0: Pin 7 traced to DAC 9
> hdaa0: Association 1 (15) trace succeeded
> hdaa0: Looking for additional DAC for association 0 (15)
> hdaa0: Looking for additional DAC for association 1 (15)
> hdaa0: Tracing input monitor
> hdaa0: Tracing other input monitors
> hdaa0: Tracing beeper
> hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref
> pcm0: <NVIDIA (0x0042) (HDMI/DP 8ch)> at nid 5 on hdaa0
> pcm0: Playback:
> pcm0: Stream cap: 0x00000005 AC3 PCM
> pcm0: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 K=
Hz
> pcm0: DAC: 8
> pcm0:
> pcm0: nid=3D5 [pin: Digital-out (Jack)]
> pcm0: + <- nid=3D8 [audio output] [src: pcm]
> pcm0:
> pcm0: Mixer "vol" -> "none": child=3D0x00000010
> pcm0: Mixer "pcm": parent=3D"vol"
> pcm0: Soft PCM mixer ENABLED
> pcm0: Playback channel matrix is: unknown, assuming 7.1 (disconnected)
> random: harvesting attach, 8 bytes (4 bits) from pcm0
> pcm1: <NVIDIA (0x0042) (HDMI/DP 8ch)> at nid 7 on hdaa0
> pcm1: Playback:
> pcm1: Stream cap: 0x00000005 AC3 PCM
> pcm1: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 K=
Hz
> pcm1: DAC: 9
> pcm1:
> pcm1: nid=3D7 [pin: Digital-out (Jack)]
> pcm1: + <- nid=3D9 [audio output] [src: pcm]
> pcm1:
> pcm1: Mixer "vol" -> "none": child=3D0x00000010
> pcm1: Mixer "pcm": parent=3D"vol"
> pcm1: Soft PCM mixer ENABLED
> pcm1: Playback channel matrix is: unknown, assuming 7.1 (disconnected)
> random: harvesting attach, 8 bytes (4 bits) from pcm1
> random: harvesting attach, 8 bytes (4 bits) from hdaa0
> random: harvesting attach, 8 bytes (4 bits) from hdacc0
> hdacc1: <Realtek ALC292 HDA CODEC> at cad 0 on hdac1
> hdaa1: <Realtek ALC292 Audio Function Group> at nid 1 on hdacc1
> hdaa1: Subsystem ID: 0x102805cc
> hdaa1: NumGPIO=3D5 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D1
> hdaa1: GPIO0: disabled
> hdaa1: GPIO1: disabled
> hdaa1: GPIO2: disabled
> hdaa1: GPIO3: disabled
> hdaa1: GPIO4: disabled
> hdaa1: Original pins configuration:
> hdaa1: nid 0x as seq device conn jack loc color m=
isc
> hdaa1: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1
> hdaa1: 19 411111f0 15 0 Speaker None 1/8 Rear Black 1
> hdaa1: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1
> hdaa1: 21 0221401f 1 15 Headphones Jack 1/8 Front Green 0
> hdaa1: 22 01014020 2 0 Line-out Jack 1/8 Rear Green 0
> hdaa1: 24 02a19031 3 1 Mic Jack 1/8 Front Pink 0
> hdaa1: 25 01a1903e 3 14 Mic Jack 1/8 Rear Pink 0
> hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1
> hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1
> hdaa1: 29 40700001 0 1 Modem-handset None Unknown 0x00 Unknown 0
> hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1
> hdaa1: Patching widget caps nid=3D29 0x00400400 -> 0x00700400
> hdaa1: Patched pins configuration:
> hdaa1: nid 0x as seq device conn jack loc color m=
isc
> hdaa1: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1
> hdaa1: 19 411111f0 15 0 Speaker None 1/8 Rear Black 1=
DISA
> hdaa1: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1
> hdaa1: 21 0221401f 1 15 Headphones Jack 1/8 Front Green 0
> hdaa1: 22 01014020 2 0 Line-out Jack 1/8 Rear Green 0
> hdaa1: 24 02a19031 3 1 Mic Jack 1/8 Front Pink 0
> hdaa1: 25 01a1903e 3 14 Mic Jack 1/8 Rear Pink 0
> hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1=
DISA
> hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1=
DISA
> hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1=
DISA
> hdaa1: 4 associations found:
> hdaa1: Association 0 (1) out:
> hdaa1: Pin nid=3D20 seq=3D0
> hdaa1: Pin nid=3D21 seq=3D15
> hdaa1: Association 1 (2) out:
> hdaa1: Pin nid=3D22 seq=3D0
> hdaa1: Association 2 (3) in:
> hdaa1: Pin nid=3D24 seq=3D1
> hdaa1: Pin nid=3D25 seq=3D14
> hdaa1: Association 3 (4) in:
> hdaa1: Pin nid=3D18 seq=3D0
> hdaa1: Tracing association 0 (1)
> hdaa1: Pin 20 traced to DAC 2
> hdaa1: Pin 21 traced to DAC 2 and hpredir 0
> hdaa1: Association 0 (1) trace succeeded
> hdaa1: Tracing association 1 (2)
> hdaa1: Pin 22 traced to DAC 3
> hdaa1: Association 1 (2) trace succeeded
> hdaa1: Tracing association 2 (3)
> hdaa1: Pin 24 traced to ADC 8
> hdaa1: Pin 25 traced to ADC 8
> hdaa1: Association 2 (3) trace succeeded
> hdaa1: Tracing association 3 (4)
> hdaa1: Pin 18 traced to ADC 9
> hdaa1: Association 3 (4) trace succeeded
> hdaa1: Looking for additional DAC for association 0 (1)
> hdaa1: Looking for additional DAC for association 1 (2)
> hdaa1: Looking for additional ADC for association 2 (3)
> hdaa1: Looking for additional ADC for association 3 (4)
> hdaa1: Tracing input monitor
> hdaa1: Tracing nid 11 to out
> hdaa1: nid 11 is input monitor
> hdaa1: Tracing other input monitors
> hdaa1: Tracing nid 18 to out
> hdaa1: Tracing nid 24 to out
> hdaa1: Tracing nid 25 to out
> hdaa1: Tracing beeper
> hdaa1: Headphones redirection for association 0 nid=3D21 using unsolicite=
d responses.
> hdaa1: Redirect output to: main
> hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref
> pcm2: <Realtek ALC292 (Analog 2.0+HP/2.0)> at nid 20,21 and 24,25 on hdaa=
1
> pcm2: Playback:
> pcm2: Stream cap: 0x00000001 PCM
> pcm2: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
> pcm2: DAC: 2
> pcm2:
> pcm2: nid=3D20 [pin: Speaker (Fixed)]
> pcm2: + <- nid=3D12 [audio mixer] [src: pcm, mix]
> pcm2: + <- nid=3D2 [audio output] [src: pcm]
> pcm2: + <- nid=3D11 [audio mixer] [src: mix]
> pcm2:
> pcm2: nid=3D21 [pin: Headphones (Green Jack)]
> pcm2: + <- nid=3D12 [audio mixer] [src: pcm, mix]
> pcm2: + <- nid=3D2 [audio output] [src: pcm]
> pcm2: + <- nid=3D11 [audio mixer] [src: mix]
> pcm2:
> pcm2: Record:
> pcm2: Stream cap: 0x00000001 PCM
> pcm2: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
> pcm2: ADC: 8
> pcm2:
> pcm2: nid=3D8 [audio input]
> pcm2: + <- nid=3D35 [audio selector] [src: speaker, line, mic, mix]
> pcm2: + <- nid=3D24 [pin: Mic (Pink Jack)] [src: mic]
> pcm2: + <- nid=3D25 [pin: Mic (Pink Jack)] [src: line]
> pcm2: + <- nid=3D29 [beep widget] [src: speaker]
> pcm2: + <- nid=3D11 [audio mixer] [src: mix]
> pcm2:
> pcm2: Input Mix:
> pcm2:
> pcm2: nid=3D11 [audio mixer]
> pcm2: + <- nid=3D24 [pin: Mic (Pink Jack)] [src: mic]
> pcm2: + <- nid=3D25 [pin: Mic (Pink Jack)] [src: line]
> pcm2: + <- nid=3D29 [beep widget] [src: speaker]
> pcm2:
> pcm2: Master Volume (OSS: vol): -65/0dB
> pcm2: +- ctl 1 (nid 2 out): -65/0dB (88 steps)
> pcm2: +- ctl 10 (nid 12 in 0): mute
> pcm2: +- ctl 11 (nid 12 in 1): mute
> pcm2: +- ctl 18 (nid 20 in ): mute
> pcm2: +- ctl 19 (nid 21 in ): mute
> pcm2:
> pcm2: PCM Volume (OSS: pcm): -65/0dB
> pcm2: +- ctl 1 (nid 2 out): -65/0dB (88 steps)
> pcm2: +- ctl 10 (nid 12 in 0): mute
> pcm2:
> pcm2: Microphone Volume (OSS: mic): 0/30dB
> pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
> pcm2: +- ctl 5 (nid 11 in 0): -34/12dB (32 steps) + mute
> pcm2: +- ctl 22 (nid 24 out): 0/30dB (4 steps)
> pcm2:
> pcm2: Line-in Volume (OSS: line): 0/36dB
> pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
> pcm2: +- ctl 6 (nid 11 in 1): -34/12dB (32 steps) + mute
> pcm2: +- ctl 23 (nid 25 out): 0/36dB (4 steps)
> pcm2:
> pcm2: Speaker/Beep Volume (OSS: speaker): -17/12dB
> pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
> pcm2: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute
> pcm2:
> pcm2: Recording Level (OSS: rec): -17/30dB
> pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
> pcm2:
> pcm2: Input Mix Level (OSS: mix): -17/30dB
> pcm2: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute
> pcm2: +- ctl 11 (nid 12 in 1): mute
> pcm2:
> pcm2: Input Monitoring Level (OSS: igain): 0/0dB
> pcm2: +- ctl 11 (nid 12 in 1): mute
> pcm2:
> pcm2: Mixer "vol":
> pcm2: Mixer "pcm":
> pcm2: Mixer "speaker":
> pcm2: Mixer "line":
> pcm2: Mixer "mic":
> pcm2: Mixer "mix":
> pcm2: Mixer "rec":
> pcm2: Mixer "igain":
> pcm2: Mixer "ogain":
> pcm2: Playback channel set is: Front Left, Front Right,
> pcm2: Playback channel matrix is: 2.0 (unknown)
> pcm2: Recording channel set is: Front Left, Front Right,
> pcm2: Recording channel matrix is: 2.0 (disconnected)
> random: harvesting attach, 8 bytes (4 bits) from pcm2
> pcm3: <Realtek ALC292 (Analog)> at nid 22 and 18 on hdaa1
> pcm3: Playback:
> pcm3: Stream cap: 0x00000001 PCM
> pcm3: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
> pcm3: DAC: 3
> pcm3:
> pcm3: nid=3D22 [pin: Line-out (Green Jack)]
> pcm3: + <- nid=3D13 [audio mixer] [src: pcm, mix]
> pcm3: + <- nid=3D3 [audio output] [src: pcm]
> pcm3: + <- nid=3D11 [audio mixer] [src: mix]
> pcm3:
> pcm3: Record:
> pcm3: Stream cap: 0x00000001 PCM
> pcm3: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
> pcm3: ADC: 9
> pcm3:
> pcm3: nid=3D9 [audio input]
> pcm3: + <- nid=3D34 [audio selector] [src: speaker, monitor]
> pcm3: + <- nid=3D29 [beep widget] [src: speaker]
> pcm3: + <- nid=3D18 [pin: Mic (Fixed)] [src: monitor]
> pcm3:
> pcm3: Master Volume (OSS: vol): -65/0dB
> pcm3: +- ctl 2 (nid 3 out): -65/0dB (88 steps)
> pcm3: +- ctl 12 (nid 13 in 0): mute
> pcm3: +- ctl 13 (nid 13 in 1): mute
> pcm3: +- ctl 20 (nid 22 in ): mute
> pcm3:
> pcm3: PCM Volume (OSS: pcm): -65/0dB
> pcm3: +- ctl 2 (nid 3 out): -65/0dB (88 steps)
> pcm3: +- ctl 12 (nid 13 in 0): mute
> pcm3:
> pcm3: Microphone2 Volume (OSS: monitor): 0/36dB
> pcm3: +- ctl 4 (nid 9 in 0): -17/30dB (64 steps) + mute
> pcm3: +- ctl 16 (nid 18 out): 0/36dB (4 steps)
> pcm3:
> pcm3: Speaker/Beep Volume (OSS: speaker)
> pcm3: +- ctl 4 (nid 9 in 0): -17/30dB (64 steps) + mute
> pcm3:
> pcm3: Recording Level (OSS: rec): -17/30dB
> pcm3: +- ctl 4 (nid 9 in 0): -17/30dB (64 steps) + mute
> pcm3: +- ctl 16 (nid 18 out): 0/36dB (4 steps)
> pcm3:
> pcm3: Input Mix Level (OSS: mix)
> pcm3: +- ctl 13 (nid 13 in 1): mute
> pcm3:
> pcm3: Input Monitoring Level (OSS: igain): 0/0dB
> pcm3: +- ctl 13 (nid 13 in 1): mute
> pcm3:
> pcm3: Mixer "vol":
> pcm3: Mixer "pcm":
> pcm3: Mixer "rec":
> pcm3: Mixer "igain":
> pcm3: Mixer "ogain":
> pcm3: Mixer "monitor":
> pcm3: Playback channel set is: Front Left, Front Right,
> pcm3: Playback channel matrix is: 2.0 (disconnected)
> pcm3: Automatically set rec source to: monitor
> pcm3: Recording channel set is: Front Left, Front Right,
> pcm3: Recording channel matrix is: 2.0 (unknown)
> random: harvesting attach, 8 bytes (4 bits) from pcm3
> random: harvesting attach, 8 bytes (4 bits) from hdaa1
> random: harvesting attach, 8 bytes (4 bits) from hdacc1
> usbus0: 5.0Gbps Super Speed USB v3.0
> usbus1: 480Mbps High Speed USB v2.0
> usbus2: 480Mbps High Speed USB v2.0
> ugen0.1: <0x8086> at usbus0
> ugen1.1: <Intel> at usbus1
> uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
> ugen2.1: <Intel> at usbus2
> uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
> ahcich0: AHCI reset...
> ahcich0: SATA connect time=3D900us status=3D00000123
> ahcich0: AHCI reset: device found
> ahcich0: AHCI reset: device ready after 0ms
> ahcich1: AHCI reset...
> ahcich1: SATA connect time=3D1000us status=3D00000113
> ahcich1: AHCI reset: device found
> ahcich1: AHCI reset: device ready after 0ms
> ahcich2: AHCI reset...
> ahcich2: SATA connect timeout time=3D10000us status=3D00000000
> ahcich2: AHCI reset: device not found
> ahcich3: AHCI reset...
> ahcich3: SATA connect timeout time=3D10000us status=3D00000000
> ahcich3: AHCI reset: device not found
> acpi_acad0: acline initialization start
> battery0: battery initialization start
> battery1: battery initialization start
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> GEOM: new disk ada0
> ada0: <ST750LX003-1AC154 HPM1> ATA8-ACS SATA 2.x device
> ada0: Serial Number W200TLZD
> ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C)
> ada0: Previously was known as ad4
> pass0 at ahcich0 bus 0 scbus0 target 0 lun 0
> pass0: <ST750LX003-1AC154 HPM1> ATA8-ACS SATA 2.x device
> pass0: Serial Number W200TLZD
> pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
> pass0: Command Queueing enabled
> pass1 at ahcich1 bus 0 scbus1 target 0 lun 0
> pass1: <HL-DT-ST DVD+-RW GS40N A100> Removable CD-ROM SCSI device
> pass1: Serial Number K0121171240
> pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192byt=
es)
> pass2 at ahciem0 bus 0 scbus4 target 0 lun 0
> pass2: acpi_acad0: On Line
> <AHCI SGPIO Enclosure 1.00 0001> SEMB S-E-S 2.00 device
> acpi_acad0: GEOM_PART: partition 1 on (ada0, MBR) is not aligned on 4096 =
bytes
> GEOM_PART: partition 2 on (ada0, MBR) is not aligned on 4096 bytes
> GEOM_PART: partition 3 on (ada0, MBR) is not aligned on 4096 bytes
> acline initialization done, tried 1 times
> ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
> ses0: <AHCI SGPIO Enclosure 1.00 0001> SEMB S-E-S 2.00 device
> ses0: SEMB SES Device
> ses0: Generation Code 0x0 has 1 SubEnclosures
> ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, off=
set 8
> ses0: WWN: 0
> ses0: Type Desc[0]: Type 0x17, MaxElt 5, In Subenc 0, Text Length 0:
> Netvsc initializing... done!
> lapic7: CMCI unmasked
> lapic6: CMCI unmasked
> lapic3: CMCI unmasked
> lapic2: CMCI unmasked
> lapic4: CMCI unmasked
> lapic5: CMCI unmasked
> SMP: AP CPU #1 Launched!
> cpu1 AP:
> ID: 0x00000001 VER: 0x01060015 LDR: 0x00000002 DFR: 0x00000000 x2A=
PIC: 1
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> cmci: 0x000100f2
> SMP: AP CPU #4 Launched!
> cpu4 AP:
> ID: 0x00000004 VER: 0x01060015 LDR: 0x00000010 DFR: 0x00000000 x2A=
PIC: 1
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> cmci: 0x000000f2
> SMP: AP CPU #7 Launched!
> cpu7 AP:
> ID: 0x00000007 VER: 0x01060015 LDR: 0x00000080 DFR: 0x00000000 x2A=
PIC: 1
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> cmci: 0x000000f2
> SMP: AP CPU #5 Launched!
> cpu5 AP:
> ID: 0x00000005 VER: 0x01060015 LDR: 0x00000020 DFR: 0x00000000 x2A=
PIC: 1
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> cmci: 0x000000f2
> SMP: AP CPU #3 Launched!
> cpu3 AP:
> ID: 0x00000003 VER: 0x01060015 LDR: 0x00000008 DFR: 0x00000000 x2A=
PIC: 1
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> cmci: 0x000000f2
> SMP: AP CPU #6 Launched!
> cpu6 AP:
> ID: 0x00000006 VER: 0x01060015 LDR: 0x00000040 DFR: 0x00000000 x2A=
PIC: 1
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> cmci: 0x000000f2
> SMP: AP CPU #2 Launched!
> cpu2 AP:
> ID: 0x00000002 VER: 0x01060015 LDR: 0x00000004 DFR: 0x00000000 x2A=
PIC: 1
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> cmci: 0x000000f2
> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 2 vector 48
> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 4 vector 48
> ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 48
> ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 49
> ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 4 vector 49
> msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 48
> Sleeping on "acmtx" with the following non-sleepable locks held:
> exclusive sleep mutex intr sources (intr sources) r =3D 0 (0xffffffff81b6=
73c0) locked @ /usr/src/sys/x86/x86/intr_machdep.c:540
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0=
x2b/frame 0xffffffff82c126f0
> witness_warn() at 0xffffffff80a4489f =3D witness_warn+0x4af/frame 0xfffff=
fff82c127c0
> _sleep() at cd0 at ahcich1 bus 0 scbus1 target 0 lun 0
> cd0: <HL-DT-ST DVD+-RW GS40N A100> Removable CD-ROM SCSI device
> 0xcd0: Serial Number K0121171240
> ffffffff809cd0: 150.000MB/s transfersf (1SATA 1.x, efUDMA5, dATAPI 12byte=
s, PIO 8192bytes=3D)
> _cd0: cd present [1 x 0 byte records]
> sleep+0x6d/frame 0xffffffff82c12860
> AcpiOsAcquireMutex() at 0xffffffff8038b97f =3D AcpiOsAcquireMutex+0x17f/f=
rame 0xffffffff82c128c0
> AcpiUtAcquireMutex() at 0xffffffff803639ca =3D AcpiUtAcquireMutex+0x3a/fr=
ame 0xffffffff82c128f0
> AcpiExEnterInterpreter() at 0xffffffff803517bb =3D AcpiExEnterInterpreter=
+0xb/frame 0xffffffff82c12900
> AcpiEvaluateObject() at 0xffffffff803588ad =3D AcpiEvaluateObject+0x24d/f=
rame 0xffffffff82c12960
> acpi_GetInteger() at 0xffffffff8038c4bd =3D acpi_GetInteger+0x3d/frame 0x=
ffffffff82c129c0
> dmar_find_hpet() at 0xffffffff80ecb3e1 =3D dmar_find_hpet+0x81/frame 0xff=
ffffff82c12a00
> iommu_map_msi_intr() at 0xffffffff80ed3d1d =3D iommu_map_msi_intr+0x2d/fr=
ame 0xffffffff82c12a50
> msi_map() at 0xffffffff80ee9241 =3D msi_map+0x171/frame 0xffffffff82c12a9=
0
> hpet_remap_intr() at 0xffffffff80dc0095 =3D hpet_remap_intr+0xb5/frame 0x=
ffffffff82c12ae0
> msi_assign_cpu() at 0xffffffff80ee88f0 =3D msi_assign_cpu+0x1c0/frame 0xf=
fffffff82c12b30
> intr_shuffle_irqs() at 0xffffffff80edfb83 =3D intr_shuffle_irqs+0x73/fram=
e 0xffffffff82c12b50
> mi_startup() at 0xffffffff8098a918 =3D mi_startup+0x118/frame 0xffffffff8=
2c12b70
> btext() at 0xffffffff802f902c =3D btext+0x2c
> lock order reversal: (Giant after non-sleepable)
> 1st 0xffffffff81b673c0 intr sources (intr sources) @ /usr/src/sys/x86/x8=
6/intr_machdep.c:540
> 2nd 0xffffffff81bbcb10 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:24=
4
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0=
x2b/frame 0xffffffff82c126f0
> witness_checkorder() at 0xffffffff80a434ca =3D witness_checkorder+0xe7a/f=
rame 0xffffffff82c12770
> __mtx_lock_flags() at 0xffffffff809ccc48 =3D __mtx_lock_flags+0xa8/frame =
0xffffffff82c127c0
> _sleep() at 0xffffffff809f226a =3D _sleep+0x3da/frame 0xffffffff82c12860
> AcpiOsAcquireMutex() at 0xffffffff8038b97f =3D AcpiOsAcquireMutex+0x17f/f=
rame 0xffffffff82c128c0
> AcpiUtAcquireMutex() at 0xffffffff803639ca =3D AcpiUtAcquireMutex+0x3a/fr=
ame 0xffffffff82c128f0
> AcpiExEnterInterpreter() at 0xffffffff803517bb =3D AcpiExEnterInterpreter=
+0xb/frame 0xffffffff82c12900
> AcpiEvaluateObject() at 0xffffffff803588ad =3D AcpiEvaluateObject+0x24d/f=
rame 0xffffffff82c12960
> acpi_GetInteger() at 0xffffffff8038c4bd =3D acpi_GetInteger+0x3d/frame 0x=
ffffffff8
> 2c129c0
> dmar_find_hpet() at 0xffffffff80ecb3e1 =3D dmar_find_hpet+0x81/frame 0xff=
ffffff82c12a00
> iommu_map_msi_intr() at 0xffffffff80ed3d1d =3D iommu_map_msi_intr+0x2d/fr=
ame 0xffffffff82c12a50
> msi_map() at 0xffffffff80ee9241 =3D msi_map+0x171/frame 0xffffffff82c12a9=
0
> GEOM: new disk cd0
> hpet_remap_intr() at 0xffffffff80dc0095 =3D hpet_remap_intr+0xb5/frame 0x=
ffffffff82c12ae0
> msi_assign_cpu() at 0xffffffff80ee88f0 =3D msi_assign_cpu+0x1c0/frame 0xf=
fffffff82c12b30
> intr_shuffle_irqs() at 0xffffffff80edfb83 =3D intr_shuffle_irqs+0x73/fram=
e 0xffffffff82c12b50
> mi_startup() at 0xffffffff8098a918 =3D mi_startup+0x118/frame 0xffffffff8=
2c12b70
> btext() at 0xffffffff802f902c =3D btext+0x2c
> GEOM_PART: partition 1 on (diskid/DISK-W200TLZD, MBR) is not aligned on 4=
096 bytes
> GEOM_PART: partition 2 on (diskid/DISK-W200TLZD, MBR) is not aligned on 4=
096 bytes
> GEOM_PART: partition 3 on (diskid/DISK-W200TLZD, MBR) is not aligned on 4=
096 bytes
> Expensive timeout(9) function: 0xffffffff80883770(0xffffffff817648c8) 0.0=
0470876
> 8 s
> msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50
> Sleeping on "acmtx" with the following non-sleepable locks held:
> exclusive sleep mutex intr sources (intr sources) r =3D 0 (0xffffffff81b6=
73c0) locked @ /usr/src/sys/x86/x86/intr_machdep.c:540
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0=
x2b/frame 0xffffffff82c126b0
> witness_warn() at 0xffffffff80a4489f =3D witness_warn+0x4af/frame 0xfffff=
fff82c12780
> _sleep() at 0xffffffff809f1efd =3D _sleep+0x6d/frame 0xffffffff82c12820
> AcpiOsAcquireMutex() at 0xffffffff8038b97f =3D AcpiOsAcquireMutex+0x17f/f=
rame 0xffffffff82c12880
> AcpiUtAcquireMutex() at 0xffffffff803639ca =3D AcpiUtAcquireMutex+0x3a/fr=
ame 0xffffffff82c128b0
> AcpiExEnterInterpreter() at 0xffffffff803517bb =3D AcpiExEnterInterpreter=
+0xb/frame 0xffffffff82c128c0
> AcpiNsEvaluate() at 0xffffffff8035539b =3D AcpiNsEvaluate+0x1cb/frame 0xf=
fffffff82c12900
> AcpiEvaluateObject() at 0xffffffff803587ca =3D AcpiEvaluateObject+0x16a/f=
rame 0xffffffff82c12960
> acpi_GetInteger() at 0xffffffff8038c4bd =3D acpi_GetInteger+0x3d/frame 0x=
ffffffff8
> 2c129c0
> dmar_find_hpet() at 0xffffffff80ecb3e1 =3D dmar_find_hpet+0x81/frame 0xff=
ffffff82c12a00
> iommu_map_msi_intr() at 0xffffffff80ed3d1d =3D iommu_map_msi_intr+0x2d/fr=
ame 0xffffffff82c12a50
> msi_map() at 0xffffffff80ee9241 =3D msi_map+0x171/frame 0xffffffff82c12a9=
0
> hpet_remap_intr() at 0xffffffff80dc0095 =3D hpet_remap_intr+0xb5/frame 0x=
ffffffff82c12ae0
> msi_assign_cpu() at 0xffffffff80ee88f0 =3D msi_assign_cpu+0x1c0/frame 0xf=
fffffff82c12b30
> intr_shuffle_irqs() at 0xffffffff80edfb83 =3D intr_shuffle_irqs+0x73/fram=
e 0xffffffff82c12b50
> mi_startup() at 0xffffffff8098a918 =3D mi_startup+0x118/frame 0xffffffff8=
2c12b70
> btext() at 0xffffffff802f902c =3D btext+0x2c
> msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 48
> msi: Assigning MSI-X IRQ 260 to local APIC 4 vector 50
> msi: Assigning MSI-X IRQ 261 to local APIC 5 vector 48
> msi: Assigning MSI-X IRQ 262 to local APIC 6 vector 49
> msi: Assigning MSI-X IRQ 263 to local APIC 7 vector 48
> msi: Assigning MSI IRQ 264 to local APIC 6 vector 50
> msi: Assigning MSI IRQ 266 to local APIC 2 vector 51
> msi: Assigning MSI IRQ 267 to local APIC 4 vector 51
> msi: Assigning MSI IRQ 268 to local APIC 6 vector 51
> msi: Assigning MSI IRQ 270 to local APIC 2 vector 52
> msi: Assigning MSI IRQ 271 to local APIC 4 vector 52
> SMP: passed TSC synchronization test
> TSC timecounter discards lower 1 bit(s)
> Timecounter "TSC-low" frequency 1396796100 Hz quality 1000
> WARNING: WITNESS option enabled, expect reduced performance.
> WARNING: DIAGNOSTIC option enabled, expect reduced performance.
> battery0: battery initialization done, tried 1 times
> Root mount waiting for: usbus2 usbus1 usbus0
> uhub1: 2 ports with 2 removable, self powered
> random: harvesting attach, 8 bytes (4 bits) from uhub1
> uhub2: 2 ports with 2 removable, self powered
> random: harvesting attach, 8 bytes (4 bits) from uhub2
> uhub0: 21 ports with 21 removable, self powered
> random: harvesting attach, 8 bytes (4 bits) from uhub0
> ugen2.2: <vendor 0x8087> at usbus2
> uhub3: <vendor 0x8087 product 0x8000, class 9/0, rev 2.00/0.04, addr 2> o=
n usbus2
> ugen1.2: <vendor 0x8087> at usbus1
> uhub4: <vendor 0x8087 product 0x8008, class 9/0, rev 2.00/0.04, addr 2> o=
n usbus1
> Root mount waiting for: usbus2 usbus1
> uhub4: 6 ports with 6 removable, self powered
> random: harvesting attach, 8 bytes (4 bits) from uhub4
> uhub3: 8 ports with 8 removable, self powered
> random: harvesting attach, 8 bytes (4 bits) from uhub3
> ugen2.3: <Broadcom Corp> at usbus2
> ugen1.3: <CN0767N972487515BSJWA01> at usbus1
> Trying to mount root from ufs:/dev/ada0s4a [rw]...
> WARNING: / was not properly dismounted
> start_init: trying /sbin/init
> <118>Setting hostuuid: 3482a31e-f7d5-11e4-beac-34e6d73c4a93.
> <118>Setting hostid: 0x7ed217e0.
> <118>Starting file system checks:
> <118>/dev/ada0s1a: 5398 files, 316995 used, 444252 free (1516 frags, 5534=
2 blocks, 0.2% fragmentation)
> <118>/dev/ada0s1d: 175475 files, 947886 used, 1335905 free (14809 frags, =
165137 blocks, 0.6% fragmentation)
> <118>/dev/ada0s2a: 5403 files, 317180 used, 444067 free (659 frags, 55426=
blocks, 0.1% fragmentation)
> <118>/dev/ada0s2d: 174957 files, 943282 used, 1340509 free (749 frags, 16=
7470 blocks, 0.0% fragmentation)
> <118>/dev/ada0s3a: 7218 files, 476323 used, 284924 free (364 frags, 35570=
blocks, 0.0% fragmentation)
> <118>/dev/ada0s3d: 205182 files, 1103572 used, 1180219 free (347 frags, 1=
47484 b
> locks, 0.0% fragmentation)
> <118>/dev/ada0s4a: 5646 files, 299863 used, 461384 free (968 frags, 57552=
blocks, 0.1% fragmentation)
> <118>/dev/ada0s4d: 208393 files, 1295230 used, 988561 free (13225 frags, =
121917 blocks, 0.6% fragmentation)
> <118>/dev/ada0s4e: 10478 files, 1167526 used, 1368345 free (2025 frags, 1=
70790 blocks, 0.1% fragmentation)
> battery1: battery initialization failed, giving up
> <118>/dev/ada0s4f: 1343217 files, 11547082 used, 20950605 free (11133 fra=
gs, 2617434 blocks, 0.0% fragmentation)
> <118>/dev/ada0s4g: 1850789 files, 22060589 used, 10437098 free (250314 fr=
ags, 1273348 blocks, 0.8% fragmentation)
> <118>/dev/ada0s4h: 56713 files, 23911910 used, 8585777 free (209 frags, 1=
073196 blocks, 0.0% fragmentation)
> <118>/dev/ada0s4i: 545090 files, 3812474 used, 1264325 free (19925 frags,=
155550 blocks, 0.4% fragmentation)
> <118>Mounting local file systems:
> linprocfs registered
> <118>.
> <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr=
/local/lib/compat/pkg /usr/local/lib/R/lib /usr/local/lib/compat /usr/local=
/lib/gcc48 /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/l=
ibxul /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/pth /usr/local=
/lib/qt4 /usr/local/lib/virtualbox /usr/local/llvm35/lib /usr/local/llvm36/=
lib
> <118>32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32 /usr=
/local/lib32/compat /usr/local/lib32/wine
> <118>Setting hostname: localhost.
> <118>Setting up harvesting:[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHE=
R,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
> <118>Feeding entropy:.
> wlan0: bpf attached
> wlan0: bpf attached
> wlan0: Ethernet address: 00:24:d6:7a:03:ce
> <118>Created wlan(4) interfaces: wlan0.
> <118>Starting dhclient.
> <118>em0: no link .............. giving up
> <118>/etc/rc.d/dhclient: WARNING: failed to start dhclient
> <118>Starting wpa_supplicant.
> <118>Starting dhclient.
> <118>wlan0: no link ...
> iwn0: iwn_read_firmware: ucode rev=3D0x08530501
> <118>.
> panic: lock (sleep mutex) iwn0_com_lock not locked @ /usr/src/sys/dev/iwn=
/if_iwn.c:5356
> cpuid =3D 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff8037d1bb =3D db_trace_self_wrapper+0=
x2b/frame 0xfffffe060ad34850
> vpanic() at 0xffffffff809e9119 =3D vpanic+0x189/frame 0xfffffe060ad348d0
> kassert_panic() at 0xffffffff809e8f82 =3D kassert_panic+0x132/frame 0xfff=
ffe060ad34940
> __mtx_unlock_flags() at 0xffffffff809cd161 =3D __mtx_unlock_flags+0x71/fr=
ame 0xfffffe060ad34980
> iwn_updateedca() at 0xffffffff8058c9da =3D iwn_updateedca+0x15a/frame 0xf=
ffffe060ad349e0
> taskqueue_run_locked() at 0xffffffff80a36ad0 =3D taskqueue_run_locked+0xf=
0/frame 0xfffffe060ad34a40
> taskqueue_thread_loop() at 0xffffffff80a375f8 =3D taskqueue_thread_loop+0=
x88/frame 0xfffffe060ad34a70
> fork_exit() at 0xffffffff809af194 =3D fork_exit+0x84/frame 0xfffffe060ad3=
4ab0
> fork_trampoline() at 0xffffffff80d9a9be =3D fork_trampoline+0xe/frame 0xf=
ffffe060ad34ab0
> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 ---
> KDB: enter: panic
>
> Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /usr=
/lib/debug//boot/kernel/geom_eli.ko.debug...done.
> done.
> Loaded symbols for ...
> ...
> Loaded symbols for /boot/kernel/linprocfs.ko
> #0 doadump (textdump=3D0) at pcpu.h:221
> 221 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0 doadump (textdump=3D0) at pcpu.h:221
> #1 0xffffffff8037af3e in db_dump (dummy=3D<value optimized out>, dummy2=
=3Dfalse,
> dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533
> #2 0xffffffff8037aab1 in db_command (cmd_table=3D0x0)
> at /usr/src/sys/ddb/db_command.c:440
> #3 0xffffffff8037a744 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:493
> #4 0xffffffff8037d2fb in db_trap (type=3D<value optimized out>, code=3D0=
)
> at /usr/src/sys/ddb/db_main.c:251
> #5 0xffffffff80a26264 in kdb_trap (type=3D3, code=3D0, tf=3D<value optim=
ized out>)
> at /usr/src/sys/kern/subr_kdb.c:654
> #6 0xffffffff80dba2c3 in trap (frame=3D0xfffffe060ad34780)
> at /usr/src/sys/amd64/amd64/trap.c:549
> #7 0xffffffff80d9a48a in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:234
> #8 0xffffffff80a2593e in kdb_enter (why=3D0xffffffff812a93ee "panic",
> msg=3D0xffffffff80a2bb90 "UH\211<E5>AWAVATSH\203<EC>PI\211<F7>A\211<F=
E>H\213\004%<D0><E8><A9>\201H\211E<D8>\201<%x<F8><A9>\201") at cpufunc.h:63
> #9 0xffffffff809e9139 in vpanic (fmt=3D<value optimized out>,
> ap=3D<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:746
> #10 0xffffffff809e8f82 in kassert_panic (fmt=3D<value optimized out>)
> at /usr/src/sys/kern/kern_shutdown.c:643
> #11 0xffffffff809cd161 in __mtx_unlock_flags (c=3D0xfffffe03d7ed0070, opt=
s=3D0,
> file=3D0xffffffff80fcedd8 "/usr/src/sys/dev/iwn/if_iwn.c", line=3D535=
6)
> at /usr/src/sys/kern/kern_mutex.c:245
> #12 0xffffffff8058c9da in iwn_updateedca (ic=3D<value optimized out>)
> at /usr/src/sys/dev/iwn/if_iwn.c:5356
> #13 0xffffffff80a36ad0 in taskqueue_run_locked (queue=3D0xfffff80006f6230=
0)
> at /usr/src/sys/kern/subr_taskqueue.c:430
> #14 0xffffffff80a375f8 in taskqueue_thread_loop (arg=3D<value optimized o=
ut>)
> at /usr/src/sys/kern/subr_taskqueue.c:683
> #15 0xffffffff809af194 in fork_exit (
> callout=3D0xffffffff80a37570 <taskqueue_thread_loop>,
> arg=3D0xfffffe03d7ed0118, frame=3D0xfffffe060ad34ac0)
> at /usr/src/sys/kern/kern_fork.c:1006
> #16 0xffffffff80d9a9be in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:609
> #17 0x0000000000000000 in ?? ()
> Current language: auto; currently minimal
> (kgdb)
>
> ------------------------------------------------------------------------
> ps -axlww
>
> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
> 0 0 0 0 -16 0 0 0 swapin DLs - 0:00.00 [kernel]
> 0 1 0 0 20 0 5320 140 wait DLs - 0:00.00 [init]
> 0 2 0 0 -16 0 0 0 - DL - 0:00.00 [rand_harves=
tq]
> 0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto]
> 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto retu=
rns]
> 0 5 0 0 -16 0 0 0 - RL - 0:00.00 [cam]
> 0 6 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterat=
or]
> 0 7 0 0 -16 0 0 0 idle DL - 0:00.00 [enc_daemon0=
]
> 0 8 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon]
> 0 9 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon]
> 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit]
> 0 11 0 0 155 0 0 0 - RL - 0:00.00 [idle]
> 0 12 0 0 -64 0 0 0 - WL - 0:00.00 [intr]
> 0 13 0 0 -8 0 0 0 - DL - 0:00.00 [geom]
> 0 14 0 0 -68 0 0 0 - DL - 0:00.00 [usb]
> 0 15 0 0 -16 0 0 0 tzpoll DL - 0:00.00 [acpi_therma=
l]
> 0 16 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero]
> 0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon]
> 0 18 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer]
> 0 19 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru]
> 0 20 1 0 52 0 13056 2008 wait Ds+ - 0:00.00 [sh]
> 0 192 20 0 52 0 13056 2500 wait D+ - 0:00.00 [sh]
> 0 343 1 0 46 0 20036 6288 - Rs - 0:00.00 [wpa_supplic=
ant]
> 0 346 192 0 52 0 13064 3300 wait D+ - 0:00.00 [sh]
> 0 353 346 0 45 0 10532 2364 nanslp D+ - 0:00.00 [dhclient]
>
> ------------------------------------------------------------------------
>
>
> [Above was the second try (which is why all the fsck output is
> present), and was a verbose boot.]
>
> As I type, vmcore.5 is about half-copied over. I need to relocate
> shortly, so I may end up starting the copy over.
>
> Peace,
> david
> --
> David H. Wolfskill david@catwhisker.org
> Those who would murder in the name of God or prophet are blasphemous cowa=
rds.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
From owner-freebsd-net@freebsd.org Tue Sep 29 22:52:02 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03E12A0C9EC
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 29 Sep 2015 22:52:02 +0000 (UTC)
(envelope-from trtrmitya@gmail.com)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com
[IPv6:2a00:1450:4010:c03::233])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 7E6B31C53
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 22:52:01 +0000 (UTC)
(envelope-from trtrmitya@gmail.com)
Received: by laclj5 with SMTP id lj5so26041491lac.3
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 15:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:content-type:subject:message-id:date:to:mime-version;
bh=ry9gPp9XDRNrqA3T8K0A5KZOxLoTPkCW3ScrOjUbYgc=;
b=seBwvPWZucM9NE+dk0Md/kJm1qB7NrgaIocC7hg8yi9cyarqRw2QBQlt2jRoM5B7a/
3ZuvGT+bCu3eXw9H2XbgQKin9qgtR3kBSkJB5lr8yy9mDw3EG57p5B7qEQUOzoT9NDka
MRmb+jm4MD5cil/f/aRx3y3kFYT/ObA2ugbke/y6MwAQcIoB1IZgitleYi1Ufkbgx2ht
iM5qqEcaqq0y9ECPRkqh1X14hgBrZNYpllQ+ohDsY+Ry6YrUKPorG+6LgtX4ei/02aMn
jY4uvxF9G8CCmIlAi4JeV9bLxcbTUYAkXYE1o0/k1zoMIA3NgmFpyiEgSut9tEP0Rr1l
19Sg==
X-Received: by 10.152.224.130 with SMTP id rc2mr139330lac.116.1443567119096;
Tue, 29 Sep 2015 15:51:59 -0700 (PDT)
Received: from [10.0.1.4] (broadband-5-228-251-240.nationalcablenetworks.ru.
[5.228.251.240])
by smtp.gmail.com with ESMTPSA id j11sm459487lfe.24.2015.09.29.15.51.57
for <freebsd-net@freebsd.org>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 29 Sep 2015 15:51:57 -0700 (PDT)
From: Dmitry Sivachenko <trtrmitya@gmail.com>
Content-Type: multipart/mixed;
boundary="Apple-Mail=_267DA67E-FB01-48D6-857A-D1FE3D23A94B"
Subject: getaddrinfo() question
Message-Id: <F5AD2BAC-7927-46CA-A52C-287685DD4260@gmail.com>
Date: Wed, 30 Sep 2015 01:51:56 +0300
To: FreeBSD Net <freebsd-net@freebsd.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 22:52:02 -0000
--Apple-Mail=_267DA67E-FB01-48D6-857A-D1FE3D23A94B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hello!
I have a machine (FreeBSD-10/stable) with both ipv4 and ipv6 addresses =
configured.
Also I have ip6addrctl_policy=3D"ipv4_prefer" in rc.conf.
I am trying to resolve a hostname which has both A and AAAA records and =
I expect getaddrinfo() to return A record because of ipv4_prefer.
I am running a sample program attached.
When I use hints.ai_flags =3D AI_PASSIVE flag, the program prints =
"AF_INET6" (why?), if I change that line to hints.ai_flags =3D 0; it =
printf "AF_INET" (as expected).
Can you please explain why AI_PASSIVE makes a difference?
On FreeBSD, the manual page is unclear about the behavior when hostname =
is not NULL and AI_PASSIVE is used, but on Linux it explicitly states =
that
"If node is not NULL, then the AI_PASSIVE flag is ignored."
Thanks!
--Apple-Mail=_267DA67E-FB01-48D6-857A-D1FE3D23A94B
Content-Disposition: attachment;
filename=test_getaddrinfo.c
Content-Type: application/octet-stream;
name="test_getaddrinfo.c"
Content-Transfer-Encoding: 7bit
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <string.h>
#include <stdio.h>
int main() {
struct addrinfo hints, *result;
const char* host = "wfe0.ysv.freebsd.org";
memset(&result, 0, sizeof(result));
memset(&hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_PASSIVE;
hints.ai_protocol = 0;
if (getaddrinfo(host, NULL, &hints, &result) == 0) {
switch (result->ai_family) {
case AF_INET:
printf("AF_INET\n");
break;
case AF_INET6:
printf("AF_INET6\n");
break;
}
}
}
--Apple-Mail=_267DA67E-FB01-48D6-857A-D1FE3D23A94B--
From owner-freebsd-net@freebsd.org Tue Sep 29 23:01:48 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42784A0B17D
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 29 Sep 2015 23:01:48 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 2ECDB112D
for <freebsd-net@FreeBSD.org>; Tue, 29 Sep 2015 23:01:48 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8TN1mR4062538
for <freebsd-net@FreeBSD.org>; Tue, 29 Sep 2015 23:01:48 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203422] mpd/ppoe not working with re(4) with revision 285177
Date: Tue, 29 Sep 2015 23:01:48 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.2-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: marius@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-203422-2472-FR8ZZTCdBJ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203422-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203422-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 23:01:48 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203422
--- Comment #2 from Marius Strobl <marius@FreeBSD.org> ---
Created attachment 161553
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161553&action=edit
re_cfg.diff_fix
As I already wrote via e-mail, please give this patch a try.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Tue Sep 29 23:22:51 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E489A0C190
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 29 Sep 2015 23:22:51 +0000 (UTC)
(envelope-from javocado@gmail.com)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com
[IPv6:2a00:1450:4010:c03::22b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id A35481C3B
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 23:22:50 +0000 (UTC)
(envelope-from javocado@gmail.com)
Received: by laclj5 with SMTP id lj5so26600599lac.3
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 16:22:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=q/6OrebTQAv41wcJn/U3q9KQvN5miLw9j5rN9szpf6k=;
b=xrgyGqRTXlzAcEHzmzAuLjj4PpmZw4bMm0xPdCq7f4Bhrjis+pwbw2jYKS+ryTG+iD
F0wcJcU79rD+9HwreZ8ZEh+i0P40NFA8BUavpbvrEvvNEHtSi32jt9ATYr4/QeZmDVkD
8IyIVbmSZD05SrAgw5ly6m+gmXfE00sqsjfh2MHmvaSv0B3UOzf1Ied1YAgDAe4IZehp
0VrsxELqLUL/Ss8Tou+/GnpoyQXIq+sDk8yfNuuzi9+L9mpldFk9uERmW/BfoK37FNxI
ZToW1c9JtsAwUBFvVnKWsCIw6sK7ALn3PnZya1UODZrcXL+OS6+ftqm4d/16qluHCQS5
winA==
MIME-Version: 1.0
X-Received: by 10.152.6.70 with SMTP id y6mr147772lay.101.1443568968058; Tue,
29 Sep 2015 16:22:48 -0700 (PDT)
Received: by 10.114.77.134 with HTTP; Tue, 29 Sep 2015 16:22:48 -0700 (PDT)
Date: Tue, 29 Sep 2015 16:22:48 -0700
Message-ID: <CAP1HOmSMne6YyNGAXS-jDMGoYEsPUYnpRO3dHvrp2qP+Z3btmw@mail.gmail.com>
Subject: Network tuning help needed - asymmetric speed
From: javocado <javocado@gmail.com>
To: freebsd-net@freebsd.org
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 23:22:51 -0000
I am trying to figure out what set of tunables need to be tweaked in order
to get an Internet connection operating at decent speed in _both_
directions. Here are my particulars:
Source: FreeBSD 8.4 AMD
Target: Ubuntu 14.04 x64
Iperf tests:
Source -> Target:
# iperf -t10 -P1 -i1 -c xxxxxxxx
------------------------------------------------------------
Client connecting to xxxxxxxxx, TCP port 5001
TCP window size: 2.16 MByte (default)
------------------------------------------------------------
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 26.4 MBytes 221 Mbits/sec
[ 3] 1.0- 2.0 sec 9.12 MBytes 76.5 Mbits/sec
[ 3] 2.0- 3.0 sec 3.38 MBytes 28.3 Mbits/sec
[ 3] 3.0- 4.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 3] 4.0- 5.0 sec 1.62 MBytes 13.6 Mbits/sec
[ 3] 5.0- 6.0 sec 2.38 MBytes 19.9 Mbits/sec
[ 3] 6.0- 7.0 sec 2.88 MBytes 24.1 Mbits/sec
[ 3] 7.0- 8.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 8.0- 9.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 3] 9.0-10.0 sec 1.88 MBytes 15.7 Mbits/sec
[ 3] 0.0-10.1 sec 53.9 MBytes 44.9 Mbits/sec
subsequent identical iperf tests:
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 3] 1.0- 2.0 sec 3.75 MBytes 31.5 Mbits/sec
[ 3] 2.0- 3.0 sec 6.38 MBytes 53.5 Mbits/sec
[ 3] 3.0- 4.0 sec 2.12 MBytes 17.8 Mbits/sec
[ 3] 4.0- 5.0 sec 3.25 MBytes 27.3 Mbits/sec
[ 3] 5.0- 6.0 sec 4.25 MBytes 35.7 Mbits/sec
[ 3] 6.0- 7.0 sec 1.88 MBytes 15.7 Mbits/sec
[ 3] 7.0- 8.0 sec 4.12 MBytes 34.6 Mbits/sec
[ 3] 8.0- 9.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 9.0-10.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 0.0-10.1 sec 31.8 MBytes 26.4 Mbits/sec
Target -> Source:
# iperf -t10 -P1 -i1 -c xxxxxx
------------------------------------------------------------
Client connecting to xxxxxxxx, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 90.8 MBytes 761 Mbits/sec
[ 3] 1.0- 2.0 sec 104 MBytes 871 Mbits/sec
[ 3] 2.0- 3.0 sec 107 MBytes 900 Mbits/sec
[ 3] 3.0- 4.0 sec 96.0 MBytes 805 Mbits/sec
[ 3] 4.0- 5.0 sec 97.8 MBytes 820 Mbits/sec
[ 3] 5.0- 6.0 sec 102 MBytes 857 Mbits/sec
[ 3] 6.0- 7.0 sec 104 MBytes 873 Mbits/sec
[ 3] 7.0- 8.0 sec 104 MBytes 868 Mbits/sec
[ 3] 8.0- 9.0 sec 104 MBytes 873 Mbits/sec
[ 3] 9.0-10.0 sec 104 MBytes 871 Mbits/sec
[ 3] 0.0-10.0 sec 1014 MBytes 850 Mbits/sec
Traceroutes:
Source -> Target:
traceroute to xxxxxxx 64 hops max, 52 byte packets
1 6.978 ms 1.989 ms 2.002 ms
2 10.954 ms 0.983 ms
1.957 ms
3 52.189 ms 5.998 ms 22.044 ms
4 26.091 ms 22.056 ms 24.017 ms
5 21.492 ms 21.029 ms
6 21.047 ms 21.093 ms 21.998 ms
7 20.897 ms 20.744 ms 23.042 ms
8 20.699 ms 20.655 ms 20.526 ms
Target -> Source:
traceroute to xxxxxx, 30 hops max, 60 byte packets
1 0.782 ms 0.761 ms 0.784 ms
2 1.072 ms 1.028 ms 1.002 ms
3 0.689 ms 0.665 ms 0.796 ms
4 42.513 ms 42.596 ms 42.568 ms
5 0.917 ms 0.895 ms 0.866 ms
6 20.209 ms 28.508 ms 28.507 ms
7 20.346 ms 20.352 ms 20.392 ms
8 30.392 ms 30.404 ms 30.387 ms
9 20.542 ms 20.720 ms 20.899 ms
We thought there could just be a bad hop or perhaps it was hardware at
fault, but when we run our iperf from a different source (a stock Ubuntu
12.04 box) connected to the same switch as the FreeBSD source, we get
great/better/acceptable results:
(Ubuntu 12.04) Source -> Target:
$ iperf -t10 -P1 -i1 -w1M -c xxxxxxx
------------------------------------------------------------
Client connecting to xxxxxxxx, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 1.00 MByte)
------------------------------------------------------------
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 9.25 MBytes 77.6 Mbits/sec
[ 3] 1.0- 2.0 sec 10.2 MBytes 86.0 Mbits/sec
[ 3] 2.0- 3.0 sec 10.6 MBytes 89.1 Mbits/sec
[ 3] 3.0- 4.0 sec 11.1 MBytes 93.3 Mbits/sec
[ 3] 4.0- 5.0 sec 11.2 MBytes 94.4 Mbits/sec
[ 3] 5.0- 6.0 sec 10.8 MBytes 90.2 Mbits/sec
[ 3] 6.0- 7.0 sec 11.5 MBytes 96.5 Mbits/sec
[ 3] 7.0- 8.0 sec 11.2 MBytes 94.4 Mbits/sec
[ 3] 8.0- 9.0 sec 11.0 MBytes 92.3 Mbits/sec
[ 3] 9.0-10.0 sec 11.1 MBytes 93.3 Mbits/sec
[ 3] 0.0-10.0 sec 108 MBytes 90.7 Mbits/sec
So, it would seem that FreeBSD is very well tuned for Target -> Source
traffic (nearly 1Gbps), but the Source -> Target direction is terrible
(20Mbps). Since the RTT is the same and the # of hops is virtually
unchanged, we don't see any reason the speed should be different outbound,
and further we see that when we use Ubuntu -> Target, we get decent speed
(100Mbps). Thus we conclude the hardware and hops must not the issue. So,
what we're missing in our FreeBSD tuning that is making the outbound
transfers so slow (while the inbound transfers are great)?
Thanks
Source settings (FreeBSD):
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
ether xxxxxx
inet xxxxxx netmask 0xfffffff8 broadcast xxxxx
inet6 xxxxx%igb0 prefixlen 64 scopeid 0x1
inet6 xxxxxxx prefixlen 64
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
kern.ipc.maxsockbuf: 16777216
kern.ipc.sockbuf_waste_factor: 8
kern.ipc.somaxconn: 128
kern.ipc.max_linkhdr: 16
kern.ipc.max_protohdr: 60
kern.ipc.max_hdr: 76
kern.ipc.max_datalen: 92
kern.ipc.nmbjumbo16: 3200
kern.ipc.nmbjumbo9: 6400
kern.ipc.nmbjumbop: 12800
kern.ipc.nmbclusters: 25600
kern.ipc.piperesizeallowed: 1
kern.ipc.piperesizefail: 0
kern.ipc.pipeallocfail: 0
kern.ipc.pipefragretry: 0
kern.ipc.pipekva: 21315584
kern.ipc.maxpipekva: 4080218112
kern.ipc.msgseg: 2048
kern.ipc.msgssz: 8
kern.ipc.msgtql: 40
kern.ipc.msgmnb: 2048
kern.ipc.msgmni: 40
kern.ipc.msgmax: 16384
kern.ipc.semaem: 16384
kern.ipc.semvmx: 32767
kern.ipc.semusz: 152
kern.ipc.semume: 10
kern.ipc.semopm: 100
kern.ipc.semmsl: 60
kern.ipc.semmnu: 30
kern.ipc.semmns: 60
kern.ipc.semmni: 10
kern.ipc.semmap: 30
kern.ipc.shm_allow_removed: 0
kern.ipc.shm_use_phys: 0
kern.ipc.shmall: 8192
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 33554432
kern.ipc.maxsockets: 25600
kern.ipc.numopensockets: 1281
kern.ipc.nsfbufsused: 0
kern.ipc.nsfbufspeak: 0
kern.ipc.nsfbufs: 0
net.inet.tcp.rfc1323: 1
net.inet.tcp.mssdflt: 1460
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.sendspace: 2263000
net.inet.tcp.recvspace: 2263000
net.inet.tcp.keepinit: 75000
net.inet.tcp.delacktime: 100
net.inet.tcp.v6mssdflt: 1024
net.inet.tcp.cc.available: newreno
net.inet.tcp.cc.algorithm: newreno
net.inet.tcp.hostcache.purge: 0
net.inet.tcp.hostcache.prune: 300
net.inet.tcp.hostcache.expire: 3600
net.inet.tcp.hostcache.count: 193
net.inet.tcp.hostcache.bucketlimit: 30
net.inet.tcp.hostcache.hashsize: 512
net.inet.tcp.hostcache.cachelimit: 15360
net.inet.tcp.read_locking: 1
net.inet.tcp.recvbuf_max: 16777216
net.inet.tcp.recvbuf_inc: 524288
net.inet.tcp.recvbuf_auto: 1
net.inet.tcp.insecure_rst: 0
net.inet.tcp.ecn.maxretries: 1
net.inet.tcp.ecn.enable: 0
net.inet.tcp.abc_l_var: 2
net.inet.tcp.rfc3465: 1
net.inet.tcp.rfc3390: 1
net.inet.tcp.rfc3042: 1
net.inet.tcp.drop_synfin: 1
net.inet.tcp.delayed_ack: 1
net.inet.tcp.blackhole: 0
net.inet.tcp.log_in_vain: 0
net.inet.tcp.sendbuf_max: 16777216
net.inet.tcp.sendbuf_inc: 16384
net.inet.tcp.sendbuf_auto: 1
net.inet.tcp.tso: 1
net.inet.tcp.local_slowstart_flightsize: 4
net.inet.tcp.slowstart_flightsize: 1550
net.inet.tcp.path_mtu_discovery: 1
net.inet.tcp.reass.overflows: 481332
net.inet.tcp.reass.cursegments: 4
net.inet.tcp.reass.maxsegments: 1680
net.inet.tcp.sack.globalholes: 0
net.inet.tcp.sack.globalmaxholes: 65536
net.inet.tcp.sack.maxholes: 128
net.inet.tcp.sack.enable: 1
net.inet.tcp.inflight.stab: 20
net.inet.tcp.inflight.max: 1073725440
net.inet.tcp.inflight.min: 6144
net.inet.tcp.inflight.rttthresh: 10
net.inet.tcp.inflight.debug: 0
net.inet.tcp.inflight.enable: 0
net.inet.tcp.isn_reseed_interval: 0
net.inet.tcp.icmp_may_rst: 1
net.inet.tcp.pcbcount: 461
net.inet.tcp.do_tcpdrain: 1
net.inet.tcp.tcbhashsize: 512
net.inet.tcp.log_debug: 0
net.inet.tcp.minmss: 216
net.inet.tcp.syncache.rst_on_sock_fail: 1
net.inet.tcp.syncache.rexmtlimit: 3
net.inet.tcp.syncache.hashsize: 512
net.inet.tcp.syncache.count: 4294967277
net.inet.tcp.syncache.cachelimit: 15360
net.inet.tcp.syncache.bucketlimit: 30
net.inet.tcp.syncookies_only: 0
net.inet.tcp.syncookies: 1
net.inet.tcp.timer_race: 1
net.inet.tcp.rexmit_drop_options: 1
net.inet.tcp.finwait2_timeout: 60000
net.inet.tcp.fast_finwait2_recycle: 0
net.inet.tcp.always_keepalive: 1
net.inet.tcp.rexmit_slop: 200
net.inet.tcp.rexmit_min: 30
net.inet.tcp.msl: 30000
net.inet.tcp.nolocaltimewait: 0
net.inet.tcp.maxtcptw: 5120
Target settings (Ubuntu):
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:840363516 errors:0 dropped:0 overruns:0 frame:0
TX packets:152325250 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2086148084848 (2.0 TB) TX bytes:64233189137 (64.2 GB)
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_adv_win_scale = 1
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_autocorking = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_challenge_ack_limit = 100
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_early_retrans = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_fack = 1
net.ipv4.tcp_fastopen = 1
net.ipv4.tcp_fastopen_key = 00000000-00000000-00000000-00000000
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_frto = 2
net.ipv4.tcp_fwmark_accept = 0
net.ipv4.tcp_invalid_ratelimit = 500
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_limit_output_bytes = 131072
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_max_orphans = 32768
net.ipv4.tcp_max_reordering = 300
net.ipv4.tcp_max_syn_backlog = 256
net.ipv4.tcp_max_tw_buckets = 32768
net.ipv4.tcp_mem = 524288 524288 524288
net.ipv4.tcp_min_tso_segs = 2
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_notsent_lowat = -1
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_sack = 1
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_syn_retries = 6
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_thin_dupack = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_workaround_signed_windows = 0
net.core.busy_poll = 0
net.core.busy_read = 0
net.core.default_qdisc = pfifo_fast
net.core.dev_weight = 64
net.core.flow_limit_cpu_bitmap = 00
net.core.flow_limit_table_len = 4096
net.core.message_burst = 10
net.core.message_cost = 5
net.core.netdev_budget = 300
net.core.netdev_max_backlog = 1000
net.core.netdev_tstamp_prequeue = 1
net.core.optmem_max = 20480
net.core.rmem_default = 524288
net.core.rmem_max = 33554432
net.core.rps_sock_flow_entries = 0
net.core.somaxconn = 128
net.core.tstamp_allow_data = 1
net.core.warnings = 0
net.core.wmem_default = 524288
net.core.wmem_max = 33554432
net.core.xfrm_acq_expires = 30
net.core.xfrm_aevent_etime = 10
net.core.xfrm_aevent_rseqth = 2
net.core.xfrm_larval_drop = 1
From owner-freebsd-net@freebsd.org Wed Sep 30 06:10:20 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52A0FA0C102
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 06:10:20 +0000 (UTC)
(envelope-from kob6558@gmail.com)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com
[IPv6:2607:f8b0:4003:c01::233])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 172191A47
for <freebsd-net@freebsd.org>; Wed, 30 Sep 2015 06:10:20 +0000 (UTC)
(envelope-from kob6558@gmail.com)
Received: by obbzf10 with SMTP id zf10so23775477obb.2
for <freebsd-net@freebsd.org>; Tue, 29 Sep 2015 23:10:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=Q6AfJHYnIkwHG3gyAmXjymSOKUvriffDGqBd6fHYfkQ=;
b=M+RV8k6tf5RTxFSBILCBIkk0vfl3Dg59l+px4XHLZX56X9Gr52Y+UgONje2FWSL6bJ
Go+l11rdHKuaDI17LE9piJ60xbzflEXbE/tQ386FkmkgWHG7kwjTgpob7PvcD+K8yB5C
DhJxWtk/4rvnJYQIb7z8fb6lGfRWQ06795t974AB/LmvcwXaXfKrlIustKf35gyrpThM
zML6AuAlLlbf7qF662n47A7bHUoo/sofuX2toZHwdYgb+/N6FB432Iu71KXxPvCjEu0v
MUSRXim127VRTzR+sl9ZjUAYhVv9KlW3+3rIwsBVsn87R2VHV8bduq0vsderf+1n7hBi
TPeQ==
MIME-Version: 1.0
X-Received: by 10.60.47.199 with SMTP id f7mr1137268oen.54.1443593419091; Tue,
29 Sep 2015 23:10:19 -0700 (PDT)
Sender: kob6558@gmail.com
Received: by 10.202.102.9 with HTTP; Tue, 29 Sep 2015 23:10:19 -0700 (PDT)
In-Reply-To: <CAP1HOmSMne6YyNGAXS-jDMGoYEsPUYnpRO3dHvrp2qP+Z3btmw@mail.gmail.com>
References: <CAP1HOmSMne6YyNGAXS-jDMGoYEsPUYnpRO3dHvrp2qP+Z3btmw@mail.gmail.com>
Date: Tue, 29 Sep 2015 23:10:19 -0700
X-Google-Sender-Auth: A8MiCjgbV8f3dRZhAdR6hRjUloM
Message-ID: <CAN6yY1tVQU2Om8kvyz_ueCX-mpbo88PnaE2qSs3CY2W1vS=LMg@mail.gmail.com>
Subject: Re: Network tuning help needed - asymmetric speed
From: Kevin Oberman <rkoberman@gmail.com>
To: javocado <javocado@gmail.com>
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 06:10:20 -0000
On Tue, Sep 29, 2015 at 4:22 PM, javocado <javocado@gmail.com> wrote:
> I am trying to figure out what set of tunables need to be tweaked in order
> to get an Internet connection operating at decent speed in _both_
> directions. Here are my particulars:
>
> Source: FreeBSD 8.4 AMD
> Target: Ubuntu 14.04 x64
>
>
> Iperf tests:
>
> Source -> Target:
>
> # iperf -t10 -P1 -i1 -c xxxxxxxx
> ------------------------------------------------------------
> Client connecting to xxxxxxxxx, TCP port 5001
> TCP window size: 2.16 MByte (default)
> ------------------------------------------------------------
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 26.4 MBytes 221 Mbits/sec
> [ 3] 1.0- 2.0 sec 9.12 MBytes 76.5 Mbits/sec
> [ 3] 2.0- 3.0 sec 3.38 MBytes 28.3 Mbits/sec
> [ 3] 3.0- 4.0 sec 3.88 MBytes 32.5 Mbits/sec
> [ 3] 4.0- 5.0 sec 1.62 MBytes 13.6 Mbits/sec
> [ 3] 5.0- 6.0 sec 2.38 MBytes 19.9 Mbits/sec
> [ 3] 6.0- 7.0 sec 2.88 MBytes 24.1 Mbits/sec
> [ 3] 7.0- 8.0 sec 1.00 MBytes 8.39 Mbits/sec
> [ 3] 8.0- 9.0 sec 1.12 MBytes 9.44 Mbits/sec
> [ 3] 9.0-10.0 sec 1.88 MBytes 15.7 Mbits/sec
> [ 3] 0.0-10.1 sec 53.9 MBytes 44.9 Mbits/sec
>
> subsequent identical iperf tests:
>
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 3.50 MBytes 29.4 Mbits/sec
> [ 3] 1.0- 2.0 sec 3.75 MBytes 31.5 Mbits/sec
> [ 3] 2.0- 3.0 sec 6.38 MBytes 53.5 Mbits/sec
> [ 3] 3.0- 4.0 sec 2.12 MBytes 17.8 Mbits/sec
> [ 3] 4.0- 5.0 sec 3.25 MBytes 27.3 Mbits/sec
> [ 3] 5.0- 6.0 sec 4.25 MBytes 35.7 Mbits/sec
> [ 3] 6.0- 7.0 sec 1.88 MBytes 15.7 Mbits/sec
> [ 3] 7.0- 8.0 sec 4.12 MBytes 34.6 Mbits/sec
> [ 3] 8.0- 9.0 sec 1.25 MBytes 10.5 Mbits/sec
> [ 3] 9.0-10.0 sec 1.00 MBytes 8.39 Mbits/sec
> [ 3] 0.0-10.1 sec 31.8 MBytes 26.4 Mbits/sec
>
>
> Target -> Source:
>
> # iperf -t10 -P1 -i1 -c xxxxxx
> ------------------------------------------------------------
> Client connecting to xxxxxxxx, TCP port 5001
> TCP window size: 64.0 KByte (default)
> ------------------------------------------------------------
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 90.8 MBytes 761 Mbits/sec
> [ 3] 1.0- 2.0 sec 104 MBytes 871 Mbits/sec
> [ 3] 2.0- 3.0 sec 107 MBytes 900 Mbits/sec
> [ 3] 3.0- 4.0 sec 96.0 MBytes 805 Mbits/sec
> [ 3] 4.0- 5.0 sec 97.8 MBytes 820 Mbits/sec
> [ 3] 5.0- 6.0 sec 102 MBytes 857 Mbits/sec
> [ 3] 6.0- 7.0 sec 104 MBytes 873 Mbits/sec
> [ 3] 7.0- 8.0 sec 104 MBytes 868 Mbits/sec
> [ 3] 8.0- 9.0 sec 104 MBytes 873 Mbits/sec
> [ 3] 9.0-10.0 sec 104 MBytes 871 Mbits/sec
> [ 3] 0.0-10.0 sec 1014 MBytes 850 Mbits/sec
>
>
> Traceroutes:
>
> Source -> Target:
>
> traceroute to xxxxxxx 64 hops max, 52 byte packets
> 1 6.978 ms 1.989 ms 2.002 ms
> 2 10.954 ms 0.983 ms
> 1.957 ms
> 3 52.189 ms 5.998 ms 22.044 ms
> 4 26.091 ms 22.056 ms 24.017 ms
> 5 21.492 ms 21.029 ms
> 6 21.047 ms 21.093 ms 21.998 ms
> 7 20.897 ms 20.744 ms 23.042 ms
> 8 20.699 ms 20.655 ms 20.526 ms
>
>
> Target -> Source:
> traceroute to xxxxxx, 30 hops max, 60 byte packets
> 1 0.782 ms 0.761 ms 0.784 ms
> 2 1.072 ms 1.028 ms 1.002 ms
> 3 0.689 ms 0.665 ms 0.796 ms
> 4 42.513 ms 42.596 ms 42.568 ms
> 5 0.917 ms 0.895 ms 0.866 ms
> 6 20.209 ms 28.508 ms 28.507 ms
> 7 20.346 ms 20.352 ms 20.392 ms
> 8 30.392 ms 30.404 ms 30.387 ms
> 9 20.542 ms 20.720 ms 20.899 ms
>
>
> We thought there could just be a bad hop or perhaps it was hardware at
> fault, but when we run our iperf from a different source (a stock Ubuntu
> 12.04 box) connected to the same switch as the FreeBSD source, we get
> great/better/acceptable results:
>
>
> (Ubuntu 12.04) Source -> Target:
>
> $ iperf -t10 -P1 -i1 -w1M -c xxxxxxx
> ------------------------------------------------------------
> Client connecting to xxxxxxxx, TCP port 5001
> TCP window size: 256 KByte (WARNING: requested 1.00 MByte)
> ------------------------------------------------------------
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 9.25 MBytes 77.6 Mbits/sec
> [ 3] 1.0- 2.0 sec 10.2 MBytes 86.0 Mbits/sec
> [ 3] 2.0- 3.0 sec 10.6 MBytes 89.1 Mbits/sec
> [ 3] 3.0- 4.0 sec 11.1 MBytes 93.3 Mbits/sec
> [ 3] 4.0- 5.0 sec 11.2 MBytes 94.4 Mbits/sec
> [ 3] 5.0- 6.0 sec 10.8 MBytes 90.2 Mbits/sec
> [ 3] 6.0- 7.0 sec 11.5 MBytes 96.5 Mbits/sec
> [ 3] 7.0- 8.0 sec 11.2 MBytes 94.4 Mbits/sec
> [ 3] 8.0- 9.0 sec 11.0 MBytes 92.3 Mbits/sec
> [ 3] 9.0-10.0 sec 11.1 MBytes 93.3 Mbits/sec
> [ 3] 0.0-10.0 sec 108 MBytes 90.7 Mbits/sec
>
>
> So, it would seem that FreeBSD is very well tuned for Target -> Source
> traffic (nearly 1Gbps), but the Source -> Target direction is terrible
> (20Mbps). Since the RTT is the same and the # of hops is virtually
> unchanged, we don't see any reason the speed should be different outbound,
> and further we see that when we use Ubuntu -> Target, we get decent speed
> (100Mbps). Thus we conclude the hardware and hops must not the issue. So,
> what we're missing in our FreeBSD tuning that is making the outbound
> transfers so slow (while the inbound transfers are great)?
>
> Thanks
>
> [See original message for the details which I elided]
First, I know that I was able to most data both from and to a FreeBSD
system under v8 over a transcontinental path (San Jose to New York City) at
multi-gigabit rates. It took a bit of tuning, but was not difficult.
I see several possible issues.
What interface are you using There have been performance issues with
drivers on some interfaces. Many are fixed in more recent versions of
FreeBSD. 8.4 is past it's EOL and fixes are not being made any longer.
(Note, I think that this is unlikely, but it is possible.)
It could also be bad hardware. Was the Ubuntu system connected to the same
port using the same cable? Can you boot Ubuntu on the same hardware and
confirm whether it works as well on the same hardware? Unless you can do
this or test an on another system running FreeBSD with the same results,
you really can't exclude hardware as the source of the problem.
Tuning could be an issue. It is hard to tell without a LOT more
information. Collecting data with siftr(4) is quite simple and can provide
very useful data as to exactly what is impacting performance. The man page
describes it and how to run it quite clearly. For lots of tuning
recommendations for truly high performance, see FasterData
<http://fasterdata.es.net/>. Unfortunately, since my retirement five years
ago, I believe that all work has moved to Linux, so there may not be much
specific to FreeBSD.
I can say that, with properly functioning hardware, it was not at all hard
to exceed 900 Mbps on a GigE on FreeBSD 8. I retired before 9 was released,
but I am pretty sure that this would not be a problem on newer versions,
either. I should also admit that, after four years away from dealing with
these issues, I am far less competent than I was, so I may not be as much
help as I would like.
--
Kevin Oberman, Part time goatherd and retired Network Engineer
From owner-freebsd-net@freebsd.org Wed Sep 30 08:39:52 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1929BA0B6BC
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 08:39:52 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 05C3C148D
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 08:39:52 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8U8dp4o052812
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 08:39:51 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 200221] em0 watchdog timeout under load
Date: Wed, 30 Sep 2015 08:39:50 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.1-RELEASE
X-Bugzilla-Keywords: IntelNetworking, needs-qa, patch
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: franco@opnsense.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-200221-2472-v0r6Tnm7bR@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-200221-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-200221-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 08:39:52 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200221
Franco Fichtner <franco@opnsense.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |franco@opnsense.org
--- Comment #19 from Franco Fichtner <franco@opnsense.org> ---
It would be great to have these MFC'd to 10-STABLE, thanks. :)
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Wed Sep 30 12:06:32 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64055A0C422
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 12:06:32 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4F54B1D78
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 12:06:32 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8UC6WrZ021720
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 12:06:32 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and
"panic: sbsndptr: sockbuf _ and mbuf _ clashing"
Date: Wed, 30 Sep 2015 12:06:30 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.1-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: girgen@FreeBSD.org
X-Bugzilla-Status: Open
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-148807-2472-X7J1rIm90m@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-148807-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-148807-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 12:06:32 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807
Palle Girgensohn <girgen@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |girgen@FreeBSD.org
--- Comment #20 from Palle Girgensohn <girgen@FreeBSD.org> ---
Hi,
This seems related? A GENERIC kernel binary installed using freebsd-update, so
I have no WITNESS or KGDB, only standard vanilla kernel.
I have core dumps (2) and a complete core.txt if anyone is interested.
# ifconfig -l
oce0 oce1 lo0
# freebsd-version -k
10.1-RELEASE-p19
# cat /var/crash/core.txt.1
...
Thu Aug 27 15:04:09 CEST 2015
FreeBSD kurs-ap-01 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13
06:54:13 UTC 2015
root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf 0xfffff800b4a36800
clashing
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf 0xfffff800b4a36800
clashing
cpuid = 1
KDB: stack backtrace:
#0 0xffffffff80963000 at kdb_backtrace+0x60
#1 0xffffffff80928125 at panic+0x155
#2 0xffffffff8099c180 at sbdroprecord_locked+0
#3 0xffffffff80ac8c9c at tcp_output+0xdbc
#4 0xffffffff80ac6a95 at tcp_do_segment+0x3045
#5 0xffffffff80ac2e04 at tcp_input+0xd04
#6 0xffffffff80a54fc7 at ip_input+0x97
#7 0xffffffff809f4f73 at swi_net+0x143
#8 0xffffffff808faf4b at intr_event_execute_handlers+0xab
#9 0xffffffff808fb396 at ithread_loop+0x96
#10 0xffffffff808f8b6a at fork_exit+0x9a
#11 0xffffffff80d0b67e at fork_trampoline+0xe
Uptime: 21d0h54m53s
Dumping 2005 out of 32709 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_data.ko.symbols
Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_http.ko.symbols
Reading symbols from /boot/kernel/oce.ko.symbols...done.
Loaded symbols for /boot/kernel/oce.ko.symbols
Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
[root@kurs-ap-01 /home/girgen]# head -n 300 /var/crash/core.txt.1
kurs-ap-01 dumped core - see /var/crash/vmcore.1
Thu Aug 27 15:04:09 CEST 2015
FreeBSD kurs-ap-01 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13
06:54:13 UTC 2015
root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf 0xfffff800b4a36800
clashing
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
panic: sbsndptr: sockbuf 0xfffff80312126c68 and mbuf 0xfffff800b4a36800
clashing
cpuid = 1
KDB: stack backtrace:
#0 0xffffffff80963000 at kdb_backtrace+0x60
#1 0xffffffff80928125 at panic+0x155
#2 0xffffffff8099c180 at sbdroprecord_locked+0
#3 0xffffffff80ac8c9c at tcp_output+0xdbc
#4 0xffffffff80ac6a95 at tcp_do_segment+0x3045
#5 0xffffffff80ac2e04 at tcp_input+0xd04
#6 0xffffffff80a54fc7 at ip_input+0x97
#7 0xffffffff809f4f73 at swi_net+0x143
#8 0xffffffff808faf4b at intr_event_execute_handlers+0xab
#9 0xffffffff808fb396 at ithread_loop+0x96
#10 0xffffffff808f8b6a at fork_exit+0x9a
#11 0xffffffff80d0b67e at fork_trampoline+0xe
Uptime: 21d0h54m53s
Dumping 2005 out of 32709 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_data.ko.symbols
Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_http.ko.symbols
Reading symbols from /boot/kernel/oce.ko.symbols...done.
Loaded symbols for /boot/kernel/oce.ko.symbols
Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
Loaded symbols for /boot/kernel/nullfs.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
#0 doadump (textdump=<value optimized out>) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump (textdump=<value optimized out>) at pcpu.h:219
#1 0xffffffff80927da2 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:452
#2 0xffffffff80928164 in panic (fmt=<value optimized out>)
at /usr/src/sys/kern/kern_shutdown.c:759
#3 0xffffffff8099c180 in sbsndptr (sb=<value optimized out>,
off=<value optimized out>, len=<value optimized out>,
moff=<value optimized out>) at /usr/src/sys/kern/uipc_sockbuf.c:1011
#4 0xffffffff80ac8c9c in tcp_output (tp=0xfffff80312ef5800)
at /usr/src/sys/netinet/tcp_output.c:870
#5 0xffffffff80ac6a95 in tcp_do_segment (m=<value optimized out>,
th=<value optimized out>, so=<value optimized out>,
tp=<value optimized out>, drop_hdrlen=<value optimized out>, tlen=0,
iptos=<value optimized out>, ti_locked=Cannot access memory at address 0x1
)
at /usr/src/sys/netinet/tcp_input.c:3018
#6 0xffffffff80ac2e04 in tcp_input (m=<value optimized out>,
off0=<value optimized out>) at /usr/src/sys/netinet/tcp_input.c:1377
#7 0xffffffff80a54fc7 in ip_input (m=0xfffff800b4516600)
at /usr/src/sys/netinet/ip_input.c:734
#8 0xffffffff809f4f73 in swi_net (arg=0xffffffff81988880)
at /usr/src/sys/net/netisr.c:765
#9 0xffffffff808faf4b in intr_event_execute_handlers (
p=<value optimized out>, ie=0xfffff800093ac600)
at /usr/src/sys/kern/kern_intr.c:1263
#10 0xffffffff808fb396 in ithread_loop (arg=0xfffff80009388e40)
at /usr/src/sys/kern/kern_intr.c:1276
#11 0xffffffff808f8b6a in fork_exit (
callout=0xffffffff808fb300 <ithread_loop>, arg=0xfffff80009388e40,
frame=0xfffffe083c3e3ac0) at /usr/src/sys/kern/kern_fork.c:996
#12 0xffffffff80d0b67e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:606
#13 0x0000000000000000 in ?? ()
Current language: auto; currently minimal
(kgdb)
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Wed Sep 30 12:54:55 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B41BBA0BFAD
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 12:54:55 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::50:5])
by mx1.freebsd.org (Postfix) with ESMTP id 966FC1939
for <freebsd-net@freebsd.org>; Wed, 30 Sep 2015 12:54:55 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: by mailman.ysv.freebsd.org (Postfix)
id 937C1A0BFAB; Wed, 30 Sep 2015 12:54:55 +0000 (UTC)
Delivered-To: net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92CC8A0BFA9;
Wed, 30 Sep 2015 12:54:55 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 3BA721937;
Wed, 30 Sep 2015 12:54:54 +0000 (UTC)
(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id t8UCsrWR042080;
Wed, 30 Sep 2015 05:54:53 -0700 (PDT)
(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
by albert.catwhisker.org (8.15.2/8.15.2/Submit) id t8UCsq6q042079;
Wed, 30 Sep 2015 05:54:52 -0700 (PDT) (envelope-from david)
Date: Wed, 30 Sep 2015 05:54:52 -0700
From: David Wolfskill <david@catwhisker.org>
To: Adrian Chadd <adrian.chadd@gmail.com>
Cc: "current@freebsd.org" <current@freebsd.org>,
"net@freebsd.org" <net@freebsd.org>, wireless@freebsd.org
Subject: Re: head/amd64 @r288358: panic: lock (sleep mutex) iwn0_com_lock not
locked @ /usr/src/sys/dev/iwn/if_iwn.c:5356
Message-ID: <20150930125452.GS1125@albert.catwhisker.org>
Mail-Followup-To: David Wolfskill <david@catwhisker.org>,
Adrian Chadd <adrian.chadd@gmail.com>,
"current@freebsd.org" <current@freebsd.org>,
"net@freebsd.org" <net@freebsd.org>, wireless@freebsd.org
References: <20150929130534.GI1125@albert.catwhisker.org>
<CAJ-Vmo=NESAxpv8X=KPA6EOhnkFcojwSEWYDcAL=tFqq4T3R2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="24bywM+ZyrW0DJoD"
Content-Disposition: inline
In-Reply-To: <CAJ-Vmo=NESAxpv8X=KPA6EOhnkFcojwSEWYDcAL=tFqq4T3R2w@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 12:54:55 -0000
--24bywM+ZyrW0DJoD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Sep 29, 2015 at 12:12:02PM -0700, Adrian Chadd wrote:
> hi
>=20
> (please subscribe and email freebsd-wireless@ these things, I'm more
> likely to notice!)
>=20
> It looks due to my recent taskqueue change for updateedca. I'll go fix
> that today.
>=20
> Thanks,
> ...
Looks as if you did:
FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #199 r2884=
18M/288418:1100079: Wed Sep 30 04:51:56 PDT 2015 root@g1-252.catwhisker=
=2Eorg:/common/S4/obj/usr/src/sys/CANARY amd64
Thanks! :-)
Peace,
david
--=20
David H. Wolfskill david@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous coward=
s.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
--24bywM+ZyrW0DJoD
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJWC9ucXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4
QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7r/8P/0nCmtGe+ad/GBAC9DLmJZfJ
Ru5cvBdi+s8QN8lQ7m+WSxEmiLjvDTzkfmr/Mijtr99BfBRefb2GfJDWhuQVmBvU
J9ucCxElvIUMZ/HtHeyqDaa0ZQnvjKBNxxQAQKY6+Lg0XbMyKuA6c5SFpFofoB+V
ywoP/PCfCUV6kWxBua0jM8KvXzKq/qZoaT1K4dVA08eSaydg0C5iO9zVWJ/fLIv0
aZnCQ2/+P/qyUt86bwnN1ncOevy79h7BxVobhBX+kRy0rhINtqXAY2w4mxKmHel5
OimAcWNkujPv2KWMVJl76RxWcqPBIMJTScVVdnTBQqgHVDntW4319KODMScQn+mB
o9VRdV12QWUILyuuz/SuL9rDB4MHyqsQUo1Z3H5obnE96gTbQg1wG6e3Mf/4XOFj
xX/eUc8460+AtY2H50aiFN5T/4PJ8VuszzFRyhpOy3C+r0pneawmtykv1gZ0PkOb
pa/DB2ilhvJ6RM9d2XWT1ntayhT8cgklaZ47ZBuxE32TZ0lSEJc8pB7cNoadHVqv
yH5y3Z6FQTbsFX2ufBbPc/hr7Ce/XmC3VLCEHFdZHgqTBiPerz3VWkSuw+iFTXLy
/IRv0CtxDkbBiHiGFBU3fP6X5Ie83rrKCnyV9PRw60+vFeoyKAs8c/MvsvYsa+vF
kNii1ic2ls8++ON0kE7d
=zYOS
-----END PGP SIGNATURE-----
--24bywM+ZyrW0DJoD--
From owner-freebsd-net@freebsd.org Wed Sep 30 13:40:40 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0094EA0C0C6
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 13:40:40 +0000 (UTC)
(envelope-from vangyzen@FreeBSD.org)
Received: from smtp.vangyzen.net (hotblack.vangyzen.net
[IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f])
by mx1.freebsd.org (Postfix) with ESMTP id DCDA91021
for <freebsd-net@freebsd.org>; Wed, 30 Sep 2015 13:40:39 +0000 (UTC)
(envelope-from vangyzen@FreeBSD.org)
Received: from marvin.beer.town (unknown [76.164.8.130])
by smtp.vangyzen.net (Postfix) with ESMTPSA id 110CB56483;
Wed, 30 Sep 2015 08:40:33 -0500 (CDT)
Subject: Re: getaddrinfo() question
To: Dmitry Sivachenko <trtrmitya@gmail.com>,
FreeBSD Net <freebsd-net@freebsd.org>
References: <F5AD2BAC-7927-46CA-A52C-287685DD4260@gmail.com>
From: Eric van Gyzen <vangyzen@FreeBSD.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <560BE64C.7090800@FreeBSD.org>
Date: Wed, 30 Sep 2015 08:40:28 -0500
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <F5AD2BAC-7927-46CA-A52C-287685DD4260@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 13:40:40 -0000
On 09/29/2015 17:51, Dmitry Sivachenko wrote:
> Hello!
>
> I have a machine (FreeBSD-10/stable) with both ipv4 and ipv6 addresses configured.
> Also I have ip6addrctl_policy="ipv4_prefer" in rc.conf.
>
> I am trying to resolve a hostname which has both A and AAAA records and I expect getaddrinfo() to return A record because of ipv4_prefer.
>
> I am running a sample program attached.
>
> When I use hints.ai_flags = AI_PASSIVE flag, the program prints "AF_INET6" (why?), if I change that line to hints.ai_flags = 0; it printf "AF_INET" (as expected).
>
> Can you please explain why AI_PASSIVE makes a difference?
>
> On FreeBSD, the manual page is unclear about the behavior when hostname is not NULL and AI_PASSIVE is used, but on Linux it explicitly states that
> "If node is not NULL, then the AI_PASSIVE flag is ignored."
I haven't looked at the code or the RFCs recently, so my reply shouldn't be considered even remotely authoritative, but this behavior makes sense to me. I believe ip6addrctl only applies to active/outgoing connections, since client programs usually don't provide a convenient way to choose the address family. Passive/listening programs are different by nature: they usually provide a way to configure the desired address families, and they usually want to listen on all families by default. By using PF_UNSPEC with AI_PASSIVE, you're saying you want to listen on the given host's addresses, regardless of protocol family/version. If you follow the ai_next pointers, you'll see that you're getting two addrinfo results: AF_INET6 and AF_INET. Since you're going to open passive/listening sockets, the order is irrelevant.
Like I said, though, this is just my interpretation.
Eric
From owner-freebsd-net@freebsd.org Wed Sep 30 15:37:41 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DE5DA0CAEB
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 15:37:41 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::50:5])
by mx1.freebsd.org (Postfix) with ESMTP id 0E7B610C1
for <freebsd-net@freebsd.org>; Wed, 30 Sep 2015 15:37:41 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: by mailman.ysv.freebsd.org (Postfix)
id 0D783A0CAE9; Wed, 30 Sep 2015 15:37:41 +0000 (UTC)
Delivered-To: net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CC33A0CAE7;
Wed, 30 Sep 2015 15:37:41 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com
[IPv6:2607:f8b0:4001:c06::22a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id CCFEF10C0;
Wed, 30 Sep 2015 15:37:40 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: by iow1 with SMTP id 1so14608393iow.1;
Wed, 30 Sep 2015 08:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=PPy1TZUmSfWUaT/axvqai0G7aVtTNhUvZc386/+3edo=;
b=CYdRxyAkOPG9anSLd7jQkKD0+omw+A7kun7SEc76OX7F7LKCcD7B4EfCzqe9HuA7mh
Tf0X5GRMQfetIZwiLNVp1C1Ip6idKZeMzm85aiSGs5prdZSYHAaZUw4hAcCmkk+K5vtK
WQzkZQg3iJL20bZFZEbHXBRK12zyZKam+hZaNOSpy40NCn+gc6yCoC5ZWMwDfrxoCN9d
Qx6eO5M1Ts4EMLsdeEiVhffHruoZvie6QGSRu3WbEd068E7jqZI04YlkERs7UPNyTr1a
/WfMGXK3TyMOilNuR6NrE109o/ZTKcahSzP+rPpmEA9fC3gGb067zL8wa/oQRdN11dYx
mV5Q==
MIME-Version: 1.0
X-Received: by 10.107.46.228 with SMTP id u97mr5147370iou.165.1443627460222;
Wed, 30 Sep 2015 08:37:40 -0700 (PDT)
Received: by 10.36.46.15 with HTTP; Wed, 30 Sep 2015 08:37:40 -0700 (PDT)
In-Reply-To: <20150930125452.GS1125@albert.catwhisker.org>
References: <20150929130534.GI1125@albert.catwhisker.org>
<CAJ-Vmo=NESAxpv8X=KPA6EOhnkFcojwSEWYDcAL=tFqq4T3R2w@mail.gmail.com>
<20150930125452.GS1125@albert.catwhisker.org>
Date: Wed, 30 Sep 2015 08:37:40 -0700
Message-ID: <CAJ-VmonCG23VHHi85ywZ_vJKYSQZd8j+LWDyw=8W3aiuVC93JA@mail.gmail.com>
Subject: Re: head/amd64 @r288358: panic: lock (sleep mutex) iwn0_com_lock not
locked @ /usr/src/sys/dev/iwn/if_iwn.c:5356
From: Adrian Chadd <adrian.chadd@gmail.com>
To: David Wolfskill <david@catwhisker.org>,
Adrian Chadd <adrian.chadd@gmail.com>,
"current@freebsd.org" <current@freebsd.org>,
"net@freebsd.org" <net@freebsd.org>,
"freebsd-wireless@freebsd.org" <wireless@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 15:37:41 -0000
Thanks for being quick and on the ball. I did another review of the
drivers to see which others needed fixing and luckily it was only
if_iwn.
-a
On 30 September 2015 at 05:54, David Wolfskill <david@catwhisker.org> wrote:
> On Tue, Sep 29, 2015 at 12:12:02PM -0700, Adrian Chadd wrote:
>> hi
>>
>> (please subscribe and email freebsd-wireless@ these things, I'm more
>> likely to notice!)
>>
>> It looks due to my recent taskqueue change for updateedca. I'll go fix
>> that today.
>>
>> Thanks,
>> ...
>
> Looks as if you did:
>
> FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #199 r288418M/288418:1100079: Wed Sep 30 04:51:56 PDT 2015 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64
>
> Thanks! :-)
>
> Peace,
> david
> --
> David H. Wolfskill david@catwhisker.org
> Those who would murder in the name of God or prophet are blasphemous cowards.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
From owner-freebsd-net@freebsd.org Wed Sep 30 15:48:14 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82D55A0B332
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 15:48:14 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 6F9921997
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 15:48:14 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8UFmEpl064535
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 15:48:14 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203422] mpd/ppoe not working with re(4) with revision 285177
Date: Wed, 30 Sep 2015 15:48:14 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.2-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: lab@gta.com
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-203422-2472-MUzf12bBt2@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203422-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203422-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 15:48:14 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203422
--- Comment #3 from lab@gta.com ---
This patch allows PPPoE to work with both RealTech chipsets I have that use the
re(4) driver.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Wed Sep 30 17:32:18 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 994AFA0B52E
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 17:32:18 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com
[IPv6:2607:f8b0:4001:c05::231])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 65C291D39
for <freebsd-net@freebsd.org>; Wed, 30 Sep 2015 17:32:18 +0000 (UTC)
(envelope-from adrian.chadd@gmail.com)
Received: by igcpb10 with SMTP id pb10so110811923igc.1
for <freebsd-net@freebsd.org>; Wed, 30 Sep 2015 10:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=70YbcGeuEpNX18+WZ1zsIK3BhARqyN3L401NTBWzlqo=;
b=DbJZAKr6LknaRfAlT7CMEvK4BUlE+xE6Sf2gHIrkUgRo24BtcniEU1SL8dHQRw3oNh
bO4KGPxQgUD7CJ40DMTMGCRjLVHN+aHsDyCnZZKo3bgD5/2Nlzsvizesn13oAXM1p1+z
dFsMp6RbrFlmZRraX/Bud/TqMii0erePLaBknjkI1DTnGZKieccLJAsZIh7UpPXFVJ2s
OdD9MuR+hAHG25NvILMBg17zPjn4L1i4OVoFiimXOJZIO5zO8w5LkpyL+XovtnChbp50
W6bjuNB+IfQHFJPAndleltKyYeKALxPR2KaRGdtxj9xP34Qwwu8lqzn9wPcGdD1PeiFz
ZIzQ==
MIME-Version: 1.0
X-Received: by 10.50.61.243 with SMTP id t19mr3277868igr.22.1443634337622;
Wed, 30 Sep 2015 10:32:17 -0700 (PDT)
Received: by 10.36.46.15 with HTTP; Wed, 30 Sep 2015 10:32:17 -0700 (PDT)
In-Reply-To: <CAP1HOmSMne6YyNGAXS-jDMGoYEsPUYnpRO3dHvrp2qP+Z3btmw@mail.gmail.com>
References: <CAP1HOmSMne6YyNGAXS-jDMGoYEsPUYnpRO3dHvrp2qP+Z3btmw@mail.gmail.com>
Date: Wed, 30 Sep 2015 10:32:17 -0700
Message-ID: <CAJ-Vmom77oj=oZNukiXzjVQ1tHcfLcFFCo9hjkz73iaAu3BEoQ@mail.gmail.com>
Subject: Re: Network tuning help needed - asymmetric speed
From: Adrian Chadd <adrian.chadd@gmail.com>
To: javocado <javocado@gmail.com>
Cc: FreeBSD Net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 17:32:18 -0000
hi,,
Please retry with freebsd-head or freebsd stable/10. Bugs keep being
fixed every day in those drivers. :)
-a
On 29 September 2015 at 16:22, javocado <javocado@gmail.com> wrote:
> I am trying to figure out what set of tunables need to be tweaked in order
> to get an Internet connection operating at decent speed in _both_
> directions. Here are my particulars:
>
> Source: FreeBSD 8.4 AMD
> Target: Ubuntu 14.04 x64
>
>
> Iperf tests:
>
> Source -> Target:
>
> # iperf -t10 -P1 -i1 -c xxxxxxxx
> ------------------------------------------------------------
> Client connecting to xxxxxxxxx, TCP port 5001
> TCP window size: 2.16 MByte (default)
> ------------------------------------------------------------
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 26.4 MBytes 221 Mbits/sec
> [ 3] 1.0- 2.0 sec 9.12 MBytes 76.5 Mbits/sec
> [ 3] 2.0- 3.0 sec 3.38 MBytes 28.3 Mbits/sec
> [ 3] 3.0- 4.0 sec 3.88 MBytes 32.5 Mbits/sec
> [ 3] 4.0- 5.0 sec 1.62 MBytes 13.6 Mbits/sec
> [ 3] 5.0- 6.0 sec 2.38 MBytes 19.9 Mbits/sec
> [ 3] 6.0- 7.0 sec 2.88 MBytes 24.1 Mbits/sec
> [ 3] 7.0- 8.0 sec 1.00 MBytes 8.39 Mbits/sec
> [ 3] 8.0- 9.0 sec 1.12 MBytes 9.44 Mbits/sec
> [ 3] 9.0-10.0 sec 1.88 MBytes 15.7 Mbits/sec
> [ 3] 0.0-10.1 sec 53.9 MBytes 44.9 Mbits/sec
>
> subsequent identical iperf tests:
>
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 3.50 MBytes 29.4 Mbits/sec
> [ 3] 1.0- 2.0 sec 3.75 MBytes 31.5 Mbits/sec
> [ 3] 2.0- 3.0 sec 6.38 MBytes 53.5 Mbits/sec
> [ 3] 3.0- 4.0 sec 2.12 MBytes 17.8 Mbits/sec
> [ 3] 4.0- 5.0 sec 3.25 MBytes 27.3 Mbits/sec
> [ 3] 5.0- 6.0 sec 4.25 MBytes 35.7 Mbits/sec
> [ 3] 6.0- 7.0 sec 1.88 MBytes 15.7 Mbits/sec
> [ 3] 7.0- 8.0 sec 4.12 MBytes 34.6 Mbits/sec
> [ 3] 8.0- 9.0 sec 1.25 MBytes 10.5 Mbits/sec
> [ 3] 9.0-10.0 sec 1.00 MBytes 8.39 Mbits/sec
> [ 3] 0.0-10.1 sec 31.8 MBytes 26.4 Mbits/sec
>
>
> Target -> Source:
>
> # iperf -t10 -P1 -i1 -c xxxxxx
> ------------------------------------------------------------
> Client connecting to xxxxxxxx, TCP port 5001
> TCP window size: 64.0 KByte (default)
> ------------------------------------------------------------
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 90.8 MBytes 761 Mbits/sec
> [ 3] 1.0- 2.0 sec 104 MBytes 871 Mbits/sec
> [ 3] 2.0- 3.0 sec 107 MBytes 900 Mbits/sec
> [ 3] 3.0- 4.0 sec 96.0 MBytes 805 Mbits/sec
> [ 3] 4.0- 5.0 sec 97.8 MBytes 820 Mbits/sec
> [ 3] 5.0- 6.0 sec 102 MBytes 857 Mbits/sec
> [ 3] 6.0- 7.0 sec 104 MBytes 873 Mbits/sec
> [ 3] 7.0- 8.0 sec 104 MBytes 868 Mbits/sec
> [ 3] 8.0- 9.0 sec 104 MBytes 873 Mbits/sec
> [ 3] 9.0-10.0 sec 104 MBytes 871 Mbits/sec
> [ 3] 0.0-10.0 sec 1014 MBytes 850 Mbits/sec
>
>
> Traceroutes:
>
> Source -> Target:
>
> traceroute to xxxxxxx 64 hops max, 52 byte packets
> 1 6.978 ms 1.989 ms 2.002 ms
> 2 10.954 ms 0.983 ms
> 1.957 ms
> 3 52.189 ms 5.998 ms 22.044 ms
> 4 26.091 ms 22.056 ms 24.017 ms
> 5 21.492 ms 21.029 ms
> 6 21.047 ms 21.093 ms 21.998 ms
> 7 20.897 ms 20.744 ms 23.042 ms
> 8 20.699 ms 20.655 ms 20.526 ms
>
>
> Target -> Source:
> traceroute to xxxxxx, 30 hops max, 60 byte packets
> 1 0.782 ms 0.761 ms 0.784 ms
> 2 1.072 ms 1.028 ms 1.002 ms
> 3 0.689 ms 0.665 ms 0.796 ms
> 4 42.513 ms 42.596 ms 42.568 ms
> 5 0.917 ms 0.895 ms 0.866 ms
> 6 20.209 ms 28.508 ms 28.507 ms
> 7 20.346 ms 20.352 ms 20.392 ms
> 8 30.392 ms 30.404 ms 30.387 ms
> 9 20.542 ms 20.720 ms 20.899 ms
>
>
> We thought there could just be a bad hop or perhaps it was hardware at
> fault, but when we run our iperf from a different source (a stock Ubuntu
> 12.04 box) connected to the same switch as the FreeBSD source, we get
> great/better/acceptable results:
>
>
> (Ubuntu 12.04) Source -> Target:
>
> $ iperf -t10 -P1 -i1 -w1M -c xxxxxxx
> ------------------------------------------------------------
> Client connecting to xxxxxxxx, TCP port 5001
> TCP window size: 256 KByte (WARNING: requested 1.00 MByte)
> ------------------------------------------------------------
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 9.25 MBytes 77.6 Mbits/sec
> [ 3] 1.0- 2.0 sec 10.2 MBytes 86.0 Mbits/sec
> [ 3] 2.0- 3.0 sec 10.6 MBytes 89.1 Mbits/sec
> [ 3] 3.0- 4.0 sec 11.1 MBytes 93.3 Mbits/sec
> [ 3] 4.0- 5.0 sec 11.2 MBytes 94.4 Mbits/sec
> [ 3] 5.0- 6.0 sec 10.8 MBytes 90.2 Mbits/sec
> [ 3] 6.0- 7.0 sec 11.5 MBytes 96.5 Mbits/sec
> [ 3] 7.0- 8.0 sec 11.2 MBytes 94.4 Mbits/sec
> [ 3] 8.0- 9.0 sec 11.0 MBytes 92.3 Mbits/sec
> [ 3] 9.0-10.0 sec 11.1 MBytes 93.3 Mbits/sec
> [ 3] 0.0-10.0 sec 108 MBytes 90.7 Mbits/sec
>
>
> So, it would seem that FreeBSD is very well tuned for Target -> Source
> traffic (nearly 1Gbps), but the Source -> Target direction is terrible
> (20Mbps). Since the RTT is the same and the # of hops is virtually
> unchanged, we don't see any reason the speed should be different outbound,
> and further we see that when we use Ubuntu -> Target, we get decent speed
> (100Mbps). Thus we conclude the hardware and hops must not the issue. So,
> what we're missing in our FreeBSD tuning that is making the outbound
> transfers so slow (while the inbound transfers are great)?
>
> Thanks
>
>
>
> Source settings (FreeBSD):
>
> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
> ether xxxxxx
> inet xxxxxx netmask 0xfffffff8 broadcast xxxxx
> inet6 xxxxx%igb0 prefixlen 64 scopeid 0x1
> inet6 xxxxxxx prefixlen 64
> nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
> media: Ethernet autoselect (1000baseT <full-duplex>)
> status: active
>
> kern.ipc.maxsockbuf: 16777216
> kern.ipc.sockbuf_waste_factor: 8
> kern.ipc.somaxconn: 128
> kern.ipc.max_linkhdr: 16
> kern.ipc.max_protohdr: 60
> kern.ipc.max_hdr: 76
> kern.ipc.max_datalen: 92
> kern.ipc.nmbjumbo16: 3200
> kern.ipc.nmbjumbo9: 6400
> kern.ipc.nmbjumbop: 12800
> kern.ipc.nmbclusters: 25600
> kern.ipc.piperesizeallowed: 1
> kern.ipc.piperesizefail: 0
> kern.ipc.pipeallocfail: 0
> kern.ipc.pipefragretry: 0
> kern.ipc.pipekva: 21315584
> kern.ipc.maxpipekva: 4080218112
> kern.ipc.msgseg: 2048
> kern.ipc.msgssz: 8
> kern.ipc.msgtql: 40
> kern.ipc.msgmnb: 2048
> kern.ipc.msgmni: 40
> kern.ipc.msgmax: 16384
> kern.ipc.semaem: 16384
> kern.ipc.semvmx: 32767
> kern.ipc.semusz: 152
> kern.ipc.semume: 10
> kern.ipc.semopm: 100
> kern.ipc.semmsl: 60
> kern.ipc.semmnu: 30
> kern.ipc.semmns: 60
> kern.ipc.semmni: 10
> kern.ipc.semmap: 30
> kern.ipc.shm_allow_removed: 0
> kern.ipc.shm_use_phys: 0
> kern.ipc.shmall: 8192
> kern.ipc.shmseg: 128
> kern.ipc.shmmni: 192
> kern.ipc.shmmin: 1
> kern.ipc.shmmax: 33554432
> kern.ipc.maxsockets: 25600
> kern.ipc.numopensockets: 1281
> kern.ipc.nsfbufsused: 0
> kern.ipc.nsfbufspeak: 0
> kern.ipc.nsfbufs: 0
> net.inet.tcp.rfc1323: 1
> net.inet.tcp.mssdflt: 1460
> net.inet.tcp.keepidle: 7200000
> net.inet.tcp.keepintvl: 75000
> net.inet.tcp.sendspace: 2263000
> net.inet.tcp.recvspace: 2263000
> net.inet.tcp.keepinit: 75000
> net.inet.tcp.delacktime: 100
> net.inet.tcp.v6mssdflt: 1024
> net.inet.tcp.cc.available: newreno
> net.inet.tcp.cc.algorithm: newreno
> net.inet.tcp.hostcache.purge: 0
> net.inet.tcp.hostcache.prune: 300
> net.inet.tcp.hostcache.expire: 3600
> net.inet.tcp.hostcache.count: 193
> net.inet.tcp.hostcache.bucketlimit: 30
> net.inet.tcp.hostcache.hashsize: 512
> net.inet.tcp.hostcache.cachelimit: 15360
> net.inet.tcp.read_locking: 1
> net.inet.tcp.recvbuf_max: 16777216
> net.inet.tcp.recvbuf_inc: 524288
> net.inet.tcp.recvbuf_auto: 1
> net.inet.tcp.insecure_rst: 0
> net.inet.tcp.ecn.maxretries: 1
> net.inet.tcp.ecn.enable: 0
> net.inet.tcp.abc_l_var: 2
> net.inet.tcp.rfc3465: 1
> net.inet.tcp.rfc3390: 1
> net.inet.tcp.rfc3042: 1
> net.inet.tcp.drop_synfin: 1
> net.inet.tcp.delayed_ack: 1
> net.inet.tcp.blackhole: 0
> net.inet.tcp.log_in_vain: 0
> net.inet.tcp.sendbuf_max: 16777216
> net.inet.tcp.sendbuf_inc: 16384
> net.inet.tcp.sendbuf_auto: 1
> net.inet.tcp.tso: 1
> net.inet.tcp.local_slowstart_flightsize: 4
> net.inet.tcp.slowstart_flightsize: 1550
> net.inet.tcp.path_mtu_discovery: 1
> net.inet.tcp.reass.overflows: 481332
> net.inet.tcp.reass.cursegments: 4
> net.inet.tcp.reass.maxsegments: 1680
> net.inet.tcp.sack.globalholes: 0
> net.inet.tcp.sack.globalmaxholes: 65536
> net.inet.tcp.sack.maxholes: 128
> net.inet.tcp.sack.enable: 1
> net.inet.tcp.inflight.stab: 20
> net.inet.tcp.inflight.max: 1073725440
> net.inet.tcp.inflight.min: 6144
> net.inet.tcp.inflight.rttthresh: 10
> net.inet.tcp.inflight.debug: 0
> net.inet.tcp.inflight.enable: 0
> net.inet.tcp.isn_reseed_interval: 0
> net.inet.tcp.icmp_may_rst: 1
> net.inet.tcp.pcbcount: 461
> net.inet.tcp.do_tcpdrain: 1
> net.inet.tcp.tcbhashsize: 512
> net.inet.tcp.log_debug: 0
> net.inet.tcp.minmss: 216
> net.inet.tcp.syncache.rst_on_sock_fail: 1
> net.inet.tcp.syncache.rexmtlimit: 3
> net.inet.tcp.syncache.hashsize: 512
> net.inet.tcp.syncache.count: 4294967277
> net.inet.tcp.syncache.cachelimit: 15360
> net.inet.tcp.syncache.bucketlimit: 30
> net.inet.tcp.syncookies_only: 0
> net.inet.tcp.syncookies: 1
> net.inet.tcp.timer_race: 1
> net.inet.tcp.rexmit_drop_options: 1
> net.inet.tcp.finwait2_timeout: 60000
> net.inet.tcp.fast_finwait2_recycle: 0
> net.inet.tcp.always_keepalive: 1
> net.inet.tcp.rexmit_slop: 200
> net.inet.tcp.rexmit_min: 30
> net.inet.tcp.msl: 30000
> net.inet.tcp.nolocaltimewait: 0
> net.inet.tcp.maxtcptw: 5120
>
>
> Target settings (Ubuntu):
>
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:840363516 errors:0 dropped:0 overruns:0 frame:0
> TX packets:152325250 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2086148084848 (2.0 TB) TX bytes:64233189137 (64.2 GB)
>
> net.ipv4.tcp_abort_on_overflow = 0
> net.ipv4.tcp_adv_win_scale = 1
> net.ipv4.tcp_allowed_congestion_control = cubic reno
> net.ipv4.tcp_app_win = 31
> net.ipv4.tcp_autocorking = 1
> net.ipv4.tcp_available_congestion_control = cubic reno
> net.ipv4.tcp_base_mss = 512
> net.ipv4.tcp_challenge_ack_limit = 100
> net.ipv4.tcp_congestion_control = cubic
> net.ipv4.tcp_dsack = 1
> net.ipv4.tcp_early_retrans = 3
> net.ipv4.tcp_ecn = 2
> net.ipv4.tcp_fack = 1
> net.ipv4.tcp_fastopen = 1
> net.ipv4.tcp_fastopen_key = 00000000-00000000-00000000-00000000
> net.ipv4.tcp_fin_timeout = 60
> net.ipv4.tcp_frto = 2
> net.ipv4.tcp_fwmark_accept = 0
> net.ipv4.tcp_invalid_ratelimit = 500
> net.ipv4.tcp_keepalive_intvl = 75
> net.ipv4.tcp_keepalive_probes = 9
> net.ipv4.tcp_keepalive_time = 7200
> net.ipv4.tcp_limit_output_bytes = 131072
> net.ipv4.tcp_low_latency = 0
> net.ipv4.tcp_max_orphans = 32768
> net.ipv4.tcp_max_reordering = 300
> net.ipv4.tcp_max_syn_backlog = 256
> net.ipv4.tcp_max_tw_buckets = 32768
> net.ipv4.tcp_mem = 524288 524288 524288
> net.ipv4.tcp_min_tso_segs = 2
> net.ipv4.tcp_moderate_rcvbuf = 1
> net.ipv4.tcp_mtu_probing = 0
> net.ipv4.tcp_no_metrics_save = 0
> net.ipv4.tcp_notsent_lowat = -1
> net.ipv4.tcp_orphan_retries = 0
> net.ipv4.tcp_reordering = 3
> net.ipv4.tcp_retrans_collapse = 1
> net.ipv4.tcp_retries1 = 3
> net.ipv4.tcp_retries2 = 15
> net.ipv4.tcp_rfc1337 = 0
> net.ipv4.tcp_rmem = 4096 87380 16777216
> net.ipv4.tcp_sack = 1
> net.ipv4.tcp_slow_start_after_idle = 1
> net.ipv4.tcp_stdurg = 0
> net.ipv4.tcp_syn_retries = 6
> net.ipv4.tcp_synack_retries = 5
> net.ipv4.tcp_syncookies = 0
> net.ipv4.tcp_thin_dupack = 0
> net.ipv4.tcp_thin_linear_timeouts = 0
> net.ipv4.tcp_timestamps = 1
> net.ipv4.tcp_tso_win_divisor = 3
> net.ipv4.tcp_tw_recycle = 0
> net.ipv4.tcp_tw_reuse = 0
> net.ipv4.tcp_window_scaling = 1
> net.ipv4.tcp_wmem = 4096 65536 16777216
> net.ipv4.tcp_workaround_signed_windows = 0
> net.core.busy_poll = 0
> net.core.busy_read = 0
> net.core.default_qdisc = pfifo_fast
> net.core.dev_weight = 64
> net.core.flow_limit_cpu_bitmap = 00
> net.core.flow_limit_table_len = 4096
> net.core.message_burst = 10
> net.core.message_cost = 5
> net.core.netdev_budget = 300
> net.core.netdev_max_backlog = 1000
> net.core.netdev_tstamp_prequeue = 1
> net.core.optmem_max = 20480
> net.core.rmem_default = 524288
> net.core.rmem_max = 33554432
> net.core.rps_sock_flow_entries = 0
> net.core.somaxconn = 128
> net.core.tstamp_allow_data = 1
> net.core.warnings = 0
> net.core.wmem_default = 524288
> net.core.wmem_max = 33554432
> net.core.xfrm_acq_expires = 30
> net.core.xfrm_aevent_etime = 10
> net.core.xfrm_aevent_rseqth = 2
> net.core.xfrm_larval_drop = 1
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
From owner-freebsd-net@freebsd.org Wed Sep 30 23:11:00 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A53DAA0CF1D
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 30 Sep 2015 23:11:00 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 91A5118AC
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 23:11:00 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8UNB0Tp056999
for <freebsd-net@FreeBSD.org>; Wed, 30 Sep 2015 23:11:00 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203445] Receive side scaling (RSS) for more than 16 queues not
working in "ixl" driver
Date: Wed, 30 Sep 2015 23:11:00 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords: IntelNetworking
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to keywords
Message-ID: <bug-203445-2472-qFdAtrgDGX@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 23:11:00 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203445
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
Keywords| |IntelNetworking
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Thu Oct 1 01:07:38 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D354FA0DB36
for <freebsd-net@mailman.ysv.freebsd.org>;
Thu, 1 Oct 2015 01:07:38 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id BFDD21135
for <freebsd-net@FreeBSD.org>; Thu, 1 Oct 2015 01:07:38 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t9117cTq031640
for <freebsd-net@FreeBSD.org>; Thu, 1 Oct 2015 01:07:38 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203445] Receive side scaling (RSS) for more than 16 queues not
working in "ixl" driver
Date: Thu, 01 Oct 2015 01:07:38 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords: IntelNetworking
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: erj@freebsd.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-203445-2472-Z8OdUEEIKK@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 01:07:38 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203445
--- Comment #1 from Eric Joyner <erj@freebsd.org> ---
So it looks like the hash is being used to index into the HLUT, but the
resulting queue is then mod 16.
To illustrate:
HLUT(45): 0x24252627 (where bits 21:16 contain LUT entry 4*45+2) and a packet
received on queue 5 has a hash of 0xa33600b6 in its RX descriptor. According to
the HLUT, it should really have gone to queue 37.
This is really odd.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Thu Oct 1 02:11:39 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32315A0D363
for <freebsd-net@mailman.ysv.freebsd.org>;
Thu, 1 Oct 2015 02:11:39 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 1E8801032
for <freebsd-net@FreeBSD.org>; Thu, 1 Oct 2015 02:11:39 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t912Bc2O082962
for <freebsd-net@FreeBSD.org>; Thu, 1 Oct 2015 02:11:38 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203445] Receive side scaling (RSS) for more than 16 queues not
working in "ixl" driver
Date: Thu, 01 Oct 2015 02:11:39 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords: IntelNetworking
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: erj@freebsd.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-203445-2472-vL6sZBILkJ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 02:11:39 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203445
--- Comment #2 from Eric Joyner <erj@freebsd.org> ---
Try replacing the line
ctxt.info.tc_mapping[0] = 0x0800
with
ctxt.info.tc_mapping[0] = 0x0c00
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Thu Oct 1 03:39:41 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDB13A0BA11
for <freebsd-net@mailman.ysv.freebsd.org>;
Thu, 1 Oct 2015 03:39:41 +0000 (UTC)
(envelope-from sonsechang@gmail.com)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com
[IPv6:2607:f8b0:400e:c03::22b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id AF53F17E1
for <freebsd-net@freebsd.org>; Thu, 1 Oct 2015 03:39:41 +0000 (UTC)
(envelope-from sonsechang@gmail.com)
Received: by pacex6 with SMTP id ex6so60338670pac.0
for <freebsd-net@freebsd.org>; Wed, 30 Sep 2015 20:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:date:subject:from:to:message-id:thread-topic
:mime-version:content-type;
bh=PiNdKEPa536sVn4AZCp8vagANzbVgFC9pv9tGq75c00=;
b=KaO8h40BM6QaSZJBw/+0EQrimitQpw/sBok2KZrVuKe3UFeruRSwHcpZGou379hfKy
pza+bz03EBdyIrwsgvANn/MHTecopHaYYRhcHQrQj6j9uX0ceRvGaDeBqt+1VKGy75It
CSJvr7Cal1JdfXaoR6Vy3oU+NnnANR2U/X+EfK/XV38+/pSA9h/ukAPiyBENx8ILGZEq
GCSzDlmiiNpQ5TMa9OktExd0aLZ2DjEZ01Eo0/fkfAJaGOCSO76+WD4MyOkVc5/dCAab
vv7s/7WmiNqS+MGp4wTcrFC6YV0OAoIByJ6koBmNLlkT4KZ5ZdYW6dXTw6xDvZYtqavA
bSTQ==
X-Received: by 10.68.68.233 with SMTP id z9mr9271461pbt.132.1443670781265;
Wed, 30 Sep 2015 20:39:41 -0700 (PDT)
Received: from [10.55.77.148] (nat-198-95-226-236.netapp.com. [198.95.226.236])
by smtp.gmail.com with ESMTPSA id so4sm3389487pbc.72.2015.09.30.20.39.38
for <freebsd-net@freebsd.org> (version=TLSv1/SSLv3 cipher=OTHER);
Wed, 30 Sep 2015 20:39:40 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.4.150722
Date: Wed, 30 Sep 2015 23:39:34 -0400
Subject: routine that configure 127.0.0.1
From: Sechang Son <sonsechang@gmail.com>
To: freebsd-net <freebsd-net@freebsd.org>
Message-ID: <D2322336.4E9A1%sonsechang@gmail.com>
Thread-Topic: routine that configure 127.0.0.1
Mime-version: 1.0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 03:39:42 -0000
Hi,
Can somebody tell me the name of the routine that configures 127.0.0.1 to
loif of Vnet=8Bi.e., V_loif? I checked =8Cvnet_loif_init=B9 but it does not seem
to be doing that=8A Thanks a lot.
=8BSonny
From owner-freebsd-net@freebsd.org Thu Oct 1 07:22:52 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AE25A0DF6D
for <freebsd-net@mailman.ysv.freebsd.org>;
Thu, 1 Oct 2015 07:22:52 +0000 (UTC)
(envelope-from daemon-user@freebsd.org)
Received: from phabric-backend.isc.freebsd.org
(phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2])
by mx1.freebsd.org (Postfix) with ESMTP id 8756D12E9
for <freebsd-net@freebsd.org>; Thu, 1 Oct 2015 07:22:52 +0000 (UTC)
(envelope-from daemon-user@freebsd.org)
Received: by phabric-backend.isc.freebsd.org (Postfix, from userid 1346)
id 841C5331FB2B; Thu, 1 Oct 2015 07:22:52 +0000 (UTC)
Date: Thu, 1 Oct 2015 07:22:52 +0000
To: freebsd-net@freebsd.org
From: "lakshmi.n_msystechnologies.com (LN)" <phabric-noreply@FreeBSD.org>
Reply-to: D1986+325+381818416dc12ca2@reviews.freebsd.org
Subject: [Differential] [Commented On] D1986: Teach lagg(4) to change MTU
Message-ID: <6fc6c359fa75c7ac51a52c10fda12fad@localhost.localdomain>
X-Priority: 3
X-Phabricator-Sent-This-Message: Yes
X-Mail-Transport-Agent: MetaMTA
X-Auto-Response-Suppress: All
X-Phabricator-Mail-Tags: <differential-cc>, <differential-comment>
Thread-Topic: D1986: Teach lagg(4) to change MTU
X-Herald-Rules: none
X-Phabricator-To: <PHID-USER-gxjszcyr3icxaytfydyu>
X-Phabricator-To: <PHID-USER-vtlauz4uwe46gac4fu2j>
X-Phabricator-Cc: <PHID-USER-m472qpdkxj722xbzguun>
X-Phabricator-Cc: <PHID-USER-axkijn4pfdxlezgbnt7g>
X-Phabricator-Cc: <PHID-USER-e73re76ob52gi4vjprnd>
X-Phabricator-Cc: <PHID-USER-dyyyzfp34mimhzvg33tk>
Precedence: bulk
In-Reply-To: <differential-rev-PHID-DREV-i34kfg4qpajia7fo5u5l-req@FreeBSD.org>
References: <differential-rev-PHID-DREV-i34kfg4qpajia7fo5u5l-req@FreeBSD.org>
Thread-Index: ODZhMzNlYThiYzMxOTgzYmRhMDE5M2Q2Yzk4IFYM30w=
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 07:22:52 -0000
lakshmi.n_msystechnologies.com added a subscriber: lakshmi.n_msystechnologies.com.
lakshmi.n_msystechnologies.com added a comment.
We (Panasas) tried reproducing the problem by applying the patch and enabled WITNESS in freebsd stable (10.1) kernel.
While testing with this patched kernel, LOR not observed on ixl and igb ports.
Based on the LOR logs mentioned earlier, the issue seems to be observed on device specific driver like em (e1000).
We tried doing code analysis on em driver and could not find anything obvious. Our platform do not use em driver anymore.
The issue seems to be on device specific driver and not the lagg driver changes that we introduced.
So, we kindly request you to accept these changes to mainline.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D1986
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: rpokala-panasas.com, rstone
Cc: lakshmi.n_msystechnologies.com, emaste, ae, freebsd-net-list
From owner-freebsd-net@freebsd.org Thu Oct 1 08:22:05 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B911DA08AAE
for <freebsd-net@mailman.ysv.freebsd.org>;
Thu, 1 Oct 2015 08:22:05 +0000 (UTC)
(envelope-from bu7cher@yandex.ru)
Received: from forward13j.cmail.yandex.net (forward13j.cmail.yandex.net
[IPv6:2a02:6b8:0:1630::b3])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "forwards.mail.yandex.net",
Issuer "Certum Level IV CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 6B45E177C
for <freebsd-net@freebsd.org>; Thu, 1 Oct 2015 08:22:05 +0000 (UTC)
(envelope-from bu7cher@yandex.ru)
Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191])
by forward13j.cmail.yandex.net (Yandex) with ESMTP id A3762216F6;
Thu, 1 Oct 2015 11:21:53 +0300 (MSK)
Received: from smtp12.mail.yandex.net (localhost [127.0.0.1])
by smtp12.mail.yandex.net (Yandex) with ESMTP id 4713616A0A26;
Thu, 1 Oct 2015 11:21:53 +0300 (MSK)
Received: by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id
DVggMDjncp-LqHaVrVh; Thu, 1 Oct 2015 11:21:52 +0300
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client certificate not present)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
t=1443687712; bh=0zuAwfvWeeyHaDRa5E6edKLK5umOxDHw2k2YKK1qTzY=;
h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:
References:In-Reply-To:Content-Type;
b=U5pHnG9y6ahELgPBmUh0dctqL6hT+aRoIj7+M0x4KB6QXYu6/PuhXaCBfP3iSM5VY
nMYmFCB+VNHncTstM/g+koYRFlMzWdT1Ah9wUjJ35k93P0r27Grp5fvwJSdyZzMcYh
Qp0VkYdzz3N2+isSGdszM2xaaGg+6oV56QvKEEWQ=
Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@yandex.ru
X-Yandex-ForeignMX: US
Message-ID: <560CECDE.8090602@yandex.ru>
Date: Thu, 01 Oct 2015 11:20:46 +0300
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Sechang Son <sonsechang@gmail.com>, freebsd-net <freebsd-net@freebsd.org>
Subject: Re: routine that configure 127.0.0.1
References: <D2322336.4E9A1%sonsechang@gmail.com>
In-Reply-To: <D2322336.4E9A1%sonsechang@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="7uTtcHGjIJdstDeFRQAO46MQ60GaHcHE9"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 08:22:05 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--7uTtcHGjIJdstDeFRQAO46MQ60GaHcHE9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 01.10.2015 06:39, Sechang Son wrote:
> Hi,
>=20
> Can somebody tell me the name of the routine that configures 127.0.0.1 =
to
> loif of Vnet=8Bi.e., V_loif? I checked =8Cvnet_loif_init=B9 but it does=
not seem
> to be doing that=8A Thanks a lot.
It is ipv4_up() from /etc/network.subr.
--=20
WBR, Andrey V. Elsukov
--7uTtcHGjIJdstDeFRQAO46MQ60GaHcHE9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJWDOzeAAoJEAHF6gQQyKF6PQMH/j+spiMmVKY/m6cuo24ioqrg
SavuvsWXnN3/565pzAOGAL5585aEDZqcW7Ob3r0eQ71UtPvXnPyNsddbPhepKU1t
Egi32EGYO4SUNh0JbZTYBymMMkyXnev9jO/45bGrkuS74v9YpHM1L0ocRBeDUh6v
wLqvElu/gNx5UOk9qh3YkEiQS2waJJFVwlu6jo/hr8C4sFc2MG+kVnHnCmsMe+ZF
70cUiprjStHxrL0XFEB8V+yPjipGF2p8AHvI5Vl7+mxllaDlCeNo9DsI15ZkNeIt
A+3UwChY+h0B1oLIOcPa1LAGZXpepOK2FPgJL4j03BOaHYoSVmjwLeKbomWAN80=
=dylm
-----END PGP SIGNATURE-----
--7uTtcHGjIJdstDeFRQAO46MQ60GaHcHE9--
From owner-freebsd-net@freebsd.org Thu Oct 1 10:52:57 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5580A0DE56
for <freebsd-net@mailman.ysv.freebsd.org>;
Thu, 1 Oct 2015 10:52:56 +0000 (UTC)
(envelope-from rizzo.unipi@gmail.com)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com
[IPv6:2a00:1450:4010:c04::234])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 70E621197
for <freebsd-net@freebsd.org>; Thu, 1 Oct 2015 10:52:56 +0000 (UTC)
(envelope-from rizzo.unipi@gmail.com)
Received: by lbos8 with SMTP id s8so6786128lbo.0
for <freebsd-net@freebsd.org>; Thu, 01 Oct 2015 03:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:date:message-id:subject:from:to:content-type;
bh=O7VPn75LdqKLW/Gl4wDx/d9sNycHQRGnH1+E4iBBLKA=;
b=gxnhfafd/+JsU3lITOeQHoCGmqjpvfLUEusHRo5SPjLpu3F6XghevgTRpcTJL2esiZ
COhetVd1BJ6Jec0m/rR42Sywq2polajXfhTv/KS7HrB9gGeB1gK2ElbW/dpvf4JRXuo0
PNFh8xLG+Eo8/WjXn5aP7wGICWktvmhTYo6fVISZXjPu4EGYd0+DdfqIOzujyygLpgQg
nllmbuH9zgj/JKU4f4UNxfGmQi4+deu2KdhIdfiMphXtGs8DaEuO/wJHqIgCpYq2/kBR
aHfH3m5Q/ZnF+Sx1qE6PcSU/g9kBPJzUhH1w5rL4bepYEO06Be1wZUSDUvarKxCN+EBa
/JDA==
MIME-Version: 1.0
X-Received: by 10.112.13.136 with SMTP id h8mr2591257lbc.23.1443696773507;
Thu, 01 Oct 2015 03:52:53 -0700 (PDT)
Sender: rizzo.unipi@gmail.com
Received: by 10.114.96.168 with HTTP; Thu, 1 Oct 2015 03:52:53 -0700 (PDT)
Date: Thu, 1 Oct 2015 12:52:53 +0200
X-Google-Sender-Auth: 8ucFRaT_0fs1DVhPiLktQ6wt2fA
Message-ID: <CA+hQ2+hmT_7KtYRYQzFPo=V3AbfBv97QTExY5xLDdOdaKya41w@mail.gmail.com>
Subject: RFC: revising netmap ring initialization
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 10:52:57 -0000
I would like people's suggestions on the following
=E2=80=8B topic.=E2=80=8B
Right now, on enteringng netmap mode on a NIC we do an ifconfig
down, flush the tx and rx queues, and replace the rx buffers with
the netmap ones. Similarly, on exit, we down the interface, flush
queues and restore the mbufs/skbufs. The annoying side effect is
that in this way the link goes down and sometimes it takes a long
time for autonegotiation and/or spanning tree to restore connectivity.
I was thinking of a different way, as follows (i omit the locking
requirements):
1. always keep the interface active and the mbufs associated to the
NIC rings as allocated by the network stack, whether or not the
interface is in normal or netmap mode;
2. when entering netmap mode just record the new operating mode (in
turn redirecting the interrupt handlers to use the netmap routines
rather than the usual *txeof(), *rxeof() ), and set the ring indexes
according to the state of the ring (ie. pending tx mbufs are reported
as unavailable);
3. the *_rxsync() routine in each driver will track which slots are
still using mbufs (initially, all of them). When an incoming packet
is in an mbuf, *_rxsync() will copy the payload in the netmap buffer,
and mark the slot as a standard netmap bufffer for the future.
After one round through the ring, all buffers will be standard
netmap and there is no copy anymore.
4. on the tx side things are even simpler, all it takes is to
do an m_freem() of completed tx mbufs and then mark the slots
as available. Here again, after one round there is no overhead
anymore.
5. when switching out of netmap mode things are a bit trickier,
because we cannot release immediately the netmap buffers that are
under processing, so we should add special code in the
standard *txeof()/*rxeof() to report when the netmap buffers
are not in use anymore. The code changes in the standard
driver should be relatively simple, but the annoying thing is
that we cannot free the netmap buffers on detach.
For the tx side we could just loop shortly until
the tx queue has been drained., which should happen quickly.
For the rx side, however, we cannot tell when we will receive
incoming traffic and reclaiming a buffer that is already in
the rx engine may require a ring reset.
So, any comment on the above, especially on the last issue ?
cheers
luigi
From owner-freebsd-net@freebsd.org Thu Oct 1 15:44:31 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B67DA0D4D5
for <freebsd-net@mailman.ysv.freebsd.org>;
Thu, 1 Oct 2015 15:44:31 +0000 (UTC)
(envelope-from daemon-user@freebsd.org)
Received: from phabric-backend.isc.freebsd.org
(phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2])
by mx1.freebsd.org (Postfix) with ESMTP id 36C4412D8
for <freebsd-net@freebsd.org>; Thu, 1 Oct 2015 15:44:31 +0000 (UTC)
(envelope-from daemon-user@freebsd.org)
Received: by phabric-backend.isc.freebsd.org (Postfix, from userid 1346)
id 32F2D331F8C8; Thu, 1 Oct 2015 15:44:31 +0000 (UTC)
Date: Thu, 1 Oct 2015 15:44:31 +0000
To: freebsd-net@freebsd.org
From: "sbruno (Sean Bruno)" <phabric-noreply@FreeBSD.org>
Reply-to: D1986+325+381818416dc12ca2@reviews.freebsd.org
Subject: [Differential] [Commented On] D1986: Teach lagg(4) to change MTU
Message-ID: <ee7bacf92ca53d865ece444c6bccd65b@localhost.localdomain>
X-Priority: 3
X-Phabricator-Sent-This-Message: Yes
X-Mail-Transport-Agent: MetaMTA
X-Auto-Response-Suppress: All
X-Phabricator-Mail-Tags: <differential-cc>, <differential-comment>
Thread-Topic: D1986: Teach lagg(4) to change MTU
X-Herald-Rules: none
X-Phabricator-To: <PHID-USER-gxjszcyr3icxaytfydyu>
X-Phabricator-To: <PHID-USER-vtlauz4uwe46gac4fu2j>
X-Phabricator-Cc: <PHID-USER-u62wa6uhdoiyjmodxchd>
X-Phabricator-Cc: <PHID-USER-m472qpdkxj722xbzguun>
X-Phabricator-Cc: <PHID-USER-axkijn4pfdxlezgbnt7g>
X-Phabricator-Cc: <PHID-USER-e73re76ob52gi4vjprnd>
X-Phabricator-Cc: <PHID-USER-dyyyzfp34mimhzvg33tk>
Precedence: bulk
In-Reply-To: <differential-rev-PHID-DREV-i34kfg4qpajia7fo5u5l-req@FreeBSD.org>
References: <differential-rev-PHID-DREV-i34kfg4qpajia7fo5u5l-req@FreeBSD.org>
Thread-Index: ODZhMzNlYThiYzMxOTgzYmRhMDE5M2Q2Yzk4IFYNVN8=
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 15:44:31 -0000
sbruno added a subscriber: sbruno.
sbruno added a comment.
In https://reviews.freebsd.org/D1986#77466, @lakshmi.n_msystechnologies.com wrote:
> We (Panasas) tried reproducing the problem by applying the patch and enabled WITNESS in freebsd stable (10.1) kernel.
> While testing with this patched kernel, LOR not observed on ixl and igb ports.
>
> Based on the LOR logs mentioned earlier, the issue seems to be observed on device specific driver like em (e1000).
> We tried doing code analysis on em driver and could not find anything obvious. Our platform do not use em driver anymore.
>
> The issue seems to be on device specific driver and not the lagg driver changes that we introduced.
> So, we kindly request you to accept these changes to mainline.
lem_ioctl() at lem_ioctl+0x3e8/frame 0xfffffe00003f87e0
This actually means sys/dev/e1000/if_lem.c ... I'll take a look at the LOR and see if its fixable.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D1986
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: rpokala-panasas.com, rstone
Cc: sbruno, lakshmi.n_msystechnologies.com, emaste, ae, freebsd-net-list
From owner-freebsd-net@freebsd.org Fri Oct 2 02:02:49 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A940FA0E651
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 02:02:49 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 956961328
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 02:02:49 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t9222nRM087353
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 02:02:49 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 200221] em0 watchdog timeout under load
Date: Fri, 02 Oct 2015 02:02:49 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.1-RELEASE
X-Bugzilla-Keywords: IntelNetworking, needs-qa, patch
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: koobs@FreeBSD.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: mfc-stable10?
X-Bugzilla-Changed-Fields: flagtypes.name
Message-ID: <bug-200221-2472-AFoB1MpY66@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-200221-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-200221-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 02:02:49 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200221
Kubilay Kocak <koobs@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |mfc-stable10?
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Fri Oct 2 04:01:50 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96101A0D3AF
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 04:01:50 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 82784179D
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 04:01:50 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t9241ohl060923
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 04:01:50 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203476] [net] [igb] not optimal checksum processing
Date: Fri, 02 Oct 2015 04:01:50 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.2-STABLE
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to keywords
Message-ID: <bug-203476-2472-Feytssw8Gu@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203476-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203476-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 04:01:50 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203476
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
Keywords| |patch
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Fri Oct 2 05:23:47 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5EA4A0CF87
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 05:23:47 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 0F7091E15
for <freebsd-net@freebsd.org>; Fri, 2 Oct 2015 05:23:46 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from admin.sibptus.TOMSK.ru ([212.73.125.240] verified)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 38887866 for freebsd-net@freebsd.org;
Fri, 02 Oct 2015 11:23:43 +0600
Received: from admin.sibptus.TOMSK.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.TOMSK.ru (8.14.9/8.14.7) with ESMTP id t925NgQ5017508
for <freebsd-net@freebsd.org>; Fri, 2 Oct 2015 11:23:43 +0600 (NOVT)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.TOMSK.ru (8.14.9/8.14.7/Submit) id t925NgU3017507
for freebsd-net@freebsd.org; Fri, 2 Oct 2015 11:23:42 +0600 (NOVT)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.TOMSK.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Fri, 2 Oct 2015 11:23:42 +0600
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: freebsd-net@freebsd.org
Subject: Beware: FreeBSD-SA-15:24.rpcbind broke my NIS servers
Message-ID: <20151002052342.GA16707@admin.sibptus.tomsk.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: OAO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.5.24 (2015-08-30)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 05:23:47 -0000
Dear Colleagues,
The installation of FreeBSD-SA-15:24.rpcbind broke my NIS servers. The
NIS clients cannot bind to them any more.
"freebsd-update rollback" helped. Don't know the reason yet, but beware.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru
From owner-freebsd-net@freebsd.org Fri Oct 2 10:08:08 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9270A0E1FA;
Fri, 2 Oct 2015 10:08:08 +0000 (UTC)
(envelope-from kp@vega.codepro.be)
Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
bits))
(Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 95FF41825;
Fri, 2 Oct 2015 10:08:08 +0000 (UTC)
(envelope-from kp@vega.codepro.be)
Received: from vega.codepro.be (unknown [172.16.1.3])
by venus.codepro.be (Postfix) with ESMTP id CF743B40F;
Fri, 2 Oct 2015 12:08:05 +0200 (CEST)
Received: by vega.codepro.be (Postfix, from userid 1001)
id C8174FE9F; Fri, 2 Oct 2015 12:08:05 +0200 (CEST)
Date: Fri, 2 Oct 2015 12:08:05 +0200
From: Kristof Provost <kp@FreeBSD.org>
To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org
Subject: pf+TSO patch
Message-ID: <20151002100805.GL3433@vega.codepro.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Checked-By-NSA: Probably
User-Agent: Mutt/1.5.23 (2014-03-12)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 10:08:08 -0000
Hi,
I've found a little time to look at the pf TSO issue (which made pf
unusable on Xen VMs, like Amazon EC2).
I've posted the patch here:
https://reviews.freebsd.org/D3779
It still needs a bit more testing, but so far it looks good.
I'd be very grateful for any brave souls who want to give this a try.
This work was very kindly sponsored by RootBSD (rootbsd.net).
Regards,
Kristof
From owner-freebsd-net@freebsd.org Fri Oct 2 10:28:09 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCEEFA0D500
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 10:28:09 +0000 (UTC)
(envelope-from andrej.fil@gmail.com)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com
[IPv6:2a00:1450:400c:c05::234])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4ED481458;
Fri, 2 Oct 2015 10:28:09 +0000 (UTC)
(envelope-from andrej.fil@gmail.com)
Received: by wiclk2 with SMTP id lk2so27467795wic.0;
Fri, 02 Oct 2015 03:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-type;
bh=9FkEMJCL70zDsW2t58YXuXCFoJ8njzurr0KQ8eMKTug=;
b=HlDSH2sx1xsYyGxyF8aSMJR+l8hQ65EC0ztcb1g7kaDQx4scGJQgCOFXusGMCl7La7
lPOEtHzOOFUS/K5F8/e41Ng37g4VmwdYtxcPDhojcSL2FrChlcQGxDdxfGHYLydrkD4y
5vdZe8WpXcYloUyBn1PYWX2bQ/FI3LJfuL7UdemkLaSGcGf1aTdeQ4MDHms6qtPSdIWm
bHjpB2xgNpFdl3hQuwNRLFpfCNvkoBXMLDeN991L42mGFaHwNP9JAXJONMlgD5pvzkMk
Uqmqa5n7x6F++RLYvoM81GOTvZjpFymHm6LFDBFY7YbZ/l58rD+BpmGtezRVMdhz6mcJ
FQ0Q==
X-Received: by 10.180.182.84 with SMTP id ec20mr3706139wic.42.1443781687907;
Fri, 02 Oct 2015 03:28:07 -0700 (PDT)
Received: from [192.168.0.2]
(host11-165-static.60-79-b.business.telecomitalia.it. [79.60.165.11])
by smtp.gmail.com with ESMTPSA id jq10sm10583772wjc.40.2015.10.02.03.28.06
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 02 Oct 2015 03:28:07 -0700 (PDT)
Subject: Re: pf+TSO patch
To: Kristof Provost <kp@FreeBSD.org>, freebsd-net@freebsd.org
References: <20151002100805.GL3433@vega.codepro.be>
From: Sossi Andrej <andrej.fil@gmail.com>
Message-ID: <560E5C3C.8070709@gmail.com>
Date: Fri, 2 Oct 2015 12:28:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20151002100805.GL3433@vega.codepro.be>
Content-Type: multipart/mixed; boundary="------------020200060902000506070200"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 10:28:09 -0000
This is a multi-part message in MIME format.
--------------020200060902000506070200
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Kristof Provost je 02. 10. 2015 ob 12:08 napisal:
> Hi,
>
> I've found a little time to look at the pf TSO issue (which made pf
> unusable on Xen VMs, like Amazon EC2).
>
> I've posted the patch here:
> https://reviews.freebsd.org/D3779
> [...]
Thank you for your patch.
I have a similar problem but using ipfw. My issue is described in detail
in the attached message. You thing it is the same case?
Thank you in advance for your reply.
--------------020200060902000506070200
Content-Type: message/rfc822;
name="=?UTF-8?Q?Pripeto_sporo=c4=8dilo?="
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*=UTF-8''%50%72%69%70%65%74%6F%20%73%70%6F%72%6F%C4%8D%69%6C%6F
X-Mozilla-Keys:
Message-ID: <5587F8F7.2000700@dotcom.ts.it>
Date: Mon, 22 Jun 2015 14:00:55 +0200
From: Andrej Sossi <asossi@dotcom.ts.it>
Organization: DOTCOM S.R.L.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: Strange problem with TCP checksum
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hello,
I have a weird network problem which I believe may be caused by the
FreeBSD igb driver or perhaps even the network adapter.
Let me try to explain the scenario in brief:
I have a FreeBSD 10.0-RELEASE-p10 server with a public IP address, in
which N virtual machines are installed through JAIL; the machines hold
private IP addresses on the loopback1 adapter. The VMs access the
internet through NATting on the public IP via ipfw:
nat 1 config ip X.Y.Z.W if igb0 unreg_only same_ports
add 60000 nat 1 ip from 192.168.250.0/24 to any out xmit igb0 keep-state
add 60001 nat 1 ip from any to X.Y.Z.W in recv igb0
In addition, port forwarding is configured on the real machine towards
the VMs in order to support public services (Apache httpd, database, etc.)
The network adapter is:
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
ether 00:45:80:dd:32:30
inet X.Y.Z.W netmask 0xffffff00 broadcast X.Y.Z.W
inet6 XX::YY:ZZ:WWW:VVV%igb0 prefixlen 64 scopeid 0x1
inet6 XX:YY:ZZ:WWW::1 prefixlen 64
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
The loopback1 adapter, where the VMs' IPs are assigned, too, has MTU 1500.
So far so good, in the sense that everything works as expected, almost.
Occasionally there are requests originated by the VMs towards internet
servers which end in timeout (http, sftp, etc.). The very same requests,
if executed by the real machine, end correctly with a response.
After countless experiments I have managed to reproduce the problem
deterministically.
Through a tcpdump executed on the request's recipient I have noticed
that all TCP packets with a payload between 101 e 106 (inclusive)
bytes in size arrive with a wrong TCP checksum and as such are rejected.
Subsequent retransmissions of the same packet continue to bear a wrong
checksum
and this continues until the connection timeout is reached. The IP
checksum, instead, is always correct. Packets smaller than 101 bytes are
transmitted and received with the correct checksum, as the same happens
to packets with a payload in excess of 116 bytes in size.
If TXCSUM is disabled, the problem disappears.
The same problem I have on second server with same configuration and
hardware bat with FreeBSD 10.0-RELEASE-p1 .
I believe the above behavior is something error with the driver, as on
a third machine, with identical configuration with jail machines NATting
but with an em driver, the checksum problem didn't appear.
--
Cordiali saluti
Sossi Andrej
-------------------------
DOTCOM Information technology
Via Machiavelli, 28
34132 - Trieste (TS)
Italy
tel: +39 040 9828090
fax: +39 040 0641954
E-mail: asossi@dotcom.ts.it
----------------------------
Ai sensi del D.lgs n. 196 del 30.06.03 (Codice Privacy) si precisa che
le informazioni contenute in questo messaggio sono riservate e ad uso
esclusivo del destinatario. Qualora il messaggio in parola Le fosse
pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non
inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie
This message, for the D.lgs n. 196 / 30.06.03 (Privacy Code), may
contain confidential and/or privileged information. If you are not the
addressee or authorized to receive this for the addressee, you must not
use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please
advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
--------------020200060902000506070200--
From owner-freebsd-net@freebsd.org Fri Oct 2 11:24:51 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1B88A0ECF0
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 11:24:51 +0000 (UTC)
(envelope-from kp@vega.codepro.be)
Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
bits))
(Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 9B4611DE4
for <freebsd-net@freebsd.org>; Fri, 2 Oct 2015 11:24:51 +0000 (UTC)
(envelope-from kp@vega.codepro.be)
Received: from vega.codepro.be (unknown [172.16.1.3])
by venus.codepro.be (Postfix) with ESMTP id 0A543B5B4;
Fri, 2 Oct 2015 13:24:49 +0200 (CEST)
Received: by vega.codepro.be (Postfix, from userid 1001)
id 0439DFF01; Fri, 2 Oct 2015 13:24:48 +0200 (CEST)
Date: Fri, 2 Oct 2015 13:24:48 +0200
From: Kristof Provost <kp@FreeBSD.org>
To: Sossi Andrej <andrej.fil@gmail.com>
Cc: freebsd-net@freebsd.org
Subject: Re: pf+TSO patch
Message-ID: <20151002112448.GM3433@vega.codepro.be>
References: <20151002100805.GL3433@vega.codepro.be>
<560E5C3C.8070709@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <560E5C3C.8070709@gmail.com>
X-Checked-By-NSA: Probably
User-Agent: Mutt/1.5.23 (2014-03-12)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 11:24:51 -0000
On 2015-10-02 12:28:12 (+0200), Sossi Andrej <andrej.fil@gmail.com> wrote:
> I have a similar problem but using ipfw. My issue is described in detail
> in the attached message. You thing it is the same case?
>
> Thank you in advance for your reply.
I think it might be a different problem. The issue with PF mostly occurs
with large packets (because it's triggered by TSO).
This seems to only happen with very specific packet sizes, which is
quite interesting. It'd be very useful to know if this also happens
with other network cards.
Can you create a bug report on https://bugs.freebsd.org/bugzilla/ ?
Regards,
Kristof
From owner-freebsd-net@freebsd.org Fri Oct 2 12:01:42 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3963DA0E27F
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 12:01:42 +0000 (UTC)
(envelope-from andrej.fil@gmail.com)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com
[IPv6:2a00:1450:400c:c05::234])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id C7EE517C7;
Fri, 2 Oct 2015 12:01:41 +0000 (UTC)
(envelope-from andrej.fil@gmail.com)
Received: by wiclk2 with SMTP id lk2so27956505wic.1;
Fri, 02 Oct 2015 05:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to:content-type:content-transfer-encoding;
bh=r7/orhJwtOrgLFlH1YYdGtcyW4ZZagtVFXcWWttnXL0=;
b=GLD6Vvdu7dd1/iro7NfdQuyvJh2zK+n/SszPoA0dPAfeMdmDzDsgNxrPPWLx3nsu6a
usHFfMuxER9bQie/tz7kvuduOVFaoAVZavJbc/+auNja7w+AAOzrq++ADhkjDmDp0wHR
rUYKTD7yCKooZCTMIVdjZUQuKmAi9YeYAYSZYwEKATGoZdyDl+UzQrtOZYnVxQGMB7Vc
upnZFBuJyXG7VNootoo9dnapyMnRjeLAEbd8SudWRQyPXyVjx586G1K4rgUHw2dIlIee
bV98z0m6J+Rz6GJNKSGb1U0RkKZ0rPXTyaiQf/fbpwH1frD0x1iZ/CvLWLYpvil7KxOj
kkXg==
X-Received: by 10.180.198.48 with SMTP id iz16mr4195350wic.63.1443787300372;
Fri, 02 Oct 2015 05:01:40 -0700 (PDT)
Received: from [192.168.0.2]
(host11-165-static.60-79-b.business.telecomitalia.it. [79.60.165.11])
by smtp.gmail.com with ESMTPSA id wc12sm8044801wic.18.2015.10.02.05.01.39
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 02 Oct 2015 05:01:39 -0700 (PDT)
Subject: Re: pf+TSO patch
To: Kristof Provost <kp@FreeBSD.org>
References: <20151002100805.GL3433@vega.codepro.be>
<560E5C3C.8070709@gmail.com> <20151002112448.GM3433@vega.codepro.be>
Cc: freebsd-net@freebsd.org
From: Sossi Andrej <andrej.fil@gmail.com>
Message-ID: <560E7228.2020000@gmail.com>
Date: Fri, 2 Oct 2015 14:01:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20151002112448.GM3433@vega.codepro.be>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 12:01:42 -0000
Kristof Provost je 02. 10. 2015 ob 13:24 napisal:
> On 2015-10-02 12:28:12 (+0200), Sossi Andrej <andrej.fil@gmail.com> wrote:
>> I have a similar problem but using ipfw. My issue is described in detail
>> in the attached message. You thing it is the same case?
>>
>> Thank you in advance for your reply.
>
> I think it might be a different problem. The issue with PF mostly occurs
> with large packets (because it's triggered by TSO).
>
> This seems to only happen with very specific packet sizes, which is
> quite interesting. It'd be very useful to know if this also happens
> with other network cards.
>
> Can you create a bug report on https://bugs.freebsd.org/bugzilla/ ?
No, I no open a bug. I' don't know if it is a bug of driver or ipfw or
jail virtualization. I wrote only a message on the net-list and to
original writer (freebsd@intel.com), but i don't receive any reply.
I want to do other tests to determinate more precisely nature of bug,
but servers who I reproduce the problem is a production server (!) and I
have no time (!!!) to do this. Sorry.
From owner-freebsd-net@freebsd.org Fri Oct 2 15:52:36 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93E99A0ED95
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 15:52:36 +0000 (UTC)
(envelope-from ricera10@gmail.com)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com
[IPv6:2607:f8b0:400d:c04::22b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 5192519E1;
Fri, 2 Oct 2015 15:52:36 +0000 (UTC)
(envelope-from ricera10@gmail.com)
Received: by qgt47 with SMTP id 47so98070868qgt.2;
Fri, 02 Oct 2015 08:52:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=OGDQ4yJyHmtxe/8Xnu00NRYkukeFN5r9TfNO0QSspHI=;
b=Go0VXSlm6B4Hv9qK10MB1cMS9o0uvtuu82BbkIgsChLGFE9rDsD4Gn1j2FTV7lmHRT
nPH92WRGo0n3bVYtLY/7/RDcgGiYCkDOP4GhbJn5zaiZDgPOBd8MwLNOFomot7BCrD50
JAfU1oY+m9R30u5OA+jpmU6U/T0tf6TD5oXZR0hSYUGPgegODfrg063+EDVbrXtTRUaJ
1bqDeejyCcPxw+/nTi8JL6s4IZL49rf+K11+xn3pNG23Kmf09HO+0tsnjp9iuT00mdcH
TgrKDm5Pq8IhpHy8OyUj7iYbqr5hFJpueSNHTzAR4gPMu62bmACqUFRWHdkqVweniL96
bE6A==
X-Received: by 10.140.92.175 with SMTP id b44mr20458163qge.61.1443801155273;
Fri, 02 Oct 2015 08:52:35 -0700 (PDT)
MIME-Version: 1.0
References: <20151002100805.GL3433@vega.codepro.be>
<560E5C3C.8070709@gmail.com>
<20151002112448.GM3433@vega.codepro.be> <560E7228.2020000@gmail.com>
In-Reply-To: <560E7228.2020000@gmail.com>
From: Eric Joyner <ricera10@gmail.com>
Date: Fri, 02 Oct 2015 15:52:25 +0000
Message-ID: <CA+b0zg-_MW7oNbFpNvTVFArmJX-d0j9a7RHvYUHvZTqW75wCfg@mail.gmail.com>
Subject: Re: pf+TSO patch
To: Sossi Andrej <andrej.fil@gmail.com>, Kristof Provost <kp@freebsd.org>
Cc: freebsd-net@freebsd.org
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 15:52:36 -0000
I don't know where that email goes, either. You should really open a bug
report; it'll be something to start off of in investigating the issue.
On Fri, Oct 2, 2015 at 5:01 AM Sossi Andrej <andrej.fil@gmail.com> wrote:
> Kristof Provost je 02. 10. 2015 ob 13:24 napisal:
> > On 2015-10-02 12:28:12 (+0200), Sossi Andrej <andrej.fil@gmail.com>
> wrote:
> >> I have a similar problem but using ipfw. My issue is described in detail
> >> in the attached message. You thing it is the same case?
> >>
> >> Thank you in advance for your reply.
> >
> > I think it might be a different problem. The issue with PF mostly occurs
> > with large packets (because it's triggered by TSO).
> >
> > This seems to only happen with very specific packet sizes, which is
> > quite interesting. It'd be very useful to know if this also happens
> > with other network cards.
> >
> > Can you create a bug report on https://bugs.freebsd.org/bugzilla/ ?
>
> No, I no open a bug. I' don't know if it is a bug of driver or ipfw or
> jail virtualization. I wrote only a message on the net-list and to
> original writer (freebsd@intel.com), but i don't receive any reply.
>
> I want to do other tests to determinate more precisely nature of bug,
> but servers who I reproduce the problem is a production server (!) and I
> have no time (!!!) to do this. Sorry.
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
From owner-freebsd-net@freebsd.org Fri Oct 2 15:54:17 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 825C9A0EEC5
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 15:54:17 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 6DF8C1BE9
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 15:54:17 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t92FsHnL003879
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 15:54:17 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 203445] Receive side scaling (RSS) for more than 16 queues not
working in "ixl" driver
Date: Fri, 02 Oct 2015 15:54:17 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords: IntelNetworking
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: erj@freebsd.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: erj@freebsd.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-203445-2472-losob1h7So@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-203445-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 15:54:17 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203445
Eric Joyner <erj@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |In Progress
Assignee|freebsd-net@FreeBSD.org |erj@freebsd.org
--- Comment #3 from Eric Joyner <erj@freebsd.org> ---
Tushar has said this enabled RSS on all of his queues, so it looks like the
change I posted worked and should be included in the driver.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Fri Oct 2 17:12:36 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB101A0E4FB
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 17:12:36 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 96BC1162C
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 17:12:36 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t92HCa5D099637
for <freebsd-net@FreeBSD.org>; Fri, 2 Oct 2015 17:12:36 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch
Date: Fri, 02 Oct 2015 17:12:36 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: feature, needs-qa, patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: weberge42@gmail.com
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-156226-2472-Kga1QqAO4i@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 17:12:36 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226
weberge42@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |weberge42@gmail.com
--- Comment #4 from weberge42@gmail.com ---
Any news on this ?
I have the same problem - lagg is just not useable without notifying the
switch.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Fri Oct 2 22:16:16 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0172A0E835
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 2 Oct 2015 22:16:15 +0000 (UTC) (envelope-from nvass@gmx.com)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id AE8D319F9
for <freebsd-net@freebsd.org>; Fri, 2 Oct 2015 22:16:15 +0000 (UTC)
(envelope-from nvass@gmx.com)
Received: from moby.local ([91.140.35.215]) by mail.gmx.com (mrgmx003) with
ESMTPSA (Nemesis) id 0LcShi-1aOf5M1SkQ-00jpmD for <freebsd-net@freebsd.org>;
Sat, 03 Oct 2015 00:11:02 +0200
From: Nikos Vassiliadis <nvass@gmx.com>
To: freebsd-net@freebsd.org
Subject: carp on if_bridge deadlock
Message-ID: <560F00E6.5010503@gmx.com>
Date: Sat, 3 Oct 2015 01:10:46 +0300
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:kMjNh8rdA4FyMbfUKgx/XXGFvaf+huYT37cooTEltYM0N1eixeR
r6qbMTl/7xWS4IJ+/w1hhKHhdvdN4nxHTA8MtmzAlfAfFZlBUKlv/n8Ewkp+NagrX2rGeQW
gcAxzaHdGvh2lbAiGVWurUq7P81QgBpQmsU9MvhLMFN5Pt4vIePAe/+ybohWv/hI3CfqFOo
xLTbdXemPAwHX+gi9pLGg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:vOopai/6JV8=:1xJSxDvlwu4m4/IaVn1mjx
RepjmqSKJ0JpAbpLSeVUtCBVCHaR3PZCZIRRdrkcqnAbyl3hna88QOzG3R/BjfsWOMTrr5rjM
yNnS1lTugPHJJi5YFC0NDcQytJf1M1l+bFUMRw4xtPEN8cypyYRMyoR4jkNfJfET93irX1/GZ
zJrLksXcbBrd2Q96WQXHAgSiAcj62BQxYYgU9Kz1YJWACDeLKePtlgiVgbJWMhe6sTAz8kbsl
AFwce0/utYfRdECg2bCfnaHOGJNF9exCfyqX6nhNbgMZXi8sLOM39AlM5otMzweOV84Emx3A8
A/sfah2wF8ufBNokzmEzwbkI+lNXtnvOYATzg/UEIkJQVPdbJtgasjKak8nbht66vthStFa/r
YXgIDkla727aDfthx1bZ53eqxB5mnivNyP70wPcfZuvue3lkNZ0j2/UVda4BrC3ru+wl8bypw
93Z9+sFL9WOXKWrRnkQLHJT4g+4RSXCvvgDyU7CcLtdp5burZOtykwE94ZRBducPxKlX08cX0
Xe4K3elX7Ej/ogAwZSgN9CQhbmz0PAhrPHd4mAL5JDBdY+acRgSehuu9O4ZQb7OAr6S6ow8eM
QOhhALSGSbyrADz7x+GSnFmP41EhJvWv+Usovpz3EqFe5DRrbVpOrfpE0tHA8RbaRaLwbKilk
xdsmrDt60/+EUUGhsydeUyvp/+JzKVdm4ktb7tDlPTr7QWVrWG0v1GYKAKz/uE5CDpun86oN+
Z6YhBJStKpnU1L779saCBRroFyOEdGXWpFJzbVaHvhp4ilTjLdWy1a2tPWnfMb9sN4gq1QPpL
GSJCWem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 22:16:16 -0000
Hi,
I am trying to use carp over an if_bridge and am getting
this LOR:
> login: lock order reversal:
> 1st 0xfffff8000848a018 if_bridge (if_bridge) @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2315
> 2nd 0xfffff80003a58778 carp_if (carp_if) @ /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1118
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0092c3b6a0
> witness_checkorder() at witness_checkorder+0xe7a/frame 0xfffffe0092c3b720
> __mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfffffe0092c3b770
> carp_forus() at carp_forus+0x7a/frame 0xfffffe0092c3b7b0
> bridge_input() at bridge_input+0x338/frame 0xfffffe0092c3b820
> ether_nh_input() at ether_nh_input+0x2ab/frame 0xfffffe0092c3b860
> netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfffffe0092c3b8d0
> ether_input() at ether_input+0x4f/frame 0xfffffe0092c3b900
> vtnet_rxq_eof() at vtnet_rxq_eof+0x845/frame 0xfffffe0092c3b9b0
> vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x4e/frame 0xfffffe0092c3b9e0
> intr_event_execute_handlers() at intr_event_execute_handlers+0xe4/frame 0xfffffe0092c3ba20
> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe0092c3ba70
> fork_exit() at fork_exit+0x84/frame 0xfffffe0092c3bab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0092c3bab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Eventually all network activity will stop and this will happen:
> load: 0.33 cmd: ifconfig 665 [*carp_if] 228.29r 0.00u 0.01s 0% 2716k
Or:
> load: 2.86 cmd: ifconfig 720 [running] 104.92r 0.00u 36.53s 100% 2716k
A single ping to the carp address is enough to trigger the problem.
The debugger says:
> db> show all locks
> Process 669 (sysctl) thread 0xfffff800084269a0 (100082)
> exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff81cc4e90) locked @ /usr/src/sys/kern/kern_sysctl.c:164
> Process 668 (ifconfig) thread 0xfffff8000842e9a0 (100079)
> exclusive sx carp_sx (carp_sx) r = 0 (0xffffffff820b0ac0) locked @ /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1644
> Process 12 (intr) thread 0xfffff800038a89a0 (100010)
> exclusive sleep mutex carp_softc (carp_softc) r = 0 (0xfffff80008266508) locked @ /usr/src/sys/kern/kern_mutex.c:158
> Process 12 (intr) thread 0xfffff80003a679a0 (100031)
> exclusive sleep mutex carp_if (carp_if) r = 0 (0xfffff8000825b078) locked @ /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1118
> exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xfffff80008467018) locked @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2315
> db>
There is a related PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319
But I couldn't apply cleanly the patch to HEAD or 10-STABLE.
Thanks for any insights,
Nikos
From owner-freebsd-net@freebsd.org Sat Oct 3 03:18:24 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96884A0FF80
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 03:18:24 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 000001BA0
for <freebsd-net@freebsd.org>; Sat, 3 Oct 2015 03:18:22 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from admin.sibptus.TOMSK.ru ([212.73.125.240] verified)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 38889522 for freebsd-net@freebsd.org;
Sat, 03 Oct 2015 09:18:20 +0600
Received: from admin.sibptus.TOMSK.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.TOMSK.ru (8.14.9/8.14.7) with ESMTP id t933IILn038985
for <freebsd-net@freebsd.org>; Sat, 3 Oct 2015 09:18:19 +0600 (NOVT)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.TOMSK.ru (8.14.9/8.14.7/Submit) id t933IIut038984
for freebsd-net@freebsd.org; Sat, 3 Oct 2015 09:18:18 +0600 (NOVT)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.TOMSK.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sat, 3 Oct 2015 09:18:18 +0600
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: freebsd-net@freebsd.org
Subject: Re: Beware: FreeBSD-SA-15:24.rpcbind broke my NIS servers
Message-ID: <20151003031818.GA38652@admin.sibptus.tomsk.ru>
References: <20151002052342.GA16707@admin.sibptus.tomsk.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151002052342.GA16707@admin.sibptus.tomsk.ru>
Organization: OAO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.5.24 (2015-08-30)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 03:18:24 -0000
Victor Sudakov wrote:
>
> The installation of FreeBSD-SA-15:24.rpcbind broke my NIS servers. The
> NIS clients cannot bind to them any more.
>
> "freebsd-update rollback" helped. Don't know the reason yet, but beware.
p28 resolves the issue. Thanks to delphij for the quick fix.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru
From owner-freebsd-net@freebsd.org Sat Oct 3 06:28:28 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63721A0E2AF
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 06:28:28 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4F61414DC
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 06:28:28 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t936SSNW082605
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 06:28:28 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch
Date: Sat, 03 Oct 2015 06:28:27 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: feature, needs-qa, patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: eugen@grosbein.net
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-156226-2472-VzLs2SlTSS@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 06:28:28 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226
--- Comment #5 from eugen@grosbein.net ---
(In reply to weberge42 from comment #4)
AFAIK, link aggregation (lagg) is not supposed to be used this way, without
special switch configuration. And lagg IS usable if you do things right:
configure your switch(es) to make them know what ports are aggregated, so they
can manage their information databases to do right thing.
This PR should be closed as pilot error, I guess.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Sat Oct 3 17:52:52 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B066CA0F184
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 17:52:52 +0000 (UTC)
(envelope-from ermal.luci@gmail.com)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com
[IPv6:2607:f8b0:4002:c07::235])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 717B8134C
for <freebsd-net@freebsd.org>; Sat, 3 Oct 2015 17:52:52 +0000 (UTC)
(envelope-from ermal.luci@gmail.com)
Received: by ykdz138 with SMTP id z138so137850330ykd.2
for <freebsd-net@freebsd.org>; Sat, 03 Oct 2015 10:52:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=qkVEE1nfqJZM4jl72b1mqzWKzbM6radIPwv0u+VpzMU=;
b=03sAtiIvmoMrGDy3X3UxFHKaaRhOac7zNvh7mYo3gw2qlxgMwN+o4REQHNWHg+yfjQ
aRoTSA2+utB2IPrXIzg39ARqDLbs/jARY8+Ms7dYy6bPo+J3+bGJCGuALUelnEmOBNIo
Spy1u4cOjKzx5VOZZcZfQljrDmmAO6HGo0PUm5MFFGiWegdwCdVeDSE8oqHDprvhBdM2
QDH9ZcYEASbmadQw7Pbqj1yVACdcYHAB9eQ/xCCddktkBrGYVANFQzYkvbvgiwO9nlNS
kDFOsyR6uUxYlixFSgjoVQc/jhuhUsnjvONqAuq8wn7DoQVhzDdQsbghUfEK0KV/ec3Q
sa2g==
MIME-Version: 1.0
X-Received: by 10.170.223.69 with SMTP id p66mr18535470ykf.48.1443894771241;
Sat, 03 Oct 2015 10:52:51 -0700 (PDT)
Sender: ermal.luci@gmail.com
Received: by 10.129.89.195 with HTTP; Sat, 3 Oct 2015 10:52:51 -0700 (PDT)
In-Reply-To: <560F00E6.5010503@gmx.com>
References: <560F00E6.5010503@gmx.com>
Date: Sat, 3 Oct 2015 19:52:51 +0200
X-Google-Sender-Auth: FbjydgCuxHEedDsswNfOhSyjYl8
Message-ID: <CAPBZQG3=+boSOy+fSrj5_g9SkUm0xjqf97zKp1tC08QOe44hUg@mail.gmail.com>
Subject: Re: carp on if_bridge deadlock
From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= <eri@freebsd.org>
To: Nikos Vassiliadis <nvass@gmx.com>
Cc: freebsd-net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 17:52:52 -0000
This should apply https://reviews.freebsd.org/D3133
Somehow it is still pending on gnn@ for some reason!
On Sat, Oct 3, 2015 at 12:10 AM, Nikos Vassiliadis <nvass@gmx.com> wrote:
> Hi,
>
> I am trying to use carp over an if_bridge and am getting
> this LOR:
>
>> login: lock order reversal:
>> 1st 0xfffff8000848a018 if_bridge (if_bridge) @
>> /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2315
>> 2nd 0xfffff80003a58778 carp_if (carp_if) @
>> /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1118
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfffffe0092c3b6a0
>> witness_checkorder() at witness_checkorder+0xe7a/frame 0xfffffe0092c3b720
>> __mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfffffe0092c3b770
>> carp_forus() at carp_forus+0x7a/frame 0xfffffe0092c3b7b0
>> bridge_input() at bridge_input+0x338/frame 0xfffffe0092c3b820
>> ether_nh_input() at ether_nh_input+0x2ab/frame 0xfffffe0092c3b860
>> netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfffffe0092c3b8d0
>> ether_input() at ether_input+0x4f/frame 0xfffffe0092c3b900
>> vtnet_rxq_eof() at vtnet_rxq_eof+0x845/frame 0xfffffe0092c3b9b0
>> vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x4e/frame 0xfffffe0092c3b9e0
>> intr_event_execute_handlers() at intr_event_execute_handlers+0xe4/frame
>> 0xfffffe0092c3ba20
>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe0092c3ba70
>> fork_exit() at fork_exit+0x84/frame 0xfffffe0092c3bab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0092c3bab0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>
>
> Eventually all network activity will stop and this will happen:
>
>> load: 0.33 cmd: ifconfig 665 [*carp_if] 228.29r 0.00u 0.01s 0% 2716k
>>
> Or:
>
>> load: 2.86 cmd: ifconfig 720 [running] 104.92r 0.00u 36.53s 100% 2716k
>>
>
> A single ping to the carp address is enough to trigger the problem.
> The debugger says:
>
>> db> show all locks
>> Process 669 (sysctl) thread 0xfffff800084269a0 (100082)
>> exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff81cc4e90) locked @
>> /usr/src/sys/kern/kern_sysctl.c:164
>> Process 668 (ifconfig) thread 0xfffff8000842e9a0 (100079)
>> exclusive sx carp_sx (carp_sx) r = 0 (0xffffffff820b0ac0) locked @
>> /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1644
>> Process 12 (intr) thread 0xfffff800038a89a0 (100010)
>> exclusive sleep mutex carp_softc (carp_softc) r = 0 (0xfffff80008266508)
>> locked @ /usr/src/sys/kern/kern_mutex.c:158
>> Process 12 (intr) thread 0xfffff80003a679a0 (100031)
>> exclusive sleep mutex carp_if (carp_if) r = 0 (0xfffff8000825b078) locked
>> @ /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1118
>> exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xfffff80008467018)
>> locked @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2315
>> db>
>>
>
> There is a related PR
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319
> But I couldn't apply cleanly the patch to HEAD or 10-STABLE.
>
> Thanks for any insights,
> Nikos
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
> --
> Ermal
>
From owner-freebsd-net@freebsd.org Sat Oct 3 19:35:59 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FB86A0ED2A
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 19:35:59 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 8DAC9132D
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 19:35:59 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t93JZxtO084035
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 19:35:59 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 123045] [ng_mppc] ng_mppc_decompress - disabling node
Date: Sat, 03 Oct 2015 19:35:58 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: eugen@grosbein.net
X-Bugzilla-Status: Closed
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-123045-2472-Un1lU2pcNI@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-123045-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-123045-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 19:35:59 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=123045
eugen@grosbein.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eugen@grosbein.net
--- Comment #7 from eugen@grosbein.net ---
Just for the record: the problem reported again with the fix in kern/182212 and
the fix commited to stable/8 and present in all releases since 9.3 and 10.1
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Sat Oct 3 21:22:10 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A78CA0FD89
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 21:22:10 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id EBB001157
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 21:22:09 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t93LM9v6041144
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 21:22:09 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch
Date: Sat, 03 Oct 2015 21:22:10 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: feature, needs-qa, patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: weberge42@gmail.com
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-156226-2472-SAfvMwLXed@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 21:22:10 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226
--- Comment #6 from weberge42@gmail.com ---
(In reply to eugen from comment #5)
i know that link aggregation needs to configured on the switch(es) too. but i'm
not talking about link aggregation - i'm (and the opener) are talking about
simple failover supported by lagg(4):
failover Sends traffic only through the active port. If the
master
port becomes unavailable, the next active port is used. The
first interface added is the master port; any interfaces
added after that are used as failover devices.
without sending traffic from the host, traffic flow is only working again when
the switch(es) update their tables.
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Sat Oct 3 21:26:02 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58D37A0FFB9
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 21:26:02 +0000 (UTC) (envelope-from nvass@gmx.com)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 1536E1277;
Sat, 3 Oct 2015 21:26:02 +0000 (UTC) (envelope-from nvass@gmx.com)
Received: from moby.local ([91.140.35.215]) by mail.gmx.com (mrgmx101) with
ESMTPSA (Nemesis) id 0M7CRe-1aWc6I0VDq-00x4O4; Sat, 03 Oct 2015 23:26:00
+0200
Subject: Re: carp on if_bridge deadlock
To: =?UTF-8?Q?Ermal_Lu=c3=a7i?= <eri@freebsd.org>
References: <560F00E6.5010503@gmx.com>
<CAPBZQG3=+boSOy+fSrj5_g9SkUm0xjqf97zKp1tC08QOe44hUg@mail.gmail.com>
Cc: freebsd-net <freebsd-net@freebsd.org>
From: Nikos Vassiliadis <nvass@gmx.com>
Message-ID: <561047D2.1010303@gmx.com>
Date: Sun, 4 Oct 2015 00:25:38 +0300
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAPBZQG3=+boSOy+fSrj5_g9SkUm0xjqf97zKp1tC08QOe44hUg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:ylH4RAf2xxwTQn8qfcaFUVUIWuR6Uv3/0oiMvjxmBgn1RyXePvn
tUD5UZNrZOQVBME5+WYRHzXvz5mCP0EAMms5naLqHJZm7FuKJ/P4u29vHAT+NG7QZKT1Ty6
PZyZq4RRb6OjoO5k1YA50KSSItE+/SisOijdJR8kpX5qudyfRMq+qJxzBbjC69baIBZBTM7
KT7s1Q2EmO6tCvlsnYpGw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:vttxo0xr10Q=:2C56oJC86qt8eCWL2zE4l/
eJjM45lzxYPaUySsYXDPPx17dOmM5odwSz7UyYRtK9GTsolkgurWX6txFhPqFd+zONtRcBtIc
hz1cMuMNE4VhHONGSKWZxa0CxQKgRx30YzBRw2uYaT4Q9VTfdwM2ab0votE5BaFvJvQaKMs7Z
fVZz9wTtAezwBP2Vn6BIXX3S49gKXb6VS+hwnRdHWekOkz+2EjMgVQ3awufX50fV/5QTiX4wR
55s3/qpaimZXovoHuo8uoKtr7Ica3cAzEboapho5FI6S7MvHRXNLueVpmY2jvdbHqfBnHp2/V
1mp/Mc0xHLS0Rf7URNv9Qo/Meav6hkBMpAYQAWPF6RU3gtiZB9d6ME3n1cVklwFiNHmmJ0P5n
Qt1UeH1EUpKfAXE+KlCxJmF/qGtAZYAkPZUn8TAOWjyHnjxNOaWZNq0+6lPJq66yx+hetqIiH
u3gJfIa9gsuEPPqtDZZdquiM+TUp5fdRrXLnSY+sHZertiInVFoTEGlLLrY/kMS309/N0ogWR
bRN2CXt3CwMojneTt5cBf+VProNve4CMCbqFH/2gJyCRSOMjGhmfAqYRRFt+B8pWSGX8+GER3
guzHZDfVVHBpKM4smSylbGbqH8RDGIhP+yIr8ubaLCtw7q8nsUifCDQhGkp2fq1fLENn5IguT
65BmNS1TwCHYdno80O2dEsgV7hR/1LDHb/oHiF8+270wX1Rh+N2+zHGbCQguUoDuCYHYXVjxH
HUmnSO8qOf0h+JcFzSF2RCuIHmSYrEZOWxdddcWrMPJSWZnAY68cN1+VwpTvrIV9NIjwou4az
DnQsjZ0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 21:26:02 -0000
Hi Ermal,
Thanks for the pointer. I just tried and I get this panic:
> bridge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> ether 00:a0:98:27:8d:55
> inet 10.0.0.11 netmask 0xff000000 broadcast 10.255.255.255
> inet 10.0.0.2 netmask 0xff000000 broadcast 10.25panic: Lock carp_if not exclusively locked @ /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1744
>
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0092cd56f0
> vpanic() at vpanic+0x189/frame 0xfffffe0092cd5770
> panic() at panic+0x43/frame 0xfffffe0092cd57d0
> __rw_assert() at __rw_assert+0xa1/frame 0xfffffe0092cd57e0
> carp_ioctl() at carp_ioctl+0x334/frame 0xfffffe0092cd5860
> kern_ioctl() at kern_ioctl+0x230/frame 0xfffffe0092cd58c0
> sys_ioctl() at sys_ioctl+0x153/frame 0xfffffe0092cd59a0
> amd64_syscall() at amd64_syscall+0x2e1/frame 0xfffffe0092cd5ab0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0092cd5ab0
> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e927a, rsp = 0x7fffffffbd08, rbp = 0x7fffffffe500 ---
> KDB: enter: panic
> [ thread pid 295 tid 100060 ]
> Stopped at kdb_enter+0x3e: movq $0,kdb_why
> db>
On 10/03/15 20:52, Ermal Luçi wrote:
> This should apply https://reviews.freebsd.org/D3133
>
> Somehow it is still pending on gnn@ for some reason!
>
> On Sat, Oct 3, 2015 at 12:10 AM, Nikos Vassiliadis <nvass@gmx.com> wrote:
>
>> Hi,
>>
>> I am trying to use carp over an if_bridge and am getting
>> this LOR:
>>
>>> login: lock order reversal:
>>> 1st 0xfffff8000848a018 if_bridge (if_bridge) @
>>> /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2315
>>> 2nd 0xfffff80003a58778 carp_if (carp_if) @
>>> /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1118
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0xfffffe0092c3b6a0
>>> witness_checkorder() at witness_checkorder+0xe7a/frame 0xfffffe0092c3b720
>>> __mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfffffe0092c3b770
>>> carp_forus() at carp_forus+0x7a/frame 0xfffffe0092c3b7b0
>>> bridge_input() at bridge_input+0x338/frame 0xfffffe0092c3b820
>>> ether_nh_input() at ether_nh_input+0x2ab/frame 0xfffffe0092c3b860
>>> netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfffffe0092c3b8d0
>>> ether_input() at ether_input+0x4f/frame 0xfffffe0092c3b900
>>> vtnet_rxq_eof() at vtnet_rxq_eof+0x845/frame 0xfffffe0092c3b9b0
>>> vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x4e/frame 0xfffffe0092c3b9e0
>>> intr_event_execute_handlers() at intr_event_execute_handlers+0xe4/frame
>>> 0xfffffe0092c3ba20
>>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe0092c3ba70
>>> fork_exit() at fork_exit+0x84/frame 0xfffffe0092c3bab0
>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0092c3bab0
>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>>
>>
>> Eventually all network activity will stop and this will happen:
>>
>>> load: 0.33 cmd: ifconfig 665 [*carp_if] 228.29r 0.00u 0.01s 0% 2716k
>>>
>> Or:
>>
>>> load: 2.86 cmd: ifconfig 720 [running] 104.92r 0.00u 36.53s 100% 2716k
>>>
>>
>> A single ping to the carp address is enough to trigger the problem.
>> The debugger says:
>>
>>> db> show all locks
>>> Process 669 (sysctl) thread 0xfffff800084269a0 (100082)
>>> exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff81cc4e90) locked @
>>> /usr/src/sys/kern/kern_sysctl.c:164
>>> Process 668 (ifconfig) thread 0xfffff8000842e9a0 (100079)
>>> exclusive sx carp_sx (carp_sx) r = 0 (0xffffffff820b0ac0) locked @
>>> /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1644
>>> Process 12 (intr) thread 0xfffff800038a89a0 (100010)
>>> exclusive sleep mutex carp_softc (carp_softc) r = 0 (0xfffff80008266508)
>>> locked @ /usr/src/sys/kern/kern_mutex.c:158
>>> Process 12 (intr) thread 0xfffff80003a679a0 (100031)
>>> exclusive sleep mutex carp_if (carp_if) r = 0 (0xfffff8000825b078) locked
>>> @ /usr/src/sys/modules/carp/../../netinet/ip_carp.c:1118
>>> exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xfffff80008467018)
>>> locked @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2315
>>> db>
>>>
>>
>> There is a related PR
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319
>> But I couldn't apply cleanly the patch to HEAD or 10-STABLE.
>>
>> Thanks for any insights,
>> Nikos
>>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>
>> --
>> Ermal
>>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
From owner-freebsd-net@freebsd.org Sat Oct 3 21:40:13 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45227A0EB11
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 21:40:13 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 31DC11A06
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 21:40:13 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t93LeD9M066363
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 21:40:13 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch
Date: Sat, 03 Oct 2015 21:40:13 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: feature, needs-qa, patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: eugen@grosbein.net
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-156226-2472-SADx5lOcxF@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 21:40:13 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226
--- Comment #7 from eugen@grosbein.net ---
(In reply to weberge42 from comment #6)
In case of real failure, physical link goes down and switch updates its table
at once. There are patches for em(4)/igb(4) drivers that brings link down in
case of manual "ifconfig em0 down" command:
http://www.grosbein.net/freebsd/patches/em_sysctl-9.3S.diff.gz
http://www.grosbein.net/freebsd/patches/igb_sysctl-9.3S.diff.gz
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Sat Oct 3 21:59:25 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3066A0FA80
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 21:59:25 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id AF61612D3
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 21:59:25 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t93LxPsn095247
for <freebsd-net@FreeBSD.org>; Sat, 3 Oct 2015 21:59:25 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch
Date: Sat, 03 Oct 2015 21:59:25 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: feature, needs-qa, patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: weberge42@gmail.com
X-Bugzilla-Status: In Progress
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-156226-2472-6KpIAC8dUW@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 21:59:25 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226
--- Comment #8 from weberge42@gmail.com ---
(In reply to eugen from comment #7)
Yes, but if you have the following setup:
Server NIC1 - Switch 1
Server NIC2 - Switch 2
If NIC1 is active and Switch 1 fails, NIC2 becomes active and it takes ages to
see traffic flowing again.
I can't remember if the standby link is up but no traffic flowing or if it is
really down (down as in disabled).
I will try to investigate this a little bit further when i have access to the
switches again (tried with fortiswitch 548d, latest firmware)
--
You are receiving this mail because:
You are the assignee for the bug.
From owner-freebsd-net@freebsd.org Sat Oct 3 23:10:22 2015
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E8AFA0F1A6
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 3 Oct 2015 23:10:22 +0000 (UTC) (envelope-from juliank@tzi.de)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::50:5])
by mx1.freebsd.org (Postfix) with ESMTP id 4441B1C9D
for <freebsd-net@freebsd.org>; Sat, 3 Oct 2015 23:10:22 +0000 (UTC)
(envelope-from juliank@tzi.de)
Received: by mailman.ysv.freebsd.org (Postfix)
id 41A52A0F1A3; Sat, 3 Oct 2015 23:10:22 +0000 (UTC)
Delivered-To: net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 413D2A0F1A2
for <net@mailman.ysv.freebsd.org>; Sat, 3 Oct 2015 23:10:22 +0000 (UTC)
(envelope-from juliank@tzi.de)
Received: from mailhost.informatik.uni-bremen.de
(mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mailhost.informatik.uni-bremen.de",
Issuer "Universitaet Bremen CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id D6EDB1C9B
for <net@freebsd.org>; Sat, 3 Oct 2015 23:10:21 +0000 (UTC)
(envelope-from juliank@tzi.de)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de
(submithost.informatik.uni-bremen.de [134.102.201.11])
by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id
t93NAFGx026487
for <net@freebsd.org>; Sun, 4 Oct 2015 01:10:15 +0200 (CEST)
Received: from [IPv6:2001:470:7408:0:3870:db74:396c:50a5] (unknown
[IPv6:2001:470:7408:0:3870:db74:396c:50a5])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id
3nT3nM3QD2z4pJ9
for <net@freebsd.org>; Sun, 4 Oct 2015 01:10:15 +0200 (CEST)
To: "net@freebsd.org" <net@freebsd.org>
From: Julian Kornberger <juliank@tzi.de>
Subject: Page fault after destroying/reconfiguring GRE interface
Message-ID: <56106056.7040006@tzi.de>
Date: Sun, 4 Oct 2015 01:10:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2015 23:10:22 -0000
Hi,
my machine (FreeBSD 10.2) crashes sometimes after I destroy or
reconfigure a GRE interface. You find my crash dumps at:
http://www.informatik.uni-bremen.de/~juliank/crash/
[...]
#7 0xffffffff80d307f2 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:236
#8 0xffffffff81e125eb in in_gre_encapcheck (m=0xfffff8001ef81d00, off=20,
proto=47, arg=0xfffff800613f3000)
at /usr/src/sys/modules/if_gre/../../netinet/ip_gre.c:112
#9 0xffffffff80a75142 in encap4_input (m=0xfffff8001ef81d00, off=20)
at /usr/src/sys/netinet/ip_encap.c:149
#10 0xffffffff80a77f57 in ip_input (m=0xfffff8001ef81d00)
at /usr/src/sys/netinet/ip_input.c:734
[...]
Any ideas?
Kind Regards,
Julian Kornberger