From owner-freebsd-stable@freebsd.org Sun Aug 6 01:13:23 2017 Return-Path: Delivered-To: freebsd-stable@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 994A5DD5905 for ; Sun, 6 Aug 2017 01:13:23 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FAF86A6BF for ; Sun, 6 Aug 2017 01:13:22 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id v761D462004601 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 6 Aug 2017 03:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id v761D4Zf004600 for freebsd-stable@FreeBSD.ORG; Sun, 6 Aug 2017 03:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id v760PGsV024374 for ; Sun, 6 Aug 2017 02:25:16 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id v760O0qH024199 for ; Sun, 6 Aug 2017 02:24:01 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id v760O0F3024198 for freebsd-stable@FreeBSD.ORG; Sun, 6 Aug 2017 02:24:00 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: a strange and terrible saga of the cursed iSCSI ZFS SAN Date: Sun, 6 Aug 2017 02:10:40 +0200 Organization: even some more stinky socks Message-ID: References: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> <1d53f489-5135-7633-fef4-35d26e4969dc@norma.perm.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 6 Aug 2017 00:11:41 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="22325"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <1d53f489-5135-7633-fef4-35d26e4969dc@norma.perm.ru> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Sun, 06 Aug 2017 03:13:05 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 01:13:23 -0000 Eugene M. Zheganin wrote: > Hi, > > On 05.08.2017 22:08, Eugene M. Zheganin wrote: >> >> pool: userdata >> state: ONLINE >> status: One or more devices has experienced an error resulting in data >> corruption. Applications may be affected. >> action: Restore the file in question if possible. Otherwise restore the >> entire pool from backup. >> see: http://illumos.org/msg/ZFS-8000-8A >> scan: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> userdata ONLINE 0 0 216K >> mirror-0 ONLINE 0 0 432K >> gpt/userdata0 ONLINE 0 0 432K >> gpt/userdata1 ONLINE 0 0 432K > That would be funny, if not that sad, but while writing this message, > the pool started to look like below (I just asked zpool status twice in > a row, comparing to what it was): > > [root@san1:~]# zpool status userdata > pool: userdata > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > userdata ONLINE 0 0 728K > mirror-0 ONLINE 0 0 1,42M > gpt/userdata0 ONLINE 0 0 1,42M > gpt/userdata1 ONLINE 0 0 1,42M > > errors: 4 data errors, use '-v' for a list > [root@san1:~]# zpool status userdata > pool: userdata > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > userdata ONLINE 0 0 730K > mirror-0 ONLINE 0 0 1,43M > gpt/userdata0 ONLINE 0 0 1,43M > gpt/userdata1 ONLINE 0 0 1,43M > > errors: 4 data errors, use '-v' for a list > > So, you see, the error rate is like speed of light. And I'm not sure if > the data access rate is that enormous, looks like they are increasing on > their own. > So may be someone have an idea on what this really means. It is remarkable that You always have the same error count on both sides of the mirror. From what I have seen, such a picture appears when an unrecoverable error (i.e. one that is on both sides of the mirror) is read again and again. File number 0x1 is probably some important metadata, and since it is not readable it cannot be put into the ARC, so the read is tried ever again. An error that would appear only on one side appears only once, because then it is auto-corrected. In that case the figures have some erratic deviations. Therefore it is worthwile to remove the erroneous data soon, because as long as that exists one does not get anything useful from the figures (like how many errors are actually appearing anew). From owner-freebsd-stable@freebsd.org Sun Aug 6 03:36:04 2017 Return-Path: Delivered-To: freebsd-stable@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 5C3F9DB4860 for ; Sun, 6 Aug 2017 03:36:04 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (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 2BE656E8BF for ; Sun, 6 Aug 2017 03:36:04 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:2435:171d:82f4:26a7]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v763a03f067712 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Aug 2017 22:36:05 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2016; t=1501990565; bh=ZIbzASw6k5H0E2Kx3xosYDWhd4ZVNv9R35RwxajvcgQ=; h=From:To:Subject:Date; b=KrTtlpcwNA+QM+n/NTHUTuwfHYmrGbzuyQo81zkBRGjcry7JXdN9Did8cE2upbyIV tun1+aALU9fU6HqkG2+TmrD6TDPOV6R1SGcMGesYG2nIn3zQWkWqjCXDxDk4E2es/z CA4gkI/xrqZRB5PimUkfEJf1RHOnyygAkIQh6EolhfUJ5dtJFfS7bVVffyVJ8ceL2L 8Wp7pMDz+r8mqWOcLOWAbkEi5qJGfjdkX+wFw3DjTbA2nGvBvZBeMdeQ87C1s25TI5 tNpMAIKwg6Vj2Z/TBARBChrzXqUCf1NMQM9AZlqeN+SKtITdIV0cej0XA+o9OePP8B XUlopD47xQ3jQ== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:2435:171d:82f4:26a7] claimed to be flake.tharned.org From: Greg Rivers To: freebsd-stable@freebsd.org Subject: SLAAC not working Date: Sat, 05 Aug 2017 22:35:56 -0500 Message-ID: <1646645.UkMcyRZBVl@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE; KDE/4.14.30; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Sat, 05 Aug 2017 22:36:05 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 03:36:04 -0000 I have a couple of hosts on different networks running 11.1-RELEASE amd64. Neither host will auto-configure its IPv6 address, even though valid router advertisements[1] are present. Both hosts have two oce(4) interfaces aggregated in fail-over mode via lagg(4). The lagg interface is configured thusly (/etc/rc.conf): ifconfig_oce0="up" ifconfig_oce1="up" cloned_interfaces="lagg0" ifconfig_lagg0="inet xxx.xxx.217.100/25 laggproto failover laggport oce0 laggport oce1" defaultrouter="xxx.xxx.217.1" ip6addrctl_policy="ipv6_prefer" ifconfig_lagg0_ipv6="inet6 accept_rtadv" rtsold_enable="YES" The running interface looks like this: lagg0: flags=8843 metric 0 mtu 1500 options=507bb ether ac:16:2d:1e:b8:80 inet xxx.xxx.217.100 netmask 0xffffff80 broadcast xxx.xxx.217.127 inet6 fe80::ae16:2dff:fe1e:b880%lagg0 prefixlen 64 scopeid 0xc nd6 options=23 media: Ethernet autoselect status: active groups: lagg laggproto failover lagghash l2,l3,l4 laggport: oce0 flags=5 laggport: oce1 flags=0<> ndp(8) shows only: Neighbor Linklayer Address Netif Expire S Flags fe80::ae16:2dff:fe1e:b880%lagg0 ac:16:2d:1e:b8:80 lagg0 permanent R Other hosts (running RedHat 6) on the same network SLAAC just fine. Does anyone have insight into this problem or suggestions for troubleshooting? -- Greg Rivers [1] Internet Control Message Protocol v6 Type: Router Advertisement (134) Code: 0 Checksum: 0x8176 [correct] [Checksum Status: Good] Cur hop limit: 64 Flags: 0x00, Prf (Default Router Preference): Medium 0... .... = Managed address configuration: Not set .0.. .... = Other configuration: Not set ..0. .... = Home Agent: Not set ...0 0... = Prf (Default Router Preference): Medium (0) .... .0.. = Proxy: Not set .... ..0. = Reserved: 0 Router lifetime (s): 1800 Reachable time (ms): 0 Retrans timer (ms): 0 ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) Type: Prefix information (3) Length: 4 (32 bytes) Prefix Length: 64 Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) 1... .... = On-link flag(L): Set .1.. .... = Autonomous address-configuration flag(A): Set ..0. .... = Router address flag(R): Not set ...0 0000 = Reserved: 0 Valid Lifetime: 2592000 Preferred Lifetime: 604800 Reserved Prefix: 26xx:xxxx:4013:23:: ICMPv6 Option (MTU : 9216) Type: MTU (5) Length: 1 (8 bytes) Reserved MTU: 9216 From owner-freebsd-stable@freebsd.org Sun Aug 6 03:44:57 2017 Return-Path: Delivered-To: freebsd-stable@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 A8493DB50E9 for ; Sun, 6 Aug 2017 03:44:57 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 66AB26ED9B for ; Sun, 6 Aug 2017 03:44:57 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x242.google.com with SMTP id p68so3138355ywg.5 for ; Sat, 05 Aug 2017 20:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NYy9usHoBhTxGx92LzVyY2cIEo1t7sTUwe95MG/cGmc=; b=b9l07zLvSgZ/CHs9SXpHLNO4CiSx2UO981ipKMsb1kYl7gL7XrJGIEJbiIXAIR5WfX OWjaBKYHjiilvRaStasPbas6bWVsf6QgmTBs374Qeww8cC9FRNLiVfXFPbwfCUjUM5bc Hks6LLVykIt8Rg71+m+HH5YlhhwbOx9XPfF3EwzYD9ATqdbBFTAjio2wli3wfBLi1ZBV a7l5550r8seHeCSIc/LGEjM8z3U749xPhECW73DYLG22FCTPk5imMESMg/THgmjuRIAc gmECE+AlxicD8PNVh38rHCqqPhc017nGPh7Z3gyEU6ukt5wXoIWy2puQVO3p9LLiwNEr 8STA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NYy9usHoBhTxGx92LzVyY2cIEo1t7sTUwe95MG/cGmc=; b=mFnJbNAwqXO2NXyD3UyKQRcs/uuOgu0KUbVn8k/4moznCN0IhQxamp9+MrEoNQfnmD 0q0eilvLCyxeu0rTFKJahb4vNUhamElRF6ZGncjQG21qwzzjBdIiRukg5py1cLZhTtUb 7H7HGHuX7qdxxrIddD1Pel2/DXPTsRdM5MK0fC3eWoDsnVHCJEgkXgkwNjThCwmgfE+f W7l+S5MU0ll6SFyS4trwqJVmGjOtKVK7gHoXH0dMO4gA46ZvmVtLjTf3UsvOpwqCqsCY FtVqo0Sbm0pkEsAzNJ9C1Sw07ldNmsge/uHkk++jXEZGzgSz0+i4fAsNFx42ocLd061a Wl0A== X-Gm-Message-State: AHYfb5jXwQoYre6nRDNjcAPYGdFEGRZ/m2Tv7zRqJqLdJ1WZomkH6zID kSttY29SaPRBoKGpGm2inF+FRFuayBxNcgE= X-Received: by 10.129.43.131 with SMTP id r125mr5589219ywr.330.1501991096495; Sat, 05 Aug 2017 20:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.238.135 with HTTP; Sat, 5 Aug 2017 20:44:56 -0700 (PDT) In-Reply-To: <1646645.UkMcyRZBVl@flake.tharned.org> References: <1646645.UkMcyRZBVl@flake.tharned.org> From: Ultima Date: Sat, 5 Aug 2017 20:44:56 -0700 Message-ID: Subject: Re: SLAAC not working To: Greg Rivers Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 03:44:57 -0000 Do you have pf or ipfw running? are they accepting ICMP type 128, 129, 135, 136? the first 2 are for ping requests last 2 for Neighbor solicitation/advertisement. On Sat, Aug 5, 2017 at 8:35 PM, Greg Rivers wrote: > I have a couple of hosts on different networks running 11.1-RELEASE amd64. > Neither host will auto-configure its IPv6 address, even though valid router > advertisements[1] are present. Both hosts have two oce(4) interfaces > aggregated in fail-over mode via lagg(4). The lagg interface is configured > thusly (/etc/rc.conf): > > ifconfig_oce0="up" > ifconfig_oce1="up" > cloned_interfaces="lagg0" > ifconfig_lagg0="inet xxx.xxx.217.100/25 laggproto failover laggport oce0 > laggport oce1" > defaultrouter="xxx.xxx.217.1" > ip6addrctl_policy="ipv6_prefer" > ifconfig_lagg0_ipv6="inet6 accept_rtadv" > rtsold_enable="YES" > > The running interface looks like this: > lagg0: flags=8843 metric 0 mtu > 1500 > options=507bb MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO> > ether ac:16:2d:1e:b8:80 > inet xxx.xxx.217.100 netmask 0xffffff80 broadcast xxx.xxx.217.127 > inet6 fe80::ae16:2dff:fe1e:b880%lagg0 prefixlen 64 scopeid 0xc > nd6 options=23 > media: Ethernet autoselect > status: active > groups: lagg > laggproto failover lagghash l2,l3,l4 > laggport: oce0 flags=5 > laggport: oce1 flags=0<> > > ndp(8) shows only: > Neighbor Linklayer Address Netif Expire S > Flags > fe80::ae16:2dff:fe1e:b880%lagg0 ac:16:2d:1e:b8:80 lagg0 permanent R > > Other hosts (running RedHat 6) on the same network SLAAC just fine. Does > anyone have insight into this problem or suggestions for troubleshooting? > > -- > Greg Rivers > > > [1] > Internet Control Message Protocol v6 > Type: Router Advertisement (134) > Code: 0 > Checksum: 0x8176 [correct] > [Checksum Status: Good] > Cur hop limit: 64 > Flags: 0x00, Prf (Default Router Preference): Medium > 0... .... = Managed address configuration: Not set > .0.. .... = Other configuration: Not set > ..0. .... = Home Agent: Not set > ...0 0... = Prf (Default Router Preference): Medium (0) > .... .0.. = Proxy: Not set > .... ..0. = Reserved: 0 > Router lifetime (s): 1800 > Reachable time (ms): 0 > Retrans timer (ms): 0 > ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) > Type: Source link-layer address (1) > Length: 1 (8 bytes) > Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) > ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) > Type: Prefix information (3) > Length: 4 (32 bytes) > Prefix Length: 64 > Flag: 0xc0, On-link flag(L), Autonomous address-configuration > flag(A) > 1... .... = On-link flag(L): Set > .1.. .... = Autonomous address-configuration flag(A): Set > ..0. .... = Router address flag(R): Not set > ...0 0000 = Reserved: 0 > Valid Lifetime: 2592000 > Preferred Lifetime: 604800 > Reserved > Prefix: 26xx:xxxx:4013:23:: > ICMPv6 Option (MTU : 9216) > Type: MTU (5) > Length: 1 (8 bytes) > Reserved > MTU: 9216 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Sun Aug 6 03:54:13 2017 Return-Path: Delivered-To: freebsd-stable@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 19FC2DB59D8 for ; Sun, 6 Aug 2017 03:54:13 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (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 BDEFA6F345 for ; Sun, 6 Aug 2017 03:54:12 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:2435:171d:82f4:26a7]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v763s9OP067863 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Aug 2017 22:54:14 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2016; t=1501991654; bh=vh/SmAsfcWwzQFu72r9NZUkpUJSTlYKPG1nn+uCzyzw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mIJmEX9sjokM40CQHQn31YtzGllv3eLrmxfz4SJmMxQe2PVHvc3K+z6HWQR4r9xdf De0+MKmbjvvnYvxFnUym4z7eD2Cx7DG0O6jSGZIOFYrh3j/OsXSgL2yYFELi0QrIL+ AsQgKbtszklvUVo0fbhMbPpWXisRg8frfAK6uqz3Bish2o0PN7sY0FMm8kE0jbG0Zz ZvQPcuGHsRYYqd/7yQwS7L7C0ISXxdZl3zyVFyjZceGH4JJ+2Fn16AIf7ldFhIb+7J nzpQgmoBIsXtS/VZuvoLdlkIz1Q88Yhh+EtR3qrXVFJzKxLDELe8TE/6Yuvc6wSX/Y /7wVWkj3HcWzQ== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:2435:171d:82f4:26a7] claimed to be flake.tharned.org From: Greg Rivers To: Ultima Cc: freebsd-stable@freebsd.org Subject: Re: SLAAC not working Date: Sat, 05 Aug 2017 22:54:06 -0500 Message-ID: <1512869.XSHPEJXeo8@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <1646645.UkMcyRZBVl@flake.tharned.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Sat, 05 Aug 2017 22:54:14 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 03:54:13 -0000 On Saturday, August 05, 2017 20:44:56 Ultima wrote: > Do you have pf or ipfw running? are they accepting ICMP type 128, 129, 135, > 136? the first 2 are for ping requests last 2 for Neighbor > solicitation/advertisement. > Ah, good question. Neither host is running a firewall; I should have mentioned that. Thanks for your reply. -- Greg Rivers From owner-freebsd-stable@freebsd.org Sun Aug 6 04:37:36 2017 Return-Path: Delivered-To: freebsd-stable@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 DFB7ADBC602 for ; Sun, 6 Aug 2017 04:37:36 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 9D9B070BD3 for ; Sun, 6 Aug 2017 04:37:36 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x234.google.com with SMTP id l82so28260957ywc.2 for ; Sat, 05 Aug 2017 21:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dWH7wd6+oSC0UZvNCZrTpNTRBzN9o/4eVs/B81+mZoU=; b=OAWZNovrLTJMKHDauMEeRJkHqbENE1XBI/O2jRnY5wuh//e98W3NnY7vfyZAkY9UNp FMvgBUEY1xBC/EAVFI89fEt95LvNdgS4BBQhh5yYTuVaM7GP6P930DWAx3ikMBVQ/zvI RrK5awR78VKVjh9RykQayc8n1sptBMONBkrxuwkEfdUKp0Gs0WYuysL8Yqai54ScZno3 UYB+YHRlUIT4wRSIUK9IHYLo/x9eqB6lkpz0ZdYKAvKPmDAM/Ph9PWikayatWKAgmW5H Ol5GCOG9ycPq7qXkgi6xK/ybnon+6SAsDYoZF+E19HFNuFQSCLTtvJGy6+byFs6JQMrw 5T3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dWH7wd6+oSC0UZvNCZrTpNTRBzN9o/4eVs/B81+mZoU=; b=sWRgwMGQ6ArR48smRgnVgNmxBlwHI8Ok1pcHHoRaaTXleHXQb1YeVnZ9Tbmni2pmEY aiVBeyLqTVTjD+9lSAIHbHpPIETq7F0omiujWVoF85pYkG+d2RUuEMhloCOxpWneHQmc 5j021li1Ho3DDoM7jLUnmF4U9SSyOkT5JI4FrNU5MgAUHTw/0fevu+Tr12NxCwkWHmkx P4PEfzQNfvgkySk2jf750AzqoiGgWnUCRh1IuthjYuB6pv3c7z4N7dVv48buismJT7U3 8fxoHI7ncHQTBhLAlVIPVL9i/zGw3IICUrxluhFSp+aH+QYZNb9x4iDzbei9ON9YTMyp OK9w== X-Gm-Message-State: AHYfb5iD6vDU2IBJvF58PVwDu1xcr3zEX0TK9/2kV9bvtU263J0mGMx2 Mekxs9+C1DvD1le86dv8KzO0uAzUvOQGNSY= X-Received: by 10.37.231.16 with SMTP id e16mr5690055ybh.306.1501994255708; Sat, 05 Aug 2017 21:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.238.135 with HTTP; Sat, 5 Aug 2017 21:37:35 -0700 (PDT) In-Reply-To: <1512869.XSHPEJXeo8@flake.tharned.org> References: <1646645.UkMcyRZBVl@flake.tharned.org> <1512869.XSHPEJXeo8@flake.tharned.org> From: Ultima Date: Sat, 5 Aug 2017 21:37:35 -0700 Message-ID: Subject: Re: SLAAC not working To: Greg Rivers Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 04:37:37 -0000 Never tested SLAAC on lagg, but your configuration looks correct to me. One flag that I notice that looks questionable is the MTU option being 9216 while the lagg interface is set to 1500. I doubt this would cause SLAAC to fail but it maybe worth investigating. On Sat, Aug 5, 2017 at 8:54 PM, Greg Rivers wrote: > On Saturday, August 05, 2017 20:44:56 Ultima wrote: > > Do you have pf or ipfw running? are they accepting ICMP type 128, 129, > 135, > > 136? the first 2 are for ping requests last 2 for Neighbor > > solicitation/advertisement. > > > Ah, good question. Neither host is running a firewall; I should have > mentioned that. Thanks for your reply. > > -- > Greg Rivers > From owner-freebsd-stable@freebsd.org Sun Aug 6 05:12:05 2017 Return-Path: Delivered-To: freebsd-stable@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 15C0BDBE304 for ; Sun, 6 Aug 2017 05:12:05 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (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 AA95071FE8 for ; Sun, 6 Aug 2017 05:12:04 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:2435:171d:82f4:26a7]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v765C0M3068594 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Aug 2017 00:12:05 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2016; t=1501996326; bh=cEI4iVl1hnzVkkxiFp3bPcnNUAD3KbF5Ms6RjeTIrkI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=QaDnml0uQZlmG7jmOhrMMAKkMg+SgDPLUGXHEGbxWYcTuOy1Ln08WWC+eOQmkdmwb gz0Iol8KOCGR0UvajbTCzjPQryYffff37FJ5wRImCF35nvwk367kc3Ob1OqkUjuvWk a1SmfWjdBQ8smsX9yEdm68/91PgDYGijuBwTHhfnB4SxE1mNWhemMbFlrmd2siUJnI N84LohgpnfSLVZPRu0PFoM+IAcCAmW2mAKTbpcnUSsK+ufkv75UAOYI9R1lBdWRlfi 1LZ+84F8O/YVvn8LtQ28De3bCkOslXZVJsCakEIuf6UDSoF5AC+Twa5NlOoQXFLKUh CXVqzIBjSLtiw== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:2435:171d:82f4:26a7] claimed to be flake.tharned.org From: Greg Rivers To: Ultima Cc: freebsd-stable@freebsd.org Subject: Re: SLAAC not working Date: Sun, 06 Aug 2017 00:11:57 -0500 Message-ID: <13414011.RNdQKF0511@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <1646645.UkMcyRZBVl@flake.tharned.org> <1512869.XSHPEJXeo8@flake.tharned.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Sun, 06 Aug 2017 00:12:06 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 05:12:05 -0000 On Saturday, August 05, 2017 21:37:35 Ultima wrote: > Never tested SLAAC on lagg, but your configuration looks correct to me. One > flag that I notice that looks questionable is the MTU option being 9216 > while the lagg interface is set to 1500. I doubt this would cause SLAAC to > fail but it maybe worth investigating. > I had noticed that too. I'll ask the networking guys why the RA has that MTU option. As you say, I it's probably not the cause: the Linux hosts have have the same hardware and an analogous configuration using the bonding driver. The Linux bond interfaces also have MTU 1500, yet they SLAAC fine: bond0 Link encap:Ethernet HWaddr D0:BF:9C:F1:C9:E8 inet addr:xxx.xxx.212.13 Bcast:xxx.xxx.212.127 Mask:255.255.255.128 inet6 addr: 26xx:xxxx:4013:4:d2bf:9cff:fef1:c9e8/64 Scope:Global inet6 addr: fe80::d2bf:9cff:fef1:c9e8/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:139503168 errors:0 dropped:0 overruns:0 frame:0 TX packets:166569190 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:17165085983 (15.9 GiB) TX bytes:90980707420 (84.7 GiB) It may not be lagg related. As I recall, a few months ago I tried bringing one of the hosts up on oce0 alone, and SLAAC failed then too. I wonder if it's an oce(4) problem? -- Greg Rivers From owner-freebsd-stable@freebsd.org Mon Aug 7 12:33:24 2017 Return-Path: Delivered-To: freebsd-stable@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 21A42DD05CA for ; Mon, 7 Aug 2017 12:33:24 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward18o.cmail.yandex.net (forward18o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::1e8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEAFC68967 for ; Mon, 7 Aug 2017 12:33:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback1o.mail.yandex.net (mxback1o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1b]) by forward18o.cmail.yandex.net (Yandex) with ESMTP id 22DBF22737; Mon, 7 Aug 2017 15:33:21 +0300 (MSK) Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:7]) by mxback1o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ufFpoCmkI7-XKe8FRpT; Mon, 07 Aug 2017 15:33:21 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1502109201; bh=xVzGBPCfG3pJT5wWLUEIiDfDjES60ug2qPGCvOZs3t0=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=szJVEISav20CYMgZgOEr1TeaMrOHezdsosta0HkI0ujkBgkfKMUTlwusB6ywqrw3I Fm/eVbgdQERmHTSE0H8CVChJm070m/2vAQ71KeQHtZSapjHHfRqMNm8wZijfUOYVt5 QIqtXWgJfnMJl7yaoH0CD3QuEtHAHbqvgElq3fME= Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 6v6wSZEQLO-XKvOLvLq; Mon, 07 Aug 2017 15:33:20 +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=1502109200; bh=xVzGBPCfG3pJT5wWLUEIiDfDjES60ug2qPGCvOZs3t0=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=pBef6R2QLdYOutW4ckR0S922ffUGSWT5lGiIpXXfjp83/HBZm9eZKeKvbu0QhU66Q wr2XQdpWEX6M9khnGq9jM2MRCGAn5FmReH7Oad6Umlkxu8hwRAbeLlRuGz6L5C6BbJ cYJnZigTm5JR1rZeyH8DlvnOM6aiTxGYGbOClC+o= Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: SLAAC not working To: Greg Rivers , freebsd-stable@freebsd.org References: <1646645.UkMcyRZBVl@flake.tharned.org> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: Date: Mon, 7 Aug 2017 15:30:21 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1646645.UkMcyRZBVl@flake.tharned.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GMUlBn0lofMNxwpVnDN9FuWBSTBV0l0wC" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 12:33:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GMUlBn0lofMNxwpVnDN9FuWBSTBV0l0wC Content-Type: multipart/mixed; boundary="u0CoWAMIFPwDW9EPinf8dfllhFRNELso2"; protected-headers="v1" From: "Andrey V. Elsukov" To: Greg Rivers , freebsd-stable@freebsd.org Message-ID: Subject: Re: SLAAC not working References: <1646645.UkMcyRZBVl@flake.tharned.org> In-Reply-To: <1646645.UkMcyRZBVl@flake.tharned.org> --u0CoWAMIFPwDW9EPinf8dfllhFRNELso2 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06.08.2017 06:35, Greg Rivers wrote: > The running interface looks like this: > lagg0: flags=3D8843 metric 0 mt= u 1500 > options=3D507bb > ether ac:16:2d:1e:b8:80 > inet xxx.xxx.217.100 netmask 0xffffff80 broadcast xxx.xxx.217.127=20 > inet6 fe80::ae16:2dff:fe1e:b880%lagg0 prefixlen 64 scopeid 0xc=20 > nd6 options=3D23 > media: Ethernet autoselect > status: active > groups: lagg=20 > laggproto failover lagghash l2,l3,l4 > laggport: oce0 flags=3D5 > laggport: oce1 flags=3D0<> You can set net.inet6.icmp6.nd6_debug=3D1 and I think you will see the message that mtu exceeds maxmtu value. --=20 WBR, Andrey V. Elsukov --u0CoWAMIFPwDW9EPinf8dfllhFRNELso2-- --GMUlBn0lofMNxwpVnDN9FuWBSTBV0l0wC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlmIXWIACgkQAcXqBBDI oXrQZggAknTY2HXoaIxxmEwoNRQ0hk5IoA6ewDLultbLwBtYtk+vN+p3vePmDrNY CAxrn3+uAKIE980KSMWvxrTsmmB0wCrhDwvC7GPFqjHf6CHFhNr3sc2XBVCD/38W 4dK0QMRMvP5Nh8JshwUc/z+uyjekyDDxxYtYKylLwbWrzEDTama51cfae96iNLMN Uu2NXSty+74N5hRGEv9jmVTjwN+rsTp6WlnlnK31fnY0u1sHaVQiz4T66u7xGmNS wBPx4BBzzm4H+ChoNsvHG/Fz8NQjRAe1EyFi1IVjtV7kezkULBFPJOIQoMVfhFmh +2xbcMb8dl3okik7YOeUyCyrCtu+vw== =sGKC -----END PGP SIGNATURE----- --GMUlBn0lofMNxwpVnDN9FuWBSTBV0l0wC-- From owner-freebsd-stable@freebsd.org Mon Aug 7 13:00:12 2017 Return-Path: Delivered-To: freebsd-stable@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 CE861DD1F24 for ; Mon, 7 Aug 2017 13:00:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward102o.mail.yandex.net (forward102o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C7876A76A for ; Mon, 7 Aug 2017 13:00:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback14j.mail.yandex.net (mxback14j.mail.yandex.net [IPv6:2a02:6b8:0:1619::90]) by forward102o.mail.yandex.net (Yandex) with ESMTP id 468DE5A01655; Mon, 7 Aug 2017 16:00:00 +0300 (MSK) Received: from smtp2j.mail.yandex.net (smtp2j.mail.yandex.net [2a02:6b8:0:801::ac]) by mxback14j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id MhJrcjnGww-xxwmEB25; Mon, 07 Aug 2017 16:00:00 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1502110800; bh=eMaPBQEe5MRb1n29RN5dnPIuSiRKrGnn5ttGpCJJqHg=; h=Subject:From:To:References:Message-ID:Date:In-Reply-To; b=erG6JmhyIF4mpdQMcK5hLqtWayF+ZkhkPbs2hilUInoCG4s9E6UASLqA9ND3Lma+l 8JFNH9sZSdcJ9in5TVaWrw9itc9A1+2J4vk5SwgiG5Lvm1yckugi2U14Kc0vAb5Vg4 ek5yB0Rzf/mhLoEijOKTo0RLhOSmzSgnBonik+mE= Received: by smtp2j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id GyIsqtcawP-xwLqeKv6; Mon, 07 Aug 2017 15:59:58 +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=1502110798; bh=eMaPBQEe5MRb1n29RN5dnPIuSiRKrGnn5ttGpCJJqHg=; h=Subject:From:To:References:Message-ID:Date:In-Reply-To; b=dR9J+/OoSR2Ps5NG1nGWusB8qqmeyyWs+kQDCBEEo5xxRex26pKpatQWtHoLa3mMs 2xfx/8rvT2vhvFh4lhCn2GpdUJ/kF7DJ9QbJaWwHE5frggTzf/Sl1mDKBbIvdkp8w/ xjzpsdi4u0F0gcrGial/O3O0j7noZOsNcASHB3Zc= Authentication-Results: smtp2j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: SLAAC not working From: "Andrey V. Elsukov" To: Greg Rivers , freebsd-stable@freebsd.org References: <1646645.UkMcyRZBVl@flake.tharned.org> Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: Date: Mon, 7 Aug 2017 15:57:04 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cEIQXNLavsfMX3ewmotgCeSRJbFwXUoFM" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:00:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cEIQXNLavsfMX3ewmotgCeSRJbFwXUoFM Content-Type: multipart/mixed; boundary="Uj5ijQVAsr5HLVAPnqR1g0fkflf1x1cCG"; protected-headers="v1" From: "Andrey V. Elsukov" To: Greg Rivers , freebsd-stable@freebsd.org Message-ID: Subject: Re: SLAAC not working References: <1646645.UkMcyRZBVl@flake.tharned.org> In-Reply-To: --Uj5ijQVAsr5HLVAPnqR1g0fkflf1x1cCG Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07.08.2017 15:30, Andrey V. Elsukov wrote: > On 06.08.2017 06:35, Greg Rivers wrote: >> The running interface looks like this: >> lagg0: flags=3D8843 metric 0 m= tu 1500 >> options=3D507bb >> ether ac:16:2d:1e:b8:80 >> inet xxx.xxx.217.100 netmask 0xffffff80 broadcast xxx.xxx.217.127=20 >> inet6 fe80::ae16:2dff:fe1e:b880%lagg0 prefixlen 64 scopeid 0xc=20 >> nd6 options=3D23 >> media: Ethernet autoselect >> status: active >> groups: lagg=20 >> laggproto failover lagghash l2,l3,l4 >> laggport: oce0 flags=3D5 >> laggport: oce1 flags=3D0<> >=20 > You can set net.inet6.icmp6.nd6_debug=3D1 and I think you will see the > message that mtu exceeds maxmtu value. But it seems, this should only ignore the mtu option. So, set net.inet6.icmp6.nd6_debug=3D1 and show what you have in the ndp -p ndp -r ndp -i lagg0 --=20 WBR, Andrey V. Elsukov --Uj5ijQVAsr5HLVAPnqR1g0fkflf1x1cCG-- --cEIQXNLavsfMX3ewmotgCeSRJbFwXUoFM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlmIY6AACgkQAcXqBBDI oXpZbgf/RBgeUzf6nADgd3qTED6osY0VTJSF+Zel9SKqqfEJLY/RV5GefnAnwrkq AHtsLQ2CM6ZidcmzSVO5SctfTp86ROaITGeOLoKRpBbN8J6XZfT53YLudVer9G2P Q2wiWxeEUGgl+FtN3ZXSE5gmR1Kj7agoIiriZ5GrUVZCQ8iBvduKjVqbbMUI1qHV PSm0hEOyAURcnVX5+EUnv2FCs/UUwpIs2EbJXzjAMnk6pXuOYazqd5io/gcs80IZ nqaUFELBNRfKPTm0/JKx3R52P/l38CA3GCtdOFFBu3l4/3XHnP2hVQ5rLL8wMQVU oH0JFJi4Lt1ZytpJjYd38NKVlTg9Jg== =4gLg -----END PGP SIGNATURE----- --cEIQXNLavsfMX3ewmotgCeSRJbFwXUoFM-- From owner-freebsd-stable@freebsd.org Mon Aug 7 13:00:22 2017 Return-Path: Delivered-To: freebsd-stable@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 559E7DD1F59 for ; Mon, 7 Aug 2017 13:00:22 +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 3D5F06A7BB for ; Mon, 7 Aug 2017 13:00:22 +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 v77Cxt2J012746 for ; Mon, 7 Aug 2017 13:00:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221050] emulators/virtualbox-ose: Bridged network doesn't work (11.1-RELEASE) Date: Mon, 07 Aug 2017 12:59:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vermaden@interia.pl X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vbox@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:00:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221050 vermaden@interia.pl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vermaden@interia.pl --- Comment #15 from vermaden@interia.pl --- Compilation fails for me: # make -C /usr/ports/emulators/virtualbox-ose-kmod install (...) rm -rf $backupdir; exit $rc gmake[7]: Leaving directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/bootstrap/sed/doc' Making all in testsuite gmake[7]: Entering directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/bootstrap/sed/testsuite' gmake[7]: Nothing to be done for 'all'. gmake[7]: Leaving directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/bootstrap/sed/testsuite' gmake[7]: Entering directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/bootstrap/sed' gmake[7]: Leaving directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/bootstrap/sed' gmake[6]: Leaving directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/bootstrap/sed' gmake[5]: Leaving directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/bootstrap/sed' cp -f /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/bootstrap/sed/sed/sed /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/bootstrap/kmk/kmk_sed ln -s /bin/echo /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/bootstrap/kmk/kmk_echo cp -f /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/bootstrap/kmk/config.h /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/config.h= .freebsd echo "" >> /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/config.h= .freebsd echo '#include "inlined_memchr.h"' >> /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/config.h= .freebsd cp -f /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/bootstrap/sed/config.h /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/sed/config.h= .freebsd KBUILD_BIN_PATH=3D/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.999= 8/out/freebsd.amd64/release/bootstrap/kmk /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/bootstrap/kmk/kmk -C /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998 KBUILD_BOOTSTRAP=3D1 kmk: Entering directory `/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998' Config.kmk:87: Neither SvnInfo nor .svn/* was found in the root. Will have = to cook up something too keep the build happy. Config.kmk:99: /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/SvnInfo.kmk: No such file or directory kmk_builtin_rm -f /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/SvnInfo.kmk kmk_builtin_mkdir -p /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj kmk_builtin_append /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/SvnInfo.kmk 'KBUILD_SVN_REV :=3D 0' kmk_builtin_append /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/SvnInfo.kmk 'KBUILD_SVN_URL :=3D /dev/null' kmk: Leaving directory `/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998' kmk: Entering directory `/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998' Config.kmk:87: Neither SvnInfo nor .svn/* was found in the root. Will have = to cook up something too keep the build happy. kBuild: Pass - Build Programs kBuild: Pass - Libraries kBuild: Compiling kDep - /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/kDep.c kBuild: Compiling kUtil - /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/crc32.c kBuild: Compiling kUtil - /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/md5.c kBuild: Compiling kUtil - /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/maybe_co= n_write.c In file included from /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/crc32.c:= 48:0: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:266:1: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ In file included from /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/uni= std.h:46:0, from /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/maybe_co= n_write.c:45: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:266:1: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:268:1: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:268:1: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ In file included from /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/mytypes.= h:36:0, from /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/md5.h:4, from /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/md5.c:19: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:266:1: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:268:1: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ kmk: *** [/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/obj/kUtil/crc32.o] Error 1 The failing command: @gcc48 -c -O2 -g -O3 -m64 -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/kStuff= /include -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/glob -I/usr/local/include -DKBUILD_VERSION_MAJOR=3D0 -DKBUILD_VERSION_MINOR=3D1 -DKBUILD_VERSION_PATCH=3D9998 -DKBUILD_OS_FREEBSD -DKBUILD_ARCH_AMD64 -DNDE= BUG -Wp,-MD,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kUtil/crc32.o.dep -Wp,-MT,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kUtil/crc32.o -Wp,-MP -o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/kUtil/crc32.o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/crc32.c kmk: *** Waiting for unfinished jobs.... kmk: *** [/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/obj/kUtil/maybe_con_write.o] Error 1 The failing command: @gcc48 -c -O2 -g -O3 -m64 -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/kStuff= /include -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/glob -I/usr/local/include -DKBUILD_VERSION_MAJOR=3D0 -DKBUILD_VERSION_MINOR=3D1 -DKBUILD_VERSION_PATCH=3D9998 -DKBUILD_OS_FREEBSD -DKBUILD_ARCH_AMD64 -DNDE= BUG -Wp,-MD,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kUtil/maybe_con_write.o.dep -Wp,-MT,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kUtil/maybe_con_write.o -Wp,-MP -o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/kUtil/maybe_con_write.o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/maybe_co= n_write.c In file included from /usr/include/sys/time.h:37:0, from /usr/include/sys/stat.h:99, from /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/kDep.c:4= 4: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:266:1: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys= /types.h:268:1: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ kmk: *** [/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/obj/kUtil/md5.o] Error 1 The failing command: @gcc48 -c -O2 -g -O3 -m64 -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/kStuff= /include -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/glob -I/usr/local/include -DKBUILD_VERSION_MAJOR=3D0 -DKBUILD_VERSION_MINOR=3D1 -DKBUILD_VERSION_PATCH=3D9998 -DKBUILD_OS_FREEBSD -DKBUILD_ARCH_AMD64 -DNDE= BUG -Wp,-MD,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kUtil/md5.o.dep -Wp,-MT,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kUtil/md5.o -Wp,-MP -o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/kUtil/md5.o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/md5.c kmk: *** [/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd= 64/release/obj/kDep/kDep.o] Error 1 The failing command: @gcc48 -c -O2 -g -O3 -m64 -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/kStuff= /include -I/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/glob -I/usr/local/include -DKBUILD_VERSION_MAJOR=3D0 -DKBUILD_VERSION_MINOR=3D1 -DKBUILD_VERSION_PATCH=3D9998 -DKBUILD_OS_FREEBSD -DKBUILD_ARCH_AMD64 -DNDE= BUG -Wp,-MD,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kDep/kDep.o.dep -Wp,-MT,/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/free= bsd.amd64/release/obj/kDep/kDep.o -Wp,-MP -o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/obj/kDep/kDep.o /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/lib/kDep.c kmk: Leaving directory `/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998' kmk: Entering directory `/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998' kmk: *** Exiting with status 2 gmake[4]: *** [bootstrap.gmk:221: /usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd6= 4/release/bootstrap/ts-stage2-build] Error 2 gmake[4]: Leaving directory '/usr/ports/obj/usr/ports/devel/kBuild/work/kBuild-0.1.9998' ./kBuild/env.sh: info: rc=3D2: gmake -f bootstrap.gmk *** Error code 2 Stop. make[3]: stopped in /usr/ports/devel/kBuild *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/kBuild *** Error code 1 Stop. make[1]: stopped in /usr/ports/emulators/virtualbox-ose-kmod *** Error code 1 Stop. make: stopped in /usr/ports/emulators/virtualbox-ose-kmod --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Mon Aug 7 13:16:57 2017 Return-Path: Delivered-To: freebsd-stable@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 27D3ADD2F6D for ; Mon, 7 Aug 2017 13:16:57 +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 149FC6B75D for ; Mon, 7 Aug 2017 13:16:57 +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 v77DGuas083253 for ; Mon, 7 Aug 2017 13:16:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221050] emulators/virtualbox-ose: Bridged network doesn't work (11.1-RELEASE) Date: Mon, 07 Aug 2017 13:16:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vbox@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:16:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221050 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-stable@FreeBSD.org |gerald@FreeBSD.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 211 | |11, | |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 212 | |37 --- Comment #16 from Kubilay Kocak --- (In reply to vermaden from comment #15) Please use attachments (not comments) for long bodfies of text like log/bui= ld files, configuration files, etc. The errors looks very much like: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221111(gcc6-aux) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221237 (gcc5) But for gcc48 CC maintainer --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Mon Aug 7 13:20:40 2017 Return-Path: Delivered-To: freebsd-stable@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 6E3F0DD339C for ; Mon, 7 Aug 2017 13:20:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC876BAF4 for ; Mon, 7 Aug 2017 13:20:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4843EDD339B; Mon, 7 Aug 2017 13:20:40 +0000 (UTC) Delivered-To: stable@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 45A5EDD3399 for ; Mon, 7 Aug 2017 13:20:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 0BF126BAF2 for ; Mon, 7 Aug 2017 13:20:39 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-vk0-x22e.google.com with SMTP id g189so1457870vke.5 for ; Mon, 07 Aug 2017 06:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=Ga/4xt2pMQOX9oGi4wwuA/onnWl2+HgfazXnZngdu78=; b=doNMzi7sdXvjcwCdgTfZR63p5n0fOwtUlnmbIFqM2pCVl7E+KvEypCUXYmx8+KzHPG td4jlnKXsWgiE/GMFaIll9PpgzI3enG45eQ5VB03dgzbgNqMHC6c+KkP/ybLUgMVoiUj lF2AOqRp2Ion+HaaW1DmcAWG7sUZcXHY200bigyrZIpHpD4BhLvSozMBaQLR3sZ/FZgp v7Kpbf4MqXVHv9vTUQvwEaR5Z+UPTWBkKEbW2nxhUjwpkMHl/NcXVVI3cI+Ct7dLZXg6 SVusx8JQbp51u4bzzs74WagM5d53SnUeHOBYhp/AgYrGObyxjIMkioWY4jt0oxjojzCT bXSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Ga/4xt2pMQOX9oGi4wwuA/onnWl2+HgfazXnZngdu78=; b=jmbijulppejIATBhR33S079lj/MmrxdO1y1HfEU8RCQxEKyhNfm8QmgZpLZxyKorq5 DvLVlrWCmTTNHfzQcHZyCU33CDqjZgWJRT3dmNEXXUoVXTn1a57KE9d+tKiFbrF/mRdi NOZaC4mn7t/pa101o+xzhkg6zHOtH9yJE+xKUyMnFOs28GiqYjnZ/IDyLZxyJ/SNq/6E fXrBEjU0YfWNonIrg0bHjRobn6bwkxCwkJhULm8dvctJ86o7kut/Rd5zXHaxnehOQ3EM bWMVIV3f0pFh5Ls266rZ/8jwvLaEzrnQxSzyu3peCQMpVUY9UZgpKi2YrbbLHF3EMsxX HlzQ== X-Gm-Message-State: AHYfb5hYAz9ppGkT18MIaqiK/Ln7pRDa+GZfjW6m9mu4dZhrdr6TSqw8 ST1nEWbQpD9BojG/q50ql4RlPsTk3wtSl5E= X-Received: by 10.31.171.129 with SMTP id u123mr300602vke.82.1502112038683; Mon, 07 Aug 2017 06:20:38 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.176.3.148 with HTTP; Mon, 7 Aug 2017 06:20:38 -0700 (PDT) From: Maxim Sobolev Date: Mon, 7 Aug 2017 06:20:38 -0700 X-Google-Sender-Auth: Ho7WG_inkUf0MWn4cDy9RWLlP-4 Message-ID: Subject: 11.1-RELEASE has issue with system headers in pedantic mode (type nullability specifier) To: stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:20:40 -0000 Hi, we noticed that some of our internal packages fail the build on 11.1 now with -pedantic: *00:31:09.178* Warning: Object directory not changed from original /tmp/mnt/dncd/work/dncd-20170627161415*00:31:09.178* cc -pipe -g3 -O0 -pipe -fstack-protector -fno-strict-aliasing -Wall -pedantic -O0 -g3 -g3 -O0 -pipe -MD -MF.depend.main.o -MTmain.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c main.c -o main.o*00:31:09.455* In file included from main.c:17:*00:31:09.456* /usr/include/err.h:63:27: error: type nullability specifier '_Nullable' is a Clang extension [-Werror,-Wnullability-extension]*00:31:09.456* void err_set_exit(void (* _Nullable)(int));*00:31:09.456* ^*00:31:09.456* In file included from main.c:19:*00:31:09.456* /usr/include/signal.h:87:27: error: type nullability specifier '_Nonnull' is a Clang extension [-Werror,-Wnullability-extension]*00:31:09.456* int sigpending(sigset_t * _Nonnull); I am not sure what the solution might be, perhaps change pedantic to make this condition non-fatal in pedantic mode? -Max From owner-freebsd-stable@freebsd.org Mon Aug 7 15:20:25 2017 Return-Path: Delivered-To: freebsd-stable@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 2617FDD8FDD for ; Mon, 7 Aug 2017 15:20:25 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id EBDE9701AB for ; Mon, 7 Aug 2017 15:20:24 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mailman.ysv.freebsd.org (Postfix) id E849BDD8FDA; Mon, 7 Aug 2017 15:20:24 +0000 (UTC) Delivered-To: stable@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 E7CC8DD8FD9 for ; Mon, 7 Aug 2017 15:20:24 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 AB564701A9 for ; Mon, 7 Aug 2017 15:20:24 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ua0-x22d.google.com with SMTP id f9so3184017uaf.4 for ; Mon, 07 Aug 2017 08:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=mqEytjiJjXiT9Q6ZKOpEG2qk6cmcnSlfkutCt1zQkhA=; b=PqirG1+r4qoFiq955jAYQSLSpUAhiIjNwpqPzC+8MHG8TXykN0LIYxly0GbHF3jUzw mjcUlI2BkdltpfD1X0B2duLQkNov5fqtEky/M0Ji83FtfCbRnQrH+3NuwTs3+uryyWZ5 0wjF5fRsp1VoZsMAPQZvtyw9SoKpuAvvMTm1beB1gu5FXLedQu8LuYVKLZY89ptvLfpJ O52xVRwEeOcKk0DJPcA68tEn7tnkVg6yyh+Q0Bts+pX0/iLsUnAb18OSza33JMw8cvIn eDgq/a+vLLx8GR+zWPa/XX5WfcVF1UZlCkeMdBRVttPwzO7XCLgCy0gpbnFizLtXcHt6 cS3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=mqEytjiJjXiT9Q6ZKOpEG2qk6cmcnSlfkutCt1zQkhA=; b=UeZzHoh4m8Zm50uS9tL4vLKDY4Eb7XkWFgPz38McQuytkccNlgD5NGIlFYknwEvtjt afBnYQLDvR3LvioiAA3bQuOpjaLfmep9fNehe9wueKPpATPf19qtEjSA5fzkHmlJ99NW Kfpn/9zmU18R2I5ebTN0lGSV1ifx6Re7r39Hj3S8vgtPX7XXB2QWrnrsMpnu90YWGKfM kxZgaqF4lDRFrtr+Q8+ptlfGkogZFVT/muoRpjbCyTcLzkPsOn6YvZ4iHe9QEOALRy92 Lpj9oWTx0D9CzrLcAa2P/9GWb7vEoUfsJV3l9N+DE+v4KCPMqhEbExDbHqfeq9kfFtgx lZIg== X-Gm-Message-State: AHYfb5iNiJTsE4y8fSeDKp3+r2G5+WAzC1jGb0Qya3tUXBg36YrDd9nx noVQNFmAwrulL9lROE6KQeeOuMG1UHwTpUE= X-Received: by 10.176.23.77 with SMTP id k13mr650540uaf.128.1502119223576; Mon, 07 Aug 2017 08:20:23 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.176.3.148 with HTTP; Mon, 7 Aug 2017 08:20:23 -0700 (PDT) In-Reply-To: References: From: Maxim Sobolev Date: Mon, 7 Aug 2017 08:20:23 -0700 X-Google-Sender-Auth: 03SpWn9Bl2vR5IaB8VptGdr8xRw Message-ID: Subject: Re: 11.1-RELEASE has issue with system headers in pedantic mode (type nullability specifier) To: stable@freebsd.org, freebsd-toolchain@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:20:25 -0000 One way to defeat this would be to mark those headers with the #pragma clang system_header. As per: https://clang.llvm.org/docs/UsersManual.html#id27 -Max On Mon, Aug 7, 2017 at 6:20 AM, Maxim Sobolev wrote: > Hi, we noticed that some of our internal packages fail the build on 11.1 > now with -pedantic: > > *00:31:09.178* Warning: Object directory not changed from original /tmp/m= nt/dncd/work/dncd-20170627161415*00:31:09.178* cc -pipe -g3 -O0 -pipe -fsta= ck-protector -fno-strict-aliasing -Wall -pedantic -O0 -g3 -g3 -O0 -pipe -= MD -MF.depend.main.o -MTmain.o -std=3Dgnu99 -fstack-protector-strong -Wsys= tem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-ta= utological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-= function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-pac= ked-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunus= ed-arguments -c main.c -o main.o*00:31:09.455* In file included from main.= c:17:*00:31:09.456* /usr/include/err.h:63:27: error: type nullability speci= fier '_Nullable' is a Clang extension [-Werror,-Wnullability-extension]*00:= 31:09.456* void err_set_exit(void (* _Nullable)(int));*00:31:09.456* = ^*00:31:09.456* In file included from main.c:19:*= 00:31:09.456* /usr/include/signal.h:87:27: error: type nullability specifie= r '_Nonnull' is a Clang extension [-Werror,-Wnullability-extension]*00:31:0= 9.456* int sigpending(sigset_t * _Nonnull); > > > I am not sure what the solution might be, perhaps change pedantic to make= this condition non-fatal in pedantic mode? > > > -Max > > From owner-freebsd-stable@freebsd.org Mon Aug 7 15:23:57 2017 Return-Path: Delivered-To: freebsd-stable@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 72948DD9398 for ; Mon, 7 Aug 2017 15:23:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0E9705BA for ; Mon, 7 Aug 2017 15:23:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5A7A9DD9397; Mon, 7 Aug 2017 15:23:57 +0000 (UTC) Delivered-To: stable@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 59ECBDD9396; Mon, 7 Aug 2017 15:23:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F26DE705B8; Mon, 7 Aug 2017 15:23:56 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v77FNlCY091322 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Aug 2017 15:23:48 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: d60e724c-75b0-4b63-9702-f4a9d2bf6793: Host host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: 11.1-RELEASE has issue with system headers in pedantic mode (type nullability specifier) From: David Chisnall In-Reply-To: Date: Mon, 7 Aug 2017 16:23:42 +0100 Cc: stable@freebsd.org, freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <64B5D885-9A86-427C-900E-D5FDD6D791BB@FreeBSD.org> References: To: Maxim Sobolev X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:23:57 -0000 On 7 Aug 2017, at 16:20, Maxim Sobolev wrote: >=20 > One way to defeat this would be to mark those headers with the #pragma > clang system_header. As per: >=20 > https://clang.llvm.org/docs/UsersManual.html#id27 That won=E2=80=99t fix the issue, because base (as you can see from the = passed compile command) is compiled with -Wsystem-headers, which issues = warnings even in system headers. This is increasingly unhelpful and = must, for example, be turned off when compiling anything written in C++ = because of warnings in libc++ headers. David From owner-freebsd-stable@freebsd.org Mon Aug 7 16:10:01 2017 Return-Path: Delivered-To: freebsd-stable@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 1B365DAEDB4; Mon, 7 Aug 2017 16:10:01 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: from mail.takwa.de (antares.takwa.de [5.9.72.166]) by mx1.freebsd.org (Postfix) with ESMTP id D5B9C71E7A; Mon, 7 Aug 2017 16:10:00 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: by mail.takwa.de (Postfix, from userid 65534) id A48DA5203; Mon, 7 Aug 2017 17:59:54 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.takwa.de X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 Received: from [192.168.10.5] (unknown [62.246.110.10]) by mail.takwa.de (Postfix) with ESMTPSA id 58FDD5201; Mon, 7 Aug 2017 17:59:54 +0200 (CEST) From: Michael Schmiedgen Subject: [USB] hang after upgrade from 10.0 to 10.1, ZFS or callout() related? To: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Message-ID: Date: Mon, 7 Aug 2017 17:59:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:10:01 -0000 Hi list, after upgrading kernel from 11.0 to 11.1 the boot process stopped, waiting forever for some USB stuff. I tried to skip waiting with hw.usb.no_boot_wait="1" in /boot/loader.conf but then I got a very strange ZFS 'mount error 5', which I had some time ago upgrading from 10.0 to 10.1. That error did magically went away with 11.0, and now it seems to pop up again: https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052900.html https://lists.freebsd.org/pipermail/freebsd-stable/2014-December/081192.html So I reset the boot wait option to default again and switched on some USB debug options: https://imgur.com/a/xzkrC Anybody? Thanks, Michael -- ___________________________ Michael Schmiedgen, BSc Senior Software Engineer Takwa GmbH Friedrich-List-Str. 36 99096 Erfurt GERMANY Tel +49 361 6534096 Fax +49 361 6534097 Mail schmiedgen@takwa.de Web http://www.takwa.de/ ___________________________ Amtsgericht Jena HRB 112964 Geschäftsführung: Ingo Buchholz From owner-freebsd-stable@freebsd.org Mon Aug 7 16:10:23 2017 Return-Path: Delivered-To: freebsd-stable@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 C3C64DAEE79 for ; Mon, 7 Aug 2017 16:10: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 AF9B871F91 for ; Mon, 7 Aug 2017 16:10: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 v77GALI1014420 for ; Mon, 7 Aug 2017 16:10:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Mon, 07 Aug 2017 16:10:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:10:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress CC| |sbruno@FreeBSD.org --- Comment #13 from Sean Bruno --- (In reply to Cassiano Peixoto from comment #8) For NetMap, yes. That would be a different issue. Which driver? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Mon Aug 7 16:12:39 2017 Return-Path: Delivered-To: freebsd-stable@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 1DFC6DB36CB; Mon, 7 Aug 2017 16:12:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 DA19C72595; Mon, 7 Aug 2017 16:12:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 68F1926080B; Mon, 7 Aug 2017 18:12:30 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 10.0 to 10.1, ZFS or callout() related? To: Michael Schmiedgen , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org References: From: Hans Petter Selasky Message-ID: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> Date: Mon, 7 Aug 2017 18:10:16 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:12:39 -0000 On 08/07/17 17:59, Michael Schmiedgen wrote: > Hi list, > > after upgrading kernel from 11.0 to 11.1 the boot process stopped, > waiting forever for some USB stuff. I tried to skip waiting with > > hw.usb.no_boot_wait="1" > > in /boot/loader.conf but then I got a very strange ZFS 'mount error 5', > which I had some time ago upgrading from 10.0 to 10.1. That error did > magically went away with 11.0, and now it seems to pop up again: > > https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052900.html > > > https://lists.freebsd.org/pipermail/freebsd-stable/2014-December/081192.html > Can you try getting the dmesg. You can also disable USB enumeration setting these: hw.usb.disable_enumeration: 0 dev.uhub.2.disable_enumeration: 0 dev.uhub.1.disable_enumeration: 0 dev.uhub.0.disable_enumeration: 0 Are you sure you loaded all drivers, like XHCI, EHCI, OHCI, UHCI ? DOes the BIOS offer any USB options? --HPS > > > So I reset the boot wait option to default again and switched on some USB > debug options: > > https://imgur.com/a/xzkrC > > > Anybody? Thanks, > Michael > From owner-freebsd-stable@freebsd.org Mon Aug 7 16:28:11 2017 Return-Path: Delivered-To: freebsd-stable@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 D281CDB47DD; Mon, 7 Aug 2017 16:28:11 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: from mail.takwa.de (antares.takwa.de [5.9.72.166]) by mx1.freebsd.org (Postfix) with ESMTP id 7C50C7317D; Mon, 7 Aug 2017 16:28:10 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: by mail.takwa.de (Postfix, from userid 65534) id 1722B521E; Mon, 7 Aug 2017 18:28:10 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.takwa.de X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 Received: from [192.168.10.5] (unknown [62.246.110.10]) by mail.takwa.de (Postfix) with ESMTPSA id 5D4E0521B; Mon, 7 Aug 2017 18:28:09 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related? To: Hans Petter Selasky , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> From: Michael Schmiedgen Message-ID: <2f3f1931-cfbc-124c-3ecc-6e8b71cc7b52@takwa.de> Date: Mon, 7 Aug 2017 18:28:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:28:11 -0000 On 07.08.2017 18:10, Hans Petter Selasky wrote: > > Can you try getting the dmesg. > > You can also disable USB enumeration setting these: > > hw.usb.disable_enumeration: 0 > dev.uhub.2.disable_enumeration: 0 > dev.uhub.1.disable_enumeration: 0 > dev.uhub.0.disable_enumeration: 0 > > Are you sure you loaded all drivers, like XHCI, EHCI, OHCI, UHCI ? DOes the BIOS offer any USB options? > It is a generic 11.1 kernel. I already tried hw.usb.disable_enumeration="1" but that triggered the strange 'ZFS error 5'. Part of the debug dmesg with 11.0 kernel below. Thanks, Michael dmesg: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023165148 endpoint=0xfffff800231640d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023196148 endpoint=0xfffff8002318f0d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff80023165148, endpoint=0xfffff800231640d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff800231640d8 edesc=0xfffff80023164720 isoc_next=0 toggle_next=0usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: bEndpointAddress=0x00usbd_transfer_submit: xfer=0xfffff80023196148, endpoint=0xfffff8002318f0d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff8002318f0d8usb_dump_queue: endpoint=0xfffff800231640d8 xfer: edesc=0xfffff8002318f720 isoc_next=0 toggle_next=0 Aug 7 18:26:34 antares kernel: bEndpointAddress=0x00usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff8002318f0d8 xfer: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023196148 endpoint=0xfffff8002318f0d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023165148 endpoint=0xfffff800231640d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff80023165148, endpoint=0xfffff800231640d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff800231640d8usbd_transfer_submit: xfer=0xfffff80023196148, endpoint=0xfffff8002318f0d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: edesc=0xfffff80023164720 isoc_next=0 toggle_next=0usb_dump_endpoint: endpoint=0xfffff8002318f0d8 bEndpointAddress=0x00 edesc=0xfffff8002318f720 isoc_next=0 toggle_next=0 Aug 7 18:26:34 antares kernel: bEndpointAddress=0x00usb_dump_queue: endpoint=0xfffff800231640d8 xfer: Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff8002318f0d8 xfer: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023196148 endpoint=0xfffff8002318f0d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023165148 endpoint=0xfffff800231640d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff80023196148, endpoint=0xfffff8002318f0d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff8002318f0d8usbd_transfer_submit: xfer=0xfffff80023165148, endpoint=0xfffff800231640d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: edesc=0xfffff8002318f720 isoc_next=0 toggle_next=0usb_dump_endpoint: endpoint=0xfffff800231640d8 bEndpointAddress=0x00 edesc=0xfffff80023164720 isoc_next=0 toggle_next=0 Aug 7 18:26:34 antares kernel: bEndpointAddress=0x00usb_dump_queue: endpoint=0xfffff8002318f0d8 xfer: Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff800231640d8 xfer: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023196148 endpoint=0xfffff8002318f0d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023165148 endpoint=0xfffff800231640d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff80023196148, endpoint=0xfffff8002318f0d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff8002318f0d8usbd_transfer_submit: xfer=0xfffff80023165148, endpoint=0xfffff800231640d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: edesc=0xfffff8002318f720 isoc_next=0 toggle_next=0usb_dump_endpoint: endpoint=0xfffff800231640d8 bEndpointAddress=0x00 edesc=0xfffff80023164720 isoc_next=0 toggle_next=0 Aug 7 18:26:34 antares kernel: bEndpointAddress=0x00usb_dump_queue: endpoint=0xfffff8002318f0d8 xfer: Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff800231640d8 xfer: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023196148 endpoint=0xfffff8002318f0d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023165148 endpoint=0xfffff800231640d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_flags: Handle Request function is set Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff800231c5148, endpoint=0xfffff800231c00d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff800231c00d8 edesc=0xfffff800231c0720 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff800231c00d8 xfer: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff800231c5148 endpoint=0xfffff800231c00d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff800231c5148, endpoint=0xfffff800231c00d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff800231c00d8 edesc=0xfffff800231c0720 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff800231c00d8 xfer: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff800231c5148 endpoint=0xfffff800231c00d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff800231c5148, endpoint=0xfffff800231c00d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff800231c00d8 edesc=0xfffff800231c0720 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff800231c00d8 xfer: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff800231c5148 endpoint=0xfffff800231c00d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff800231c5148, endpoint=0xfffff800231c00d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff800231c00d8 edesc=0xfffff800231c0720 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff800231c00d8 xfer: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff800231c5148 endpoint=0xfffff800231c00d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff80023196148, endpoint=0xfffff8002318f0d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff8002318f0d8 edesc=0xfffff8002318f720 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff8002318f0d8 xfer: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023196148 endpoint=0xfffff8002318f0d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=0 Aug 7 18:26:34 antares kernel: usbd_transfer_submit: xfer=0xfffff80023196148, endpoint=0xfffff8002318f0d8, nframes=2, dir=read Aug 7 18:26:34 antares kernel: usb_dump_endpoint: endpoint=0xfffff8002318f0d8 edesc=0xfffff8002318f720 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Aug 7 18:26:34 antares kernel: usb_dump_queue: endpoint=0xfffff8002318f0d8 xfer: Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter Aug 7 18:26:34 antares kernel: usbd_pipe_start: start Aug 7 18:26:34 antares kernel: usbd_transfer_done: err=USB_ERR_NORMAL_COMPLETION Aug 7 18:26:34 antares kernel: usbd_callback_wrapper_sub: xfer=0xfffff80023196148 endpoint=0xfffff8002318f0d8 sts=0 alen=12, slen=12, afrm=2, nfrm=2 Aug 7 18:26:34 antares kernel: usbd_do_request_callback: st=1 Aug 7 18:26:34 antares kernel: usbd_do_request_flags: Handle Request function is set Aug 7 18:26:38 antares kernel: usb_needs_explore: Aug 7 18:26:38 antares kernel: usb_bus_powerd: bus=0xfffffe000118a428 Aug 7 18:26:38 antares kernel: usb_bus_powerd: Recomputing power masks Aug 7 18:26:38 antares kernel: usbd_do_request_flags: Handle Request function is set -- ___________________________ Michael Schmiedgen, BSc Senior Software Engineer Takwa GmbH Friedrich-List-Str. 36 99096 Erfurt GERMANY Tel +49 361 6534096 Fax +49 361 6534097 Mail schmiedgen@takwa.de Web http://www.takwa.de/ ___________________________ Amtsgericht Jena HRB 112964 Geschäftsführung: Ingo Buchholz From owner-freebsd-stable@freebsd.org Mon Aug 7 16:48:21 2017 Return-Path: Delivered-To: freebsd-stable@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 A9C27DB5C6B; Mon, 7 Aug 2017 16:48:21 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: from mail.takwa.de (antares.takwa.de [5.9.72.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5F16673DD8; Mon, 7 Aug 2017 16:48:20 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: by mail.takwa.de (Postfix, from userid 65534) id E7458806B; Mon, 7 Aug 2017 18:48:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.takwa.de X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 Received: from [192.168.10.5] (unknown [62.246.110.10]) by mail.takwa.de (Postfix) with ESMTPSA id 58E468067; Mon, 7 Aug 2017 18:48:19 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 10.0 to 10.1, ZFS or callout() related? To: Hans Petter Selasky , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> From: Michael Schmiedgen Message-ID: <34864f60-5117-c80b-a1b3-4e73a978cdc6@takwa.de> Date: Mon, 7 Aug 2017 18:48:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:48:21 -0000 On 07.08.2017 18:10, Hans Petter Selasky wrote: > > Are you sure you loaded all drivers, like XHCI, EHCI, OHCI, UHCI ? DOes the BIOS offer any USB options? https://imgur.com/a/YN428 It seems like some cheapo hardware. BTW, after the hang I requested KVM access at our hoster, so there is possible new USB interference with the (crappy) KVM hardware too. But the hang exist before the KVM was attached. Disabeling dev.uhub.2.disable_enumeration="1" dev.uhub.1.disable_enumeration="1" dev.uhub.0.disable_enumeration="1" leads to a hang and this console output: https://imgur.com/a/WiiQW Thanks, Michael -- ___________________________ Michael Schmiedgen, BSc Senior Software Engineer Takwa GmbH Friedrich-List-Str. 36 99096 Erfurt GERMANY Tel +49 361 6534096 Fax +49 361 6534097 Mail schmiedgen@takwa.de Web http://www.takwa.de/ ___________________________ Amtsgericht Jena HRB 112964 Geschäftsführung: Ingo Buchholz From owner-freebsd-stable@freebsd.org Mon Aug 7 17:07:16 2017 Return-Path: Delivered-To: freebsd-stable@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 4CB09DB705A; Mon, 7 Aug 2017 17:07:16 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: from mail.takwa.de (antares.takwa.de [5.9.72.166]) by mx1.freebsd.org (Postfix) with ESMTP id 12DE77485A; Mon, 7 Aug 2017 17:07:15 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: by mail.takwa.de (Postfix, from userid 65534) id A407851A7; Mon, 7 Aug 2017 19:07:14 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.takwa.de X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 Received: from [192.168.10.5] (unknown [62.246.110.10]) by mail.takwa.de (Postfix) with ESMTPSA id 4860C51A5; Mon, 7 Aug 2017 19:07:14 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related? To: Hans Petter Selasky , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> From: Michael Schmiedgen Message-ID: <5941d75e-8995-cc84-c1eb-482e8135d307@takwa.de> Date: Mon, 7 Aug 2017 19:07:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:07:16 -0000 On 07.08.2017 18:10, Hans Petter Selasky wrote: > > Are you sure you loaded all drivers, like XHCI, EHCI, OHCI, UHCI ? DOes the BIOS offer any USB options? > After enabling the 'USB hands off' in BIOS I got the strange 'error 5' with 11.1, disable_enumeration was not enabled BTW: https://imgur.com/a/67jV1 Switching back to 11.0 but still with 'USB hands off' activated, everything is fine. Michael -- ___________________________ Michael Schmiedgen, BSc Senior Software Engineer Takwa GmbH Friedrich-List-Str. 36 99096 Erfurt GERMANY Tel +49 361 6534096 Fax +49 361 6534097 Mail schmiedgen@takwa.de Web http://www.takwa.de/ ___________________________ Amtsgericht Jena HRB 112964 Geschäftsführung: Ingo Buchholz From owner-freebsd-stable@freebsd.org Mon Aug 7 17:11:37 2017 Return-Path: Delivered-To: freebsd-stable@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 3AEE0DB762A; Mon, 7 Aug 2017 17:11:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 F34E974B28; Mon, 7 Aug 2017 17:11:36 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 354F326080B; Mon, 7 Aug 2017 19:11:34 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related? To: Michael Schmiedgen , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> <2f3f1931-cfbc-124c-3ecc-6e8b71cc7b52@takwa.de> From: Hans Petter Selasky Message-ID: Date: Mon, 7 Aug 2017 19:09:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <2f3f1931-cfbc-124c-3ecc-6e8b71cc7b52@takwa.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:11:37 -0000 On 08/07/17 18:28, Michael Schmiedgen wrote: > dmesg: > > Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter > Aug 7 18:26:34 antares kernel: usbd_pipe_enter: enter > Aug 7 18:26:34 antares kernel: usbd_pipe_start: start > Aug 7 18:26:34 antares kernel: usbd_pipe_start: start > Aug 7 18:26:34 antares kernel: usbd_transfer_done: > err=USB_ERR_NORMAL_COMPLETION > Aug 7 18:26:34 antares kernel: usbd_transfer_done: > err=USB_ERR_NORMAL_COMPLETION > Aug 7 18:26:34 antares kernel Can you get dmesg without the USB debug enabled? --HPS From owner-freebsd-stable@freebsd.org Mon Aug 7 17:17:03 2017 Return-Path: Delivered-To: freebsd-stable@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 BE69FDB7B11; Mon, 7 Aug 2017 17:17:03 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: from mail.takwa.de (antares.takwa.de [5.9.72.166]) by mx1.freebsd.org (Postfix) with ESMTP id 498F374ED4; Mon, 7 Aug 2017 17:17:02 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: by mail.takwa.de (Postfix, from userid 65534) id 59DCB806C; Mon, 7 Aug 2017 19:17:01 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.takwa.de X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED,BAYES_50 autolearn=disabled version=3.4.1 Received: from [192.168.10.5] (unknown [62.246.110.10]) by mail.takwa.de (Postfix) with ESMTPSA id 651F48068; Mon, 7 Aug 2017 19:17:00 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related? To: Hans Petter Selasky , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> <2f3f1931-cfbc-124c-3ecc-6e8b71cc7b52@takwa.de> From: Michael Schmiedgen Message-ID: Date: Mon, 7 Aug 2017 19:17:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:17:03 -0000 On 07.08.2017 19:09, Hans Petter Selasky wrote: > > Can you get dmesg without the USB debug enabled? > But this is all for 11.0, on 11.1 it hangs and I cannot look it up: Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.09-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 Features=0xbfebfbff Features2=0x1fbae3ff AMD Features=0x28100800 AMD Features2=0x1 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33186914304 (31649 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-23 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff8101c950, 0) error 19 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: _OSC returned error 0x4 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device pcib2: irq 19 at device 6.0 on pci0 pci2: on pcib2 pci0: at device 22.0 (no driver attached) ehci0: mem 0xf7e04000-0xf7e043ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 pcib3: irq 16 at device 28.0 on pci0 pcib3: [GIANT-LOCKED] pcib4: irq 17 at device 28.5 on pci0 pci3: on pcib4 em0: port 0xe000-0xe01f mem 0xf7d00000-0xf7d1ffff,0xf7d20000-0xf7d23fff irq 17 at device 0.0 on pci3 em0: Using MSIX interrupts with 3 vectors em0: Ethernet address: 10:bf:48:d7:f1:29 em0: netmap queues/slots: TX 1/1024, RX 1/1024 pcib5: irq 19 at device 28.7 on pci0 pci4: on pcib5 xhci0: mem 0xf7c00000-0xf7c07fff irq 19 at device 0.0 on pci4 xhci0: 32 bytes context size, 32-bit DMA xhci0: Unable to map MSI-X table usbus1 on xhci0 ehci1: mem 0xf7e03000-0xf7e033ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 pcib6: at device 30.0 on pci0 pci5: on pcib6 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7e02000-0xf7e027ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahciem0: on ahci0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xce800-0xcf7ff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 usbus0: 480Mbps High Speed USB v2.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec nvme cam probe device init usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1b21> at usbus1 uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 uhub1: 4 ports with 4 removable, self powered ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA8-ACS SATA 3.x device ada0: Serial Number Z292SCYD ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2861588MB (5860533168 512 byte sectors) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA8-ACS SATA 3.x device ada1: Serial Number Z292QCBX ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 2861588MB (5860533168 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! Timecounter "TSC-low" frequency 1650042874 Hz quality 1000 Trying to mount root from zfs:tank []... Root mount waiting for: usbus2 usbus0 uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus0 ugen2.2: at usbus2 uhub3: on usbus2 ugen0.2: at usbus0 uhub4: on usbus0 uhub4: 6 ports with 6 removable, self powered Root mount waiting for: usbus2 usbus0 uhub3: 8 ports with 8 removable, self powered ugen2.3: at usbus2 uhub5: on usbus2 Root mount waiting for: usbus2 uhub5: 4 ports with 4 removable, self powered ugen2.4: at usbus2 ukbd0: on usbus2 kbd2 at ukbd0 uhid0: on usbus2 ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled em0: link state changed to UP -- ___________________________ Michael Schmiedgen, BSc Senior Software Engineer Takwa GmbH Friedrich-List-Str. 36 99096 Erfurt GERMANY Tel +49 361 6534096 Fax +49 361 6534097 Mail schmiedgen@takwa.de Web http://www.takwa.de/ ___________________________ Amtsgericht Jena HRB 112964 Geschäftsführung: Ingo Buchholz From owner-freebsd-stable@freebsd.org Mon Aug 7 17:20:29 2017 Return-Path: Delivered-To: freebsd-stable@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 B3E24DBC077 for ; Mon, 7 Aug 2017 17:20:29 +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 A254A752A7 for ; Mon, 7 Aug 2017 17:20:29 +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 v77HKTRf055301 for ; Mon, 7 Aug 2017 17:20:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Mon, 07 Aug 2017 17:20:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:20:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #14 from Cassiano Peixoto --- (In reply to Sean Bruno from comment #13) Dear Sean, I've just opened a PR 221317 regarding ixgbe driver update and netmap issue. Thanks. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Mon Aug 7 17:21:43 2017 Return-Path: Delivered-To: freebsd-stable@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 51F9EDBC31D; Mon, 7 Aug 2017 17:21:43 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 0B41D7566F; Mon, 7 Aug 2017 17:21:43 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3xR4840G9Szpr; Mon, 7 Aug 2017 19:21:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1502126496; x=1504718497; bh=QiC FQ1TN3V0IatDXTasmHnq4wWwJp+/sSsjp/2Ovcho=; b=Iz3q8U95mvJGg8kWVzE M+1GAZ8uEe/43TCWlRTFWurvZkDP/qAYW9Pkt+eOiajEh/ShfVjeZtKTBi6B/WYp TQnva9YD0MoxeBfJyVvk+q5PUE3t/rO21j1h7oVlO/OYzoOpSWYVGWkd22yhd0o4 Xpcacyw8+w+Dri2FfctfnaQk= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id psxTvUPFcoP3; Mon, 7 Aug 2017 19:21:36 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3xR4804t3Kzpp; Mon, 7 Aug 2017 19:21:36 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3xR4804fW6zMD; Mon, 7 Aug 2017 19:21:36 +0200 (CEST) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Mon, 07 Aug 2017 19:21:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 07 Aug 2017 19:21:36 +0200 From: Mark Martinec To: freebsd-stable@freebsd.org Cc: freebsd-usb@freebsd.org, Michael Schmiedgen Subject: Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related? Organization: Jozef Stefan Institute In-Reply-To: References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> <2f3f1931-cfbc-124c-3ecc-6e8b71cc7b52@takwa.de> Message-ID: <7a75fe78eeb9e0262c43359aaab87597@ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:21:43 -0000 > But this is all for 11.0, on 11.1 it hangs and I cannot look it up: Does it also hang if you choose 'Safe mode" in the loader dialog? Mark From owner-freebsd-stable@freebsd.org Mon Aug 7 17:38:54 2017 Return-Path: Delivered-To: freebsd-stable@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 25ED4DBD6CA; Mon, 7 Aug 2017 17:38:54 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: from mail.takwa.de (antares.takwa.de [5.9.72.166]) by mx1.freebsd.org (Postfix) with ESMTP id D2C07766E9; Mon, 7 Aug 2017 17:38:53 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: by mail.takwa.de (Postfix, from userid 65534) id BC63551A1; Mon, 7 Aug 2017 19:38:52 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.takwa.de X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 Received: from [192.168.10.5] (unknown [62.246.110.10]) by mail.takwa.de (Postfix) with ESMTPSA id 41A74519D; Mon, 7 Aug 2017 19:38:52 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related? To: Mark Martinec , freebsd-stable@freebsd.org Cc: freebsd-usb@freebsd.org References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> <2f3f1931-cfbc-124c-3ecc-6e8b71cc7b52@takwa.de> <7a75fe78eeb9e0262c43359aaab87597@ijs.si> From: Michael Schmiedgen Message-ID: Date: Mon, 7 Aug 2017 19:38:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7a75fe78eeb9e0262c43359aaab87597@ijs.si> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:38:54 -0000 On 07.08.2017 19:21, Mark Martinec wrote: >> But this is all for 11.0, on 11.1 it hangs and I cannot look it up: > > Does it also hang if you choose 'Safe mode" in the loader dialog? > > Mark It hangs even with 'Safe mode' (multiuser): https://imgur.com/a/fz3KB I tried setting cam boot delay, as some people in web forums suggested: kern.cam.boot_delay="10000" But then I get the 'ZFS error 5' with an 11.1 kernel. Thanks, Michael -- ___________________________ Michael Schmiedgen, BSc Senior Software Engineer Takwa GmbH Friedrich-List-Str. 36 99096 Erfurt GERMANY Tel +49 361 6534096 Fax +49 361 6534097 Mail schmiedgen@takwa.de Web http://www.takwa.de/ ___________________________ Amtsgericht Jena HRB 112964 Geschäftsführung: Ingo Buchholz From owner-freebsd-stable@freebsd.org Mon Aug 7 17:39:34 2017 Return-Path: Delivered-To: freebsd-stable@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 9B611DBD83F; Mon, 7 Aug 2017 17:39:34 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: from mail.takwa.de (antares.takwa.de [5.9.72.166]) by mx1.freebsd.org (Postfix) with ESMTP id 61CB776847; Mon, 7 Aug 2017 17:39:34 +0000 (UTC) (envelope-from schmiedgen@takwa.de) Received: by mail.takwa.de (Postfix, from userid 65534) id 579A251D5; Mon, 7 Aug 2017 19:39:33 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.takwa.de X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 Received: from [192.168.10.5] (unknown [62.246.110.10]) by mail.takwa.de (Postfix) with ESMTPSA id 092B251D2; Mon, 7 Aug 2017 19:39:32 +0200 (CEST) Subject: Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related? To: Mark Martinec , freebsd-stable@freebsd.org Cc: freebsd-usb@freebsd.org References: <7a382dbf-5211-18b0-d6c4-f2abb3a327b6@selasky.org> <2f3f1931-cfbc-124c-3ecc-6e8b71cc7b52@takwa.de> <7a75fe78eeb9e0262c43359aaab87597@ijs.si> From: Michael Schmiedgen Message-ID: Date: Mon, 7 Aug 2017 19:39:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7a75fe78eeb9e0262c43359aaab87597@ijs.si> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:39:34 -0000 On 07.08.2017 19:21, Mark Martinec wrote: >> But this is all for 11.0, on 11.1 it hangs and I cannot look it up: > > Does it also hang if you choose 'Safe mode" in the loader dialog? It hangs even with 'Safe mode' (multiuser): https://imgur.com/a/fz3KB Thanks, Michael -- ___________________________ Michael Schmiedgen, BSc Senior Software Engineer Takwa GmbH Friedrich-List-Str. 36 99096 Erfurt GERMANY Tel +49 361 6534096 Fax +49 361 6534097 Mail schmiedgen@takwa.de Web http://www.takwa.de/ ___________________________ Amtsgericht Jena HRB 112964 Geschäftsführung: Ingo Buchholz From owner-freebsd-stable@freebsd.org Tue Aug 8 02:13:42 2017 Return-Path: Delivered-To: freebsd-stable@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 08068DD9FF2 for ; Tue, 8 Aug 2017 02:13:42 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CCCA694E9 for ; Tue, 8 Aug 2017 02:13:41 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id v782D7N4071559 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 8 Aug 2017 04:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id v782D7T9071558 for freebsd-stable@FreeBSD.ORG; Tue, 8 Aug 2017 04:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id v7824jeu024532 for ; Tue, 8 Aug 2017 04:04:45 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id v78241bw024436 for ; Tue, 8 Aug 2017 04:04:01 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id v78240Fe024435 for freebsd-stable@FreeBSD.ORG; Tue, 8 Aug 2017 04:04:00 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: 11.1-RELEASE: magic hosed, file recognition fails Date: Tue, 8 Aug 2017 03:50:34 +0200 Organization: even some more stinky socks Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 8 Aug 2017 01:50:35 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="22159"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 X-Mozilla-News-Host: news://localhost:119 Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Tue, 08 Aug 2017 04:13:08 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 02:13:42 -0000 Just found that my scripts that would detect image types by means of the "file" command do not work anymore in RELEASE-11. :( Whats happening in R11.1 is this: $ scanimage > /tmp/SCAN $ file /tmp/SCAN /tmp/SCAN: data While on R10 in looked this way, which appears slightly more useful: $ scanimage > /tmp/SCAN $ file /tmp/SCAN /tmp/SCAN: Netpbm image data, size = 2480 x 3507, rawbits, greymap Further investigation shows, the problem may have appeared with this update: >r309847 | delphij | 2016-12-11 08:33:02 +0100 (Sun, 11 Dec 2016) | 2 lines > >MFC r308420: MFV r308392: file 5.29. And that is a contrib, it seems the original comes from fishy penguins. So no proper repo, and doubtful if anybody might be in charge, but instead some colorful pictures like this one: https://fossies.org/diffs/file/5.28_vs_5.29/magic/Magdir/images-diff.html --------------------------------------------------------------- Looking closer - this is my file header: pmc@disp:604:1/tmp$ hd SCAN |more 00000000 50 35 0a 23 20 53 41 4e 45 20 64 61 74 61 20 66 |P5.# SANE data f| 00000010 6f 6c 6c 6f 77 73 0a 32 34 38 30 20 33 35 30 37 |ollows.2480 3507| 00000020 0a 32 35 35 0a 5f 58 56 4b 53 49 4b 52 54 50 51 |.255._XVKSIKRTPQ| 00000030 4e 4c 52 5b 56 55 4c 47 4e 4f 4e 4d 53 54 53 4d |NLR[VULGNONMSTSM| 00000040 53 49 50 52 4c 51 4f 53 56 55 53 4d 55 4e 4e 4c |SIPRLQOSVUSMUNNL| 00000050 55 49 4d 50 52 4c 4e 50 4d 56 4e 51 52 4e 4e 50 |UIMPRLNPMVNQRNNP| And this is the ruleset in the magic file: # PBMPLUS images # The next byte following the magic is always whitespace. # strength is changed to try these patterns before "x86 boot sector" 0 name netpbm >3 regex/s =[0-9]{1,50}\ [0-9]{1,50} Netpbm image data >>&0 regex =[0-9]{1,50} \b, size = %s x >>>&0 regex =[0-9]{1,50} \b %s 0 string P5 >0 regex/4 P5\\s >>0 use netpbm >>>0 string x \b, rawbits, pixmap !:strength + 45 !:mime image/x-portable-pixmap The failing line is the one with "regex/4" command, and I dont see why there is a *double* \ - but a single one doesnt work either. Using \n instead, would work. And what also works is this one: >0 regex/4 P5[[:space:]] To figure the root cause would mean to look into that libmagic, and maybe there is a misunderstanding between the design of that lib and the linux guys maintaining the magic file? From owner-freebsd-stable@freebsd.org Tue Aug 8 07:23:37 2017 Return-Path: Delivered-To: freebsd-stable@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 B1D12DC7A7A; Tue, 8 Aug 2017 07:23:37 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C2A573506; Tue, 8 Aug 2017 07:23:36 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (net206-94.perm.ertelecom.ru [46.146.206.94] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id v787NSZW037580 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Aug 2017 12:23:29 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Subject: Re: a strange and terrible saga of the cursed iSCSI ZFS SAN To: freebsd-fs@freebsd.org References: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> Cc: freebsd-stable@FreeBSD.org From: "Eugene M. Zheganin" Message-ID: Date: Tue, 8 Aug 2017 12:23:28 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [1.50 / 25.00] BAYES_HAM(-3.00)[100.00%] RBL_SPAMHAUS_PBL(2.00)[94.206.146.46.zen.spamhaus.org : 127.0.0.10] HFILTER_HOSTNAME_UNKNOWN(2.50)[] DMARC_NA(0.00)[norma.perm.ru] MIME_GOOD(-0.10)[text/plain] R_DKIM_NA(0.00)[] R_SPF_SOFTFAIL(0.00)[~all] MID_RHS_MATCH_FROM(0.00)[] RECEIVED_SPAMHAUS(0.00)[94.206.146.46.zen.spamhaus.org] RCPT_COUNT_2(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_HAS_DN(0.00)[] TO_DN_NONE(0.00)[] FROM_EQ_ENVFROM(0.00)[] RCVD_COUNT_1(0.00)[] ONCE_RECEIVED(0.10)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 2.81 X-Rspamd-Queue-ID: v787NSZW037580 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 07:23:37 -0000 On 05.08.2017 22:08, Eugene M. Zheganin wrote: > Hi, > > > I got a problem that I cannot solve just by myself. I have a iSCSI zfs > SAN system that crashes, corrupting it's data. I'll be short, and try > to describe it's genesis shortly: > > 1) autumn 2016, SAN is set up, supermicro server, external JBOD, > sandisk ssds, several redundant pools, FreeBSD 11.x (probably release, > don't really remember - see below). > > 2) this is working just fine until early spring 2017 > > 3) system starts to crash (various panics): > > panic: general protection fault > panic: page fault > panic: Solaris(panic): zfs: allocating allocated > segment(offset=6599069589504 size=81920) > panic: page fault > panic: page fault > panic: Solaris(panic): zfs: allocating allocated > segment(offset=8245779054592 size=8192) > panic: page fault > panic: page fault > panic: page fault > panic: Solaris(panic): zfs: allocating allocated > segment(offset=1792100934656 size=46080) > > 4) we memtested it immidiately, no problems found. > > 5) we switch sandisks to toshibas, we switch also the server to an > identical one, JBOD to an identical one, leaving same cables. > > 6) crashes don't stop. > > 7) we found that field engineers physically damaged (sic!) the SATA > cables (main one and spare ones), and that 90% of the disks show ICRC > SMART errors. > > 8) we replaced the cable (brand new HP one). > > 9) ATA SMART errors stopped increasing. > > 10) crashes continue. > > 11) we decided that probably when ZFS was moved over damaged cables > between JBODs it was somehow damaged too, so now it's panicking > because of that. so we wiped the data completely, reinitialized the > SAN system and put it back into the production. we even dd'ed each > disk with zeroes (!) - just in case. Important note: the data was > imported using zfs send from another, stable system that is runing in > production in another DC. > > 12) today we got another panic. > > btw the pools look now like this: > > > # zpool status -v > pool: data > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > data ONLINE 0 0 62 > raidz1-0 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > raidz1-1 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > da11 ONLINE 0 0 0 > raidz1-2 ONLINE 0 0 62 > da12 ONLINE 0 0 0 > da13 ONLINE 0 0 0 > da14 ONLINE 0 0 0 > da15 ONLINE 0 0 0 > da16 ONLINE 0 0 0 > > errors: Permanent errors have been detected in the following files: > > data/userdata/worker208:<0x1> > > pool: userdata > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > userdata ONLINE 0 0 216K > mirror-0 ONLINE 0 0 432K > gpt/userdata0 ONLINE 0 0 432K > gpt/userdata1 ONLINE 0 0 432K > > errors: Permanent errors have been detected in the following files: > > userdata/worker36:<0x1> > userdata/worker30:<0x1> > userdata/worker31:<0x1> > userdata/worker35:<0x1> > > 12) somewhere between p.5 and p.10 the pool became deduplicated (not > directly connected to the problem, just for production reasons). > > > So, concluding: we had bad hardware, we replaced EACH piece (server, > adapter, JBOD, cable, disks), and crashes just don't stop. We have 5 > another iSCSI SAN systems, almost fully identical that don't crash. > Crashes on this particular system began when it was running same set > of versions that stable systems. > > So far my priority version is that something was broken in the iSCSI+zfs stack somewhere between r310734 (most recent version on my SAN systems that works) and r320056 (probably earlier, but r320056 is the first revision with documented crash). So I downgraded back to r310734 (from a 11.1-RELEASE, which is affected, if I'm right). Some things speak pro this version: - the system was stable pre-spring 2017, before the upgrade happened - zfs corruption happens _only_ on the pools that the iSCSI is serving from, no corruption happens on the zfs pools that have nothing to do with providing zvils as iSCSI targets (and this seems to be the most convincing point). - the faulty hardware was changed. though it was changed to a identical hardware, BUT I have the very same set of identical hardware working in almost identical environment under r310734 in another DC. so far I'm not sure, because only 20 hours passed since the downgrade. However, if the system will be stable for more than a week (was never stable that long on recent revisions), it will prove I'm right and I'll file the PR. Thanks. Eugene. From owner-freebsd-stable@freebsd.org Tue Aug 8 08:33:49 2017 Return-Path: Delivered-To: freebsd-stable@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 3362BDCBC1A; Tue, 8 Aug 2017 08:33:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 D22EB75DA8; Tue, 8 Aug 2017 08:33:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 01AFA26079F; Tue, 8 Aug 2017 10:33:46 +0200 (CEST) Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) To: Ben RUBSON , FreeBSD Net , jch , hiren , Slawa Olhovchenkov , FreeBSD Stable References: <4DF74CB8-23D2-4CCF-B699-5B86DAEA65E5@gmail.com> <40602CEA-D417-4E5B-8C68-916958D49A0B@gmail.com> <9c306f10-7c05-d28d-e551-a930603aaafa@selasky.org> <896dd782-cb2c-0259-65d1-b00daae452de@FreeBSD.org> <0DB9F6FF-8BC9-48F5-B359-AC1905B9EB06@gmail.com> <7f14c95d-1ef8-bf82-c469-e6566c3aba66@selasky.org> <76A5EE7E-1D2E-46B4-86F1-F219C3DCE6EA@gmail.com> <4C91C6E5-0725-42E7-9813-1F3ACF3DDD6E@gmail.com> <5840c25e-7472-3276-6df9-1ed4183078ad@selasky.org> <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> From: Hans Petter Selasky Message-ID: Date: Tue, 8 Aug 2017 10:31:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> Content-Type: multipart/mixed; boundary="------------FE67B731424B1568ADC4B17D" Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 08:33:49 -0000 This is a multi-part message in MIME format. --------------FE67B731424B1568ADC4B17D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 08/08/17 10:06, Ben RUBSON wrote: >> On 08 Aug 2017, at 10:02, Hans Petter Selasky wrote: >> >> On 08/08/17 10:00, Ben RUBSON wrote: >>> kgdb) print *twq_2msl.tqh_first >>> $2 = { >>> tw_inpcb = 0xfffff8031c570740, >> >> print *twq_2msl.tqh_first->tw_inpcb > > (kgdb) print *twq_2msl.tqh_first->tw_inpcb > $3 = { > inp_hash = { > le_next = 0x0, > le_prev = 0xfffffe000f78adb8 > }, > inp_pcbgrouphash = { > le_next = 0x0, > le_prev = 0x0 > }, > inp_list = { > le_next = 0xfffff80c2a07f570, > le_prev = 0xffffffff81e15e20 > }, > inp_ppcb = 0xfffff80d1bf12210, > inp_pcbinfo = 0xffffffff81e15e28, > inp_pcbgroup = 0x0, > inp_pcbgroup_wild = { > le_next = 0x0, > le_prev = 0x0 > }, > inp_socket = 0x0, > inp_cred = 0xfffff804ae6ca400, > inp_flow = 0, > inp_flags = 92274688, > inp_flags2 = 16, > inp_vflag = 0 '\0', > inp_ip_ttl = 64 '@', > inp_ip_p = 0 '\0', > inp_ip_minttl = 0 '\0', > inp_flowid = 946611505, > inp_refcount = 2, > inp_pspare = 0xfffff8031c5707c0, > inp_flowtype = 191, > inp_rss_listen_bucket = 0, > inp_ispare = 0xfffff8031c5707f0, > inp_inc = { > inc_flags = 0 '\0', > inc_len = 0 '\0', > inc_fibnum = 0, > inc_ie = { > ie_fport = 53987, > ie_lport = 47873, > ie_dependfaddr = { > ie46_foreign = { > ia46_pad32 = 0xfffff8031c570808, > ia46_addr4 = { > s_addr = 3011802202 > } > }, > ie6_foreign = { > __u6_addr = { > __u6_addr8 = 0xfffff8031c570808 "", > __u6_addr16 = 0xfffff8031c570808, > __u6_addr32 = 0xfffff8031c570808 > } > } > }, > ie_dependladdr = { > ie46_local = { > ia46_pad32 = 0xfffff8031c570818, > ia46_addr4 = { > s_addr = 4068705883 > } > }, > ie6_local = { > __u6_addr = { > __u6_addr8 = 0xfffff8031c570818 "", > __u6_addr16 = 0xfffff8031c570818, > __u6_addr32 = 0xfffff8031c570818 > } > } > }, > ie6_zoneid = 0 > } > }, > inp_label = 0x0, > inp_sp = 0x0, > inp_depend4 = { > inp4_ip_tos = 0 '\0', > inp4_options = 0x0, > inp4_moptions = 0x0 > }, > inp_depend6 = { > inp6_options = 0x0, > inp6_outputopts = 0x0, > inp6_moptions = 0x0, > inp6_icmp6filt = 0x0, > inp6_cksum = 0, > inp6_hops = 0 > }, > inp_portlist = { > le_next = 0xfffff80274298ae0, > le_prev = 0xfffff800454999b0 > }, > inp_phd = 0xfffff800454999a0, > inp_gencnt = 2119756, > inp_lle = 0x0, > inp_lock = { > lock_object = { > lo_name = 0xffffffff814e6940 "tcpinp", > lo_flags = 90898432, > lo_data = 0, > lo_witness = 0x0 > }, > rw_lock = 18446735277871559936 > }, > inp_rt_cookie = 10, > inp_rtu = { > inpu_route = { > ro_rt = 0x0, > ro_lle = 0x0, > ro_prepend = 0x0, > ro_plen = 0, > ro_flags = 384, > ro_mtu = 0, > spare = 0, > ro_dst = { > sa_len = 16 '\020', > sa_family = 2 '\002', > sa_data = 0xfffff8031c5708f2 "" > } > }, > inpu_route6 = { > ro_rt = 0x0, > ro_lle = 0x0, > ro_prepend = 0x0, > ro_plen = 0, > ro_flags = 384, > ro_mtu = 0, > spare = 0, > ro_dst = { > sin6_len = 16 '\020', > sin6_family = 2 '\002', > sin6_port = 0, > sin6_flowinfo = 3011802202, > sin6_addr = { > __u6_addr = { > __u6_addr8 = 0xfffff8031c5708f8 "", > __u6_addr16 = 0xfffff8031c5708f8, > __u6_addr32 = 0xfffff8031c5708f8 > } > }, > sin6_scope_id = 0 > } > } > } > } > (kgdb) > Hi, Here is the conclusion: The following code is going in an infinite loop: > for (;;) { > TW_RLOCK(V_tw_lock); > tw = TAILQ_FIRST(&V_twq_2msl); > if (tw == NULL || (!reuse && (tw->tw_time - ticks) > 0)) { > TW_RUNLOCK(V_tw_lock); > break; > } > KASSERT(tw->tw_inpcb != NULL, ("%s: tw->tw_inpcb == NULL", > __func__)); > > inp = tw->tw_inpcb; > in_pcbref(inp); > TW_RUNLOCK(V_tw_lock); > > if (INP_INFO_TRY_RLOCK(&V_tcbinfo)) { > > INP_WLOCK(inp); > tw = intotw(inp); > if (in_pcbrele_wlocked(inp)) { in_pcbrele_wlocked() returns (1) because INP_FREED (16) is set in inp->inp_flags2. I guess you have invariants disabled, because the KASSERT() below should have caused a panic. > KASSERT(tw == NULL, ("%s: held last inp " > "reference but tw not NULL", __func__)); > INP_INFO_RUNLOCK(&V_tcbinfo); > continue; > } This is a regression issue after: > commit 5630210a7f1dbbd903b77b2aef939cd47c63da58 > Author: jch > Date: Thu Oct 30 08:53:56 2014 +0000 > > Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() and > tcp_tw_2msl_scan(). This race condition drives unplanned timewait > timeout cancellation. Also simplify implementation by holding inpcb > reference and removing tcptw reference counting. Suggested fix attached. --HPS --------------FE67B731424B1568ADC4B17D Content-Type: text/x-patch; name="tcp_timewait.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcp_timewait.diff" Index: sys/netinet/tcp_timewait.c =================================================================== --- sys/netinet/tcp_timewait.c (revision 321981) +++ sys/netinet/tcp_timewait.c (working copy) @@ -709,10 +709,11 @@ INP_WLOCK(inp); tw = intotw(inp); if (in_pcbrele_wlocked(inp)) { - KASSERT(tw == NULL, ("%s: held last inp " - "reference but tw not NULL", __func__)); INP_INFO_RUNLOCK(&V_tcbinfo); - continue; + if (tw == NULL) + continue; + else + break; /* INP_FREED flag is set */ } if (tw == NULL) { --------------FE67B731424B1568ADC4B17D-- From owner-freebsd-stable@freebsd.org Tue Aug 8 08:51:40 2017 Return-Path: Delivered-To: freebsd-stable@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 04D01DCCCF6; Tue, 8 Aug 2017 08:51:40 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 8365A7673C; Tue, 8 Aug 2017 08:51:39 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id x64so3313620wmg.1; Tue, 08 Aug 2017 01:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0Lg1qqe3YoSfWVcOjfxlsVisICZxoCdxsCANfoDom8o=; b=u+5XWeFPq3vb3iJE4sax2B7MCfJI17T7q5/EIuagnIPrivT9nJZHMsrST3Gf/bcniS cKWynWnVIN8ullDr3ZqYDnZIDThtElqWPrZw4ydIGcXHLVtVB/gr+vzNOdZKbEomCIUg KHCMaqoVmf+viw+uypT1MFyKSNhcsc+OjZokhyxohx7dz4qJ4RrPG/BJRkOsUpl5kmZY aB1YE6NAtOQfnuurv6o0dXdjdBcc/65+prJK+tvn1vqAWSuRW97RckwKjBD0eTbZSSlR 74fL/NgETpkyaT4DBpXoaG18iOPCvGt14P0AWJd7rgawGfFzGZRHesVmL7sEQdPVp5py IIQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0Lg1qqe3YoSfWVcOjfxlsVisICZxoCdxsCANfoDom8o=; b=NJjq/DRQZhfM4gRwyPcShLTp5A6hrI6oPWpZJs/70vrvKKDnfQtzR03xf8Ek1xDNDW cqLgF7pY4NlWK5NvdYII1rGm5egiULq6l3unNYAEznod8qaoPltto9KLJaOYIquQ3dPn 9cI5k+5YVuCWbtmCyt+NdtIEetGCuFRQewwMefISbGPntEkvH3hq38bICxFIK6gvjkDd NY3LMSvaYyMNLUyqAJKdT/JF4uNjcL2iqoTMSUveuei/FCjH5aMDbuThheZkp3R5oSvL dzCJqFVwDiuUuW1qzBabWVUvAtFVJ+PLs693+UWwRvLpD4hYNZuXfc8zMZeX9uLdMsGg 7/Iw== X-Gm-Message-State: AHYfb5hnpSqLitZczu17Jmaxqm2jkbvLCUxz6cKD2fmEVzWLRiHbs25U KFcYdnj3XjWmdECe6F+ltQ== X-Received: by 10.28.194.138 with SMTP id s132mr2606550wmf.29.1502182297885; Tue, 08 Aug 2017 01:51:37 -0700 (PDT) Received: from ben.home (LFbn-1-6951-179.w90-116.abo.wanadoo.fr. [90.116.132.179]) by smtp.gmail.com with ESMTPSA id v186sm1005318wmf.34.2017.08.08.01.51.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Aug 2017 01:51:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) From: Ben RUBSON In-Reply-To: Date: Tue, 8 Aug 2017 10:51:35 +0200 Cc: jch , hiren , Slawa Olhovchenkov , FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: <18031E23-711F-4E74-9D59-15A3C1DB113F@gmail.com> References: <4DF74CB8-23D2-4CCF-B699-5B86DAEA65E5@gmail.com> <40602CEA-D417-4E5B-8C68-916958D49A0B@gmail.com> <9c306f10-7c05-d28d-e551-a930603aaafa@selasky.org> <896dd782-cb2c-0259-65d1-b00daae452de@FreeBSD.org> <0DB9F6FF-8BC9-48F5-B359-AC1905B9EB06@gmail.com> <7f14c95d-1ef8-bf82-c469-e6566c3aba66@selasky.org> <76A5EE7E-1D2E-46B4-86F1-F219C3DCE6EA@gmail.com> <4C91C6E5-0725-42E7-9813-1F3ACF3DDD6E@gmail.com> <5840c25e-7472-3276-6df9-1ed4183078ad@selasky.org> <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> To: FreeBSD Net X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 08:51:40 -0000 > On 08 Aug 2017, at 10:31, Hans Petter Selasky wrote: >=20 > On 08/08/17 10:06, Ben RUBSON wrote: >>> On 08 Aug 2017, at 10:02, Hans Petter Selasky = wrote: >>>=20 >>> On 08/08/17 10:00, Ben RUBSON wrote: >>>> kgdb) print *twq_2msl.tqh_first >>>> $2 =3D { >>>> tw_inpcb =3D 0xfffff8031c570740, >>>=20 >>> print *twq_2msl.tqh_first->tw_inpcb >> (kgdb) print *twq_2msl.tqh_first->tw_inpcb >> $3 =3D { >> inp_hash =3D { >> le_next =3D 0x0, >> le_prev =3D 0xfffffe000f78adb8 >> }, >> inp_pcbgrouphash =3D { >> le_next =3D 0x0, >> le_prev =3D 0x0 >> }, >> inp_list =3D { >> le_next =3D 0xfffff80c2a07f570, >> le_prev =3D 0xffffffff81e15e20 >> }, >> inp_ppcb =3D 0xfffff80d1bf12210, >> inp_pcbinfo =3D 0xffffffff81e15e28, >> inp_pcbgroup =3D 0x0, >> inp_pcbgroup_wild =3D { >> le_next =3D 0x0, >> le_prev =3D 0x0 >> }, >> inp_socket =3D 0x0, >> inp_cred =3D 0xfffff804ae6ca400, >> inp_flow =3D 0, >> inp_flags =3D 92274688, >> inp_flags2 =3D 16, >> inp_vflag =3D 0 '\0', >> inp_ip_ttl =3D 64 '@', >> inp_ip_p =3D 0 '\0', >> inp_ip_minttl =3D 0 '\0', >> inp_flowid =3D 946611505, >> inp_refcount =3D 2, >> inp_pspare =3D 0xfffff8031c5707c0, >> inp_flowtype =3D 191, >> inp_rss_listen_bucket =3D 0, >> inp_ispare =3D 0xfffff8031c5707f0, >> inp_inc =3D { >> inc_flags =3D 0 '\0', >> inc_len =3D 0 '\0', >> inc_fibnum =3D 0, >> inc_ie =3D { >> ie_fport =3D 53987, >> ie_lport =3D 47873, >> ie_dependfaddr =3D { >> ie46_foreign =3D { >> ia46_pad32 =3D 0xfffff8031c570808, >> ia46_addr4 =3D { >> s_addr =3D 3011802202 >> } >> }, >> ie6_foreign =3D { >> __u6_addr =3D { >> __u6_addr8 =3D 0xfffff8031c570808 "", >> __u6_addr16 =3D 0xfffff8031c570808, >> __u6_addr32 =3D 0xfffff8031c570808 >> } >> } >> }, >> ie_dependladdr =3D { >> ie46_local =3D { >> ia46_pad32 =3D 0xfffff8031c570818, >> ia46_addr4 =3D { >> s_addr =3D 4068705883 >> } >> }, >> ie6_local =3D { >> __u6_addr =3D { >> __u6_addr8 =3D 0xfffff8031c570818 "", >> __u6_addr16 =3D 0xfffff8031c570818, >> __u6_addr32 =3D 0xfffff8031c570818 >> } >> } >> }, >> ie6_zoneid =3D 0 >> } >> }, >> inp_label =3D 0x0, >> inp_sp =3D 0x0, >> inp_depend4 =3D { >> inp4_ip_tos =3D 0 '\0', >> inp4_options =3D 0x0, >> inp4_moptions =3D 0x0 >> }, >> inp_depend6 =3D { >> inp6_options =3D 0x0, >> inp6_outputopts =3D 0x0, >> inp6_moptions =3D 0x0, >> inp6_icmp6filt =3D 0x0, >> inp6_cksum =3D 0, >> inp6_hops =3D 0 >> }, >> inp_portlist =3D { >> le_next =3D 0xfffff80274298ae0, >> le_prev =3D 0xfffff800454999b0 >> }, >> inp_phd =3D 0xfffff800454999a0, >> inp_gencnt =3D 2119756, >> inp_lle =3D 0x0, >> inp_lock =3D { >> lock_object =3D { >> lo_name =3D 0xffffffff814e6940 "tcpinp", >> lo_flags =3D 90898432, >> lo_data =3D 0, >> lo_witness =3D 0x0 >> }, >> rw_lock =3D 18446735277871559936 >> }, >> inp_rt_cookie =3D 10, >> inp_rtu =3D { >> inpu_route =3D { >> ro_rt =3D 0x0, >> ro_lle =3D 0x0, >> ro_prepend =3D 0x0, >> ro_plen =3D 0, >> ro_flags =3D 384, >> ro_mtu =3D 0, >> spare =3D 0, >> ro_dst =3D { >> sa_len =3D 16 '\020', >> sa_family =3D 2 '\002', >> sa_data =3D 0xfffff8031c5708f2 "" >> } >> }, >> inpu_route6 =3D { >> ro_rt =3D 0x0, >> ro_lle =3D 0x0, >> ro_prepend =3D 0x0, >> ro_plen =3D 0, >> ro_flags =3D 384, >> ro_mtu =3D 0, >> spare =3D 0, >> ro_dst =3D { >> sin6_len =3D 16 '\020', >> sin6_family =3D 2 '\002', >> sin6_port =3D 0, >> sin6_flowinfo =3D 3011802202, >> sin6_addr =3D { >> __u6_addr =3D { >> __u6_addr8 =3D 0xfffff8031c5708f8 "", >> __u6_addr16 =3D 0xfffff8031c5708f8, >> __u6_addr32 =3D 0xfffff8031c5708f8 >> } >> }, >> sin6_scope_id =3D 0 >> } >> } >> } >> } >> (kgdb) >=20 > Hi, >=20 > Here is the conclusion: >=20 > The following code is going in an infinite loop: >=20 >=20 >> for (;;) { >> TW_RLOCK(V_tw_lock); >> tw =3D TAILQ_FIRST(&V_twq_2msl); >> if (tw =3D=3D NULL || (!reuse && (tw->tw_time - ticks) = > 0)) { >> TW_RUNLOCK(V_tw_lock); >> break; >> } >> KASSERT(tw->tw_inpcb !=3D NULL, ("%s: tw->tw_inpcb =3D=3D= NULL", >> __func__)); >> inp =3D tw->tw_inpcb; >> in_pcbref(inp); >> TW_RUNLOCK(V_tw_lock); >> if (INP_INFO_TRY_RLOCK(&V_tcbinfo)) { >> INP_WLOCK(inp); >> tw =3D intotw(inp); >> if (in_pcbrele_wlocked(inp)) { >=20 > in_pcbrele_wlocked() returns (1) because INP_FREED (16) is set in = inp->inp_flags2. I guess you have invariants disabled, because the = KASSERT() below should have caused a panic. You're right, INVARIANTS is not in GENERIC : # grep -i INVARIANTS /usr/src/sys/amd64/conf/GENERIC # grep -i INVARIANTS /usr/src/sys/amd64/conf/* /usr/src/sys/amd64/conf/MINIMAL:options INVARIANTS = # Enable calls of extra sanity checking /usr/src/sys/amd64/conf/MINIMAL:options INVARIANT_SUPPORT = # Extra sanity checks of internal structures, required by INVARIANTS >> KASSERT(tw =3D=3D NULL, ("%s: held = last inp " >> "reference but tw not NULL", = __func__)); >> INP_INFO_RUNLOCK(&V_tcbinfo); >> continue; >> } >=20 > This is a regression issue after: >=20 >> commit 5630210a7f1dbbd903b77b2aef939cd47c63da58 >> Author: jch >> Date: Thu Oct 30 08:53:56 2014 +0000 >> Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() = and >> tcp_tw_2msl_scan(). This race condition drives unplanned timewait >> timeout cancellation. Also simplify implementation by holding = inpcb >> reference and removing tcptw reference counting. >=20 > Suggested fix attached. Thank you very much for your investigation HPS and for the patch ! Not sure however how to test it as I don't know a way to reproduce the = issue. Certainly your patch will reach 11.0 & 11.1 soon. Thank you again, and glad to have helped to track this down. Ben From owner-freebsd-stable@freebsd.org Tue Aug 8 11:34:03 2017 Return-Path: Delivered-To: freebsd-stable@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 9189ADD5A4C; Tue, 8 Aug 2017 11:34:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 375E881D22; Tue, 8 Aug 2017 11:34:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1df2lk-000Jxr-ET; Tue, 08 Aug 2017 14:33:52 +0300 Date: Tue, 8 Aug 2017 14:33:52 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Cc: Ben RUBSON , FreeBSD Net , jch , hiren , FreeBSD Stable Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) Message-ID: <20170808113352.GH18123@zxy.spb.ru> References: <4C91C6E5-0725-42E7-9813-1F3ACF3DDD6E@gmail.com> <5840c25e-7472-3276-6df9-1ed4183078ad@selasky.org> <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 11:34:03 -0000 On Tue, Aug 08, 2017 at 10:31:33AM +0200, Hans Petter Selasky wrote: > Here is the conclusion: > > The following code is going in an infinite loop: > > > > for (;;) { > > TW_RLOCK(V_tw_lock); > > tw = TAILQ_FIRST(&V_twq_2msl); > > if (tw == NULL || (!reuse && (tw->tw_time - ticks) > 0)) { > > TW_RUNLOCK(V_tw_lock); > > break; > > } > > KASSERT(tw->tw_inpcb != NULL, ("%s: tw->tw_inpcb == NULL", > > __func__)); > > > > inp = tw->tw_inpcb; > > in_pcbref(inp); > > TW_RUNLOCK(V_tw_lock); > > > > if (INP_INFO_TRY_RLOCK(&V_tcbinfo)) { > > > > INP_WLOCK(inp); > > tw = intotw(inp); > > if (in_pcbrele_wlocked(inp)) { > > in_pcbrele_wlocked() returns (1) because INP_FREED (16) is set in > inp->inp_flags2. I guess you have invariants disabled, because the > KASSERT() below should have caused a panic. > > > KASSERT(tw == NULL, ("%s: held last inp " > > "reference but tw not NULL", __func__)); > > INP_INFO_RUNLOCK(&V_tcbinfo); > > continue; > > } > > This is a regression issue after: > > > commit 5630210a7f1dbbd903b77b2aef939cd47c63da58 > > Author: jch > > Date: Thu Oct 30 08:53:56 2014 +0000 > > > > Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() and > > tcp_tw_2msl_scan(). This race condition drives unplanned timewait > > timeout cancellation. Also simplify implementation by holding inpcb > > reference and removing tcptw reference counting. > > Suggested fix attached. Hmm, I am not sure, IMHO between TW_RUNLOCK(V_tw_lock); and if (INP_INFO_TRY_WLOCK(&V_tcbinfo)) { `inp` can be invalidated, freed and this pointer may be invalid? > Index: sys/netinet/tcp_timewait.c > =================================================================== > --- sys/netinet/tcp_timewait.c (revision 321981) > +++ sys/netinet/tcp_timewait.c (working copy) > @@ -709,10 +709,11 @@ > INP_WLOCK(inp); > tw = intotw(inp); > if (in_pcbrele_wlocked(inp)) { > - KASSERT(tw == NULL, ("%s: held last inp " > - "reference but tw not NULL", __func__)); > INP_INFO_RUNLOCK(&V_tcbinfo); > - continue; > + if (tw == NULL) > + continue; > + else > + break; /* INP_FREED flag is set */ > } > > if (tw == NULL) { > _______________________________________________ > 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-stable@freebsd.org Tue Aug 8 11:51:24 2017 Return-Path: Delivered-To: freebsd-stable@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 A3ACCDD6C89; Tue, 8 Aug 2017 11:51:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 6940F82DAE; Tue, 8 Aug 2017 11:51:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7DCE326080B; Tue, 8 Aug 2017 13:51:22 +0200 (CEST) Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) To: Slawa Olhovchenkov Cc: FreeBSD Net , FreeBSD Stable , Ben RUBSON , hiren , jch References: <4C91C6E5-0725-42E7-9813-1F3ACF3DDD6E@gmail.com> <5840c25e-7472-3276-6df9-1ed4183078ad@selasky.org> <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> <20170808113352.GH18123@zxy.spb.ru> From: Hans Petter Selasky Message-ID: Date: Tue, 8 Aug 2017 13:49:08 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170808113352.GH18123@zxy.spb.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 11:51:24 -0000 On 08/08/17 13:33, Slawa Olhovchenkov wrote: > TW_RUNLOCK(V_tw_lock); > and > if (INP_INFO_TRY_WLOCK(&V_tcbinfo)) { > > `inp` can be invalidated, freed and this pointer may be invalid? If you look one line up there is a pcbref ?? --HPS From owner-freebsd-stable@freebsd.org Tue Aug 8 11:56:38 2017 Return-Path: Delivered-To: freebsd-stable@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 C5783DD70D5; Tue, 8 Aug 2017 11:56:38 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 6B42D83135; Tue, 8 Aug 2017 11:56:38 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1df37j-000K9C-Cs; Tue, 08 Aug 2017 14:56:35 +0300 Date: Tue, 8 Aug 2017 14:56:35 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Cc: FreeBSD Net , FreeBSD Stable , Ben RUBSON , hiren , jch Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) Message-ID: <20170808115635.GY1585@zxy.spb.ru> References: <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> <20170808113352.GH18123@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 11:56:38 -0000 On Tue, Aug 08, 2017 at 01:49:08PM +0200, Hans Petter Selasky wrote: > On 08/08/17 13:33, Slawa Olhovchenkov wrote: > > TW_RUNLOCK(V_tw_lock); > > and > > if (INP_INFO_TRY_WLOCK(&V_tcbinfo)) { > > > > `inp` can be invalidated, freed and this pointer may be invalid? > > If you look one line up there is a pcbref ?? Yes. Can different thread take this inp and freed it? May be timer thread? From owner-freebsd-stable@freebsd.org Tue Aug 8 12:00:46 2017 Return-Path: Delivered-To: freebsd-stable@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 E2429DD79B9; Tue, 8 Aug 2017 12:00:46 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mail-wr0-f195.google.com (mail-wr0-f195.google.com [209.85.128.195]) (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 763228367A; Tue, 8 Aug 2017 12:00:46 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mail-wr0-f195.google.com with SMTP id g32so2267016wrd.5; Tue, 08 Aug 2017 05:00:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HMGu62aG5xnbzGPlxvUFWp4spkuQo/iym+Ss38zM/5M=; b=GeWsymHpGTmWhQ05xJGImrm+7MqsI9ozqJO9nFIj6p798VtSdv0QhRHdhkla3NriAc jCOM2gxxXphzf2URaduGPbeH+tKheU+WQWpDFoE25zqUU9wombxAchYjYx7uFNK7GHYu 3MXRk3htGGXWf+2YdyfASLRnayNG/BKVX5AUoeWkMBXoJZdIrwntgcqGPmYPOuE/aOUN WaNd7Z6D4/E6PChn/iUO0SwYQYsTjhT9ca9Z4pUQ5Y2a/b/dnLeIzNM2+2rdUDYuGTMA aUiT0N6BuY/+HJloW7SaFJzQ6Ds6SetjN/mGLCliUUHFD2Bar2+pq4UrbUvlzmqz8wdE a8Jw== X-Gm-Message-State: AHYfb5ghuz2qlJAEHcj/5GBGYW99xf97gAs2QKajlE3WQan/lsrnuGLb +jtleA7L2vCmlOU01z8= X-Received: by 10.223.177.202 with SMTP id r10mr2601657wra.36.1502192025945; Tue, 08 Aug 2017 04:33:45 -0700 (PDT) Received: from [10.100.64.12] ([217.30.88.7]) by smtp.gmail.com with ESMTPSA id g93sm1533468wrd.11.2017.08.08.04.33.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Aug 2017 04:33:45 -0700 (PDT) Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) To: Hans Petter Selasky , Ben RUBSON , FreeBSD Net , hiren , Slawa Olhovchenkov , FreeBSD Stable References: <4DF74CB8-23D2-4CCF-B699-5B86DAEA65E5@gmail.com> <40602CEA-D417-4E5B-8C68-916958D49A0B@gmail.com> <9c306f10-7c05-d28d-e551-a930603aaafa@selasky.org> <896dd782-cb2c-0259-65d1-b00daae452de@FreeBSD.org> <0DB9F6FF-8BC9-48F5-B359-AC1905B9EB06@gmail.com> <7f14c95d-1ef8-bf82-c469-e6566c3aba66@selasky.org> <76A5EE7E-1D2E-46B4-86F1-F219C3DCE6EA@gmail.com> <4C91C6E5-0725-42E7-9813-1F3ACF3DDD6E@gmail.com> <5840c25e-7472-3276-6df9-1ed4183078ad@selasky.org> <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> From: Julien Charbon Message-ID: <0a5787c5-8a53-ab09-971a-dc1cd5f3aca0@freebsd.org> Date: Tue, 8 Aug 2017 13:33:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 12:00:47 -0000 Hi, On 8/8/17 10:31 AM, Hans Petter Selasky wrote: > On 08/08/17 10:06, Ben RUBSON wrote: >>> On 08 Aug 2017, at 10:02, Hans Petter Selasky wrote: >>> >>> On 08/08/17 10:00, Ben RUBSON wrote: >>>> kgdb) print *twq_2msl.tqh_first >>>> $2 = { >>>> tw_inpcb = 0xfffff8031c570740, >>> >>> print *twq_2msl.tqh_first->tw_inpcb >> > > Here is the conclusion: > > The following code is going in an infinite loop: > > >> for (;;) { >> TW_RLOCK(V_tw_lock); >> tw = TAILQ_FIRST(&V_twq_2msl); >> if (tw == NULL || (!reuse && (tw->tw_time - ticks) > >> 0)) { >> TW_RUNLOCK(V_tw_lock); >> break; >> } >> KASSERT(tw->tw_inpcb != NULL, ("%s: tw->tw_inpcb == >> NULL", >> __func__)); >> >> inp = tw->tw_inpcb; >> in_pcbref(inp); >> TW_RUNLOCK(V_tw_lock); >> >> if (INP_INFO_TRY_RLOCK(&V_tcbinfo)) { >> >> INP_WLOCK(inp); >> tw = intotw(inp); >> if (in_pcbrele_wlocked(inp)) { > > in_pcbrele_wlocked() returns (1) because INP_FREED (16) is set in > inp->inp_flags2. I guess you have invariants disabled, because the > KASSERT() below should have caused a panic. > >> KASSERT(tw == NULL, ("%s: held last inp " >> "reference but tw not NULL", >> __func__)); >> INP_INFO_RUNLOCK(&V_tcbinfo); >> continue; >> } > > This is a regression issue after: > >> commit 5630210a7f1dbbd903b77b2aef939cd47c63da58 >> Author: jch >> Date: Thu Oct 30 08:53:56 2014 +0000 >> >> Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() and >> tcp_tw_2msl_scan(). This race condition drives unplanned timewait >> timeout cancellation. Also simplify implementation by holding inpcb >> reference and removing tcptw reference counting. > > Suggested fix attached. I agree we your conclusion. Just for the record, more precisely this regression seems to have been introduced with: commit b02d40ddcda08b51a49e5667e6808f5dc5ec0472 Author: fabient Date: Wed Nov 25 14:45:43 2015 +0000 The r241129 description was wrong that the scenario is possible only for read locks on pcbs. The same race can happen with write lock semantics as well. The race scenario: - Two threads (1 and 2) locate pcb with writer semantics (INPLOOKUP_WLOCKPCB) and do in_pcbref() on it. - 1 and 2 both drop the inp hash lock. - Another thread (3) grabs the inp hash lock. Then it runs in_pcbfree(), which wlocks the pcb. They must happen faster than 1 or 2 come INP_WLOCK()! - 1 and 2 congest in INP_WLOCK(). - 3 does in_pcbremlists(), drops hash lock, and runs in_pcbrele_wlocked(), which doesn't free the pcb due to two references on it. Then it unlocks the pcb. - 1 (or 2) gets wlock on the pcb, runs in_pcbrele_wlocked(), which doesn't report inp as freed, due to 2 (or 1) still helding extra reference on it. The thread tries to do smth with a disconnected pcb and crashes. Submitted by: emeric.poupon@stormshield.eu Reviewed by: gleb@ MFC after: 1 week Sponsored by: Stormshield Tested by: Cassiano Peixoto, Stormshield Notes: svn path=/head/; revision=291301 Before this change in_pcbrele_wlocked() returned 1 only on the last reference which is what tcp_tw_2msl_scan() currently expects. Thus good catch, and your patch looks good. I am going to just verify the other in_pcbrele_wlocked() calls in TCP stack. Thanks. -- Julien From owner-freebsd-stable@freebsd.org Tue Aug 8 12:01:25 2017 Return-Path: Delivered-To: freebsd-stable@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 6AAF9DD7CD8; Tue, 8 Aug 2017 12:01:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 1DB0E83839; Tue, 8 Aug 2017 12:01:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E281C26080B; Tue, 8 Aug 2017 14:01:22 +0200 (CEST) Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) To: Slawa Olhovchenkov Cc: jch , FreeBSD Net , FreeBSD Stable , Ben RUBSON , hiren References: <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> <20170808113352.GH18123@zxy.spb.ru> <20170808115635.GY1585@zxy.spb.ru> From: Hans Petter Selasky Message-ID: Date: Tue, 8 Aug 2017 13:59:08 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170808115635.GY1585@zxy.spb.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 12:01:25 -0000 On 08/08/17 13:56, Slawa Olhovchenkov wrote: > On Tue, Aug 08, 2017 at 01:49:08PM +0200, Hans Petter Selasky wrote: > >> On 08/08/17 13:33, Slawa Olhovchenkov wrote: >>> TW_RUNLOCK(V_tw_lock); >>> and >>> if (INP_INFO_TRY_WLOCK(&V_tcbinfo)) { >>> >>> `inp` can be invalidated, freed and this pointer may be invalid? >> >> If you look one line up there is a pcbref ?? > > Yes. > Can different thread take this inp and freed it? > May be timer thread? No, it cannot be freed while there is a ref. Some lines down the ref is dropped once the inp pointer is no longer needed. --HPS From owner-freebsd-stable@freebsd.org Tue Aug 8 18:40:53 2017 Return-Path: Delivered-To: freebsd-stable@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 51248DC8E89 for ; Tue, 8 Aug 2017 18:40:53 +0000 (UTC) (envelope-from cheeky.m@gmx.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 367DC6E6E6 for ; Tue, 8 Aug 2017 18:40:53 +0000 (UTC) (envelope-from cheeky.m@gmx.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2F12FDC8E88; Tue, 8 Aug 2017 18:40:53 +0000 (UTC) Delivered-To: stable@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 2E958DC8E87 for ; Tue, 8 Aug 2017 18:40:53 +0000 (UTC) (envelope-from cheeky.m@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FAE26E6E3 for ; Tue, 8 Aug 2017 18:40:52 +0000 (UTC) (envelope-from cheeky.m@gmx.com) Received: from [73.143.155.105] by 3capp-mailcom-bs14.server.lan (via HTTP); Tue, 8 Aug 2017 20:40:45 +0200 MIME-Version: 1.0 Message-ID: From: cheeky.m@gmx.com To: stable@freebsd.org Subject: 11.1-RELEASE panics SUN X4200, EARLY_AP_STARTUP Content-Type: text/plain; charset=UTF-8 Date: Tue, 8 Aug 2017 20:40:45 +0200 Importance: normal Sensitivity: Normal Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-Provags-ID: V03:K1:aCeunro/wctdvoMTcclabg7WdjdI32dlHVVfsaBITUE dx4I4wt/APpxXkDQX8ORDJr7XoB8VSCmAYrBPndDyjxbCkLbOt eXfNS0HgdBpWczVd6YNQCLPcjlvhxcHQkV6zKe63shaQss7Ugb 0Ywbg/rRBTZun95pQBlej38e3gnkeYy5DRaTqOWV1jWpF55rWD 3GtkFAaw1uosJPqZ5/Fb5/WXco994YJ1F/R1xBz4GzjkAkqMUR wMIfwjs7OexdJVyUFMT1cF/q/kFvfZHaWzI4868n+xDFK3MDM3 vzXFpAzYCoNF1Bnch8oZij8Dn9t X-UI-Out-Filterresults: notjunk:1;V01:K0:3OeYfVHfewg=:bJjZSbb7xSwRX/G9rYLPXB BQQOQ+0flnNNaZm7T6oaani2rIGgXrDQTi6xNHbSGt0CVvh+vqf2gsKAEBL6Q82PAvCUB1TCZ 6iasU0WiCdNxmSeU0s/FC2C9D53Qp1537awlK63Wpb4cZ9mPfn61TdxbVTdvNyikVY9igfiVc kHrmpc8c/IN4ARfs9gnrOJkn51NOSN0n/CZXRcWzKJwxIypgFDbmC8fwfL9juJqYKUT9+evxG 8NI1g1rqOiNplNiLt99a977XFUGMyMrIMhy4SlOfTr9FbQx8c+mRCVkXB72kFx1gyjYHLUBkR 6mdTxI2WnfVmxHbhInB5IykuY/k6V7Boh+4ynsFl6lpWTAcu4BW8j50lMnORhxXdISBjdeQQM z5QiQX4FE+CjKioQLUt4Vqw2fnL9PPVwYpNfVSCiWF2/YFE8apvlVxj7I+9iWLlYfu7Q20cfI 23AIE7rjm7w+Cl/1XqMWeelagU7S5AVLHSDNBiIb3MwLJJeXE198 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 18:40:53 -0000 The EARLY_AP_STARTUP kernel option causes kernel panics on SUN X4200 AMD machines=2E COmmenting it out of GENERIC and new kernel allows boot=2E safe mode boot works because it disables smp=2E an svn bisect was performed for 11-stable and the addition of EARLY_AP_STA= RTUP caused the problem, version r318763 broken=2E =20 --------------------------------------------------------------------------= - /boot/kernel=2Eold/kernel text=3D0x14972f8 data=3D0x1384c0+0x4c15e8 syms= =3D[0x8+0x15e8b0+0x8+0x178422] /boot/entropy size=3D0x1000 Booting=2E=2E=2E Copyright (c) 1992-2017 The FreeBSD Project=2E Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California=2E All rights reserved= =2E FreeBSD is a registered trademark of The FreeBSD Foundation=2E FreeBSD 11=2E1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017 root@releng2=2Enyi=2Efreebsd=2Eorg:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 4=2E0=2E0 (tags/RELEASE_400/final 297347) (based on = LLVM 4=2E0=2E0) VT(vga): resolution 640x480 CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2593=2E16-MHz K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x40f12 Family=3D0xf Model=3D0x41 Stepp= ing=3D2 Features=3D0x178bfbff Features2=3D0x2001 AMD Features=3D0xea500800 AMD Features2=3D0x1f SVM: NAsids=3D64 real memory =3D 4563402752 (4352 MB) avail memory =3D 4104478720 (3914 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) random: unblocking device=2E ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (= 20170303/tbfadt-748) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 128/64 = (20170303/tbfadt-748) ioapic1: Changing APIC ID to 16 ioapic2: Changing APIC ID to 17 ioapic3 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard ioapic1 irqs 48-54 on motherboard ioapic2 irqs 56-62 on motherboard SMP: AP CPU SMP: AP CPU k F aF aFat F aF kkernel trap 12 with interrupts disab=C3=83=C2=BE=C3=83=C2=BF=C3=83=C2=BF= =C3=83=C2=BF=C3=83=C2=BF=C3=AF=C2=BF=C2=BD=C3=83=C2=BF=C3=83=C2=BF=C3=83=C2= =BF=C3=83=C2=BF=C3=83=C2=BF=C3=83=C2=BF=C3=83=C2=BF=C3=83=C2=BFkernel trap = 12 with interrupts disabled Fatal trap 60276736: UN=C3=83=C2=BF=C3=83=C2=BFkernel trap 12 with interru= pts disabled iatal trap -2130508367: UNKNOWN whilpanierc: staeck ovlerflowt detrected; = backt1race mawy bei corrup ted cpuid t=3D 1 KrDB: stack bupackttrace: #0 0xffffffffs80aada97 at lkdb_backtrace+0x67 xffffffff80a6bb76 aFat vpanic+0x1l86 #r2 0xfpffffff1f80a6b9e3 at panipc+0x43g #3e 0xffffaffff80a9b072u at __tstackw_chkh_lfail+0x12 i#4 0xffffff kff80eab3f2b eat vprintf+0 x10b 000 atcp dmapbase+0x397c000 Upt =3Dime: 12s Au;toma tic rebpoot inc 15 secondsi - press a key on 0the con sole fto abor= t -u-> Press a key on the iconsroule to reboot , -a-> or drswitech off the =3Dsystem xnow=2E ke=C3=82=C2=A1=C3=83=C2=BF=C3=83=C2=BF=C3=83=C2=BF=C3=83=C2=BF=C3=83=C2=BF= =C3=83=C2=BF=C3=83=C2=BF=C3=83=C2=BFkernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode c=C3=83=C2=B0 c --------------------------------------------------------------------------= ---------------------- The corruption above is how it was on the screen=2E the memory detected is also wrong, or it is how much a single cpu sees=2E there are 12 gigs in this machine=2E Here is a boot from 11-stable with EARLY_AP_STARTUP commented out Copyright (c) 1992-2017 The FreeBSD Project=2E Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California=2E All rights reserved= =2E FreeBSD is a registered trademark of The FreeBSD Foundation=2E FreeBSD 11=2E1-STABLE #11 r322170M: Tue Aug 8 13:13:21 EDT 2017 root@xxx:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 4=2E0=2E0 (tags/RELEASE_400/final 297347) (based on = LLVM 4=2E0=2E0) VT(vga): resolution 640x480 CPU: Dual-Core AMD Opteron(tm) Processor 2216 (2393=2E69-MHz K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x40f13 Family=3D0xf Model=3D0x41 Stepp= ing=3D3 Features=3D0x178bfbff Features2=3D0x2001 AMD Features=3D0xea500800 AMD Features2=3D0x1f SVM: NAsids=3D64 real memory =3D 12884901888 (12288 MB) avail memory =3D 12435623936 (11859 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) random: unblocking device=2E ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (= 20170303/tbfadt-748) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 128/64 = (20170303/tbfadt-748) ioapic1: Changing APIC ID to 16 ioapic2: Changing APIC ID to 17 ioapic3 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard ioapic1 irqs 48-54 on motherboard ioapic2 irqs 56-62 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80f67f60, 0) error 19 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed00fff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 950 hpet1: iomem 0xfed10000-0xfed10fff on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3=2E579545MHz> port 0x2008-0x200b on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0=2E0 (no driver attached) isab0: at device 1=2E0 on pci0 isa0: on isab0 ohci0: mem 0xfe3ff000-0xfe3fffff irq = 20 at device 2=2E0 on pci0 usbus0 on ohci0 ehci0: mem 0xfe3fec00-0xfe3fecf= f irq 21 at device 2=2E1 on pci0 usbus1: EHCI version 1=2E0 usbus1 on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0= x170-0x177,0x376,0x9100-0x910f at device 6=2E0 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pcib1: at device 9=2E0 on pci0 pci1: on pcib1 vgapci0: port 0xc800-0xc8ff mem 0xfd000000-0xfdff= ffff,0xfe2ff000-0xfe2fffff irq 16 at device 3=2E0 on pci1 vgapci0: Boot video device nfe0: port 0xdc00-0xdc07 me= m 0xfe3fd000-0xfe3fdfff irq 22 at device 10=2E0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000base= SX, 1000baseSX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-F= DX-master, auto, auto-flow nfe0: Using defaults for TSO: 65518/35/2048 nfe0: Ethernet address: pcib2: at device 11=2E0 on pci0 pci2: on pcib2 pcib3: at device 12=2E0 on pci0 pci3: on pcib3 pcib4: at device 13=2E0 on pci0 pci4: on pcib4 pcib5: at device 14=2E0 on pci0 pci5: on pcib5 pcib6: on acpi0 pci6: on pcib6 pci6: at device 0=2E0 (no driver attached) pci6: at device 1=2E0 (no driver attached) nfe1: port 0xfc00-0xfc07 me= m 0xfeafe000-0xfeafefff irq 44 at device 10=2E0 on pci6 miibus1: on nfe1 e1000phy1: PHY 1 on miibus1 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000base= SX, 1000baseSX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-F= DX-master, auto, auto-flow nfe1: Using defaults for TSO: 65518/35/2048 nfe1: Ethernet address: pcib7: at device 11=2E0 on pci6 pci7: on pcib7 pcib8: at device 12=2E0 on pci6 pci8: on pcib8 pcib9: at device 13=2E0 on pci6 pci9: on pcib9 pcib10: at device 14=2E0 on pci6 pci10: on pcib10 pcib11: at device 16=2E0 on pci6 pci11: on pcib11 pcib12: at device 17=2E0 on pci6 pci12: on pcib12 em0: port 0xec00-0= xec3f mem 0xfe9e0000-0xfe9fffff irq 56 at device 1=2E0 on pci12 em0: Ethernet address: em0: netmap queues/slots: TX 1/4096, RX 1/4096 em1: port 0xe800-0= xe83f mem 0xfe9c0000-0xfe9dffff irq 57 at device 1=2E1 on pci12 em1: Ethernet address: em1: netmap queues/slots: TX 1/4096, RX 1/4096 mpt0: port 0xe400-0xe4ff mem 0xfe9bc000-0xfe9b= ffff,0xfe9a0000-0xfe9affff irq 58 at device 2=2E0 on pci12 mpt0: MPI Version=3D1=2E5=2E16=2E0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 1 Active Volume (2 Max) mpt0: 2 Hidden Drive Members (14 Max) acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) orm0: at iomem 0xc0000-0xc9fff,0xca000-0xcb7ff,0xcb800-0= xcc7ff,0xcc800-0xcd7ff,0xd3800-0xd47ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range powernow0: on cpu0 powernow1: on cpu1 powernow2: on cpu2 powernow3: on cpu3 Timecounters tick every 1=2E000 msec nvme cam probe device init usbus0: 12Mbps Full Speed USB v1=2E0 usbus1: 480Mbps High Speed USB v2=2E0 ugen0=2E1: at usbus0 uhub0: on usb= us0 ugen1=2E1: at usbus1 uhub1: on usb= us1 mpt0: mpt_read_cfg_page: Config Info Status 22 mpt0:vol0(mpt0:0:0): mpt_refresh_raid_vol: Failed to read RAID Vol Page(0) mpt0:vol0(mpt0:0:0): Settings ( ) mpt0:vol0(mpt0:0:0): 0 Members: mpt0:vol0(mpt0:0:0): uhub0: 7 ports with 7 removable, self powered RAID-0 - Optimal From owner-freebsd-stable@freebsd.org Wed Aug 9 06:01:58 2017 Return-Path: Delivered-To: freebsd-stable@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 13C47DC3C07 for ; Wed, 9 Aug 2017 06:01:58 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (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 C1BE963929 for ; Wed, 9 Aug 2017 06:01:57 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:45b3:f867:72d9:e0c7]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v7961s3n010485 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Aug 2017 01:02:00 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2016; t=1502258520; bh=fZy+YvBYPsc+oeIUGzbqnt7OuV82LqIuBRYK/ClIRKg=; h=From:To:Subject:Date:In-Reply-To:References; b=KCwY00OzF+vOopqNr1wCf2mUWhlMON9loSyqjj8UVim1Lxclrig1XJDRnqen5CnvO RIfa/Kw+a7gT0Atfbqz3p3Anai5x+8YqzbWSmuvvBB8mGcPmBooxO/HXVuojwDTjha oRvE+V+vSdGXfTMv0Do+/YX2fmb3kSEmoT013n88IaRakBL+vgnxWWD3X85W+PoaJI 6GFVDPSnjPX8d6kxQB8p7UoA77ZpkgfF+p5oGooIXIwF/7KoPhz911EoGI1SdUYYe5 2eqObye03H2x7qjq2PGaPF31CBwelSWzsTdsNWcXNSzxY6n9Di6DeQXRarckAFwRMS wiXXicRwKGuXg== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:45b3:f867:72d9:e0c7] claimed to be flake.tharned.org From: Greg Rivers To: "Andrey V. Elsukov" , freebsd-stable@freebsd.org Subject: Re: SLAAC not working Date: Wed, 09 Aug 2017 01:01:50 -0500 Message-ID: <1557648.beBEYmqKBO@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <1646645.UkMcyRZBVl@flake.tharned.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Wed, 09 Aug 2017 01:02:00 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 06:01:58 -0000 On Monday, August 07, 2017 15:57:04 Andrey V. Elsukov wrote: > So, set net.inet6.icmp6.nd6_debug=1 and show what you have in the > ndp -p > ndp -r > ndp -i lagg0 > # sysctl net.inet6.icmp6.nd6_debug=1 net.inet6.icmp6.nd6_debug: 0 -> 1 # suspend [1] + Stopped (SIGSTOP) su - $ ndp -p fe80::%lagg0/64 if=lagg0 flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0 No advertising router fe80::%lo0/64 if=lo0 flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0 No advertising router $ ndp -r $ ndp -i lagg0 linkmtu=0, maxmtu=0, curhlim=64, basereachable=30s0ms, reachable=31s, retrans=1s0ms Flags: nud accept_rtadv auto_linklocal Clearly there's no SLAAC action. I can't find any NDP debug messages in the kernel message log or in the syslog. Where might they be going? -- Greg Rivers From owner-freebsd-stable@freebsd.org Wed Aug 9 07:27:20 2017 Return-Path: Delivered-To: freebsd-stable@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 D9D68DC53F6 for ; Wed, 9 Aug 2017 07:27:20 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 900A265CF9 for ; Wed, 9 Aug 2017 07:27:20 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p1949254-ipbf202funabasi.chiba.ocn.ne.jp [118.1.70.254]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id v797R3Wg064455 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Wed, 9 Aug 2017 16:27:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id v797R1RR021266 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Aug 2017 16:27:01 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id v797QvTv021263; Wed, 9 Aug 2017 16:26:59 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 09 Aug 2017 16:26:50 +0900 (JST) Message-Id: <20170809.162650.970303478864091097.hrs@allbsd.org> To: gcr+freebsd-stable@tharned.org Cc: bu7cher@yandex.ru, freebsd-stable@freebsd.org Subject: Re: SLAAC not working From: Hiroki Sato In-Reply-To: <1557648.beBEYmqKBO@flake.tharned.org> References: <1557648.beBEYmqKBO@flake.tharned.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Aug__9_16_26_50_2017_475)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [133.31.130.32]); Wed, 09 Aug 2017 16:27:16 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,URIBL_SC2_SURBL,URIBL_XS_SURBL,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 07:27:20 -0000 ----Security_Multipart(Wed_Aug__9_16_26_50_2017_475)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg Rivers wrote in <1557648.beBEYmqKBO@flake.tharned.org>: gc> On Monday, August 07, 2017 15:57:04 Andrey V. Elsukov wrote: gc> > So, set net.inet6.icmp6.nd6_debug=1 and show what you have in the gc> > ndp -p gc> > ndp -r gc> > ndp -i lagg0 gc> > gc> # sysctl net.inet6.icmp6.nd6_debug=1 gc> net.inet6.icmp6.nd6_debug: 0 -> 1 gc> # suspend gc> [1] + Stopped (SIGSTOP) su - gc> $ ndp -p gc> fe80::%lagg0/64 if=lagg0 gc> flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0 gc> No advertising router gc> fe80::%lo0/64 if=lo0 gc> flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0 gc> No advertising router gc> $ ndp -r gc> $ ndp -i lagg0 gc> linkmtu=0, maxmtu=0, curhlim=64, basereachable=30s0ms, reachable=31s, gc> retrans=1s0ms gc> Flags: nud accept_rtadv auto_linklocal gc> gc> Clearly there's no SLAAC action. I can't find any NDP debug messages gc> in the kernel message log or in the syslog. Where might they be going? The configuration looks correct to me, but two questions: 1. Does "sysctl net.inet6.ip6.forwarding" command show "0"? 2. What is shown by the command "ping6 ff02::1%lagg0" and "rtsol -dD lagg0"? -- Hiroki ----Security_Multipart(Wed_Aug__9_16_26_50_2017_475)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlmKuToACgkQTyzT2CeTzy3QLgCgmYDH0Ulpc8spOPd6evUCOTEq x3gAnAsH1tjW7FApZB4diJLnV67c34O5 =vMKP -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Aug__9_16_26_50_2017_475)---- From owner-freebsd-stable@freebsd.org Wed Aug 9 07:55:15 2017 Return-Path: Delivered-To: freebsd-stable@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 C70F4DC5C91 for ; Wed, 9 Aug 2017 07:55:15 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (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 97A9A6698E; Wed, 9 Aug 2017 07:55:15 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:5919:2b26:ea54:e4b9]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v797tCkb011281 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Aug 2017 02:55:18 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2016; t=1502265318; bh=qC5Xp2VxpoEEmf4uY4OA9ujSkEZqFe1e8cZx9d/AhtQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=NbYovCi4DY7+Gl1bkBxfRIklLAkwdb7N5txRmPTkvuvn3uPNropzFkGoDvzxGUgEY Z/mBa3o1L3ZKWBWiIVmfMB6WoIYhL5VMlSlaBFy7CR+iQcE8V+J1vy3DdPxkkNmXjF CDq5wB0S17atrnHFPl4yh5Yqo0MEwppEyH2koO+p9TtcAzQ8jQMRi+7c5nD5n064HM RCuzQt32zNpfkVcNGPZvRe63gyOw48igB4KxhrP7bTzmOIdqLipMNEO4m6yXkS0plk 9C6mGyHlkcX+GAC0dTzrUAC1i8cR5rL5+swso9seN2kjH2IrO3uz6BxIggycwRb+QO dhIMirzCSOmiQ== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:5919:2b26:ea54:e4b9] claimed to be flake.tharned.org From: Greg Rivers To: Hiroki Sato Cc: freebsd-stable@freebsd.org Subject: Re: SLAAC not working Date: Wed, 09 Aug 2017 02:55:08 -0500 Message-ID: <2045487.FzlpjXtTmv@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170809.162650.970303478864091097.hrs@allbsd.org> References: <1557648.beBEYmqKBO@flake.tharned.org> <20170809.162650.970303478864091097.hrs@allbsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Wed, 09 Aug 2017 02:55:18 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 07:55:15 -0000 On Wednesday, August 09, 2017 16:26:50 Hiroki Sato wrote: > The configuration looks correct to me, but two questions: > > 1. Does "sysctl net.inet6.ip6.forwarding" command show "0"? > $ sysctl net.inet6.ip6.forwarding net.inet6.ip6.forwarding: 0 > 2. What is shown by the command "ping6 ff02::1%lagg0" and "rtsol -dD lagg0"? > $ ping6 -c 2 ff02::1%lagg0 PING6(56=40+8+8 bytes) fe80::ae16:2dff:fe1e:b880%lagg0 --> ff02::1%lagg0 16 bytes from fe80::ae16:2dff:fe1e:b880%lagg0, icmp_seq=0 hlim=64 time=0.181 ms 16 bytes from fe80::f415:63ff:fe2b:ea06%lagg0, icmp_seq=0 hlim=64 time=0.263 ms(DUP!) 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=0.318 ms(DUP!) 16 bytes from fe80::8edc:d4ff:feaf:8938%lagg0, icmp_seq=0 hlim=64 time=0.369 ms(DUP!) 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=0.803 ms(DUP!) 16 bytes from fe80::ae16:2dff:fe1e:e998%lagg0, icmp_seq=0 hlim=64 time=0.868 ms(DUP!) 16 bytes from fe80::ae16:2dff:fe1e:49f8%lagg0, icmp_seq=0 hlim=64 time=0.922 ms(DUP!) 16 bytes from fe80::226:55ff:fe2f:40a4%lagg0, icmp_seq=0 hlim=64 time=0.971 ms(DUP!) 16 bytes from fe80::f415:63ff:fe2b:ea06%lagg0, icmp_seq=0 hlim=64 time=2.144 ms(DUP!) 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=4.154 ms(DUP!) 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=4.220 ms(DUP!) 16 bytes from fe80::ae16:2dff:fe1e:b880%lagg0, icmp_seq=1 hlim=64 time=0.222 ms --- ff02::1%lagg0 ping6 statistics --- 2 packets transmitted, 2 packets received, +10 duplicates, 0.0% packet loss round-trip min/avg/max/std-dev = 0.181/1.286/4.220/1.396 ms $ fg su - # rtsol -dD lagg0 checking if lagg0 is ready... lagg0 is ready set timer for lagg0 to 1s New timer is 1s timer expiration on lagg0, state = 1 send RS on lagg0, whose state is 2 set timer for lagg0 to 4s New timer is 4s timer expiration on lagg0, state = 2 send RS on lagg0, whose state is 2 set timer for lagg0 to 4s New timer is 4s timer expiration on lagg0, state = 2 send RS on lagg0, whose state is 2 set timer for lagg0 to 1s New timer is 1s timer expiration on lagg0, state = 2 No answer after sending 3 RSs stop timer for lagg0 there is no timer -- Greg Rivers From owner-freebsd-stable@freebsd.org Wed Aug 9 08:42:12 2017 Return-Path: Delivered-To: freebsd-stable@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 D2CE8DC6C76 for ; Wed, 9 Aug 2017 08:42:12 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88B0668411 for ; Wed, 9 Aug 2017 08:42:12 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p1949254-ipbf202funabasi.chiba.ocn.ne.jp [118.1.70.254]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id v798fuWl066495 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Wed, 9 Aug 2017 17:42:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id v798fraf021835 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Aug 2017 17:41:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id v798fphx021831; Wed, 9 Aug 2017 17:41:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 09 Aug 2017 17:41:47 +0900 (JST) Message-Id: <20170809.174147.590175436870311346.hrs@allbsd.org> To: gcr+freebsd-stable@tharned.org Cc: freebsd-stable@freebsd.org Subject: Re: SLAAC not working From: Hiroki Sato In-Reply-To: <2045487.FzlpjXtTmv@flake.tharned.org> References: <1557648.beBEYmqKBO@flake.tharned.org> <20170809.162650.970303478864091097.hrs@allbsd.org> <2045487.FzlpjXtTmv@flake.tharned.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Aug__9_17_41_47_2017_273)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [133.31.130.32]); Wed, 09 Aug 2017 17:42:08 +0900 (JST) X-Spam-Status: No, score=-96.9 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_ONE, FAKEDWORD_VERTICALLINE, QENCPTR1, URIBL_SC2_SURBL, URIBL_XS_SURBL, USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 08:42:12 -0000 ----Security_Multipart(Wed_Aug__9_17_41_47_2017_273)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg Rivers wrote in <2045487.FzlpjXtTmv@flake.tharned.org>: gc> > 2. What is shown by the command "ping6 ff02::1%lagg0" and "rtsol -dD lagg0"? gc> > gc> $ ping6 -c 2 ff02::1%lagg0 gc> PING6(56=40+8+8 bytes) fe80::ae16:2dff:fe1e:b880%lagg0 --> ff02::1%lagg0 gc> 16 bytes from fe80::ae16:2dff:fe1e:b880%lagg0, icmp_seq=0 hlim=64 time=0.181 ms gc> 16 bytes from fe80::f415:63ff:fe2b:ea06%lagg0, icmp_seq=0 hlim=64 time=0.263 ms(DUP!) gc> 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=0.318 ms(DUP!) gc> 16 bytes from fe80::8edc:d4ff:feaf:8938%lagg0, icmp_seq=0 hlim=64 time=0.369 ms(DUP!) gc> 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=0.803 ms(DUP!) gc> 16 bytes from fe80::ae16:2dff:fe1e:e998%lagg0, icmp_seq=0 hlim=64 time=0.868 ms(DUP!) gc> 16 bytes from fe80::ae16:2dff:fe1e:49f8%lagg0, icmp_seq=0 hlim=64 time=0.922 ms(DUP!) gc> 16 bytes from fe80::226:55ff:fe2f:40a4%lagg0, icmp_seq=0 hlim=64 time=0.971 ms(DUP!) gc> 16 bytes from fe80::f415:63ff:fe2b:ea06%lagg0, icmp_seq=0 hlim=64 time=2.144 ms(DUP!) gc> 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=4.154 ms(DUP!) gc> 16 bytes from fe80::f415:63ff:fe2b:e806%lagg0, icmp_seq=0 hlim=64 time=4.220 ms(DUP!) gc> 16 bytes from fe80::ae16:2dff:fe1e:b880%lagg0, icmp_seq=1 hlim=64 time=0.222 ms You should have got responses from 64:a0:e7:45:63:43 (router), namely fe80::66a0:e7ff:fe45:6343%lagg0, but it seems it did not happen for some reason. Was the router receiving the ICMPv6 ECHOes which came from fe80::ae16:2dff:fe1e:b880? gc> > 2. What is shown by the command "ping6 ff02::1%lagg0" and "rtsol -dD lagg0"? (snip) gc> # rtsol -dD lagg0 gc> checking if lagg0 is ready... gc> lagg0 is ready gc> set timer for lagg0 to 1s gc> New timer is 1s gc> timer expiration on lagg0, state = 1 gc> send RS on lagg0, whose state is 2 gc> set timer for lagg0 to 4s gc> New timer is 4s gc> timer expiration on lagg0, state = 2 gc> send RS on lagg0, whose state is 2 gc> set timer for lagg0 to 4s gc> New timer is 4s gc> timer expiration on lagg0, state = 2 gc> send RS on lagg0, whose state is 2 gc> set timer for lagg0 to 1s gc> New timer is 1s gc> timer expiration on lagg0, state = 2 gc> No answer after sending 3 RSs gc> stop timer for lagg0 gc> there is no timer This indicates that there was no RA as an answer from the router after a RS message was sent. Probably there is a problem with the link between lagg0 and the router, not specific to IPv6. -- Hiroki ----Security_Multipart(Wed_Aug__9_17_41_47_2017_273)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlmKyssACgkQTyzT2CeTzy0V9wCgtO27iflAnvqJTHzpDnogMXpq gz0AoN6Zl0M0xwthBf9UXpvDpWUVLZwS =SZT/ -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Aug__9_17_41_47_2017_273)---- From owner-freebsd-stable@freebsd.org Wed Aug 9 08:50:07 2017 Return-Path: Delivered-To: freebsd-stable@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 85816DC6F40 for ; Wed, 9 Aug 2017 08:50:07 +0000 (UTC) (envelope-from as@cmplx.uk) Received: from jail0199.vps.exonetric.net (jail0199.vps.exonetric.net [IPv6:2a02:1658:1::199:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "jail0199.vps.exonetric.net", Issuer "jail0199.vps.exonetric.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 191DB6886D for ; Wed, 9 Aug 2017 08:50:06 +0000 (UTC) (envelope-from as@cmplx.uk) Received: from jail0199.vps.exonetric.net (jail0199.vps.exonetric.net [178.250.76.108]) by jail0199.vps.exonetric.net (8.15.2/8.15.2) with ESMTPS id v798o4rF080910 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Aug 2017 08:50:04 GMT (envelope-from as@jail0199.vps.exonetric.net) Received: (from as@localhost) by jail0199.vps.exonetric.net (8.15.2/8.15.2/Submit) id v798o482080909 for freebsd-stable@freebsd.org; Wed, 9 Aug 2017 08:50:04 GMT (envelope-from as) Date: Wed, 9 Aug 2017 08:50:04 GMT From: Anton Shterenlikht Message-Id: <201708090850.v798o482080909@jail0199.vps.exonetric.net> To: freebsd-stable@freebsd.org Subject: 11.0: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 08:50:07 -0000 http://eis.bris.ac.uk/~mexas/core.txt.9 vmcore.9 is >450MB: http://cmplx.uk/pic/vmcore.9 Thanks Anton From owner-freebsd-stable@freebsd.org Wed Aug 9 12:52:46 2017 Return-Path: Delivered-To: freebsd-stable@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 538E2DCC556 for ; Wed, 9 Aug 2017 12:52:46 +0000 (UTC) (envelope-from raf@rafal.net) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) (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 281C070F22 for ; Wed, 9 Aug 2017 12:52:45 +0000 (UTC) (envelope-from raf@rafal.net) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by fallback-in2.mxes.net (Postfix) with ESMTP id 302F22FDBF1 for ; Wed, 9 Aug 2017 08:47:24 -0400 (EDT) Received: from lucy.glencottage.net (unknown [86.40.118.125]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1671D509BF for ; Wed, 9 Aug 2017 08:47:16 -0400 (EDT) From: Rafal Lukawiecki Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Is it worth waiting for AMD Opteron X3000 support in FreeBSD? Bug [221350] Message-Id: Date: Wed, 9 Aug 2017 13:47:15 +0100 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 12:52:46 -0000 Apologies if this is the wrong way to approach the FreeBSD community = wisdom: I am new here, please forgive. I am unable to boot/install = FreeBSD-11.1-RELEASE-amd64-memstick.img (dated 2017-July-21) on a = brand-new HPE MicroServer Gen10 containing an AMD Opteron X3421. Boot = hangs very early in the process. I have described the issue, and all = remedies that I have tried, in detail on the forum = (https://forums.freebsd.org/threads/61936/) and I have logged a bugzilla = bug [221350]. It has been suggested to me that FreeBSD might not yet = support this new AMD processor, or that it has issues with the chipset. = As this is equipment from a major vendor, I wonder if it is likely that = it would be supported at some stage in the *near* future. Although I am somewhat new to FreeBSD, I have 30+ years of = dev/OS/crypto/AI experience (way back from System V) and I would be = willing and hopefully able to help debug this issue if it is at all = likely that I could get support for it from the FreeBSD developers. May I politely ask if in your opinion this equipment is likely to be = supported soon? If not, I will return it to the vendor and use something = a little older. If this is the wrong place to ask, please kindly direct = me to the correct mailing list. The full details with boot console outputs: = https://forums.freebsd.org/threads/61936/ Bugzilla bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221350 Regards from Ireland, Rafal Lukawiecki=20= From owner-freebsd-stable@freebsd.org Wed Aug 9 13:08:04 2017 Return-Path: Delivered-To: freebsd-stable@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 7897ADCC96A for ; Wed, 9 Aug 2017 13:08:04 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 409EB71655; Wed, 9 Aug 2017 13:08:04 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dfQiS-0009NT-VM; Wed, 09 Aug 2017 15:08:04 +0200 Date: Wed, 9 Aug 2017 15:08:04 +0200 From: Kurt Jaeger To: Rafal Lukawiecki Cc: freebsd-stable@freebsd.org Subject: Re: Is it worth waiting for AMD Opteron X3000 support in FreeBSD? Bug [221350] Message-ID: <20170809130804.GG81427@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 13:08:04 -0000 Hi! > The full details with boot console outputs: https://forums.freebsd.org/threads/61936/ > > Bugzilla bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221350 Please compare with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213155 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213333 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214242 If this matches your problem, Martin Waschbuesch is working with the FreeBSD Foundation and Ed Maste to get this reproduced and fixed. If this does not match, please give a short heads up -- if possible, elaborate. -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-stable@freebsd.org Wed Aug 9 13:11:51 2017 Return-Path: Delivered-To: freebsd-stable@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 60C7EDCCBD2 for ; Wed, 9 Aug 2017 13:11:51 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 D417171990 for ; Wed, 9 Aug 2017 13:11:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 8A63F28458; Wed, 9 Aug 2017 15:11:41 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6D40628454; Wed, 9 Aug 2017 15:11:40 +0200 (CEST) Subject: Re: Is it worth waiting for AMD Opteron X3000 support in FreeBSD? Bug [221350] To: Rafal Lukawiecki , freebsd-stable@freebsd.org References: From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <598B0A0C.1040008@quip.cz> Date: Wed, 9 Aug 2017 15:11:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 13:11:51 -0000 Rafal Lukawiecki wrote on 2017/08/09 14:47: > > Apologies if this is the wrong way to approach the FreeBSD community wisdom: I am new here, please forgive. I am unable to boot/install FreeBSD-11.1-RELEASE-amd64-memstick.img (dated 2017-July-21) on a brand-new HPE MicroServer Gen10 containing an AMD Opteron X3421. Boot hangs very early in the process. I have described the issue, and all remedies that I have tried, in detail on the forum (https://forums.freebsd.org/threads/61936/) and I have logged a bugzilla bug [221350]. It has been suggested to me that FreeBSD might not yet support this new AMD processor, or that it has issues with the chipset. As this is equipment from a major vendor, I wonder if it is likely that it would be supported at some stage in the *near* future. > > Although I am somewhat new to FreeBSD, I have 30+ years of dev/OS/crypto/AI experience (way back from System V) and I would be willing and hopefully able to help debug this issue if it is at all likely that I could get support for it from the FreeBSD developers. > > May I politely ask if in your opinion this equipment is likely to be supported soon? If not, I will return it to the vendor and use something a little older. If this is the wrong place to ask, please kindly direct me to the correct mailing list. > > The full details with boot console outputs: https://forums.freebsd.org/threads/61936/ > > Bugzilla bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221350 I suggest you to test booting with fresh image of CURRENT (12.0). You can find it on ftp.freebsd.org /pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/12.0 Or you can try to boot some older ISO like 10.3. I remember some regression years ago with booting problem on newer version. Miroslav Lachman From owner-freebsd-stable@freebsd.org Wed Aug 9 15:05:38 2017 Return-Path: Delivered-To: freebsd-stable@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 4E06DDCF1E8 for ; Wed, 9 Aug 2017 15:05:38 +0000 (UTC) (envelope-from raf@rafal.net) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) (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 08132754EE for ; Wed, 9 Aug 2017 15:05:37 +0000 (UTC) (envelope-from raf@rafal.net) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in2.mxes.net (Postfix) with ESMTP id 3404A2FD7E0 for ; Wed, 9 Aug 2017 11:05:30 -0400 (EDT) Received: from [172.20.10.2] (unknown [213.233.150.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8232F22E2B7 for ; Wed, 9 Aug 2017 11:05:17 -0400 (EDT) From: Rafal Lukawiecki Mime-Version: 1.0 (1.0) Date: Wed, 9 Aug 2017 16:05:15 +0100 Subject: Re: Is it worth waiting for AMD Opteron X3000 support in FreeBSD? Bug [221350] Message-Id: <7B1C3028-EBD7-4671-AB6E-CD7EB72F99DF@rafal.net> References: <20170809130804.GG81427@home.opsec.eu> In-Reply-To: <20170809130804.GG81427@home.opsec.eu> To: freebsd-stable@freebsd.org X-Mailer: iPad Mail (14G60) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 15:05:38 -0000 Many thanks, Kurt, for pointing out those other 3 bug reports. On the face o= f it, they look different to mine. In my case, and in the case of another us= er who has reported this on the FreeNAS forum (affecting FreeBSD 11.0), the b= oot progresses past the point shown in the 3 reports that you have suggested= , by perhaps another 5-10 seconds. Kindly have a look at the screenshots I h= ave submitted within the bug report here: https://bugs.freebsd.org/bugzilla/= show_bug.cgi?id=3D221350 ...and you may notice that the boot process hangs just after it has displaye= d messages about pci0 acpi. The verbose boot (screenshot also above) shows t= hat the boot process seems to have just identified memory modules on pcib0. T= he remaining screenshots show kernel panics when I tried to disable ACPI. I will test the boot with the other releases of FreeBSD as suggested by Miro= slav Lachman, later today, and I will report back here, then I suppose I can= make a decision if to move this discussion to freebsd-current, as recommend= ed by @wishmaster. I apologise for confusing which list to keep reporting to= . Many thanks, Rafal Lukawiecki= From owner-freebsd-stable@freebsd.org Wed Aug 9 17:40:30 2017 Return-Path: Delivered-To: freebsd-stable@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 CB350DD1F78 for ; Wed, 9 Aug 2017 17:40:30 +0000 (UTC) (envelope-from raf@rafal.net) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 A7E2A7E63B for ; Wed, 9 Aug 2017 17:40:30 +0000 (UTC) (envelope-from raf@rafal.net) Received: from lucy.glencottage.net (unknown [86.40.118.125]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D37B9509B8; Wed, 9 Aug 2017 13:40:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Is it worth waiting for AMD Opteron X3000 support in FreeBSD? Bug [221350] From: Rafal Lukawiecki In-Reply-To: <598B0A0C.1040008@quip.cz> Date: Wed, 9 Aug 2017 18:40:25 +0100 Cc: artemrts@ukr.net Content-Transfer-Encoding: quoted-printable Message-Id: <3D6F0A37-6C88-42E7-B9D9-8EBB89483471@rafal.net> References: <598B0A0C.1040008@quip.cz> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 17:40:30 -0000 Following suggestion by Miroslav Lachman I have tested a few other = releases of FreeBSD to see if this issue still persists, and if it was = perhaps a regression. Unfortunately, in all the tests, 9.3-12.0-CURRENT, = I get exactly the same error. The initial boot stops after displaying = messages about ACPI or pcib0 memory detection. To be precise, these are the versions that I have just tested, in all = cases having validated the integrity of the download: FreeBSD-9.3-RELEASE-amd64-memstick.img FreeBSD-11.1-RELEASE-amd64-memstick.img FreeBSD-11.1-STABLE-amd64-20170807-r322164-memstick.img FreeBSD-12.0-CURRENT-amd64-20170807-r322167-memstick.img I have updated the bug [221350] description at: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221350 Please advise me @wishmaster, and anyone else, if in your opinion I = should start a new discussion on another, more appropriate FreeBSD = mailing list. Thank you for your kind help.= From owner-freebsd-stable@freebsd.org Thu Aug 10 01:36:24 2017 Return-Path: Delivered-To: freebsd-stable@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 4F07FDDAF9A for ; Thu, 10 Aug 2017 01:36:24 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (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 B87AF68517; Thu, 10 Aug 2017 01:36:23 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:5919:2b26:ea54:e4b9]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v7A1aGS6023811 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Aug 2017 20:36:22 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2016; t=1502328982; bh=LFOk/yaWltlPZOgI81m1OW6HpNpeRUD7hceeIuEZVoo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=eFhpP8BhKHB5jsv3V7kIyKFxclDQ76xKukXBV3aDgVKnevLbCwQLXQ7BRN5tbhSzZ CZPw+XiYPzafUakUIrNpgS7jEgeT58dbk9Ddou8m822gj2lZWC5nhGH6IPSJsVhq1S O+kRQjGv7JFoKIyh5ViuO34Cg3s91q4W3DCojKKaNZKurAndPAVTqmEzth0BYE92gl 02pDzEGwzf6VWm0s5b7j/BrdVTShBURiUlWTe1RmCR2OMNH/ct9sSwMYoiyngrtge0 6iaQgMMpUlS2ihBwt93W4IyuYrBnYr8wMEwPaEYixFAmUfImbukqGetF/JqBAjDNS4 6aDvMRySL1Xiw== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:5919:2b26:ea54:e4b9] claimed to be flake.tharned.org From: Greg Rivers To: Hiroki Sato Cc: freebsd-stable@freebsd.org Subject: Re: SLAAC not working Date: Wed, 09 Aug 2017 20:36:16 -0500 Message-ID: <2260730.UN1ijHaZFf@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170809.174147.590175436870311346.hrs@allbsd.org> References: <1557648.beBEYmqKBO@flake.tharned.org> <2045487.FzlpjXtTmv@flake.tharned.org> <20170809.174147.590175436870311346.hrs@allbsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Wed, 09 Aug 2017 20:36:22 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 01:36:24 -0000 On Wednesday, August 09, 2017 17:41:47 Hiroki Sato wrote: > Greg Rivers wrote > in <2045487.FzlpjXtTmv@flake.tharned.org>: > > gc> > 2. What is shown by the command "ping6 ff02::1%lagg0" ...? > gc> > > gc> $ ping6 -c 2 ff02::1%lagg0 > gc> PING6(56=40+8+8 bytes) fe80::ae16:2dff:fe1e:b880%lagg0 --> ff02::1%lagg0 > gc> 16 bytes from fe80::ae16:2dff:fe1e:b880%lagg0, icmp_seq=0 hlim=64 time=0.181 ms > [snip] > > You should have got responses from 64:a0:e7:45:63:43 (router), namely > fe80::66a0:e7ff:fe45:6343%lagg0, but it seems it did not happen for > some reason. Was the router receiving the ICMPv6 ECHOes which came > from fe80::ae16:2dff:fe1e:b880? > I can't tell from the host; I'll have to engage the networking guys. > gc> > 2. What is shown by the command ... "rtsol -dD lagg0"? > (snip) > gc> # rtsol -dD lagg0 > gc> checking if lagg0 is ready... > gc> lagg0 is ready > gc> set timer for lagg0 to 1s > gc> New timer is 1s > gc> timer expiration on lagg0, state = 1 > gc> send RS on lagg0, whose state is 2 > gc> set timer for lagg0 to 4s > gc> New timer is 4s > gc> timer expiration on lagg0, state = 2 > gc> send RS on lagg0, whose state is 2 > gc> set timer for lagg0 to 4s > gc> New timer is 4s > gc> timer expiration on lagg0, state = 2 > gc> send RS on lagg0, whose state is 2 > gc> set timer for lagg0 to 1s > gc> New timer is 1s > gc> timer expiration on lagg0, state = 2 > gc> No answer after sending 3 RSs > gc> stop timer for lagg0 > gc> there is no timer > > This indicates that there was no RA as an answer from the router > after a RS message was sent. Probably there is a problem with the > link between lagg0 and the router, not specific to IPv6. > That's a reasonable hypothesis, but it's contradicted by further testing. I started a packet capture on the host: # tcpdump -Z gcr -w /tmp/hostname.pcap -i lagg0 ip6 Then I ran rtsol on the host again: # rtsol -dD lagg0 The output was as before, but the pcap[1] shows that RAs were received. In response to the RSs sent by the host (frames 1 and 2), both routers on this network responded with RAs (frames 3 and 4). So it would appear that the disconnect is not between the routers and lagg0, rather it's between lagg0 and the host's IPv6 stack. tcpdump saw the RAs on lagg0, but rtsol did not. Could it be that the router replies are out of spec somehow and are being discarded? Where does debug output from net.inet6.icmp6.nd6_debug=1 go? -- Greg Rivers [1] Frame 1: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:08.515684000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315708.515684000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 70 bytes (560 bits) Capture Length: 70 bytes (560 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80), Dst: IPv6mcast_02 (33:33:00:00:00:02) Destination: IPv6mcast_02 (33:33:00:00:00:02) Address: IPv6mcast_02 (33:33:00:00:00:02) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80::ae16:2dff:fe1e:b880, Dst: ff02::2 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 16 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80::ae16:2dff:fe1e:b880 Destination: ff02::2 [Source SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Solicitation (133) Code: 0 Checksum: 0x57c3 [correct] [Checksum Status: Good] Reserved: 00000000 ICMPv6 Option (Source link-layer address : ac:16:2d:1e:b8:80) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Frame 2: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:08.515751000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315708.515751000 seconds [Time delta from previous captured frame: 0.000067000 seconds] [Time delta from previous displayed frame: 0.000067000 seconds] [Time since reference or first frame: 0.000067000 seconds] Frame Number: 2 Frame Length: 70 bytes (560 bits) Capture Length: 70 bytes (560 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80), Dst: IPv6mcast_02 (33:33:00:00:00:02) Destination: IPv6mcast_02 (33:33:00:00:00:02) Address: IPv6mcast_02 (33:33:00:00:00:02) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80::ae16:2dff:fe1e:b880, Dst: ff02::2 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 16 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80::ae16:2dff:fe1e:b880 Destination: ff02::2 [Source SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Solicitation (133) Code: 0 Checksum: 0x57c3 [correct] [Checksum Status: Good] Reserved: 00000000 ICMPv6 Option (Source link-layer address : ac:16:2d:1e:b8:80) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Frame 3: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:08.516365000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315708.516365000 seconds [Time delta from previous captured frame: 0.000614000 seconds] [Time delta from previous displayed frame: 0.000614000 seconds] [Time since reference or first frame: 0.000681000 seconds] Frame Number: 3 Frame Length: 118 bytes (944 bits) Capture Length: 118 bytes (944 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_41:13:43 (64:a0:e7:41:13:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_41:13:43 (64:a0:e7:41:13:43) Address: Cisco_41:13:43 (64:a0:e7:41:13:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::3, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 64 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::3 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Advertisement (134) Code: 0 Checksum: 0x3f47 [correct] [Checksum Status: Good] Cur hop limit: 64 Flags: 0x00, Prf (Default Router Preference): Medium 0... .... = Managed address configuration: Not set .0.. .... = Other configuration: Not set ..0. .... = Home Agent: Not set ...0 0... = Prf (Default Router Preference): Medium (0) .... .0.. = Proxy: Not set .... ..0. = Reserved: 0 Router lifetime (s): 1800 Reachable time (ms): 0 Retrans timer (ms): 0 ICMPv6 Option (Source link-layer address : 64:a0:e7:41:13:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_41:13:43 (64:a0:e7:41:13:43) ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) Type: Prefix information (3) Length: 4 (32 bytes) Prefix Length: 64 Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) 1... .... = On-link flag(L): Set .1.. .... = Autonomous address-configuration flag(A): Set ..0. .... = Router address flag(R): Not set ...0 0000 = Reserved: 0 Valid Lifetime: 2592000 Preferred Lifetime: 604800 Reserved Prefix: 26xx:xxxx:4013:23:: ICMPv6 Option (MTU : 9216) Type: MTU (5) Length: 1 (8 bytes) Reserved MTU: 9216 Frame 4: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:08.516650000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315708.516650000 seconds [Time delta from previous captured frame: 0.000285000 seconds] [Time delta from previous displayed frame: 0.000285000 seconds] [Time since reference or first frame: 0.000966000 seconds] Frame Number: 4 Frame Length: 118 bytes (944 bits) Capture Length: 118 bytes (944 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_45:63:43 (64:a0:e7:45:63:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_45:63:43 (64:a0:e7:45:63:43) Address: Cisco_45:63:43 (64:a0:e7:45:63:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::2, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 64 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::2 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Advertisement (134) Code: 0 Checksum: 0xef43 [correct] [Checksum Status: Good] Cur hop limit: 64 Flags: 0x00, Prf (Default Router Preference): Medium 0... .... = Managed address configuration: Not set .0.. .... = Other configuration: Not set ..0. .... = Home Agent: Not set ...0 0... = Prf (Default Router Preference): Medium (0) .... .0.. = Proxy: Not set .... ..0. = Reserved: 0 Router lifetime (s): 1800 Reachable time (ms): 0 Retrans timer (ms): 0 ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) Type: Prefix information (3) Length: 4 (32 bytes) Prefix Length: 64 Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) 1... .... = On-link flag(L): Set .1.. .... = Autonomous address-configuration flag(A): Set ..0. .... = Router address flag(R): Not set ...0 0000 = Reserved: 0 Valid Lifetime: 2592000 Preferred Lifetime: 604800 Reserved Prefix: 26xx:xxxx:4013:23:: ICMPv6 Option (MTU : 9216) Type: MTU (5) Length: 1 (8 bytes) Reserved MTU: 9216 Frame 5: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:12.519651000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315712.519651000 seconds [Time delta from previous captured frame: 4.003001000 seconds] [Time delta from previous displayed frame: 4.003001000 seconds] [Time since reference or first frame: 4.003967000 seconds] Frame Number: 5 Frame Length: 70 bytes (560 bits) Capture Length: 70 bytes (560 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80), Dst: IPv6mcast_02 (33:33:00:00:00:02) Destination: IPv6mcast_02 (33:33:00:00:00:02) Address: IPv6mcast_02 (33:33:00:00:00:02) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80::ae16:2dff:fe1e:b880, Dst: ff02::2 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 16 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80::ae16:2dff:fe1e:b880 Destination: ff02::2 [Source SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Solicitation (133) Code: 0 Checksum: 0x57c3 [correct] [Checksum Status: Good] Reserved: 00000000 ICMPv6 Option (Source link-layer address : ac:16:2d:1e:b8:80) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Frame 6: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:12.519757000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315712.519757000 seconds [Time delta from previous captured frame: 0.000106000 seconds] [Time delta from previous displayed frame: 0.000106000 seconds] [Time since reference or first frame: 4.004073000 seconds] Frame Number: 6 Frame Length: 70 bytes (560 bits) Capture Length: 70 bytes (560 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80), Dst: IPv6mcast_02 (33:33:00:00:00:02) Destination: IPv6mcast_02 (33:33:00:00:00:02) Address: IPv6mcast_02 (33:33:00:00:00:02) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80::ae16:2dff:fe1e:b880, Dst: ff02::2 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 16 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80::ae16:2dff:fe1e:b880 Destination: ff02::2 [Source SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Solicitation (133) Code: 0 Checksum: 0x57c3 [correct] [Checksum Status: Good] Reserved: 00000000 ICMPv6 Option (Source link-layer address : ac:16:2d:1e:b8:80) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Frame 7: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:12.520260000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315712.520260000 seconds [Time delta from previous captured frame: 0.000503000 seconds] [Time delta from previous displayed frame: 0.000503000 seconds] [Time since reference or first frame: 4.004576000 seconds] Frame Number: 7 Frame Length: 118 bytes (944 bits) Capture Length: 118 bytes (944 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_41:13:43 (64:a0:e7:41:13:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_41:13:43 (64:a0:e7:41:13:43) Address: Cisco_41:13:43 (64:a0:e7:41:13:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::3, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 64 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::3 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Advertisement (134) Code: 0 Checksum: 0x3f47 [correct] [Checksum Status: Good] Cur hop limit: 64 Flags: 0x00, Prf (Default Router Preference): Medium 0... .... = Managed address configuration: Not set .0.. .... = Other configuration: Not set ..0. .... = Home Agent: Not set ...0 0... = Prf (Default Router Preference): Medium (0) .... .0.. = Proxy: Not set .... ..0. = Reserved: 0 Router lifetime (s): 1800 Reachable time (ms): 0 Retrans timer (ms): 0 ICMPv6 Option (Source link-layer address : 64:a0:e7:41:13:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_41:13:43 (64:a0:e7:41:13:43) ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) Type: Prefix information (3) Length: 4 (32 bytes) Prefix Length: 64 Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) 1... .... = On-link flag(L): Set .1.. .... = Autonomous address-configuration flag(A): Set ..0. .... = Router address flag(R): Not set ...0 0000 = Reserved: 0 Valid Lifetime: 2592000 Preferred Lifetime: 604800 Reserved Prefix: 26xx:xxxx:4013:23:: ICMPv6 Option (MTU : 9216) Type: MTU (5) Length: 1 (8 bytes) Reserved MTU: 9216 Frame 8: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:12.520287000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315712.520287000 seconds [Time delta from previous captured frame: 0.000027000 seconds] [Time delta from previous displayed frame: 0.000027000 seconds] [Time since reference or first frame: 4.004603000 seconds] Frame Number: 8 Frame Length: 118 bytes (944 bits) Capture Length: 118 bytes (944 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_45:63:43 (64:a0:e7:45:63:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_45:63:43 (64:a0:e7:45:63:43) Address: Cisco_45:63:43 (64:a0:e7:45:63:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::2, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 64 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::2 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Advertisement (134) Code: 0 Checksum: 0xef43 [correct] [Checksum Status: Good] Cur hop limit: 64 Flags: 0x00, Prf (Default Router Preference): Medium 0... .... = Managed address configuration: Not set .0.. .... = Other configuration: Not set ..0. .... = Home Agent: Not set ...0 0... = Prf (Default Router Preference): Medium (0) .... .0.. = Proxy: Not set .... ..0. = Reserved: 0 Router lifetime (s): 1800 Reachable time (ms): 0 Retrans timer (ms): 0 ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) Type: Prefix information (3) Length: 4 (32 bytes) Prefix Length: 64 Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) 1... .... = On-link flag(L): Set .1.. .... = Autonomous address-configuration flag(A): Set ..0. .... = Router address flag(R): Not set ...0 0000 = Reserved: 0 Valid Lifetime: 2592000 Preferred Lifetime: 604800 Reserved Prefix: 26xx:xxxx:4013:23:: ICMPv6 Option (MTU : 9216) Type: MTU (5) Length: 1 (8 bytes) Reserved MTU: 9216 Frame 9: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:13.516290000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315713.516290000 seconds [Time delta from previous captured frame: 0.996003000 seconds] [Time delta from previous displayed frame: 0.996003000 seconds] [Time since reference or first frame: 5.000606000 seconds] Frame Number: 9 Frame Length: 86 bytes (688 bits) Capture Length: 86 bytes (688 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_41:13:43 (64:a0:e7:41:13:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_41:13:43 (64:a0:e7:41:13:43) Address: Cisco_41:13:43 (64:a0:e7:41:13:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::3, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 32 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::3 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Neighbor Solicitation (135) Code: 0 Checksum: 0x901e [correct] [Checksum Status: Good] Reserved: 00000000 Target Address: fe80::ae16:2dff:fe1e:b880 ICMPv6 Option (Source link-layer address : 64:a0:e7:41:13:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_41:13:43 (64:a0:e7:41:13:43) Frame 10: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:13.533062000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315713.533062000 seconds [Time delta from previous captured frame: 0.016772000 seconds] [Time delta from previous displayed frame: 0.016772000 seconds] [Time since reference or first frame: 5.017378000 seconds] Frame Number: 10 Frame Length: 86 bytes (688 bits) Capture Length: 86 bytes (688 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_45:63:43 (64:a0:e7:45:63:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_45:63:43 (64:a0:e7:45:63:43) Address: Cisco_45:63:43 (64:a0:e7:45:63:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::2, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 32 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::2 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Neighbor Solicitation (135) Code: 0 Checksum: 0x401b [correct] [Checksum Status: Good] Reserved: 00000000 Target Address: fe80::ae16:2dff:fe1e:b880 ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) Frame 11: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:14.516568000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315714.516568000 seconds [Time delta from previous captured frame: 0.983506000 seconds] [Time delta from previous displayed frame: 0.983506000 seconds] [Time since reference or first frame: 6.000884000 seconds] Frame Number: 11 Frame Length: 86 bytes (688 bits) Capture Length: 86 bytes (688 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_41:13:43 (64:a0:e7:41:13:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_41:13:43 (64:a0:e7:41:13:43) Address: Cisco_41:13:43 (64:a0:e7:41:13:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::3, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 32 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::3 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Neighbor Solicitation (135) Code: 0 Checksum: 0x901e [correct] [Checksum Status: Good] Reserved: 00000000 Target Address: fe80::ae16:2dff:fe1e:b880 ICMPv6 Option (Source link-layer address : 64:a0:e7:41:13:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_41:13:43 (64:a0:e7:41:13:43) Frame 12: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:14.533211000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315714.533211000 seconds [Time delta from previous captured frame: 0.016643000 seconds] [Time delta from previous displayed frame: 0.016643000 seconds] [Time since reference or first frame: 6.017527000 seconds] Frame Number: 12 Frame Length: 86 bytes (688 bits) Capture Length: 86 bytes (688 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_45:63:43 (64:a0:e7:45:63:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_45:63:43 (64:a0:e7:45:63:43) Address: Cisco_45:63:43 (64:a0:e7:45:63:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::2, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 32 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::2 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Neighbor Solicitation (135) Code: 0 Checksum: 0x401b [correct] [Checksum Status: Good] Reserved: 00000000 Target Address: fe80::ae16:2dff:fe1e:b880 ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) Frame 13: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:15.516875000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315715.516875000 seconds [Time delta from previous captured frame: 0.983664000 seconds] [Time delta from previous displayed frame: 0.983664000 seconds] [Time since reference or first frame: 7.001191000 seconds] Frame Number: 13 Frame Length: 86 bytes (688 bits) Capture Length: 86 bytes (688 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_41:13:43 (64:a0:e7:41:13:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_41:13:43 (64:a0:e7:41:13:43) Address: Cisco_41:13:43 (64:a0:e7:41:13:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::3, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 32 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::3 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Neighbor Solicitation (135) Code: 0 Checksum: 0x901e [correct] [Checksum Status: Good] Reserved: 00000000 Target Address: fe80::ae16:2dff:fe1e:b880 ICMPv6 Option (Source link-layer address : 64:a0:e7:41:13:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_41:13:43 (64:a0:e7:41:13:43) Frame 14: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:15.533308000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315715.533308000 seconds [Time delta from previous captured frame: 0.016433000 seconds] [Time delta from previous displayed frame: 0.016433000 seconds] [Time since reference or first frame: 7.017624000 seconds] Frame Number: 14 Frame Length: 86 bytes (688 bits) Capture Length: 86 bytes (688 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_45:63:43 (64:a0:e7:45:63:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_45:63:43 (64:a0:e7:45:63:43) Address: Cisco_45:63:43 (64:a0:e7:45:63:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::2, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 32 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::2 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Neighbor Solicitation (135) Code: 0 Checksum: 0x401b [correct] [Checksum Status: Good] Reserved: 00000000 Target Address: fe80::ae16:2dff:fe1e:b880 ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) Frame 15: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:16.526856000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315716.526856000 seconds [Time delta from previous captured frame: 0.993548000 seconds] [Time delta from previous displayed frame: 0.993548000 seconds] [Time since reference or first frame: 8.011172000 seconds] Frame Number: 15 Frame Length: 70 bytes (560 bits) Capture Length: 70 bytes (560 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80), Dst: IPv6mcast_02 (33:33:00:00:00:02) Destination: IPv6mcast_02 (33:33:00:00:00:02) Address: IPv6mcast_02 (33:33:00:00:00:02) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80::ae16:2dff:fe1e:b880, Dst: ff02::2 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 16 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80::ae16:2dff:fe1e:b880 Destination: ff02::2 [Source SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Solicitation (133) Code: 0 Checksum: 0x57c3 [correct] [Checksum Status: Good] Reserved: 00000000 ICMPv6 Option (Source link-layer address : ac:16:2d:1e:b8:80) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Frame 16: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:16.526921000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315716.526921000 seconds [Time delta from previous captured frame: 0.000065000 seconds] [Time delta from previous displayed frame: 0.000065000 seconds] [Time since reference or first frame: 8.011237000 seconds] Frame Number: 16 Frame Length: 70 bytes (560 bits) Capture Length: 70 bytes (560 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80), Dst: IPv6mcast_02 (33:33:00:00:00:02) Destination: IPv6mcast_02 (33:33:00:00:00:02) Address: IPv6mcast_02 (33:33:00:00:00:02) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80::ae16:2dff:fe1e:b880, Dst: ff02::2 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 16 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80::ae16:2dff:fe1e:b880 Destination: ff02::2 [Source SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Solicitation (133) Code: 0 Checksum: 0x57c3 [correct] [Checksum Status: Good] Reserved: 00000000 ICMPv6 Option (Source link-layer address : ac:16:2d:1e:b8:80) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Frame 17: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:16.527423000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315716.527423000 seconds [Time delta from previous captured frame: 0.000502000 seconds] [Time delta from previous displayed frame: 0.000502000 seconds] [Time since reference or first frame: 8.011739000 seconds] Frame Number: 17 Frame Length: 118 bytes (944 bits) Capture Length: 118 bytes (944 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_45:63:43 (64:a0:e7:45:63:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_45:63:43 (64:a0:e7:45:63:43) Address: Cisco_45:63:43 (64:a0:e7:45:63:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::2, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 64 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::2 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Advertisement (134) Code: 0 Checksum: 0xef43 [correct] [Checksum Status: Good] Cur hop limit: 64 Flags: 0x00, Prf (Default Router Preference): Medium 0... .... = Managed address configuration: Not set .0.. .... = Other configuration: Not set ..0. .... = Home Agent: Not set ...0 0... = Prf (Default Router Preference): Medium (0) .... .0.. = Proxy: Not set .... ..0. = Reserved: 0 Router lifetime (s): 1800 Reachable time (ms): 0 Retrans timer (ms): 0 ICMPv6 Option (Source link-layer address : 64:a0:e7:45:63:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_45:63:43 (64:a0:e7:45:63:43) ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) Type: Prefix information (3) Length: 4 (32 bytes) Prefix Length: 64 Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) 1... .... = On-link flag(L): Set .1.. .... = Autonomous address-configuration flag(A): Set ..0. .... = Router address flag(R): Not set ...0 0000 = Reserved: 0 Valid Lifetime: 2592000 Preferred Lifetime: 604800 Reserved Prefix: 26xx:xxxx:4013:23:: ICMPv6 Option (MTU : 9216) Type: MTU (5) Length: 1 (8 bytes) Reserved MTU: 9216 Frame 18: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) Encapsulation type: Ethernet (1) Arrival Time: Aug 9, 2017 16:55:16.527792000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1502315716.527792000 seconds [Time delta from previous captured frame: 0.000369000 seconds] [Time delta from previous displayed frame: 0.000369000 seconds] [Time since reference or first frame: 8.012108000 seconds] Frame Number: 18 Frame Length: 118 bytes (944 bits) Capture Length: 118 bytes (944 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ipv6:icmpv6] Ethernet II, Src: Cisco_41:13:43 (64:a0:e7:41:13:43), Dst: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Destination: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) Address: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Cisco_41:13:43 (64:a0:e7:41:13:43) Address: Cisco_41:13:43 (64:a0:e7:41:13:43) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80:26xx:xxxx:4013:23::3, Dst: fe80::ae16:2dff:fe1e:b880 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT) .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Payload Length: 64 Next Header: ICMPv6 (58) Hop Limit: 255 Source: fe80:26xx:xxxx:4013:23::3 Destination: fe80::ae16:2dff:fe1e:b880 [Destination SA MAC: HewlettP_1e:b8:80 (ac:16:2d:1e:b8:80)] [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol v6 Type: Router Advertisement (134) Code: 0 Checksum: 0x3f47 [correct] [Checksum Status: Good] Cur hop limit: 64 Flags: 0x00, Prf (Default Router Preference): Medium 0... .... = Managed address configuration: Not set .0.. .... = Other configuration: Not set ..0. .... = Home Agent: Not set ...0 0... = Prf (Default Router Preference): Medium (0) .... .0.. = Proxy: Not set .... ..0. = Reserved: 0 Router lifetime (s): 1800 Reachable time (ms): 0 Retrans timer (ms): 0 ICMPv6 Option (Source link-layer address : 64:a0:e7:41:13:43) Type: Source link-layer address (1) Length: 1 (8 bytes) Link-layer address: Cisco_41:13:43 (64:a0:e7:41:13:43) ICMPv6 Option (Prefix information : 26xx:xxxx:4013:23::/64) Type: Prefix information (3) Length: 4 (32 bytes) Prefix Length: 64 Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) 1... .... = On-link flag(L): Set .1.. .... = Autonomous address-configuration flag(A): Set ..0. .... = Router address flag(R): Not set ...0 0000 = Reserved: 0 Valid Lifetime: 2592000 Preferred Lifetime: 604800 Reserved Prefix: 26xx:xxxx:4013:23:: ICMPv6 Option (MTU : 9216) Type: MTU (5) Length: 1 (8 bytes) Reserved MTU: 9216 From owner-freebsd-stable@freebsd.org Thu Aug 10 01:58:15 2017 Return-Path: Delivered-To: freebsd-stable@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 0BA52DDC20D for ; Thu, 10 Aug 2017 01:58:15 +0000 (UTC) (envelope-from rajil.s@gmail.com) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 CFD79699EE for ; Thu, 10 Aug 2017 01:58:14 +0000 (UTC) (envelope-from rajil.s@gmail.com) Received: by mail-pg0-x232.google.com with SMTP id u5so35153382pgn.0 for ; Wed, 09 Aug 2017 18:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=aDh6Y821PYDsT4BdmlKTdUj9yK7JHNeimj8oVA4NRBY=; b=XkNCFEid0rMRIzCW9zQHDhvK91yOjr6rwx/nCsgK7XOJaXzqXv14s0RDAGGiSDDOP1 61zeP907z9G3uyY9PjcYYg0gFKLB+IAr/yZ+rtSfX5CWpOa4BFOs9N3o8+r7rr/kQ7Er yo90364OQDGC8mukcTnYe/l6uGQiCEqlU/IC/MPxRi8/KPHOsa0N4zZcomhgZhfM/n4S ncpcuUjAtKlqAzibFocTiB8epVxy4fn6pRvcTmUgc7vPaO43kZxUwa5oYCRBS+++szOv H1mZqNldlpx1MaWrjeFlNJqnmr9jiJTlfmnS9q+U1TXPWa/Zb5ShoRM1qjgzyM8SVXrk lCKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=aDh6Y821PYDsT4BdmlKTdUj9yK7JHNeimj8oVA4NRBY=; b=HC+QBrnAi8cpB1996MfWuEdq2T7i2JR7KOhfyI5FNRzogafo1q2IKjFgBjwSghErVd HBOsEdj0nZHVIJEb/8wIjMsIilWU+a0jIqLEFlVFmjRPuCxndNxSFEkyIZ3JqHq50sMw I2AajmkRM+oeksx++cjNr5MZSGzCv2BSofYDS7R8DVJcaohvNpXgEog4mZiKxWn0VcqC 0TXGiWbw47ZI1W56yMN6z4lI2gwagg53UBVEaEFc/l6HK9Qb7k20dBdpSl4XFweizqTd GrziY2rykKZ1A4gKLq3wpITYonqODuarrW9dbVUMO8OX6MnzQ7ncWoKU0z7RrEyUCZZO 6v0Q== X-Gm-Message-State: AHYfb5h+SZcjT3N/qMEgmyqpfuGg2TsJzAc9t5d9hwvQVPdFRKreVtf1 fX4MvuYkDaoduzg0Rvs= X-Received: by 10.84.169.3 with SMTP id g3mr11148657plb.136.1502330294231; Wed, 09 Aug 2017 18:58:14 -0700 (PDT) Received: from [172.16.1.28] (c-73-232-201-213.hsd1.tx.comcast.net. [73.232.201.213]) by smtp.gmail.com with ESMTPSA id j63sm4151266pge.88.2017.08.09.18.58.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 18:58:13 -0700 (PDT) To: freebsd-stable@freebsd.org From: Rajil Saraswat Subject: Infrequent boot failure with 11.1 Message-ID: Date: Wed, 9 Aug 2017 20:58:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 01:58:15 -0000 Hello, I have a Supermicro X10Dri-T motherboard which refuses to boot 50% of the time. It hangs with the message DMAR: Found table at 0x7995ccb0 x2APIC should be disabled by DMAR table but already enabled by BIOS; enabling. Event timer "LAPIC" quality 600 ACPI APIC Table: Package ID shift: 5 L3 cache ID shift: 5 L2 cache ID shift: 1 L1 cache ID shift: 1 Core ID shift: 1 I have tried setting X2APIC on and off in the BIOS but it hasnt helped. I also custom compiled the kernel without the option EARLY_AP_STARTUP. The full log is at https://pastebin.com/FUdUKaR2 Anybody has a idea what could be the issue? Thanks From owner-freebsd-stable@freebsd.org Thu Aug 10 20:50:23 2017 Return-Path: Delivered-To: freebsd-stable@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 92833DDCBD4 for ; Thu, 10 Aug 2017 20:50:23 +0000 (UTC) (envelope-from bounce@ims2.isendservice.com.br) Received: from ims2.isendservice.com.br (ims2.isendservice.com.br [54.232.111.224]) by mx1.freebsd.org (Postfix) with ESMTP id 1674570F79 for ; Thu, 10 Aug 2017 20:50:22 +0000 (UTC) (envelope-from bounce@ims2.isendservice.com.br) Received: from localhost (localhost [127.0.0.1]) by ims2.isendservice.com.br (Postfix) with ESMTP id 8CDB643971 for ; Thu, 10 Aug 2017 17:37:28 -0300 (BRT) Date: Thu, 10 Aug 2017 17:37:28 -0300 (BRT) From: FIERGS | FATEC - Faculdade SENAI de Tecnologia Reply-To: posgraduacao@senairs.org.br To: freebsd-stable@freebsd.org Message-ID: <470886323.885727.1502397448572.JavaMail.root@ims2> Subject: =?ISO-8859-1?Q?Fa=E7a_sua_P=D3S-Gradua=E7=E3o_na_Facul?= =?ISO-8859-1?Q?dade_SENAI_|_Inscri=E7=F5es_Abertas?= bounce-key: <2420-22522874-1934703> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:50:23 -0000 From owner-freebsd-stable@freebsd.org Fri Aug 11 01:22:24 2017 Return-Path: Delivered-To: freebsd-stable@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 7A8ABCA15E4 for ; Fri, 11 Aug 2017 01:22:24 +0000 (UTC) (envelope-from rajil.s@gmail.com) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::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 4B7C57DE08 for ; Fri, 11 Aug 2017 01:22:24 +0000 (UTC) (envelope-from rajil.s@gmail.com) Received: by mail-pg0-x235.google.com with SMTP id v77so9487840pgb.3 for ; Thu, 10 Aug 2017 18:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=tFss6HjU5OT5iez/r0jH9iiXQfAzQrkJMyX/31mBGkg=; b=WpSsbkhA5VDrtdiEIetNQddxPWb7hP2Kvitv33Yjeh6cI7yWLmcuKUVIXQe2WpQ1FM pHoEPgSTeuHCekmkNRiGk/vz1dA6RQ1NlIt7po4EdeqjXyq5tlAfGFP07LLJkxMhVJ08 TFUWGDARIlO2ICpbRl+LyU+xzh6LYZnJGq4TMyh7T94mKPhLC+Sd4bJ1uLiBbtJMt3D4 64yuh7+acCy0XsGXgLbY/+1vBWuBJYFiA3M1RL7smJYPEimf3JpWlobNah5R0g6fMXgd 48tF/IcGqni2DmIzKmwETjsjpfYZRYRLV+CNEl/gX/c1gEKs1YUnIjmh5n/CfqpIq1uo 0luw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tFss6HjU5OT5iez/r0jH9iiXQfAzQrkJMyX/31mBGkg=; b=R5W7GXNnXpS5j8tHrEwTal8vl/n1/Zw7/FkFyaNkemawK+jvz/lKACXDki8LAGQOHP cmj0OJNsDgHjWv5BPjScuQTwlb/xXOUiggmnBONmUuwkvgzq/PHqEsNYU/aCfKKtcKbg nfqvRTZNwZRbo+UdEsqQv4cbvLLp5Tb9Cu6DHxuTSAbTskv82UgqRXpvcMIpFe3pSleh Zdemve9sYJQDjzrWdCR8l44QfihAOGgzKG5GdApOM1BxS9dixwWarX3GR5EJlPtG/P1T ktRPyqQ6LQ8i6njLvlY8ATIvYl8wug/3R3z32kwpZnZMKR++xgrlMYVzG0BnYVrBybJv FDfg== X-Gm-Message-State: AHYfb5ihaKJP+GbP7smzpN/Vg2v+2sUXMTWuHb9IZXUl2aylkkQGBisj NnaBnQRnN+wF48DyDgY= X-Received: by 10.99.2.197 with SMTP id 188mr13951964pgc.307.1502414543287; Thu, 10 Aug 2017 18:22:23 -0700 (PDT) Received: from [172.16.1.28] (c-73-232-201-213.hsd1.tx.comcast.net. [73.232.201.213]) by smtp.gmail.com with ESMTPSA id h20sm14705137pfk.175.2017.08.10.18.22.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 18:22:22 -0700 (PDT) Subject: [Bug 221405] Re: Infrequent boot failure with 11.1 From: Rajil Saraswat To: freebsd-stable@freebsd.org References: Message-ID: Date: Thu, 10 Aug 2017 20:22:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 01:22:24 -0000 Bug registered at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221405 On 08/09/2017 08:58 PM, Rajil Saraswat wrote: > Hello, > > I have a Supermicro X10Dri-T motherboard which refuses to boot 50% of > the time. It hangs with the message > > > DMAR: Found table at 0x7995ccb0 > x2APIC should be disabled by DMAR table but already enabled by BIOS; > enabling. > Event timer "LAPIC" quality 600 > ACPI APIC Table: > Package ID shift: 5 > L3 cache ID shift: 5 > L2 cache ID shift: 1 > L1 cache ID shift: 1 > Core ID shift: 1 > > I have tried setting X2APIC on and off in the BIOS but it hasnt helped. > I also custom compiled the kernel without the option EARLY_AP_STARTUP. > > The full log is at https://pastebin.com/FUdUKaR2 > > Anybody has a idea what could be the issue? > > > Thanks > From owner-freebsd-stable@freebsd.org Fri Aug 11 03:40:10 2017 Return-Path: Delivered-To: freebsd-stable@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 AF7A2D7F24B for ; Fri, 11 Aug 2017 03:40: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 9CDC1826FA for ; Fri, 11 Aug 2017 03:40:10 +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 v7B3e9dA044479 for ; Fri, 11 Aug 2017 03:40:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Fri, 11 Aug 2017 03:40:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kbowling@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 03:40:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #15 from Kevin Bowling --- Our cxgbe issue was not related and has been fixed by the vendor. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Aug 11 06:28:30 2017 Return-Path: Delivered-To: freebsd-stable@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 607A9DC563C; Fri, 11 Aug 2017 06:28:30 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB5953538; Fri, 11 Aug 2017 06:28:29 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (net206-94.perm.ertelecom.ru [46.146.206.94] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id v7B6SMEH008220 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Aug 2017 11:28:23 +0500 (YEKT) (envelope-from emz@norma.perm.ru) To: freebsd-fs@freebsd.org Cc: freebsd-stable From: "Eugene M. Zheganin" Subject: zfs listing and CPU Message-ID: Date: Fri, 11 Aug 2017 11:28:21 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [1.50 / 25.00] RBL_SPAMHAUS_PBL(2.00)[94.206.146.46.zen.spamhaus.org : 127.0.0.10] HFILTER_HOSTNAME_UNKNOWN(2.50)[] BAYES_HAM(-3.00)[99.99%] DMARC_NA(0.00)[norma.perm.ru] MIME_GOOD(-0.10)[text/plain] R_DKIM_NA(0.00)[] R_SPF_SOFTFAIL(0.00)[~all] MID_RHS_MATCH_FROM(0.00)[] RECEIVED_SPAMHAUS(0.00)[94.206.146.46.zen.spamhaus.org] TO_DN_SOME(0.00)[] RCPT_COUNT_2(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_HAS_DN(0.00)[] FROM_EQ_ENVFROM(0.00)[] RCVD_COUNT_1(0.00)[] ONCE_RECEIVED(0.10)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.93 X-Rspamd-Queue-ID: v7B6SMEH008220 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 06:28:30 -0000 Hi, Why does the zfs listing eat so much of the CPU ? last pid: 47151; load averages: 3.97, 6.35, 6.13 up 1+23:21:18 09:15:13 146 processes: 3 running, 142 sleeping, 1 waiting CPU: 0.0% user, 0.0% nice, 30.5% system, 0.3% interrupt, 69.2% idle Mem: 44M Active, 360M Inact, 37G Wired, 25G Free ARC: 32G Total, 14G MFU, 17G MRU, 312M Anon, 803M Header, 523M Other Swap: 32G Total, 185M Used, 32G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 32 155 ki31 0K 512K CPU0 0 1104.1 2666.23% idle 0 root 9880 -16 - 0K 154M swapin 11 314.0H 281.29% kernel 13 root 3 -8 - 0K 48K gread 0 20.9H 28.71% geom 47114 root 1 20 0 40432K 3840K db->db 4 0:05 26.84% zfs 47099 root 1 20 0 40432K 3840K zio->i 17 0:05 26.83% zfs 47106 root 1 20 0 40432K 3840K db->db 21 0:05 26.81% zfs 47150 root 1 20 0 40432K 3428K db->db 13 0:03 26.31% zfs 47141 root 1 20 0 40432K 3428K zio->i 28 0:03 26.31% zfs 47135 root 1 20 0 40432K 3312K g_wait 9 0:03 25.51% zfs 4 root 7 -16 - 0K 112K - 20 975:01 19.73% cam 5 root 2494 -8 - 0K 39952K arc_re 18 20.2H 18.58% zfskern 12 root 65 -60 - 0K 1040K WAIT 0 17.8H 15.64% intr 22 root 2 -16 - 0K 32K psleep 3 66:34 7.31% pagedaemon 590 root 10 -16 - 0K 160K - 21 177:02 2.96% ctl [...] This is from winter 2017 11-STABLE (r310734), one of the 'zfs'es is cloning, and all the others are 'zfs list -t all'. I have like 25 gigs of free RAM, do I have any chance of speeding this up using may be some caching or some sysctl tuning ? We are using a simple ZFS web API that may issue concurrent or sequential listing requests, so as you can see they sometimes do stack. Thanks. Eugene. From owner-freebsd-stable@freebsd.org Fri Aug 11 09:32:14 2017 Return-Path: Delivered-To: freebsd-stable@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 8CEB1DB67AD; Fri, 11 Aug 2017 09:32:14 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 16291698C7; Fri, 11 Aug 2017 09:32:14 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wr0-x244.google.com with SMTP id o33so2161158wrb.1; Fri, 11 Aug 2017 02:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xq6eKh+UadLUfC8tbRjdbkqknNjX2n3oRIVt2Bz3hMU=; b=fn/dXvyAFiacT2JBk/+WVIChb3SEom4axS1J3cbWHTLwaxbrA5m+f8W3yz+HdRfSAj 1icIPKeoRg3MG4q0abZl7Vpw96QyKl1/qH+WRTyHLHINOS2z753pt7nCoa5UtBp2EDio OJYsTUJ4VEvVzIDtYtFX/g3ZLP9BArHNJVvu5Cr5sziA3vAfOZp0hvwUn00+EZI1kHUn /MWPKVlgFKItjdfIt6m7ZylEwpbpjgnLz17XSruty0KepJndd4/Ol+sznXoJ2s+F/Ze+ /Sm4zywrzRnAgWPaj9jXJg7I7ZtHPWCXc8NwOTKjM0aNYfMdwC5DjTBcB6f3rNbwVF5L LbrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xq6eKh+UadLUfC8tbRjdbkqknNjX2n3oRIVt2Bz3hMU=; b=fAB/TgCJ04lzP96YUZO5TT1k3c0VwfQjZpb+3OSPCdEkNzhnJA07i8P9Y3ZSIRnCVM IX3W1fC0cDozY7wXu+Kikl0L/yTnW1p9ygY0//kAFqrGcfNUjR4okhW7OuCJnTzLCoj5 fzh/lkMUNaQx8lCae9DxJdHRMybMMqbAsr00mfTvN587YoWZInU3ixuetOrg37ziHBdW CGiN9RkKy+cS103OCnexCgsI+dZmcaVSSmFSbILtMdYL7Dk+6ESiPH1jRAQC0rmz6Zq+ By/sXB8Rng1bmaNeDjqKSQeMkT/mRDZoTSF60nhPa0DcpmPsqM0j/al8Sr0VdWyXrCSJ PL0Q== X-Gm-Message-State: AHYfb5jPBzsrcMQEnsn/U9TJ11/BXhbfittAo7WeclTgoQ+2WZuEFHmr rVw9AZcDLP1UAhoOfJ1CfA== X-Received: by 10.223.146.65 with SMTP id 59mr9900405wrj.152.1502443932415; Fri, 11 Aug 2017 02:32:12 -0700 (PDT) Received: from ben.home (LFbn-1-6951-179.w90-116.abo.wanadoo.fr. [90.116.132.179]) by smtp.gmail.com with ESMTPSA id p192sm470663wme.12.2017.08.11.02.32.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Aug 2017 02:32:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???) From: Ben RUBSON In-Reply-To: <0a5787c5-8a53-ab09-971a-dc1cd5f3aca0@freebsd.org> Date: Fri, 11 Aug 2017 11:32:10 +0200 Cc: Hans Petter Selasky , FreeBSD Net , hiren , Slawa Olhovchenkov , FreeBSD Stable Content-Transfer-Encoding: 7bit Message-Id: References: <4DF74CB8-23D2-4CCF-B699-5B86DAEA65E5@gmail.com> <40602CEA-D417-4E5B-8C68-916958D49A0B@gmail.com> <9c306f10-7c05-d28d-e551-a930603aaafa@selasky.org> <896dd782-cb2c-0259-65d1-b00daae452de@FreeBSD.org> <0DB9F6FF-8BC9-48F5-B359-AC1905B9EB06@gmail.com> <7f14c95d-1ef8-bf82-c469-e6566c3aba66@selasky.org> <76A5EE7E-1D2E-46B4-86F1-F219C3DCE6EA@gmail.com> <4C91C6E5-0725-42E7-9813-1F3ACF3DDD6E@gmail.com> <5840c25e-7472-3276-6df9-1ed4183078ad@selasky.org> <2ADA8C57-2C2D-4F97-9F0B-82D53EDDC649@gmail.com> <061cdf72-6285-8239-5380-58d9d19a1ef7@selasky.org> <92BEE83D-498F-47D5-A53C-39DCDC00A0FD@gmail.com> <5d8960d8-e1ff-8719-320f-d3ae84054714@selasky.org> <6B4A35F7-5694-4945-9575-19ADB678F9FA@gmail.com> <297a784a-3d80-b1a6-652e-a78621fe5a8b@selasky.org> <3ECCFBF1-18D9-4E33-8F39-0C366C3BB8B4@gmail.com> <0a5787c5-8a53-ab09-971a-dc1cd5f3aca0@freebsd.org> To: Julien Charbon X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 09:32:14 -0000 > On 08 Aug 2017, at 13:33, Julien Charbon wrote: > > Hi, > > On 8/8/17 10:31 AM, Hans Petter Selasky wrote: >> >> >> Suggested fix attached. > > I agree we your conclusion. Just for the record, more precisely this > regression seems to have been introduced with: > (...) > Thus good catch, and your patch looks good. I am going to just verify > the other in_pcbrele_wlocked() calls in TCP stack. Julien, do you plan to make this fix reach 11.0-p12 ? Many thx ! Ben From owner-freebsd-stable@freebsd.org Sat Aug 12 12:03:25 2017 Return-Path: Delivered-To: freebsd-stable@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 B5FBCDD1F33 for ; Sat, 12 Aug 2017 12:03: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 9FDC083730 for ; Sat, 12 Aug 2017 12:03: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 v7CC3Oma049942 for ; Sat, 12 Aug 2017 12:03:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Sat, 12 Aug 2017 12:03:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: muxx.dev@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: mjg@FreeBSD.org X-Bugzilla-Flags: mfc-stable10+ mfc-stable11+ X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 12:03:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 muxx.dev@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |muxx.dev@gmail.com --- Comment #54 from muxx.dev@gmail.com --- I can confirm the same crash on FreeBSD 11.0-RELEASE-p1 (GENERIC) on the following hardware: Aug 12 11:57:04 gw kernel: CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.05-MHz K8-class CPU) Aug 12 11:57:04 gw kernel: Origin=3D"GenuineIntel" Id=3D0x30678 Family=3D= 0x6=20 Model=3D0x37 Stepping=3D8 Aug 12 11:57:04 gw kernel: Features=3D0xbfebfbff Aug 12 11:57:04 gw kernel: Features2=3D0x41d8e3bf Aug 12 11:57:04 gw kernel: AMD Features=3D0x28100800 Aug 12 11:57:04 gw kernel: AMD Features2=3D0x101 Aug 12 11:57:04 gw kernel: Structured Extended Features=3D0x2282 Aug 12 11:57:04 gw kernel: VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID Aug 12 11:57:04 gw kernel: TSC: P-state invariant, performance statistics Aug 12 11:57:04 gw kernel: real memory =3D 8589934592 (8192 MB) Aug 12 11:57:04 gw kernel: avail memory =3D 8137785344 (7760 MB) Aug 12 11:57:04 gw kernel: Event timer "LAPIC" quality 600 Aug 12 11:57:04 gw kernel: ACPI APIC Table: Aug 12 11:57:04 gw kernel: WARNING: L1 data cache covers less APIC IDs than= a core Aug 12 11:57:04 gw kernel: 0 < 1 Aug 12 11:57:04 gw kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 C= PUs Aug 12 11:57:04 gw kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Aug 12 11:57:04 gw kernel: random: unblocking device. Aug 12 11:57:04 gw kernel: ACPI BIOS Warning (bug): 32/64X length mismatch = in FADT/Gpe0Block: 128/32 (20160527/tbfadt-650) Aug 12 11:57:04 gw kernel: WARNING: Bogus Interrupt Polarity. Assume CONFOR= MS more information from /var/log/messages and kgdb: Aug 12 11:57:04 gw kernel: Fatal trap 12: page fault while in kernel mode Aug 12 11:57:04 gw kernel: cpuid =3D 1; apic id =3D 02 Aug 12 11:57:04 gw kernel: fault virtual address =3D 0x30 Aug 12 11:57:04 gw kernel: fault code =3D supervisor read data, p= age not present Aug 12 11:57:04 gw kernel: instruction pointer =3D 0x20:0xffffffff80b3a89c Aug 12 11:57:04 gw kernel: stack pointer =3D 0x28:0xfffffe0232609440 Aug 12 11:57:04 gw kernel: frame pointer =3D 0x28:0xfffffe0232609470 Aug 12 11:57:04 gw kernel: code segment =3D base 0x0, limit 0xfffff= , type 0x1b Aug 12 11:57:04 gw kernel: =3D DPL 0, pres 1, long 1, def32 0, gran 1 Aug 12 11:57:04 gw kernel: processor eflags =3D resume, IOPL =3D 0 Aug 12 11:57:04 gw kernel: current process =3D 18204 (telegraf) Aug 12 11:57:04 gw kernel: trap number =3D 12 Aug 12 11:57:04 gw kernel: panic: page fault Aug 12 11:57:04 gw kernel: cpuid =3D 1 Aug 12 11:57:04 gw kernel: KDB: stack backtrace: Aug 12 11:57:04 gw kernel: #0 0xffffffff80b24077 at kdb_backtrace+0x67 Aug 12 11:57:04 gw kernel: #1 0xffffffff80ad93e2 at vpanic+0x182 Aug 12 11:57:04 gw kernel: #2 0xffffffff80ad9253 at panic+0x43 Aug 12 11:57:04 gw kernel: #3 0xffffffff80fa0d31 at trap_fatal+0x351 Aug 12 11:57:04 gw kernel: #4 0xffffffff80fa0f23 at trap_pfault+0x1e3 Aug 12 11:57:04 gw kernel: #5 0xffffffff80fa04cc at trap+0x26c Aug 12 11:57:04 gw kernel: #6 0xffffffff80f84141 at calltrap+0x8 Aug 12 11:57:04 gw kernel: #7 0xffffffff80ad48cf at __rw_wunlock_hard+0x8f Aug 12 11:57:04 gw kernel: #8 0xffffffff80e1a75c at vm_map_delete+0x3dc Aug 12 11:57:04 gw kernel: #9 0xffffffff80e1c5f7 at vm_map_remove+0x47 Aug 12 11:57:04 gw kernel: #10 0xffffffff80a86c7f at exec_new_vmspace+0x22f Aug 12 11:57:04 gw kernel: #11 0xffffffff80a5bfe8 at exec_elf64_imgact+0xa58 Aug 12 11:57:04 gw kernel: #12 0xffffffff80a84d4d at kern_execve+0x7dd Aug 12 11:57:04 gw kernel: #13 0xffffffff80a841dc at sys_execve+0x4c Aug 12 11:57:04 gw kernel: #14 0xffffffff80fa168e at amd64_syscall+0x4ce Aug 12 11:57:04 gw kernel: #15 0xffffffff80f8442b at Xfast_syscall+0xfb ... (kgdb) list *0xffffffff80b3a89c 0xffffffff80b3a89c is in turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837). 832 833 /* 834 * Transfer the blocked list to the pending list. 835 */ 836 mtx_lock_spin(&td_contested_lock); 837 TAILQ_CONCAT(&ts->ts_pending, &ts->ts_blocked[queue], td_lockq); 838 mtx_unlock_spin(&td_contested_lock); 839 840 /* 841 * Give a turnstile to each thread. The last thread gets Current language: auto; currently minimal (kgdb) backtrace #0 doadump (textdump=3D) at pcpu.h:221 #1 0xffffffff80ad8e69 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff80ad941b in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80ad9253 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff80fa0d31 in trap_fatal (frame=3D0xfffffe0232609390, eva=3D48)= at /usr/src/sys/amd64/amd64/trap.c:841 #5 0xffffffff80fa0f23 in trap_pfault (frame=3D0xfffffe0232609390, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:691 #6 0xffffffff80fa04cc in trap (frame=3D0xfffffe0232609390) at /usr/src/sys/amd64/amd64/trap.c:442 #7 0xffffffff80f84141 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #8 0xffffffff80b3a89c in turnstile_broadcast (ts=3D0x0, queue=3D1) at /usr/src/sys/kern/subr_turnstile.c:837 #9 0xffffffff80ad48cf in __rw_wunlock_hard (c=3D0xfffff800437de858, tid=3D= , file=3D, line=3D)= at /usr/src/sys/kern/kern_rwlock.c:1027 #10 0xffffffff80e1a75c in vm_map_delete (map=3D, start=3D, end=3D) at /usr/src/sys/vm/vm_map.c:2960 #11 0xffffffff80e1c5f7 in vm_map_remove (map=3D0xfffff80032b91000, start=3D140737488355328, end=3D1) at /usr/src/sys/vm/vm_map.c:3077 #12 0xffffffff80a86c7f in exec_new_vmspace (imgp=3D0xfffffe0232609860, sv=3D0xffffffff81a02720) at /usr/src/sys/kern/kern_exec.c:1095 #13 0xffffffff80a5bfe8 in exec_elf64_imgact (imgp=3D) = at /usr/src/sys/kern/imgact_elf.c:896 #14 0xffffffff80a84d4d in kern_execve (td=3D, args=3D<= value optimized out>, mac_p=3D0x0) at /usr/src/sys/kern/kern_exec.c:602 #15 0xffffffff80a841dc in sys_execve (td=3D0xfffff801a5da3a00, uap=3D0xfffffe0232609b80) at /usr/src/sys/kern/kern_exec.c:218 #16 0xffffffff80fa168e in amd64_syscall (td=3D, traced= =3D0) at subr_syscall.c:135 #17 0xffffffff80f8442b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #18 0x000000000047da1f in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sat Aug 12 15:50:36 2017 Return-Path: Delivered-To: freebsd-stable@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 AF5B9DDEA30 for ; Sat, 12 Aug 2017 15:50:36 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 6FB4965B88 for ; Sat, 12 Aug 2017 15:50:36 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qk0-x241.google.com with SMTP id x77so6003770qka.4 for ; Sat, 12 Aug 2017 08:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MjHsvgiLSvpfuasu3J/hQLYf8RWllt/+/3QQNmkY7qM=; b=saBFQ9HrIFzogDEf3rH7kTR4rNWBvVkUgEYn032Uyu72w0egPUh0YN/CexTnhg9iHp 38Uj80hTjZFbryc5H9sdty4Ebnu/VAvXkGtAwmbMFkDnM8a+MrZ7Vz+utFyE2WwpkiYr vp8dwFBi8KGH8zuGNznD5RzCBXizVTdVtMw62+Z4xykj3UPNpZtVMm71h7Eg9L8sCUdG ehGkftp5zauJDEq6Gb9tudzzd04JiyYslDaEQI/qbNCGe/kCFZUko/7Mxl4S+mFU/ixQ JfvhCHPsrP08rVvMrC66uzcEPDFtNAnNL+oKAz6Xm3L1FsftIX5VB9UOmto+2wZiqQ+O qbEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MjHsvgiLSvpfuasu3J/hQLYf8RWllt/+/3QQNmkY7qM=; b=XMdyjOgA4dftJGB02GjqV++apUr/Gz+J0MVv+F5IUzrW3+xbJ6Ha6djIJttlkUP8Ki EWZvA8TbgIHz9KPQJEM5kXnNQx/oiBS9D5fufUY7vjHHIqC88SHNDlgK3SIzMam69flB walX4AYgjDVK6b6PMzXWMP7ifKNpaB5pkMSy6Ray9/BQ7TDZF4WD+AANNCjBwy+vtv+S ArRNujZA1+bO4J796P+b9oJVEDLTxGJcHpqi7okzYd0ljS5+tAgVOVhKnWPhpvbdJs91 NJk0YXvYT3v1w0awDr1ToUSUho0O/S7EyM59VHQU9qgRGq8Cuh4ObppB3DxcHqWznCoD Z/IQ== X-Gm-Message-State: AHYfb5jb5Q0aFhhjfVURzKOOJDAssZIZKHUT2ITVp/AeCzvzPYfBydo+ 4kbpdb9tFSKVkD1u1yUENw== X-Received: by 10.55.20.25 with SMTP id e25mr24944550qkh.75.1502553035460; Sat, 12 Aug 2017 08:50:35 -0700 (PDT) Received: from [192.168.2.65] (pool-74-109-188-83.albyny.fios.verizon.net. [74.109.188.83]) by smtp.gmail.com with ESMTPSA id r23sm2399878qtc.50.2017.08.12.08.50.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 12 Aug 2017 08:50:33 -0700 (PDT) Subject: Re: zfs listing and CPU Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Paul Kraus In-Reply-To: Date: Sat, 12 Aug 2017 11:50:34 -0400 Cc: freebsd-fs@freebsd.org, freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Eugene M. Zheganin" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 15:50:36 -0000 > On Aug 11, 2017, at 2:28 AM, Eugene M. Zheganin = wrote: >=20 > Why does the zfs listing eat so much of the CPU ? > 47114 root 1 20 0 40432K 3840K db->db 4 0:05 26.84% = zfs > 47099 root 1 20 0 40432K 3840K zio->i 17 0:05 26.83% = zfs > 47106 root 1 20 0 40432K 3840K db->db 21 0:05 26.81% = zfs > 47150 root 1 20 0 40432K 3428K db->db 13 0:03 26.31% = zfs > 47141 root 1 20 0 40432K 3428K zio->i 28 0:03 26.31% = zfs > 47135 root 1 20 0 40432K 3312K g_wait 9 0:03 25.51% = zfs > This is from winter 2017 11-STABLE (r310734), one of the 'zfs'es is = cloning, and all the others are 'zfs list -t all'. I have like 25 gigs = of free RAM, do I have any chance of speeding this up using may be some = caching or some sysctl tuning ? We are using a simple ZFS web API that = may issue concurrent or sequential listing requests, so as you can see = they sometimes do stack. How many snapshots do you have ? I have only seen this behavior with = LOTS (not hundreds, but thousands) of snapshots. What does your `iostat -x 1` look like ? I expect that you are probably = saturating your drives with random I/O. From owner-freebsd-stable@freebsd.org Sat Aug 12 17:12:16 2017 Return-Path: Delivered-To: freebsd-stable@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 2FEDDD945A5 for ; Sat, 12 Aug 2017 17:12:16 +0000 (UTC) (envelope-from bryce@bryce.net) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 C75D7691BA for ; Sat, 12 Aug 2017 17:12:15 +0000 (UTC) (envelope-from bryce@bryce.net) Received: by mail-wm0-x231.google.com with SMTP id f15so13834118wmg.1 for ; Sat, 12 Aug 2017 10:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bryce.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=8h1mnNMNa0BhDfj/iU/55vtqSRvoj2iYKJiIXMixIiI=; b=Ay8MAhjBoGTBNfXJ1bubBzduF62NDA7eh1PW5c3b0vsam28b37g9/yQT7XFFaAajxt KgS3ox+zHqr8o/zfk7TFIWwIt740ILWtgrbTgHjNAPDq/eGS6fBjk01dEQR2XzqfBHWV O+zumUAwed/7xk9EC2uqdbor03wN6z9Y03+a4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8h1mnNMNa0BhDfj/iU/55vtqSRvoj2iYKJiIXMixIiI=; b=GHzqJAjsS56GQXT7CKXndcsltbcI2nFQE9a8NZ9UiNkUAS4A/Ftwwh1i1B/RJhq3r9 SRSre7VTrIO/XkbDOxhdJJXiRVcXef8OHsd4bgAwRnb5rXNjZ4VSw0Hx6GwYGTIw00AQ CLRPjqSoLWX9eUYQi5vrrPtzo1oU97D85wVHg8VVJ3hcc8OTi5xjhsVaEBXnrlsrwTtk rjh8gZgJXDOxeNmjFoORaXcBYL80X7jJ5/WTGX97wfp00lW7ImMqf/xIQ1yuf1/N3iZg hwqYIbq72LDAWUSdld8Gb6Wya6ktd8V8EbNUUCosfdbH9OzwdllEDj16W5t39YN8Vfgo Szlg== X-Gm-Message-State: AHYfb5jcna9BOwKvs+7jfNEa6bKXVr8wBXFOTsV0JtT1UuJURu+S4Mxu upwTYhih1J+1eljTJxlW6rSbFyzR64eELik= X-Received: by 10.28.159.133 with SMTP id i127mr1168394wme.172.1502557933850; Sat, 12 Aug 2017 10:12:13 -0700 (PDT) MIME-Version: 1.0 From: Bryce Edwards Date: Sat, 12 Aug 2017 17:12:02 +0000 Message-ID: Subject: Error in /usr/src/release/release.sh To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 17:12:16 -0000 When trying to build a set of RELENG/11.1 release files, I'm getting the following error (tail end of output) in the release.sh run: -------------------------------------------------------------- >>> Kernel build for ALLWINNER completed on Fri Aug 11 22:24:02 UTC 2017 -------------------------------------------------------------- make -C /usr/src/release obj make -C /usr/src/release ftp `ftp' is up to date. make -C /usr/src/release release-done touch release true mkdir -p /R cp -a ftp /R/ cd /R && sha512 FreeBSD-11.1-RELEASE-p1-arm-armv6* > /R/CHECKSUM.SHA512 sha512: FreeBSD-11.1-RELEASE-p1-arm-armv6*: No such file or directory *** Error code 1 Stop. make: stopped in /usr/src/release Here's the contents of my release.conf: CHROOTDIR="/usr/local/build/chroot" SRCBRANCH="base/releng/11.1" TARGET="arm" TARGET_ARCH="armv6" KERNEL="ALLWINNER" NOSRC=yes NODOC=yes NOPORTS=yes And the contents of the R/ directory after the run: bryce@tahiti /usr/local/build $find chroot/R/ chroot/R/ chroot/R/ftp chroot/R/ftp/kernel-dbg.txz chroot/R/ftp/tests.txz chroot/R/ftp/doc.txz chroot/R/ftp/base.txz chroot/R/ftp/MANIFEST chroot/R/ftp/kernel.txz chroot/R/ftp/base-dbg.txz chroot/R/CHECKSUM.SHA512 Thanks in advance for any insight. I'm not having luck with make distributeworld in /usr/src either - The use of DESTDIR & DISTDIR in the Makefiles seem to alternate between absolute & relative use of those and it isn't cooperating with me (which is why I was trying to just go with /usr/src/release/release.sh) Bryce From owner-freebsd-stable@freebsd.org Sat Aug 12 17:13:39 2017 Return-Path: Delivered-To: freebsd-stable@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 E8E0AD94799 for ; Sat, 12 Aug 2017 17:13:39 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50C5C69344 for ; Sat, 12 Aug 2017 17:13:39 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id v7CHD5D8054747 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 12 Aug 2017 19:13:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id v7CHD53M054746 for freebsd-stable@FreeBSD.ORG; Sat, 12 Aug 2017 19:13:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id v7CGacDM010032 for ; Sat, 12 Aug 2017 18:36:38 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id v7CGY3dv009717 for ; Sat, 12 Aug 2017 18:34:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id v7CGY3VY009709 for freebsd-stable@FreeBSD.ORG; Sat, 12 Aug 2017 18:34:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: errors from port make (analyzed: bug in pkg) Date: Sat, 12 Aug 2017 18:25:24 +0200 Organization: even some more stinky socks Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: oper.dinoex.de; logging-data="8440"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 X-Mozilla-News-Host: news://localhost:119 Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Sat, 12 Aug 2017 19:13:06 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 17:13:40 -0000 For a long time already, I get these strange messages whenever building a port: pkg: Bad argument on pkg_set 2143284626 Today I looked into it, and found it is easily reproducible: # pkg audit whatever pkg: Bad argument on pkg_set 2143284618 0 problem(s) in the installed packages found. # Looking closer, I found this offending call in src/audit.c:exec_audit(): pkg_set(pkg, PKG_UNIQUEID, name); This goes into libpkg/pkg.c:pkg_vset(), but there nobody is interested in an UNIQUEID parameter, so that the parameter does not get fetched from the va_list. It does not do any harm, but it is ugly. Please fix. From owner-freebsd-stable@freebsd.org Sat Aug 12 20:38:05 2017 Return-Path: Delivered-To: freebsd-stable@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 120C7DC833E for ; Sat, 12 Aug 2017 20:38:05 +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 F410370844 for ; Sat, 12 Aug 2017 20:38:04 +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 v7CKc4dk086605 for ; Sat, 12 Aug 2017 20:38:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Sat, 12 Aug 2017 20:38:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: mjg@FreeBSD.org X-Bugzilla-Flags: mfc-stable10+ mfc-stable11+ X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 20:38:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markmi@dsl-only.net --- Comment #55 from Mark Millard --- (In reply to muxx.dev from comment #54)\ Looks to me like ts=3D=3D0x0 was the starting value given to turnstile_broadcast in each backtrace listed in this buzilla bug (213903), for example: (kgdb) list *0xffffffff80b3a89c 0xffffffff80b3a89c is in turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837). 832 833 /* 834 * Transfer the blocked list to the pending list. 835 */ 836 mtx_lock_spin(&td_contested_lock); 837 TAILQ_CONCAT(&ts->ts_pending, &ts->ts_blocked[queue], td_lockq); 838 mtx_unlock_spin(&td_contested_lock); 839 840 /* 841 * Give a turnstile to each thread. The last thread gets Current language: auto; currently minimal (kgdb) backtrace . . . #8 0xffffffff80b3a89c in turnstile_broadcast (ts=3D0x0, queue=3D1) at /usr/src/sys/kern/subr_turnstile.c:837 #9 0xffffffff80ad48cf in __rw_wunlock_hard (c=3D0xfffff800437de858, tid=3D= , file=3D, line=3D)= at /usr/src/sys/kern/kern_rwlock.c:1027 . . . Note that ts=3D=3D0x0 would be a problem for: TAILQ_CONCAT(&ts->ts_pending, &ts->ts_blocked[queue], td_lockq); So I wonder if __rw_wunlock_hard is providing a bad ts value. If yes: the problem then occurs before the turnstile_broadcast call is made. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sat Aug 12 23:08:47 2017 Return-Path: Delivered-To: freebsd-stable@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 77E6EDCFBCA for ; Sat, 12 Aug 2017 23:08:47 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5C45F75659 for ; Sat, 12 Aug 2017 23:08:47 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5BA23DCFBC9; Sat, 12 Aug 2017 23:08:47 +0000 (UTC) Delivered-To: stable@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 5B395DCFBC8 for ; Sat, 12 Aug 2017 23:08:47 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 244E875657 for ; Sat, 12 Aug 2017 23:08:47 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=Aa3zJDfG c=1 sm=1 tr=0 a=lGUdY1O6J9NpztYPi32J9g==:117 a=lGUdY1O6J9NpztYPi32J9g==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=kNquPxYBJoqLaxc4lWcA:9 a=QEXdDO2ut3YA:10 a=iLLe7rO2xMddCKsRhdYA:9 a=gmhEUAAHJ45tzAm8:21 a=_W_S_7VecoQA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YW5hdEByY24uY29t Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=mi+thun@aldan.algebra.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=mi+thun@aldan.algebra.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=anat; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 108.53.87.28 is neither permitted nor denied by domain of aldan.algebra.com) Received: from [108.53.87.28] ([108.53.87.28:65211] helo=aldan.narawntapu) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPSA (cipher=DHE-RSA-AES128-SHA) id B1/B0-53214-67A8F895; Sat, 12 Aug 2017 19:08:38 -0400 To: stable@freebsd.org, tuexen@FreeBSD.org, gnn@FreeBSD.org, glebius@FreeBSD.org From: "Mikhail T." Subject: error compiling sys/netinet/tcp_syncache.c on i386 Message-ID: Date: Sat, 12 Aug 2017 19:08:37 -0400 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 23:08:47 -0000 Just my luck -- deciding to update to the latest 10.x today... sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from 'long long' to 'time_t' (aka 'int') changes value from -9223372036854775808 to 0 [-Werror,-Wconstant-conversion] V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; ~ ^~~~~~~~~ ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' #define INT64_MIN (-0x7fffffffffffffffLL-1) Yours, -mi From owner-freebsd-stable@freebsd.org Sat Aug 12 23:16:16 2017 Return-Path: Delivered-To: freebsd-stable@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 F24D2DD0459 for ; Sat, 12 Aug 2017 23:16:16 +0000 (UTC) (envelope-from tuexen@freebsd.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 D89CB75B68 for ; Sat, 12 Aug 2017 23:16:16 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D809ADD0456; Sat, 12 Aug 2017 23:16:16 +0000 (UTC) Delivered-To: stable@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 D7BD6DD0454 for ; Sat, 12 Aug 2017 23:16:16 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0BAA75B65; Sat, 12 Aug 2017 23:16:16 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.204] (p57BB572F.dip0.t-ipconnect.de [87.187.87.47]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 10052721E281A; Sun, 13 Aug 2017 01:16:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: error compiling sys/netinet/tcp_syncache.c on i386 From: Michael Tuexen In-Reply-To: Date: Sun, 13 Aug 2017 01:16:02 +0200 Cc: stable@freebsd.org, gnn@FreeBSD.org, glebius@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <0479D894-AF45-4000-8CA4-0EF338959CF4@freebsd.org> References: To: "Mikhail T." X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 23:16:17 -0000 > On 13. Aug 2017, at 01:08, Mikhail T. = wrote: >=20 > Just my luck -- deciding to update to the latest 10.x today... > sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from = 'long long' to 'time_t' (aka 'int') changes value from = -9223372036854775808 to 0 [-Werror,-Wconstant-conversion] > V_tcp_syncache.hashbase[i].sch_last_overflow =3D = INT64_MIN; > ~ = ^~~~~~~~~ > ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' > #define INT64_MIN (-0x7fffffffffffffffLL-1) > Yours, Right... I need to MFC also = https://svnweb.freebsd.org/base?view=3Drevision&revision=3D317244 Will do that tomorrow. Thanks for reminding me... Best regards Michael >=20 > -mi From owner-freebsd-stable@freebsd.org Sat Aug 12 23:21:46 2017 Return-Path: Delivered-To: freebsd-stable@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 9D818DD0ACB for ; Sat, 12 Aug 2017 23:21:46 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1B075E2B for ; Sat, 12 Aug 2017 23:21:46 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7E514DD0ACA; Sat, 12 Aug 2017 23:21:46 +0000 (UTC) Delivered-To: stable@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 7DEBDDD0AC9 for ; Sat, 12 Aug 2017 23:21:46 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 4501375E29 for ; Sat, 12 Aug 2017 23:21:46 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=Aa3zJDfG c=1 sm=1 tr=0 a=lGUdY1O6J9NpztYPi32J9g==:117 a=lGUdY1O6J9NpztYPi32J9g==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=6I5d2MoRAAAA:8 a=f09v-ToifBHtgSxDXZcA:9 a=QEXdDO2ut3YA:10 a=MqcSXMRtI0ejiub_qdcA:9 a=oTHBZxOi4jIsV0Ys:21 a=_W_S_7VecoQA:10 a=IjZwj45LgO3ly-622nXo:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YW5hdEByY24uY29t Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=mi+thun@aldan.algebra.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=mi+thun@aldan.algebra.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=anat; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 108.53.87.28 is neither permitted nor denied by domain of aldan.algebra.com) Received: from [108.53.87.28] ([108.53.87.28:51792] helo=aldan.narawntapu) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPSA (cipher=DHE-RSA-AES128-SHA) id 8F/41-53214-78D8F895; Sat, 12 Aug 2017 19:21:44 -0400 Subject: Re: error compiling sys/netinet/tcp_syncache.c on i386 To: Michael Tuexen Cc: stable@freebsd.org, gnn@FreeBSD.org, glebius@FreeBSD.org References: <0479D894-AF45-4000-8CA4-0EF338959CF4@freebsd.org> From: "Mikhail T." Message-ID: <6fc9aff1-7935-34c1-578a-dcc5a5e83468@aldan.algebra.com> Date: Sat, 12 Aug 2017 19:21:43 -0400 MIME-Version: 1.0 In-Reply-To: <0479D894-AF45-4000-8CA4-0EF338959CF4@freebsd.org> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 23:21:46 -0000 On 12.08.2017 19:16, Michael Tuexen wrote: >> Just my luck -- deciding to update to the latest 10.x today... >> sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from 'long long' to 'time_t' (aka 'int') changes value from -9223372036854775808 to 0 [-Werror,-Wconstant-conversion] >> V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; >> ~ ^~~~~~~~~ >> ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' >> #define INT64_MIN (-0x7fffffffffffffffLL-1) >> Yours, > Right... I need to MFC alsohttps://svnweb.freebsd.org/base?view=revision&revision=317244 > > Will do that tomorrow. > > Thanks for reminding me... You are welcome, but this means, stable is not currently buildable on i386 -- a Tier1-platform... Is not that monitored for? On the ports side of things, I'd be getting an automated build-failure notice shortly after making a change, that breaks a build... I applied the diff you linked to by hand and the kernel-build moved on, thank you! Yours, -mi -mi