From owner-freebsd-net@freebsd.org Sun Sep 27 21:00:23 2015 Return-Path: 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 ; 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 ; 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 ; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 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> <5601CF2D.9030307@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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 08:00:12 -0000 > 25 sep 2015 kl. 16:19 skrev Palle Girgensohn : >=20 >>=20 >> 25 sep 2015 kl. 16:14 skrev Palle Girgensohn : >>=20 >>>=20 >>> 24 sep 2015 kl. 11:39 skrev Palle Girgensohn : >>>=20 >>>=20 >>>> 24 sep 2015 kl. 09:57 skrev Julien Charbon : >>>>=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 >>>>>>> : >>>>>>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn >>>>>>>> : >>>>>>>>> 23 sep 2015 kl. 20:32 skrev Julien Charbon :=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 >>>> >>>=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) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D) 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) > at /usr/src/sys/kern/kern_shutdown.c:759 > #3 0xffffffff8099c180 in sbsndptr (sb=3D,=20 > off=3D, len=3D,=20 > moff=3D) 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,=20= > th=3D, so=3D,=20 > tp=3D, drop_hdrlen=3D, = tlen=3D0,=20 > iptos=3D, ti_locked=3DCannot access memory at = address 0x1 > ) > at /usr/src/sys/netinet/tcp_input.c:3018 > #6 0xffffffff80ac2e04 in tcp_input (m=3D,=20 > off0=3D) 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, 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 , = 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: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Mon, 28 Sep 2015 10:08:26 +0200 (CEST) Date: Mon, 28 Sep 2015 10:08:25 +0200 (CEST) From: Emeric POUPON To: FreeBSD Net 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" =C3=80: "FreeBSD Net" 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: 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 ; 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 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> <5601CF2D.9030307@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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : >>> 24 sep 2015 kl. 09:57 skrev Julien Charbon : 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 >>>>>> : >>>>>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn=20 >>>>>>> : >>>>>>>> 23 sep 2015 kl. 20:32 skrev Julien Charbon >>>>>>>> : 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: 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 ; 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 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> <5601CF2D.9030307@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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D) 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) > at /usr/src/sys/kern/kern_shutdown.c:759 > #3 0xffffffff8099c180 in sbsndptr (sb=3D,=20 > off=3D, len=3D,=20 > moff=3D) 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,=20 > th=3D, so=3D,=20 > tp=3D, drop_hdrlen=3D, tl= en=3D0,=20 > iptos=3D, ti_locked=3DCannot access memory at = address 0x1 > ) > at /usr/src/sys/netinet/tcp_input.c:3018 > #6 0xffffffff80ac2e04 in tcp_input (m=3D,=20 > off0=3D) 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, 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 , 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: 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 ; 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 Subject: Re: Can tcp_close() be called in INP_TIMEWAIT case To: John Baldwin References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org> <5602BB7A.9010504@freebsd.org> <5603E8E4.5030406@freebsd.org> <2216936.QIvWsOndvU@ralph.baldwin.cx> Cc: Palle Girgensohn , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 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 From: Julien Charbon 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --- 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |gnn@FreeBSD.org --- Comment #2 from Hiren Panchasara --- (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: 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 (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: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu2 cpu3: Processor \_PR_.CPU3 (ACPI ID 4) -> APIC ID 6 cpu3: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu3 cpu4: Processor \_PR_.CPU4 (ACPI ID 5) -> APIC ID 1 cpu4: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu4 cpu5: Processor \_PR_.CPU5 (ACPI ID 6) -> APIC ID 3 cpu5: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu5 cpu6: Processor \_PR_.CPU6 (ACPI ID 7) -> APIC ID 5 cpu6: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu6 cpu7: Processor \_PR_.CPU7 (ACPI ID 8) -> APIC ID 7 cpu7: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu7 hpet0: 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: 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: 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: 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: 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: 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: 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: 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: port 0xe000-0xe07f mem 0xf4000000-0xf4fff= fff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff irq 16 at device 0.0 on pci1 nvidia0: 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: 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: 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: at device 22.0 (no driver attached) em0: 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: 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: 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: irq 16 at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pci2: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: at device 31.0 on pci0 isa0: on isab0 random: harvesting attach, 8 bytes (4 bits) from isa0 random: harvesting attach, 8 bytes (4 bits) from isab0 ahci0: 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: at channel 0 on ahci0 ahcich0: Caps: random: harvesting attach, 8 bytes (4 bits) from ahcich0 ahcich1: at channel 1 on ahci0 ahcich1: Caps: HPCP MPSP random: harvesting attach, 8 bytes (4 bits) from ahcich1 ahcich2: at channel 2 on ahci0 ahcich2: Caps: ESP random: harvesting attach, 8 bytes (4 bits) from ahcich2 ahcich3: at channel 3 on ahci0 ahcich3: Caps: ESP random: harvesting attach, 8 bytes (4 bits) from ahcich3 ahcich4: not probed (disabled) ahciem0: 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: 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: on ichsmb0 smb0: 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: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_lid0 acpi_button0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_button0 acpi_button1: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_button1 acpi_acad0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_acad0 battery0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from battery0 battery1: on acpi0 random: harvesting attach, 8 bytes (4 bits) from battery1 acpi_tz0: 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: port 0x60,0x64 irq 1 on acpi0 atkbd0: 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: 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: 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: on cpu0 coretemp0: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp0 est0: on cpu0 random: harvesting attach, 8 bytes (4 bits) from cpufreq0 random: harvesting attach, 8 bytes (4 bits) from est0 coretemp1: on cpu1 coretemp1: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp1 est1: on cpu1 random: harvesting attach, 8 bytes (4 bits) from cpufreq1 random: harvesting attach, 8 bytes (4 bits) from est1 coretemp2: on cpu2 coretemp2: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp2 est2: on cpu2 random: harvesting attach, 8 bytes (4 bits) from cpufreq2 random: harvesting attach, 8 bytes (4 bits) from est2 coretemp3: on cpu3 coretemp3: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp3 est3: on cpu3 random: harvesting attach, 8 bytes (4 bits) from cpufreq3 random: harvesting attach, 8 bytes (4 bits) from est3 coretemp4: on cpu4 coretemp4: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp4 est4: on cpu4 random: harvesting attach, 8 bytes (4 bits) from cpufreq4 random: harvesting attach, 8 bytes (4 bits) from est4 coretemp5: on cpu5 coretemp5: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp5 est5: on cpu5 random: harvesting attach, 8 bytes (4 bits) from cpufreq5 random: harvesting attach, 8 bytes (4 bits) from est5 coretemp6: on cpu6 coretemp6: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp6 est6: on cpu6 random: harvesting attach, 8 bytes (4 bits) from cpufreq6 random: harvesting attach, 8 bytes (4 bits) from est6 coretemp7: on cpu7 coretemp7: Setting TjMax=3D100 random: harvesting attach, 8 bytes (4 bits) from coretemp7 est7: 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: at cad 0 on hdac0 hdaa0: 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: 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: 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: at cad 0 on hdac1 hdaa1: 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: 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: 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: at usbus1 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: 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: 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: 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: 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 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: 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: 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: at usbus2 uhub3: on = usbus2 ugen1.2: at usbus1 uhub4: 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: at usbus2 ugen1.3: 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, 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, code=3D0) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80a26264 in kdb_trap (type=3D3, code=3D0, tf=3D) 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\211AWAVATSH\203PI\211A\211= H\213\004%\201H\211E\201<%x\201") at cpufunc.h:63 #9 0xffffffff809e9139 in vpanic (fmt=3D,=20 ap=3D) at /usr/src/sys/kern/kern_shutdown.c:746 #10 0xffffffff809e8f82 in kassert_panic (fmt=3D) 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) 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) at /usr/src/sys/kern/subr_taskqueue.c:683 #15 0xffffffff809af194 in fork_exit ( callout=3D0xffffffff80a37570 ,=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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marius@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #1 from Mark Linimon --- 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: 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 ; 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 ; 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: 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 To: David Wolfskill , "current@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > (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: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from cpu2 > cpu3: Processor \_PR_.CPU3 (ACPI ID 4) -> APIC ID 6 > cpu3: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from cpu3 > cpu4: Processor \_PR_.CPU4 (ACPI ID 5) -> APIC ID 1 > cpu4: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from cpu4 > cpu5: Processor \_PR_.CPU5 (ACPI ID 6) -> APIC ID 3 > cpu5: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from cpu5 > cpu6: Processor \_PR_.CPU6 (ACPI ID 7) -> APIC ID 5 > cpu6: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from cpu6 > cpu7: Processor \_PR_.CPU7 (ACPI ID 8) -> APIC ID 7 > cpu7: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from cpu7 > hpet0: 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: 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: 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: 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: 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: 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: 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: 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: port 0xe000-0xe07f mem 0xf4000000-0xf4f= fffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff irq 16 at device 0.0 on p= ci1 > nvidia0: 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: 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: 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: at device 22.0 (no driver attached) > em0: 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: 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: 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: irq 16 at device 28.0 on pci0 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pci2: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: at device 31.0 on pci0 > isa0: on isab0 > random: harvesting attach, 8 bytes (4 bits) from isa0 > random: harvesting attach, 8 bytes (4 bits) from isab0 > ahci0: 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: at channel 0 on ahci0 > ahcich0: Caps: > random: harvesting attach, 8 bytes (4 bits) from ahcich0 > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: HPCP MPSP > random: harvesting attach, 8 bytes (4 bits) from ahcich1 > ahcich2: at channel 2 on ahci0 > ahcich2: Caps: ESP > random: harvesting attach, 8 bytes (4 bits) from ahcich2 > ahcich3: at channel 3 on ahci0 > ahcich3: Caps: ESP > random: harvesting attach, 8 bytes (4 bits) from ahcich3 > ahcich4: not probed (disabled) > ahciem0: 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: 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: on ichsmb0 > smb0: 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: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from acpi_lid0 > acpi_button0: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from acpi_button0 > acpi_button1: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from acpi_button1 > acpi_acad0: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from acpi_acad0 > battery0: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from battery0 > battery1: on acpi0 > random: harvesting attach, 8 bytes (4 bits) from battery1 > acpi_tz0: 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: port 0x60,0x64 irq 1 on acpi0 > atkbd0: 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: 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: 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: on cpu0 > coretemp0: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp0 > est0: on cpu0 > random: harvesting attach, 8 bytes (4 bits) from cpufreq0 > random: harvesting attach, 8 bytes (4 bits) from est0 > coretemp1: on cpu1 > coretemp1: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp1 > est1: on cpu1 > random: harvesting attach, 8 bytes (4 bits) from cpufreq1 > random: harvesting attach, 8 bytes (4 bits) from est1 > coretemp2: on cpu2 > coretemp2: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp2 > est2: on cpu2 > random: harvesting attach, 8 bytes (4 bits) from cpufreq2 > random: harvesting attach, 8 bytes (4 bits) from est2 > coretemp3: on cpu3 > coretemp3: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp3 > est3: on cpu3 > random: harvesting attach, 8 bytes (4 bits) from cpufreq3 > random: harvesting attach, 8 bytes (4 bits) from est3 > coretemp4: on cpu4 > coretemp4: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp4 > est4: on cpu4 > random: harvesting attach, 8 bytes (4 bits) from cpufreq4 > random: harvesting attach, 8 bytes (4 bits) from est4 > coretemp5: on cpu5 > coretemp5: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp5 > est5: on cpu5 > random: harvesting attach, 8 bytes (4 bits) from cpufreq5 > random: harvesting attach, 8 bytes (4 bits) from est5 > coretemp6: on cpu6 > coretemp6: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp6 > est6: on cpu6 > random: harvesting attach, 8 bytes (4 bits) from cpufreq6 > random: harvesting attach, 8 bytes (4 bits) from est6 > coretemp7: on cpu7 > coretemp7: Setting TjMax=3D100 > random: harvesting attach, 8 bytes (4 bits) from coretemp7 > est7: 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: at cad 0 on hdac0 > hdaa0: 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: 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: 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: at cad 0 on hdac1 > hdaa1: 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: 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: 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: at usbus1 > uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: 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: 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: 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: 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 > 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: 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: 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: at usbus2 > uhub3: o= n usbus2 > ugen1.2: at usbus1 > uhub4: 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: at usbus2 > ugen1.3: 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, 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, code=3D0= ) > at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff80a26264 in kdb_trap (type=3D3, code=3D0, tf=3D) > 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\211AWAVATSH\203PI\211A\211H\213\004%\201H\211E\201<%x\201") at cpufunc.h:63 > #9 0xffffffff809e9139 in vpanic (fmt=3D, > ap=3D) at /usr/src/sys/kern/kern_shutdown.c:746 > #10 0xffffffff809e8f82 in kassert_panic (fmt=3D) > 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) > 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) > at /usr/src/sys/kern/subr_taskqueue.c:683 > #15 0xffffffff809af194 in fork_exit ( > callout=3D0xffffffff80a37570 , > 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: 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 ; 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 ; Tue, 29 Sep 2015 22:52:01 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: by laclj5 with SMTP id lj5so26041491lac.3 for ; 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 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Sep 2015 15:51:57 -0700 (PDT) From: Dmitry Sivachenko Content-Type: multipart/mixed; boundary="Apple-Mail=_267DA67E-FB01-48D6-857A-D1FE3D23A94B" Subject: getaddrinfo() question Message-Id: Date: Wed, 30 Sep 2015 01:51:56 +0300 To: FreeBSD Net 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 #include #include #include #include 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --- 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: 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 ; 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 ; Tue, 29 Sep 2015 23:22:50 +0000 (UTC) (envelope-from javocado@gmail.com) Received: by laclj5 with SMTP id lj5so26600599lac.3 for ; 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: Subject: Network tuning help needed - asymmetric speed From: javocado 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 metric 0 mtu 1500 options=401bb ether xxxxxx inet xxxxxx netmask 0xfffffff8 broadcast xxxxx inet6 xxxxx%igb0 prefixlen 64 scopeid 0x1 inet6 xxxxxxx prefixlen 64 nd6 options=3 media: Ethernet autoselect (1000baseT ) 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: 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 ; 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 ; Wed, 30 Sep 2015 06:10:20 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by obbzf10 with SMTP id zf10so23775477obb.2 for ; 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: References: Date: Tue, 29 Sep 2015 23:10:19 -0700 X-Google-Sender-Auth: A8MiCjgbV8f3dRZhAdR6hRjUloM Message-ID: Subject: Re: Network tuning help needed - asymmetric speed From: Kevin Oberman To: javocado 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 06:10:20 -0000 On Tue, Sep 29, 2015 at 4:22 PM, javocado 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 . 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |franco@opnsense.org --- Comment #19 from Franco Fichtner --- 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |girgen@FreeBSD.org --- Comment #20 from Palle Girgensohn --- 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=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) 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=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff8099c180 in sbsndptr (sb=, off=, len=, moff=) 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=, th=, so=, tp=, drop_hdrlen=, tlen=0, iptos=, ti_locked=Cannot access memory at address 0x1 ) at /usr/src/sys/netinet/tcp_input.c:3018 #6 0xffffffff80ac2e04 in tcp_input (m=, off0=) 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=, 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 , 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: 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 ; 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 ; 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 To: Adrian Chadd Cc: "current@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 , Adrian Chadd , "current@freebsd.org" , "net@freebsd.org" , wireless@freebsd.org References: <20150929130534.GI1125@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="24bywM+ZyrW0DJoD" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 , FreeBSD Net References: From: Eric van Gyzen 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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> <20150930125452.GS1125@albert.catwhisker.org> Date: Wed, 30 Sep 2015 08:37:40 -0700 Message-ID: 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 To: David Wolfskill , Adrian Chadd , "current@freebsd.org" , "net@freebsd.org" , "freebsd-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; Wed, 30 Sep 2015 17:32:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcpb10 with SMTP id pb10so110811923igc.1 for ; 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: References: Date: Wed, 30 Sep 2015 10:32:17 -0700 Message-ID: Subject: Re: Network tuning help needed - asymmetric speed From: Adrian Chadd To: javocado Cc: FreeBSD Net 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 metric 0 mtu 1500 > options=401bb > ether xxxxxx > inet xxxxxx netmask 0xfffffff8 broadcast xxxxx > inet6 xxxxx%igb0 prefixlen 64 scopeid 0x1 > inet6 xxxxxxx prefixlen 64 > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --- 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --- 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: 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 ; 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 ; Thu, 1 Oct 2015 03:39:41 +0000 (UTC) (envelope-from sonsechang@gmail.com) Received: by pacex6 with SMTP id ex6so60338670pac.0 for ; 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 (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 To: freebsd-net Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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)" 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: , Thread-Topic: D1986: Teach lagg(4) to change MTU X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sechang Son , freebsd-net Subject: Re: routine that configure 127.0.0.1 References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; Thu, 1 Oct 2015 10:52:56 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by lbos8 with SMTP id s8so6786128lbo.0 for ; 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: Subject: RFC: revising netmap ring initialization From: Luigi Rizzo To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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)" Reply-to: D1986+325+381818416dc12ca2@reviews.freebsd.org Subject: [Differential] [Commented On] D1986: Teach lagg(4) to change MTU Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D1986: Teach lagg(4) to change MTU X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 , freebsd-net@freebsd.org References: <20151002100805.GL3433@vega.codepro.be> From: Sossi Andrej 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 metric 0 mtu 1500 options=403bb 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 media: Ethernet autoselect (1000baseT ) 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: 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 ; 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 ; 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 To: Sossi Andrej 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 11:24:51 -0000 On 2015-10-02 12:28:12 (+0200), Sossi Andrej 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: 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 ; 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 References: <20151002100805.GL3433@vega.codepro.be> <560E5C3C.8070709@gmail.com> <20151002112448.GM3433@vega.codepro.be> Cc: freebsd-net@freebsd.org From: Sossi Andrej 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 Date: Fri, 02 Oct 2015 15:52:25 +0000 Message-ID: Subject: Re: pf+TSO patch To: Sossi Andrej , Kristof Provost 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > Kristof Provost je 02. 10. 2015 ob 13:24 napisal: > > On 2015-10-02 12:28:12 (+0200), Sossi Andrej > 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-net@FreeBSD.org |erj@freebsd.org --- Comment #3 from Eric Joyner --- 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; Sat, 03 Oct 2015 00:11:02 +0200 From: Nikos Vassiliadis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; Sat, 3 Oct 2015 17:52:52 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by ykdz138 with SMTP id z138so137850330ykd.2 for ; 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: Subject: Re: carp on if_bridge deadlock From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Nikos Vassiliadis Cc: freebsd-net 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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?= References: <560F00E6.5010503@gmx.com> Cc: freebsd-net From: Nikos Vassiliadis 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Sun, 4 Oct 2015 01:10:15 +0200 (CEST) To: "net@freebsd.org" From: Julian Kornberger 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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