From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 05:36:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28EA0106566B for ; Sun, 17 Apr 2011 05:36:49 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB998FC15 for ; Sun, 17 Apr 2011 05:36:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p3H5ae6A045530; Sun, 17 Apr 2011 15:36:41 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 17 Apr 2011 15:36:40 +1000 (EST) From: Ian Smith To: rondzierwa@comcast.net In-Reply-To: <349334508.1236453.1302976895873.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> Message-ID: <20110417150456.J35056@sola.nimnet.asn.au> References: <349334508.1236453.1302976895873.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, hrs@freebsd.org Subject: Re: natd starting after firewall rules are loaded X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 05:36:49 -0000 On Sat, 16 Apr 2011, rondzierwa@comcast.net wrote: > After the firewall rules are loaded, the rc script then loads natd, > Once the system is up, i can ipfw list and the divert command is, > in fact, not there, but by this time natd is running. If I run the rc.firewall > script interactively, it completes successfully and the divert rule > is in the list, and everyone is happy again. There are several outstanding PRs about this and related issues; copying hrs@ who grabbed these PRs a while ago. The quick fix is to add ipdivert_load="YES" to /boot/loader.conf so it's there before ipfw & natd start. You still need ipfw_enable=YES and natd_enable=YES in /etc/rc.conf > In 4.9 there used to be a rc.network script that started natd before > it loaded the firewall rules. I do not see it in 8.2 anymore, instead > it looks like rc simply runs the scripts in rc.d alphabetically, so natd > comes after ipfw. Not alphabetically but according to rcorder(8). /etc/rc.d/natd has keyword NOSTART and is now only run when /etc/rc.d/ipfw invokes it, but as you've seen, ipfw's attempt to install divert rule(s) fails for want of ipdivert.ko - which /etc/rc.d/natd does load, but too late. > I can't believe i'm the only one using ipfw and natd with 8.2, so it > seems to me that i just don't know the secret handshake that will > make it work. In 4.x you had to build ipfw into kernel; lots of changes since :) cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 06:01:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65783106566C; Sun, 17 Apr 2011 06:01:25 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0CBFD8FC0A; Sun, 17 Apr 2011 06:01:24 +0000 (UTC) Received: by iwn33 with SMTP id 33so4124900iwn.13 for ; Sat, 16 Apr 2011 23:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=mUtUBjIAaFTT1zo/Q4sikKLIAiOIyNPY79aMCLKgTAw=; b=BksIdGS6SezgPiMie4QaUmpvge9bJIcYRbNYa9OdJbui+yaPaQjSuevBkkFxHwNjZY 3C1TXWZ42FZYAf98kuCfjEmSWJBReqBhqBdDrNtmj2QerXjbwvCqRfUWoyVYApV3Hy4+ ZDu8zRf1XcNZMh2UnDNRJo06OCpMooN0fxNt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=gpUH8T7BC5HS4xXUjIuGHW03c8xoBZKmZWsLZ1ZA6t6cOPkc5/z7X3LDarDvkDjc2T ACx/HTjcNnkS3hrR95Ty2o04vgWqk0DNxu30goNyBoJ2COzctt6X0TQvaqnME2A8NWQW khubJPZjzhQaMldyAp2JIb0crhmqqZH2soD7Q= Received: by 10.42.208.67 with SMTP id gb3mr4734911icb.423.1303020084362; Sat, 16 Apr 2011 23:01:24 -0700 (PDT) Received: from DataIX.net (adsl-99-19-43-8.dsl.klmzmi.sbcglobal.net [99.19.43.8]) by mx.google.com with ESMTPS id vw9sm2164474icb.11.2011.04.16.23.01.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Apr 2011 23:01:22 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p3H61IR1021499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Apr 2011 02:01:19 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3H61H7q021498; Sun, 17 Apr 2011 02:01:17 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 17 Apr 2011 02:01:17 -0400 From: "J. Hellenthal" To: Ian Smith Message-ID: <20110417060117.GA20390@DataIX.net> References: <349334508.1236453.1302976895873.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> <20110417150456.J35056@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <20110417150456.J35056@sola.nimnet.asn.au> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-net@freebsd.org, hrs@freebsd.org, rondzierwa@comcast.net Subject: Re: natd starting after firewall rules are loaded X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 06:01:25 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 17, 2011 at 03:36:40PM +1000, Ian Smith wrote: >On Sat, 16 Apr 2011, rondzierwa@comcast.net wrote: > > > After the firewall rules are loaded, the rc script then loads natd,=20 > > Once the system is up, i can ipfw list and the divert command is,=20 > > in fact, not there, but by this time natd is running. If I run the rc.f= irewall=20 > > script interactively, it completes successfully and the divert rule=20 > > is in the list, and everyone is happy again.=20 > >There are several outstanding PRs about this and related issues; copying= =20 >hrs@ who grabbed these PRs a while ago. The quick fix is to add > >ipdivert_load=3D"YES" > >to /boot/loader.conf so it's there before ipfw & natd start. You still=20 >need ipfw_enable=3DYES and natd_enable=3DYES in /etc/rc.conf > > > In 4.9 there used to be a rc.network script that started natd before=20 > > it loaded the firewall rules. I do not see it in 8.2 anymore, instead= =20 > > it looks like rc simply runs the scripts in rc.d alphabetically, so nat= d=20 > > comes after ipfw.=20 > >Not alphabetically but according to rcorder(8). /etc/rc.d/natd has=20 >keyword NOSTART and is now only run when /etc/rc.d/ipfw invokes it, but=20 >as you've seen, ipfw's attempt to install divert rule(s) fails for want=20 >of ipdivert.ko - which /etc/rc.d/natd does load, but too late. > > > I can't believe i'm the only one using ipfw and natd with 8.2, so it=20 > > seems to me that i just don't know the secret handshake that will=20 > > make it work.=20 > >In 4.x you had to build ipfw into kernel; lots of changes since :) > >cheers, Ian Add the following to change the order of the scripts in which they run. /etc/rc.d/natd: # BEFORE: ipfw /etc/rc.d/ipfw: # AFTER: natd And that will change the order in which the scripts execute. whether this has any implications on other running daemons you will have to check but as far as the rcorder(8) goes that will put ipfw executing just after natd. rcorder /etc/rc.d/* [...] /etc/rc.d/routed /etc/rc.d/defaultroute /etc/rc.d/natd /etc/rc.d/ipfw /etc/rc.d/netoptions /etc/rc.d/NETWORKING [...] PS: For those with commit bits... $ rcorder /etc/rc.d/ipfw rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. /etc/rc.d/ipfw Dont know why because, $ grep -n ppp /etc/rc.d/* | grep PROVIDE /etc/rc.d/ppp:6:# PROVIDE: ppp There are a few other scripts in there that generate other similiar errors but this one seem sketchy to me. --=20 Regards, J. Hellenthal WWJD --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNqoIsAAoJEJBXh4mJ2FR+8HYH/0kqzhwgBubXVbsTnF2sgcq1 cn9raBjo1+RI/KyNd1H+HitfC+Di7tXGIDvXf+fkJ5eGl/NfZaya4+C93b0TMUHn SS1QSRShNraH/sWtNasZa7qvW94ePDYBZWSM3DTcY9GK/17oywBQ10OS8NDNF9aJ sTbL+Xz+vgMjBaZ2RMMuYMUTczWrbSjbIuB32v4K+THOeqeuzSzIc5ra5bgSp6Sp 2hzj7FB1ptVT0lSjEZEPmy6fLkXGW4YGrLr6vdG86FkXn7OC8s6FAmtcwU79Nyjq nM0+p7eCgM/2x/WOuk/6UzlLte/EjP5xvJGKXZHpcBZLwuirRSZA3ydDI9RhOOw= =nzsn -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 14:30:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D10E0106564A for ; Sun, 17 Apr 2011 14:30:45 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 569708FC23 for ; Sun, 17 Apr 2011 14:30:45 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6B2434AC42 for ; Sun, 17 Apr 2011 18:30:43 +0400 (MSD) Date: Sun, 17 Apr 2011 18:30:34 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1666528527.20110417183034@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: IPv6 tunnel from Hurricane Electric: very strange behavior of incoming traffic -- it works only if tcpdump is running on outer (IPv4) interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 14:30:45 -0000 Hello, Freebsd-net. I'm setting up IPv6 tunnel to Hurricane Electrict for first time. I've encountered very strange behavior of incoming traffic: everything works only if tcpdump is running on external (IPv4) interface. Here are details. I've created tunnel as usual: # ifconfig gif0 create # ifconfig gif0 tunnel 89.112.xx.xx 64.71.xx.xx # ifconfig gif0 inet6 2001:470:hhhh:hhhh::2 2001:470:hhhh:hhhh::1 prefixlen= 128 # route -n add -inet6 default 2001:470:hhhh:hhhh::2 # ifconfig gif0 up # route -n add -inet6 default 2001:470:hhhh:hhhh::2 Added "allowed" rules for icmpv6 input/output to my ipfw firewall. After that I could ping6 any "outside" IPv6 address -- not only HE one, but, for example, my IPv6-enabled host at Hetzner ISP. So far, so good. When I'm trying to ping 2001:470:hhhh:hhhh::2 from outside I didn't get any reply. Ok, my first thought is ``I've messed up firewall configuration''. I'm trying # tcpdump -ni gif0 NOTHING is coming in from outside. Complete silence. Then I try # tcpdump -ni ng0 host 64.71.xx.xx Where "ng0" is my interface with real external IP (my PPPoE connection to IPv4-only ISP). This command shows 5-7 ICMPv6 Echo requests (wrapped into IPv4, of course), and AFTER that my host starts to reply! tcpdump on ng0 shows both requests and replies (tunneled), tcpdump on gif0 shows "pure" requests and replies, "external" host (with ping6 running) sees replies too, everything works. When I stop tcpdump on ng0, it continues to work for about 4-5 minutes, and after that silence again till I run tcpdump again! What do I do wrong? Here is my interface: # ifconfig gif0 gif0: flags=3D8051 metric 0 mtu 1280 tunnel inet 89.112.xx.xx --> 64.71.xx.xx inet6 2001:470:hhhh:hhhh::2 --> 2001:470:hhhh:hhhh::1 prefixlen 128 nd6 options=3D3 options=3D1 Here is my routing: # netstat -rn -f inet6 Internet6: Destination Gateway Flags = Netif Expire default 2001:470:hhhh:hhhh::2 UGS = gif0 ::1 ::1 UH = lo0 2001:470:hhhh:hhhh::1 2001:470:hhhh:hhhh::2 UH = gif0 fe80::%lo0/64 link#8 U = lo0 fe80::1%lo0 link#8 UHS = lo0 ff01::%lo0/32 fe80::1%lo0 U = lo0 ff01::%gif0/32 2001:470:hhhh:hhhh::2 U = gif0 ff02::%lo0/32 fe80::1%lo0 U = lo0 ff02::%gif0/32 2001:470:hhhh:hhhh::2 U = gif0 And here is my ipfw IPv6-related rules: 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,1= 35,136 01000 3248938 2654059165 skipto 2000 ip from any to any in 01010 3225982 2652423541 skipto 3000 ip from any to any out 02000 ..... other internal and external interfaces 02040 23 9089 skipto 15000 ip6 from any to any via gif0 02999 0 0 deny ip from any to any 03000 ..... other internal and external interfaces 03040 26 2418 skipto 16000 ip6 from any to any via gif0 03999 0 0 deny ip from any to any ..... 15000 0 0 check-state 15010 0 0 allow ipv6-icmp from any to me keep-state 15020 0 0 allow ipv6-icmp from any to 2001:470:hhhh:hhhh::/6= 4 ip6 icmp6types 1,2,3,4,128,129 keep-state 15999 0 0 skipto 30000 ip from any to any 16000 0 0 deny ip6 from not 2001:470:hhhh:hhhh::2,2001:470:h= hhh:hhhh::/64 to any 16990 0 0 allow ipv6-icmp from any to any keep-state 16999 49 11507 allow ip6 from any to any keep-state 30000 0 0 allow tcp from any to me dst-port 22,80 setup keep= -state 30010 20 824 allow tcp from any to me dst-port 53 setup keep-st= ate 30020 26 1632 allow udp from any to me dst-port 53 keep-state 39000 18 1152 allow icmp from any to me keep-state 39999 22957 1526424 deny ip from any to any --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 15:14:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 377C6106564A; Sun, 17 Apr 2011 15:14:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id EF1B88FC16; Sun, 17 Apr 2011 15:14:05 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 3C6324AC42; Sun, 17 Apr 2011 19:14:05 +0400 (MSD) Date: Sun, 17 Apr 2011 19:13:56 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <15310141717.20110417191356@serebryakov.spb.ru> To: Lev Serebryakov In-Reply-To: <1666528527.20110417183034@serebryakov.spb.ru> References: <1666528527.20110417183034@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: IPv6 tunnel from Hurricane Electric: very strange behavior of incoming traffic -- it works only if tcpdump is running on outer (IPv4) interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:14:06 -0000 Hello, Lev. You wrote 17 =E0=EF=F0=E5=EB=FF 2011 =E3., 18:30:34: > Added "allowed" rules for icmpv6 input/output to my ipfw firewall. Ok, I need to allow tunneling protocol for external (outer) interface with "allow ip from HE-ENDPOINT to me proto ipv6". Sorry. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 15:55:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3314106566B for ; Sun, 17 Apr 2011 15:55:59 +0000 (UTC) (envelope-from rondzierwa@comcast.net) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4098FC17 for ; Sun, 17 Apr 2011 15:55:59 +0000 (UTC) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id YfoV1g0021GhbT853fvzwy; Sun, 17 Apr 2011 15:55:59 +0000 Received: from sz0128.wc.mail.comcast.net ([76.96.58.192]) by omta07.westchester.pa.mail.comcast.net with comcast id Yfvz1g00348qnZY3TfvzF4; Sun, 17 Apr 2011 15:55:59 +0000 Date: Sun, 17 Apr 2011 15:55:59 +0000 (UTC) From: rondzierwa@comcast.net To: "J. Hellenthal" Message-ID: <104526415.1263850.1303055758946.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> In-Reply-To: <311011138.1263836.1303055734510.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 X-Originating-IP: [68.50.136.212] X-Mailer: Zimbra 6.0.5_GA_2431.RHEL5_64 (ZimbraWebClient - FF3.0 (Win)/6.0.5_GA_2427.RHEL4) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, hrs@freebsd.org, Ian Smith Subject: Re: natd starting after firewall rules are loaded X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:55:59 -0000 All, thank you for your help. I went back to my old system and found that I did, in fact, build the kernel with several firewall options, including nat and divert. I added the same flags to my new 8.2 kernel and built it, and, since divert is already there, the firewall rules load the first time through. One other thing that's missing since 4.9 (and this probably needs to go to some other list) is the kernel LINT file. Unless you already know about these firewall options there is no where you can go to find them. The documentation makes some mention about them, but not all of them. I was lucky because I still had my old system lying around that I could look at, but I found these options in the first place because I looked at the LINT file and added any options that I thought were pertinent. man, i sound like my dad... back when I was your age, we had a kernel LINT file, you kids these days don't know anything... :-)) thanks again for your help, ron. ----- Original Message ----- From: "J. Hellenthal" To: "Ian Smith" Cc: rondzierwa@comcast.net, freebsd-net@freebsd.org, hrs@freebsd.org Sent: Sunday, April 17, 2011 2:01:17 AM Subject: Re: natd starting after firewall rules are loaded On Sun, Apr 17, 2011 at 03:36:40PM +1000, Ian Smith wrote: >On Sat, 16 Apr 2011, rondzierwa@comcast.net wrote: > > > After the firewall rules are loaded, the rc script then loads natd, > > Once the system is up, i can ipfw list and the divert command is, > > in fact, not there, but by this time natd is running. If I run the rc.firewall > > script interactively, it completes successfully and the divert rule > > is in the list, and everyone is happy again. > >There are several outstanding PRs about this and related issues; copying >hrs@ who grabbed these PRs a while ago. The quick fix is to add > >ipdivert_load="YES" > >to /boot/loader.conf so it's there before ipfw & natd start. You still >need ipfw_enable=YES and natd_enable=YES in /etc/rc.conf > > > In 4.9 there used to be a rc.network script that started natd before > > it loaded the firewall rules. I do not see it in 8.2 anymore, instead > > it looks like rc simply runs the scripts in rc.d alphabetically, so natd > > comes after ipfw. > >Not alphabetically but according to rcorder(8). /etc/rc.d/natd has >keyword NOSTART and is now only run when /etc/rc.d/ipfw invokes it, but >as you've seen, ipfw's attempt to install divert rule(s) fails for want >of ipdivert.ko - which /etc/rc.d/natd does load, but too late. > > > I can't believe i'm the only one using ipfw and natd with 8.2, so it > > seems to me that i just don't know the secret handshake that will > > make it work. > >In 4.x you had to build ipfw into kernel; lots of changes since :) > >cheers, Ian Add the following to change the order of the scripts in which they run. /etc/rc.d/natd: # BEFORE: ipfw /etc/rc.d/ipfw: # AFTER: natd And that will change the order in which the scripts execute. whether this has any implications on other running daemons you will have to check but as far as the rcorder(8) goes that will put ipfw executing just after natd. rcorder /etc/rc.d/* [...] /etc/rc.d/routed /etc/rc.d/defaultroute /etc/rc.d/natd /etc/rc.d/ipfw /etc/rc.d/netoptions /etc/rc.d/NETWORKING [...] PS: For those with commit bits... $ rcorder /etc/rc.d/ipfw rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. /etc/rc.d/ipfw Dont know why because, $ grep -n ppp /etc/rc.d/* | grep PROVIDE /etc/rc.d/ppp:6:# PROVIDE: ppp There are a few other scripts in there that generate other similiar errors but this one seem sketchy to me. -- Regards, J. Hellenthal WWJD From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 16:54:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B23B106564A; Sun, 17 Apr 2011 16:54:08 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id EEA788FC0C; Sun, 17 Apr 2011 16:54:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p3HGriGi080562; Mon, 18 Apr 2011 02:53:44 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 18 Apr 2011 02:53:43 +1000 (EST) From: Ian Smith To: "J. Hellenthal" In-Reply-To: <20110417060117.GA20390@DataIX.net> Message-ID: <20110418010850.Q35056@sola.nimnet.asn.au> References: <349334508.1236453.1302976895873.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> <20110417150456.J35056@sola.nimnet.asn.au> <20110417060117.GA20390@DataIX.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, hrs@freebsd.org, rondzierwa@comcast.net Subject: Re: natd starting after firewall rules are loaded X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 16:54:08 -0000 On Sun, 17 Apr 2011, J. Hellenthal wrote: > On Sun, Apr 17, 2011 at 03:36:40PM +1000, Ian Smith wrote: > >On Sat, 16 Apr 2011, rondzierwa@comcast.net wrote: > > > > > After the firewall rules are loaded, the rc script then loads natd, > > > Once the system is up, i can ipfw list and the divert command is, > > > in fact, not there, but by this time natd is running. If I run the rc.firewall > > > script interactively, it completes successfully and the divert rule > > > is in the list, and everyone is happy again. > > > >There are several outstanding PRs about this and related issues; copying > >hrs@ who grabbed these PRs a while ago. The quick fix is to add > > > >ipdivert_load="YES" > > > >to /boot/loader.conf so it's there before ipfw & natd start. You still > >need ipfw_enable=YES and natd_enable=YES in /etc/rc.conf > > > > > In 4.9 there used to be a rc.network script that started natd before > > > it loaded the firewall rules. I do not see it in 8.2 anymore, instead > > > it looks like rc simply runs the scripts in rc.d alphabetically, so natd > > > comes after ipfw. > > > >Not alphabetically but according to rcorder(8). /etc/rc.d/natd has > >keyword NOSTART and is now only run when /etc/rc.d/ipfw invokes it, but Sorry, it has 'KEYWORD: nostart nojail', so /etc/rc.d/natd is not run by rc on system (or jail) startup, enabled or not. > >as you've seen, ipfw's attempt to install divert rule(s) fails for want > >of ipdivert.ko - which /etc/rc.d/natd does load, but too late. [..] > Add the following to change the order of the scripts in which they run. > > /etc/rc.d/natd: > # BEFORE: ipfw > > /etc/rc.d/ipfw: > # AFTER: natd > > And that will change the order in which the scripts execute. whether > this has any implications on other running daemons you will have to > check but as far as the rcorder(8) goes that will put ipfw executing > just after natd. A solution for many ordering problems, but not this one. It's been an ongoing tug'o'war for years, but recent consensus starts and stops natd from /etc/rc.d/ipfw, loading ipfw rules before starting natd and other 'firewall_coscripts', only then enabling the firewall; vice versa on stopping and so, restarting. For this bug, ipfw just lacks requiring module ipdivert when natd is enabled (and firewall_nat is not enabled, but that's another issue :) > rcorder /etc/rc.d/* > [...] > /etc/rc.d/routed > /etc/rc.d/defaultroute > /etc/rc.d/natd > /etc/rc.d/ipfw > /etc/rc.d/netoptions > /etc/rc.d/NETWORKING > [...] natd won't run on startup; ipfw will still run natd after ipfw rules are loaded but still needs ipdivert.ko loaded before loading divert rules :) > PS: For those with commit bits... > $ rcorder /etc/rc.d/ipfw > rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. > /etc/rc.d/ipfw > > Dont know why because, > $ grep -n ppp /etc/rc.d/* | grep PROVIDE > /etc/rc.d/ppp:6:# PROVIDE: ppp !rcorder /etc/rc.d/ipfw /etc/rc.d/ppp rcorder: requirement `netif' in file `/etc/rc.d/ppp' has no providers. /etc/rc.d/ppp /etc/rc.d/ipfw and so on .. rcorder only considers files provided as arguments. Ron: 4.6 to 8.2 is quite a jump, maybe time to rescan the ol' Handbook? % find /sys/ -name NOTES /sys/conf/NOTES /sys/amd64/conf/NOTES /sys/i386/conf/NOTES [..] cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 17:40:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D360106564A for ; Sun, 17 Apr 2011 17:40:25 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 349E18FC08 for ; Sun, 17 Apr 2011 17:40:25 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBVxQ-000GGn-9F; Sun, 17 Apr 2011 13:40:24 -0400 Date: Sun, 17 Apr 2011 13:40:24 -0400 From: Gary Palmer To: rondzierwa@comcast.net Message-ID: <20110417174024.GA1196@in-addr.com> References: <311011138.1263836.1303055734510.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> <104526415.1263850.1303055758946.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <104526415.1263850.1303055758946.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: natd starting after firewall rules are loaded X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 17:40:25 -0000 On Sun, Apr 17, 2011 at 03:55:59PM +0000, rondzierwa@comcast.net wrote: > One other thing that's missing since 4.9 (and this probably needs > to go to some other list) is the kernel LINT file. Unless you already > know about these firewall options there is no where you can go > to find them. The documentation makes some mention about them, > but not all of them. I was lucky because I still had my old system lying > around that I could look at, but I found these options in the first > place because I looked at the LINT file and added any options > that I thought were pertinent. > > man, i sound like my dad... back when I was your age, we had a > kernel LINT file, you kids these days don't know anything... :-)) /sys/conf/NOTES and /sys//conf/NOTES Regards, Gary From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 18:23:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075BD106566C for ; Sun, 17 Apr 2011 18:23:50 +0000 (UTC) (envelope-from rondzierwa@comcast.net) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 991A98FC17 for ; Sun, 17 Apr 2011 18:23:49 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id YiPE1g0090cZkys53iPpNx; Sun, 17 Apr 2011 18:23:49 +0000 Received: from sz0128.wc.mail.comcast.net ([76.96.58.192]) by omta10.westchester.pa.mail.comcast.net with comcast id YiPp1g00p48qnZY3WiPpMq; Sun, 17 Apr 2011 18:23:49 +0000 Date: Sun, 17 Apr 2011 18:23:49 +0000 (UTC) From: rondzierwa@comcast.net To: Freddie Cash Message-ID: <1761997147.1268808.1303064629531.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [68.50.136.212] X-Mailer: Zimbra 6.0.5_GA_2431.RHEL5_64 (ZimbraWebClient - FF3.0 (Win)/6.0.5_GA_2427.RHEL4) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: natd starting after firewall rules are loaded X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:23:50 -0000 Coowell! thanks, Freddie! ron. ----- Original Message ----- From: "Freddie Cash" To: rondzierwa@comcast.net Cc: freebsd-net@freebsd.org Sent: Sunday, April 17, 2011 1:56:51 PM Subject: Re: natd starting after firewall rules are loaded On Sun, Apr 17, 2011 at 8:55 AM, wrote: > One other thing that's missing since 4.9 (and this probably needs > to go to some other list) is the kernel LINT file. cd /usr/src/sys//conf make LINT Voila! An old-school LINT file with all the kernel config options listed. :) A better read, though, are the NOTES files: /usr/src/sys/conf/NOTES (arch independent options) /usr/src/sys//conf/NOTES (arch dependent options) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 18:28:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64690106564A for ; Sun, 17 Apr 2011 18:28:26 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1E58FC13 for ; Sun, 17 Apr 2011 18:28:25 +0000 (UTC) Received: by gyg13 with SMTP id 13so1635211gyg.13 for ; Sun, 17 Apr 2011 11:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F6xObpLGIZjhUXz1HpRDB9ryASopsAIwkK8Wz2EGuoQ=; b=XDDixPCxAFViVQG8rJqoxmtMIxMPHRhDEQajWT2sQXDgM/60ohmAlvYnD2k+Z59P4z G7R7QaQuBgn6c+EchF7SV2BeH4/e6qKpHCoxY1Kzu+FXPgjhMW8fNMuhQIsmO/ByPq2W pxeORhkV4qyYLoH4oMCmmC399VdTz4y8Rm4bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fsDkneH/NEOKt1ROiC/AjCZP60eClYkFGYKtEqohckwZfFwK3K/R1DslRwrWq9u/f8 XuCgtcstfpFP+UhPCAVSfLF8neUvPsvTMNwuJS0qRvm27rKrse11NLs7MJpBCNXw0QLw rChKxkN0N7v0TnhVwnZYY39qMw+IeiD6ZnSIw= MIME-Version: 1.0 Received: by 10.91.65.2 with SMTP id s2mr3734938agk.190.1303063011126; Sun, 17 Apr 2011 10:56:51 -0700 (PDT) Received: by 10.90.67.9 with HTTP; Sun, 17 Apr 2011 10:56:51 -0700 (PDT) In-Reply-To: <104526415.1263850.1303055758946.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> References: <311011138.1263836.1303055734510.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> <104526415.1263850.1303055758946.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> Date: Sun, 17 Apr 2011 10:56:51 -0700 Message-ID: From: Freddie Cash To: rondzierwa@comcast.net Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: natd starting after firewall rules are loaded X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:28:26 -0000 On Sun, Apr 17, 2011 at 8:55 AM, wrote: > One other thing that's missing since 4.9 (and this probably needs > to go to some other list) is the kernel LINT file. cd /usr/src/sys//conf make LINT Voila! An old-school LINT file with all the kernel config options listed. :) A better read, though, are the NOTES files: /usr/src/sys/conf/NOTES (arch independent options) /usr/src/sys//conf/NOTES (arch dependent options) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Apr 17 23:00:24 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57680106566B for ; Sun, 17 Apr 2011 23:00:24 +0000 (UTC) (envelope-from if@freebsd.org) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 8573E8FC0A for ; Sun, 17 Apr 2011 23:00:21 +0000 (UTC) Received: (qmail 26373 invoked from network); 18 Apr 2011 00:53:37 +0200 Received: from unknown (HELO filebunker.xip.at) (89.207.145.147) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2011 00:53:37 +0200 Date: Mon, 18 Apr 2011 00:53:37 +0200 (CEST) From: Ingo Flaschberger X-X-Sender: if@filebunker.xip.at To: freebsd-net@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168430090-2014229598-1303080817=:8693" Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:00:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --168430090-2014229598-1303080817=:8693 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII attached a new version of this patch with some improvements and bug-fixes. Test-Reports are welcome. Kind regards, Ingo Flaschberger --168430090-2014229598-1303080817=:8693 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=rmlock_8.2_20110418.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=rmlock_8.2_20110418.diff ZGlmZiAtdSAtciAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9jb250cmliL2lw ZmlsdGVyL3JhZGl4LmMgLi9jb250cmliL2lwZmlsdGVyL3JhZGl4LmMNCi0t LSAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9jb250cmliL2lwZmlsdGVyL3Jh ZGl4LmMJMjAwOS0wOC0wMyAwODoxMzowNi4wMDAwMDAwMDAgKzAwMDANCisr KyAuL2NvbnRyaWIvaXBmaWx0ZXIvcmFkaXguYwkyMDExLTA0LTAzIDE2OjA4 OjI4LjAwMDAwMDAwMCArMDAwMA0KQEAgLTc1OSw5ICs3NTksMTAgQEANCiB9 DQogDQogc3RydWN0IHJhZGl4X25vZGUgKg0KLXJuX2RlbGV0ZSh2X2FyZywg bmV0bWFza19hcmcsIGhlYWQpDQorcm5fZGVsZXRlKHZfYXJnLCBuZXRtYXNr X2FyZywgaGVhZCwgcm4pDQogCXZvaWQgKnZfYXJnLCAqbmV0bWFza19hcmc7 DQogCXN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKmhlYWQ7DQorCXN0cnVjdCBy YWRpeF9ub2RlICpybjsNCiB7DQogCXN0cnVjdCByYWRpeF9ub2RlICp0LCAq cCwgKngsICp0dDsNCiAJc3RydWN0IHJhZGl4X21hc2sgKm0sICpzYXZlZF9t LCAqKm1wOw0KQEAgLTEwNjksNyArMTA3MCw3IEBADQogCXN0cnVjdCByYWRp eF9ub2RlX2hlYWQgKnJuaCA9IHA7DQogCXN0cnVjdCByYWRpeF9ub2RlICpk Ow0KIA0KLQlkID0gcm5oLT5ybmhfZGVsYWRkcihuLT5ybl9rZXksIE5VTEws IHJuaCk7DQorCWQgPSBybmgtPnJuaF9kZWxhZGRyKG4tPnJuX2tleSwgTlVM TCwgcm5oLCBOVUxMKTsNCiAJaWYgKGQgIT0gTlVMTCkgew0KIAkJRnJlZVMo ZCwgbWF4X2tleWxlbiArIDIgKiBzaXplb2YgKCpkKSk7DQogCX0NCmRpZmYg LXUgLXIgLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvY29udHJpYi9pcGZpbHRl ci9yYWRpeF9pcGYuaCAuL2NvbnRyaWIvaXBmaWx0ZXIvcmFkaXhfaXBmLmgN Ci0tLSAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9jb250cmliL2lwZmlsdGVy L3JhZGl4X2lwZi5oCTIwMDktMDgtMDMgMDg6MTM6MDYuMDAwMDAwMDAwICsw MDAwDQorKysgLi9jb250cmliL2lwZmlsdGVyL3JhZGl4X2lwZi5oCTIwMTEt MDQtMTIgMTY6Mjc6MzEuMDAwMDAwMDAwICswMDAwDQpAQCAtMTMwLDcgKzEz MCw4IEBADQogCQlfX1AoKHZvaWQgKnYsIHZvaWQgKm1hc2ssDQogCQkgICAg IHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKmhlYWQsIHN0cnVjdCByYWRpeF9u b2RlIG5vZGVzW10pKTsNCiAJc3RydWN0CXJhZGl4X25vZGUgKigqcm5oX2Rl bGFkZHIpCS8qIHJlbW92ZSBiYXNlZCBvbiBzb2NrYWRkciAqLw0KLQkJX19Q KCh2b2lkICp2LCB2b2lkICptYXNrLCBzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFk ICpoZWFkKSk7DQorCQlfX1AoKHZvaWQgKnYsIHZvaWQgKm1hc2ssIHN0cnVj dCByYWRpeF9ub2RlX2hlYWQgKmhlYWQsDQorCQkgICAgc3RydWN0IHJhZGl4 X25vZGUgKnJuKSk7DQogCXN0cnVjdAlyYWRpeF9ub2RlICooKnJuaF9kZWxw a3QpCS8qIHJlbW92ZSBiYXNlZCBvbiBwYWNrZXQgaGRyICovDQogCQlfX1Ao KHZvaWQgKnYsIHZvaWQgKm1hc2ssIHN0cnVjdCByYWRpeF9ub2RlX2hlYWQg KmhlYWQpKTsNCiAJc3RydWN0CXJhZGl4X25vZGUgKigqcm5oX21hdGNoYWRk cikJLyogbG9jYXRlIGJhc2VkIG9uIHNvY2thZGRyICovDQpAQCAtMjAyLDcg KzIwMyw4IEBADQogCSAqcm5fYWRkbWFzayBfX1AoKHZvaWQgKiwgaW50LCBp bnQpKSwNCiAJICpybl9hZGRyb3V0ZSBfX1AoKHZvaWQgKiwgdm9pZCAqLCBz dHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICosDQogCQkJc3RydWN0IHJhZGl4X25v ZGUgWzJdKSksDQotCSAqcm5fZGVsZXRlIF9fUCgodm9pZCAqLCB2b2lkICos IHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKikpLA0KKwkgKnJuX2RlbGV0ZSBf X1AoKHZvaWQgKiwgdm9pZCAqLCBzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICos DQorCSAgICAgIHN0cnVjdCByYWRpeF9ub2RlICopKSwNCiAJICpybl9pbnNl cnQgX19QKCh2b2lkICosIHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKiwgaW50 ICosDQogCQkJc3RydWN0IHJhZGl4X25vZGUgWzJdKSksDQogCSAqcm5fbG9v a3VwIF9fUCgodm9pZCAqLCB2b2lkICosIHN0cnVjdCByYWRpeF9ub2RlX2hl YWQgKikpLA0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9z YmluL3JvdXRlZC9yYWRpeC5jIC4vc2Jpbi9yb3V0ZWQvcmFkaXguYw0KLS0t IC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3NiaW4vcm91dGVkL3JhZGl4LmMJ MjAwOS0wOC0wMyAwODoxMzowNi4wMDAwMDAwMDAgKzAwMDANCisrKyAuL3Ni aW4vcm91dGVkL3JhZGl4LmMJMjAxMS0wNC0wMyAxNjowODowNy4wMDAwMDAw MDAgKzAwMDANCkBAIC02NjIsNyArNjYyLDggQEANCiBzdGF0aWMgc3RydWN0 IHJhZGl4X25vZGUgKg0KIHJuX2RlbGV0ZSh2b2lkICp2X2FyZywNCiAJICB2 b2lkICpuZXRtYXNrX2FyZywNCi0JICBzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFk ICpoZWFkKQ0KKwkgIHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKmhlYWQsDQor CSAgc3RydWN0IHJhZGl4X25vZGUgKnJuKQ0KIHsNCiAJc3RydWN0IHJhZGl4 X25vZGUgKnQsICpwLCAqeCwgKnR0Ow0KIAlzdHJ1Y3QgcmFkaXhfbWFzayAq bSwgKnNhdmVkX20sICoqbXA7DQpAQCAtNjcwLDYgKzY3MSw4IEBADQogCWNh ZGRyX3QgdiwgbmV0bWFzazsNCiAJaW50IGIsIGhlYWRfb2ZmLCB2bGVuOw0K IA0KKwlybiA9IE5VTEw7IC8qIFhYWCBtYWtlIGNvbXBpbGVyIGhhcHB5ICov DQorDQogCXYgPSB2X2FyZzsNCiAJbmV0bWFzayA9IG5ldG1hc2tfYXJnOw0K IAl4ID0gaGVhZC0+cm5oX3RyZWV0b3A7DQpkaWZmIC11IC1yIC4uL3NyY19v cmdfOC4yXzIwMTEwMzI5L3NiaW4vcm91dGVkL3JhZGl4LmggLi9zYmluL3Jv dXRlZC9yYWRpeC5oDQotLS0gLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc2Jp bi9yb3V0ZWQvcmFkaXguaAkyMDA5LTA4LTAzIDA4OjEzOjA2LjAwMDAwMDAw MCArMDAwMA0KKysrIC4vc2Jpbi9yb3V0ZWQvcmFkaXguaAkyMDExLTA0LTEy IDE2OjI4OjA0LjAwMDAwMDAwMCArMDAwMA0KQEAgLTExNSw3ICsxMTUsOCBA QA0KIAkJKHZvaWQgKnYsIHZvaWQgKm1hc2ssDQogCQkgICAgIHN0cnVjdCBy YWRpeF9ub2RlX2hlYWQgKmhlYWQsIHN0cnVjdCByYWRpeF9ub2RlIG5vZGVz W10pOw0KIAlzdHJ1Y3QJcmFkaXhfbm9kZSAqKCpybmhfZGVsYWRkcikJLyog cmVtb3ZlIGJhc2VkIG9uIHNvY2thZGRyICovDQotCQkodm9pZCAqdiwgdm9p ZCAqbWFzaywgc3RydWN0IHJhZGl4X25vZGVfaGVhZCAqaGVhZCk7DQorCQko dm9pZCAqdiwgdm9pZCAqbWFzaywgc3RydWN0IHJhZGl4X25vZGVfaGVhZCAq aGVhZCwNCisJCSAgICAgc3RydWN0IHJhZGl4X25vZGUgKnJuKTsNCiAJc3Ry dWN0CXJhZGl4X25vZGUgKigqcm5oX2RlbHBrdCkJLyogcmVtb3ZlIGJhc2Vk IG9uIHBhY2tldCBoZHIgKi8NCiAJCSh2b2lkICp2LCB2b2lkICptYXNrLCBz dHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICpoZWFkKTsNCiAJc3RydWN0CXJhZGl4 X25vZGUgKigqcm5oX21hdGNoYWRkcikJLyogbG9jYXRlIGJhc2VkIG9uIHNv Y2thZGRyICovDQpkaWZmIC11IC1yIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5 L3NiaW4vcm91dGVkL3RhYmxlLmMgLi9zYmluL3JvdXRlZC90YWJsZS5jDQot LS0gLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc2Jpbi9yb3V0ZWQvdGFibGUu YwkyMDA5LTA4LTAzIDA4OjEzOjA2LjAwMDAwMDAwMCArMDAwMA0KKysrIC4v c2Jpbi9yb3V0ZWQvdGFibGUuYwkyMDExLTA0LTAzIDE2OjA4OjA3LjAwMDAw MDAwMCArMDAwMA0KQEAgLTE4NjUsNyArMTg2NSw3IEBADQogCW1hc2tfc29j ay5zaW5fYWRkci5zX2FkZHIgPSBodG9ubChydC0+cnRfbWFzayk7DQogCW1h c2t0cmltKCZtYXNrX3NvY2spOw0KIAlpZiAocnQgIT0gKHN0cnVjdCBydF9l bnRyeSAqKXJoZWFkLT5ybmhfZGVsYWRkcigmZHN0X3NvY2ssICZtYXNrX3Nv Y2ssDQotCQkJCQkJCXJoZWFkKSkgew0KKwkJCQkJCQlyaGVhZCwgTlVMTCkp IHsNCiAJCW1zZ2xvZygicm5oX2RlbGFkZHIoKSBmYWlsZWQiKTsNCiAJfSBl bHNlIHsNCiAJCWZyZWUocnQpOw0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzgu Ml8yMDExMDMyOS9zeXMvY29udHJpYi9pcGZpbHRlci9uZXRpbmV0L2lwX3Bv b2wuYyAuL3N5cy9jb250cmliL2lwZmlsdGVyL25ldGluZXQvaXBfcG9vbC5j DQotLS0gLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL2NvbnRyaWIvaXBm aWx0ZXIvbmV0aW5ldC9pcF9wb29sLmMJMjAwNy0xMC0xOCAyMTo0MjozOC4w MDAwMDAwMDAgKzAwMDANCisrKyAuL3N5cy9jb250cmliL2lwZmlsdGVyL25l dGluZXQvaXBfcG9vbC5jCTIwMTEtMDQtMDMgMTY6MDc6NDYuMDAwMDAwMDAw ICswMDAwDQpAQCAtNjcsNiArNjcsNyBAQA0KICNpbmNsdWRlICJuZXRpbmV0 L2lwX2NvbXBhdC5oIg0KICNpbmNsdWRlICJuZXRpbmV0L2lwX2ZpbC5oIg0K ICNpbmNsdWRlICJuZXRpbmV0L2lwX3Bvb2wuaCINCisjaW5jbHVkZSA8c3lz L3JtbG9jay5oPg0KIA0KICNpZiBkZWZpbmVkKElQRklMVEVSX0xPT0tVUCkg JiYgZGVmaW5lZChfS0VSTkVMKSAmJiBcDQogICAgICAgKChCU0QgPj0gMTk4 OTExKSAmJiAhZGVmaW5lZChfX29zZl9fKSAmJiBcDQpAQCAtNjIwLDcgKzYy MSw3IEBADQogDQogCVJBRElYX05PREVfSEVBRF9MT0NLKGlwby0+aXBvX2hl YWQpOw0KIAlpcG8tPmlwb19oZWFkLT5ybmhfZGVsYWRkcigmaXBlLT5pcG5f YWRkciwgJmlwZS0+aXBuX21hc2ssDQotCQkJCSAgIGlwby0+aXBvX2hlYWQp Ow0KKwkJCQkgICBpcG8tPmlwb19oZWFkLCBOVUxMKTsNCiAJUkFESVhfTk9E RV9IRUFEX1VOTE9DSyhpcG8tPmlwb19oZWFkKTsNCiANCiAJaXBfcG9vbF9u b2RlX2RlcmVmKGlwZSk7DQpAQCAtNzUxLDcgKzc1Miw3IEBADQogCVJBRElY X05PREVfSEVBRF9MT0NLKGlwby0+aXBvX2hlYWQpOw0KIAl3aGlsZSAoKG4g PSBpcG8tPmlwb19saXN0KSAhPSBOVUxMKSB7DQogCQlpcG8tPmlwb19oZWFk LT5ybmhfZGVsYWRkcigmbi0+aXBuX2FkZHIsICZuLT5pcG5fbWFzaywNCi0J CQkJCSAgIGlwby0+aXBvX2hlYWQpOw0KKwkJCQkJICAgaXBvLT5pcG9faGVh ZCwgTlVMTCk7DQogDQogCQkqbi0+aXBuX3BuZXh0ID0gbi0+aXBuX25leHQ7 DQogCQlpZiAobi0+aXBuX25leHQpDQpAQCAtOTYzLDcgKzk2NCw3IEBADQog CXN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKnJuaCA9IHA7DQogCXN0cnVjdCBy YWRpeF9ub2RlICpkOw0KIA0KLQlkID0gcm5oLT5ybmhfZGVsYWRkcihuLT5y bl9rZXksIE5VTEwsIHJuaCk7DQorCWQgPSBybmgtPnJuaF9kZWxhZGRyKG4t PnJuX2tleSwgTlVMTCwgcm5oLCBOVUxMKTsNCiAJaWYgKGQgIT0gTlVMTCkg ew0KIAkJRnJlZVMoZCwgbWF4X2tleWxlbiArIDIgKiBzaXplb2YgKCpkKSk7 DQogCX0NCmRpZmYgLXUgLXIgLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lz L2NvbnRyaWIvcGYvbmV0L3BmLmMgLi9zeXMvY29udHJpYi9wZi9uZXQvcGYu Yw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9jb250cmliL3Bm L25ldC9wZi5jCTIwMTAtMDktMjAgMTc6MDM6MTAuMDAwMDAwMDAwICswMDAw DQorKysgLi9zeXMvY29udHJpYi9wZi9uZXQvcGYuYwkyMDExLTA0LTAzIDE2 OjA3OjQ2LjAwMDAwMDAwMCArMDAwMA0KQEAgLTk5LDkgKzk5LDcgQEANCiAj aW5jbHVkZSA8bmV0L2lmX3R5cGVzLmg+DQogI2luY2x1ZGUgPG5ldC9icGYu aD4NCiAjaW5jbHVkZSA8bmV0L3JvdXRlLmg+DQotI2lmbmRlZiBfX0ZyZWVC U0RfXw0KICNpbmNsdWRlIDxuZXQvcmFkaXhfbXBhdGguaD4NCi0jZW5kaWYN CiANCiAjaW5jbHVkZSA8bmV0aW5ldC9pbi5oPg0KICNpbmNsdWRlIDxuZXRp bmV0L2luX3Zhci5oPg0KQEAgLTYxNjYsOSArNjE2NCw5IEBADQogCQkJaWYg KGtpZi0+cGZpa19pZnAgPT0gaWZwKQ0KIAkJCQlyZXQgPSAxOw0KICNpZmRl ZiBfX0ZyZWVCU0RfXyAvKiBNVUxUSVBBVEhfUk9VVElORyAqLw0KLQkJCXJu ID0gTlVMTDsNCi0jZWxzZQ0KIAkJCXJuID0gcm5fbXBhdGhfbmV4dChybik7 DQorI2Vsc2UNCisJCQlybiA9IHJuX21wYXRoX25leHQocm4sIDApOw0KICNl bmRpZg0KIAkJfSB3aGlsZSAoY2hlY2tfbXBhdGggPT0gMSAmJiBybiAhPSBO VUxMICYmIHJldCA9PSAwKTsNCiAJfSBlbHNlDQpkaWZmIC11IC1yIC4uL3Ny Y19vcmdfOC4yXzIwMTEwMzI5L3N5cy9jb250cmliL3BmL25ldC9wZl90YWJs ZS5jIC4vc3lzL2NvbnRyaWIvcGYvbmV0L3BmX3RhYmxlLmMNCi0tLSAuLi9z cmNfb3JnXzguMl8yMDExMDMyOS9zeXMvY29udHJpYi9wZi9uZXQvcGZfdGFi bGUuYwkyMDA5LTA4LTAzIDA4OjEzOjA2LjAwMDAwMDAwMCArMDAwMA0KKysr IC4vc3lzL2NvbnRyaWIvcGYvbmV0L3BmX3RhYmxlLmMJMjAxMS0wNC0wMyAx NjowNzo0Ni4wMDAwMDAwMDAgKzAwMDANCkBAIC00NCw3ICs0NCw3IEBADQog I2luY2x1ZGUgPHN5cy9tYnVmLmg+DQogI2luY2x1ZGUgPHN5cy9rZXJuZWwu aD4NCiAjaW5jbHVkZSA8c3lzL2xvY2suaD4NCi0jaW5jbHVkZSA8c3lzL3J3 bG9jay5oPg0KKyNpbmNsdWRlIDxzeXMvcm1sb2NrLmg+DQogI2lmZGVmIF9f RnJlZUJTRF9fDQogI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4NCiAjZW5kaWYN CkBAIC0xMTE0LDE3ICsxMTE0LDkgQEANCiAjZW5kaWYNCiAJaWYgKEtFTlRS WV9ORVRXT1JLKGtlKSkgew0KIAkJcGZyX3ByZXBhcmVfbmV0d29yaygmbWFz aywga2UtPnBmcmtlX2FmLCBrZS0+cGZya2VfbmV0KTsNCi0jaWZkZWYgX19G cmVlQlNEX18NCi0JCXJuID0gcm5fZGVsZXRlKCZrZS0+cGZya2Vfc2EsICZt YXNrLCBoZWFkKTsNCi0jZWxzZQ0KIAkJcm4gPSBybl9kZWxldGUoJmtlLT5w ZnJrZV9zYSwgJm1hc2ssIGhlYWQsIE5VTEwpOw0KLSNlbmRpZg0KIAl9IGVs c2UNCi0jaWZkZWYgX19GcmVlQlNEX18NCi0JCXJuID0gcm5fZGVsZXRlKCZr ZS0+cGZya2Vfc2EsIE5VTEwsIGhlYWQpOw0KLSNlbHNlDQogCQlybiA9IHJu X2RlbGV0ZSgma2UtPnBmcmtlX3NhLCBOVUxMLCBoZWFkLCBOVUxMKTsNCi0j ZW5kaWYNCiAJc3BseChzKTsNCiANCiAJaWYgKHJuID09IE5VTEwpIHsNCmRp ZmYgLXUgLXIgLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL2tlcm4vc3Vi cl93aXRuZXNzLmMgLi9zeXMva2Vybi9zdWJyX3dpdG5lc3MuYw0KLS0tIC4u L3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9rZXJuL3N1YnJfd2l0bmVzcy5j CTIwMTEtMDMtMjggMTU6MjY6NDguMDAwMDAwMDAwICswMDAwDQorKysgLi9z eXMva2Vybi9zdWJyX3dpdG5lc3MuYwkyMDExLTA0LTAzIDE2OjA3OjU0LjAw MDAwMDAwMCArMDAwMA0KQEAgLTUwOCw3ICs1MDgsNyBAQA0KIAkgKiBSb3V0 aW5nDQogCSAqLw0KIAl7ICJzb19yY3YiLCAmbG9ja19jbGFzc19tdHhfc2xl ZXAgfSwNCi0JeyAicmFkaXggbm9kZSBoZWFkIiwgJmxvY2tfY2xhc3Nfcncg fSwNCisJeyAicmFkaXggbm9kZSBoZWFkIiwgJmxvY2tfY2xhc3Nfcm0gfSwN CiAJeyAicnRlbnRyeSIsICZsb2NrX2NsYXNzX210eF9zbGVlcCB9LA0KIAl7 ICJpZmFkZHIiLCAmbG9ja19jbGFzc19tdHhfc2xlZXAgfSwNCiAJeyBOVUxM LCBOVUxMIH0sDQpkaWZmIC11IC1yIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5 L3N5cy9rZXJuL3Zmc19leHBvcnQuYyAuL3N5cy9rZXJuL3Zmc19leHBvcnQu Yw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9rZXJuL3Zmc19l eHBvcnQuYwkyMDA5LTEwLTAxIDEzOjExOjQ1LjAwMDAwMDAwMCArMDAwMA0K KysrIC4vc3lzL2tlcm4vdmZzX2V4cG9ydC5jCTIwMTEtMDQtMDMgMTY6MDc6 NTQuMDAwMDAwMDAwICswMDAwDQpAQCAtNDMsNiArNDMsNyBAQA0KICNpbmNs dWRlIDxzeXMvamFpbC5oPg0KICNpbmNsdWRlIDxzeXMva2VybmVsLmg+DQog I2luY2x1ZGUgPHN5cy9sb2NrLmg+DQorI2luY2x1ZGUgPHN5cy9ybWxvY2su aD4NCiAjaW5jbHVkZSA8c3lzL21hbGxvYy5oPg0KICNpbmNsdWRlIDxzeXMv bWJ1Zi5oPg0KICNpbmNsdWRlIDxzeXMvbW91bnQuaD4NCkBAIC0yMjgsNyAr MjI5LDcgQEANCiAJc3RydWN0IHJhZGl4X25vZGVfaGVhZCAqcm5oID0gKHN0 cnVjdCByYWRpeF9ub2RlX2hlYWQgKikgdzsNCiAJc3RydWN0IHVjcmVkICpj cmVkOw0KIA0KLQkoKnJuaC0+cm5oX2RlbGFkZHIpIChybi0+cm5fa2V5LCBy bi0+cm5fbWFzaywgcm5oKTsNCisJKCpybmgtPnJuaF9kZWxhZGRyKSAocm4t PnJuX2tleSwgcm4tPnJuX21hc2ssIHJuaCwgTlVMTCk7DQogCWNyZWQgPSAo KHN0cnVjdCBuZXRjcmVkICopcm4pLT5uZXRjX2Fub247DQogCWlmIChjcmVk ICE9IE5VTEwpDQogCQljcmZyZWUoY3JlZCk7DQpAQCAtNDI3LDYgKzQyOCw3 IEBADQogCXJlZ2lzdGVyIHN0cnVjdCBuZXRjcmVkICpucDsNCiAJcmVnaXN0 ZXIgc3RydWN0IHJhZGl4X25vZGVfaGVhZCAqcm5oOw0KIAlzdHJ1Y3Qgc29j a2FkZHIgKnNhZGRyOw0KKwlzdHJ1Y3Qgcm1fcHJpb3RyYWNrZXIgdHJhY2tl cjsNCiANCiAJbmVwID0gbXAtPm1udF9leHBvcnQ7DQogCWlmIChuZXAgPT0g TlVMTCkNCkBAIC00NDAsMTAgKzQ0MiwxMCBAQA0KIAkJCXNhZGRyID0gbmFt Ow0KIAkJCXJuaCA9IG5lcC0+bmVfcnRhYmxlW3NhZGRyLT5zYV9mYW1pbHld Ow0KIAkJCWlmIChybmggIT0gTlVMTCkgew0KLQkJCQlSQURJWF9OT0RFX0hF QURfUkxPQ0socm5oKTsNCisJCQkJUkFESVhfTk9ERV9IRUFEX1JMT0NLKHJu aCwgJnRyYWNrZXIpOw0KIAkJCQlucCA9IChzdHJ1Y3QgbmV0Y3JlZCAqKQ0K IAkJCQkgICAgKCpybmgtPnJuaF9tYXRjaGFkZHIpKHNhZGRyLCBybmgpOw0K LQkJCQlSQURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgpOw0KKwkJCQlSQURJ WF9OT0RFX0hFQURfUlVOTE9DSyhybmgsICZ0cmFja2VyKTsNCiAJCQkJaWYg KG5wICYmIG5wLT5uZXRjX3Jub2Rlcy0+cm5fZmxhZ3MgJiBSTkZfUk9PVCkN CiAJCQkJCW5wID0gTlVMTDsNCiAJCQl9DQpkaWZmIC11IC1yIC4uL3NyY19v cmdfOC4yXzIwMTEwMzI5L3N5cy9uZXQvaWYuYyAuL3N5cy9uZXQvaWYuYw0K LS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXQvaWYuYwkyMDEx LTA0LTA2IDE4OjAzOjQ5LjAwMDAwMDAwMCArMDAwMA0KKysrIC4vc3lzL25l dC9pZi5jCTIwMTEtMDQtMTIgMTY6MjE6MDUuMDAwMDAwMDAwICswMDAwDQpA QCAtNDksNiArNDksNyBAQA0KICNpbmNsdWRlIDxzeXMvcHJvdG9zdy5oPg0K ICNpbmNsdWRlIDxzeXMva2VybmVsLmg+DQogI2luY2x1ZGUgPHN5cy9sb2Nr Lmg+DQorI2luY2x1ZGUgPHN5cy9ybWxvY2suaD4NCiAjaW5jbHVkZSA8c3lz L3JlZmNvdW50Lmg+DQogI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4NCiAjaW5j bHVkZSA8c3lzL3J3bG9jay5oPg0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzgu Ml8yMDExMDMyOS9zeXMvbmV0L3BmaWwuYyAuL3N5cy9uZXQvcGZpbC5jDQot LS0gLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL25ldC9wZmlsLmMJMjAx MC0wMi0wNyAwOTowMDoyMi4wMDAwMDAwMDAgKzAwMDANCisrKyAuL3N5cy9u ZXQvcGZpbC5jCTIwMTEtMDQtMDMgMTY6MDc6NTcuMDAwMDAwMDAwICswMDAw DQpAQCAtMzksNyArMzksNiBAQA0KICNpbmNsdWRlIDxzeXMvc29ja2V0dmFy Lmg+DQogI2luY2x1ZGUgPHN5cy9zeXN0bS5oPg0KICNpbmNsdWRlIDxzeXMv Y29uZHZhci5oPg0KLSNpbmNsdWRlIDxzeXMvbG9jay5oPg0KICNpbmNsdWRl IDxzeXMvbXV0ZXguaD4NCiAjaW5jbHVkZSA8c3lzL3Byb2MuaD4NCiAjaW5j bHVkZSA8c3lzL3F1ZXVlLmg+DQpkaWZmIC11IC1yIC4uL3NyY19vcmdfOC4y XzIwMTEwMzI5L3N5cy9uZXQvcmFkaXguYyAuL3N5cy9uZXQvcmFkaXguYw0K LS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXQvcmFkaXguYwky MDEwLTA0LTAyIDA1OjAyOjUwLjAwMDAwMDAwMCArMDAwMA0KKysrIC4vc3lz L25ldC9yYWRpeC5jCTIwMTEtMDQtMDMgMTY6MDc6NTcuMDAwMDAwMDAwICsw MDAwDQpAQCAtNDEsNiArNDEsNyBAQA0KICNpbmNsdWRlIDxzeXMvc3lzdG0u aD4NCiAjaW5jbHVkZSA8c3lzL21hbGxvYy5oPg0KICNpbmNsdWRlIDxzeXMv c3lzbG9nLmg+DQorI2luY2x1ZGUgPHN5cy9ybWxvY2suaD4NCiAjaW5jbHVk ZSA8bmV0L3JhZGl4Lmg+DQogI2luY2x1ZGUgIm9wdF9tcGF0aC5oIg0KICNp ZmRlZiBSQURJWF9NUEFUSA0KQEAgLTYxNCw3ICs2MTUsNyBAQA0KIAlzdHJ1 Y3QgcmFkaXhfbm9kZSB0cmVlbm9kZXNbMl07DQogew0KIAljYWRkcl90IHYg PSAoY2FkZHJfdCl2X2FyZywgbmV0bWFzayA9IChjYWRkcl90KW5fYXJnOw0K LQlyZWdpc3RlciBzdHJ1Y3QgcmFkaXhfbm9kZSAqdCwgKnggPSAwLCAqdHQ7 DQorCXJlZ2lzdGVyIHN0cnVjdCByYWRpeF9ub2RlICp0LCAqeCA9IDAsICp4 eCA9IDAsICp0dDsNCiAJc3RydWN0IHJhZGl4X25vZGUgKnNhdmVkX3R0LCAq dG9wID0gaGVhZC0+cm5oX3RyZWV0b3A7DQogCXNob3J0IGIgPSAwLCBiX2xl YWYgPSAwOw0KIAlpbnQga2V5ZHVwbGljYXRlZDsNCkBAIC03MjMsMTIgKzcy NCwxOSBAQA0KIAkJeCA9IHQtPnJuX3JpZ2h0Ow0KIAkvKiBQcm9tb3RlIGdl bmVyYWwgcm91dGVzIGZyb20gYmVsb3cgKi8NCiAJaWYgKHgtPnJuX2JpdCA8 IDApIHsNCi0JICAgIGZvciAobXAgPSAmdC0+cm5fbWtsaXN0OyB4OyB4ID0g eC0+cm5fZHVwZWRrZXkpDQorICAgICAgICAgICAgZm9yIChtcCA9ICZ0LT5y bl9ta2xpc3Q7IHg7IHh4ID0geCwgeCA9IHgtPnJuX2R1cGVka2V5KSB7DQor ICAgICAgICAgICAgICAgIGlmICh4eCAmJiB4eC0+cm5fbWtsaXN0ICYmIHh4 LT5ybl9tYXNrID09IHgtPnJuX21hc2sgJiYNCisJCQkJeC0+cm5fbWtsaXN0 ID09IDApIHsNCisJCQkvKiBtdWx0aXBhdGggcm91dGUsIGJ1bXAgcmVmY291 bnQgb24gZmlyc3QgbWtsaXN0ICovDQorCQkJeC0+cm5fbWtsaXN0ID0geHgt PnJuX21rbGlzdDsNCisJCQl4LT5ybl9ta2xpc3QtPnJtX3JlZnMrKzsNCisJ CX0NCiAJCWlmICh4LT5ybl9tYXNrICYmICh4LT5ybl9iaXQgPj0gYl9sZWFm KSAmJiB4LT5ybl9ta2xpc3QgPT0gMCkgew0KIAkJCSptcCA9IG0gPSBybl9u ZXdfcmFkaXhfbWFzayh4LCAwKTsNCiAJCQlpZiAobSkNCiAJCQkJbXAgPSAm bS0+cm1fbWtsaXN0Ow0KIAkJfQ0KKwkgICAgfQ0KIAl9IGVsc2UgaWYgKHgt PnJuX21rbGlzdCkgew0KIAkJLyoNCiAJCSAqIFNraXAgb3ZlciBtYXNrcyB3 aG9zZSBpbmRleCBpcyA+IHRoYXQgb2YgbmV3IG5vZGUNCkBAIC03NjAsMTEg Kzc2OCwzMCBAQA0KIAkJCWJyZWFrOw0KIAkJaWYgKG0tPnJtX2ZsYWdzICYg Uk5GX05PUk1BTCkgew0KIAkJCW1tYXNrID0gbS0+cm1fbGVhZi0+cm5fbWFz azsNCi0JCQlpZiAodHQtPnJuX2ZsYWdzICYgUk5GX05PUk1BTCkgew0KLSNp ZiAhZGVmaW5lZChSQURJWF9NUEFUSCkNCi0JCQkgICAgbG9nKExPR19FUlIs DQotCQkJICAgICAgICAiTm9uLXVuaXF1ZSBub3JtYWwgcm91dGUsIG1hc2sg bm90IGVudGVyZWRcbiIpOw0KKwkJCWlmIChrZXlkdXBsaWNhdGVkKSB7DQor CQkJCWlmIChtLT5ybV9sZWFmLT5ybl9wYXJlbnQgPT0gdHQpDQorCQkJCQkv KiBuZXcgcm91dGUgaXMgYmV0dHRlciAqLw0KKwkJCQkJbS0+cm1fbGVhZiA9 IHR0Ow0KKyNpZmRlZiBESUFHTk9TVElDDQorCQkJCWVsc2Ugew0KKwkJCQkJ Zm9yICh0ID0gbS0+cm1fbGVhZjsgdDsNCisJCQkJCQl0ID0gdC0+cm5fZHVw ZWRrZXkpIHsNCisJCQkJCQlicmVhazsNCisJCQkJCX0NCisJCQkJCWlmICh0 ID09IE5VTEwpIHsNCisJCQkJCQlsb2coTE9HX0VSUiwgIk5vbi11bmlxdWUg Ig0KKwkJCQkJCQkibm9ybWFsIHJvdXRlIG9uIGR1cGVka2V5LCAiDQorCQkJ CQkJCSJtYXNrIG5vdCBlbnRlcmVkXG4iKTsNCisJCQkJCQlyZXR1cm4gdHQ7 DQorCQkJCQl9DQorCQkJCX0NCiAjZW5kaWYNCisJCQkJbS0+cm1fcmVmcysr Ow0KKwkJCQl0dC0+cm5fbWtsaXN0ID0gbTsNCisJCQkJcmV0dXJuIHR0Ow0K KwkJCX0gZWxzZSBpZiAodHQtPnJuX2ZsYWdzICYgUk5GX05PUk1BTCkgew0K KwkJCQlsb2coTE9HX0VSUiwgIk5vbi11bmlxdWUgbm9ybWFsIHJvdXRlLCIN CisJCQkJCSIgbWFzayBub3QgZW50ZXJlZFxuIik7DQogCQkJCXJldHVybiB0 dDsNCiAJCQl9DQogCQl9IGVsc2UNCkBAIC03ODMsOSArODEwLDEwIEBADQog fQ0KIA0KIHN0cnVjdCByYWRpeF9ub2RlICoNCi1ybl9kZWxldGUodl9hcmcs IG5ldG1hc2tfYXJnLCBoZWFkKQ0KK3JuX2RlbGV0ZSh2X2FyZywgbmV0bWFz a19hcmcsIGhlYWQsIHJuKQ0KIAl2b2lkICp2X2FyZywgKm5ldG1hc2tfYXJn Ow0KIAlzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICpoZWFkOw0KKwlzdHJ1Y3Qg cmFkaXhfbm9kZSAqcm47DQogew0KIAlyZWdpc3RlciBzdHJ1Y3QgcmFkaXhf bm9kZSAqdCwgKnAsICp4LCAqdHQ7DQogCXN0cnVjdCByYWRpeF9tYXNrICpt LCAqc2F2ZWRfbSwgKiptcDsNCkBAIC04MTUsMTMgKzg0MywzNyBAQA0KIAkJ CWlmICgodHQgPSB0dC0+cm5fZHVwZWRrZXkpID09IDApDQogCQkJCXJldHVy biAoMCk7DQogCX0NCisjaWZkZWYgUkFESVhfTVBBVEgNCisJaWYgKHJuKSB7 DQorCQl3aGlsZSAodHQgIT0gcm4pDQorCQkJaWYgKCh0dCA9IHR0LT5ybl9k dXBlZGtleSkgPT0gMCkNCisJCQkJcmV0dXJuICgwKTsNCisJfQ0KKyNlbmRp Zg0KIAlpZiAodHQtPnJuX21hc2sgPT0gMCB8fCAoc2F2ZWRfbSA9IG0gPSB0 dC0+cm5fbWtsaXN0KSA9PSAwKQ0KIAkJZ290byBvbjE7DQogCWlmICh0dC0+ cm5fZmxhZ3MgJiBSTkZfTk9STUFMKSB7DQotCQlpZiAobS0+cm1fbGVhZiAh PSB0dCB8fCBtLT5ybV9yZWZzID4gMCkgew0KKwkJaWYgKG0tPnJtX2xlYWYg IT0gdHQgJiYgbS0+cm1fcmVmcyA9PSAwKSB7DQogCQkJbG9nKExPR19FUlIs ICJybl9kZWxldGU6IGluY29uc2lzdGVudCBhbm5vdGF0aW9uXG4iKTsNCiAJ CQlyZXR1cm4gMDsgIC8qIGRhbmdsaW5nIHJlZiBjb3VsZCBjYXVzZSBkaXNh c3RlciAqLw0KIAkJfQ0KKwkJaWYgKG0tPnJtX2xlYWYgIT0gdHQpIHsNCisJ CQlpZiAoLS1tLT5ybV9yZWZzID49IDApDQorCQkJCWdvdG8gb24xOw0KKwkJ fQ0KKwkJLyogdHQgaXMgY3VycmVudGx5IHRoZSBoZWFkIG9mIHRoZSBwb3Nz aWJsZSBtdWx0aXBhdGggY2hhaW4gKi8NCisJCWlmIChtLT5ybV9yZWZzID4g MCkgew0KKwkJCWlmICh0dC0+cm5fZHVwZWRrZXkgPT0gTlVMTCB8fA0KKwkJ CQl0dC0+cm5fZHVwZWRrZXktPnJuX21rbGlzdCAhPSBtKSB7DQorCQkJCQls b2coTE9HX0VSUiwgInJuX2RlbGV0ZTogaW5jb25zaXN0ZW50ICINCisJCQkJ CQkiZHVwZWRrZXkgbGlzdFxuIik7DQorCQkJCQlyZXR1cm4gKDApOw0KKwkJ CX0NCisJCQltLT5ybV9sZWFmID0gdHQtPnJuX2R1cGVka2V5Ow0KKwkJCS0t bS0+cm1fcmVmczsNCisJCQlnb3RvIG9uMTsNCisJCX0NCisJCS8qIGVsc2Ug dHQgaXMgbGFzdCBhbmQgb25seSByb3V0ZSAqLw0KIAl9IGVsc2Ugew0KIAkJ aWYgKG0tPnJtX21hc2sgIT0gdHQtPnJuX21hc2spIHsNCiAJCQlsb2coTE9H X0VSUiwgInJuX2RlbGV0ZTogaW5jb25zaXN0ZW50IGFubm90YXRpb25cbiIp Ow0KQEAgLTg3NSwxNSArOTI3LDEwIEBADQogCQkJZWxzZQ0KIAkJCQl0LT5y bl9yaWdodCA9IHg7DQogCQl9IGVsc2Ugew0KLQkJCS8qIGZpbmQgbm9kZSBp biBmcm9udCBvZiB0dCBvbiB0aGUgY2hhaW4gKi8NCi0JCQlmb3IgKHggPSBw ID0gc2F2ZWRfdHQ7IHAgJiYgcC0+cm5fZHVwZWRrZXkgIT0gdHQ7KQ0KLQkJ CQlwID0gcC0+cm5fZHVwZWRrZXk7DQotCQkJaWYgKHApIHsNCi0JCQkJcC0+ cm5fZHVwZWRrZXkgPSB0dC0+cm5fZHVwZWRrZXk7DQotCQkJCWlmICh0dC0+ cm5fZHVwZWRrZXkpCQkvKiBwYXJlbnQgKi8NCi0JCQkJCXR0LT5ybl9kdXBl ZGtleS0+cm5fcGFyZW50ID0gcDsNCi0JCQkJCQkJCS8qIHBhcmVudCAqLw0K LQkJCX0gZWxzZSBsb2coTE9HX0VSUiwgInJuX2RlbGV0ZTogY291bGRuJ3Qg ZmluZCB1c1xuIik7DQorCQkJeCA9IHNhdmVkX3R0Ow0KKwkJCXQtPnJuX2R1 cGVka2V5ID0gdHQtPnJuX2R1cGVka2V5Ow0KKwkJCWlmICh0dC0+cm5fZHVw ZWRrZXkpDQorCQkJCXR0LT5ybl9kdXBlZGtleS0+cm5fcGFyZW50ID0gdDsN CiAJCX0NCiAJCXQgPSB0dCArIDE7DQogCQlpZiAgKHQtPnJuX2ZsYWdzICYg Uk5GX0FDVElWRSkgew0KQEAgLTkzMSw4ICs5NzgsMTYgQEANCiAJCQkJaWYg KG0gPT0geC0+cm5fbWtsaXN0KSB7DQogCQkJCQlzdHJ1Y3QgcmFkaXhfbWFz ayAqbW0gPSBtLT5ybV9ta2xpc3Q7DQogCQkJCQl4LT5ybl9ta2xpc3QgPSAw Ow0KLQkJCQkJaWYgKC0tKG0tPnJtX3JlZnMpIDwgMCkNCisJCQkJCWlmICgt LShtLT5ybV9yZWZzKSA8IDApIHsNCiAJCQkJCQlNS0ZyZWUobSk7DQorCQkJ CQl9IGVsc2UgaWYgKG0tPnJtX2ZsYWdzICYgUk5GX05PUk1BTCkgew0KKwkJ CQkJCS8qDQorCQkJCQkJKiBkb24ndCBwcm9ncmVzcyBiZWNhdXNlIHRoaXMN CisJCQkJCQkqIGEgbXVsdGlwYXRoIHJvdXRlLiBOZXh0DQorCQkJCQkJKiBy b3V0ZSB3aWxsIHVzZSB0aGUgc2FtZSBtLg0KKwkJCQkJCSovDQorCQkJCQkJ bW0gPSBtOw0KKwkJCQkJfQ0KIAkJCQkJbSA9IG1tOw0KIAkJCQl9DQogCQkJ aWYgKG0pDQpkaWZmIC11IC1yIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5 cy9uZXQvcmFkaXguaCAuL3N5cy9uZXQvcmFkaXguaA0KLS0tIC4uL3NyY19v cmdfOC4yXzIwMTEwMzI5L3N5cy9uZXQvcmFkaXguaAkyMDEwLTAzLTIzIDA5 OjU4OjU5LjAwMDAwMDAwMCArMDAwMA0KKysrIC4vc3lzL25ldC9yYWRpeC5o CTIwMTEtMDQtMTIgMTY6Mjk6NDcuMDAwMDAwMDAwICswMDAwDQpAQCAtMzYs NyArMzYsNyBAQA0KICNpZmRlZiBfS0VSTkVMDQogI2luY2x1ZGUgPHN5cy9f bG9jay5oPg0KICNpbmNsdWRlIDxzeXMvX211dGV4Lmg+DQotI2luY2x1ZGUg PHN5cy9fcndsb2NrLmg+DQorI2luY2x1ZGUgPHN5cy9fcm1sb2NrLmg+DQog I2VuZGlmDQogDQogI2lmZGVmIE1BTExPQ19ERUNMQVJFDQpAQCAtMTE0LDcg KzExNCw4IEBADQogCQkodm9pZCAqdiwgdm9pZCAqbWFzaywNCiAJCSAgICAg c3RydWN0IHJhZGl4X25vZGVfaGVhZCAqaGVhZCwgc3RydWN0IHJhZGl4X25v ZGUgbm9kZXNbXSk7DQogCXN0cnVjdAlyYWRpeF9ub2RlICooKnJuaF9kZWxh ZGRyKQkvKiByZW1vdmUgYmFzZWQgb24gc29ja2FkZHIgKi8NCi0JCSh2b2lk ICp2LCB2b2lkICptYXNrLCBzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICpoZWFk KTsNCisJCSh2b2lkICp2LCB2b2lkICptYXNrLCBzdHJ1Y3QgcmFkaXhfbm9k ZV9oZWFkICpoZWFkLA0KKwkJICAgICBzdHJ1Y3QgcmFkaXhfbm9kZSAqcm4p Ow0KIAlzdHJ1Y3QJcmFkaXhfbm9kZSAqKCpybmhfZGVscGt0KQkvKiByZW1v dmUgYmFzZWQgb24gcGFja2V0IGhkciAqLw0KIAkJKHZvaWQgKnYsIHZvaWQg Km1hc2ssIHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKmhlYWQpOw0KIAlzdHJ1 Y3QJcmFkaXhfbm9kZSAqKCpybmhfbWF0Y2hhZGRyKQkvKiBsb2NhdGUgYmFz ZWQgb24gc29ja2FkZHIgKi8NCkBAIC0xMzMsNyArMTM0LDcgQEANCiAJc3Ry dWN0CXJhZGl4X25vZGUgcm5oX25vZGVzWzNdOwkvKiBlbXB0eSB0cmVlIGZv ciBjb21tb24gY2FzZSAqLw0KIAlpbnQJcm5oX211bHRpcGF0aDsJCQkvKiBt dWx0aXBhdGggY2FwYWJsZSA/ICovDQogI2lmZGVmIF9LRVJORUwNCi0Jc3Ry dWN0CXJ3bG9jayBybmhfbG9jazsJCS8qIGxvY2tzIGVudGlyZSByYWRpeCB0 cmVlICovDQorCXN0cnVjdAlybWxvY2sgcm5oX2xvY2s7CQkvKiBsb2NrcyBl bnRpcmUgcmFkaXggdHJlZSAqLw0KICNlbmRpZg0KIH07DQogDQpAQCAtMTQ3 LDE3ICsxNDgsMTUgQEANCiAjZGVmaW5lIEZyZWUocCkgZnJlZSgoY2FkZHJf dClwLCBNX1JUQUJMRSk7DQogDQogI2RlZmluZQlSQURJWF9OT0RFX0hFQURf TE9DS19JTklUKHJuaCkJXA0KLSAgICByd19pbml0X2ZsYWdzKCYocm5oKS0+ cm5oX2xvY2ssICJyYWRpeCBub2RlIGhlYWQiLCAwKQ0KLSNkZWZpbmUJUkFE SVhfTk9ERV9IRUFEX0xPQ0socm5oKQlyd193bG9jaygmKHJuaCktPnJuaF9s b2NrKQ0KLSNkZWZpbmUJUkFESVhfTk9ERV9IRUFEX1VOTE9DSyhybmgpCXJ3 X3d1bmxvY2soJihybmgpLT5ybmhfbG9jaykNCi0jZGVmaW5lCVJBRElYX05P REVfSEVBRF9STE9DSyhybmgpCXJ3X3Jsb2NrKCYocm5oKS0+cm5oX2xvY2sp DQotI2RlZmluZQlSQURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgpCXJ3X3J1 bmxvY2soJihybmgpLT5ybmhfbG9jaykNCi0jZGVmaW5lCVJBRElYX05PREVf SEVBRF9MT0NLX1RSWV9VUEdSQURFKHJuaCkJcndfdHJ5X3VwZ3JhZGUoJihy bmgpLT5ybmhfbG9jaykNCi0NCi0NCi0jZGVmaW5lCVJBRElYX05PREVfSEVB RF9ERVNUUk9ZKHJuaCkJcndfZGVzdHJveSgmKHJuaCktPnJuaF9sb2NrKQ0K LSNkZWZpbmUJUkFESVhfTk9ERV9IRUFEX0xPQ0tfQVNTRVJUKHJuaCkgcndf YXNzZXJ0KCYocm5oKS0+cm5oX2xvY2ssIFJBX0xPQ0tFRCkNCi0jZGVmaW5l CVJBRElYX05PREVfSEVBRF9XTE9DS19BU1NFUlQocm5oKSByd19hc3NlcnQo JihybmgpLT5ybmhfbG9jaywgUkFfV0xPQ0tFRCkNCisJcm1faW5pdF9mbGFn cygmKHJuaCktPnJuaF9sb2NrLCAicmFkaXggbm9kZSBoZWFkIiwgMCkNCisj ZGVmaW5lICAgICAgICBSQURJWF9OT0RFX0hFQURfTE9DSyhybmgpICAgICAg IHJtX3dsb2NrKCYocm5oKS0+cm5oX2xvY2spDQorI2RlZmluZSAgICAgICAg UkFESVhfTk9ERV9IRUFEX1VOTE9DSyhybmgpICAgICBybV93dW5sb2NrKCYo cm5oKS0+cm5oX2xvY2spDQorI2RlZmluZSAgICAgICAgUkFESVhfTk9ERV9I RUFEX1JMT0NLKHJuaCwgdHJhY2tlcikgICAgIHJtX3Jsb2NrKCYocm5oKS0+ cm5oX2xvY2ssICh0cmFja2VyKSkNCisjZGVmaW5lICAgICAgICBSQURJWF9O T0RFX0hFQURfUlVOTE9DSyhybmgsIHRyYWNrZXIpICAgcm1fcnVubG9jaygm KHJuaCktPnJuaF9sb2NrLCAodHJhY2tlcikpDQorDQorI2RlZmluZSAgICAg ICAgUkFESVhfTk9ERV9IRUFEX0RFU1RST1kocm5oKSAgICBybV9kZXN0cm95 KCYocm5oKS0+cm5oX2xvY2spDQorI2RlZmluZSAgICAgICAgUkFESVhfTk9E RV9IRUFEX0xPQ0tfQVNTRVJUKHJuaCkgICAgICAgIHJtX3dvd25lZCgmKHJu aCktPnJuaF9sb2NrKQ0KKyNkZWZpbmUgICAgICAgIFJBRElYX05PREVfSEVB RF9XTE9DS19BU1NFUlQocm5oKSAgICAgICBybV93b3duZWQoJihybmgpLT5y bmhfbG9jaykNCiAjZW5kaWYgLyogX0tFUk5FTCAqLw0KIA0KIHZvaWQJIHJu X2luaXQoaW50KTsNCkBAIC0xNjgsNyArMTY3LDcgQEANCiAJICpybl9hZGRt YXNrKHZvaWQgKiwgaW50LCBpbnQpLA0KIAkgKnJuX2FkZHJvdXRlICh2b2lk ICosIHZvaWQgKiwgc3RydWN0IHJhZGl4X25vZGVfaGVhZCAqLA0KIAkJCXN0 cnVjdCByYWRpeF9ub2RlIFsyXSksDQotCSAqcm5fZGVsZXRlKHZvaWQgKiwg dm9pZCAqLCBzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICopLA0KKwkgKnJuX2Rl bGV0ZSh2b2lkICosIHZvaWQgKiwgc3RydWN0IHJhZGl4X25vZGVfaGVhZCAq LCBzdHJ1Y3QgcmFkaXhfbm9kZSAqKSwNCiAJICpybl9sb29rdXAgKHZvaWQg KnZfYXJnLCB2b2lkICptX2FyZywNCiAJCSAgICAgICAgc3RydWN0IHJhZGl4 X25vZGVfaGVhZCAqaGVhZCksDQogCSAqcm5fbWF0Y2godm9pZCAqLCBzdHJ1 Y3QgcmFkaXhfbm9kZV9oZWFkICopOw0KZGlmZiAtdSAtciAuLi9zcmNfb3Jn XzguMl8yMDExMDMyOS9zeXMvbmV0L3JhZGl4X21wYXRoLmMgLi9zeXMvbmV0 L3JhZGl4X21wYXRoLmMNCi0tLSAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9z eXMvbmV0L3JhZGl4X21wYXRoLmMJMjAxMS0wNC0xMiAyMTozMTowOC4wMDAw MDAwMDAgKzAwMDANCisrKyAuL3N5cy9uZXQvcmFkaXhfbXBhdGguYwkyMDEx LTA0LTE1IDE3OjQwOjQzLjAwMDAwMDAwMCArMDAwMA0KQEAgLTQ1LDYgKzQ1 LDggQEANCiAjaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0KICNpbmNsdWRlIDxz eXMvZG9tYWluLmg+DQogI2luY2x1ZGUgPHN5cy9zeXNsb2cuaD4NCisjaW5j bHVkZSA8c3lzL2xvY2suaD4NCisjaW5jbHVkZSA8c3lzL3JtbG9jay5oPg0K ICNpbmNsdWRlIDxuZXQvcmFkaXguaD4NCiAjaW5jbHVkZSA8bmV0L3JhZGl4 X21wYXRoLmg+DQogI2luY2x1ZGUgPG5ldC9yb3V0ZS5oPg0KQEAgLTU0LDcg KzU2LDcgQEANCiAvKg0KICAqIGdpdmUgc29tZSBqaXR0ZXIgdG8gaGFzaCwg dG8gYXZvaWQgc3luY2hyb25pemF0aW9uIGJldHdlZW4gcm91dGVycw0KICAq Lw0KLXN0YXRpYyB1aW50MzJfdCBoYXNoaml0dGVyOw0KK3VpbnQzMl90IGhh c2hqaXR0ZXI7DQogDQogaW50DQogcm5fbXBhdGhfY2FwYWJsZShzdHJ1Y3Qg cmFkaXhfbm9kZV9oZWFkICpybmgpDQpAQCAtNzcsMjAgKzc5LDYgQEANCiAJ CXJldHVybiBOVUxMOw0KIH0NCiANCi11aW50MzJfdA0KLXJuX21wYXRoX2Nv dW50KHN0cnVjdCByYWRpeF9ub2RlICpybikNCi17DQotCXVpbnQzMl90IGkg PSAwOw0KLQlzdHJ1Y3QgcnRlbnRyeSAqcnQ7DQotCQ0KLQl3aGlsZSAocm4g IT0gTlVMTCkgew0KLQkJcnQgPSAoc3RydWN0IHJ0ZW50cnkgKilybjsNCi0J CWkgKz0gcnQtPnJ0X3JteC5ybXhfd2VpZ2h0Ow0KLQkJcm4gPSBybl9tcGF0 aF9uZXh0KHJuKTsNCi0JfQ0KLQlyZXR1cm4gKGkpOw0KLX0NCi0NCiBzdHJ1 Y3QgcnRlbnRyeSAqDQogcnRfbXBhdGhfbWF0Y2hnYXRlKHN0cnVjdCBydGVu dHJ5ICpydCwgc3RydWN0IHNvY2thZGRyICpnYXRlKQ0KIHsNCkBAIC0xMjUs MzMgKzExMyw2IEBADQogCXJldHVybiAoc3RydWN0IHJ0ZW50cnkgKilybjsN CiB9DQogDQotLyogDQotICogZ28gdGhyb3VnaCB0aGUgY2hhaW4gYW5kIHVu bGluayAicnQiIGZyb20gdGhlIGxpc3QNCi0gKiB0aGUgY2FsbGVyIHdpbGwg ZnJlZSAicnQiDQotICovDQotaW50DQotcnRfbXBhdGhfZGVsZHVwKHN0cnVj dCBydGVudHJ5ICpoZWFkcnQsIHN0cnVjdCBydGVudHJ5ICpydCkNCi17DQot ICAgICAgICBzdHJ1Y3QgcmFkaXhfbm9kZSAqdCwgKnR0Ow0KLQ0KLSAgICAg ICAgaWYgKCFoZWFkcnQgfHwgIXJ0KQ0KLSAgICAgICAgICAgIHJldHVybiAo MCk7DQotICAgICAgICB0ID0gKHN0cnVjdCByYWRpeF9ub2RlICopaGVhZHJ0 Ow0KLSAgICAgICAgdHQgPSBybl9tcGF0aF9uZXh0KHQpOw0KLSAgICAgICAg d2hpbGUgKHR0KSB7DQotICAgICAgICAgICAgaWYgKHR0ID09IChzdHJ1Y3Qg cmFkaXhfbm9kZSAqKXJ0KSB7DQotICAgICAgICAgICAgICAgIHQtPnJuX2R1 cGVka2V5ID0gdHQtPnJuX2R1cGVka2V5Ow0KLSAgICAgICAgICAgICAgICB0 dC0+cm5fZHVwZWRrZXkgPSBOVUxMOw0KLSAgICAJICAgICAgICB0dC0+cm5f ZmxhZ3MgJj0gflJORl9BQ1RJVkU7DQotCSAgICAgICAgdHRbMV0ucm5fZmxh Z3MgJj0gflJORl9BQ1RJVkU7DQotICAgICAgICAgICAgICAgIHJldHVybiAo MSk7DQotICAgICAgICAgICAgfQ0KLSAgICAgICAgICAgIHQgPSB0dDsNCi0g ICAgICAgICAgICB0dCA9IHJuX21wYXRoX25leHQoKHN0cnVjdCByYWRpeF9u b2RlICopdCk7DQotICAgICAgICB9DQotICAgICAgICByZXR1cm4gKDApOw0K LX0NCi0NCiAvKg0KICAqIGNoZWNrIGlmIHdlIGhhdmUgdGhlIHNhbWUga2V5 L21hc2svZ2F0ZXdheSBvbiB0aGUgdGFibGUgYWxyZWFkeS4NCiAgKi8NCkBA IC0yNjEsMTAgKzIyMiwyMSBAQA0KIHZvaWQNCiBydGFsbG9jX21wYXRoX2Zp YihzdHJ1Y3Qgcm91dGUgKnJvLCB1aW50MzJfdCBoYXNoLCB1X2ludCBmaWJu dW0pDQogew0KKwlydGFsbG9jX21wYXRoX2ZpYl9mbGFncyggcm8sIGhhc2gs IGZpYm51bSwgMCk7DQorfQ0KKw0KKy8qDQorICogZmxhZyBSVEZfR0FURVdB WSByZXR1cm5zIG9ubHkgaW50ZXJmYWNlIHJvdXRlcywNCisgKiBvbmx5IG9u ZSBpbnRlcmZhY2Utcm91dGUgaXMgcG9zc2libGUNCisgKi8NCit2b2lkDQor cnRhbGxvY19tcGF0aF9maWJfZmxhZ3Moc3RydWN0IHJvdXRlICpybywgdWlu dDMyX3QgaGFzaCwgdV9pbnQgZmlibnVtLCBpbnQgZmxhZ3MpDQorew0KIAlz dHJ1Y3QgcmFkaXhfbm9kZSAqcm4wLCAqcm47DQotCXVfaW50MzJfdCBuOw0K Kwl1X2ludDMyX3QgbiA9IDE7DQogCXN0cnVjdCBydGVudHJ5ICpydDsNCiAJ aW50NjRfdCB3ZWlnaHQ7DQorCWludDY0X3QgbG93ZXN0X3dlaWdodDsNCiAN CiAJLyoNCiAJICogWFhYIHdlIGRvbid0IGF0dGVtcHQgdG8gbG9va3VwIGNh Y2hlZCByb3V0ZSBhZ2Fpbjsgd2hhdCBzaG91bGQNCkBAIC0yODUsMjAgKzI1 NywzNSBAQA0KIA0KIAkvKiBiZXlvbmQgaGVyZSwgd2UgdXNlIHJuIGFzIHRo ZSBtYXN0ZXIgY29weSAqLw0KIAlybjAgPSBybiA9IChzdHJ1Y3QgcmFkaXhf bm9kZSAqKXJvLT5yb19ydDsNCi0JbiA9IHJuX21wYXRoX2NvdW50KHJuMCk7 DQorDQorCS8qIGZpbmQgbG93ZXN0IHdlaWdodCByb3V0ZSAqLw0KKwlmb3Ig KCBydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKXJuLCB3ZWlnaHQgPSBydC0+cnRf cm14LnJteF93ZWlnaHQ7DQorCSAgICBybiAhPSBOVUxMOyBybiA9IHJuX21w YXRoX25leHQoIHJuKSkgew0KKwkJcnQgPSAoc3RydWN0IHJ0ZW50cnkgKily bjsNCisJCWlmICgocnQtPnJ0X2ZsYWdzICYgUlRGX1VQKSAmJiAhKHJ0LT5y dF9mbGFncyAmIGZsYWdzKSkgew0KKwkJCWlmIChmbGFncyAmIFJURl9HQVRF V0FZKSAvKiBzaG9ydGN1dCAqLw0KKwkJCQlnb3RvIGVuZDsJLyogb25seSAx IGludGVyZmFjZSByb3V0ZSBwb3NzaWJsZSEgKi8NCisJCQlpZiAod2VpZ2h0 ID4gcnQtPnJ0X3JteC5ybXhfd2VpZ2h0KSB7DQorCQkJCXdlaWdodCA9IHJ0 LT5ydF9ybXgucm14X3dlaWdodDsNCisJCQkJbiA9IDE7DQorCQkJfSBlbHNl IGlmICh3ZWlnaHQgPT0gcnQtPnJ0X3JteC5ybXhfd2VpZ2h0KQ0KKwkJCQlu Kys7DQorCQl9DQorCX0NCisJbG93ZXN0X3dlaWdodCA9IHdlaWdodDsNCiAN CiAJLyogZ3cgc2VsZWN0aW9uIGJ5IE1vZHVsby1OIEhhc2ggKFJGQzI5OTEp IFhYWCBuZWVkIGltcHJvdmVtZW50PyAqLw0KIAloYXNoICs9IGhhc2hqaXR0 ZXI7DQogCWhhc2ggJT0gbjsNCi0JZm9yICh3ZWlnaHQgPSBhYnMoKGludDMy X3QpaGFzaCksIHJ0ID0gcm8tPnJvX3J0Ow0KLQkgICAgIHdlaWdodCA+PSBy dC0+cnRfcm14LnJteF93ZWlnaHQgJiYgcm47IA0KLQkgICAgIHdlaWdodCAt PSBydC0+cnRfcm14LnJteF93ZWlnaHQpIHsNCi0JCQ0KLQkJLyogc3RheSB3 aXRoaW4gdGhlIG11bHRpcGF0aCByb3V0ZXMgKi8NCi0JCWlmIChybi0+cm5f ZHVwZWRrZXkgJiYgcm4tPnJuX21hc2sgIT0gcm4tPnJuX2R1cGVka2V5LT5y bl9tYXNrKQ0KLQkJCWJyZWFrOw0KLQkJcm4gPSBybi0+cm5fZHVwZWRrZXk7 DQorCWZvciAoIHJuID0gcm4wLCBuID0gMDsgcm4gIT0gTlVMTDsgcm4gPSBy bl9tcGF0aF9uZXh0KCBybikpIHsNCiAJCXJ0ID0gKHN0cnVjdCBydGVudHJ5 ICopcm47DQorCQlpZiAocnQtPnJ0X2ZsYWdzICYgUlRGX1VQKSB7DQorCQkJ aWYgKCBydC0+cnRfcm14LnJteF93ZWlnaHQgPT0gbG93ZXN0X3dlaWdodCkg ew0KKwkJCQlpZiAobiA9PSBoYXNoKQ0KKwkJCQkJYnJlYWs7DQorCQkJCW4r KzsNCisJCQl9DQorCQl9DQogCX0NCiAJLyogWFhYIHRyeSBmaWxsaW5nIHJ0 X2d3cm91dGUgYW5kIGF2b2lkIHVucmVhY2hhYmxlIGd3ICAqLw0KIA0KQEAg LTMwOCw2ICsyOTUsNyBAQA0KIAkJcm8tPnJvX3J0ID0gTlVMTDsNCiAJCXJl dHVybjsNCiAJfQ0KK2VuZDoNCiAJaWYgKHJvLT5yb19ydCAhPSBydCkgew0K IAkJUlRGUkVFX0xPQ0tFRChyby0+cm9fcnQpOw0KIAkJcm8tPnJvX3J0ID0g KHN0cnVjdCBydGVudHJ5ICopcm47DQpkaWZmIC11IC1yIC4uL3NyY19vcmdf OC4yXzIwMTEwMzI5L3N5cy9uZXQvcmFkaXhfbXBhdGguaCAuL3N5cy9uZXQv cmFkaXhfbXBhdGguaA0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5 cy9uZXQvcmFkaXhfbXBhdGguaAkyMDA5LTA4LTAzIDA4OjEzOjA2LjAwMDAw MDAwMCArMDAwMA0KKysrIC4vc3lzL25ldC9yYWRpeF9tcGF0aC5oCTIwMTEt MDQtMTUgMTc6Mzk6NTYuMDAwMDAwMDAwICswMDAwDQpAQCAtNDQsMTQgKzQ0 LDE1IEBADQogc3RydWN0IHJvdXRlOw0KIHN0cnVjdCBydGVudHJ5Ow0KIHN0 cnVjdCBzb2NrYWRkcjsNCitleHRlcm4gdWludDMyX3QgaGFzaGppdHRlcjsN CiBpbnQJcm5fbXBhdGhfY2FwYWJsZShzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFk ICopOw0KIHN0cnVjdCByYWRpeF9ub2RlICpybl9tcGF0aF9uZXh0KHN0cnVj dCByYWRpeF9ub2RlICopOw0KLXVfaW50MzJfdCBybl9tcGF0aF9jb3VudChz dHJ1Y3QgcmFkaXhfbm9kZSAqKTsNCiBzdHJ1Y3QgcnRlbnRyeSAqcnRfbXBh dGhfbWF0Y2hnYXRlKHN0cnVjdCBydGVudHJ5ICosIHN0cnVjdCBzb2NrYWRk ciAqKTsNCiBpbnQgcnRfbXBhdGhfY29uZmxpY3Qoc3RydWN0IHJhZGl4X25v ZGVfaGVhZCAqLCBzdHJ1Y3QgcnRlbnRyeSAqLA0KICAgICBzdHJ1Y3Qgc29j a2FkZHIgKik7DQordm9pZCBydGFsbG9jX21wYXRoX2ZpYl9mbGFncyhzdHJ1 Y3Qgcm91dGUgKiwgdV9pbnQzMl90LCB1X2ludCwgaW50KTsNCiB2b2lkIHJ0 YWxsb2NfbXBhdGhfZmliKHN0cnVjdCByb3V0ZSAqLCB1X2ludDMyX3QsIHVf aW50KTsNCi0jZGVmaW5lIHJ0YWxsb2NfbXBhdGgoX3JvdXRlLCBfaGFzaCkg cnRhbGxvY19tcGF0aF9maWIoKF9yb3V0ZSksIChfaGFzaCksIDApDQorI2Rl ZmluZSBydGFsbG9jX21wYXRoKF9yb3V0ZSwgX2hhc2gpIHJ0YWxsb2NfbXBh dGhfZmliX2ZsYWdzKChfcm91dGUpLCAoX2hhc2gpLCAwLCAwKQ0KIHN0cnVj dCByYWRpeF9ub2RlICpybl9tcGF0aF9sb29rdXAodm9pZCAqLCB2b2lkICos DQogICAgIHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKik7DQogaW50IHJ0X21w YXRoX2RlbGR1cChzdHJ1Y3QgcnRlbnRyeSAqLCBzdHJ1Y3QgcnRlbnRyeSAq KTsNCmRpZmYgLXUgLXIgLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL25l dC9yb3V0ZS5jIC4vc3lzL25ldC9yb3V0ZS5jDQotLS0gLi4vc3JjX29yZ184 LjJfMjAxMTAzMjkvc3lzL25ldC9yb3V0ZS5jCTIwMTEtMDQtMTQgMTY6MDk6 NDAuMDAwMDAwMDAwICswMDAwDQorKysgLi9zeXMvbmV0L3JvdXRlLmMJMjAx MS0wNC0xNCAxNjoxNDoxOC4wMDAwMDAwMDAgKzAwMDANCkBAIC01MSw2ICs1 MSw4IEBADQogI2luY2x1ZGUgPHN5cy9wcm9jLmg+DQogI2luY2x1ZGUgPHN5 cy9kb21haW4uaD4NCiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPg0KKyNpbmNs dWRlIDxzeXMvbG9jay5oPg0KKyNpbmNsdWRlIDxzeXMvcm1sb2NrLmg+DQog DQogI2luY2x1ZGUgPG5ldC9pZi5oPg0KICNpbmNsdWRlIDxuZXQvaWZfZGwu aD4NCkBAIC0zNDIsNiArMzQ0LDcgQEANCiAJc3RydWN0IHJhZGl4X25vZGUg KnJuOw0KIAlzdHJ1Y3QgcnRlbnRyeSAqbmV3cnQ7DQogCXN0cnVjdCBydF9h ZGRyaW5mbyBpbmZvOw0KKwlzdHJ1Y3Qgcm1fcHJpb3RyYWNrZXIgdHJhY2tl cjsNCiAJaW50IGVyciA9IDAsIG1zZ3R5cGUgPSBSVE1fTUlTUzsNCiAJaW50 IG5lZWRsb2NrOw0KIA0KQEAgLTM1OCwyNCArMzYxLDI2IEBADQogCQlnb3Rv IG1pc3M7DQogCX0NCiAJbmVlZGxvY2sgPSAhKGlnbmZsYWdzICYgUlRGX1JO SF9MT0NLRUQpOw0KLQlpZiAobmVlZGxvY2spDQotCQlSQURJWF9OT0RFX0hF QURfUkxPQ0socm5oKTsNCi0jaWZkZWYgSU5WQVJJQU5UUwkNCisJaWYgKG5l ZWRsb2NrKSAvKiBYWFggd2UgYWx3YXlzIG5lZWQgdGhlIGxvY2sgZm9yIG5v dyEgKi8NCisJCVJBRElYX05PREVfSEVBRF9MT0NLKHJuaCk7DQogCWVsc2UN Ci0JCVJBRElYX05PREVfSEVBRF9MT0NLX0FTU0VSVChybmgpOw0KLSNlbmRp Zg0KKwkJUkFESVhfTk9ERV9IRUFEX1JMT0NLKHJuaCwgJnRyYWNrZXIpOw0K IAlybiA9IHJuaC0+cm5oX21hdGNoYWRkcihkc3QsIHJuaCk7DQogCWlmIChy biAmJiAoKHJuLT5ybl9mbGFncyAmIFJORl9ST09UKSA9PSAwKSkgew0KIAkJ bmV3cnQgPSBydCA9IFJOVE9SVChybik7DQogCQlSVF9MT0NLKG5ld3J0KTsN CiAJCVJUX0FERFJFRihuZXdydCk7DQotCQlpZiAobmVlZGxvY2spDQotCQkJ UkFESVhfTk9ERV9IRUFEX1JVTkxPQ0socm5oKTsNCisJCWlmIChuZWVkbG9j aykgLyogWFhYIHdlIGFsd2F5cyBuZWVkIHRoZSBsb2NrIGZvciBub3chICov DQorCQkJUkFESVhfTk9ERV9IRUFEX1VOTE9DSyhybmgpOw0KKwkJZWxzZQ0K KwkJCVJBRElYX05PREVfSEVBRF9SVU5MT0NLKHJuaCwgJnRyYWNrZXIpOw0K IAkJZ290byBkb25lOw0KKwl9DQorCWlmIChuZWVkbG9jaykgLyogWFhYIHdl IGFsd2F5cyBuZWVkIHRoZSBsb2NrIGZvciBub3chICovDQorCQlSQURJWF9O T0RFX0hFQURfVU5MT0NLKHJuaCk7DQorCWVsc2UNCisJCVJBRElYX05PREVf SEVBRF9SVU5MT0NLKHJuaCwgJnRyYWNrZXIpOw0KIA0KLQl9IGVsc2UgaWYg KG5lZWRsb2NrKQ0KLQkJUkFESVhfTk9ERV9IRUFEX1JVTkxPQ0socm5oKTsN Ci0JDQogCS8qDQogCSAqIEVpdGhlciB3ZSBoaXQgdGhlIHJvb3Qgb3IgY291 bGRuJ3QgZmluZCBhbnkgbWF0Y2gsDQogCSAqIFdoaWNoIGJhc2ljYWxseSBt ZWFucw0KQEAgLTQwMCw2ICs0MDUsMTYyIEBADQogfQ0KIA0KIC8qDQorICog TG9va3VwIGEgZGVzdGluYXRpb24gaW4gdGhlIHJvdXRpbmcgdGFibGUgYW5k DQorICogcmVwb3J0IHRoZSBuZXh0IGhvcCwgaW50ZXJmYWNlIGFuZCBpbnRl cmZhY2UgYWRkcmVzcw0KKyAqIGluIGEgbmV3IHN0cnVjdHVyZS4NCisgKiBP bmx5IHJlYWQgbG9jayBhY2Nlc3Mgb24gdGhlIHJvdXRpbmcgdGFibGUgaXMg cmVxdWlyZWQsDQorICogaW5kaXZpZHVhbCByb3V0ZXMgYXJlIG5vdCBsb2Nr ZWQuDQorICogUmV0dXJucyAxIGZvciBlbnRyeSBmb3VuZCwgMCBmb3Igbm90 IGZvdW5kLg0KKyAqLw0KK2ludA0KK3J0bG9va3VwX2ZpYihzdHJ1Y3Qgc29j a2FkZHIgKmRzdCwgdV9pbnQgZmlibnVtLCBzdHJ1Y3QgcnRsb29rdXAgKnJ0 bCwNCisgICAgaW50IGZsYWdzKQ0KK3sNCisJc3RydWN0IHJhZGl4X25vZGVf aGVhZCAqcm5oOw0KKwlzdHJ1Y3QgcmFkaXhfbm9kZSAqcm47DQorCXN0cnVj dCBydGVudHJ5ICpydDsNCisJaW50IHJldCA9IDA7DQorCXN0cnVjdCBybV9w cmlvdHJhY2tlciB0cmFja2VyOw0KKw0KKwlLQVNTRVJUKChmaWJudW0gPCBy dF9udW1maWJzKSwgKCJydGFsbG9jMV9maWI6IGJhZCBmaWJudW0iKSk7DQor CWlmIChkc3QtPnNhX2ZhbWlseSAhPSBBRl9JTkVUKSAgLyogT25seSBJTkVU IHN1cHBvcnRzID4gMSBmaWIgbm93ICovDQorCQlmaWJudW0gPSAwOw0KKwly bmggPSBydF90YWJsZXNfZ2V0X3JuaChmaWJudW0sIGRzdC0+c2FfZmFtaWx5 KTsNCisNCisJLyogTG9vayB1cCB0aGUgYWRkcmVzcyBpbiB0aGUgdGFibGUg Zm9yIHRoYXQgQWRkcmVzcyBGYW1pbHkuICovDQorCWlmIChybmggPT0gTlVM TCkgew0KKwkJVl9ydHN0YXQucnRzX3VucmVhY2grKzsNCisJCXJldHVybiAo MCk7DQorCX0NCisNCisJUkFESVhfTk9ERV9IRUFEX1JMT0NLKHJuaCwgJnRy YWNrZXIpOw0KKwlybiA9IHJuaC0+cm5oX21hdGNoYWRkcihkc3QsIHJuaCk7 DQorCWlmIChybiAhPSBOVUxMICYmICgocm4tPnJuX2ZsYWdzICYgUk5GX1JP T1QpID09IDApKSB7DQorCQlydCA9IFJOVE9SVChybik7DQorDQorCQlpZigg cnQtPnJ0X2dhdGV3YXktPnNhX2xlbiA+IHJ0bC0+cnRfZ2F0ZXdheS0+c2Ff bGVuKSB7DQorCQkJdW5zaWduZWQgY2hhciBzYV9sZW4gPSBydGwtPnJ0X2dh dGV3YXktPnNhX2xlbjsNCisJCQliY29weSggcnQtPnJ0X2dhdGV3YXksIHJ0 bC0+cnRfZ2F0ZXdheSwgc2FfbGVuKTsNCisJCQlydGwtPnJ0X2dhdGV3YXkt PnNhX2xlbiA9IHNhX2xlbjsNCisJCX0gZWxzZSB7DQorCQkJdW5zaWduZWQg Y2hhciBzYV9sZW4gPSBydC0+cnRfZ2F0ZXdheS0+c2FfbGVuOw0KKwkJCWJj b3B5KCBydC0+cnRfZ2F0ZXdheSwgcnRsLT5ydF9nYXRld2F5LCBzYV9sZW4p Ow0KKwkJCXJ0bC0+cnRfZ2F0ZXdheS0+c2FfbGVuID0gc2FfbGVuOw0KKwkJ fQ0KKwkJcnRsLT5ydF9pZnAgPSBydC0+cnRfaWZwOw0KKwkJcnRsLT5ydF9p ZmEgPSBydC0+cnRfaWZhOw0KKwkJcnRsLT5ydF9ybXgucm14X210dSA9IHJ0 LT5ydF9ybXgucm14X210dTsNCisJCXJ0bC0+cnRfcm14LnJteF9leHBpcmUg PSBydC0+cnRfcm14LnJteF9leHBpcmU7DQorCQlydGwtPnJ0X2ZsYWdzID0g cnQtPnJ0X2ZsYWdzOw0KKwkJaWYgKGZsYWdzICYgUlRMX1BLU0VOVCkNCisg ICAgICAgICAgICAgICAgCXJ0LT5ydF9ybXgucm14X3Brc2VudCsrOyAvKiBy YWN5IGJ1dCBvayAqLw0KKwkJcmV0ID0gMTsNCisJfQ0KKwlSQURJWF9OT0RF X0hFQURfUlVOTE9DSyhybmgsICZ0cmFja2VyKTsNCisJcmV0dXJuIChyZXQp Ow0KK30NCisNCisjaWZkZWYgUkFESVhfTVBBVEgNCisvKg0KKyAqIExvb2t1 cCBhIG1wYXRoIGRlc3RpbmF0aW9uIGluIHRoZSByb3V0aW5nIHRhYmxlIGFu ZA0KKyAqIHJlcG9ydCB0aGUgbmV4dCBob3AsIGludGVyZmFjZSBhbmQgaW50 ZXJmYWNlIGFkZHJlc3MNCisgKiBpbiBhIG5ldyBzdHJ1Y3R1cmUuDQorICog T25seSByZWFkIGxvY2sgYWNjZXNzIG9uIHRoZSByb3V0aW5nIHRhYmxlIGlz IHJlcXVpcmVkLA0KKyAqIGluZGl2aWR1YWwgcm91dGVzIGFyZSBub3QgbG9j a2VkLg0KKyAqIFJldHVybnMgMSBmb3IgZW50cnkgZm91bmQsIDAgZm9yIG5v dCBmb3VuZC4NCisgKi8NCitpbnQNCitydGxvb2t1cF9tcGF0aF9maWIoc3Ry dWN0IHNvY2thZGRyICpkc3QsIHVfaW50MzJfdCBoYXNoLCB1X2ludCBmaWJu dW0sDQorICAgIHN0cnVjdCBydGxvb2t1cCAqcnRsLCBpbnQgZmxhZ3MpDQor ew0KKwlzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICpybmg7DQorCXN0cnVjdCBy YWRpeF9ub2RlICpybiwgKnJuMDsNCisJc3RydWN0IHJ0ZW50cnkgKnJ0Ow0K KwlpbnQgcmV0ID0gMDsNCisJc3RydWN0IHJtX3ByaW90cmFja2VyIHRyYWNr ZXI7DQorCWludDY0X3Qgd2VpZ2h0Ow0KKwlpbnQ2NF90IGxvd2VzdF93ZWln aHQ7DQorCXVfaW50MzJfdCBuID0gMDsNCisNCisJS0FTU0VSVCgoZmlibnVt IDwgcnRfbnVtZmlicyksICgicnRhbGxvYzFfZmliOiBiYWQgZmlibnVtIikp Ow0KKwlpZiAoZHN0LT5zYV9mYW1pbHkgIT0gQUZfSU5FVCkgIC8qIE9ubHkg SU5FVCBzdXBwb3J0cyA+IDEgZmliIG5vdyAqLw0KKwkJZmlibnVtID0gMDsN CisJcm5oID0gcnRfdGFibGVzX2dldF9ybmgoZmlibnVtLCBkc3QtPnNhX2Zh bWlseSk7DQorDQorCS8qIExvb2sgdXAgdGhlIGFkZHJlc3MgaW4gdGhlIHRh YmxlIGZvciB0aGF0IEFkZHJlc3MgRmFtaWx5LiAqLw0KKwlpZiAocm5oID09 IE5VTEwpIHsNCisJCVZfcnRzdGF0LnJ0c191bnJlYWNoKys7DQorCQlyZXR1 cm4gKDApOw0KKwl9DQorDQorCVJBRElYX05PREVfSEVBRF9STE9DSyhybmgs ICZ0cmFja2VyKTsNCisJcm4gPSBybmgtPnJuaF9tYXRjaGFkZHIoZHN0LCBy bmgpOw0KKwlpZiAocm4gIT0gTlVMTCAmJiAoKHJuLT5ybl9mbGFncyAmIFJO Rl9ST09UKSA9PSAwKSkgew0KKwkJLyogd2UgaGF2ZSBhIHJvdXRlIC0gbm93 IGRvIHRoZSBtcGF0aCBzZWxlY3Rpb24gKi8NCisJCWlmIChybl9tcGF0aF9u ZXh0KCBybikgIT0gTlVMTCkgeyAvKiBtdWx0aXBhdGggKi8NCisJCQlybjAg PSBybjsNCisNCisJCQkvKiBmaW5kIGxvd2VzdCB3ZWlnaHQgcm91dGUgKi8N CisJCQlmb3IgKCBydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKXJuLA0KKwkJCSAg ICB3ZWlnaHQgPSBydC0+cnRfcm14LnJteF93ZWlnaHQ7DQorCQkJICAgIHJu ICE9IE5VTEw7IHJuID0gcm5fbXBhdGhfbmV4dCggcm4pKSB7DQorCQkJCXJ0 ID0gKHN0cnVjdCBydGVudHJ5ICopcm47DQorCQkJCWlmKHJ0LT5ydF9mbGFn cyAmIFJURl9VUCkgew0KKwkJCQkJaWYgKHdlaWdodCA+IHJ0LT5ydF9ybXgu cm14X3dlaWdodCkgew0KKwkJCQkJCXdlaWdodCA9IHJ0LT5ydF9ybXgucm14 X3dlaWdodDsNCisJCQkJCQluID0gMTsNCisJCQkJCX0gZWxzZSBpZiAod2Vp Z2h0ID09IHJ0LT5ydF9ybXgucm14X3dlaWdodCkNCisJCQkJCQluKys7DQor CQkJCX0NCisJCQl9DQorCQkJbG93ZXN0X3dlaWdodCA9IHdlaWdodDsNCisN CisJCQkvKiBzZWxlY3Qgbm93IG9uZSBvZiB0aGUgbG93ZXN0IHdlaWdodCBy b3V0ZXMgKi8NCisJCQkvKiBndyBzZWxlY3Rpb24gYnkgTW9kdWxvLU4gSGFz aCAoUkZDMjk5MSkgWFhYIG5lZWQgaW1wcm92ZW1lbnQ/ICovDQorCQkJaGFz aCArPSBoYXNoaml0dGVyOw0KKwkJCWhhc2ggJT0gbjsNCisJCQlmb3IgKCBy biA9IHJuMCwgbiA9IDA7IHJuICE9IE5VTEw7IHJuID0gcm5fbXBhdGhfbmV4 dCggcm4pKSB7DQorCQkJCXJ0ID0gKHN0cnVjdCBydGVudHJ5ICopcm47DQor CQkJCWlmKHJ0LT5ydF9mbGFncyAmIFJURl9VUCkgew0KKwkJCQkJaWYgKCBy dC0+cnRfcm14LnJteF93ZWlnaHQgPT0gbG93ZXN0X3dlaWdodCkgew0KKwkJ CQkJCWlmIChuID09IGhhc2gpDQorCQkJCQkJCWJyZWFrOw0KKwkJCQkJCW4r KzsNCisJCQkJCX0NCisJCQkJfQ0KKwkJCX0NCisNCisJCQkvKiBndyBzZWxl Y3Rpb24gaGFzIGZhaWxlZCAtIHRoZXJlIG11c3QgYmUgb25seSB6ZXJvIHdl aWdodCByb3V0ZXMgKi8gICAgICAgICAgICAgICAgICAgDQorCQkJaWYgKCFy bikNCisJCQkJZ290byBlbmQ7DQorCQl9IGVsc2UNCisJCQlydCA9IChzdHJ1 Y3QgcnRlbnRyeSAqKXJuOw0KKw0KKwkJaWYoIHJ0LT5ydF9nYXRld2F5LT5z YV9sZW4gPiBydGwtPnJ0X2dhdGV3YXktPnNhX2xlbikgew0KKwkJCXVuc2ln bmVkIGNoYXIgc2FfbGVuID0gcnRsLT5ydF9nYXRld2F5LT5zYV9sZW47DQor CQkJYmNvcHkoIHJ0LT5ydF9nYXRld2F5LCBydGwtPnJ0X2dhdGV3YXksIHNh X2xlbik7DQorCQkJcnRsLT5ydF9nYXRld2F5LT5zYV9sZW4gPSBzYV9sZW47 DQorCQl9IGVsc2Ugew0KKwkJCXVuc2lnbmVkIGNoYXIgc2FfbGVuID0gcnQt PnJ0X2dhdGV3YXktPnNhX2xlbjsNCisJCQliY29weSggcnQtPnJ0X2dhdGV3 YXksIHJ0bC0+cnRfZ2F0ZXdheSwgc2FfbGVuKTsNCisJCQlydGwtPnJ0X2dh dGV3YXktPnNhX2xlbiA9IHNhX2xlbjsNCisJCX0NCisJCXJ0bC0+cnRfaWZw ID0gcnQtPnJ0X2lmcDsNCisJCXJ0bC0+cnRfaWZhID0gcnQtPnJ0X2lmYTsN CisJCXJ0bC0+cnRfcm14LnJteF9tdHUgPSBydC0+cnRfcm14LnJteF9tdHU7 DQorCQlydGwtPnJ0X3JteC5ybXhfZXhwaXJlID0gcnQtPnJ0X3JteC5ybXhf ZXhwaXJlOw0KKwkJcnRsLT5ydF9mbGFncyA9IHJ0LT5ydF9mbGFnczsNCisJ CWlmIChmbGFncyAmIFJUTF9QS1NFTlQpDQorCQkJcnQtPnJ0X3JteC5ybXhf cGtzZW50Kys7CS8qIHJhY3kgYnV0IG9rICovDQorCQlyZXQgPSAxOw0KKwl9 DQorZW5kOg0KKwlSQURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgsICZ0cmFj a2VyKTsNCisJcmV0dXJuIChyZXQpOw0KK30NCisjZW5kaWYNCisNCisvKg0K ICAqIFJlbW92ZSBhIHJlZmVyZW5jZSBjb3VudCBmcm9tIGFuIHJ0ZW50cnku DQogICogSWYgdGhlIGNvdW50IGdldHMgbG93IGVub3VnaCwgdGFrZSBpdCBv dXQgb2YgdGhlIHJvdXRpbmcgdGFibGUNCiAgKi8NCkBAIC04NzUsNyArMTAz Niw3IEBADQogCSAqIFJlbW92ZSB0aGUgaXRlbSBmcm9tIHRoZSB0cmVlOyBp dCBzaG91bGQgYmUgdGhlcmUsDQogCSAqIGJ1dCB3aGVuIGNhbGxlcnMgaW52 b2tlIHVzIGJsaW5kbHkgaXQgbWF5IG5vdCAoc2lnaCkuDQogCSAqLw0KLQly biA9IHJuaC0+cm5oX2RlbGFkZHIocnRfa2V5KHJ0KSwgcnRfbWFzayhydCks IHJuaCk7DQorCXJuID0gcm5oLT5ybmhfZGVsYWRkcihydF9rZXkocnQpLCBy dF9tYXNrKHJ0KSwgcm5oLCBOVUxMKTsNCiAJaWYgKHJuID09IE5VTEwpIHsN CiAJCWVycm9yID0gRVNSQ0g7DQogCQlnb3RvIGJhZDsNCkBAIC05MTMsMTEy ICsxMDc0LDYgQEANCiAJcmV0dXJuIChlcnJvcik7DQogfQ0KIA0KLSNpZmRl ZiBSQURJWF9NUEFUSA0KLXN0YXRpYyBpbnQNCi1ybl9tcGF0aF91cGRhdGUo aW50IHJlcSwgc3RydWN0IHJ0X2FkZHJpbmZvICppbmZvLA0KLSAgICBzdHJ1 Y3QgcmFkaXhfbm9kZV9oZWFkICpybmgsIHN0cnVjdCBydGVudHJ5ICoqcmV0 X25ydCkNCi17DQotCS8qDQotCSAqIGlmIHdlIGdvdCBtdWx0aXBhdGggcm91 dGVzLCB3ZSByZXF1aXJlIHVzZXJzIHRvIHNwZWNpZnkNCi0JICogYSBtYXRj aGluZyBSVEFYX0dBVEVXQVkuDQotCSAqLw0KLQlzdHJ1Y3QgcnRlbnRyeSAq cnQsICpydG8gPSBOVUxMOw0KLQlyZWdpc3RlciBzdHJ1Y3QgcmFkaXhfbm9k ZSAqcm47DQotCWludCBlcnJvciA9IDA7DQotDQotCXJuID0gcm5oLT5ybmhf bWF0Y2hhZGRyKGRzdCwgcm5oKTsNCi0JaWYgKHJuID09IE5VTEwpDQotCQly ZXR1cm4gKEVTUkNIKTsNCi0JcnRvID0gcnQgPSBSTlRPUlQocm4pOw0KLQly dCA9IHJ0X21wYXRoX21hdGNoZ2F0ZShydCwgZ2F0ZXdheSk7DQotCWlmIChy dCA9PSBOVUxMKQ0KLQkJcmV0dXJuIChFU1JDSCk7DQotCS8qDQotCSAqIHRo aXMgaXMgdGhlIGZpcnN0IGVudHJ5IGluIHRoZSBjaGFpbg0KLQkgKi8NCi0J aWYgKHJ0byA9PSBydCkgew0KLQkJcm4gPSBybl9tcGF0aF9uZXh0KChzdHJ1 Y3QgcmFkaXhfbm9kZSAqKXJ0KTsNCi0JCS8qDQotCQkgKiB0aGVyZSBpcyBh bm90aGVyIGVudHJ5LCBub3cgaXQncyBhY3RpdmUNCi0JCSAqLw0KLQkJaWYg KHJuKSB7DQotCQkJcnRvID0gUk5UT1JUKHJuKTsNCi0JCQlSVF9MT0NLKHJ0 byk7DQotCQkJcnRvLT5ydF9mbGFncyB8PSBSVEZfVVA7DQotCQkJUlRfVU5M T0NLKHJ0byk7DQotCQl9IGVsc2UgaWYgKHJ0LT5ydF9mbGFncyAmIFJURl9H QVRFV0FZKSB7DQotCQkJLyoNCi0JCQkgKiBGb3IgZ2F0ZXdheSByb3V0ZXMs IHdlIG5lZWQgdG8gDQotCQkJICogbWFrZSBzdXJlIHRoYXQgd2Ugd2UgYXJl IGRlbGV0aW5nDQotCQkJICogdGhlIGNvcnJlY3QgZ2F0ZXdheS4gDQotCQkJ ICogcnRfbXBhdGhfbWF0Y2hnYXRlKCkgZG9lcyBub3QgDQotCQkJICogY2hl Y2sgdGhlIGNhc2Ugd2hlbiB0aGVyZSBpcyBvbmx5DQotCQkJICogb25lIHJv dXRlIGluIHRoZSBjaGFpbi4gIA0KLQkJCSAqLw0KLQkJCWlmIChnYXRld2F5 ICYmDQotCQkJICAgIChydC0+cnRfZ2F0ZXdheS0+c2FfbGVuICE9IGdhdGV3 YXktPnNhX2xlbiB8fA0KLQkJCQltZW1jbXAocnQtPnJ0X2dhdGV3YXksIGdh dGV3YXksIGdhdGV3YXktPnNhX2xlbikpKQ0KLQkJCQllcnJvciA9IEVTUkNI Ow0KLQkJCWVsc2Ugew0KLQkJCQkvKg0KLQkJCQkgKiByZW1vdmUgZnJvbSB0 cmVlIGJlZm9yZSByZXR1cm5pbmcgaXQNCi0JCQkJICogdG8gdGhlIGNhbGxl cg0KLQkJCQkgKi8NCi0JCQkJcm4gPSBybmgtPnJuaF9kZWxhZGRyKGRzdCwg bmV0bWFzaywgcm5oKTsNCi0JCQkJS0FTU0VSVChydCA9PSBSTlRPUlQocm4p LCAoInJhZGl4IG5vZGUgZGlzYXBwZWFyZWQiKSk7DQotCQkJCWdvdG8gZ3dk ZWxldGU7DQotCQkJfQ0KLQkJCQ0KLQkJfQ0KLQkJLyoNCi0JCSAqIHVzZSB0 aGUgbm9ybWFsIGRlbGV0ZSBjb2RlIHRvIHJlbW92ZQ0KLQkJICogdGhlIGZp cnN0IGVudHJ5DQotCQkgKi8NCi0JCWlmIChyZXEgIT0gUlRNX0RFTEVURSkg DQotCQkJZ290byBub25kZWxldGU7DQotDQotCQllcnJvciA9IEVOT0VOVDsN Ci0JCWdvdG8gZG9uZTsNCi0JfQ0KLQkJDQotCS8qDQotCSAqIGlmIHRoZSBl bnRyeSBpcyAybmQgYW5kIG9uIHVwDQotCSAqLw0KLQlpZiAoKHJlcSA9PSBS VE1fREVMRVRFKSAmJiAhcnRfbXBhdGhfZGVsZHVwKHJ0bywgcnQpKQ0KLQkJ cGFuaWMgKCJydHJlcXVlc3QxOiBydF9tcGF0aF9kZWxkdXAiKTsNCi1nd2Rl bGV0ZToNCi0JUlRfTE9DSyhydCk7DQotCVJUX0FERFJFRihydCk7DQotCWlm IChyZXEgPT0gUlRNX0RFTEVURSkgew0KLQkJcnQtPnJ0X2ZsYWdzICY9IH5S VEZfVVA7DQotCQkvKg0KLQkJICogT25lIG1vcmUgcnRlbnRyeSBmbG9hdGlu ZyBhcm91bmQgdGhhdCBpcyBub3QNCi0JCSAqIGxpbmtlZCB0byB0aGUgcm91 dGluZyB0YWJsZS4gcnR0cmFzaCB3aWxsIGJlIGRlY3JlbWVudGVkDQotCQkg KiB3aGVuIFJURlJFRShydCkgaXMgZXZlbnR1YWxseSBjYWxsZWQuDQotCQkg Ki8NCi0JCVZfcnR0cmFzaCsrOw0KLQl9DQotCQ0KLW5vbmRlbGV0ZToNCi0J aWYgKHJlcSAhPSBSVE1fREVMRVRFKQ0KLQkJcGFuaWMoInVucmVjb2duaXpl ZCByZXF1ZXN0ICVkIiwgcmVxKTsNCi0JDQotDQotCS8qDQotCSAqIElmIHRo ZSBjYWxsZXIgd2FudHMgaXQsIHRoZW4gaXQgY2FuIGhhdmUgaXQsDQotCSAq IGJ1dCBpdCdzIHVwIHRvIGl0IHRvIGZyZWUgdGhlIHJ0ZW50cnkgYXMgd2Ug d29uJ3QgYmUNCi0JICogZG9pbmcgaXQuDQotCSAqLw0KLQlpZiAocmV0X25y dCkgew0KLQkJKnJldF9ucnQgPSBydDsNCi0JCVJUX1VOTE9DSyhydCk7DQot CX0gZWxzZQ0KLQkJUlRGUkVFX0xPQ0tFRChydCk7DQotZG9uZToNCi0JcmV0 dXJuIChlcnJvcik7DQotfQ0KLSNlbmRpZg0KLQ0KIGludA0KIHJ0cmVxdWVz dDFfZmliKGludCByZXEsIHN0cnVjdCBydF9hZGRyaW5mbyAqaW5mbywgc3Ry dWN0IHJ0ZW50cnkgKipyZXRfbnJ0LA0KIAkJCQl1X2ludCBmaWJudW0pDQpA QCAtMTAzMiw2ICsxMDg3LDcgQEANCiAJcmVnaXN0ZXIgc3RydWN0IHJhZGl4 X25vZGVfaGVhZCAqcm5oOw0KIAlzdHJ1Y3QgaWZhZGRyICppZmE7DQogCXN0 cnVjdCBzb2NrYWRkciAqbmRzdDsNCisJc3RydWN0IHJtX3ByaW90cmFja2Vy IHRyYWNrZXI7DQogI2RlZmluZSBzZW5kZXJyKHgpIHsgZXJyb3IgPSB4IDsg Z290byBiYWQ7IH0NCiANCiAJS0FTU0VSVCgoZmlibnVtIDwgcnRfbnVtZmli cyksICgicnRyZXF1ZXN0MV9maWI6IGJhZCBmaWJudW0iKSk7DQpAQCAtMTA0 OCw3ICsxMTA0LDcgQEANCiAJaWYgKG5lZWRsb2NrKQ0KIAkJUkFESVhfTk9E RV9IRUFEX0xPQ0socm5oKTsNCiAJZWxzZQ0KLQkJUkFESVhfTk9ERV9IRUFE X0xPQ0tfQVNTRVJUKHJuaCk7DQorCQlSQURJWF9OT0RFX0hFQURfUkxPQ0so cm5oLCAmdHJhY2tlcik7DQogCS8qDQogCSAqIElmIHdlIGFyZSBhZGRpbmcg YSBob3N0IHJvdXRlIHRoZW4gd2UgZG9uJ3Qgd2FudCB0byBwdXQNCiAJICog YSBuZXRtYXNrIGluIHRoZSB0cmVlLCBub3IgZG8gd2Ugd2FudCB0byBjbG9u ZSBpdC4NCkBAIC0xMDU4LDI4ICsxMTE0LDMwIEBADQogDQogCXN3aXRjaCAo cmVxKSB7DQogCWNhc2UgUlRNX0RFTEVURToNCisJCWlmICgocm4gPSBybmgt PnJuaF9sb29rdXAoZHN0LCBuZXRtYXNrLCBybmgpKSA9PSBOVUxMKQ0KKwkJ CXNlbmRlcnIoRVNSQ0gpOw0KKwkJcnQgPSBSTlRPUlQocm4pOw0KICNpZmRl ZiBSQURJWF9NUEFUSA0KKwkJLyoNCisJCSAqIGlmIHdlIGdvdCBtdWx0aXBh dGggcm91dGVzLCB3ZSByZXF1aXJlIHVzZXJzIHRvIHNwZWNpZnkNCisJCSAq IGEgbWF0Y2hpbmcgUlRBWF9HQVRFV0FZLg0KKwkJICovDQogCQlpZiAocm5f bXBhdGhfY2FwYWJsZShybmgpKSB7DQotCQkJZXJyb3IgPSBybl9tcGF0aF91 cGRhdGUocmVxLCBpbmZvLCBybmgsIHJldF9ucnQpOw0KLQkJCS8qDQotCQkJ ICogImJhZCIgaG9sZHMgdHJ1ZSBmb3IgdGhlIHN1Y2Nlc3MgY2FzZQ0KLQkJ CSAqIGFzIHdlbGwNCi0JCQkgKi8NCi0JCQlpZiAoZXJyb3IgIT0gRU5PRU5U KQ0KLQkJCQlnb3RvIGJhZDsNCi0JCQllcnJvciA9IDA7DQorCQkJcnQgPSBy dF9tcGF0aF9tYXRjaGdhdGUoIHJ0LCBnYXRld2F5KTsNCisJCQlybiA9IChz dHJ1Y3QgcmFkaXhfbm9kZSAqKXJ0Ow0KKwkJCWlmICghcnQpDQorCQkJCXNl bmRlcnIoRVNSQ0gpOw0KIAkJfQ0KICNlbmRpZg0KIAkJLyoNCiAJCSAqIFJl bW92ZSB0aGUgaXRlbSBmcm9tIHRoZSB0cmVlIGFuZCByZXR1cm4gaXQuDQog CQkgKiBDb21wbGFpbiBpZiBpdCBpcyBub3QgdGhlcmUgYW5kIGRvIG5vIG1v cmUgcHJvY2Vzc2luZy4NCiAJCSAqLw0KLQkJcm4gPSBybmgtPnJuaF9kZWxh ZGRyKGRzdCwgbmV0bWFzaywgcm5oKTsNCisJCXJuID0gcm5oLT5ybmhfZGVs YWRkcihkc3QsIG5ldG1hc2ssIHJuaCwgcm4pOw0KIAkJaWYgKHJuID09IE5V TEwpDQogCQkJc2VuZGVycihFU1JDSCk7DQogCQlpZiAocm4tPnJuX2ZsYWdz ICYgKFJORl9BQ1RJVkUgfCBSTkZfUk9PVCkpDQogCQkJcGFuaWMgKCJydHJl cXVlc3QgZGVsZXRlIik7DQotCQlydCA9IFJOVE9SVChybik7DQogCQlSVF9M T0NLKHJ0KTsNCiAJCVJUX0FERFJFRihydCk7DQogCQlydC0+cnRfZmxhZ3Mg Jj0gflJURl9VUDsNCkBAIC0xMjg1LDYgKzEzNDMsOCBAQA0KIGJhZDoNCiAJ aWYgKG5lZWRsb2NrKQ0KIAkJUkFESVhfTk9ERV9IRUFEX1VOTE9DSyhybmgp Ow0KKwllbHNlDQorCQlSQURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgsICZ0 cmFja2VyKTsNCiAJcmV0dXJuIChlcnJvcik7DQogI3VuZGVmIHNlbmRlcnIN CiB9DQpAQCAtMTMwOCw3ICsxMzY4LDkgQEANCiAjZW5kaWYNCiANCiAJUlRf TE9DS19BU1NFUlQocnQpOw0KKyNpZmRlZiBJTlZBUklBTlRTDQogCVJBRElY X05PREVfSEVBRF9MT0NLX0FTU0VSVChybmgpOw0KKyNlbmRpZg0KIAkNCiAJ LyoNCiAJICogUHJlcGFyZSB0byBzdG9yZSB0aGUgZ2F0ZXdheSBpbiBydC0+ cnRfZ2F0ZXdheS4NCkBAIC0xNDY0LDYgKzE1MjYsNyBAQA0KIAkJCQkJICAg IGlmYS0+aWZhX2FkZHIpOw0KIAkJCQkJaWYgKCFydCkNCiAJCQkJCQllcnJv ciA9IEVTUkNIOw0KKwkJCQkJcm4gPSAoc3RydWN0IHJhZGl4X25vZGUgKily dDsNCiAJCQkJfQ0KIAkJCX0NCiAJCQllbHNlDQpkaWZmIC11IC1yIC4uL3Ny Y19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXQvcm91dGUuaCAuL3N5cy9uZXQv cm91dGUuaA0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXQv cm91dGUuaAkyMDEwLTA0LTAyIDA1OjEyOjQ2LjAwMDAwMDAwMCArMDAwMA0K KysrIC4vc3lzL25ldC9yb3V0ZS5oCTIwMTEtMDQtMDYgMjA6Mzc6NDguMDAw MDAwMDAwICswMDAwDQpAQCAtNzksNiArNzksMzkgQEANCiB9Ow0KIA0KIC8q DQorICogUG9pbnRlcnMgdG8gc3RydWN0dXJlcyBvbiB0aGUgc3RhY2sgZm9y IHB1cmUgcm91dGluZw0KKyAqIHRhYmxlIGxvb2t1cHMgLyBmYXN0IG10dSBh Y2Nlc3MuDQorICogRmFrZXMgc3RydWN0IHJ0X21ldHJpY3NfbGl0ZQ0KKyAq Lw0KK3N0cnVjdCBydGxvb2t1cF9tZXRyaWNzIHsNCisJdV9sb25nICBybXhf bXR1OyAgICAgICAgLyogTVRVIGZvciB0aGlzIHBhdGggKi8NCisJdV9sb25n ICBybXhfZXhwaXJlOyAgICAgLyogWFhYIHJlYXJhbmdlIHJ0X21ldHJpY3Nf bGl0ZSAqLw0KKwl1X2xvbmcgIHJteF9wa3NlbnQ7ICAgICAvKiBYWFggZmFz dGVyIHRoYW4gZXh0cmEgaWY/IC0gcmVtb3ZlPyAqLw0KK307DQorDQorLyoN CisgKiBQb2ludGVycyB0byBzdHJ1Y3R1cmVzIG9uIHRoZSBzdGFjayBmb3Ig cHVyZSByb3V0aW5nDQorICogdGFibGUgbG9va3Vwcy4gDQorICogRmFrZXMg c3RydWN0IHJ0ZW50cnkNCisgKi8NCisjaWZuZGVmIFJORl9OT1JNQUwNCisj aW5jbHVkZSA8bmV0L3JhZGl4Lmg+DQorI2lmZGVmIFJBRElYX01QQVRIDQor I2luY2x1ZGUgPG5ldC9yYWRpeF9tcGF0aC5oPg0KKyNlbmRpZg0KKyNlbmRp Zg0KK3N0cnVjdCBydGxvb2t1cCB7DQorICAgICAgIHN0cnVjdCAgcmFkaXhf bm9kZSBydF9ub2Rlc1syXTsgICAgICAgICAvKiBYWFggcmVhcmFuZ2UgcnRl bnRyeSBhbmQgcmVtb3ZlICovDQorICAgICAgIHN0cnVjdCAgc29ja2FkZHIg KnJ0X2dhdGV3YXk7DQorICAgICAgIGludCAgICAgcnRfZmxhZ3M7DQorICAg ICAgIGludCAgICAgcnRfcmVmY250OyAgICAgICAgICAgICAgICAgICAgICAv KiBYWFggcmVhcmFuZ2UgcnRlbnRyeSBhbmQgcmVtb3ZlICovDQorICAgICAg IHN0cnVjdCAgaWZuZXQgKnJ0X2lmcDsNCisgICAgICAgc3RydWN0ICBpZmFk ZHIgKnJ0X2lmYTsNCisgICAgICAgc3RydWN0ICBydGxvb2t1cF9tZXRyaWNz IHJ0X3JteDsNCit9Ow0KKyNkZWZpbmUgICAgICAgIFJUTF9QS1NFTlQgICAg ICAweDAwMDEgIC8qIGluY3JlbWVudCBwYWNrZXQgc2VudCBjb3VudGVyICov DQorDQorLyoNCiAgKiBybXhfcnR0IGFuZCBybXhfcnR0dmFyIGFyZSBzdG9y ZWQgYXMgbWljcm9zZWNvbmRzOw0KICAqIFJUVFRPUFJIWihydHQpIGNvbnZl cnRzIHRvIGEgdmFsdWUgc3VpdGFibGUgZm9yIHVzZQ0KICAqIGJ5IGEgcHJv dG9jb2wgc2xvd3RpbW8gY291bnRlci4NCkBAIC0xMjMsMTIgKzE1Niw2IEBA DQogICogZ2F0ZXdheXMgYXJlIG1hcmtlZCBzbyB0aGF0IHRoZSBvdXRwdXQg cm91dGluZXMga25vdyB0byBhZGRyZXNzIHRoZQ0KICAqIGdhdGV3YXkgcmF0 aGVyIHRoYW4gdGhlIHVsdGltYXRlIGRlc3RpbmF0aW9uLg0KICAqLw0KLSNp Zm5kZWYgUk5GX05PUk1BTA0KLSNpbmNsdWRlIDxuZXQvcmFkaXguaD4NCi0j aWZkZWYgUkFESVhfTVBBVEgNCi0jaW5jbHVkZSA8bmV0L3JhZGl4X21wYXRo Lmg+DQotI2VuZGlmDQotI2VuZGlmDQogc3RydWN0IHJ0ZW50cnkgew0KIAlz dHJ1Y3QJcmFkaXhfbm9kZSBydF9ub2Rlc1syXTsJLyogdHJlZSBnbHVlLCBh bmQgb3RoZXIgdmFsdWVzICovDQogCS8qDQpAQCAtNDMwLDYgKzQ1NywxMCBA QA0KIHZvaWQJIHJ0YWxsb2NfZmliKHN0cnVjdCByb3V0ZSAqcm8sIHVfaW50 IGZpYm51bSk7DQogc3RydWN0IHJ0ZW50cnkgKnJ0YWxsb2MxX2ZpYihzdHJ1 Y3Qgc29ja2FkZHIgKiwgaW50LCB1X2xvbmcsIHVfaW50KTsNCiBpbnQJIHJ0 aW9jdGxfZmliKHVfbG9uZywgY2FkZHJfdCwgdV9pbnQpOw0KK2ludCAgICBy dGxvb2t1cF9maWIoc3RydWN0IHNvY2thZGRyICosIHVfaW50LCBzdHJ1Y3Qg cnRsb29rdXAgKiwgaW50KTsNCisjaWZkZWYgUkFESVhfTVBBVEgNCitpbnQg ICAgcnRsb29rdXBfbXBhdGhfZmliKHN0cnVjdCBzb2NrYWRkciAqLCB1X2lu dDMyX3QsIHVfaW50LCBzdHJ1Y3QgcnRsb29rdXAgKiwgaW50KTsNCisjZW5k aWYNCiB2b2lkCSBydHJlZGlyZWN0X2ZpYihzdHJ1Y3Qgc29ja2FkZHIgKiwg c3RydWN0IHNvY2thZGRyICosDQogCSAgICBzdHJ1Y3Qgc29ja2FkZHIgKiwg aW50LCBzdHJ1Y3Qgc29ja2FkZHIgKiwgdV9pbnQpOw0KIGludAkgcnRyZXF1 ZXN0X2ZpYihpbnQsIHN0cnVjdCBzb2NrYWRkciAqLA0KZGlmZiAtdSAtciAu Li9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMvbmV0L3J0c29jay5jIC4vc3lz L25ldC9ydHNvY2suYw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5 cy9uZXQvcnRzb2NrLmMJMjAxMC0xMC0zMCAxMTo1NDo1NS4wMDAwMDAwMDAg KzAwMDANCisrKyAuL3N5cy9uZXQvcnRzb2NrLmMJMjAxMS0wNC0wMyAxNjow Nzo1Ny4wMDAwMDAwMDAgKzAwMDANCkBAIC01MSw2ICs1MSw3IEBADQogI2lu Y2x1ZGUgPHN5cy9zb2NrZXR2YXIuaD4NCiAjaW5jbHVkZSA8c3lzL3N5c2N0 bC5oPg0KICNpbmNsdWRlIDxzeXMvc3lzdG0uaD4NCisjaW5jbHVkZSA8c3lz L3JtbG9jay5oPg0KIA0KICNpbmNsdWRlIDxuZXQvaWYuaD4NCiAjaW5jbHVk ZSA8bmV0L2lmX2RsLmg+DQpAQCAtNTEzLDYgKzUxNCw3IEBADQogCWludCBs ZW4sIGVycm9yID0gMDsNCiAJc3RydWN0IGlmbmV0ICppZnAgPSBOVUxMOw0K IAl1bmlvbiBzb2NrYWRkcl91bmlvbiBzYXVuOw0KKwlzdHJ1Y3Qgcm1fcHJp b3RyYWNrZXIgdHJhY2tlcjsNCiANCiAjZGVmaW5lIHNlbmRlcnIoZSkgeyBl cnJvciA9IGU7IGdvdG8gZmx1c2g7fQ0KIAlpZiAobSA9PSBOVUxMIHx8ICgo bS0+bV9sZW4gPCBzaXplb2YobG9uZykpICYmDQpAQCAtNjQzLDExICs2NDUs MTEgQEANCiAJCSAgICBpbmZvLnJ0aV9pbmZvW1JUQVhfRFNUXS0+c2FfZmFt aWx5KTsNCiAJCWlmIChybmggPT0gTlVMTCkNCiAJCQlzZW5kZXJyKEVBRk5P U1VQUE9SVCk7DQotCQlSQURJWF9OT0RFX0hFQURfUkxPQ0socm5oKTsNCisJ CVJBRElYX05PREVfSEVBRF9STE9DSyhybmgsICZ0cmFja2VyKTsNCiAJCXJ0 ID0gKHN0cnVjdCBydGVudHJ5ICopIHJuaC0+cm5oX2xvb2t1cChpbmZvLnJ0 aV9pbmZvW1JUQVhfRFNUXSwNCiAJCQlpbmZvLnJ0aV9pbmZvW1JUQVhfTkVU TUFTS10sIHJuaCk7DQogCQlpZiAocnQgPT0gTlVMTCkgewkvKiBYWFggbG9v a3MgYm9ndXMgKi8NCi0JCQlSQURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgp Ow0KKwkJCVJBRElYX05PREVfSEVBRF9SVU5MT0NLKHJuaCwgJnRyYWNrZXIp Ow0KIAkJCXNlbmRlcnIoRVNSQ0gpOw0KIAkJfQ0KICNpZmRlZiBSQURJWF9N UEFUSA0KQEAgLTY2Myw3ICs2NjUsNyBAQA0KIAkJICAgIChydG0tPnJ0bV90 eXBlICE9IFJUTV9HRVQgfHwgaW5mby5ydGlfaW5mb1tSVEFYX0dBVEVXQVld KSkgew0KIAkJCXJ0ID0gcnRfbXBhdGhfbWF0Y2hnYXRlKHJ0LCBpbmZvLnJ0 aV9pbmZvW1JUQVhfR0FURVdBWV0pOw0KIAkJCWlmICghcnQpIHsNCi0JCQkJ UkFESVhfTk9ERV9IRUFEX1JVTkxPQ0socm5oKTsNCisJCQkJUkFESVhfTk9E RV9IRUFEX1JVTkxPQ0socm5oLCAmdHJhY2tlcik7DQogCQkJCXNlbmRlcnIo RVNSQ0gpOw0KIAkJCX0NCiAJCX0NCkBAIC02OTUsMTMgKzY5NywxMyBAQA0K IAkJCSAqLw0KIAkJCXJ0ID0gKHN0cnVjdCBydGVudHJ5ICopcm5oLT5ybmhf bWF0Y2hhZGRyKCZsYWRkciwgcm5oKTsNCiAJCQlpZiAocnQgPT0gTlVMTCkg ew0KLQkJCQlSQURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgpOw0KKwkJCQlS QURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgsICZ0cmFja2VyKTsNCiAJCQkJ c2VuZGVycihFU1JDSCk7DQogCQkJfQ0KIAkJfSANCiAJCVJUX0xPQ0socnQp Ow0KIAkJUlRfQUREUkVGKHJ0KTsNCi0JCVJBRElYX05PREVfSEVBRF9SVU5M T0NLKHJuaCk7DQorCQlSQURJWF9OT0RFX0hFQURfUlVOTE9DSyhybmgsICZ0 cmFja2VyKTsNCiANCiAJCS8qIA0KIAkJICogRml4IGZvciBQUjogODI5NzQN CmRpZmYgLXUgLXIgLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL25ldGlu ZXQvaWNtcF92YXIuaCAuL3N5cy9uZXRpbmV0L2ljbXBfdmFyLmgNCi0tLSAu Li9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldC9pY21wX3Zhci5o CTIwMDktMDgtMDMgMDg6MTM6MDYuMDAwMDAwMDAwICswMDAwDQorKysgLi9z eXMvbmV0aW5ldC9pY21wX3Zhci5oCTIwMTEtMDQtMDMgMTY6MDc6NTcuMDAw MDAwMDAwICswMDAwDQpAQCAtMTAyLDcgKzEwMiwxMSBAQA0KICNkZWZpbmUg QkFORExJTV9SU1RfQ0xPU0VEUE9SVCAzIC8qIE5vIGNvbm5lY3Rpb24sIGFu ZCBubyBsaXN0ZW5lcnMgKi8NCiAjZGVmaW5lIEJBTkRMSU1fUlNUX09QRU5Q T1JUIDQgICAvKiBObyBjb25uZWN0aW9uLCBsaXN0ZW5lciAqLw0KICNkZWZp bmUgQkFORExJTV9JQ01QNl9VTlJFQUNIIDUNCi0jZGVmaW5lIEJBTkRMSU1f TUFYIDUNCisjZGVmaW5lIEJBTkRMSU1fSUNNUF9GV0RfVU5SRUFDSCA2IC8q IGZvcndhcmRpbmc6IGxpbWl0IHVucmVhY2hhYmxlICovDQorI2RlZmluZSBC QU5ETElNX0lDTVBfRldEX1RJTVhDRUVEIDcgLyogZm9yd2FyZGluZzogbGlt aXQgdGltZS1leGNlZWRlZCAqLw0KKyNkZWZpbmUgQkFORExJTV9JQ01QX0ZX RF9ORUVERlJBRyA4IC8qIGZvcndhcmRpbmc6IGxpbWl0IG5lZWQtZnJhZyAq Lw0KKyNkZWZpbmUgQkFORExJTV9JQ01QX0ZXRF9GSUxURVIgOSAvKiBmb3J3 YXJkaW5nOiBsaW1pdCBhZG1pbi1wcm9oaWIgKi8NCisjZGVmaW5lIEJBTkRM SU1fTUFYIDkNCiAjZW5kaWYNCiANCiAjZW5kaWYNCmRpZmYgLXUgLXIgLi4v c3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL25ldGluZXQvaW4uYyAuL3N5cy9u ZXRpbmV0L2luLmMNCi0tLSAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMv bmV0aW5ldC9pbi5jCTIwMTEtMDQtMTIgMTM6MDI6MDIuMDAwMDAwMDAwICsw MDAwDQorKysgLi9zeXMvbmV0aW5ldC9pbi5jCTIwMTEtMDQtMTQgMTY6MjI6 NDEuMDAwMDAwMDAwICswMDAwDQpAQCAtMTM5MywxMiArMTM5MywyMiBAQA0K IGluX2xsdGFibGVfcnRjaGVjayhzdHJ1Y3QgaWZuZXQgKmlmcCwgdV9pbnQg ZmxhZ3MsIGNvbnN0IHN0cnVjdCBzb2NrYWRkciAqbDNhZGRyKQ0KIHsNCiAJ c3RydWN0IHJ0ZW50cnkgKnJ0Ow0KKyNpZmRlZiBSQURJWF9NUEFUSA0KKwlz dHJ1Y3Qgcm91dGUgcm87DQorI2VuZGlmDQogDQogCUtBU1NFUlQobDNhZGRy LT5zYV9mYW1pbHkgPT0gQUZfSU5FVCwNCiAJICAgICgic2luX2ZhbWlseSAl ZCIsIGwzYWRkci0+c2FfZmFtaWx5KSk7DQogDQorI2lmZGVmIFJBRElYX01Q QVRIDQorCWJ6ZXJvKCAmcm8sIHNpemVvZihybykpOw0KKwliY29weSggX19E RUNPTlNUKHN0cnVjdCBzb2NrYWRkciAqLCBsM2FkZHIpLCAmcm8ucm9fZHN0 LCBzaXplb2Yoc3RydWN0IHNvY2thZGRyKSk7DQorCXJ0YWxsb2NfbXBhdGhf ZmliX2ZsYWdzKCAoc3RydWN0IHJvdXRlICopJnJvLCBSVEZfQU5OT1VOQ0Us IDAsIFJURl9HQVRFV0FZKTsNCisJcnQgPSByby5yb19ydDsNCisjZWxzZQ0K IAkvKiBYWFggcnRhbGxvYzEgc2hvdWxkIHRha2UgYSBjb25zdCBwYXJhbSAq Lw0KIAlydCA9IHJ0YWxsb2MxKF9fREVDT05TVChzdHJ1Y3Qgc29ja2FkZHIg KiwgbDNhZGRyKSwgMCwgMCk7DQorI2VuZGlmDQogCWlmIChydCA9PSBOVUxM IHx8ICghKGZsYWdzICYgTExFX1BVQikgJiYNCiAJCQkgICAoKHJ0LT5ydF9m bGFncyAmIFJURl9HQVRFV0FZKSB8fCANCiAJCQkgICAgKHJ0LT5ydF9pZnAg IT0gaWZwKSkpKSB7DQpAQCAtMTQwNiwxMSArMTQxNiwyMCBAQA0KIAkJbG9n KExPR19JTkZPLCAiSVB2NCBhZGRyZXNzOiBcIiVzXCIgaXMgbm90IG9uIHRo ZSBuZXR3b3JrXG4iLA0KIAkJICAgIGluZXRfbnRvYSgoKGNvbnN0IHN0cnVj dCBzb2NrYWRkcl9pbiAqKWwzYWRkciktPnNpbl9hZGRyKSk7DQogI2VuZGlm DQorI2lmZGVmIFJBRElYX01QQVRIDQorCQlpZiAocnQgIT0gTlVMTCkNCisJ CQlSVEZSRUUocnQpOw0KKyNlbHNlDQogCQlpZiAocnQgIT0gTlVMTCkNCiAJ CQlSVEZSRUVfTE9DS0VEKHJ0KTsNCisjZW5kaWYNCiAJCXJldHVybiAoRUlO VkFMKTsNCiAJfQ0KKyNpZmRlZiBSQURJWF9NUEFUSA0KKwlSVEZSRUUocnQp Ow0KKyNlbHNlDQogCVJURlJFRV9MT0NLRUQocnQpOw0KKyNlbmRpZg0KIAly ZXR1cm4gMDsNCiB9DQogDQpkaWZmIC11IC1yIC4uL3NyY19vcmdfOC4yXzIw MTEwMzI5L3N5cy9uZXRpbmV0L2luX3JteC5jIC4vc3lzL25ldGluZXQvaW5f cm14LmMNCi0tLSAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5l dC9pbl9ybXguYwkyMDEwLTEwLTExIDExOjI1OjM3LjAwMDAwMDAwMCArMDAw MA0KKysrIC4vc3lzL25ldGluZXQvaW5fcm14LmMJMjAxMS0wNC0xNCAxNjoy MzoxMy4wMDAwMDAwMDAgKzAwMDANCkBAIC01MSw2ICs1MSw4IEBADQogI2lu Y2x1ZGUgPHN5cy9tYnVmLmg+DQogI2luY2x1ZGUgPHN5cy9zeXNsb2cuaD4N CiAjaW5jbHVkZSA8c3lzL2NhbGxvdXQuaD4NCisjaW5jbHVkZSA8c3lzL2xv Y2suaD4NCisjaW5jbHVkZSA8c3lzL3JtbG9jay5oPg0KIA0KICNpbmNsdWRl IDxuZXQvaWYuaD4NCiAjaW5jbHVkZSA8bmV0L3JvdXRlLmg+DQpkaWZmIC11 IC1yIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpbmV0L2lwX2Zh c3Rmd2QuYyAuL3N5cy9uZXRpbmV0L2lwX2Zhc3Rmd2QuYw0KLS0tIC4uL3Ny Y19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpbmV0L2lwX2Zhc3Rmd2QuYwky MDEwLTEyLTEwIDE0OjA2OjUwLjAwMDAwMDAwMCArMDAwMA0KKysrIC4vc3lz L25ldGluZXQvaXBfZmFzdGZ3ZC5jCTIwMTEtMDQtMDcgMDI6MjQ6MDEuMDAw MDAwMDAwICswMDAwDQpAQCAtOTQsNiArOTQsOSBAQA0KICNpbmNsdWRlIDxu ZXQvaWZfdmFyLmg+DQogI2luY2x1ZGUgPG5ldC9pZl9kbC5oPg0KICNpbmNs dWRlIDxuZXQvcm91dGUuaD4NCisjaWZkZWYgUkFESVhfTVBBVEgNCisjaW5j bHVkZSA8bmV0L3JhZGl4X21wYXRoLmg+DQorI2VuZGlmDQogI2luY2x1ZGUg PG5ldC92bmV0Lmg+DQogDQogI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4NCkBA IC0xMDIsNiArMTA1LDcgQEANCiAjaW5jbHVkZSA8bmV0aW5ldC9pcC5oPg0K ICNpbmNsdWRlIDxuZXRpbmV0L2lwX3Zhci5oPg0KICNpbmNsdWRlIDxuZXRp bmV0L2lwX2ljbXAuaD4NCisjaW5jbHVkZSA8bmV0aW5ldC9pY21wX3Zhci5o Pg0KICNpbmNsdWRlIDxuZXRpbmV0L2lwX29wdGlvbnMuaD4NCiANCiAjaW5j bHVkZSA8bWFjaGluZS9pbl9ja3N1bS5oPg0KQEAgLTExMyw3ICsxMTcsMTEg QEANCiAgICAgJlZORVRfTkFNRShpcGZhc3Rmb3J3YXJkX2FjdGl2ZSksIDAs ICJFbmFibGUgZmFzdCBJUCBmb3J3YXJkaW5nIik7DQogDQogc3RhdGljIHN0 cnVjdCBzb2NrYWRkcl9pbiAqDQotaXBfZmluZHJvdXRlKHN0cnVjdCByb3V0 ZSAqcm8sIHN0cnVjdCBpbl9hZGRyIGRlc3QsIHN0cnVjdCBtYnVmICptKQ0K KyNpZmRlZiBSQURJWF9NUEFUSA0KK2lwX2ZpbmRyb3V0ZShzdHJ1Y3Qgcm91 dGUgKnJvLCB1aW50MzJfdCBoYXNoLCBzdHJ1Y3QgaW5fYWRkciBkZXN0LCBz dHJ1Y3QgbWJ1ZiAqbSwgc3RydWN0IHJ0bG9va3VwICpydGwpDQorI2Vsc2UN CitpcF9maW5kcm91dGUoc3RydWN0IHJvdXRlICpybywgc3RydWN0IGluX2Fk ZHIgZGVzdCwgc3RydWN0IG1idWYgKm0sIHN0cnVjdCBydGxvb2t1cCAqcnRs KQ0KKyNlbmRpZg0KIHsNCiAJc3RydWN0IHNvY2thZGRyX2luICpkc3Q7DQog CXN0cnVjdCBydGVudHJ5ICpydDsNCkBAIC0xMjYsNyArMTM0LDE2IEBADQog CWRzdC0+c2luX2ZhbWlseSA9IEFGX0lORVQ7DQogCWRzdC0+c2luX2xlbiA9 IHNpemVvZigqZHN0KTsNCiAJZHN0LT5zaW5fYWRkci5zX2FkZHIgPSBkZXN0 LnNfYWRkcjsNCi0JaW5fcnRhbGxvY19pZ24ocm8sIDAsIE1fR0VURklCKG0p KTsNCisNCisjaWZkZWYgUkFESVhfTVBBVEgNCisJaWYgKCFydGxvb2t1cF9t cGF0aF9maWIoKHN0cnVjdCBzb2NrYWRkciAqKWRzdCwNCisJCQloYXNoLCBN X0dFVEZJQihtKSwgIHJ0bCwgUlRMX1BLU0VOVCkpDQorI2Vsc2UNCisJaWYg KCFydGxvb2t1cF9maWIoIChzdHJ1Y3Qgc29ja2FkZHIgKilkc3QsIE1fR0VU RklCKG0pLCBydGwsIFJUTF9QS1NFTlQpKQ0KKyNlbmRpZg0KKwkJcm8tPnJv X3J0ID0gTlVMTDsNCisJZWxzZQ0KKwkJcm8tPnJvX3J0ID0gKHN0cnVjdCBy dGVudHJ5ICopcnRsOw0KIA0KIAkvKg0KIAkgKiBSb3V0ZSB0aGVyZSBhbmQg aW50ZXJmYWNlIHN0aWxsIHVwPw0KQEAgLTE0MCw5ICsxNTcsMTAgQEANCiAJ fSBlbHNlIHsNCiAJCUlQU1RBVF9JTkMoaXBzX25vcm91dGUpOw0KIAkJSVBT VEFUX0lOQyhpcHNfY2FudGZvcndhcmQpOw0KLQkJaWYgKHJ0KQ0KLQkJCVJU RlJFRShydCk7DQotCQlpY21wX2Vycm9yKG0sIElDTVBfVU5SRUFDSCwgSUNN UF9VTlJFQUNIX0hPU1QsIDAsIDApOw0KKwkJaWYgKGJhZHBvcnRfYmFuZGxp bShCQU5ETElNX0lDTVBfRldEX1VOUkVBQ0gpIDwgMCkNCisJCQltX2ZyZWVt KG0pOw0KKwkJZWxzZQ0KKwkJCWljbXBfZXJyb3IobSwgSUNNUF9VTlJFQUNI LCBJQ01QX1VOUkVBQ0hfSE9TVCwgMCwgMCk7DQogCQlyZXR1cm4gTlVMTDsN CiAJfQ0KIAlyZXR1cm4gZHN0Ow0KQEAgLTE2Nyw2ICsxODUsOCBAQA0KIAl1 X3Nob3J0IHN1bSwgaXBfbGVuOw0KIAlpbnQgZXJyb3IgPSAwOw0KIAlpbnQg aGxlbiwgbXR1Ow0KKwlzdHJ1Y3QgcnRsb29rdXAgcnRsOw0KKwlzdHJ1Y3Qg c29ja2FkZHJfZGwgZ2F0ZXdheTsNCiAjaWZkZWYgSVBGSVJFV0FMTF9GT1JX QVJEDQogCXN0cnVjdCBtX3RhZyAqZndkX3RhZzsNCiAjZW5kaWYNCkBAIC0y OTksOCArMzE5LDExIEBADQogCQlpZiAoaXBfZG9vcHRzID09IDEpDQogCQkJ cmV0dXJuIG07DQogCQllbHNlIGlmIChpcF9kb29wdHMgPT0gMikgew0KLQkJ CWljbXBfZXJyb3IobSwgSUNNUF9VTlJFQUNILCBJQ01QX1VOUkVBQ0hfRklM VEVSX1BST0hJQiwNCi0JCQkJMCwgMCk7DQorCQkJaWYgKGJhZHBvcnRfYmFu ZGxpbShCQU5ETElNX0lDTVBfRldEX0ZJTFRFUikgPCAwKQ0KKwkJCQltX2Zy ZWVtKG0pOw0KKwkJCWVsc2UNCisJCQkJaWNtcF9lcnJvcihtLCBJQ01QX1VO UkVBQ0gsDQorCQkJCQlJQ01QX1VOUkVBQ0hfRklMVEVSX1BST0hJQiwgMCwg MCk7DQogCQkJcmV0dXJuIE5VTEw7CS8qIG1idWYgYWxyZWFkeSBmcmVlJ2Qg Ki8NCiAJCX0NCiAJCS8qIGVsc2UgaWdub3JlIElQIG9wdGlvbnMgYW5kIGNv bnRpbnVlICovDQpAQCAtMzk5LDcgKzQyMiwxMSBAQA0KIAlpZiAoIVZfaXBz dGVhbHRoKSB7DQogI2VuZGlmDQogCWlmIChpcC0+aXBfdHRsIDw9IElQVFRM REVDKSB7DQotCQlpY21wX2Vycm9yKG0sIElDTVBfVElNWENFRUQsIElDTVBf VElNWENFRURfSU5UUkFOUywgMCwgMCk7DQorCQlpZiAoYmFkcG9ydF9iYW5k bGltKEJBTkRMSU1fSUNNUF9GV0RfVElNWENFRUQpIDwgMCkNCisJCQltX2Zy ZWVtKG0pOw0KKwkJZWxzZQ0KKwkJCWljbXBfZXJyb3IobSwgSUNNUF9USU1Y Q0VFRCwgSUNNUF9USU1YQ0VFRF9JTlRSQU5TLA0KKwkJCQkwLCAwKTsNCiAJ CXJldHVybiBOVUxMOwkvKiBtYnVmIGFscmVhZHkgZnJlZSdkICovDQogCX0N CiANCkBAIC00MjAsNyArNDQ3LDE2IEBADQogCS8qDQogCSAqIEZpbmQgcm91 dGUgdG8gZGVzdGluYXRpb24uDQogCSAqLw0KLQlpZiAoKGRzdCA9IGlwX2Zp bmRyb3V0ZSgmcm8sIGRlc3QsIG0pKSA9PSBOVUxMKQ0KKwliemVybyggJmdh dGV3YXksIHNpemVvZihnYXRld2F5KSk7DQorCWdhdGV3YXkuc2RsX2xlbiA9 IHNpemVvZihnYXRld2F5KTsNCisJcnRsLnJ0X2dhdGV3YXkgPSAoc3RydWN0 IHNvY2thZGRyICopJmdhdGV3YXk7DQorI2lmZGVmIFJBRElYX01QQVRIDQor CWlmICgoZHN0ID0gaXBfZmluZHJvdXRlKCZybywgbnRvaGwoaXAtPmlwX3Ny Yy5zX2FkZHIgXiBpcC0+aXBfZHN0LnNfYWRkciksDQorCQkJZGVzdCwgbSwg JnJ0bCkpID09IE5VTEwpDQorI2Vsc2UNCisJaWYgKChkc3QgPSBpcF9maW5k cm91dGUoJnJvLA0KKwkJCWRlc3QsIG0sICZydGwpKSA9PSBOVUxMKQ0KKyNl bmRpZg0KIAkJcmV0dXJuIE5VTEw7CS8qIGljbXAgdW5yZWFjaCBhbHJlYWR5 IHNlbnQgKi8NCiAJaWZwID0gcm8ucm9fcnQtPnJ0X2lmcDsNCiANCkBAIC00 NzYsOCArNTEyLDYgQEANCiAJCQkgKiAib3VycyItbGFiZWwuDQogCQkJICov DQogCQkJbS0+bV9mbGFncyB8PSBNX0ZBU1RGV0RfT1VSUzsNCi0JCQlpZiAo cm8ucm9fcnQpDQotCQkJCVJURlJFRShyby5yb19ydCk7DQogCQkJcmV0dXJu IG07DQogCQl9DQogCQkvKg0KQEAgLTQ5MCw4ICs1MjQsMTAgQEANCiAJCQlt X3RhZ19kZWxldGUobSwgZndkX3RhZyk7DQogCQl9DQogI2VuZGlmIC8qIElQ RklSRVdBTExfRk9SV0FSRCAqLw0KLQkJUlRGUkVFKHJvLnJvX3J0KTsNCi0J CWlmICgoZHN0ID0gaXBfZmluZHJvdXRlKCZybywgZGVzdCwgbSkpID09IE5V TEwpDQorCQliemVybyggJmdhdGV3YXksIHNpemVvZihnYXRld2F5KSk7DQor CQlnYXRld2F5LnNkbF9sZW4gPSBzaXplb2YoZ2F0ZXdheSk7DQorCQlydGwu cnRfZ2F0ZXdheSA9IChzdHJ1Y3Qgc29ja2FkZHIgKikmZ2F0ZXdheTsNCisJ CWlmICgoZHN0ID0gaXBfZmluZHJvdXRlKCZybywgZGVzdCwgbSwgJnJ0bCkp ID09IE5VTEwpDQogCQkJcmV0dXJuIE5VTEw7CS8qIGljbXAgdW5yZWFjaCBh bHJlYWR5IHNlbnQgKi8NCiAJCWlmcCA9IHJvLnJvX3J0LT5ydF9pZnA7DQog CX0NCkBAIC01MDcsNiArNTQzLDggQEANCiAJaWYgKChyby5yb19ydC0+cnRf ZmxhZ3MgJiBSVEZfUkVKRUNUKSAmJg0KIAkgICAgKHJvLnJvX3J0LT5ydF9y bXgucm14X2V4cGlyZSA9PSAwIHx8DQogCSAgICB0aW1lX3VwdGltZSA8IHJv LnJvX3J0LT5ydF9ybXgucm14X2V4cGlyZSkpIHsNCisJCWlmIChiYWRwb3J0 X2JhbmRsaW0oQkFORExJTV9JQ01QX0ZXRF9VTlJFQUNIKSA8IDApDQorCQkJ Z290byBkcm9wOw0KIAkJaWNtcF9lcnJvcihtLCBJQ01QX1VOUkVBQ0gsIElD TVBfVU5SRUFDSF9IT1NULCAwLCAwKTsNCiAJCWdvdG8gY29uc3VtZWQ7DQog CX0NCkBAIC01MjcsNiArNTY1LDggQEANCiAJICogQ2hlY2sgaWYgbWVkaWEg bGluayBzdGF0ZSBvZiBpbnRlcmZhY2UgaXMgbm90IGRvd24NCiAJICovDQog CWlmIChpZnAtPmlmX2xpbmtfc3RhdGUgPT0gTElOS19TVEFURV9ET1dOKSB7 DQorCQlpZiAoYmFkcG9ydF9iYW5kbGltKEJBTkRMSU1fSUNNUF9GV0RfVU5S RUFDSCkgPCAwKQ0KKwkJCWdvdG8gZHJvcDsNCiAJCWljbXBfZXJyb3IobSwg SUNNUF9VTlJFQUNILCBJQ01QX1VOUkVBQ0hfSE9TVCwgMCwgMCk7DQogCQln b3RvIGNvbnN1bWVkOw0KIAl9DQpAQCAtNTU3LDggKzU5Nyw5IEBADQogCQkg Ki8NCiAJCWlmIChpcC0+aXBfb2ZmICYgSVBfREYpIHsNCiAJCQlJUFNUQVRf SU5DKGlwc19jYW50ZnJhZyk7DQotCQkJaWNtcF9lcnJvcihtLCBJQ01QX1VO UkVBQ0gsIElDTVBfVU5SRUFDSF9ORUVERlJBRywNCi0JCQkJMCwgbXR1KTsN CisJCQlpZiAoYmFkcG9ydF9iYW5kbGltKEJBTkRMSU1fSUNNUF9GV0RfTkVF REZSQUcpIDwgMCkNCisJCQkJZ290byBkcm9wOw0KKwkJCWljbXBfZXJyb3Io bSwgSUNNUF9VTlJFQUNILCBJQ01QX1VOUkVBQ0hfTkVFREZSQUcsIDAsIG10 dSk7DQogCQkJZ290byBjb25zdW1lZDsNCiAJCX0gZWxzZSB7DQogCQkJLyoN CkBAIC02MDYsMTIgKzY0Nyw5IEBADQogCQlJUFNUQVRfSU5DKGlwc19mYXN0 Zm9yd2FyZCk7DQogCX0NCiBjb25zdW1lZDoNCi0JUlRGUkVFKHJvLnJvX3J0 KTsNCiAJcmV0dXJuIE5VTEw7DQogZHJvcDoNCiAJaWYgKG0pDQogCQltX2Zy ZWVtKG0pOw0KLQlpZiAocm8ucm9fcnQpDQotCQlSVEZSRUUocm8ucm9fcnQp Ow0KIAlyZXR1cm4gTlVMTDsNCiB9DQpkaWZmIC11IC1yIC4uL3NyY19vcmdf OC4yXzIwMTEwMzI5L3N5cy9uZXRpbmV0L2lwX2ljbXAuYyAuL3N5cy9uZXRp bmV0L2lwX2ljbXAuYw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5 cy9uZXRpbmV0L2lwX2ljbXAuYwkyMDEwLTA5LTIxIDIyOjMzOjMwLjAwMDAw MDAwMCArMDAwMA0KKysrIC4vc3lzL25ldGluZXQvaXBfaWNtcC5jCTIwMTEt MDQtMDQgMjM6MDE6NTcuMDAwMDAwMDAwICswMDAwDQpAQCAtOTU4LDcgKzk1 OCwxMSBAQA0KIAkJeyAiaWNtcCB0c3RhbXAgcmVzcG9uc2UiIH0sDQogCQl7 ICJjbG9zZWQgcG9ydCBSU1QgcmVzcG9uc2UiIH0sDQogCQl7ICJvcGVuIHBv cnQgUlNUIHJlc3BvbnNlIiB9LA0KLQkJeyAiaWNtcDYgdW5yZWFjaCByZXNw b25zZSIgfQ0KKwkJeyAiaWNtcDYgdW5yZWFjaCByZXNwb25zZSIgfSwNCisJ CXsgImZvcndhcmRpbmc6IGxpbWl0IHVucmVhY2hhYmxlIiB9LA0KKwkJeyAi Zm9yd2FyZGluZzogbGltaXQgdGltZS1leGNlZWRlZCIgfSwNCisJCXsgImZv cndhcmRpbmc6IGxpbWl0IG5lZWQtZnJhZyIgfSwNCisJCXsgImZvcndhcmRp bmc6IGxpbWl0IGFkbWluLXByb2hpYiIgfQ0KIAl9Ow0KIA0KIAkvKg0KZGlm ZiAtdSAtciAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldC9p cF9pbnB1dC5jIC4vc3lzL25ldGluZXQvaXBfaW5wdXQuYw0KLS0tIC4uL3Ny Y19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpbmV0L2lwX2lucHV0LmMJMjAx MS0wMy0yOCAxNToyNjo1Mi4wMDAwMDAwMDAgKzAwMDANCisrKyAuL3N5cy9u ZXRpbmV0L2lwX2lucHV0LmMJMjAxMS0wNC0xNCAxNjoyODoyMi4wMDAwMDAw MDAgKzAwMDANCkBAIC03MSw2ICs3MSw3IEBADQogI2luY2x1ZGUgPG5ldGlu ZXQvaXBfdmFyLmg+DQogI2luY2x1ZGUgPG5ldGluZXQvaXBfZncuaD4NCiAj aW5jbHVkZSA8bmV0aW5ldC9pcF9pY21wLmg+DQorI2luY2x1ZGUgPG5ldGlu ZXQvaWNtcF92YXIuaD4NCiAjaW5jbHVkZSA8bmV0aW5ldC9pcF9vcHRpb25z Lmg+DQogI2luY2x1ZGUgPG1hY2hpbmUvaW5fY2tzdW0uaD4NCiAjaW5jbHVk ZSA8bmV0aW5ldC9pcF9jYXJwLmg+DQpAQCAtMTM0OCwyMCArMTM0OSwyNCBA QA0KIAlzdHJ1Y3Qgcm91dGUgc3JvOw0KIAlzdHJ1Y3Qgc29ja2FkZHJfaW4g KnNpbjsNCiAJc3RydWN0IGluX2lmYWRkciAqaWE7DQorCXN0cnVjdCBydGxv b2t1cCBydGw7DQorCXN0cnVjdCBzb2NrYWRkcl9kbCBnYXRld2F5Ow0KIA0K IAliemVybygmc3JvLCBzaXplb2Yoc3JvKSk7DQogCXNpbiA9IChzdHJ1Y3Qg c29ja2FkZHJfaW4gKikmc3JvLnJvX2RzdDsNCiAJc2luLT5zaW5fZmFtaWx5 ID0gQUZfSU5FVDsNCiAJc2luLT5zaW5fbGVuID0gc2l6ZW9mKCpzaW4pOw0K IAlzaW4tPnNpbl9hZGRyID0gZHN0Ow0KLQlpbl9ydGFsbG9jX2lnbigmc3Jv LCAwLCBmaWJudW0pOw0KLQ0KLQlpZiAoc3JvLnJvX3J0ID09IE5VTEwpDQor CQ0KKwliemVybyggJmdhdGV3YXksIHNpemVvZihnYXRld2F5KSk7DQorCWdh dGV3YXkuc2RsX2xlbiA9IHNpemVvZihnYXRld2F5KTsNCisJcnRsLnJ0X2dh dGV3YXkgPSAoc3RydWN0IHNvY2thZGRyICopJmdhdGV3YXk7DQorCWlmICgh cnRsb29rdXBfZmliKCAoc3RydWN0IHNvY2thZGRyICopJnNyby5yb19kc3Qs DQorCQkJZmlibnVtLCAmcnRsLCAwKSkNCiAJCXJldHVybiAoTlVMTCk7DQog DQotCWlhID0gaWZhdG9pYShzcm8ucm9fcnQtPnJ0X2lmYSk7DQorCWlhID0g aWZhdG9pYShydGwucnRfaWZhKTsNCiAJaWZhX3JlZigmaWEtPmlhX2lmYSk7 DQotCVJURlJFRShzcm8ucm9fcnQpOw0KIAlyZXR1cm4gKGlhKTsNCiB9DQog DQpAQCAtMTM5Nyw2ICsxNDAyLDggQEANCiAJc3RydWN0IGluX2FkZHIgZGVz dDsNCiAJc3RydWN0IHJvdXRlIHJvOw0KIAlpbnQgZXJyb3IsIHR5cGUgPSAw LCBjb2RlID0gMCwgbXR1ID0gMDsNCisJaW50IGljbXBfc2VuZCA9IDA7DQor CXN0cnVjdCBydGxvb2t1cCBydGw7DQogDQogCWlmIChtLT5tX2ZsYWdzICYg KE1fQkNBU1R8TV9NQ0FTVCkgfHwgaW5fY2FuZm9yd2FyZChpcC0+aXBfZHN0 KSA9PSAwKSB7DQogCQlJUFNUQVRfSU5DKGlwc19jYW50Zm9yd2FyZCk7DQpA QCAtMTQwNyw4ICsxNDE0LDExIEBADQogCWlmICghVl9pcHN0ZWFsdGgpIHsN CiAjZW5kaWYNCiAJCWlmIChpcC0+aXBfdHRsIDw9IElQVFRMREVDKSB7DQot CQkJaWNtcF9lcnJvcihtLCBJQ01QX1RJTVhDRUVELCBJQ01QX1RJTVhDRUVE X0lOVFJBTlMsDQotCQkJICAgIDAsIDApOw0KKwkJCWlmIChiYWRwb3J0X2Jh bmRsaW0oQkFORExJTV9JQ01QX0ZXRF9USU1YQ0VFRCkgPCAwKQ0KKwkJCQlt X2ZyZWVtKG0pOw0KKwkJCWVsc2UNCisJCQkJaWNtcF9lcnJvcihtLCBJQ01Q X1RJTVhDRUVELCBJQ01QX1RJTVhDRUVEX0lOVFJBTlMsDQorCQkJCQkwLCAw KTsNCiAJCQlyZXR1cm47DQogCQl9DQogI2lmZGVmIElQU1RFQUxUSA0KQEAg LTE0MjMsNyArMTQzMywxMCBAQA0KIAkgKiBpcF9vdXRwdXQgaW4gY2FzZSBv ZiBvdXRnb2luZyBJUHNlYyBwb2xpY3kuDQogCSAqLw0KIAlpZiAoIXNyY3J0 ICYmIGlhID09IE5VTEwpIHsNCi0JCWljbXBfZXJyb3IobSwgSUNNUF9VTlJF QUNILCBJQ01QX1VOUkVBQ0hfSE9TVCwgMCwgMCk7DQorCQlpZiAoYmFkcG9y dF9iYW5kbGltKEJBTkRMSU1fSUNNUF9GV0RfVU5SRUFDSCkgPCAwKQ0KKwkJ CW1fZnJlZW0obSk7DQorCQllbHNlDQorCQkJaWNtcF9lcnJvcihtLCBJQ01Q X1VOUkVBQ0gsIElDTVBfVU5SRUFDSF9IT1NULCAwLCAwKTsNCiAJCXJldHVy bjsNCiAJfQ0KICNlbmRpZg0KQEAgLTE0NzYsNiArMTQ4OSw4IEBADQogCSAq IGFuZCBpZiBwYWNrZXQgd2FzIG5vdCBzb3VyY2Ugcm91dGVkIChvciBoYXMg YW55IG9wdGlvbnMpLg0KIAkgKiBBbHNvLCBkb24ndCBzZW5kIHJlZGlyZWN0 IGlmIGZvcndhcmRpbmcgdXNpbmcgYSBkZWZhdWx0IHJvdXRlDQogCSAqIG9y IGEgcm91dGUgbW9kaWZpZWQgYnkgYSByZWRpcmVjdC4NCisJICogVGhpcyBw YXJ0IG9mIGNvZGUgYWxzbyBkbyBub3QgdXNlIHRoZSBydGxvb2t1cF9maWIs IGJlY2F1c2UNCisJICogcnRfbm9kZXMgaXMgbm90IHN1cHBvcnRlZC4NCiAJ ICovDQogCWRlc3Quc19hZGRyID0gMDsNCiAJaWYgKCFzcmNydCAmJiBWX2lw c2VuZHJlZGlyZWN0cyAmJg0KQEAgLTE1MTcsMTMgKzE1MzIsMTMgQEANCiAJ ICogdGhlIElDTVBfVU5SRUFDSF9ORUVERlJBRyAiTmV4dC1Ib3AgTVRVIiBm aWVsZCBkZXNjcmliZWQgaW4gUkZDMTE5MS4NCiAJICovDQogCWJ6ZXJvKCZy bywgc2l6ZW9mKHJvKSk7DQorCWJ6ZXJvKCZydGwsIHNpemVvZihydGwpKTsN CisJcm8ucm9fcnQgPSAoc3RydWN0IHJ0ZW50cnkgKikmcnRsOw0KIA0KLQll cnJvciA9IGlwX291dHB1dChtLCBOVUxMLCAmcm8sIElQX0ZPUldBUkRJTkcs IE5VTEwsIE5VTEwpOw0KKwllcnJvciA9IGlwX291dHB1dChtLCBOVUxMLCAm cm8sIElQX0ZPUldBUkRJTkcgfCBJUF9OT1JURlJFRSwgTlVMTCwgTlVMTCk7 DQogDQogCWlmIChlcnJvciA9PSBFTVNHU0laRSAmJiByby5yb19ydCkNCiAJ CW10dSA9IHJvLnJvX3J0LT5ydF9ybXgucm14X210dTsNCi0JaWYgKHJvLnJv X3J0KQ0KLQkJUlRGUkVFKHJvLnJvX3J0KTsNCiANCiAJaWYgKGVycm9yKQ0K IAkJSVBTVEFUX0lOQyhpcHNfY2FudGZvcndhcmQpOw0KQEAgLTE1NTgsMTEg KzE1NzMsMTMgQEANCiAJZGVmYXVsdDoNCiAJCXR5cGUgPSBJQ01QX1VOUkVB Q0g7DQogCQljb2RlID0gSUNNUF9VTlJFQUNIX0hPU1Q7DQorCQlpY21wX3Nl bmQgPSBiYWRwb3J0X2JhbmRsaW0oIEJBTkRMSU1fSUNNUF9GV0RfVU5SRUFD SCk7DQogCQlicmVhazsNCiANCiAJY2FzZSBFTVNHU0laRToNCiAJCXR5cGUg PSBJQ01QX1VOUkVBQ0g7DQogCQljb2RlID0gSUNNUF9VTlJFQUNIX05FRURG UkFHOw0KKwkJaWNtcF9zZW5kID0gYmFkcG9ydF9iYW5kbGltKCBCQU5ETElN X0lDTVBfRldEX05FRURGUkFHKTsNCiANCiAjaWZkZWYgSVBTRUMNCiAJCS8q IA0KQEAgLTE2MTgsNyArMTYzNSwxMCBAQA0KIAl9DQogCWlmIChpYSAhPSBO VUxMKQ0KIAkJaWZhX2ZyZWUoJmlhLT5pYV9pZmEpOw0KLQlpY21wX2Vycm9y KG1jb3B5LCB0eXBlLCBjb2RlLCBkZXN0LnNfYWRkciwgbXR1KTsNCisJaWYg KGljbXBfc2VuZCA8IDApDQorCQltX2ZyZWVtKG0pOw0KKwllbHNlDQorCQlp Y21wX2Vycm9yKG1jb3B5LCB0eXBlLCBjb2RlLCBkZXN0LnNfYWRkciwgbXR1 KTsNCiB9DQogDQogdm9pZA0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzguMl8y MDExMDMyOS9zeXMvbmV0aW5ldC9pcF9vdXRwdXQuYyAuL3N5cy9uZXRpbmV0 L2lwX291dHB1dC5jDQotLS0gLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lz L25ldGluZXQvaXBfb3V0cHV0LmMJMjAxMC0xMC0yNSAxMzoxNjoxMS4wMDAw MDAwMDAgKzAwMDANCisrKyAuL3N5cy9uZXRpbmV0L2lwX291dHB1dC5jCTIw MTEtMDQtMTQgMTY6Mjc6MzAuMDAwMDAwMDAwICswMDAwDQpAQCAtNTQsNiAr NTQsNyBAQA0KIA0KICNpbmNsdWRlIDxuZXQvaWYuaD4NCiAjaW5jbHVkZSA8 bmV0L2lmX2xsYXRibC5oPg0KKyNpbmNsdWRlIDxuZXQvaWZfZGwuaD4NCiAj aW5jbHVkZSA8bmV0L25ldGlzci5oPg0KICNpbmNsdWRlIDxuZXQvcGZpbC5o Pg0KICNpbmNsdWRlIDxuZXQvcm91dGUuaD4NCkBAIC0xMjgsOCArMTI5LDEz IEBADQogCXN0cnVjdCBpbl9pZmFkZHIgKmlhID0gTlVMTDsNCiAJaW50IGlz YnJvYWRjYXN0LCBzd19jc3VtOw0KIAlzdHJ1Y3Qgcm91dGUgaXByb3V0ZTsN CisJc3RydWN0IHJ0bG9va3VwIHJ0bG5ldzsNCisJc3RydWN0IHJ0bG9va3Vw ICpydGw7DQogCXN0cnVjdCBydGVudHJ5ICpydGU7CS8qIGNhY2hlIGZvciBy by0+cm9fcnQgKi8NCiAJc3RydWN0IGluX2FkZHIgb2RzdDsNCisJc3RydWN0 IHNvY2thZGRyX2RsIGdhdGV3YXk7DQorCWludCByb19wcm92aWRlZCA9IDE7 DQorCQ0KICNpZmRlZiBJUEZJUkVXQUxMX0ZPUldBUkQNCiAJc3RydWN0IG1f dGFnICpmd2RfdGFnID0gTlVMTDsNCiAjZW5kaWYNCkBAIC0xNDgsNyArMTU0 LDkgQEANCiAJfQ0KIA0KIAlpZiAocm8gPT0gTlVMTCkgew0KKwkJcm9fcHJv dmlkZWQgPSAwOw0KIAkJcm8gPSAmaXByb3V0ZTsNCisJCXJ0bCA9ICZydGxu ZXc7DQogCQliemVybyhybywgc2l6ZW9mICgqcm8pKTsNCiANCiAjaWZkZWYg RkxPV1RBQkxFDQpAQCAtMTY3LDcgKzE3NSwxNSBAQA0KIAkJCX0NCiAJCX0N CiAjZW5kaWYNCi0JfQ0KKwl9IGVsc2Ugew0KKwkJaWYgKHJvLT5yb19ydCAm JiAoZmxhZ3MgJiBJUF9OT1JURlJFRSkpIHsNCisJCSAgICAgICAgbm9ydGZy ZWUgPSAxOw0KKwkJCS8qIGV4dHJhY3QgcnRsIGZyb20gcHJvdmlkZWQgcm8s IGNsZWFyIHJvLT5yb19ydCBhZnRlcndhcmRzICovDQorCSAgICAgICAgCXJ0 bCA9IChzdHJ1Y3QgcnRsb29rdXAgKilyby0+cm9fcnQ7DQorCQkJcm8tPnJv X3J0ID0gTlVMTDsNCisJCX0gZWxzZQ0KKwkJCXJ0bCA9ICZydGxuZXc7DQor ICAgICAgICB9DQogDQogCWlmIChvcHQpIHsNCiAJCWxlbiA9IDA7DQpAQCAt MjcxLDE2ICsyODcsMzkgQEANCiAJCSAqIG9wZXJhdGlvbiAoYXMgaXQgaXMg Zm9yIEFSUCkuDQogCQkgKi8NCiAJCWlmIChydGUgPT0gTlVMTCkgew0KKwkJ CS8qIGNoZWNrIGlmIGNhbGxlciBkb2VzIG5vdCBmcmVlIHJvX3J0LCBhcyB0 aGUgICovDQorCQkJaWYgKChyb19wcm92aWRlZCkgJiYgKChmbGFncyAmIElQ X05PUlRGUkVFKSA9PSAwKSkgew0KKyNpZmRlZiBSQURJWF9NUEFUSA0KKwkJ CQlydGFsbG9jX21wYXRoX2ZpYihybywNCisJCQkJICAgIG50b2hsKGlwLT5p cF9zcmMuc19hZGRyIF4gaXAtPmlwX2RzdC5zX2FkZHIpLA0KKwkJCQkgICAg aW5wID8gaW5wLT5pbnBfaW5jLmluY19maWJudW0gOiBNX0dFVEZJQihtKSk7 DQorI2Vsc2UNCisJCQkJaW5fcnRhbGxvY19pZ24ocm8sIDAsDQorCQkJCSAg ICBpbnAgPyBpbnAtPmlucF9pbmMuaW5jX2ZpYm51bSA6IE1fR0VURklCKG0p KTsNCisjZW5kaWYNCisJCQkJcnRlID0gcm8tPnJvX3J0Ow0KKwkJCX0gZWxz ZSB7IC8qIGFscmlnaHQgLSB1c2UgdGhlIGZhc3QgbG9va3VwIGNvZGUgKi8N CisJCQkgICAgICAgIGJ6ZXJvKCAmZ2F0ZXdheSwgc2l6ZW9mKGdhdGV3YXkp KTsNCisJCQkgICAgICAgIGdhdGV3YXkuc2RsX2xlbiA9IHNpemVvZihnYXRl d2F5KTsNCisJCQkJcnRsLT5ydF9nYXRld2F5ID0gKHN0cnVjdCBzb2NrYWRk ciAqKSZnYXRld2F5Ow0KICNpZmRlZiBSQURJWF9NUEFUSA0KLQkJCXJ0YWxs b2NfbXBhdGhfZmliKHJvLA0KLQkJCSAgICBudG9obChpcC0+aXBfc3JjLnNf YWRkciBeIGlwLT5pcF9kc3Quc19hZGRyKSwNCi0JCQkgICAgaW5wID8gaW5w LT5pbnBfaW5jLmluY19maWJudW0gOiBNX0dFVEZJQihtKSk7DQorCQkJCWlm ICghcnRsb29rdXBfbXBhdGhfZmliKChzdHJ1Y3Qgc29ja2FkZHIgKilkc3Qs DQorCQkJCQkJbnRvaGwoaXAtPmlwX3NyYy5zX2FkZHIgXiBpcC0+aXBfZHN0 LnNfYWRkciksDQorCQkJCQkJaW5wID8gaW5wLT5pbnBfaW5jLmluY19maWJu dW0gOiBNX0dFVEZJQihtKSwNCisJCQkJCQlydGwsIFJUTF9QS1NFTlQpKQ0K ICNlbHNlDQotCQkJaW5fcnRhbGxvY19pZ24ocm8sIDAsDQotCQkJICAgIGlu cCA/IGlucC0+aW5wX2luYy5pbmNfZmlibnVtIDogTV9HRVRGSUIobSkpOw0K KwkJCQlpZiAoIXJ0bG9va3VwX2ZpYiggKHN0cnVjdCBzb2NrYWRkciAqKWRz dCwNCisJCQkJCQlpbnAgPyBpbnAtPmlucF9pbmMuaW5jX2ZpYm51bSA6IE1f R0VURklCKG0pLA0KKwkJCQkJCXJ0bCwgUlRMX1BLU0VOVCkpDQogI2VuZGlm DQotCQkJcnRlID0gcm8tPnJvX3J0Ow0KKwkJCQkgICAgICAgIHJvLT5yb19y dCA9IE5VTEw7DQorCQkJCWVsc2Ugew0KKwkJCQkJbm9ydGZyZWUgPSAxOw0K KwkJCQkJcm8tPnJvX3J0ID0gKHN0cnVjdCBydGVudHJ5ICopcnRsOw0KKwkJ CQl9DQorCQkJfQ0KIAkJfQ0KKwkJcnRlID0gcm8tPnJvX3J0Ow0KIAkJaWYg KHJ0ZSA9PSBOVUxMIHx8DQogCQkgICAgcnRlLT5ydF9pZnAgPT0gTlVMTCB8 fA0KIAkJICAgICFSVF9MSU5LX0lTX1VQKHJ0ZS0+cnRfaWZwKSkgew0KZGlm ZiAtdSAtciAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldC9p cF92YXIuaCAuL3N5cy9uZXRpbmV0L2lwX3Zhci5oDQotLS0gLi4vc3JjX29y Z184LjJfMjAxMTAzMjkvc3lzL25ldGluZXQvaXBfdmFyLmgJMjAxMC0wOS0x OCAwMTo1NDoyOC4wMDAwMDAwMDAgKzAwMDANCisrKyAuL3N5cy9uZXRpbmV0 L2lwX3Zhci5oCTIwMTEtMDQtMDcgMDI6MjI6MDUuMDAwMDAwMDAwICswMDAw DQpAQCAtMTU3LDYgKzE1Nyw3IEBADQogI2RlZmluZQlJUF9TRU5EVE9JRgkJ MHg4CQkvKiBzZW5kIG9uIHNwZWNpZmljIGlmbmV0ICovDQogI2RlZmluZSBJ UF9ST1VURVRPSUYJCVNPX0RPTlRST1VURQkvKiAweDEwIGJ5cGFzcyByb3V0 aW5nIHRhYmxlcyAqLw0KICNkZWZpbmUgSVBfQUxMT1dCUk9BRENBU1QJU09f QlJPQURDQVNUCS8qIDB4MjAgY2FuIHNlbmQgYnJvYWRjYXN0IHBhY2tldHMg Ki8NCisjZGVmaW5lIElQX05PUlRGUkVFCQkweDQwCQkvKiBjYWxsZXIgZG9l cyBub3QgZnJlZSByb19ydCB2aWEgUlRGUkVFICovDQogDQogLyoNCiAgKiBt YnVmIGZsYWcgdXNlZCBieSBpcF9mYXN0ZndkDQpkaWZmIC11IC1yIC4uL3Ny Y19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpbmV0L2lwZncvaXBfZndfdGFi bGUuYyAuL3N5cy9uZXRpbmV0L2lwZncvaXBfZndfdGFibGUuYw0KLS0tIC4u L3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpbmV0L2lwZncvaXBfZndf dGFibGUuYwkyMDEwLTAzLTIzIDA5OjU4OjU5LjAwMDAwMDAwMCArMDAwMA0K KysrIC4vc3lzL25ldGluZXQvaXBmdy9pcF9md190YWJsZS5jCTIwMTEtMDQt MDMgMTY6MDc6NTcuMDAwMDAwMDAwICswMDAwDQpAQCAtMTM3LDcgKzEzNyw3 IEBADQogCW1hc2suc2luX2FkZHIuc19hZGRyID0gaHRvbmwobWxlbiA/IH4o KDEgPDwgKDMyIC0gbWxlbikpIC0gMSkgOiAwKTsNCiAJc2Euc2luX2FkZHIu c19hZGRyID0gYWRkciAmIG1hc2suc2luX2FkZHIuc19hZGRyOw0KIAlJUEZX X1dMT0NLKGNoKTsNCi0JZW50ID0gKHN0cnVjdCB0YWJsZV9lbnRyeSAqKXJu aC0+cm5oX2RlbGFkZHIoJnNhLCAmbWFzaywgcm5oKTsNCisJZW50ID0gKHN0 cnVjdCB0YWJsZV9lbnRyeSAqKXJuaC0+cm5oX2RlbGFkZHIoJnNhLCAmbWFz aywgcm5oLCBOVUxMKTsNCiAJaWYgKGVudCA9PSBOVUxMKSB7DQogCQlJUEZX X1dVTkxPQ0soY2gpOw0KIAkJcmV0dXJuIChFU1JDSCk7DQpAQCAtMTU0LDcg KzE1NCw3IEBADQogCXN0cnVjdCB0YWJsZV9lbnRyeSAqZW50Ow0KIA0KIAll bnQgPSAoc3RydWN0IHRhYmxlX2VudHJ5ICopDQotCSAgICBybmgtPnJuaF9k ZWxhZGRyKHJuLT5ybl9rZXksIHJuLT5ybl9tYXNrLCBybmgpOw0KKwkgICAg cm5oLT5ybmhfZGVsYWRkcihybi0+cm5fa2V5LCBybi0+cm5fbWFzaywgcm5o LCBOVUxMKTsNCiAJaWYgKGVudCAhPSBOVUxMKQ0KIAkJZnJlZShlbnQsIE1f SVBGV19UQkwpOw0KIAlyZXR1cm4gKDApOw0KZGlmZiAtdSAtciAuLi9zcmNf b3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldDYvaW42X2lmYXR0YWNoLmMg Li9zeXMvbmV0aW5ldDYvaW42X2lmYXR0YWNoLmMNCi0tLSAuLi9zcmNfb3Jn XzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldDYvaW42X2lmYXR0YWNoLmMJMjAx MC0wNS0wNiAwNjo0NDoxOS4wMDAwMDAwMDAgKzAwMDANCisrKyAuL3N5cy9u ZXRpbmV0Ni9pbjZfaWZhdHRhY2guYwkyMDExLTA0LTAzIDE2OjA3OjU3LjAw MDAwMDAwMCArMDAwMA0KQEAgLTQyLDYgKzQyLDggQEANCiAjaW5jbHVkZSA8 c3lzL3Byb2MuaD4NCiAjaW5jbHVkZSA8c3lzL3N5c2xvZy5oPg0KICNpbmNs dWRlIDxzeXMvbWQ1Lmg+DQorI2luY2x1ZGUgPHN5cy9sb2NrLmg+DQorI2lu Y2x1ZGUgPHN5cy9ybWxvY2suaD4NCiANCiAjaW5jbHVkZSA8bmV0L2lmLmg+ DQogI2luY2x1ZGUgPG5ldC9pZl9kbC5oPg0KZGlmZiAtdSAtciAuLi9zcmNf b3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldDYvaW42X3JteC5jIC4vc3lz L25ldGluZXQ2L2luNl9ybXguYw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEw MzI5L3N5cy9uZXRpbmV0Ni9pbjZfcm14LmMJMjAxMC0xMC0xMSAxMToyNToz Ny4wMDAwMDAwMDAgKzAwMDANCisrKyAuL3N5cy9uZXRpbmV0Ni9pbjZfcm14 LmMJMjAxMS0wNC0wMyAxNjowNzo1Ny4wMDAwMDAwMDAgKzAwMDANCkBAIC04 Nyw2ICs4Nyw3IEBADQogI2luY2x1ZGUgPHN5cy9yd2xvY2suaD4NCiAjaW5j bHVkZSA8c3lzL3N5c2xvZy5oPg0KICNpbmNsdWRlIDxzeXMvY2FsbG91dC5o Pg0KKyNpbmNsdWRlIDxzeXMvcm1sb2NrLmg+DQogDQogI2luY2x1ZGUgPG5l dC9pZi5oPg0KICNpbmNsdWRlIDxuZXQvcm91dGUuaD4NCmRpZmYgLXUgLXIg Li4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL25ldGluZXQ2L2luNl9zcmMu YyAuL3N5cy9uZXRpbmV0Ni9pbjZfc3JjLmMNCi0tLSAuLi9zcmNfb3JnXzgu Ml8yMDExMDMyOS9zeXMvbmV0aW5ldDYvaW42X3NyYy5jCTIwMTEtMDQtMTIg MTM6MDI6MDQuMDAwMDAwMDAwICswMDAwDQorKysgLi9zeXMvbmV0aW5ldDYv aW42X3NyYy5jCTIwMTEtMDQtMTQgMTY6MzA6MjEuMDAwMDAwMDAwICswMDAw DQpAQCAtNTE4LDEwICs1MTgsMTAgQEANCiAJaWYgKGRzdHNvY2stPnNpbjZf YWRkci5zNl9hZGRyMzJbMF0gPT0gMCAmJg0KIAkgICAgZHN0c29jay0+c2lu Nl9hZGRyLnM2X2FkZHIzMlsxXSA9PSAwICYmDQogCSAgICAhSU42X0lTX0FE RFJfTE9PUEJBQ0soJmRzdHNvY2stPnNpbjZfYWRkcikpIHsNCi0JCXByaW50 ZigiaW42X3NlbGVjdHJvdXRlOiBzdHJhbmdlIGRlc3RpbmF0aW9uICVzXG4i LA0KKwkJcHJpbnRmKCJzZWxlY3Ryb3V0ZTogc3RyYW5nZSBkZXN0aW5hdGlv biAlc1xuIiwNCiAJCSAgICAgICBpcDZfc3ByaW50ZihpcDZidWYsICZkc3Rz b2NrLT5zaW42X2FkZHIpKTsNCiAJfSBlbHNlIHsNCi0JCXByaW50ZigiaW42 X3NlbGVjdHJvdXRlOiBkZXN0aW5hdGlvbiA9ICVzJSUlZFxuIiwNCisJCXBy aW50Zigic2VsZWN0cm91dGU6IGRlc3RpbmF0aW9uID0gJXMlJSVkXG4iLA0K IAkJICAgICAgIGlwNl9zcHJpbnRmKGlwNmJ1ZiwgJmRzdHNvY2stPnNpbjZf YWRkciksDQogCQkgICAgICAgZHN0c29jay0+c2luNl9zY29wZV9pZCk7IC8q IGZvciBkZWJ1ZyAqLw0KIAl9DQpAQCAtODAyLDkgKzgwMiwyNTkgQEANCiAg ICAgc3RydWN0IGlwNl9tb3B0aW9ucyAqbW9wdHMsIHN0cnVjdCByb3V0ZV9p bjYgKnJvLA0KICAgICBzdHJ1Y3QgaWZuZXQgKipyZXRpZnAsIHN0cnVjdCBy dGVudHJ5ICoqcmV0cnQpDQogew0KKyAgICAgICAgcmV0dXJuIChzZWxlY3Ry b3V0ZShkc3Rzb2NrLCBvcHRzLCBtb3B0cywgcm8sIHJldGlmcCwNCisgICAg ICAgICAgICByZXRydCwgMCkpOw0KK30NCisgDQorLyogUHJvdmlkZXMgZmFz dCBidXQgbWluaW1hbCBhY2Nlc3MgdG8gcm91dGluZyB0YWJsZS4NCisgKiBi YXNlZCBhdCBzZWxlY3Ryb3V0ZQ0KKyAqIFhYWCByZW1vdmUgYW5kIGRvIGxv b2t1cCBkaXJlY3QgaW4gaXA2X291dHB1dA0KKyAqLw0KK2ludA0KK2luNl9s b29rdXAoc3RydWN0IHNvY2thZGRyX2luNiAqZHN0c29jaywgc3RydWN0IGlw Nl9wa3RvcHRzICpvcHRzLA0KKyAgICBzdHJ1Y3QgaXA2X21vcHRpb25zICpt b3B0cywgc3RydWN0IHJvdXRlX2luNiAqcm8sIHN0cnVjdCBydGxvb2t1cCAq cnRsLA0KKyAgICBzdHJ1Y3QgaWZuZXQgKipyZXRpZnAsIHN0cnVjdCBydGVu dHJ5ICoqcmV0cnQpDQorew0KKyAgICAgICBpbnQgZXJyb3IgPSAwOw0KKyAg ICAgICBzdHJ1Y3QgaWZuZXQgKmlmcCA9IE5VTEw7DQorICAgICAgIHN0cnVj dCBydGVudHJ5ICpydCA9IE5VTEw7DQorICAgICAgIHN0cnVjdCBzb2NrYWRk cl9pbjYgKnNpbjZfbmV4dDsNCisgICAgICAgc3RydWN0IGluNl9wa3RpbmZv ICpwaSA9IE5VTEw7DQorICAgICAgIHN0cnVjdCBpbjZfYWRkciAqZHN0ID0g JmRzdHNvY2stPnNpbjZfYWRkcjsNCisgICAgICAgaW50IG5vcm91dGVvayA9 IDA7DQorICAgICAgIHVuc2lnbmVkIGNoYXIgc2FfbGVuID0gcnRsLT5ydF9n YXRld2F5LT5zYV9sZW47DQorI2lmIDANCisgICAgICAgY2hhciBpcDZidWZb SU5FVDZfQUREUlNUUkxFTl07DQorDQorICAgICAgIGlmIChkc3Rzb2NrLT5z aW42X2FkZHIuczZfYWRkcjMyWzBdID09IDAgJiYNCisgICAgICAgICAgIGRz dHNvY2stPnNpbjZfYWRkci5zNl9hZGRyMzJbMV0gPT0gMCAmJg0KKyAgICAg ICAgICAgIUlONl9JU19BRERSX0xPT1BCQUNLKCZkc3Rzb2NrLT5zaW42X2Fk ZHIpKSB7DQorICAgICAgICAgICAgICAgcHJpbnRmKCJpbjZfbG9va3VwOiBz dHJhbmdlIGRlc3RpbmF0aW9uICVzXG4iLA0KKyAgICAgICAgICAgICAgICAg ICAgICBpcDZfc3ByaW50ZihpcDZidWYsICZkc3Rzb2NrLT5zaW42X2FkZHIp KTsNCisgICAgICAgfSBlbHNlIHsNCisgICAgICAgICAgICAgICBwcmludGYo ImluNl9sb29rdXA6IGRlc3RpbmF0aW9uID0gJXMlJSVkXG4iLA0KKyAgICAg ICAgICAgICAgICAgICAgICBpcDZfc3ByaW50ZihpcDZidWYsICZkc3Rzb2Nr LT5zaW42X2FkZHIpLA0KKyAgICAgICAgICAgICAgICAgICAgICBkc3Rzb2Nr LT5zaW42X3Njb3BlX2lkKTsgLyogZm9yIGRlYnVnICovDQorICAgICAgIH0N CisjZW5kaWYNCisNCisgICAgICAgLyogSWYgdGhlIGNhbGxlciBzcGVjaWZ5 IHRoZSBvdXRnb2luZyBpbnRlcmZhY2UgZXhwbGljaXRseSwgdXNlIGl0LiAq Lw0KKyAgICAgICBpZiAob3B0cyAmJiAocGkgPSBvcHRzLT5pcDZwb19wa3Rp bmZvKSAhPSBOVUxMICYmIHBpLT5pcGk2X2lmaW5kZXgpIHsNCisgICAgICAg ICAgICAgICAvKiBYWFggYm91bmRhcnkgY2hlY2sgaXMgYXNzdW1lZCB0byBi ZSBhbHJlYWR5IGRvbmUuICovDQorICAgICAgICAgICAgICAgaWZwID0gaWZu ZXRfYnlpbmRleChwaS0+aXBpNl9pZmluZGV4KTsNCisgICAgICAgICAgICAg ICBpZiAoaWZwICE9IE5VTEwgJiYNCisgICAgICAgICAgICAgICAgICAgKG5v cm91dGVvayB8fCByZXRydCA9PSBOVUxMIHx8DQorICAgICAgICAgICAgICAg ICAgIElONl9JU19BRERSX01VTFRJQ0FTVChkc3QpKSkgew0KKyAgICAgICAg ICAgICAgICAgICAgICAgLyoNCisgICAgICAgICAgICAgICAgICAgICAgICAq IHdlIGRvIG5vdCBoYXZlIHRvIGNoZWNrIG9yIGdldCB0aGUgcm91dGUgZm9y DQorICAgICAgICAgICAgICAgICAgICAgICAgKiBtdWx0aWNhc3QuDQorICAg ICAgICAgICAgICAgICAgICAgICAgKi8NCisgICAgICAgICAgICAgICAgICAg ICAgIGdvdG8gZG9uZTsNCisgICAgICAgICAgICAgICB9IGVsc2UNCisgICAg ICAgICAgICAgICAgICAgICAgIGdvdG8gZ2V0cm91dGU7DQorICAgICAgIH0N CisNCisgICAgICAgLyoNCisgICAgICAgICogSWYgdGhlIGRlc3RpbmF0aW9u IGFkZHJlc3MgaXMgYSBtdWx0aWNhc3QgYWRkcmVzcyBhbmQgdGhlIG91dGdv aW5nDQorICAgICAgICAqIGludGVyZmFjZSBmb3IgdGhlIGFkZHJlc3MgaXMg c3BlY2lmaWVkIGJ5IHRoZSBjYWxsZXIsIHVzZSBpdC4NCisgICAgICAgICov DQorICAgICAgIGlmIChJTjZfSVNfQUREUl9NVUxUSUNBU1QoZHN0KSAmJg0K KyAgICAgICAgICAgbW9wdHMgIT0gTlVMTCAmJiAoaWZwID0gbW9wdHMtPmlt Nm9fbXVsdGljYXN0X2lmcCkgIT0gTlVMTCkgew0KKyAgICAgICAgICAgICAg IGdvdG8gZG9uZTsgLyogd2UgZG8gbm90IG5lZWQgYSByb3V0ZSBmb3IgbXVs dGljYXN0LiAqLw0KKyAgICAgICB9DQorDQorICBnZXRyb3V0ZToNCisgICAg ICAgLyoNCisgICAgICAgICogSWYgdGhlIG5leHQgaG9wIGFkZHJlc3MgZm9y IHRoZSBwYWNrZXQgaXMgc3BlY2lmaWVkIGJ5IHRoZSBjYWxsZXIsDQorICAg ICAgICAqIHVzZSBpdCBhcyB0aGUgZ2F0ZXdheS4NCisgICAgICAgICovDQor ICAgICAgIGlmIChvcHRzICYmIG9wdHMtPmlwNnBvX25leHRob3ApIHsNCisg ICAgICAgICAgICAgICBzdHJ1Y3Qgcm91dGVfaW42ICpyb247DQorICAgICAg ICAgICAgICAgc3RydWN0IGxsZW50cnkgKmxhOw0KKyAgICAgICAgICAgDQor ICAgICAgICAgICAgICAgc2luNl9uZXh0ID0gc2F0b3NpbjYob3B0cy0+aXA2 cG9fbmV4dGhvcCk7DQorICAgICAgICAgICAgICAgDQorICAgICAgICAgICAg ICAgLyogYXQgdGhpcyBtb21lbnQsIHdlIG9ubHkgc3VwcG9ydCBBRl9JTkVU NiBuZXh0IGhvcHMgKi8NCisgICAgICAgICAgICAgICBpZiAoc2luNl9uZXh0 LT5zaW42X2ZhbWlseSAhPSBBRl9JTkVUNikgew0KKyAgICAgICAgICAgICAg ICAgICAgICAgZXJyb3IgPSBFQUZOT1NVUFBPUlQ7IC8qIG9yIHNob3VsZCB3 ZSBwcm9jZWVkPyAqLw0KKyAgICAgICAgICAgICAgICAgICAgICAgZ290byBk b25lOw0KKyAgICAgICAgICAgICAgIH0NCisNCisgICAgICAgICAgICAgICAv Kg0KKyAgICAgICAgICAgICAgICAqIElmIHRoZSBuZXh0IGhvcCBpcyBhbiBJ UHY2IGFkZHJlc3MsIHRoZW4gdGhlIG5vZGUgaWRlbnRpZmllZA0KKyAgICAg ICAgICAgICAgICAqIGJ5IHRoYXQgYWRkcmVzcyBtdXN0IGJlIGEgbmVpZ2hi b3Igb2YgdGhlIHNlbmRpbmcgaG9zdC4NCisgICAgICAgICAgICAgICAgKi8N CisgICAgICAgICAgICAgICByb24gPSAmb3B0cy0+aXA2cG9fbmV4dHJvdXRl Ow0KKyAgICAgICAgICAgICAgIC8qDQorICAgICAgICAgICAgICAgICogWFhY IHdoYXQgZG8gd2UgZG8gaGVyZT8NCisgICAgICAgICAgICAgICAgKiBQTFog dG8gYmUgZml4aW5nDQorICAgICAgICAgICAgICAgICovDQorDQorICAgICAg ICAgICAgICAgaWYgKHJvbi0+cm9fcnQgPT0gTlVMTCkgew0KKyAgICAgICAg ICAgICAgICAgICAgICAgYnplcm8oIHJ0bC0+cnRfZ2F0ZXdheSwgc2FfbGVu KTsNCisgICAgICAgICAgICAgICAgICAgICAgIHJ0bC0+cnRfZ2F0ZXdheS0+ c2FfbGVuID0gc2FfbGVuOw0KKyAgICAgICAgICAgICAgICAgICAgICAgaWYg KCFydGxvb2t1cF9maWIoIChzdHJ1Y3Qgc29ja2FkZHIgKikmcm9uLT5yb19k c3QsIDBVLCAvKiBtdWx0aSBwYXRoIGNhc2U/ICovDQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcnRsLCBSVExfUEtTRU5UKSkg ew0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByb24tPnJvX3J0 ID0gTlVMTDsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXJy b3IgPSBFSE9TVFVOUkVBQ0g7DQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGdvdG8gZG9uZTsNCisgICAgICAgICAgICAgICAgICAgICAgIH0g ZWxzZQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByb24tPnJv X3J0ID0gKHN0cnVjdCBydGVudHJ5ICopIHJ0bDsNCisgICAgICAgICAgICAg ICB9DQorDQorICAgICAgICAgICAgICAgcnQgPSByb24tPnJvX3J0Ow0KKyAg ICAgICAgICAgICAgIGlmcCA9IHJ0LT5ydF9pZnA7DQorICAgICAgICAgICAg ICAgSUZfQUZEQVRBX0xPQ0soaWZwKTsNCisgICAgICAgICAgICAgICBsYSA9 IGxsYV9sb29rdXAoTExUQUJMRTYoaWZwKSwgMCwgKHN0cnVjdCBzb2NrYWRk ciAqKSZzaW42X25leHQtPnNpbjZfYWRkcik7DQorICAgICAgICAgICAgICAg SUZfQUZEQVRBX1VOTE9DSyhpZnApOw0KKyAgICAgICAgICAgICAgIGlmIChs YSAhPSBOVUxMKSANCisgICAgICAgICAgICAgICAgICAgICAgIExMRV9SVU5M T0NLKGxhKTsNCisgICAgICAgICAgICAgICBlbHNlIHsNCisgICAgICAgICAg ICAgICAgICAgICAgIGVycm9yID0gRUhPU1RVTlJFQUNIOw0KKyAgICAgICAg ICAgICAgICAgICAgICAgZ290byBkb25lOw0KKyAgICAgICAgICAgICAgIH0N CisjaWYgMA0KKyAgICAgICAgICAgICAgIGlmICgocm9uLT5yb19ydCAmJg0K KyAgICAgICAgICAgICAgICAgICAocm9uLT5yb19ydC0+cnRfZmxhZ3MgJiAo UlRGX1VQIHwgUlRGX0xMSU5GTykpICE9DQorICAgICAgICAgICAgICAgICAg IChSVEZfVVAgfCBSVEZfTExJTkZPKSkgfHwNCisgICAgICAgICAgICAgICAg ICAgIUlONl9BUkVfQUREUl9FUVVBTCgmc2F0b3NpbjYoJnJvbi0+cm9fZHN0 KS0+c2luNl9hZGRyLA0KKyAgICAgICAgICAgICAgICAgICAmc2luNl9uZXh0 LT5zaW42X2FkZHIpKSB7DQorICAgICAgICAgICAgICAgICAgICAgICBpZiAo cm9uLT5yb19ydCkNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cm9uLT5yb19ydCA9IE5VTEw7DQorICAgICAgICAgICAgICAgICAgICAgICAq c2F0b3NpbjYoJnJvbi0+cm9fZHN0KSA9ICpzaW42X25leHQ7DQorICAgICAg ICAgICAgICAgfQ0KKyAgICAgICAgICAgICAgIGlmIChyb24tPnJvX3J0ID09 IE5VTEwpIHsNCisgICAgICAgICAgICAgICAgICAgICAgIGJ6ZXJvKCBydGwt PnJ0X2dhdGV3YXksIHNhX2xlbik7DQorICAgICAgICAgICAgICAgICAgICAg ICBydGwtPnJ0X2dhdGV3YXktPnNhX2xlbiA9IHNhX2xlbjsNCisgICAgICAg ICAgICAgICAgICAgICAgIGlmICghcnRsb29rdXBfZmliKCAoc3RydWN0IHNv Y2thZGRyICopJnJvbi0+cm9fZHN0LCAwVSwNCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBydGwsIFJUTF9QS1NFTlQpKSB7DQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJvbi0+cm9fcnQgPSBO VUxMOw0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlcnJvciA9 IEVIT1NUVU5SRUFDSDsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZ290byBkb25lOw0KKyAgICAgICAgICAgICAgICAgICAgICAgfSBlbHNl IHsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcm9uLT5yb19y dCA9IChzdHJ1Y3QgcnRlbnRyeSAqKSBydGw7DQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlmICghKHJvbi0+cm9fcnQtPnJ0X2ZsYWdzICYg UlRGX0xMSU5GTykpIHsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICByb24tPnJvX3J0ID0gTlVMTDsNCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBlcnJvciA9IEVIT1NUVU5SRUFD SDsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBn b3RvIGRvbmU7DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9 DQorICAgICAgICAgICAgICAgICAgICAgICB9DQorICAgICAgICAgICAgICAg fQ0KKyNlbmRpZg0KKw0KKyAgICAgICAgICAgICAgIC8qDQorICAgICAgICAg ICAgICAgICogV2hlbiBjbG9uaW5nIGlzIHJlcXVpcmVkLCB0cnkgdG8gYWxs b2NhdGUgYSByb3V0ZSB0byB0aGUNCisgICAgICAgICAgICAgICAgKiBkZXN0 aW5hdGlvbiBzbyB0aGF0IHRoZSBjYWxsZXIgY2FuIHN0b3JlIHBhdGggTVRV DQorICAgICAgICAgICAgICAgICogaW5mb3JtYXRpb24uDQorICAgICAgICAg ICAgICAgICovDQorICAgICAgICAgICAgICAgZ290byBkb25lOw0KKyAgICAg ICB9DQorDQorICAgICAgIC8qDQorICAgICAgICAqIFVzZSBhIGNhY2hlZCBy b3V0ZSBpZiBpdCBleGlzdHMgYW5kIGlzIHZhbGlkLCBlbHNlIHRyeSB0byBh bGxvY2F0ZQ0KKyAgICAgICAgKiBhIG5ldyBvbmUuICBOb3RlIHRoYXQgd2Ug c2hvdWxkIGNoZWNrIHRoZSBhZGRyZXNzIGZhbWlseSBvZiB0aGUNCisgICAg ICAgICogY2FjaGVkIGRlc3RpbmF0aW9uLCBpbiBjYXNlIG9mIHNoYXJpbmcg dGhlIGNhY2hlIHdpdGggSVB2NC4NCisgICAgICAgICovDQorICAgICAgIGlm IChybykgew0KKyAgICAgICAgICAgICAgIGlmIChyby0+cm9fcnQgJiYNCisg ICAgICAgICAgICAgICAgICAgKCEocm8tPnJvX3J0LT5ydF9mbGFncyAmIFJU Rl9VUCkgfHwNCisgICAgICAgICAgICAgICAgICAgICgoc3RydWN0IHNvY2th ZGRyICopKCZyby0+cm9fZHN0KSktPnNhX2ZhbWlseSAhPSBBRl9JTkVUNiB8 fA0KKyAgICAgICAgICAgICAgICAgICAgIUlONl9BUkVfQUREUl9FUVVBTCgm c2F0b3NpbjYoJnJvLT5yb19kc3QpLT5zaW42X2FkZHIsDQorICAgICAgICAg ICAgICAgICAgICBkc3QpKSkNCisgICAgICAgICAgICAgICAgICAgICAgIHJv LT5yb19ydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKU5VTEw7DQorICAgICAgICAg ICAgICAgaWYgKHJvLT5yb19ydCA9PSAoc3RydWN0IHJ0ZW50cnkgKilOVUxM KSB7DQorICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qgc29ja2FkZHJf aW42ICpzYTY7DQorDQorICAgICAgICAgICAgICAgICAgICAgICAvKiBObyBy b3V0ZSB5ZXQsIHNvIHRyeSB0byBhY3F1aXJlIG9uZSAqLw0KKyAgICAgICAg ICAgICAgICAgICAgICAgYnplcm8oJnJvLT5yb19kc3QsIHNpemVvZihzdHJ1 Y3Qgc29ja2FkZHJfaW42KSk7DQorICAgICAgICAgICAgICAgICAgICAgICBz YTYgPSAoc3RydWN0IHNvY2thZGRyX2luNiAqKSZyby0+cm9fZHN0Ow0KKyAg ICAgICAgICAgICAgICAgICAgICAgKnNhNiA9ICpkc3Rzb2NrOw0KKyAgICAg ICAgICAgICAgICAgICAgICAgc2E2LT5zaW42X3Njb3BlX2lkID0gMDsNCisN CisgICAgICAgICAgICAgICAgICAgICAgIGJ6ZXJvKCBydGwtPnJ0X2dhdGV3 YXksIHNhX2xlbik7DQorICAgICAgICAgICAgICAgICAgICAgICBydGwtPnJ0 X2dhdGV3YXktPnNhX2xlbiA9IHNhX2xlbjsNCisjaWZkZWYgUkFESVhfTVBB VEgNCisgICAgICAgICAgICAgICAgICAgICAgIGlmICghcnRsb29rdXBfbXBh dGhfZmliKChzdHJ1Y3Qgc29ja2FkZHIgKikmcm8tPnJvX2RzdCwNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBudG9obChzYTYt PnNpbjZfYWRkci5zNl9hZGRyMzJbM10pLA0KKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDBVLCBydGwsIFJUTF9QS1NFTlQpKQ0K KyNlbHNlDQorICAgICAgICAgICAgICAgICAgICAgICBpZiAoIXJ0bG9va3Vw X2ZpYigoc3RydWN0IHNvY2thZGRyICopJnJvLT5yb19kc3QsIDBVLA0KKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ0bCwgUlRM X1BLU0VOVCkpDQorI2VuZGlmDQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJvLT5yb19ydCA9IE5VTEw7DQorICAgICAgICAgICAgICAgICAg ICAgICBlbHNlDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJv LT5yb19ydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKSBydGw7DQorICAgICAgICAg ICAgICAgfQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCisg ICAgICAgICAgICAgICAvKg0KKyAgICAgICAgICAgICAgICAqIGRvIG5vdCBj YXJlIGFib3V0IHRoZSByZXN1bHQgaWYgd2UgaGF2ZSB0aGUgbmV4dGhvcA0K KyAgICAgICAgICAgICAgICAqIGV4cGxpY2l0bHkgc3BlY2lmaWVkLg0KKyAg ICAgICAgICAgICAgICAqLw0KKyAgICAgICAgICAgICAgIGlmIChvcHRzICYm IG9wdHMtPmlwNnBvX25leHRob3ApDQorICAgICAgICAgICAgICAgICAgICAg ICBnb3RvIGRvbmU7DQorDQorICAgICAgICAgICAgICAgaWYgKHJvLT5yb19y dCkgew0KKyAgICAgICAgICAgICAgICAgICAgICAgaWZwID0gcm8tPnJvX3J0 LT5ydF9pZnA7DQorDQorICAgICAgICAgICAgICAgICAgICAgICBpZiAoaWZw ID09IE5VTEwpIHsgLyogY2FuIHRoaXMgcmVhbGx5IGhhcHBlbj8gKi8NCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcm8tPnJvX3J0ID0gTlVM TDsNCisgICAgICAgICAgICAgICAgICAgICAgIH0NCisgICAgICAgICAgICAg ICB9DQorICAgICAgICAgICAgICAgaWYgKHJvLT5yb19ydCA9PSBOVUxMKQ0K KyAgICAgICAgICAgICAgICAgICAgICAgZXJyb3IgPSBFSE9TVFVOUkVBQ0g7 DQorICAgICAgICAgICAgICAgcnQgPSByby0+cm9fcnQ7DQorDQorICAgICAg ICAgICAgICAgLyoNCisgICAgICAgICAgICAgICAgKiBDaGVjayBpZiB0aGUg b3V0Z29pbmcgaW50ZXJmYWNlIGNvbmZsaWN0cyB3aXRoDQorICAgICAgICAg ICAgICAgICogdGhlIGludGVyZmFjZSBzcGVjaWZpZWQgYnkgaXBpNl9pZmlu ZGV4IChpZiBzcGVjaWZpZWQpLg0KKyAgICAgICAgICAgICAgICAqIE5vdGUg dGhhdCBsb29wYmFjayBpbnRlcmZhY2UgaXMgYWx3YXlzIG9rYXkuDQorICAg ICAgICAgICAgICAgICogKHRoaXMgbWF5IGhhcHBlbiB3aGVuIHdlIGFyZSBz ZW5kaW5nIGEgcGFja2V0IHRvIG9uZSBvZg0KKyAgICAgICAgICAgICAgICAq ICBvdXIgb3duIGFkZHJlc3Nlcy4pDQorICAgICAgICAgICAgICAgICovDQor ICAgICAgICAgICAgICAgaWYgKGlmcCAmJiBvcHRzICYmIG9wdHMtPmlwNnBv X3BrdGluZm8gJiYNCisgICAgICAgICAgICAgICAgICAgb3B0cy0+aXA2cG9f cGt0aW5mby0+aXBpNl9pZmluZGV4KSB7DQorICAgICAgICAgICAgICAgICAg ICAgICBpZiAoIShpZnAtPmlmX2ZsYWdzICYgSUZGX0xPT1BCQUNLKSAmJg0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmcC0+aWZfaW5kZXggIT0N CisgICAgICAgICAgICAgICAgICAgICAgICAgICBvcHRzLT5pcDZwb19wa3Rp bmZvLT5pcGk2X2lmaW5kZXgpIHsNCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZXJyb3IgPSBFSE9TVFVOUkVBQ0g7DQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGdvdG8gZG9uZTsNCisgICAgICAgICAgICAg ICAgICAgICAgIH0NCisgICAgICAgICAgICAgICB9DQorICAgICAgIH0NCisN CisgIGRvbmU6DQorICAgICAgIGlmIChpZnAgPT0gTlVMTCAmJiBydCA9PSBO VUxMKSB7DQorICAgICAgICAgICAgICAgLyoNCisgICAgICAgICAgICAgICAg KiBUaGlzIGNhbiBoYXBwZW4gaWYgdGhlIGNhbGxlciBkaWQgbm90IHBhc3Mg YSBjYWNoZWQgcm91dGUNCisgICAgICAgICAgICAgICAgKiBub3IgYW55IG90 aGVyIGhpbnRzLiAgV2UgdHJlYXQgdGhpcyBjYXNlIGFuIGVycm9yLg0KKyAg ICAgICAgICAgICAgICAqLw0KKyAgICAgICAgICAgICAgIGVycm9yID0gRUhP U1RVTlJFQUNIOw0KKyAgICAgICB9DQorICAgICAgIGlmIChlcnJvciA9PSBF SE9TVFVOUkVBQ0gpDQorICAgICAgICAgICAgICAgVl9pcDZzdGF0LmlwNnNf bm9yb3V0ZSsrOw0KKw0KKyAgICAgICBpZiAocmV0aWZwICE9IE5VTEwpIHsN CisgICAgICAgICAgICAgICAqcmV0aWZwID0gaWZwOw0KKw0KKyAgICAgICAg ICAgICAgIC8qDQorICAgICAgICAgICAgICAgICogQWRqdXN0IHRoZSAib3V0 Z29pbmciIGludGVyZmFjZS4gIElmIHdlJ3JlIGdvaW5nIHRvIGxvb3AgDQor ICAgICAgICAgICAgICAgICogdGhlIHBhY2tldCBiYWNrIHRvIG91cnNlbHZl cywgdGhlIGlmcCB3b3VsZCBiZSB0aGUgbG9vcGJhY2sgDQorICAgICAgICAg ICAgICAgICogaW50ZXJmYWNlLiBIb3dldmVyLCB3ZSdkIHJhdGhlciBrbm93 IHRoZSBpbnRlcmZhY2UgYXNzb2NpYXRlZCANCisgICAgICAgICAgICAgICAg KiB0byB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyAod2hpY2ggc2hvdWxkIHBy b2JhYmx5IGJlIG9uZSBvZiANCisgICAgICAgICAgICAgICAgKiBvdXIgb3du IGFkZHJlc3Nlcy4pDQorICAgICAgICAgICAgICAgICovDQorICAgICAgICAg ICAgICAgaWYgKHJ0KSB7DQorICAgICAgICAgICAgICAgICAgICAgICBpZiAo KHJ0LT5ydF9pZnAtPmlmX2ZsYWdzICYgSUZGX0xPT1BCQUNLKSAmJg0KKyAg ICAgICAgICAgICAgICAgICAgICAgICAgIChydC0+cnRfZ2F0ZXdheS0+c2Ff ZmFtaWx5ID09IEFGX0xJTkspKQ0KKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqcmV0aWZwID0gDQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaWZuZXRfYnlpbmRleCgoKHN0cnVjdCBzb2NrYWRk cl9kbCAqKQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHJ0LT5ydF9nYXRld2F5KS0+c2RsX2luZGV4 KTsNCisgICAgICAgICAgICAgICB9DQorICAgICAgIH0NCisgICAgICAgaWYg KHJldHJ0ICE9IE5VTEwpDQorICAgICAgICAgICAgICAgKnJldHJ0ID0gcnQ7 ICAgIC8qIHJ0IG1heSBiZSBOVUxMICovDQogDQotCXJldHVybiAoc2VsZWN0 cm91dGUoZHN0c29jaywgb3B0cywgbW9wdHMsIHJvLCByZXRpZnAsDQotCSAg ICByZXRydCwgMCkpOw0KKyAgICAgICByZXR1cm4gKGVycm9yKTsNCiB9DQog DQogLyoNCmRpZmYgLXUgLXIgLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lz L25ldGluZXQ2L2lwNl9mb3J3YXJkLmMgLi9zeXMvbmV0aW5ldDYvaXA2X2Zv cndhcmQuYw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRp bmV0Ni9pcDZfZm9yd2FyZC5jCTIwMTAtMDItMDcgMDk6MDA6MjIuMDAwMDAw MDAwICswMDAwDQorKysgLi9zeXMvbmV0aW5ldDYvaXA2X2ZvcndhcmQuYwky MDExLTA0LTE0IDE2OjMxOjEzLjAwMDAwMDAwMCArMDAwMA0KQEAgLTUwLDYg KzUwLDcgQEANCiAjaW5jbHVkZSA8c3lzL3N5c2xvZy5oPg0KIA0KICNpbmNs dWRlIDxuZXQvaWYuaD4NCisjaW5jbHVkZSA8bmV0L2lmX2RsLmg+DQogI2lu Y2x1ZGUgPG5ldC9yb3V0ZS5oPg0KICNpbmNsdWRlIDxuZXQvcGZpbC5oPg0K IA0KQEAgLTk5LDkgKzEwMCwxMiBAQA0KIAlzdHJ1Y3QgaWZuZXQgKm9yaWdp ZnA7CS8qIG1heWJlIHVubmVjZXNzYXJ5ICovDQogCXVfaW50MzJfdCBpbnpv bmUsIG91dHpvbmU7DQogCXN0cnVjdCBpbjZfYWRkciBzcmNfaW42LCBkc3Rf aW42Ow0KKwlzdHJ1Y3QgcnRsb29rdXAgcnRsOw0KKwlzdHJ1Y3Qgc29ja2Fk ZHJfZGwgZ2F0ZXdheTsNCiAjaWZkZWYgSVBTRUMNCiAJc3RydWN0IHNlY3Bv bGljeSAqc3AgPSBOVUxMOw0KIAlpbnQgaXBzZWNydCA9IDA7DQorCWludCBu b3J0ZnJlZSA9IDA7DQogI2VuZGlmDQogCWNoYXIgaXA2YnVmc1tJTkVUNl9B RERSU1RSTEVOXSwgaXA2YnVmZFtJTkVUNl9BRERSU1RSTEVOXTsNCiANCkBA IC0yODMsNyArMjg3LDcgQEANCiAJc3RhdGUucm8gPSBOVUxMOwkvKiB1cGRh dGUgYXQgaXBzZWM2X291dHB1dF90dW5uZWwoKSAqLw0KIAlzdGF0ZS5kc3Qg PSBOVUxMOwkvKiB1cGRhdGUgYXQgaXBzZWM2X291dHB1dF90dW5uZWwoKSAq Lw0KIA0KLQllcnJvciA9IGlwc2VjNl9vdXRwdXRfdHVubmVsKCZzdGF0ZSwg c3AsIDApOw0KKwllcnJvciA9IGlwc2VjNl9vdXRwdXRfdHVubmVsKCZzdGF0 ZSwgc3AsIDAsICZydGwsIChzdHJ1Y3Qgc29ja2FkZHIgKikmZ2F0ZXdheSwg Jm5vcnRmcmVlKTsNCiANCiAJbSA9IHN0YXRlLm07DQogCUtFWV9GUkVFU1Ao JnNwKTsNCkBAIC0zNTIsMTggKzM1NiwyOSBAQA0KIAlkc3QtPnNpbjZfZmFt aWx5ID0gQUZfSU5FVDY7DQogCWRzdC0+c2luNl9hZGRyID0gaXA2LT5pcDZf ZHN0Ow0KIA0KLQlyaW42LnJvX3J0ID0gcnRhbGxvYzEoKHN0cnVjdCBzb2Nr YWRkciAqKWRzdCwgMCwgMCk7DQotCWlmIChyaW42LnJvX3J0ICE9IE5VTEwp DQotCQlSVF9VTkxPQ0socmluNi5yb19ydCk7DQotCWVsc2Ugew0KKwliemVy byggJmdhdGV3YXksIHNpemVvZihnYXRld2F5KSk7DQorCWdhdGV3YXkuc2Rs X2xlbiA9IHNpemVvZihnYXRld2F5KTsNCisJcnRsLnJ0X2dhdGV3YXkgPSAo c3RydWN0IHNvY2thZGRyICopJmdhdGV3YXk7DQorI2lmZGVmIFJBRElYX01Q QVRIDQorCXNyY19pbjYgPSBpcDYtPmlwNl9zcmM7DQorCWRzdF9pbjYgPSBp cDYtPmlwNl9kc3Q7DQorCWlmICghcnRsb29rdXBfbXBhdGhfZmliKChzdHJ1 Y3Qgc29ja2FkZHIgKikmcmluNi5yb19kc3QsDQorCQkJbnRvaGwoc3JjX2lu Ni0+c2luNl9hZGRyLnM2X2FkZHIzMlszXSBeIGRzdF9pbjYtPnNpbjZfYWRk ci5zNl9hZGRyMzJbM10pLA0KKwkJCTBVLCAmcnRsLCBSVExfUEtTRU5UKSkg ew0KKyNlbHNlDQorCWlmICghcnRsb29rdXBfZmliKCAoc3RydWN0IHNvY2th ZGRyICopJnJpbjYucm9fZHN0LCAwVSwgJnJ0bCwNCisJCQlSVExfUEtTRU5U KSkgew0KKyNlbmRpZg0KKwkJcmluNi5yb19ydCA9IE5VTEw7DQogCQlWX2lw NnN0YXQuaXA2c19ub3JvdXRlKys7DQogCQlpbjZfaWZzdGF0X2luYyhtLT5t X3BrdGhkci5yY3ZpZiwgaWZzNl9pbl9ub3JvdXRlKTsNCiAJCWlmIChtY29w eSkgew0KIAkJCWljbXA2X2Vycm9yKG1jb3B5LCBJQ01QNl9EU1RfVU5SRUFD SCwNCi0JCQlJQ01QNl9EU1RfVU5SRUFDSF9OT1JPVVRFLCAwKTsNCisJCQkJ SUNNUDZfRFNUX1VOUkVBQ0hfTk9ST1VURSwgMCk7DQogCQl9DQogCQlnb3Rv IGJhZDsNCi0JfQ0KKwl9IGVsc2UNCisJCXJpbjYucm9fcnQgPSAoc3RydWN0 IHJ0ZW50cnkgKikgJnJ0bDsNCiAJcnQgPSByaW42LnJvX3J0Ow0KICNpZmRl ZiBJUFNFQw0KIHNraXBfcm91dGluZzoNCkBAIC01ODAsMTIgKzU5NSwxMiBA QA0KIA0KIHNlbmRlcnI6DQogCWlmIChtY29weSA9PSBOVUxMKQ0KLQkJZ290 byBvdXQ7DQorCQlyZXR1cm47DQogCXN3aXRjaCAoZXJyb3IpIHsNCiAJY2Fz ZSAwOg0KIAkJaWYgKHR5cGUgPT0gTkRfUkVESVJFQ1QpIHsNCiAJCQlpY21w Nl9yZWRpcmVjdF9vdXRwdXQobWNvcHksIHJ0KTsNCi0JCQlnb3RvIG91dDsN CisJCQlyZXR1cm47DQogCQl9DQogCQlnb3RvIGZyZWVjb3B5Ow0KIA0KQEAg LTYwNywxOCArNjIyLDExIEBADQogCQlicmVhazsNCiAJfQ0KIAlpY21wNl9l cnJvcihtY29weSwgdHlwZSwgY29kZSwgMCk7DQotCWdvdG8gb3V0Ow0KKwly ZXR1cm47DQogDQogIGZyZWVjb3B5Og0KIAltX2ZyZWVtKG1jb3B5KTsNCi0J Z290byBvdXQ7DQorCXJldHVybjsNCiBiYWQ6DQogCW1fZnJlZW0obSk7DQot b3V0Og0KLQlpZiAocnQgIT0gTlVMTA0KLSNpZmRlZiBJUFNFQw0KLQkgICAg JiYgIWlwc2VjcnQNCi0jZW5kaWYNCi0JICAgICkNCi0JCVJURlJFRShydCk7 DQogfQ0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMv bmV0aW5ldDYvaXA2X2lucHV0LmMgLi9zeXMvbmV0aW5ldDYvaXA2X2lucHV0 LmMNCi0tLSAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldDYv aXA2X2lucHV0LmMJMjAxMC0wOS0xOCAwMTo1NDoyOC4wMDAwMDAwMDAgKzAw MDANCisrKyAuL3N5cy9uZXRpbmV0Ni9pcDZfaW5wdXQuYwkyMDExLTA0LTA3 IDAyOjE0OjI4LjAwMDAwMDAwMCArMDAwMA0KQEAgLTMxMyw2ICszMTMsOCBA QA0KIAlpbnQgc3JjcnQgPSAwOw0KIAlzdHJ1Y3QgbGxlbnRyeSAqbGxlID0g TlVMTDsNCiAJc3RydWN0IHNvY2thZGRyX2luNiBkc3Q2LCAqZHN0Ow0KKwlz dHJ1Y3QgcnRsb29rdXAgcnRsOw0KKwlzdHJ1Y3Qgc29ja2FkZHJfZGwgZ2F0 ZXdheTsNCiANCiAJYnplcm8oJnJpbjYsIHNpemVvZihzdHJ1Y3Qgcm91dGVf aW42KSk7DQogI2lmZGVmIElQU0VDDQpAQCAtNjAzLDExICs2MDUsMTUgQEAN CiAJZHN0LT5zaW42X2xlbiA9IHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfaW42 KTsNCiAJZHN0LT5zaW42X2ZhbWlseSA9IEFGX0lORVQ2Ow0KIAlkc3QtPnNp bjZfYWRkciA9IGlwNi0+aXA2X2RzdDsNCi0JcmluNi5yb19ydCA9IHJ0YWxs b2MxKChzdHJ1Y3Qgc29ja2FkZHIgKilkc3QsIDAsIDApOw0KLQlpZiAocmlu Ni5yb19ydCkNCi0JCVJUX1VOTE9DSyhyaW42LnJvX3J0KTsNCiANCi0jZGVm aW5lIHJ0Nl9rZXkocikgKChzdHJ1Y3Qgc29ja2FkZHJfaW42ICopKChyKS0+ cnRfbm9kZXMtPnJuX2tleSkpDQorCWJ6ZXJvKCAmZ2F0ZXdheSwgc2l6ZW9m KGdhdGV3YXkpKTsNCisJZ2F0ZXdheS5zZGxfbGVuID0gc2l6ZW9mKGdhdGV3 YXkpOw0KKwlydGwucnRfZ2F0ZXdheSA9IChzdHJ1Y3Qgc29ja2FkZHIgKikm Z2F0ZXdheTsNCisJaWYgKCFydGxvb2t1cF9maWIoIChzdHJ1Y3Qgc29ja2Fk ZHIgKilkc3QsDQorCSAgICAwVSwgJnJ0bCwgMCkpDQorCQlyaW42LnJvX3J0 ID0gTlVMTDsNCisJZWxzZQ0KKwkJcmluNi5yb19ydCA9IChzdHJ1Y3QgcnRl bnRyeSAqKSZydGw7DQogDQogCS8qDQogCSAqIEFjY2VwdCB0aGUgcGFja2V0 IGlmIHRoZSBmb3J3YXJkaW5nIGludGVyZmFjZSB0byB0aGUgZGVzdGluYXRp b24NCkBAIC02MzgsMTUgKzY0NCw2IEBADQogI2lmZGVmIFJURl9DTE9ORUQN CiAJICAgICEocmluNi5yb19ydC0+cnRfZmxhZ3MgJiBSVEZfQ0xPTkVEKSAm Jg0KICNlbmRpZg0KLSNpZiAwDQotCSAgICAvKg0KLQkgICAgICogVGhlIGNo ZWNrIGJlbG93IGlzIHJlZHVuZGFudCBzaW5jZSB0aGUgY29tcGFyaXNvbiBv Zg0KLQkgICAgICogdGhlIGRlc3RpbmF0aW9uIGFuZCB0aGUga2V5IG9mIHRo ZSBydGVudHJ5IGhhcw0KLQkgICAgICogYWxyZWFkeSBkb25lIHRocm91Z2gg bG9va2luZyB1cCB0aGUgcm91dGluZyB0YWJsZS4NCi0JICAgICAqLw0KLQkg ICAgSU42X0FSRV9BRERSX0VRVUFMKCZpcDYtPmlwNl9kc3QsDQotCSAgICAm cnQ2X2tleShyaW42LnJvX3J0KS0+c2luNl9hZGRyKQ0KLSNlbmRpZg0KIAkg ICAgcmluNi5yb19ydC0+cnRfaWZwLT5pZl90eXBlID09IElGVF9MT09QKSB7 DQogCQlpbnQgZnJlZV9pYTYgPSAwOw0KIAkJc3RydWN0IGluNl9pZmFkZHIg KmlhNjsNCkBAIC03NjMsNyArNzYwLDcgQEANCiAjaWYgMAkvKnRvdWNoZXMg TlVMTCBwb2ludGVyKi8NCiAJCQlpbjZfaWZzdGF0X2luYyhtLT5tX3BrdGhk ci5yY3ZpZiwgaWZzNl9pbl9kaXNjYXJkKTsNCiAjZW5kaWYNCi0JCQlnb3Rv IG91dDsJLyogbSBoYXZlIGFscmVhZHkgYmVlbiBmcmVlZCAqLw0KKwkJCXJl dHVybjsJLyogbSBoYXZlIGFscmVhZHkgYmVlbiBmcmVlZCAqLw0KIAkJfQ0K IA0KIAkJLyogYWRqdXN0IHBvaW50ZXIgKi8NCkBAIC03ODYsNyArNzgzLDcg QEANCiAJCQlpY21wNl9lcnJvcihtLCBJQ01QNl9QQVJBTV9QUk9CLA0KIAkJ CQkgICAgSUNNUDZfUEFSQU1QUk9CX0hFQURFUiwNCiAJCQkJICAgIChjYWRk cl90KSZpcDYtPmlwNl9wbGVuIC0gKGNhZGRyX3QpaXA2KTsNCi0JCQlnb3Rv IG91dDsNCisJCQlyZXR1cm47DQogCQl9DQogI2lmbmRlZiBQVUxMRE9XTl9U RVNUDQogCQkvKiBpcDZfaG9wb3B0c19pbnB1dCgpIGVuc3VyZXMgdGhhdCBt YnVmIGlzIGNvbnRpZ3VvdXMgKi8NCkBAIC03OTYsNyArNzkzLDcgQEANCiAJ CQlzaXplb2Yoc3RydWN0IGlwNl9oYmgpKTsNCiAJCWlmIChoYmggPT0gTlVM TCkgew0KIAkJCVZfaXA2c3RhdC5pcDZzX3Rvb3Nob3J0Kys7DQotCQkJZ290 byBvdXQ7DQorCQkJcmV0dXJuOw0KIAkJfQ0KICNlbmRpZg0KIAkJbnh0ID0g aGJoLT5pcDZoX254dDsNCkBAIC04NjgsNyArODY1LDcgQEANCiAJCX0NCiAJ fSBlbHNlIGlmICghb3Vycykgew0KIAkJaXA2X2ZvcndhcmQobSwgc3JjcnQp Ow0KLQkJZ290byBvdXQ7DQorCQlyZXR1cm47DQogCX0NCiANCiAJaXA2ID0g bXRvZChtLCBzdHJ1Y3QgaXA2X2hkciAqKTsNCkBAIC05MzEsMTIgKzkyOCw5 IEBADQogDQogCQlueHQgPSAoKmluZXQ2c3dbaXA2X3Byb3RveFtueHRdXS5w cl9pbnB1dCkoJm0sICZvZmYsIG54dCk7DQogCX0NCi0JZ290byBvdXQ7DQor CXJldHVybjsNCiBiYWQ6DQogCW1fZnJlZW0obSk7DQotb3V0Og0KLQlpZiAo cmluNi5yb19ydCkNCi0JCVJURlJFRShyaW42LnJvX3J0KTsNCiB9DQogDQog LyoNCmRpZmYgLXUgLXIgLi4vc3JjX29yZ184LjJfMjAxMTAzMjkvc3lzL25l dGluZXQ2L2lwNl9vdXRwdXQuYyAuL3N5cy9uZXRpbmV0Ni9pcDZfb3V0cHV0 LmMNCi0tLSAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9zeXMvbmV0aW5ldDYv aXA2X291dHB1dC5jCTIwMTAtMTAtMjUgMTM6MTY6MTEuMDAwMDAwMDAwICsw MDAwDQorKysgLi9zeXMvbmV0aW5ldDYvaXA2X291dHB1dC5jCTIwMTEtMDQt MTQgMTY6MzM6MDQuMDAwMDAwMDAwICswMDAwDQpAQCAtODIsNiArODIsNyBA QA0KICNpbmNsdWRlIDxzeXMvdWNyZWQuaD4NCiANCiAjaW5jbHVkZSA8bmV0 L2lmLmg+DQorI2luY2x1ZGUgPG5ldC9pZl9kbC5oPg0KICNpbmNsdWRlIDxu ZXQvbmV0aXNyLmg+DQogI2luY2x1ZGUgPG5ldC9yb3V0ZS5oPg0KICNpbmNs dWRlIDxuZXQvcGZpbC5oPg0KQEAgLTEzNSw3ICsxMzYsOCBAQA0KIHN0YXRp YyBpbnQgaXA2X2luc2VydF9qdW1ib29wdChzdHJ1Y3QgaXA2X2V4dGhkcnMg KiwgdV9pbnQzMl90KTsNCiBzdGF0aWMgaW50IGlwNl9zcGxpdGhkcihzdHJ1 Y3QgbWJ1ZiAqLCBzdHJ1Y3QgaXA2X2V4dGhkcnMgKik7DQogc3RhdGljIGlu dCBpcDZfZ2V0cG10dSBfX1AoKHN0cnVjdCByb3V0ZV9pbjYgKiwgc3RydWN0 IHJvdXRlX2luNiAqLA0KLQlzdHJ1Y3QgaWZuZXQgKiwgc3RydWN0IGluNl9h ZGRyICosIHVfbG9uZyAqLCBpbnQgKikpOw0KKwlzdHJ1Y3QgaWZuZXQgKiwg c3RydWN0IGluNl9hZGRyICosIHVfbG9uZyAqLCBpbnQgKiwgaW50ICosIA0K KwlzdHJ1Y3QgcnRsb29rdXAgKiwgc3RydWN0IHNvY2thZGRyX2RsICopKTsN CiBzdGF0aWMgaW50IGNvcHlwa3RvcHRzKHN0cnVjdCBpcDZfcGt0b3B0cyAq LCBzdHJ1Y3QgaXA2X3BrdG9wdHMgKiwgaW50KTsNCiANCiANCkBAIC0yMTMs NiArMjE1LDEwIEBADQogCXN0cnVjdCByb3V0ZV9pbjYgKnJvX3BtdHUgPSBO VUxMOw0KIAlpbnQgaGRyc3BsaXQgPSAwOw0KIAlpbnQgbmVlZGlwc2VjID0g MDsNCisJc3RydWN0IHJ0bG9va3VwIHJ0bDsNCisJc3RydWN0IHNvY2thZGRy X2RsIGdhdGV3YXk7DQorCWludCByb19wcm92aWRlZCA9IDE7DQorCWludCBu b3J0ZnJlZSA9IDA7DQogI2lmZGVmIFNDVFANCiAJaW50IHN3X2NzdW07DQog I2VuZGlmDQpAQCAtNDYzLDYgKzQ2OSw3IEBADQogCSAqIFJvdXRlIHBhY2tl dC4NCiAJICovDQogCWlmIChybyA9PSAwKSB7DQorCSAgICAgICAgcm9fcHJv dmlkZWQgPSAwOw0KIAkJcm8gPSAmaXA2cm91dGU7DQogCQliemVybygoY2Fk ZHJfdClybywgc2l6ZW9mKCpybykpOw0KIAl9DQpAQCAtNTIxLDcgKzUyOCwx NSBAQA0KIAkJc3RhdGUucm8gPSAoc3RydWN0IHJvdXRlICopcm87DQogCQlz dGF0ZS5kc3QgPSAoc3RydWN0IHNvY2thZGRyICopZHN0Ow0KIA0KLQkJZXJy b3IgPSBpcHNlYzZfb3V0cHV0X3R1bm5lbCgmc3RhdGUsIHNwLCBmbGFncyk7 DQorCQkvKiBjaGVjayBpZiBjYWxsZXIgZG9lcyBub3QgZnJlZSByb19ydCwg YXMgbmVlZGVkIGJ5DQorCQkgKiBydGxvb2t1cF8obXBhdGgpX2ZpYg0KKwkJ ICovDQorCQlpZiAocm9fcHJvdmlkZWQpDQorCQkJZXJyb3IgPSBpcHNlYzZf b3V0cHV0X3R1bm5lbCgmc3RhdGUsIHNwLCBmbGFncywgTlVMTCwgDQorCQkJ ICAgIE5VTEwsICZub3J0ZnJlZSk7DQorCQllbHNlDQorCQkJZXJyb3IgPSBp cHNlYzZfb3V0cHV0X3R1bm5lbCgmc3RhdGUsIHNwLCBmbGFncywgJnJ0bCwN CisJCQkgICAgKHN0cnVjdCBzb2NrYWRkciAqKSZnYXRld2F5LCAmbm9ydGZy ZWUpOw0KIA0KIAkJbSA9IHN0YXRlLm07DQogCQlybyA9IChzdHJ1Y3Qgcm91 dGVfaW42ICopc3RhdGUucm87DQpAQCAtNTc2LDE1ICs1OTEsMjYgQEANCiAJ ZHN0X3NhLnNpbjZfZmFtaWx5ID0gQUZfSU5FVDY7DQogCWRzdF9zYS5zaW42 X2xlbiA9IHNpemVvZihkc3Rfc2EpOw0KIAlkc3Rfc2Euc2luNl9hZGRyID0g aXA2LT5pcDZfZHN0Ow0KLQlpZiAoKGVycm9yID0gaW42X3NlbGVjdHJvdXRl KCZkc3Rfc2EsIG9wdCwgaW02bywgcm8sDQotCSAgICAmaWZwLCAmcnQpKSAh PSAwKSB7DQorCS8qIGNoZWNrIGlmIGNhbGxlciBkb2VzIG5vdCBmcmVlIHJv X3J0LCBhcyBuZWVkZWQgYnkNCisJICogcnRsb29rdXBfKG1wYXRoKV9maWIN CisJICovDQorCWlmIChyb19wcm92aWRlZCkgew0KKwkJZXJyb3IgPSBpbjZf c2VsZWN0cm91dGUoJmRzdF9zYSwgb3B0LCBpbTZvLCBybywgJmlmcCwgJnJ0 KTsNCisJfSBlbHNlIHsNCisJCWJ6ZXJvKCAmZ2F0ZXdheSwgc2l6ZW9mKGdh dGV3YXkpKTsNCisJCWdhdGV3YXkuc2RsX2xlbiA9IHNpemVvZihnYXRld2F5 KTsNCisJCXJ0bC5ydF9nYXRld2F5ID0gKHN0cnVjdCBzb2NrYWRkciAqKSZn YXRld2F5Ow0KKwkJZXJyb3IgPSBpbjZfbG9va3VwKCZkc3Rfc2EsIG9wdCwg aW02bywgcm8sICZydGwsICZpZnAsICZydCk7DQorCQlub3J0ZnJlZSA9IDE7 DQorCX0NCisJaWYgKGVycm9yICE9IDApIHsNCiAJCXN3aXRjaCAoZXJyb3Ip IHsNCi0JCWNhc2UgRUhPU1RVTlJFQUNIOg0KLQkJCVZfaXA2c3RhdC5pcDZz X25vcm91dGUrKzsNCi0JCQlicmVhazsNCi0JCWNhc2UgRUFERFJOT1RBVkFJ TDoNCi0JCWRlZmF1bHQ6DQotCQkJYnJlYWs7IC8qIFhYWCBzdGF0aXN0aWNz PyAqLw0KKwkJCWNhc2UgRUhPU1RVTlJFQUNIOg0KKwkJCQlWX2lwNnN0YXQu aXA2c19ub3JvdXRlKys7DQorCQkJCWJyZWFrOw0KKwkJCWNhc2UgRUFERFJO T1RBVkFJTDoNCisJCQlkZWZhdWx0Og0KKwkJCQlicmVhazsgLyogWFhYIHN0 YXRpc3RpY3M/ICovDQogCQl9DQogCQlpZiAoaWZwICE9IE5VTEwpDQogCQkJ aW42X2lmc3RhdF9pbmMoaWZwLCBpZnM2X291dF9kaXNjYXJkKTsNCkBAIC01 OTIsNyArNjE4LDcgQEANCiAJfQ0KIAlpZiAocnQgPT0gTlVMTCkgew0KIAkJ LyoNCi0JCSAqIElmIGluNl9zZWxlY3Ryb3V0ZSgpIGRvZXMgbm90IHJldHVy biBhIHJvdXRlIGVudHJ5LA0KKwkJICogSWYgaW42X3NlbGVjdHJvdXRlKCkv aW42X2xvb2t1cCgpIGRvZXMgbm90IHJldHVybiBhIHJvdXRlIGVudHJ5LA0K IAkJICogZHN0IG1heSBub3QgaGF2ZSBiZWVuIHVwZGF0ZWQuDQogCQkgKi8N CiAJCSpkc3QgPSBkc3Rfc2E7CS8qIFhYWCAqLw0KQEAgLTc0MywxMSArNzY5 LDIwIEBADQogCWlmIChpZnBwKQ0KIAkJKmlmcHAgPSBpZnA7DQogDQotCS8q IERldGVybWluZSBwYXRoIE1UVS4gKi8NCi0JaWYgKChlcnJvciA9IGlwNl9n ZXRwbXR1KHJvX3BtdHUsIHJvLCBpZnAsICZmaW5hbGRzdCwgJm10dSwNCi0J ICAgICZhbHdheXNmcmFnKSkgIT0gMCkNCi0JCWdvdG8gYmFkOw0KLQ0KKwkv KiBEZXRlcm1pbmUgcGF0aCBNVFUuDQorCSAqIGNoZWNrIGlmIGNhbGxlciBk b2VzIG5vdCBmcmVlIHJvX3J0LCBhcyBuZWVkZWQgYnkNCisJICogcnRsb29r dXBfKG1wYXRoKV9maWINCisJICovDQorCWlmIChyb19wcm92aWRlZCkgew0K KwkJaWYgKChlcnJvciA9IGlwNl9nZXRwbXR1KHJvX3BtdHUsIHJvLCBpZnAs ICZmaW5hbGRzdCwgJm10dSwNCisgICAgICAgICAgICAgICAgICAgICZhbHdh eXNmcmFnLCAmbm9ydGZyZWUsIE5VTEwsIE5VTEwpKSAhPSAwKQ0KKwkJCWdv dG8gYmFkOw0KKwl9IGVsc2Ugew0KKwkJaWYgKChlcnJvciA9IGlwNl9nZXRw bXR1KHJvX3BtdHUsIHJvLCBpZnAsICZmaW5hbGRzdCwgJm10dSwNCisgICAg ICAgICAgICAgICAgICAgICZhbHdheXNmcmFnLCAmbm9ydGZyZWUsICZydGws ICZnYXRld2F5KSkgIT0gMCkNCisJCQlnb3RvIGJhZDsNCisJfQ0KKwkJCQ0K IAkvKg0KIAkgKiBUaGUgY2FsbGVyIG9mIHRoaXMgZnVuY3Rpb24gbWF5IHNw ZWNpZnkgdG8gdXNlIHRoZSBtaW5pbXVtIE1UVQ0KIAkgKiBpbiBzb21lIGNh c2VzLg0KQEAgLTEwNzEsOSArMTEwNiw5IEBADQogCQlWX2lwNnN0YXQuaXA2 c19mcmFnbWVudGVkKys7DQogDQogZG9uZToNCi0JaWYgKHJvID09ICZpcDZy b3V0ZSAmJiByby0+cm9fcnQpIHsgLyogYnJhY2UgbmVjZXNzYXJ5IGZvciBS VEZSRUUgKi8NCisJaWYgKHJvID09ICZpcDZyb3V0ZSAmJiByby0+cm9fcnQg JiYgIW5vcnRmcmVlKSB7IC8qIGJyYWNlIG5lY2Vzc2FyeSBmb3IgUlRGUkVF ICovDQogCQlSVEZSRUUocm8tPnJvX3J0KTsNCi0JfSBlbHNlIGlmIChyb19w bXR1ID09ICZpcDZyb3V0ZSAmJiByb19wbXR1LT5yb19ydCkgew0KKwl9IGVs c2UgaWYgKHJvX3BtdHUgPT0gJmlwNnJvdXRlICYmIHJvX3BtdHUtPnJvX3J0 ICYmICFub3J0ZnJlZSkgew0KIAkJUlRGUkVFKHJvX3BtdHUtPnJvX3J0KTsN CiAJfQ0KICNpZmRlZiBJUFNFQw0KQEAgLTEyNjQsNyArMTI5OSw3IEBADQog c3RhdGljIGludA0KIGlwNl9nZXRwbXR1KHN0cnVjdCByb3V0ZV9pbjYgKnJv X3BtdHUsIHN0cnVjdCByb3V0ZV9pbjYgKnJvLA0KICAgICBzdHJ1Y3QgaWZu ZXQgKmlmcCwgc3RydWN0IGluNl9hZGRyICpkc3QsIHVfbG9uZyAqbXR1cCwN Ci0gICAgaW50ICphbHdheXNmcmFncCkNCisgICAgaW50ICphbHdheXNmcmFn cCwgaW50ICpub3J0ZnJlZSwgc3RydWN0IHJ0bG9va3VwICpydGwsIHN0cnVj dCBzb2NrYWRkcl9kbCAqZ2F0ZXdheSkNCiB7DQogCXVfaW50MzJfdCBtdHUg PSAwOw0KIAlpbnQgYWx3YXlzZnJhZyA9IDA7DQpAQCAtMTI3Nyw3ICsxMzEy LDggQEANCiAJCWlmIChyb19wbXR1LT5yb19ydCAmJg0KIAkJICAgICgocm9f cG10dS0+cm9fcnQtPnJ0X2ZsYWdzICYgUlRGX1VQKSA9PSAwIHx8DQogCQkg ICAgICFJTjZfQVJFX0FERFJfRVFVQUwoJnNhNl9kc3QtPnNpbjZfYWRkciwg ZHN0KSkpIHsNCi0JCQlSVEZSRUUocm9fcG10dS0+cm9fcnQpOw0KKwkJCWlm IChydGwgPT0gTlVMTCkNCisJCQkJUlRGUkVFKHJvX3BtdHUtPnJvX3J0KTsN CiAJCQlyb19wbXR1LT5yb19ydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKU5VTEw7 DQogCQl9DQogCQlpZiAocm9fcG10dS0+cm9fcnQgPT0gTlVMTCkgew0KQEAg LTEyODYsNyArMTMyMiwxOSBAQA0KIAkJCXNhNl9kc3QtPnNpbjZfbGVuID0g c2l6ZW9mKHN0cnVjdCBzb2NrYWRkcl9pbjYpOw0KIAkJCXNhNl9kc3QtPnNp bjZfYWRkciA9ICpkc3Q7DQogDQotCQkJcnRhbGxvYygoc3RydWN0IHJvdXRl ICopcm9fcG10dSk7DQorCQkJaWYgKHJ0bCA9PSBOVUxMKQ0KKwkJCQlydGFs bG9jKChzdHJ1Y3Qgcm91dGUgKilyb19wbXR1KTsNCisJCQllbHNlIHsNCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJ6ZXJvKCBnYXRld2F5 LCBzaXplb2YoIHN0cnVjdCBzb2NrYWRkcl9kbCkpOw0KKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZ2F0ZXdheS0+c2RsX2xlbiA9IHNpemVv ZihzdHJ1Y3Qgc29ja2FkZHJfZGwpOw0KKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcnRsLT5ydF9nYXRld2F5ID0gKHN0cnVjdCBzb2NrYWRk ciAqKWdhdGV3YXk7DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpZiAoIXJ0bG9va3VwX2ZpYiggKHN0cnVjdCBzb2NrYWRkciAqKXNhNl9k c3QsIDAsIHJ0bCwgMCkpDQorCQkJCQlyb19wbXR1LT5yb19ydCA9IE5VTEw7 DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbHNlIHsNCisJ CQkJCXJvX3BtdHUtPnJvX3J0ID0gKHN0cnVjdCBydGVudHJ5ICopcnRsOw0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqbm9y dGZyZWUgPSAxOw0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fQ0KKwkJCX0NCiAJCX0NCiAJfQ0KIAlpZiAocm9fcG10dS0+cm9fcnQpIHsN CkBAIC0xODg3LDcgKzE5MzUsNyBAQA0KIAkJCQkgKiB0aGUgb3V0Z29pbmcg aW50ZXJmYWNlLg0KIAkJCQkgKi8NCiAJCQkJZXJyb3IgPSBpcDZfZ2V0cG10 dSgmc3JvLCBOVUxMLCBOVUxMLA0KLQkJCQkgICAgJmluNnAtPmluNnBfZmFk ZHIsICZwbXR1LCBOVUxMKTsNCisJCQkJICAgICZpbjZwLT5pbjZwX2ZhZGRy LCAmcG10dSwgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCk7DQogCQkJCWlmIChz cm8ucm9fcnQpDQogCQkJCQlSVEZSRUUoc3JvLnJvX3J0KTsNCiAJCQkJaWYg KGVycm9yKQ0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzguMl8yMDExMDMyOS9z eXMvbmV0aW5ldDYvaXA2X3Zhci5oIC4vc3lzL25ldGluZXQ2L2lwNl92YXIu aA0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpbmV0Ni9p cDZfdmFyLmgJMjAxMC0wOS0wOSAwNjo0MzoxOC4wMDAwMDAwMDAgKzAwMDAN CisrKyAuL3N5cy9uZXRpbmV0Ni9pcDZfdmFyLmgJMjAxMS0wNC0wNyAxMTo1 NDoxNi4wMDAwMDAwMDAgKzAwMDANCkBAIC00MzEsMTIgKzQzMSwxNiBAQA0K IGludAlkZXN0Nl9pbnB1dCBfX1AoKHN0cnVjdCBtYnVmICoqLCBpbnQgKiwg aW50KSk7DQogaW50CW5vbmVfaW5wdXQgX19QKChzdHJ1Y3QgbWJ1ZiAqKiwg aW50ICosIGludCkpOw0KIA0KKyNpbmNsdWRlIDxuZXQvcm91dGUuaD4NCiBp bnQJaW42X3NlbGVjdHNyYyhzdHJ1Y3Qgc29ja2FkZHJfaW42ICosIHN0cnVj dCBpcDZfcGt0b3B0cyAqLA0KIAlzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0 IHJvdXRlX2luNiAqLCBzdHJ1Y3QgdWNyZWQgKmNyZWQsDQogCXN0cnVjdCBp Zm5ldCAqKiwgc3RydWN0IGluNl9hZGRyICopOw0KIGludCBpbjZfc2VsZWN0 cm91dGUgX19QKChzdHJ1Y3Qgc29ja2FkZHJfaW42ICosIHN0cnVjdCBpcDZf cGt0b3B0cyAqLA0KIAlzdHJ1Y3QgaXA2X21vcHRpb25zICosIHN0cnVjdCBy b3V0ZV9pbjYgKiwgc3RydWN0IGlmbmV0ICoqLA0KIAlzdHJ1Y3QgcnRlbnRy eSAqKikpOw0KK2ludCBpbjZfbG9va3VwIF9fUCgoc3RydWN0IHNvY2thZGRy X2luNiAqLCBzdHJ1Y3QgaXA2X3BrdG9wdHMgKiwNCisJc3RydWN0IGlwNl9t b3B0aW9ucyAqLCBzdHJ1Y3Qgcm91dGVfaW42ICosIHN0cnVjdCBydGxvb2t1 cCAqLA0KKwlzdHJ1Y3QgaWZuZXQgKiosIHN0cnVjdCBydGVudHJ5ICoqKSk7 DQogdV9pbnQzMl90IGlwNl9yYW5kb21pZCBfX1AoKHZvaWQpKTsNCiB1X2lu dDMyX3QgaXA2X3JhbmRvbWZsb3dsYWJlbCBfX1AoKHZvaWQpKTsNCiAjZW5k aWYgLyogX0tFUk5FTCAqLw0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzguMl8y MDExMDMyOS9zeXMvbmV0aW5ldDYvbmQ2X25ici5jIC4vc3lzL25ldGluZXQ2 L25kNl9uYnIuYw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9u ZXRpbmV0Ni9uZDZfbmJyLmMJMjAxMS0wNC0xMiAxMzowMjowNC4wMDAwMDAw MDAgKzAwMDANCisrKyAuL3N5cy9uZXRpbmV0Ni9uZDZfbmJyLmMJMjAxMS0w NC0xMiAxNjowNjoyNi4wMDAwMDAwMDAgKzAwMDANCkBAIC0yNTYsNyArMjU2 LDExIEBADQogCQkJICovDQogCQkJaWYgKG5lZWRfcHJveHkpDQogCQkJCXBy b3h5ZGwgPSAqU0RMKHJ0LT5ydF9nYXRld2F5KTsNCisjaWZkZWYgUkFESVhf TVBBVEgNCisJCQlSVEZSRUUocnQpOyAgICAgLyogcnRhbGxvY19tcGF0aCBk b2VzIG5vdCByZXR1cm4gYSBsb2NrZWQgcm91dGUgKi8NCisjZWxzZQ0KIAkJ CVJURlJFRV9MT0NLRUQocnQpOw0KKyNlbmRpZg0KIAkJfQ0KIAkJaWYgKG5l ZWRfcHJveHkpIHsNCiAJCQkvKg0KZGlmZiAtdSAtciAuLi9zcmNfb3JnXzgu Ml8yMDExMDMyOS9zeXMvbmV0aW5ldDYvbmQ2X3J0ci5jIC4vc3lzL25ldGlu ZXQ2L25kNl9ydHIuYw0KLS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5 cy9uZXRpbmV0Ni9uZDZfcnRyLmMJMjAxMC0wNS0wNiAwNjo0NDoxOS4wMDAw MDAwMDAgKzAwMDANCisrKyAuL3N5cy9uZXRpbmV0Ni9uZDZfcnRyLmMJMjAx MS0wNC0wMyAxNjowNzo1Ny4wMDAwMDAwMDAgKzAwMDANCkBAIC00OCw2ICs0 OCw4IEBADQogI2luY2x1ZGUgPHN5cy9yd2xvY2suaD4NCiAjaW5jbHVkZSA8 c3lzL3N5c2xvZy5oPg0KICNpbmNsdWRlIDxzeXMvcXVldWUuaD4NCisjaW5j bHVkZSA8c3lzL2xvY2suaD4NCisjaW5jbHVkZSA8c3lzL3JtbG9jay5oPg0K IA0KICNpbmNsdWRlIDxuZXQvaWYuaD4NCiAjaW5jbHVkZSA8bmV0L2lmX3R5 cGVzLmg+DQpkaWZmIC11IC1yIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5 cy9uZXRpcHNlYy9pcHNlYzYuaCAuL3N5cy9uZXRpcHNlYy9pcHNlYzYuaA0K LS0tIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpcHNlYy9pcHNl YzYuaAkyMDEwLTA5LTE4IDAxOjU0OjI4LjAwMDAwMDAwMCArMDAwMA0KKysr IC4vc3lzL25ldGlwc2VjL2lwc2VjNi5oCTIwMTEtMDQtMDggMTI6NTc6NDUu MDAwMDAwMDAwICswMDAwDQpAQCAtNzIsNyArNzIsOCBAQA0KIGV4dGVybiBp bnQgaXBzZWM2X291dHB1dF90cmFucyBfX1AoKHN0cnVjdCBpcHNlY19vdXRw dXRfc3RhdGUgKiwgdV9jaGFyICosDQogCXN0cnVjdCBtYnVmICosIHN0cnVj dCBzZWNwb2xpY3kgKiwgaW50LCBpbnQgKikpOw0KIGV4dGVybiBpbnQgaXBz ZWM2X291dHB1dF90dW5uZWwgX19QKChzdHJ1Y3QgaXBzZWNfb3V0cHV0X3N0 YXRlICosDQotCXN0cnVjdCBzZWNwb2xpY3kgKiwgaW50KSk7DQorCXN0cnVj dCBzZWNwb2xpY3kgKiwgaW50LCBzdHJ1Y3QgcnRsb29rdXAgKiwgc3RydWN0 IHNvY2thZGRyICosDQorCWludCAqKSk7DQogI2VuZGlmIC8qX0tFUk5FTCov DQogDQogI2VuZGlmIC8qX05FVElQU0VDX0lQU0VDNl9IXyovDQpkaWZmIC11 IC1yIC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpcHNlYy9pcHNl Y19vdXRwdXQuYyAuL3N5cy9uZXRpcHNlYy9pcHNlY19vdXRwdXQuYw0KLS0t IC4uL3NyY19vcmdfOC4yXzIwMTEwMzI5L3N5cy9uZXRpcHNlYy9pcHNlY19v dXRwdXQuYwkyMDExLTAyLTIyIDE5OjM5OjA4LjAwMDAwMDAwMCArMDAwMA0K KysrIC4vc3lzL25ldGlwc2VjL2lwc2VjX291dHB1dC5jCTIwMTEtMDQtMDgg MTI6NTY6MzguMDAwMDAwMDAwICswMDAwDQpAQCAtNDQsNiArNDQsNyBAQA0K ICNpbmNsdWRlIDxzeXMvc3lzbG9nLmg+DQogDQogI2luY2x1ZGUgPG5ldC9p Zi5oPg0KKyNpbmNsdWRlIDxuZXQvaWZfZGwuaD4NCiAjaW5jbHVkZSA8bmV0 L3BmaWwuaD4NCiAjaW5jbHVkZSA8bmV0L3JvdXRlLmg+DQogI2luY2x1ZGUg PG5ldC92bmV0Lmg+DQpAQCAtNzUyLDcgKzc1Myw4IEBADQogICogSVBzZWMg b3V0cHV0IGxvZ2ljIGZvciBJUHY2LCB0dW5uZWwgbW9kZS4NCiAgKi8NCiBp bnQNCi1pcHNlYzZfb3V0cHV0X3R1bm5lbChzdHJ1Y3QgaXBzZWNfb3V0cHV0 X3N0YXRlICpzdGF0ZSwgc3RydWN0IHNlY3BvbGljeSAqc3AsIGludCBmbGFn cykNCitpcHNlYzZfb3V0cHV0X3R1bm5lbChzdHJ1Y3QgaXBzZWNfb3V0cHV0 X3N0YXRlICpzdGF0ZSwgc3RydWN0IHNlY3BvbGljeSAqc3AsDQorICAgIGlu dCBmbGFncywgc3RydWN0IHJ0bG9va3VwICpydGwsIHN0cnVjdCBzb2NrYWRk ciAqZ2F0ZXdheSwgaW50ICpub3J0ZnJlZSkNCiB7DQogCXN0cnVjdCBpcDZf aGRyICppcDY7DQogCXN0cnVjdCBpcHNlY3JlcXVlc3QgKmlzcjsNCkBAIC03 NjAsNyArNzYyLDcgQEANCiAJaW50IGVycm9yOw0KIAlzdHJ1Y3Qgc29ja2Fk ZHJfaW42ICpkc3Q2Ow0KIAlzdHJ1Y3QgbWJ1ZiAqbTsNCi0NCisJDQogCUlQ U0VDX0FTU0VSVChzdGF0ZSAhPSBOVUxMLCAoIm51bGwgc3RhdGUiKSk7DQog CUlQU0VDX0FTU0VSVChzdGF0ZS0+bSAhPSBOVUxMLCAoIm51bGwgbSIpKTsN CiAJSVBTRUNfQVNTRVJUKHNwICE9IE5VTEwsICgibnVsbCBzcCIpKTsNCkBA IC04MzYsNyArODM4LDggQEANCiAJCWlmIChzdGF0ZS0+cm8tPnJvX3J0DQog CQkgJiYgKChzdGF0ZS0+cm8tPnJvX3J0LT5ydF9mbGFncyAmIFJURl9VUCkg PT0gMA0KIAkJICB8fCAhSU42X0FSRV9BRERSX0VRVUFMKCZkc3Q2LT5zaW42 X2FkZHIsICZpcDYtPmlwNl9kc3QpKSkgew0KLQkJCVJURlJFRShzdGF0ZS0+ cm8tPnJvX3J0KTsNCisJCQlpZiAocnRsID09IE5VTEwpDQorCQkJCVJURlJF RShzdGF0ZS0+cm8tPnJvX3J0KTsNCiAJCQlzdGF0ZS0+cm8tPnJvX3J0ID0g TlVMTDsNCiAJCX0NCiAJCWlmIChzdGF0ZS0+cm8tPnJvX3J0ID09IE5VTEwp IHsNCkBAIC04NDQsNyArODQ3LDIwIEBADQogCQkJZHN0Ni0+c2luNl9mYW1p bHkgPSBBRl9JTkVUNjsNCiAJCQlkc3Q2LT5zaW42X2xlbiA9IHNpemVvZigq ZHN0Nik7DQogCQkJZHN0Ni0+c2luNl9hZGRyID0gaXA2LT5pcDZfZHN0Ow0K LQkJCXJ0YWxsb2Moc3RhdGUtPnJvKTsNCisNCisJCQlpZiAocnRsID09IE5V TEwpDQorCQkJCXJ0YWxsb2Moc3RhdGUtPnJvKTsNCisJCQllbHNlIHsNCisJ CQkJYnplcm8oIGdhdGV3YXksIHNpemVvZiggc3RydWN0IHNvY2thZGRyX2Rs KSk7DQorCQkJCWdhdGV3YXktPnNhX2xlbiA9IHNpemVvZihzdHJ1Y3Qgc29j a2FkZHJfZGwpOw0KKwkJCQlydGwtPnJ0X2dhdGV3YXkgPSAoc3RydWN0IHNv Y2thZGRyICopZ2F0ZXdheTsNCisJCQkJaWYgKCFydGxvb2t1cF9maWIoIChz dHJ1Y3Qgc29ja2FkZHIgKilkc3Q2LCAwLCBydGwsIDApKQ0KKwkJCQkJc3Rh dGUtPnJvLT5yb19ydCA9IE5VTEw7DQorCQkJCWVsc2Ugew0KKwkJCQkJc3Rh dGUtPnJvLT5yb19ydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKXJ0bDsNCisJCQkJ CSpub3J0ZnJlZSA9IDE7DQorCQkJCX0NCisJCQl9DQogCQl9DQogCQlpZiAo c3RhdGUtPnJvLT5yb19ydCA9PSBOVUxMKSB7DQogCQkJVl9pcDZzdGF0Lmlw NnNfbm9yb3V0ZSsrOw0K --168430090-2014229598-1303080817=:8693-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 18 11:07:04 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E26401065673 for ; Mon, 18 Apr 2011 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CEC6D8FC27 for ; Mon, 18 Apr 2011 11:07:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3IB74EX019561 for ; Mon, 18 Apr 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3IB74aF019559 for freebsd-net@FreeBSD.org; Mon, 18 Apr 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Apr 2011 11:07:04 GMT Message-Id: <201104181107.p3IB74aF019559@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155636 net [msk] msk driver locks marvel yukon 88E8057 NIC o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [routed] [patch] if.c in routed fails to compile if ti o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R p kern/154676 net [netgraph] [panic] HEAD, 8.1-RELEASE panic after some o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154567 net [ath] ath(4) lot of bad series(0) o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154284 net [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153671 net [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153255 net [panic] 8.2-PRERELEASE repeatable kernel panic under h o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125617 net [ath] [panic] ath(4) related panic o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 371 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 18 11:33:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7C571065686 for ; Mon, 18 Apr 2011 11:33:36 +0000 (UTC) (envelope-from abuse@cj-vollblutaraber.de) Received: from res7.worldserver.net (res7.worldserver.net [217.13.199.17]) by mx1.freebsd.org (Postfix) with SMTP id E768A8FC35 for ; Mon, 18 Apr 2011 11:33:35 +0000 (UTC) Received: (qmail 3928 invoked by uid 65534); 18 Apr 2011 11:22:10 -0000 Date: 18 Apr 2011 11:22:10 -0000 Message-ID: <20110418112210.3927.qmail@res7.worldserver.net> To: freebsd-net@freebsd.org From: Dr.Ban Ki-moon. MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: Congratulation, URGENT RESPONSE IS NEEDED X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: courierservice@one.co.il List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:33:36 -0000 Congratulation, I just received a call from the Director of Scarlet Courier Service Company Nigeria that the consignment box that was sent to you was returned due to wrong address, This consignment box contained your $5.500.000.00 united state dollars, Your compensation fund.Therefore call the director (Williams Wright) on Tel: (+234705-550-1921 ) email him at: (couierservice@one.co.il) and give him your correct address and Phone number: So the Information you are Required to Reconfirm to the Agent is as Follow. (1)Your Full Name============= (2)Mobile Phone Number====== (3)Current Home Address======== (4)Occupation================= (5)Fax Number================ (6)Country==================== (7)City===================== (8)Nearest Airport ============== (9)A Copy of Your I D For Identification Use this code (XA-8550) as the subject of your mail to them for identification. Yours Truly. Dr. Ban Ki-moon. From owner-freebsd-net@FreeBSD.ORG Mon Apr 18 16:04:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2AB3106564A for ; Mon, 18 Apr 2011 16:04:29 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 826518FC0C for ; Mon, 18 Apr 2011 16:04:29 +0000 (UTC) Received: by pvg11 with SMTP id 11so2941205pvg.13 for ; Mon, 18 Apr 2011 09:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iO7QPUWJJHm318w3iZa+yTF/WcqPB5v8e8kxw9luwGE=; b=MpnBg7cxORyI1skqFS/H/MsT2f1xxJNKRZIj7wh4kxGBjb9/oh6EZw1Yfh9E44Cz0y 2OWrVWyovHCwc5pJvr1b4vPFTjnF6NVmliN+ZDhl6kbbnisfwn8Ya93ZN2oGrhlYh9xY YZeber7cs5t4G0j75NTWzQMZ+hE8csVeTZa8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Mt6AXsN9kUfGMW0lwZKb/cljHY4AWSb/8hSudDn9AlpU7mmAzR19UCWQOwI/5FAPJM UEp0UapabGiyACTY6+TUUFwPDBwKYawQ2AT0KKPY2sF8O5qOXKPR+GOLq7v1bN0IE89I 1Np1sJTaPXT2uJPxg/KMqUdf3aabNP28J6gig= MIME-Version: 1.0 Received: by 10.68.50.66 with SMTP id a2mr7392010pbo.490.1303142668502; Mon, 18 Apr 2011 09:04:28 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.68.41.101 with HTTP; Mon, 18 Apr 2011 09:04:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2011 18:04:28 +0200 X-Google-Sender-Auth: IUhjvpLhgAceWrFOQU51oI7GYu0 Message-ID: From: "K. Macy" To: Ingo Flaschberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:04:29 -0000 It would be great to see flowtable going back to its intended use. However, I would be surprised if this actually scales to Mpps. I don't have any high end hardware at the moment to test, what is the highest packet rate you've seen? i.e. simply generating small packets. Thanks On Mon, Apr 18, 2011 at 12:53 AM, Ingo Flaschberger wrote: > > attached a new version of this patch with some improvements and bug-fixes= . > Test-Reports are welcome. > > Kind regards, > =A0 =A0 =A0 =A0Ingo Flaschberger > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 18 17:19:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E3091065678 for ; Mon, 18 Apr 2011 17:19:01 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 800CD8FC0C for ; Mon, 18 Apr 2011 17:18:59 +0000 (UTC) Received: (qmail 3872 invoked from network); 18 Apr 2011 19:12:16 +0200 Received: from unknown (HELO filebunker.xip.at) (89.207.145.147) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2011 19:12:16 +0200 Date: Mon, 18 Apr 2011 19:12:15 +0200 (CEST) From: Ingo Flaschberger To: "K. Macy" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Ingo Flaschberger Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:19:01 -0000 > It would be great to see flowtable going back to its intended use. > However, I would be surprised if this actually scales to Mpps. I don't > have any high end hardware at the moment to test, what is the highest > packet rate you've seen? i.e. simply generating small packets. Currently I have no tests available, but I have seen at a appliance with: Intel Q35 Quad Core cpu Intel em desktop pcie cards ~ 200mbit 64byte packets - ~ 400kpps without packetloss. Without patch flowtable and fastforward had the same speed as flowtable, fastfoward and standard forward. That means, with the patch the standard forward patch had the same speed as the fastforward path. It seems, I'm hitting some other speedlimits at my system, so there was no real difference between flowtable, fastforward with and without the patch. I would be great if someone could load a system with a full tables (400k routes) and do some tests at 10gbe speed. Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Mon Apr 18 17:28:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9048106566B; Mon, 18 Apr 2011 17:28:19 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 908168FC15; Mon, 18 Apr 2011 17:28:19 +0000 (UTC) Received: by pvg11 with SMTP id 11so2991994pvg.13 for ; Mon, 18 Apr 2011 10:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ta5ZWj0Xjeh8Zn7Wx+HAy5idXNFnE7XoQQGsZTWVnMw=; b=RZcPv+7KFVSBChKizh/wCREvCHpZZlScrcfEs/FdKX7RoposcQkPX6fF4cLTz+B2j2 gRuJwoVkopx5sQtbuPFT0rjXCuLHL2lp0HIIEX3CSJwnioLujSi698F6imotUj2Zjv3J s3WHRpbtR2+IOWGAifJBaF7nnb5IM20suoQFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YE1Szevdo7uq1byuauFfuZgqIgxgKJeD1Zi13kAhUpWIL52xwmWA/bZnB0VQux5zIj Y2lgF9eqjz60e0dUXhZdx1Nc6vADPWV+KT1FmkeB6yIKDLMGB4OA8nuyKVYOz0UKGV0v KJZRpEo3S5QQ49k9mCyawd+2eiVVItqumY1W4= MIME-Version: 1.0 Received: by 10.68.54.102 with SMTP id i6mr3573976pbp.111.1303147699179; Mon, 18 Apr 2011 10:28:19 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.68.41.101 with HTTP; Mon, 18 Apr 2011 10:28:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2011 19:28:19 +0200 X-Google-Sender-Auth: TemLwU1XAguliiCYQWL6Su3sKtY Message-ID: From: "K. Macy" To: Ingo Flaschberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Ingo Flaschberger Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:28:19 -0000 400kpps is not a large enough measure to reach any conclusions. A system like that should be able to push at least 2.3Mpps with flowtable. I'm not saying that what you've done is not an improvement, but rather that you're hitting some other bottleneck. The output of pmc and LOCK_PROFILING might be insightful. Thanks, Kip On Mon, Apr 18, 2011 at 7:12 PM, Ingo Flaschberger wrote: > >> It would be great to see flowtable going back to its intended use. >> However, I would be surprised if this actually scales to Mpps. I don't >> have any high end hardware at the moment to test, what is the highest >> packet rate you've seen? i.e. simply generating small packets. > > Currently I have no tests available, but I have seen at a appliance with: > Intel Q35 > Quad Core cpu > Intel em desktop pcie cards > > ~ 200mbit 64byte packets - ~ 400kpps without packetloss. > > Without patch flowtable and fastforward had the same speed as flowtable, > fastfoward and standard forward. > > That means, with the patch the standard forward patch had the same speed = as > the fastforward path. > > It seems, I'm hitting some other speedlimits at my system, so there was n= o > real difference between flowtable, fastforward with and without the patch= . > > I would be great if someone could load a system with a full tables (400k > routes) and do some tests at 10gbe speed. > > Kind regards, > =A0 =A0 =A0 =A0Ingo Flaschberger > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 18 17:59:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7A4E1065677; Mon, 18 Apr 2011 17:59:58 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id AE2798FC1F; Mon, 18 Apr 2011 17:59:58 +0000 (UTC) Received: by pxi6 with SMTP id 6so7324874pxi.17 for ; Mon, 18 Apr 2011 10:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ihHJU7Hu4jCYH+KgYyJNt8Z4aaMBikKuu1wTXvAwtWI=; b=ct2jsNC+wJnoGi5EGVut0OOGscfDJpFfu4i10fZmP1b3J92sEQjMvJhm3D28U7CPoh k5wPFyx8+NnR6QIUFVpwgbuXeHYOPHDxBVJ5xL+ZhgcysQUER6jqEWD7f/La9WTaLnac g2Cg7MOVDZlyCibQ6H/j3U3Rq5rPeu+Z/ILfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RN1vX543KvL4BOgHjNahLw0bXVTEX5UUxzHDG7rrg/il/bVufsZ+IkVOR28bjUBuE1 HfgLCh7KeZhfoQOUz9uIBs9gsFFnFaDLrvplBf42/OOwCh9dRC+45FSiMG5PwIkjqAZP BoQ0O0HokA+htFAgdnJzABASBDTOJTdr2BrPI= MIME-Version: 1.0 Received: by 10.68.52.227 with SMTP id w3mr7157450pbo.312.1303149598276; Mon, 18 Apr 2011 10:59:58 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.68.41.101 with HTTP; Mon, 18 Apr 2011 10:59:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2011 19:59:58 +0200 X-Google-Sender-Auth: 4W4o67wytIJimfwcFuDUxU2aTns Message-ID: From: "K. Macy" To: Ingo Flaschberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Ingo Flaschberger Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:59:59 -0000 On Mon, Apr 18, 2011 at 7:28 PM, K. Macy wrote: > 400kpps is not a large enough measure to reach any conclusions. A > system like that should be able to push at least 2.3Mpps with > flowtable. I'm not saying that what you've done is not an improvement, > but rather that you're hitting some other bottleneck. The output of > pmc and LOCK_PROFILING might be insightful. It occurred to me that I should add a couple of qualifications to the previous statements. 1.6Mpps is line rate for GigE and I only know of it to be achievable by igb hardware. The most I've seen em hardware achieve is 1.1Mpps. Furthermore, in order to achieve that you would have to enable IFNET_MULTIQUEUE in the driver, because by default the driver uses the traditional (slow) IFQ as opposed overloading if_transmit and doing its own queueing when needed. Support for efficient multi-queue software queueing is provided by buf_ring, a lock-free multi-producer ring buffer written just for this purpose. Thus, the fairly low transmit rate may be attributable to driver locking. Cheers > > Thanks, > Kip > > On Mon, Apr 18, 2011 at 7:12 PM, Ingo Flaschberger wrote: >> >>> It would be great to see flowtable going back to its intended use. >>> However, I would be surprised if this actually scales to Mpps. I don't >>> have any high end hardware at the moment to test, what is the highest >>> packet rate you've seen? i.e. simply generating small packets. >> >> Currently I have no tests available, but I have seen at a appliance with= : >> Intel Q35 >> Quad Core cpu >> Intel em desktop pcie cards >> >> ~ 200mbit 64byte packets - ~ 400kpps without packetloss. >> >> Without patch flowtable and fastforward had the same speed as flowtable, >> fastfoward and standard forward. >> >> That means, with the patch the standard forward patch had the same speed= as >> the fastforward path. >> >> It seems, I'm hitting some other speedlimits at my system, so there was = no >> real difference between flowtable, fastforward with and without the patc= h. >> >> I would be great if someone could load a system with a full tables (400k >> routes) and do some tests at 10gbe speed. >> >> Kind regards, >> =A0 =A0 =A0 =A0Ingo Flaschberger >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Mon Apr 18 21:15:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C50651065674 for ; Mon, 18 Apr 2011 21:15:49 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2ACD68FC24 for ; Mon, 18 Apr 2011 21:15:48 +0000 (UTC) Received: (qmail 26109 invoked from network); 18 Apr 2011 23:09:06 +0200 Received: from unknown (HELO filebunker.xip.at) (89.207.145.147) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2011 23:09:06 +0200 Date: Mon, 18 Apr 2011 23:09:06 +0200 (CEST) From: Ingo Flaschberger To: "K. Macy" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:15:49 -0000 > It occurred to me that I should add a couple of qualifications to the > previous statements. 1.6Mpps is line rate for GigE and I only know of > it to be achievable by igb hardware. The most I've seen em hardware > achieve is 1.1Mpps. Furthermore, in order to achieve that you would > have to enable IFNET_MULTIQUEUE in the driver, because by default the > driver uses the traditional (slow) IFQ as opposed overloading > if_transmit and doing its own queueing when needed. Support for > efficient multi-queue software queueing is provided by buf_ring, a > lock-free multi-producer ring buffer written just for this purpose. > > Thus, the fairly low transmit rate may be attributable to driver locking. Currently the quad core hardware is in production, I can only test with the single core 1,2ghz pentiumM. Also no igb cards. em cards, 82541GI, with polling 8.2 i386 with patch rmlock-copy, 400k /32 routes, 64byte packets: fastfw standard flowtable 1 dest: 85607pps 57189pps 57216pps rand. dest: 83945pps 54976pps 55007pps standard routing seems to be as fast as flowtable. flowtable does not support fastforward, rmlock-copy-patch supports fastforward. 8.2 i386 w/o patch, 400k /32 routes, 64byte packets: fastfw standard flowtable 1 dest: 84792pps 55357pps 55515pps rand. dest: 80156pps 52320pps 52300pps so even on a single cpu system less locking improve performance, but as you mentioned above, the bottlenecks of this system are the "desktop" pci network cards. I would really like to see some compareable tests with 10gbe hardware. Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 13:55:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02E0E106566B; Tue, 19 Apr 2011 13:55:34 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 53BB88FC13; Tue, 19 Apr 2011 13:55:32 +0000 (UTC) Received: by fxm11 with SMTP id 11so4611488fxm.13 for ; Tue, 19 Apr 2011 06:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=hy9KP/7D/e0ejiQ7Xct0MSeAVtQ8y4i9sypC7YWHqoA=; b=yA8sloes2vb6ABfOSXPEZGZyvKHaFwaZJuH3bo6VH71oe6olmVZPlhciBn+fl0tvIn S1I+Sjvku24WZxlmr/vpRRQnAK/OosygdUvQOdcsYdQWunwPPuPWxF5WmPzs1y/kRZdX SbUtpPPbCjTfEODsYHnbhryErtLccS+sDBCR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=LJ3lRfDVustyr0Q57jlXcOeFA7a+gwte0A5VEC8Ky1ILO0lB9r/4qDX2qWlDOwhlzJ PcLxVBNPbUQXi195g9D5DXhsdrPQ+imw6CsZOk/zbj94xMV/l0IVr7wTGl/zct4eTpCq li4zgRay15CJs3SkzRV6V/HWBEjZP0NuFzzSg= Received: by 10.223.155.140 with SMTP id s12mr874619faw.63.1303221331897; Tue, 19 Apr 2011 06:55:31 -0700 (PDT) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com [217.18.249.148]) by mx.google.com with ESMTPS id b18sm1942923fak.8.2011.04.19.06.55.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 06:55:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Nikolay Denev In-Reply-To: Date: Tue, 19 Apr 2011 16:55:27 +0300 Message-Id: References: To: K. Macy X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ingo Flaschberger Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 13:55:34 -0000 On Apr 18, 2011, at 8:59 PM, K. Macy wrote: > It occurred to me that I should add a couple of qualifications to the > previous statements. 1.6Mpps is line rate for GigE and I only know of > it to be achievable by igb hardware. The most I've seen em hardware > achieve is 1.1Mpps. Furthermore, in order to achieve that you would > have to enable IFNET_MULTIQUEUE in the driver, because by default the > driver uses the traditional (slow) IFQ as opposed overloading > if_transmit and doing its own queueing when needed. Support for > efficient multi-queue software queueing is provided by buf_ring, a > lock-free multi-producer ring buffer written just for this purpose. >=20 > Thus, the fairly low transmit rate may be attributable to driver = locking. >=20 > Cheers Hi, I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this = something present only in HEAD? Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 14:42:17 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594E2106567C; Tue, 19 Apr 2011 14:42:17 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 224818FC1B; Tue, 19 Apr 2011 14:42:16 +0000 (UTC) Received: by pwj8 with SMTP id 8so3633876pwj.13 for ; Tue, 19 Apr 2011 07:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YEYdHpaoSZyU2pnoHJOecvkd7uePRr8S/TKscb3B6+M=; b=qCsgv5f2WN9KBra5Y5pheRkUp/KtelOWZyTLw/S7sVl6DpTlnEccYa2EyjgekoBtty X4UILh0yZnEdiflJcEu92nj3ayUZJzcNZXLiJikI3Tv0AvR8L5qyBY4lZKNagRDcQaUb izll9bXBGb14SMd9GZUOzQn4Syy2l37SH+V48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=mKXLgZJmmY7EtD9pz/YYTERgHX6K+gDkmGfuolI5/tHrBvkpiy7a0HiCN6cGpip5U9 sRfHD/gHD6nEz32MlTsCylmnCqC7H4R8XShWqmsHb2d5zY1VdgYeJTTmTx+1MqSJAfmB KTpgVlT496sUJuynfT13J4wrbV3J7QoCSS0e8= MIME-Version: 1.0 Received: by 10.68.52.227 with SMTP id w3mr8658740pbo.312.1303224136534; Tue, 19 Apr 2011 07:42:16 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.68.41.101 with HTTP; Tue, 19 Apr 2011 07:42:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Apr 2011 16:42:16 +0200 X-Google-Sender-Auth: mAS-BCXArksgTQshpQ3vMITy6EU Message-ID: From: "K. Macy" To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ingo Flaschberger Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:42:17 -0000 > Hi, > > I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this something > present only in HEAD? It looks like it is now EM_MULTIQUEUE. Cheers From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 16:32:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA56106564A; Tue, 19 Apr 2011 16:32:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 953978FC19; Tue, 19 Apr 2011 16:32:00 +0000 (UTC) Received: by yie12 with SMTP id 12so2694642yie.13 for ; Tue, 19 Apr 2011 09:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=F9UdAJM9olOY0UEqgKDtscPytOOt/IY7W+yGnuLng2Y=; b=xQse1TdcJNd+814tOc5WsFVaplZID210tohe3fTtZsK/A94HJLEyXcw5zJJbSAWNVg TEz/Vt3B22wOr87O0c+nE2r+N63fwSz4zhdhIl9DZREUGrjB2Yz3Khy4EpQiTuNKWHLp +K5LwKoYsbI6EYTYXFYX1jRSGllyUequ22Fdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=cSfTxvoilehpm6WddP86yiF5e5fZpjoVXJz0It4oZAJvwqZLU1Hy9QpZRvZykxbKFh SwNmMQoQczQKrMIHTU3sYgO8RRZQqupE5Ql/5s6XWtBxE0xSp48a44v64db9Z0DBfhyQ Z6bdaL7sSqB8rk85//X0zsRmucyH7Uc7fwqWQ= MIME-Version: 1.0 Received: by 10.236.175.2 with SMTP id y2mr4846693yhl.490.1303229327378; Tue, 19 Apr 2011 09:08:47 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.131 with HTTP; Tue, 19 Apr 2011 09:08:47 -0700 (PDT) Date: Tue, 19 Apr 2011 12:08:47 -0400 X-Google-Sender-Auth: Vr8I-Pe4ozMTs1SnwkxoMNNLp4I Message-ID: From: Attilio Rao To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: "Bjoern A. Zeeb" , Ed Maste Subject: [PATCH] Add MD5 signature checking for incoming packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:32:01 -0000 The patch at: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/tcp_signature/tcp_signature.diff - Enable the md5 signature checking for incoming packets, when both enabled in the kernel and desired by the socket - Spit out an error when the option TCP_SIGNATURE is enabled and IPSEC option is not (KPI usage problem, leading to just compiler error, in the current code) Some notes: - As suggested by bz@, I named the functions tcp_fields_to_net() and tcp_fields_to_host() just following the NetBSD's names - I add the statistic anyway to the tcpstats in order to avoid ABI breakage between kernel and modules/userland. Anyway it seems that tcpstats is not a member of any structure, so probabilly having them as last step could sitll make it conditional. I'm not entirely sure on what is the desired effect here, so I just included anyway, but I'm ready to change if someone makes a valid point The patch has been already reviewed by emaste and bz and tested for years on SVOS. Please cc' me for answers as I'm not really subscribed to -net@. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 17:18:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 404F2106567B for ; Tue, 19 Apr 2011 17:18:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (unknown [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3E078FC1F for ; Tue, 19 Apr 2011 17:18:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 742434AC42 for ; Tue, 19 Apr 2011 21:18:11 +0400 (MSD) Date: Tue, 19 Apr 2011 21:18:05 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <884389059.20110419211805@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: Proper way to setup IPv6 gateway on running node without reboot? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:18:13 -0000 Hello, Freebsd-net. I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. I've added to /etc/rc.conf: ipv6_enable=3D"YES" ipv6_ifconfig_em0=3D"2001:470:hhhh:1::1 prefixlen 64" ipv6_ifconfig_wlan0=3D"2001:470:hhhh:2::1 prefixlen 64" ipv6_defaultrouter=3D"2001:470:xxxx:xxxx::2" # uplink rtadvd_enable=3D"YES" rtadvd_interfaces=3D"em0 wlan0" ipv6_gateway_enable=3D"YES" and run /etc/rc.d/network_ipv6 start /etc/rc.d/rtadvd start Interfaces em0 and wlan0 now have static addresses, but not link-local automatic ones, and it seems, that rtadvd doesn't announce anything. As far as I understand, rtadvd can not work without link-local addresses, am I right? Why these addresses doesn't appear on interfaces? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 18:01:44 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EB2181065672; Tue, 19 Apr 2011 18:01:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B4C8914E87F; Tue, 19 Apr 2011 18:01:22 +0000 (UTC) Message-ID: <4DADCDF0.7000607@FreeBSD.org> Date: Tue, 19 Apr 2011 11:01:20 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: lev@FreeBSD.org References: <884389059.20110419211805@serebryakov.spb.ru> In-Reply-To: <884389059.20110419211805@serebryakov.spb.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Proper way to setup IPv6 gateway on running node without reboot? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:01:45 -0000 On 4/19/2011 10:18 AM, Lev Serebryakov wrote: > Hello, Freebsd-net. > > > I'm looking for way to setup IPv6 router config on IPv4-configured > node without reboot. Your best bet is actually to reboot. There are a lot of moving parts, and it's difficult to catch them all, especially with a gateway setup. Meanwhile, you need to tell us what version of FreeBSD you're using, as IPv6 configuration is different in all 3 supported branches atm. > I've added to /etc/rc.conf: > > ipv6_enable="YES" > ipv6_ifconfig_em0="2001:470:hhhh:1::1 prefixlen 64" > ipv6_ifconfig_wlan0="2001:470:hhhh:2::1 prefixlen 64" I hope that the hhhh here is a method of obfuscating the real addresses for this message? > ipv6_defaultrouter="2001:470:xxxx:xxxx::2" # uplink > rtadvd_enable="YES" > rtadvd_interfaces="em0 wlan0" > ipv6_gateway_enable="YES" > > and run > > /etc/rc.d/network_ipv6 start > /etc/rc.d/rtadvd start > > Interfaces em0 and wlan0 now have static addresses, but not > link-local automatic ones, and it seems, that rtadvd doesn't announce > anything. Check the ifconfig output. You're looking for the auto link-local and ifdisabled options. Check the ifconfig man page for what you need to twiddle. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 18:19:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD4C1065679 for ; Tue, 19 Apr 2011 18:19:31 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50ED48FC13 for ; Tue, 19 Apr 2011 18:19:30 +0000 (UTC) Received: by yie12 with SMTP id 12so2735998yie.13 for ; Tue, 19 Apr 2011 11:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BZp+zYmux4tUvSdgzgIaSTuRDyr9WyeG0fXSJeY17Vk=; b=Z594/LNuF1aVMi+g7ueM08Hy5H6FdkOAAum4peqllJo40oXrDgANPHAgegY7DFS3tE yojiQEodGoiF4ZJKe4Ss0ndo3HHUUfigyWcn7FnJxi0J0thGnaBmyETmfUY+5RE2KcNA VTrBC+6l4zAA2ElRylGANm/5akZJ6T/UOE5C4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X6o0PTBnd1/oxT8UoF4a70vp87zntGowxMDRFhGxnfWZM8iSUqJ2stg8wtwTfBqanp 6Y5bzS+79QJR41tpbFRsiKuZIDCT3ZYGGAbm12Plp3I3y8TJSc7MX5o2dXJ1E6TKWKED Et9A0vOYVV5heA+rDfx+AOhL/xoYD1+WF/Bfg= MIME-Version: 1.0 Received: by 10.90.131.10 with SMTP id e10mr5565173agd.96.1303237170356; Tue, 19 Apr 2011 11:19:30 -0700 (PDT) Received: by 10.90.161.16 with HTTP; Tue, 19 Apr 2011 11:19:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Apr 2011 11:19:30 -0700 Message-ID: From: Freddie Cash To: "K. Macy" Content-Type: text/plain; charset=UTF-8 Cc: Nikolay Denev , Ingo Flaschberger , freebsd-net@freebsd.org Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:19:31 -0000 On Tue, Apr 19, 2011 at 7:42 AM, K. Macy wrote: >> I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this something >> present only in HEAD? > > It looks like it is now EM_MULTIQUEUE. Just curious, how would one enable this to test it? We have igb(4) interfaces in our new storage boxes, and it would be interesting to test whether or not it helps in our setup. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 18:39:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8BCD106564A; Tue, 19 Apr 2011 18:39:40 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (unknown [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 84C788FC0A; Tue, 19 Apr 2011 18:39:40 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 5EAD94AC42; Tue, 19 Apr 2011 22:39:39 +0400 (MSD) Date: Tue, 19 Apr 2011 22:39:38 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <888636747.20110419223938@serebryakov.spb.ru> To: Doug Barton In-Reply-To: <4DADCDF0.7000607@FreeBSD.org> References: <884389059.20110419211805@serebryakov.spb.ru> <4DADCDF0.7000607@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, lev@FreeBSD.org Subject: Re: Proper way to setup IPv6 gateway on running node without reboot? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:39:41 -0000 Hello, Doug. You wrote 19 =E0=EF=F0=E5=EB=FF 2011 =E3., 22:01:20: >> I'm looking for way to setup IPv6 router config on IPv4-configured >> node without reboot. > Your best bet is actually to reboot. There are a lot of moving parts, > and it's difficult to catch them all, especially with a gateway setup. Does it mean, that, someone'll need to reboot for renumbering or adding new net segment (for example, I want to add one more WiFi SSID on this router in future, for public access)? I don't like this idea. > Meanwhile, you need to tell us what version of FreeBSD you're using, as > IPv6 configuration is different in all 3 supported branches atm. 8.2-STABLE >> I've added to /etc/rc.conf: >> >> ipv6_enable=3D"YES" >> ipv6_ifconfig_em0=3D"2001:470:hhhh:1::1 prefixlen 64" >> ipv6_ifconfig_wlan0=3D"2001:470:hhhh:2::1 prefixlen 64" > I hope that the hhhh here is a method of obfuscating the real addresses > for this message? Yes, of course. It is fragments of routable /48 prefix, allocated to me by Hurricane Electric. >> ipv6_defaultrouter=3D"2001:470:xxxx:xxxx::2" # uplink >> rtadvd_enable=3D"YES" >> rtadvd_interfaces=3D"em0 wlan0" >> ipv6_gateway_enable=3D"YES" >> >> and run >> >> /etc/rc.d/network_ipv6 start >> /etc/rc.d/rtadvd start >> Interfaces em0 and wlan0 now have static addresses, but not >> link-local automatic ones, and it seems, that rtadvd doesn't announce >> anything. > Check the ifconfig output. You're looking for the auto link-local and=20 > ifdisabled options. Check the ifconfig man page for what you need to=20 > twiddle. ifconfig shows only one "inet6" address for each (manually configured), and these nd6 flags: nd6 options=3D3 But sysctl net.inet6.ip6.accept_rtadv: 0 sysctl net.inet6.ip6.auto_linklocal: 1 And gateway# ifconfig em0 -accept_rtadv ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument gateway# ifconfig wlan0 -accept_rtadv ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 18:48:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 497B2106566B; Tue, 19 Apr 2011 18:48:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 299EE155B52; Tue, 19 Apr 2011 18:48:41 +0000 (UTC) Message-ID: <4DADD907.2010004@FreeBSD.org> Date: Tue, 19 Apr 2011 11:48:39 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: lev@FreeBSD.org References: <884389059.20110419211805@serebryakov.spb.ru> <4DADCDF0.7000607@FreeBSD.org> <888636747.20110419223938@serebryakov.spb.ru> In-Reply-To: <888636747.20110419223938@serebryakov.spb.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Proper way to setup IPv6 gateway on running node without reboot? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:48:41 -0000 On 4/19/2011 11:39 AM, Lev Serebryakov wrote: > Hello, Doug. > You wrote 19 апреля 2011 г., 22:01:20: > >>> I'm looking for way to setup IPv6 router config on IPv4-configured >>> node without reboot. >> Your best bet is actually to reboot. There are a lot of moving parts, >> and it's difficult to catch them all, especially with a gateway setup. > Does it mean, that, someone'll need to reboot for > renumbering or adding new net segment (for example, I want to add > one more WiFi SSID on this router in future, for public access)? I > don't like this idea. Neither do I. :) I tried to improve it, but my changes were rejected. Ping hrs@ if you want to talk about your concerns, he's in charge of this stuff now. >> Meanwhile, you need to tell us what version of FreeBSD you're using, as >> IPv6 configuration is different in all 3 supported branches atm. > 8.2-STABLE Ok. >> Check the ifconfig output. You're looking for the auto link-local and >> ifdisabled options. Check the ifconfig man page for what you need to >> twiddle. > ifconfig shows only one "inet6" address for each (manually > configured), and these nd6 flags: > > nd6 options=3 Re-read what I wrote above. You've got to enable the link-local addresses for each interface. If that doesn't work, please paste full 'ifconfig' output into your next message. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 18:48:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3B6106566C for ; Tue, 19 Apr 2011 18:48:53 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp6.uk.umis.net (smtp6.mail.clearhost.co.uk [IPv6:2001:1420::25:106]) by mx1.freebsd.org (Postfix) with ESMTP id 542A58FC1B for ; Tue, 19 Apr 2011 18:48:53 +0000 (UTC) Received: from kate.prtsystems.ltd.uk ([217.65.165.35]) by smtp6.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QCFyl-0001Co-RG for freebsd-net@freebsd.org; Tue, 19 Apr 2011 18:48:51 +0000 Message-ID: <4DADD913.5010208@prt.org> Date: Tue, 19 Apr 2011 19:48:51 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:48:53 -0000 Hi, The bge driver doesn't support this chipset yet and I was wondering if anyone has looked at implementing it. NetBSD looks like it has support for it. Now I may be wrong here, but it appears that the BCM57765 is similar to other devices based on the NetBSD if_bge.c source version 1.194. I've tried applying the NetBSD changes to the FreeBSD bge source but I don't know enough about the hardware and the code is different enough that I haven't made it very far. I can get a patched 8.2 kernel to detect the device, complain that the ASIC is unknown, read the MAC address correctly and determine there is link but as soon as you attempt to ifconfig up the interface the machine locks up. I'm happy to try and port this over but need a nudge in the right direction from someone who knows the code. Thanks, Paul. From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 19:06:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD463106566C; Tue, 19 Apr 2011 19:06:02 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A09698FC12; Tue, 19 Apr 2011 19:06:02 +0000 (UTC) Received: by pvg11 with SMTP id 11so3622515pvg.13 for ; Tue, 19 Apr 2011 12:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CybIeKwfCwnNMbZwT5xGskOM+c/VvSU5vtb5+ayftaE=; b=sykRipHXxqEKHlMUf9V/RRZ8Lfj7uPEmKwaP+JkdT1nGWRbY2CYivmzESKXjs+CFI6 8flzdAVOHCT1UIjI4XLhOlJLbIQc1GAXckGwPNyhDGFZTKc5GU1pHbi+AtK8Ex9yXmoR Yjn9Cxup28p1jKuRmmmsMRUmf+EEaGOI+ZwPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UNTvTT0T0sD52m9b91PQz9+xT2nBGqKGrl8wL2fXl5WNtp6ugZScA4tR5wa+X0R7pt Hbf3I3MFYIl9I23PuV4uD+gq6Ph6Vo5qY1MPMX5nba6Mnhwx1EjFIasILQgL3g8Ja8Bw +q1YlldSRKtwUT6q/yUzf3wYJtcpN6kYkWZJ0= MIME-Version: 1.0 Received: by 10.68.8.2 with SMTP id n2mr895209pba.245.1303239962149; Tue, 19 Apr 2011 12:06:02 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.68.41.101 with HTTP; Tue, 19 Apr 2011 12:06:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Apr 2011 21:06:02 +0200 X-Google-Sender-Auth: M_RukAfaAGRJWt5hER7u6sg2pAI Message-ID: From: "K. Macy" To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nikolay Denev , Ingo Flaschberger , freebsd-net@freebsd.org Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:06:02 -0000 On Tue, Apr 19, 2011 at 8:19 PM, Freddie Cash wrote: > On Tue, Apr 19, 2011 at 7:42 AM, K. Macy wrote: >>> I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this s= omething >>> present only in HEAD? >> >> It looks like it is now EM_MULTIQUEUE. > > Just curious, how would one enable this to test it? =A0We have igb(4) > interfaces in our new storage boxes, and it would be interesting to > test whether or not it helps in our setup. > It should automatically allocate a queue per core up to the max supported. Post 8.0 it should be enabled by default for igb: #if __FreeBSD_version >=3D 800000 /* ** Multiqueue Transmit driver ** */ static int igb_mq_start(struct ifnet *ifp, struct mbuf *m) { struct adapter *adapter =3D ifp->if_softc; struct igb_queue *que; struct tx_ring *txr; int i =3D 0, err =3D 0; /* Which queue to use */ if ((m->m_flags & M_FLOWID) !=3D 0) i =3D m->m_pkthdr.flowid % adapter->num_queues; txr =3D &adapter->tx_rings[i]; que =3D &adapter->queues[i]; if (IGB_TX_TRYLOCK(txr)) { err =3D igb_mq_start_locked(ifp, txr, m); IGB_TX_UNLOCK(txr); } else { err =3D drbr_enqueue(ifp, txr->br, m); taskqueue_enqueue(que->tq, &que->que_task); } return (err); } static int igb_mq_start_locked(struct ifnet *ifp, struct tx_ring *txr, struct mbuf *m) { struct adapter *adapter =3D txr->adapter; struct mbuf *next; int err =3D 0, enq; IGB_TX_LOCK_ASSERT(txr); if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) !=3D IFF_DRV_RUNNING || adapter->link_active =3D=3D 0) { if (m !=3D NULL) err =3D drbr_enqueue(ifp, txr->br, m); return (err); } /* Call cleanup if number of TX descriptors low */ if (txr->tx_avail <=3D IGB_TX_CLEANUP_THRESHOLD) igb_txeof(txr); enq =3D 0; if (m =3D=3D NULL) { next =3D drbr_dequeue(ifp, txr->br); } else if (drbr_needs_enqueue(ifp, txr->br)) { if ((err =3D drbr_enqueue(ifp, txr->br, m)) !=3D 0) return (err); next =3D drbr_dequeue(ifp, txr->br); } else next =3D m; /* Process the queue */ while (next !=3D NULL) { if ((err =3D igb_xmit(txr, &next)) !=3D 0) { if (next !=3D NULL) err =3D drbr_enqueue(ifp, txr->br, next); break; } enq++; drbr_stats_update(ifp, next->m_pkthdr.len, next->m_flags); ETHER_BPF_MTAP(ifp, next); if ((ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0) break; if (txr->tx_avail <=3D IGB_TX_OP_THRESHOLD) { ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; break; } next =3D drbr_dequeue(ifp, txr->br); } if (enq > 0) { /* Set the watchdog */ txr->queue_status =3D IGB_QUEUE_WORKING; txr->watchdog_time =3D ticks; } return (err); } I haven't tested this to make sure there aren't any hidden locking performance issues. Cheers From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 19:10:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46961106564A; Tue, 19 Apr 2011 19:10:27 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C7DDE8FC13; Tue, 19 Apr 2011 19:10:23 +0000 (UTC) Received: by gwb15 with SMTP id 15so2416gwb.13 for ; Tue, 19 Apr 2011 12:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bdyz+pz9mc8GDFlXKxOSuAthDKw5CTu+FLnIIp2X/aI=; b=oIo9D1fRhVNZpuGrbhPT73+zAICZspq7F+iTbaigMxfWWubfZSGwwiJGDfQXETijB0 rqjHCSio/um0HH9jicd2Bn2FMI4jkLEO1VeS9+wsPqxU52ULHqqQmcWTeOP696PW2Amj FXkgR2tOddp3DE7Q2DabTQp5tgb6KfPI6vZn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=alrsk26eIsGmW4OOKrGYFRib4F27Jk+aoxZVcEMaa3Xwu/7ptxp2UcJFai0yfJ51kP CAi3IlZrzsupT6r3N5zsvQLx6vkBf4o5TjrsuTr5ZjUHfdCNGSSr1DHQfPEuEYZvoj2g cMUF6Mk4esrElYhtM4QzV2d8Xb5x7Q6ykoBqI= MIME-Version: 1.0 Received: by 10.91.92.8 with SMTP id u8mr5725573agl.15.1303240223431; Tue, 19 Apr 2011 12:10:23 -0700 (PDT) Received: by 10.90.161.16 with HTTP; Tue, 19 Apr 2011 12:10:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Apr 2011 12:10:23 -0700 Message-ID: From: Freddie Cash To: "K. Macy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Nikolay Denev , Ingo Flaschberger , freebsd-net@freebsd.org Subject: Re: Routing enhancement - reduce routing table locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:10:27 -0000 On Tue, Apr 19, 2011 at 12:06 PM, K. Macy wrote: > On Tue, Apr 19, 2011 at 8:19 PM, Freddie Cash wrote: >> On Tue, Apr 19, 2011 at 7:42 AM, K. Macy wrote: >>>> I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this = something >>>> present only in HEAD? >>> >>> It looks like it is now EM_MULTIQUEUE. >> >> Just curious, how would one enable this to test it? =C2=A0We have igb(4) >> interfaces in our new storage boxes, and it would be interesting to >> test whether or not it helps in our setup. >> > It should automatically allocate a queue per core up to the max > supported. Post 8.0 it should be enabled by default for igb: Ah, you're right. Looking through "vmstat -i" there is a separate queue for each CPU core. SuperMicro H8DGi-F motherboard with igb onboard: irq256: igb0:que 0 1139206 1 irq257: igb0:que 1 30632 0 irq258: igb0:que 2 33896 0 irq259: igb0:que 3 665468 0 irq260: igb0:que 4 297171 0 irq261: igb0:que 5 43611 0 irq262: igb0:que 6 30029 0 irq263: igb0:que 7 3326877 4 irq264: igb0:link 2 0 irq265: igb1:que 0 53522069 77 irq266: igb1:que 1 78335894 113 irq267: igb1:que 2 45704968 65 irq268: igb1:que 3 156102576 225 irq269: igb1:que 4 87793026 126 irq270: igb1:que 5 85639786 123 irq271: igb1:que 6 131898271 190 irq272: igb1:que 7 154087013 222 irq273: igb1:link 2 0 --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 19:20:24 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DD10106564A; Tue, 19 Apr 2011 19:20:24 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id C24C78FC19; Tue, 19 Apr 2011 19:20:23 +0000 (UTC) Received: by yxl31 with SMTP id 31so10049yxl.13 for ; Tue, 19 Apr 2011 12:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=TKydZAI4WNIXeD5N+eHngGEmMc3Wdx++5jGB3GCcVqM=; b=ccv8z+hU1YJOIoArs/WwHDYzXDS8gmAjmSp0W/YleNYEOz7890o5LtknogQT+ehYJ/ 1kX2z2mmOBwBRXYNGOBBw+EbriOKitMCztGMzI4chr+jrjUGfm0jtGSPFZiwXrRWO9fV fxZRFlelvYH+V+V6WZedKDwoJ0VGXvolo/y50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=x7yIQqTxip0MAwsXAfMtx5VPypRparBZiQI5/2wSaakbvmU4Qmbl8fFRxjmBX6oGJk 4X6qyUaLoHQ8OlXc/nHsIfucK2URcJblAvgC5YElzP48EQWV/7t4uTvCx7dAH4kj9F+T WJGBk9uCuaniIqG0iAO628U7pOrbeKc54SU7s= Received: by 10.150.173.9 with SMTP id v9mr5393423ybe.168.1303240823010; Tue, 19 Apr 2011 12:20:23 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id f5sm1373480ybh.13.2011.04.19.12.20.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 12:20:21 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p3JJKHtu056837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2011 15:20:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3JJKHZJ056836; Tue, 19 Apr 2011 15:20:17 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 19 Apr 2011 15:20:16 -0400 From: "J. Hellenthal" To: Doug Barton Message-ID: <20110419192016.GB2483@DataIX.net> References: <884389059.20110419211805@serebryakov.spb.ru> <4DADCDF0.7000607@FreeBSD.org> <888636747.20110419223938@serebryakov.spb.ru> <4DADD907.2010004@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline In-Reply-To: <4DADD907.2010004@FreeBSD.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: Proper way to setup IPv6 gateway on running node without reboot? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:20:24 -0000 --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2011 at 11:48:39AM -0700, Doug Barton wrote: >On 4/19/2011 11:39 AM, Lev Serebryakov wrote: >>Hello, Doug. >>You wrote 19 ???????????? 2011 ??., 22:01:20: >> >>>> I'm looking for way to setup IPv6 router config on IPv4-configured >>>>node without reboot. >>>Your best bet is actually to reboot. There are a lot of moving parts, >>>and it's difficult to catch them all, especially with a gateway setup. > >> Does it mean, that, someone'll need to reboot for >>renumbering or adding new net segment (for example, I want to add >>one more WiFi SSID on this router in future, for public access)? I >>don't like this idea. > >Neither do I. :) I tried to improve it, but my changes were rejected. >Ping hrs@ if you want to talk about your concerns, he's in charge of >this stuff now. > >>>Meanwhile, you need to tell us what version of FreeBSD you're using, as >>>IPv6 configuration is different in all 3 supported branches atm. > >> 8.2-STABLE > >Ok. > >>>Check the ifconfig output. You're looking for the auto link-local and >>>ifdisabled options. Check the ifconfig man page for what you need to >>>twiddle. > >> ifconfig shows only one "inet6" address for each (manually >>configured), and these nd6 flags: >> >> nd6 options=3D3 > >Re-read what I wrote above. You've got to enable the link-local >addresses for each interface. > >If that doesn't work, please paste full 'ifconfig' output into your >next message. > > PS: If you sysctl net.inet6.ip6.auto_linklocal=3D1 and bring the interface down and back up you will end up with a link-local address on the interface. --=20 Regards, J. Hellenthal WWJD --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNreBwAAoJEJBXh4mJ2FR+2eEH/ia4zEndYiilc2I3dXoQBUL9 CNVMTKExTTuSTmNa/TE3BfmxKBBN3IpHw0CgVHCwYzdPxXZDef2/byGJT8+30b4B oOsU+4wnNcfH98Sl85YLRDi7ZxbC/XF4aoCUUatPFJgPWh2KGUyU+/s5aDV4LZzV am2ll+65sk82dBYOLC4m2mAS+td1yTrpYkwgWKYO7t2FDmbYHWJBbgsyINPmW/f3 wwYRKsDXWvFs059KI47B7bBiLpMlKaq/Y9gwwZOZrTNphERtqD8camDcgklwkJLJ 4smmtQ3QK1T1SByOPbOOihDiixDwfLX31zX0qHeFfNBSxBC7875sI5LzEJs3YlQ= =Vz3y -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 19:26:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D54106567A; Tue, 19 Apr 2011 19:26:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (unknown [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9588FC0C; Tue, 19 Apr 2011 19:26:06 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 67ACD4AC45; Tue, 19 Apr 2011 23:26:05 +0400 (MSD) Date: Tue, 19 Apr 2011 23:26:04 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1538532090.20110419232604@serebryakov.spb.ru> To: Doug Barton In-Reply-To: <4DADD907.2010004@FreeBSD.org> References: <884389059.20110419211805@serebryakov.spb.ru> <4DADCDF0.7000607@FreeBSD.org> <888636747.20110419223938@serebryakov.spb.ru> <4DADD907.2010004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, lev@FreeBSD.org Subject: Re: Proper way to setup IPv6 gateway on running node without reboot? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:26:06 -0000 Hello, Doug. You wrote 19 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2011 =D0=B3., 22:48:39: >> ifconfig shows only one "inet6" address for each (manually >> configured), and these nd6 flags: >> nd6 options=3D3 > Re-read what I wrote above. You've got to enable the link-local > addresses for each interface. man ifconfig has only one mention about link-local addresses in BUGS section (with warning about removing them by hands) and mention, that they are automagically assigned on interface creation, if net.inet6.ip6.auto_linklocal is set to 1 (which is true on my system, but all my interfaces were created BEFORE IPv6 has been enabled in system). /etc/rc.d/auto_linklocal works only with lo0. It seems to me, that it is impossible to force kernel to create link-local addresses for already-created interfaces. But I want to be wrong here! > If that doesn't work, please paste full 'ifconfig' output into your next > message. gateway# ifconfig em0 em0: flags=3D8843 metric 0 mtu 1500 options=3D20db ether 00:07:e9:09:ed:f3 inet 192.168.134.1 netmask 0xffffff00 broadcast 192.168.134.255 inet6 2001:470:hhhh:1::1 prefixlen 64 nd6 options=3D3 media: Ethernet 1000baseT status: active gateway# ifconfig wlan0 wlan0: flags=3D8843 metric 0 mtu 15= 00 ether 00:02:6f:53:67:5a inet 192.168.135.1 netmask 0xffffff00 broadcast 192.168.135.255 inet6 2001:470:hhhh:2::1 prefixlen 64 nd6 options=3D3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid home.serebryakov.spb.ru channel 8 (2447 MHz 11g) bssid 00:02:6= f:53:67:5a regdomain ROW country RU indoor ecm authmode WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 19:29:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C50106566C; Tue, 19 Apr 2011 19:29:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (unknown [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 068928FC14; Tue, 19 Apr 2011 19:29:52 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 3179C4AC42; Tue, 19 Apr 2011 23:29:51 +0400 (MSD) Date: Tue, 19 Apr 2011 23:29:29 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <627074650.20110419232929@serebryakov.spb.ru> To: "J. Hellenthal" In-Reply-To: <20110419192016.GB2483@DataIX.net> References: <884389059.20110419211805@serebryakov.spb.ru> <4DADCDF0.7000607@FreeBSD.org> <888636747.20110419223938@serebryakov.spb.ru> <4DADD907.2010004@FreeBSD.org> <20110419192016.GB2483@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Doug Barton , lev@freebsd.org Subject: Re: Proper way to setup IPv6 gateway on running node without reboot? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:29:52 -0000 Hello, J.. You wrote 19 =E0=EF=F0=E5=EB=FF 2011 =E3., 23:20:16: > PS: If you sysctl net.inet6.ip6.auto_linklocal=3D1 and bring the interface > down and back up you will end up with a link-local address on the > interface. Oh, it is what I need. Thank you. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 22:10:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B37F106564A for ; Tue, 19 Apr 2011 22:10:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id CE14F8FC16 for ; Tue, 19 Apr 2011 22:09:59 +0000 (UTC) Received: by pvg11 with SMTP id 11so94249pvg.13 for ; Tue, 19 Apr 2011 15:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=du4p4AkoKizRbgY1X3W3xM99OLdbQ0+isR8OAZp/NOg=; b=jCpj1DkGn2WZHc4Fpe0cqvU/BSH3r+u6xLLfekVwnX11Y23dKnRx6P13nhsJUBA15y XnhqJYWXHtoZwezVz6x9UX7rdQQ0DNTRU2/QJq8OuITpFqqZoI5ykVzJqKSzOOZY3usI IiemPud7KJqgQvEks3EuowSBuEbmUPal3EG90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=XRFHnWFN8LKhoYJqrRRBlTPDR2uI8AxW3Tl7HChA4/mIc99f+IRhI36fpvKZx61L5A 85TrPXsYjuIEIOZyxE2in+XRNv0BimPV3I4ZNaSTIXloabBWsSkyu+/xzcWdqzv7uXRM Fec02zSLA+QhqzvLo4/9Gnhku65PzeqRKTGxI= Received: by 10.68.47.225 with SMTP id g1mr6008101pbn.17.1303250999412; Tue, 19 Apr 2011 15:09:59 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id a4sm192446pbf.56.2011.04.19.15.09.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 15:09:58 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 19 Apr 2011 15:09:07 -0700 From: YongHyeon PYUN Date: Tue, 19 Apr 2011 15:09:07 -0700 To: Paul Thornton Message-ID: <20110419220907.GD1637@michelle.cdnetworks.com> References: <4DADD913.5010208@prt.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <4DADD913.5010208@prt.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:10:00 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 19, 2011 at 07:48:51PM +0100, Paul Thornton wrote: > Hi, > > The bge driver doesn't support this chipset yet and I was wondering if > anyone has looked at implementing it. > > NetBSD looks like it has support for it. Now I may be wrong here, but > it appears that the BCM57765 is similar to other devices based on the > NetBSD if_bge.c source version 1.194. > > I've tried applying the NetBSD changes to the FreeBSD bge source but I > don't know enough about the hardware and the code is different enough > that I haven't made it very far. I can get a patched 8.2 kernel to > detect the device, complain that the ASIC is unknown, read the MAC > address correctly and determine there is link but as soon as you attempt > to ifconfig up the interface the machine locks up. > > I'm happy to try and port this over but need a nudge in the right > direction from someone who knows the code. > Here is experimental patch for BCM57765 family controllers. I don't have these controllers so the patch was not tested at all except compile. Recent Broadcom controllers like BCM57765 support EEE(Energy Efficient Ethernet) feature but it is not yet supported by the patch. Also it would good to see the output of "pciconf -lcbv" and dmesg after applying the patch. --EeQfGwPcQSOJBaQU Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.57765.diff" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 220872) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -223,6 +223,7 @@ #define BGE_PCI_ISR_MBX_LO 0xB4 #define BGE_PCI_PRODID_ASICREV 0xBC #define BGE_PCI_GEN2_PRODID_ASICREV 0xF4 +#define BGE_PCI_GEN15_PRODID_ASICREV 0xFC /* PCI Misc. Host control register */ #define BGE_PCIMISCCTL_CLEAR_INTA 0x00000001 @@ -318,6 +319,7 @@ #define BGE_CHIPID_BCM57780_A1 0x57780001 #define BGE_CHIPID_BCM5717_A0 0x05717000 #define BGE_CHIPID_BCM5717_B0 0x05717100 +#define BGE_CHIPID_BCM57765_A0 0x57785000 /* shorthand one */ #define BGE_ASICREV(x) ((x) >> 12) @@ -342,6 +344,7 @@ #define BGE_ASICREV_BCM5761 0x5761 #define BGE_ASICREV_BCM5784 0x5784 #define BGE_ASICREV_BCM5785 0x5785 +#define BGE_ASICREV_BCM57765 0x57785 #define BGE_ASICREV_BCM57780 0x57780 /* chip revisions */ @@ -381,6 +384,8 @@ #define BGE_PCIDMARWCTL_RD_CMD_SHIFT(x) ((x) << 24) #define BGE_PCIDMARWCTL_WR_CMD_SHIFT(x) ((x) << 28) +#define BGE_PCIDMARWCTL_CRDRDR_RDMA_MRRS_MSK 0x00000380 + #define BGE_PCI_READ_BNDRY_DISABLE 0x00000000 #define BGE_PCI_READ_BNDRY_16BYTES 0x00000100 #define BGE_PCI_READ_BNDRY_32BYTES 0x00000200 @@ -2298,9 +2303,15 @@ #define BCOM_DEVICEID_BCM5906 0x1712 #define BCOM_DEVICEID_BCM5906M 0x1713 #define BCOM_DEVICEID_BCM57760 0x1690 +#define BCOM_DEVICEID_BCM57761 0x16B0 +#define BCOM_DEVICEID_BCM57765 0x16B4 #define BCOM_DEVICEID_BCM57780 0x1692 +#define BCOM_DEVICEID_BCM57781 0x16B1 +#define BCOM_DEVICEID_BCM57785 0x16B5 #define BCOM_DEVICEID_BCM57788 0x1691 #define BCOM_DEVICEID_BCM57790 0x1694 +#define BCOM_DEVICEID_BCM57791 0x16B2 +#define BCOM_DEVICEID_BCM57795 0x16B6 /* * Alteon AceNIC PCI vendor/device ID. Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 220872) +++ sys/dev/bge/if_bge.c (working copy) @@ -214,9 +214,15 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5906 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5906M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM57760 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57761 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57765 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM57780 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57781 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57785 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM57788 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM57790 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57791 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57795 }, { SK_VENDORID, SK_DEVICEID_ALTIMA }, @@ -335,6 +341,7 @@ /* 5754 and 5787 share the same ASIC ID */ { BGE_ASICREV_BCM5787, "unknown BCM5754/5787" }, { BGE_ASICREV_BCM5906, "unknown BCM5906" }, + { BGE_ASICREV_BCM57765, "unknown BCM57765" }, { BGE_ASICREV_BCM57780, "unknown BCM57780" }, { BGE_ASICREV_BCM5717, "unknown BCM5717" }, @@ -1467,8 +1474,11 @@ if (sc->bge_asicrev == BGE_ASICREV_BCM5703 || sc->bge_asicrev == BGE_ASICREV_BCM5704) dma_rw_ctl &= ~BGE_PCIDMARWCTL_MINDMA; - if (BGE_IS_5717_PLUS(sc)) + if (BGE_IS_5717_PLUS(sc)) { dma_rw_ctl &= ~BGE_PCIDMARWCTL_DIS_CACHE_ALIGNMENT; + if (sc->bge_chipid == BGE_CHIPID_BCM57765_A0) + dma_rw_ctl &= ~BGE_PCIDMARWCTL_CRDRDR_RDMA_MRRS_MSK; + } pci_write_config(sc->bge_dev, BGE_PCI_DMA_RW_CTL, dma_rw_ctl, 4); /* @@ -1552,7 +1562,8 @@ } /* Configure mbuf pool watermarks */ - if (sc->bge_asicrev == BGE_ASICREV_BCM5717) { + if (sc->bge_asicrev == BGE_ASICREV_BCM5717 || + sc->bge_asicrev == BGE_ASICREV_BCM57765) { CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); if (sc->bge_ifp->if_mtu > ETHERMTU) { CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x7e); @@ -1819,7 +1830,8 @@ limit = 16; } else if (!BGE_IS_5705_PLUS(sc)) limit = BGE_RX_RINGS_MAX; - else if (sc->bge_asicrev == BGE_ASICREV_BCM5755) + else if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || + sc->bge_asicrev == BGE_ASICREV_BCM57765) limit = 4; else limit = 1; @@ -2180,6 +2192,15 @@ id = pci_read_config(dev, BGE_PCI_GEN2_PRODID_ASICREV, 4); break; + case BCOM_DEVICEID_BCM57761: + case BCOM_DEVICEID_BCM57765: + case BCOM_DEVICEID_BCM57781: + case BCOM_DEVICEID_BCM57785: + case BCOM_DEVICEID_BCM57791: + case BCOM_DEVICEID_BCM57795: + id = pci_read_config(dev, + BGE_PCI_GEN15_PRODID_ASICREV, 4); + break; default: id = pci_read_config(dev, BGE_PCI_PRODID_ASICREV, 4); @@ -2694,6 +2715,15 @@ sc->bge_chipid = pci_read_config(dev, BGE_PCI_GEN2_PRODID_ASICREV, 4); break; + case BCOM_DEVICEID_BCM57761: + case BCOM_DEVICEID_BCM57765: + case BCOM_DEVICEID_BCM57781: + case BCOM_DEVICEID_BCM57785: + case BCOM_DEVICEID_BCM57791: + case BCOM_DEVICEID_BCM57795: + sc->bge_chipid = pci_read_config(dev, + BGE_PCI_GEN15_PRODID_ASICREV, 4); + break; default: sc->bge_chipid = pci_read_config(dev, BGE_PCI_PRODID_ASICREV, 4); @@ -2750,9 +2780,11 @@ /* Save chipset family. */ switch (sc->bge_asicrev) { case BGE_ASICREV_BCM5717: + sc->bge_flags |= BGE_FLAG_SHORT_DMA_BUG; + case BGE_ASICREV_BCM57765: sc->bge_flags |= BGE_FLAG_5717_PLUS | BGE_FLAG_5755_PLUS | BGE_FLAG_575X_PLUS | BGE_FLAG_5705_PLUS | BGE_FLAG_JUMBO | - BGE_FLAG_SHORT_DMA_BUG | BGE_FLAG_JUMBO_FRAME; + BGE_FLAG_JUMBO_FRAME; break; case BGE_ASICREV_BCM5755: case BGE_ASICREV_BCM5761: @@ -2801,6 +2833,7 @@ sc->bge_asicrev != BGE_ASICREV_BCM5906 && sc->bge_asicrev != BGE_ASICREV_BCM5717 && sc->bge_asicrev != BGE_ASICREV_BCM5785 && + sc->bge_asicrev != BGE_ASICREV_BCM57765 && sc->bge_asicrev != BGE_ASICREV_BCM57780) { if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || sc->bge_asicrev == BGE_ASICREV_BCM5761 || @@ -3466,6 +3499,9 @@ device_printf(dev, "firmware handshake timed out, found 0x%08x\n", val); + /* BCM57765 A0 needs additional time before accessing. */ + if (sc->bge_chipid == BGE_CHIPID_BCM57765_A0) + DELAY(10 * 1000); /* XXX */ } /* @@ -3506,7 +3542,7 @@ /* XXX: Broadcom Linux driver. */ if (sc->bge_flags & BGE_FLAG_PCIE && - sc->bge_asicrev != BGE_ASICREV_BCM5717 && + !BGE_IS_5717_PLUS(sc) && sc->bge_chipid != BGE_CHIPID_BCM5750_A0 && sc->bge_asicrev != BGE_ASICREV_BCM5785) { /* Enable Data FIFO protection. */ @@ -4739,7 +4775,10 @@ * this number of frames, it will drop subsequent incoming * frames until the MBUF High Watermark is reached. */ - CSR_WRITE_4(sc, BGE_MAX_RX_FRAME_LOWAT, 2); + if (sc->bge_asicrev == BGE_ASICREV_BCM57765) + CSR_WRITE_4(sc, BGE_MAX_RX_FRAME_LOWAT, 1); + else + CSR_WRITE_4(sc, BGE_MAX_RX_FRAME_LOWAT, 2); /* Clear MAC statistics. */ if (BGE_IS_5705_PLUS(sc)) --EeQfGwPcQSOJBaQU-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 10:54:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B539A106564A for ; Wed, 20 Apr 2011 10:54:34 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp6.uk.umis.net (smtp6.mail.clearhost.co.uk [IPv6:2001:1420::25:106]) by mx1.freebsd.org (Postfix) with ESMTP id 23DD08FC08 for ; Wed, 20 Apr 2011 10:54:33 +0000 (UTC) Received: from kate.prtsystems.ltd.uk ([217.65.165.35]) by smtp6.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QCV3I-00059T-AG; Wed, 20 Apr 2011 10:54:32 +0000 Message-ID: <4DAEBB67.7070303@prt.org> Date: Wed, 20 Apr 2011 11:54:31 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> In-Reply-To: <20110419220907.GD1637@michelle.cdnetworks.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------010401070707060509080501" Cc: pyunyh@gmail.com Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 10:54:34 -0000 This is a multi-part message in MIME format. --------------010401070707060509080501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 19/04/2011 23:09, YongHyeon PYUN wrote: > Here is experimental patch for BCM57765 family controllers. I > don't have these controllers so the patch was not tested at all > except compile. Recent Broadcom controllers like BCM57765 support > EEE(Energy Efficient Ethernet) feature but it is not yet supported > by the patch. Many thanks for this patch. The patch wouldn't apply cleanly to either the 8.2-release source or to the latest if_bge / if_bgereg so I had to do it manually; but that wasn't too much of a problem. What revision should I have tried to apply the patch to? Things are not fully working yet after the patch is applied though. The current state is that the device is recognised, MAC address detected OK, link state detected OK; you can ifconfig up the interface without a problem. However, I'm seeing "bge0: watchdog timeout -- resetting" messages shortly after attempting to ping something on the LAN. The machine being pinged doesn't show up in the ARP cache. Looking at the switch that its connected to, I see the mac address learned on the port, and the received packet and byte counts incrementing with no errors so I believe that the machine is successfully transmitting frames but not able to receive them properly. The switch stats show that the switch is transmitting frames to the machine. > Also it would good to see the output of "pciconf -lcbv" and dmesg > after applying the patch. The machine in question is a 2010 Mac Mini (model rev A1347) - this has a number of "features" that make FreeBSD an interesting challenge. The kernel I'm using is a normal 8.2-GENERIC with another very minor tweak to stop the Nvidia MCP89 ata controller from being used in SATA mode (this doesn't work - Linux has a workaround based on using UDMA). Attached is a dmesg, pciconf, and the output of sysctl -a dev.bge.0 after the patch was applied. If there is any other debugging information I need to get to help please let me know. Once we have this working I'll willingly give it some thorough proper testing. Thanks again, Paul. --------------010401070707060509080501 Content-Type: text/plain; name="dmesg1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg1.txt" Copyright (c) 1992-2011 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 8.2-RELEASE #1: Wed Apr 20 08:58:24 UTC 2011 root@badger.prt.org:/usr/src/sys/amd64/compile/GENERIC-TEST2 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (2389.26-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1780576256 (1698 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported acpi_hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) isab0: port 0x2100-0x21ff at device 3.0 on pci0 isa0: on isab0 pci0: at device 3.1 (no driver attached) pci0: at device 3.2 (no driver attached) pci0: at device 3.3 (no driver attached) pci0: at device 3.4 (no driver attached) ohci0: mem 0x9358a000-0x9358afff irq 18 at device 4.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0x9358b100-0x9358b1ff irq 19 at device 4.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.10 usbus1: on ehci0 ohci1: mem 0x93589000-0x93589fff irq 20 at device 6.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0x9358b000-0x9358b0ff irq 21 at device 6.1 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.10 usbus3: on ehci1 pci0: at device 8.0 (no driver attached) atapci0: port 0x2298-0x229f,0x22a4-0x22a7,0x2290-0x2297,0x22a0-0x22a3,0x2280-0x228f mem 0x93584000-0x93585fff irq 23 at device 10.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 11.0 (no driver attached) pcib1: at device 14.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 fwohci0: <1394 Open Host Controller Interface> mem 0x93404000-0x934047ff,0x93400000-0x93403fff irq 16 at device 0.0 on pci2 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 e8:06:88:ff:fe:c5:72:4e fwohci0: invalid speed 7 (fixed to 3). fwohci0: Phy 1394a available S800, 3 ports. fwohci0: Link S800, max_rec 4096 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: ea:06:88:c5:72:4e fwe0: Ethernet address: ea:06:88:c5:72:4e fwip0: on firewire0 fwip0: Firewire address: e8:06:88:ff:fe:c5:72:4e @ 0xfffe00000000, S800, maxrec 4096 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x6b3c4000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, non CYCLEMASTER mode pcib3: at device 21.0 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: at device 22.0 on pci0 pci4: on pcib4 bge0: mem 0x93100000-0x9310ffff,0x93110000-0x9311ffff irq 18 at device 0.0 on pci4 bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E miibus0: on bge0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [FILTER] pci4: at device 0.1 (no driver attached) pcib5: at device 23.0 on pci0 pci5: on pcib5 vgapci0: port 0x1000-0x107f mem 0x92000000-0x92ffffff,0x80000000-0x8fffffff,0x90000000-0x91ffffff irq 20 at device 0.0 on pci5 atrtc0: port 0x70-0x77 on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd: unable to get the current command byte value. atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to get the current command byte value. est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 RTC BIOS diagnostic error f1 Timecounters tick every 1.000 msec firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) fwohci0: phy int usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad4: DMA limited to UDMA33, device found non-ATA66 cable ad4: 305245MB at ata2-master UDMA33 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 firewire0: New S400 device ID:000000301b464286 ata3: timeout waiting for read DRQ uhub0: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered ata3: timeout waiting for read DRQ acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata3-master UDMA33 uhub1: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen1.2: at usbus1 uhub4: on usbus1 ugen2.2: at usbus2 ums0: on usbus2 ums0: 3 buttons and [XYZ] coordinates ID=0 uhub4: 3 ports with 2 removable, bus powered SMP: AP CPU #1 Launched! ugen1.3: at usbus1 ugen2.3: at usbus2 ukbd1: on usbus1 kbd2 at ukbd1 uhid0: on usbus2 uhid1: on usbus1 ugen2.4: at usbus2 uhub5: on usbus2 uhub5: 3 ports with 0 removable, self powered ugen2.5: at usbus2 ukbd0: on usbus2 kbd3 at ukbd0 ugen2.6: at usbus2 ums1: on usbus2 ums1: 3 buttons and [XY] coordinates ID=2 ugen2.7: at usbus2 Trying to mount root from ufs:/dev/ad4p2a WARNING: /mnt was not properly dismounted WARNING: /mnt/tmp was not properly dismounted WARNING: /mnt/usr was not properly dismounted WARNING: /mnt/var was not properly dismounted ugen1.4: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3824MB (7831552 512 byte sectors: 255H 63S/T 487C) --------------010401070707060509080501 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pciconf.txt" hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x0d6010de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge subclass = HOST-PCI none0@pci0:0:0:1: class=0x050000 card=0x00000000 chip=0x0d6810de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none1@pci0:0:1:0: class=0x050000 card=0x00000000 chip=0x0d6d10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none2@pci0:0:1:1: class=0x050000 card=0x00000000 chip=0x0d6e10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none3@pci0:0:1:2: class=0x050000 card=0x00000000 chip=0x0d6f10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none4@pci0:0:1:3: class=0x050000 card=0x00000000 chip=0x0d7010de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none5@pci0:0:2:0: class=0x050000 card=0x00000000 chip=0x0d7110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none6@pci0:0:2:1: class=0x050000 card=0x00000000 chip=0x0d7210de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM isab0@pci0:0:3:0: class=0x060100 card=0xcb89106b chip=0x0d8010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-ISA bar [10] = type I/O Port, range 32, base 0x2100, size 256, enabled none7@pci0:0:3:1: class=0x050000 card=0x00000000 chip=0x0d7b10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none8@pci0:0:3:2: class=0x0c0500 card=0xcb8910de chip=0x0d7910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = SMBus bar [20] = type I/O Port, range 32, base 0x2240, size 64, enabled bar [24] = type I/O Port, range 32, base 0x2200, size 64, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 none9@pci0:0:3:3: class=0x050000 card=0x00000000 chip=0x0d6910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM none10@pci0:0:3:4: class=0x0b4000 card=0xcb8910de chip=0x0d7a10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = processor bar [10] = type Memory, range 32, base 0x93500000, size 524288, enabled ohci0@pci0:0:4:0: class=0x0c0310 card=0xcb8910de chip=0x0d9c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0x9358a000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci0@pci0:0:4:1: class=0x0c0320 card=0xcb8910de chip=0x0d9d10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0x9358b100, size 256, enabled cap 0a[44] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 ohci1@pci0:0:6:0: class=0x0c0310 card=0xcb8910de chip=0x0d9c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0x93589000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci1@pci0:0:6:1: class=0x0c0320 card=0xcb8910de chip=0x0d9d10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0x9358b000, size 256, enabled cap 0a[44] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 none11@pci0:0:8:0: class=0x040300 card=0xcb8910de chip=0x0d9410de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = multimedia subclass = HDA bar [10] = type Memory, range 32, base 0x93580000, size 16384, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 08[6c] = HT MSI fixed address window disabled at 0xfee00000 atapci0@pci0:0:10:0: class=0x010185 card=0xcb89106b chip=0x0d8510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x2298, size 8, enabled bar [14] = type I/O Port, range 32, base 0x22a4, size 4, enabled bar [18] = type I/O Port, range 32, base 0x2290, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x22a0, size 4, enabled bar [20] = type I/O Port, range 32, base 0x2280, size 16, enabled bar [24] = type Memory, range 32, base 0x93584000, size 8192, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 12[8c] = SATA Index-Data Pair cap 05[b0] = MSI supports 8 messages, 64 bit none12@pci0:0:11:0: class=0x050000 card=0x00000000 chip=0x0d7510de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM bar [10] = type Memory, range 32, base 0x93588000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks pcib1@pci0:0:14:0: class=0x060400 card=0x000010de chip=0x0d9a10de rev=0xa1 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x000010de cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window disabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port max data 128(128) link x1(x1) pcib3@pci0:0:21:0: class=0x060400 card=0x000010de chip=0x0d9b10de rev=0xa1 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x000010de cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window disabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port max data 128(128) link x1(x1) pcib4@pci0:0:22:0: class=0x060400 card=0x000010de chip=0x0d9b10de rev=0xa1 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x000010de cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window enabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port max data 128(128) link x1(x1) pcib5@pci0:0:23:0: class=0x060400 card=0x000010de chip=0x0d7610de rev=0xa1 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x000010de cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x823e104c rev=0x01 hdr=0x01 vendor = 'Texas Instruments (TI)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[60] = MSI supports 16 messages, 64 bit cap 0d[80] = PCI Bridge card=0x00000000 cap 10[90] = PCI-Express 1 PCI bridge max data 128(512) link x1(x1) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 1 corrected fwohci0@pci0:2:0:0: class=0x0c0010 card=0x00000000 chip=0x823f104c rev=0x01 hdr=0x00 vendor = 'Texas Instruments (TI)' class = serial bus subclass = FireWire bar [10] = type Memory, range 32, base 0x93404000, size 2048, enabled bar [14] = type Memory, range 32, base 0x93400000, size 16384, enabled cap 01[44] = powerspec 3 supports D0 D1 D2 D3 current D0 none13@pci0:3:0:0: class=0x028000 card=0x0093106b chip=0x435314e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' class = network bar [10] = type Memory, range 64, base 0x93300000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[48] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[13c] = VC 1 max VC0 ecap 0003[160] = Serial 1 5bc935ffff8858b0 ecap 0004[16c] = unknown 1 bge0@pci0:4:0:0: class=0x020000 card=0x16b414e4 chip=0x16b414e4 rev=0x00 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet bar [10] = type Prefetchable Memory, range 64, base 0x93100000, size 65536, enabled bar [18] = type Prefetchable Memory, range 64, base 0x93110000, size 65536, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 8 messages, 64 bit enabled with 1 message cap 11[a0] = MSI-X supports 7 messages in map 0x18 cap 10[ac] = PCI-Express 2 endpoint max data 128(128) link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[13c] = Serial 1 0000c42c03080b9d ecap 0004[150] = unknown 1 ecap 0002[160] = VC 1 max VC0 none14@pci0:4:0:1: class=0x080501 card=0x000014e4 chip=0x16bc14e4 rev=0x00 hdr=0x00 vendor = 'Broadcom Corporation' class = base peripheral subclass = SD host controller bar [10] = type Prefetchable Memory, range 64, base 0x93120000, size 65536, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 1 message, 64 bit cap 10[ac] = PCI-Express 2 endpoint max data 128(128) link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[150] = unknown 1 ecap 0002[160] = VC 1 max VC0 vgapci0@pci0:5:0:0: class=0x030000 card=0x00c0106b chip=0x08a410de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = display subclass = VGA bar [10] = type Memory, range 32, base 0x92000000, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0x80000000, size 268435456, enabled bar [1c] = type Prefetchable Memory, range 64, base 0x90000000, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0x1000, size 128, enabled cap 01[60] = powerspec 3 supports D0 D3 current D0 cap 05[68] = MSI supports 1 message, 64 bit cap 09[e0] = vendor (length 20) --------------010401070707060509080501 Content-Type: text/plain; name="sysctl.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysctl.txt" dev.bge.0.%desc: Broadcom unknown BCM57765, ASIC rev. 0x57785000 dev.bge.0.%driver: bge dev.bge.0.%location: slot=0 function=0 handle=\_SB_.PCI0.RP06.GIGE dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x16b4 subvendor=0x14e4 subdevice=0x16b4 class=0x020000 dev.bge.0.%parent: pci4 dev.bge.0.forced_collapse: 0 dev.bge.0.forced_udpcsum: 0 dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 0 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 0 dev.bge.0.stats.RecvThresholdHit: 0 dev.bge.0.stats.rx.ifHCInOctets: 4497 dev.bge.0.stats.rx.Fragments: 0 dev.bge.0.stats.rx.UnicastPkts: 21 dev.bge.0.stats.rx.MulticastPkts: 7 dev.bge.0.stats.rx.BroadcastPkts: 36 dev.bge.0.stats.rx.FCSErrors: 0 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.tx.ifHCOutOctets: 1152 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UnicastPkts: 0 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 18 dev.bge.0.wake: 0 bge0: flags=8802 metric 0 mtu 1500 options=c019b ether c4:2c:03:08:0b:9d inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active --------------010401070707060509080501-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 12:36:58 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F2E3106566B; Wed, 20 Apr 2011 12:36:58 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD648FC1C; Wed, 20 Apr 2011 12:36:58 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 81DC84AC42; Wed, 20 Apr 2011 16:36:56 +0400 (MSD) Date: Wed, 20 Apr 2011 16:36:55 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1117238404.20110420163655@serebryakov.spb.ru> To: bug-followup@FreeBSD.org, seh-10lzx4@mail.quadrizen.com MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:36:58 -0000 Hello, Bug-followup. It is still valid for 8.2-STABLE: gateway# ipfw add 50000 allow ipv6-icmp from any to 2001:470:1f09:hhhh::/64= ,2001:470:hhhh:1::/64,2001:470:hhhh:2::/64 icmp6types 1,2,3,4,128,129 keep-= state ipfw: bad netmask ``470:1f09:hhhh::/64'' gateway# uname -a FreeBSD gateway.home.serebryakov.spb.ru 8.2-STABLE FreeBSD 8.2-STABLE #0: F= ri Apr 15 16:57:44 MSD 2011 lev@vmware-8-32.home.serebryakov.spb.ru:/us= r/obj/nanobsd.gateway-net5501/usr/src/sys/NET5501 i386 It is very annoying bug, because "allow" rule can be divided into one-rule-per-network, but "deny ... NOT IPv6,IPv6,..." is hard to emulate (with multiple skipto rules). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 12:43:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AC35106564A for ; Wed, 20 Apr 2011 12:43:59 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C4FE08FC1C for ; Wed, 20 Apr 2011 12:43:58 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1QCVni-0003ni-Gt for freebsd-net@freebsd.org; Wed, 20 Apr 2011 14:42:30 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id BD7DA1CC0B; Wed, 20 Apr 2011 14:42:26 +0300 (EEST) Date: Wed, 20 Apr 2011 14:42:25 +0300 From: Andrey Simonenko To: freebsd-net@freebsd.org Message-ID: <20110420114225.GA29917@pm513-1.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 10-Dec-2010 16:36:10) X-Date: 2011-04-20 14:42:30 X-Connected-IP: 10.18.52.101:13253 X-Message-Linecount: 30 X-Body-Linecount: 18 X-Message-Size: 896 X-Body-Size: 395 Subject: sys/net/radix.c refuses addresses with all zeroes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:43:59 -0000 Hello, The sys/net/radix.c refuses to add 0.0.0.0 address to the tree, but allows to add 0.0.0.0/32 address (when mask is specified). The question. Is it not allowed to give address with all zeroes to radix.c or is there some mistake in the radix.c code? How to check: Create file, say, zero-export: / 0.0.0.0 / -network 0.0.0.0/32 / :: / -network ::/128 and run "mountd -d zero-export". From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 13:22:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE2BD106566B for ; Wed, 20 Apr 2011 13:22:49 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp6.uk.umis.net (smtp6.mail.clearhost.co.uk [IPv6:2001:1420::25:106]) by mx1.freebsd.org (Postfix) with ESMTP id 857AF8FC08 for ; Wed, 20 Apr 2011 13:22:49 +0000 (UTC) Received: from kate.prtsystems.ltd.uk ([217.65.165.35]) by smtp6.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QCXMl-0009iT-Vq; Wed, 20 Apr 2011 13:22:48 +0000 Message-ID: <4DAEDE27.8080205@prt.org> Date: Wed, 20 Apr 2011 14:22:47 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marius Strobl References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> <4DAEBB67.7070303@prt.org> <20110420131613.GA84319@alchemy.franken.de> In-Reply-To: <20110420131613.GA84319@alchemy.franken.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 13:22:49 -0000 Hi, On 20/04/2011 14:16, Marius Strobl wrote: > Looks like brgphy(4) also needs to be taught about this hardware. Could > you please provide the corresponding part of a verbose dmesg? Hopefully this covers everything that you might need: pcib4: slot 0 INTA is routed to irq 18 found-> vendor=0x14e4, dev=0x16bc, revid=0x00 domain=0, bus=4, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0x93120000, size 16, enabled pcib4: requested memory range 0x93120000-0x9312ffff: good pcib0: matched entry for 0.22.INTB (src \\_SB_.PCI0.Z00O:0) pci_link13: Picked IRQ 19 with weight 1 pcib0: slot 22 INTB routed to irq 19 via \\_SB_.PCI0.Z00O pcib4: slot 0 INTB is routed to irq 19 bge0: mem 0x93100000-0x9310ffff,0x93110000-0x9311ffff irq 18 at device 0.0 on pci4 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x93100000 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x00d897, model 0x0024, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Many thanks, Paul. From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 13:28:48 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1031106564A for ; Wed, 20 Apr 2011 13:28:48 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6A48FC16 for ; Wed, 20 Apr 2011 13:28:47 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p3KDGD8f084376; Wed, 20 Apr 2011 15:16:13 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p3KDGDTd084375; Wed, 20 Apr 2011 15:16:13 +0200 (CEST) (envelope-from marius) Date: Wed, 20 Apr 2011 15:16:13 +0200 From: Marius Strobl To: Paul Thornton Message-ID: <20110420131613.GA84319@alchemy.franken.de> References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> <4DAEBB67.7070303@prt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DAEBB67.7070303@prt.org> User-Agent: Mutt/1.4.2.3i Cc: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 13:28:49 -0000 On Wed, Apr 20, 2011 at 11:54:31AM +0100, Paul Thornton wrote: > bge0: mem 0x93100000-0x9310ffff,0x93110000-0x9311ffff irq 18 at device 0.0 on pci4 > bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E > miibus0: on bge0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Looks like brgphy(4) also needs to be taught about this hardware. Could you please provide the corresponding part of a verbose dmesg? Marius From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 13:45:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC70106564A for ; Wed, 20 Apr 2011 13:45:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id B67788FC13 for ; Wed, 20 Apr 2011 13:45:00 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p3KDixoe084531; Wed, 20 Apr 2011 15:44:59 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p3KDix06084530; Wed, 20 Apr 2011 15:44:59 +0200 (CEST) (envelope-from marius) Date: Wed, 20 Apr 2011 15:44:59 +0200 From: Marius Strobl To: Paul Thornton Message-ID: <20110420134459.GL38455@alchemy.franken.de> References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> <4DAEBB67.7070303@prt.org> <20110420131613.GA84319@alchemy.franken.de> <4DAEDE27.8080205@prt.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline In-Reply-To: <4DAEDE27.8080205@prt.org> User-Agent: Mutt/1.4.2.3i Cc: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 13:45:01 -0000 --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 20, 2011 at 02:22:47PM +0100, Paul Thornton wrote: > Hi, > > On 20/04/2011 14:16, Marius Strobl wrote: > > Looks like brgphy(4) also needs to be taught about this hardware. Could > > you please provide the corresponding part of a verbose dmesg? > > Hopefully this covers everything that you might need: > > pcib4: slot 0 INTA is routed to irq 18 > found-> vendor=0x14e4, dev=0x16bc, revid=0x00 > domain=0, bus=4, slot=0, func=1 > class=08-05-01, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=7 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Prefetchable Memory, range 64, base 0x93120000, size 16, > enabled > pcib4: requested memory range 0x93120000-0x9312ffff: good > pcib0: matched entry for 0.22.INTB (src \\_SB_.PCI0.Z00O:0) > pci_link13: Picked IRQ 19 with weight 1 > pcib0: slot 22 INTB routed to irq 19 via \\_SB_.PCI0.Z00O > pcib4: slot 0 INTB is routed to irq 19 > bge0: mem > 0x93100000-0x9310ffff,0x93110000-0x9311ffff irq 18 at device 0.0 on pci4 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x93100000 > bge0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > bge0: using IRQ 256 for MSI > bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E > bge0: Disabling fastboot > bge0: Disabling fastboot > miibus0: on bge0 > ukphy0: PHY 1 on miibus0 > ukphy0: OUI 0x00d897, model 0x0024, rev. 0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: c4:2c:03:08:0b:9d > bge0: [MPSAFE] > bge0: [FILTER] > Hrm, looks like neither NetBSD nor OpenBSD support this variant so far, however Linux also doesn't seem to have special handling for it. Could you please give the attached patch in addition to the existing one a try? Marius --UfEAyuTBtIjiZzX6 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="brgphy_57785.diff" Index: brgphy.c =================================================================== --- brgphy.c (revision 220886) +++ brgphy.c (working copy) @@ -143,6 +143,7 @@ static const struct mii_phydesc brgphys[] = { MII_PHY_DESC(xxBROADCOM_ALT1, BCM5761), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5709S), MII_PHY_DESC(xxBROADCOM_ALT2, BCM5717C), + MII_PHY_DESC(xxBROADCOM_ALT2, BCM57785), MII_PHY_DESC(BROADCOM2, BCM5906), MII_PHY_END }; Index: miidevs =================================================================== --- miidevs (revision 220886) +++ miidevs (working copy) @@ -159,6 +159,7 @@ model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/ model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY model xxBROADCOM_ALT2 BCM5717C 0x0020 BCM5717C 10/100/1000baseTX PHY +model xxBROADCOM_ALT2 BCM57785 0x0024 BCM57785 10/100/1000baseTX PHY model BROADCOM2 BCM5906 0x0004 BCM5906 10/100baseTX PHY /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ --UfEAyuTBtIjiZzX6-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 14:16:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20AB106564A for ; Wed, 20 Apr 2011 14:16:27 +0000 (UTC) (envelope-from prvs=10917ca39d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1698FC15 for ; Wed, 20 Apr 2011 14:16:27 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 20 Apr 2011 15:05:13 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 20 Apr 2011 15:05:06 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012987461.msg for ; Wed, 20 Apr 2011 15:03:43 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=10917ca39d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> From: "Steven Hartland" To: Date: Wed, 20 Apr 2011 14:37:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 14:16:27 -0000 Seems there's an issue with the intel ix driver which causes it to bin connections when you manipulate ip aliases. This causes issues on boot when jails start as it bins other active sessions. Is this a know issue? Running 8.2-RELEASE amd64 here. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 15:21:30 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C194F1065672 for ; Wed, 20 Apr 2011 15:21:30 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp6.uk.umis.net (smtp6.mail.clearhost.co.uk [IPv6:2001:1420::25:106]) by mx1.freebsd.org (Postfix) with ESMTP id 694C58FC2D for ; Wed, 20 Apr 2011 15:21:30 +0000 (UTC) Received: from kate.prtsystems.ltd.uk ([217.65.165.35]) by smtp6.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QCZDd-000ARd-03; Wed, 20 Apr 2011 15:21:29 +0000 Message-ID: <4DAEF9F8.5070305@prt.org> Date: Wed, 20 Apr 2011 16:21:28 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marius Strobl References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> <4DAEBB67.7070303@prt.org> <20110420131613.GA84319@alchemy.franken.de> <4DAEDE27.8080205@prt.org> <20110420134459.GL38455@alchemy.franken.de> In-Reply-To: <20110420134459.GL38455@alchemy.franken.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:21:30 -0000 Hi, On 20/04/2011 14:44, Marius Strobl wrote: > Hrm, looks like neither NetBSD nor OpenBSD support this variant so > far, however Linux also doesn't seem to have special handling for it. > Could you please give the attached patch in addition to the existing > one a try? I've added your patch to brgphy as well - but at a user level I'm still seeing the same thing: - Ethernet frames are transmitted by the box, switch sees them with no errors. - Frames received don't seem to make it to/beyond the driver. - After I hit CTRL-C on the non-working ping, I get a "bge0: watchdog timeout -- resetting" message. If I tcpdump the interface, I see nothing, but the dev.bge.0.stats counters are incrementing when I attempt to ping. The switch is showing counts on both its tx and rx packets counters with no errors. Is there somewhere I need to add more debug in the driver to understand what it is doing? The current dmesg looks like: bge0: mem 0x93100000-0x9310ffff,0x93110000-0x9311ffff irq 18 at device 0.0 on pci4 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x93100000 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x00d897, model 0x0024, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Paul. From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 16:00:22 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78FA41065670 for ; Wed, 20 Apr 2011 16:00:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F6838FC08 for ; Wed, 20 Apr 2011 16:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3KG0M1N037995 for ; Wed, 20 Apr 2011 16:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3KG0MTA037994; Wed, 20 Apr 2011 16:00:22 GMT (envelope-from gnats) Date: Wed, 20 Apr 2011 16:00:22 GMT Message-Id: <201104201600.p3KG0MTA037994@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Thomas Johnson Cc: Subject: re: kern/156408: [vlan] Routing failure when using VLANs vs. Physical ethernet interfaces. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas Johnson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 16:00:22 -0000 The following reply was made to PR kern/156408; it has been noted by GNATS. From: Thomas Johnson To: bug-followup@FreeBSD.org, tom@claimlynx.com Cc: Subject: re: kern/156408: [vlan] Routing failure when using VLANs vs. Physical ethernet interfaces. Date: Wed, 20 Apr 2011 10:21:27 -0500 --20cf307d01eeabd00704a15b2dba Content-Type: text/plain; charset=ISO-8859-1 After further investigation, I have learned some new information that may or may not be useful. Although I am able to connect from a host on the office lan over the bridge to hosts on the data center lan, the firewall itself is unable to connect to these same hosts. This can be corrected by adding host static routes to the firewall in the same manner as I described in my initial PR. This behavior appears to be a result of the 172.31.0.0/16 route pointing at the vlan500 interface, as I see ARP requests for dc hosts leave the firewall on the local lan (vlan500). By comparison, my existing/old firewall has a matching route for 172.31.0.0/16 pointing at the local lan (in that case, the lan is a physical adapter, not a vlan). Connections from the firewall to hosts at the dc lan work correctly, and I see ARP requests on both the lan interface and the vpn tap interface. -- Thomas Johnson ClaimLynx, Inc. --20cf307d01eeabd00704a15b2dba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After further investigation, I have learned some new information that may o= r may not be useful.

Although I am able to connect from a host on th= e office lan over the bridge to hosts on the data center lan, the firewall = itself is unable to connect to these same hosts. This can be corrected by a= dding host static routes to the firewall in the same manner as I described = in my initial PR. This behavior appears to be a result of the 172.31.0.0/16 route pointing at t= he vlan500 interface, as I see ARP requests for dc hosts leave the firewall= on the local lan (vlan500).

By comparison, my existing/old firewall has a matching route for 172.31.0.0/16 pointing at the local lan (in = that case, the lan is a physical adapter, not a vlan). Connections from the= firewall to hosts at the dc lan work correctly, and I see ARP requests on = both the lan interface and the vpn tap interface.

--
Thomas Johnson
ClaimLynx, Inc.
--20cf307d01eeabd00704a15b2dba-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 17:19:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFE77106566B for ; Wed, 20 Apr 2011 17:19:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1C58FC1B for ; Wed, 20 Apr 2011 17:19:07 +0000 (UTC) Received: by pwj8 with SMTP id 8so624105pwj.13 for ; Wed, 20 Apr 2011 10:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=OTLu/wL+1PbcM6ZNbmfbKYTgYHbr2OQ4tk6/Sf0QHXs=; b=mFIiCTtSU2mGdSZnf0ztjNMDMaEn/I7nO8M3yASj+/q4H9b3vQmjq5uZlW0l28gs+a DCQBZ+Uxohd6P5bdwElP1k+/sHQOVzz/aQQVBwbce1abVS0EzssNwD4V76dQK5VdT+EP heGiKk/dtsBSdBMVpYiMuh0u7cDTqndebFKtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=HXdwNnFkm2Ub6z9blqBAAm3oA4kRz3upu2Ny4g/fJF9Sv3eXBYiR8lQxqfS9E5Emqm 35iYghorzPwVhCUPVqs+J3RL5t0Lulv4DUUvDXNcibDr+RWTNFtGg9Vin7ojefmffR26 UT5KkObKP748EL03FFUbLGykaJ7EW3rlLQ3f0= Received: by 10.68.21.164 with SMTP id w4mr4874585pbe.53.1303319946999; Wed, 20 Apr 2011 10:19:06 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id m7sm741732pbd.33.2011.04.20.10.19.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 10:19:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 20 Apr 2011 10:18:13 -0700 From: YongHyeon PYUN Date: Wed, 20 Apr 2011 10:18:13 -0700 To: Paul Thornton Message-ID: <20110420171813.GA8566@michelle.cdnetworks.com> References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> <4DAEBB67.7070303@prt.org> <20110420131613.GA84319@alchemy.franken.de> <4DAEDE27.8080205@prt.org> <20110420134459.GL38455@alchemy.franken.de> <4DAEF9F8.5070305@prt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DAEF9F8.5070305@prt.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Marius Strobl Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:19:07 -0000 On Wed, Apr 20, 2011 at 04:21:28PM +0100, Paul Thornton wrote: > Hi, > > On 20/04/2011 14:44, Marius Strobl wrote: > > Hrm, looks like neither NetBSD nor OpenBSD support this variant so > > far, however Linux also doesn't seem to have special handling for it. > > Could you please give the attached patch in addition to the existing > > one a try? > > I've added your patch to brgphy as well - but at a user level I'm still > seeing the same thing: > - Ethernet frames are transmitted by the box, switch sees them with no > errors. > - Frames received don't seem to make it to/beyond the driver. > - After I hit CTRL-C on the non-working ping, I get a "bge0: watchdog > timeout -- resetting" message. > > If I tcpdump the interface, I see nothing, but the dev.bge.0.stats > counters are incrementing when I attempt to ping. > > The switch is showing counts on both its tx and rx packets counters with > no errors. > > Is there somewhere I need to add more debug in the driver to understand > what it is doing? > Ok, that would indicate there is an interrupt delivery issue if all others changes(including Marius' patch) are correct. Because there is no publicly available data sheet for BCM57765 yet I'm not sure what is real difference between BCM5717 and BCM57765. However I guess they require similar hardware configuration. Both BCM5717 and BCM57765 will use tagged status feature of controller if MSI is available. And NVIDIA bridge controller is known to have MSI issues for a long time in FreeBSD. Please check whether you received any interrupts for bge(4) with vmstat(8). If you see no interrupt from the output, either try disabling MSI or apply r219737 and r219740 and see whether that makes any difference. > The current dmesg looks like: > > bge0: mem > 0x93100000-0x9310ffff,0x93110000-0x9311ffff irq 18 at device 0.0 on pci4 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x93100000 > bge0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > bge0: using IRQ 256 for MSI > bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E > bge0: Disabling fastboot > bge0: Disabling fastboot > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x00d897, model 0x0024, rev. 0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: c4:2c:03:08:0b:9d > bge0: [MPSAFE] > bge0: [FILTER] > > Paul. From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 17:21:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 275FC1065675 for ; Wed, 20 Apr 2011 17:21:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id ECD5C8FC12 for ; Wed, 20 Apr 2011 17:21:28 +0000 (UTC) Received: by pwj8 with SMTP id 8so625511pwj.13 for ; Wed, 20 Apr 2011 10:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=AgB08RmAuML2FDobjMHaciTqp+ACdt+GELjdVE2WKzk=; b=LaB4cfpGeFp2XDl9c8LfylbsrOLLdXxPj+jj2iAs3RnizMUwv7lytIO9FD6c1SowTi pRpclf5ac+cOtXZdw3RT0wX5u5DnUpGZYNmZpoBic96L7Hs0W+0BAQ9MqLihGD+UlKSV e4mt3CaQkkZaighJ5nyjWdpEYztz15kSOfLRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=qXSPtLYaeSrG8Dt9UEQV6EPK90brRz1yTAqYhHkdVhSXRdn4TNz2Xq8e+Dz5/muMgJ 8mp3jDwnHwOVfTCt9C2tu/lc0Hcn8PsayudLwCAV6pVf2ZeP3YSesYuhUr5DqxAcmkEr cNspOwCHkxh8vs+oFbtBRgk6cWtZpratVrOqg= Received: by 10.142.43.16 with SMTP id q16mr4109614wfq.364.1303320088612; Wed, 20 Apr 2011 10:21:28 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id j2sm741001pbg.60.2011.04.20.10.21.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 10:21:27 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 20 Apr 2011 10:20:37 -0700 From: YongHyeon PYUN Date: Wed, 20 Apr 2011 10:20:37 -0700 To: Paul Thornton Message-ID: <20110420172037.GB8566@michelle.cdnetworks.com> References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> <4DAEBB67.7070303@prt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DAEBB67.7070303@prt.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:21:29 -0000 On Wed, Apr 20, 2011 at 11:54:31AM +0100, Paul Thornton wrote: > On 19/04/2011 23:09, YongHyeon PYUN wrote: > > Here is experimental patch for BCM57765 family controllers. I > > don't have these controllers so the patch was not tested at all > > except compile. Recent Broadcom controllers like BCM57765 support > > EEE(Energy Efficient Ethernet) feature but it is not yet supported > > by the patch. > > Many thanks for this patch. > > The patch wouldn't apply cleanly to either the 8.2-release source or to > the latest if_bge / if_bgereg so I had to do it manually; but that > wasn't too much of a problem. What revision should I have tried to > apply the patch to? > The patch was generated against latest HEAD. > Things are not fully working yet after the patch is applied though. > > The current state is that the device is recognised, MAC address detected > OK, link state detected OK; you can ifconfig up the interface without a > problem. However, I'm seeing "bge0: watchdog timeout -- resetting" > messages shortly after attempting to ping something on the LAN. The > machine being pinged doesn't show up in the ARP cache. > > Looking at the switch that its connected to, I see the mac address > learned on the port, and the received packet and byte counts > incrementing with no errors so I believe that the machine is > successfully transmitting frames but not able to receive them properly. > The switch stats show that the switch is transmitting frames to the > machine. > > > Also it would good to see the output of "pciconf -lcbv" and dmesg > > after applying the patch. > > The machine in question is a 2010 Mac Mini (model rev A1347) - this has > a number of "features" that make FreeBSD an interesting challenge. The > kernel I'm using is a normal 8.2-GENERIC with another very minor tweak > to stop the Nvidia MCP89 ata controller from being used in SATA mode > (this doesn't work - Linux has a workaround based on using UDMA). > Hmm, NVIDIA controller again. See my other posting to this thread. > Attached is a dmesg, pciconf, and the output of sysctl -a dev.bge.0 > after the patch was applied. > > If there is any other debugging information I need to get to help please > let me know. Once we have this working I'll willingly give it some > thorough proper testing. > > Thanks again, > > Paul. From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 22:29:26 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC33106566B; Wed, 20 Apr 2011 22:29:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 51F9C8FC0C; Wed, 20 Apr 2011 22:29:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3KMTQ7s092979; Wed, 20 Apr 2011 22:29:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3KMTQm6092975; Wed, 20 Apr 2011 22:29:26 GMT (envelope-from linimon) Date: Wed, 20 Apr 2011 22:29:26 GMT Message-Id: <201104202229.p3KMTQm6092975@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:29:26 -0000 Old Synopsis: Marvell Yukon 2 device works only few seconds New Synopsis: [msk] Marvell Yukon 2 device works only few seconds Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 20 22:28:37 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=156493 From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 22:45:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D84341065675 for ; Wed, 20 Apr 2011 22:45:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 799538FC13 for ; Wed, 20 Apr 2011 22:45:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0B53E4AC42 for ; Thu, 21 Apr 2011 02:45:16 +0400 (MSD) Date: Thu, 21 Apr 2011 02:45:15 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <969959848.20110421024515@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:45:18 -0000 Hello, Freebsd-net. Is here any stateless dhcp6 solution for FreeBSD? isc-dhcp 4.1 seems to not support statless mode by server dibbler is not ported to FreeBSD. dhcp6s (WIDE-dhcpd) works only with one interface... It is possible, of course, to run multiple instances of dhcp6s for multiple interfaces, but it doesn't look very convenient. I need only distribute IPv6 DNS server addresses to clients, but not prefixes or address information. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 22:55:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB8E6106564A for ; Wed, 20 Apr 2011 22:55:16 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 533D88FC19 for ; Wed, 20 Apr 2011 22:55:16 +0000 (UTC) Received: by eyg7 with SMTP id 7so469534eyg.13 for ; Wed, 20 Apr 2011 15:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.97.30 with SMTP id j30mr3324774ebn.20.1303340115230; Wed, 20 Apr 2011 15:55:15 -0700 (PDT) Received: by 10.213.15.207 with HTTP; Wed, 20 Apr 2011 15:55:15 -0700 (PDT) In-Reply-To: <969959848.20110421024515@serebryakov.spb.ru> References: <969959848.20110421024515@serebryakov.spb.ru> Date: Wed, 20 Apr 2011 18:55:15 -0400 Message-ID: From: Michael Proto To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:55:16 -0000 2011/4/20 Lev Serebryakov : > Hello, Freebsd-net. > > =A0Is here any stateless dhcp6 solution for FreeBSD? > > =A0isc-dhcp 4.1 seems to not support statless mode by server > > =A0dibbler is not ported to FreeBSD. > > =A0dhcp6s (WIDE-dhcpd) works only with one interface... It is possible, > =A0of course, to run multiple instances of dhcp6s for multiple > =A0interfaces, but it doesn't look very convenient. > > =A0I need only distribute IPv6 DNS server addresses to clients, but not > =A0prefixes or address information. Are you sure isc-dhcp doesn't support stateless? I was able to get it working by creating subnet6 entries in dhcpd6.conf and telling rtadvd to operate in other-stateful configuration mode (raflags=3D"o"). At that point, stateless autoconfiguration worked and the clients did a DHCP request to determine their name servers only. -Proto From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 23:12:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D94F106564A; Wed, 20 Apr 2011 23:12:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 02CCD8FC0C; Wed, 20 Apr 2011 23:12:20 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 31DD84AC43; Thu, 21 Apr 2011 03:12:19 +0400 (MSD) Date: Thu, 21 Apr 2011 03:11:56 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <149229911.20110421031156@serebryakov.spb.ru> To: Michael Proto In-Reply-To: References: <969959848.20110421024515@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:12:20 -0000 Hello, Michael. You wrote 21 =E0=EF=F0=E5=EB=FF 2011 =E3., 2:55:15: > Are you sure isc-dhcp doesn't support stateless? I was able to get it > working by creating subnet6 entries in dhcpd6.conf and telling rtadvd > to operate in other-stateful configuration mode (raflags=3D"o"). At that > point, stateless autoconfiguration worked and the clients did a DHCP > request to determine their name servers only. Hm... It is never mentioned in documentation. I've looking for "stateless" word in different forms without any success. I'll try this one, thank you. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 06:49:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C05181065670 for ; Thu, 21 Apr 2011 06:49:14 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 020E68FC0A for ; Thu, 21 Apr 2011 06:49:13 +0000 (UTC) Received: (qmail 16099 invoked from network); 21 Apr 2011 06:49:11 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Apr 2011 06:49:11 -0000 Date: Thu, 21 Apr 2011 08:49:11 +0200 (CEST) Message-Id: <20110421.084911.74735483.sthaug@nethelp.no> To: lev@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <149229911.20110421031156@serebryakov.spb.ru> References: <969959848.20110421024515@serebryakov.spb.ru> <149229911.20110421031156@serebryakov.spb.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mike@jellydonut.org, freebsd-net@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 06:49:14 -0000 > > Are you sure isc-dhcp doesn't support stateless? I was able to get it > > working by creating subnet6 entries in dhcpd6.conf and telling rtadvd > > to operate in other-stateful configuration mode (raflags="o"). At that > > point, stateless autoconfiguration worked and the clients did a DHCP > > request to determine their name servers only. > Hm... It is never mentioned in documentation. I've looking for > "stateless" word in different forms without any success. I'll try this > one, thank you. Think of DHCPv4 and DHCPINFORM - this is also stateless. Nothing magic about it. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 06:51:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7152106564A for ; Thu, 21 Apr 2011 06:51:13 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) Received: from web59709.mail.ac4.yahoo.com (web59709.mail.ac4.yahoo.com [76.13.12.185]) by mx1.freebsd.org (Postfix) with SMTP id 854AE8FC08 for ; Thu, 21 Apr 2011 06:51:13 +0000 (UTC) Received: (qmail 67359 invoked by uid 60001); 21 Apr 2011 06:34:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303367663; bh=v5pN0vjix1qBwkHGN3QXiWEyTDD/dgqKqgNFEgBM/h0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=XgnCrc04S21KFPbSGsafjna9tu1CD9fpwSNl7KLYxiWeAElH2e4PusuTBao1kfR4fT4fZofmaDUWLSkfrog1u6faGiPCKf3bBNyYSATFF+sGLJ56D98p8t7DurRmzkmaZuxVhqmzdUYCCQ0DMCG7qqpyfW0JX3UxXp7YEKJhMN4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=nFit85Un/7oX8+bLO5jQT7fa5XNauHrpyTeV9tMOMl9k1H+wfHfqmsKpnirMD7aNKjZXy8eyo+2kmjj63a+ma44BQS+jSmBjNpvDCAzpG3PVsSy5KTy5OuqLClOwyXXOOvRjopdrhjuirN645tNyQZL6d3mlHvBKkNdFFEefo2I=; Message-ID: <744570.28847.qm@web59709.mail.ac4.yahoo.com> X-YMail-OSG: UqdKxVQVM1nFl5b2hDaNXkFZ_QFjwdUY.dCcEet10zxuWYd Alz8ZYCfCSmMsFRUvuR3RugPXiYTgKAhGw6wUijmErFWIADVliBA6m6JsbXx GPJSq032pszxyja4Tm2fmQxj.A2YLy9UbLFuhwgNN7W4sbVb22_9YDS5MKDU WhVw11Q.zBcFdmhV2xx6xS2hADCH5_QK5UJZfPgmXmqeaMI_WJt.lsoI2vss E7RzG4yhfPMfzjRjjEzTTZ3HM3UZB440HJu1PS4xAvVynRzx11F4dxrUBDiE FrarnKTDXT.y228hxMjW70VGlQhAjDaoFzvilh_Tf7ulR0gdD5yXvWyYiZXP iRrPwdzE4gET3YHFewheCzpstWbY- Received: from [94.183.246.198] by web59709.mail.ac4.yahoo.com via HTTP; Wed, 20 Apr 2011 23:34:23 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Wed, 20 Apr 2011 23:34:23 -0700 (PDT) From: "M. V." To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Gigabit Router Hardware Specs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 06:51:14 -0000 hi, i want to setup a router-box with freebsd 8.0. with four Intel Pro/1000 NICs. the network i'm using router for, is a large and complicated network with high traffic almost all the time (up to 800Mbps for each of 4 NICs). and route table may get large. so these are my questions: 1- first, i wanted to know what hardware specifications do you recommend (RAM, CPU, ...)? 2- about CPU, which feature is more important? Cache, Core-Speed, number of Cores, FSB, ....? 3- as a followup to my second question, which of these CPUs do you think is more suitable for me? and why? a) Intel Core2-Quad q8300 (2.50GHz) b) Intel Xeon e5405 (2.00GHz) c) Intel Xeon e5420 (2.50GHz) d) Intel Core-i5 540M (2.53GHz) thank you. From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 08:16:05 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BDC71065679; Thu, 21 Apr 2011 08:16:05 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F055D8FC12; Thu, 21 Apr 2011 08:16:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3L8G49u058536; Thu, 21 Apr 2011 08:16:04 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3L8G4f7058532; Thu, 21 Apr 2011 08:16:04 GMT (envelope-from glebius) Date: Thu, 21 Apr 2011 08:16:04 GMT Message-Id: <201104210816.p3L8G4f7058532@freefall.freebsd.org> To: sergey.dyatko@gmail.com, glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/154676: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 08:16:05 -0000 Synopsis: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph State-Changed-From-To: patched->closed State-Changed-By: glebius State-Changed-When: Thu Apr 21 08:11:52 UTC 2011 State-Changed-Why: Merged to stable/8. Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Thu Apr 21 08:11:52 UTC 2011 Responsible-Changed-Why: Merged to stable/8. http://www.freebsd.org/cgi/query-pr.cgi?pr=154676 From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 10:36:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D75F1065700 for ; Thu, 21 Apr 2011 10:36:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C11468FC1B for ; Thu, 21 Apr 2011 10:36:30 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bc6b:a78d:dcd1:3a34]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id AB9864AC43 for ; Thu, 21 Apr 2011 14:36:28 +0400 (MSD) Date: Thu, 21 Apr 2011 14:36:25 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <991131094.20110421143625@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: IPv6 after reboot: noting works for ~5 minutes, normal operation after that. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 10:36:31 -0000 Hello, Freebsd-net. Ok, I've set up my router for IPv6 support (everything work at last: routing, prefix announcements, firewall, which allows ping but not access computers in my LAN from outer world, etc), double-check all configs and reboot router to be sure, that everything will work in case of reboot (that all manual changes are reflected in configuration files). Router boots up, all interfaces and firewall are Ok, gif0 interface is up. But for first 5 minutes IPv6 is useless! It can not even ping6 its own end of HE tunnel (bind to gif0)! Echo requests are sent, but no replies. It can not ping other end of tunnel, Goolge's IPv6 addresses, it can not be pinged from outside, etc. I've panicked, but about 5 minutes later everything works! Fully-functional IPv6 router, everything can be pinged, tracerouted, I can connect to outside IPv6 hosts, I can ping internal hosts from outside, etc. I've repeated reboot -- result is the same. 5 minutes router ``doesn't support'' IPv6, everything works after 5 minutes without any changes in configuration from my side. Is it normal? What do I do wrong? I'm sure that it is not firewall problem, as after these 5 minutes "deny" counters of my firewall are almost all zeroes -- only my ISP local network (IPv4) protection shows dropped packets (it has many script kiddies and zombie systems in local network, so it is not surprise me). FreeBSD 8.2-STABLE --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 09:16:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2514106566B for ; Thu, 21 Apr 2011 09:16:33 +0000 (UTC) (envelope-from cy6ergn0m@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C28C8FC08 for ; Thu, 21 Apr 2011 09:16:33 +0000 (UTC) Received: by iwn33 with SMTP id 33so1740626iwn.13 for ; Thu, 21 Apr 2011 02:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=L4BKgvspHl5YOYx+Y3a6xtxNM+zm8gTU8tCBxAAS92o=; b=dPOG+SDIIxMrTD2pcA/YtxMJWpUm6e+wh3Iz46TbjOl9HeQWLDszmxdKoMHWDZ5Epo moOLjkpT0vwAdhTPknEPEsbScPCJI2SYohLM5OOrS8E5NA2v0QwGRc1jmAVgn5m72Y/e MHZe75vkCMBeUIrmI0qwzT9gHJXpYCFO1/q8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FZlYdAbhpwJXFao6Ks6YnqmQRy9boIg6jOFW1oz6+wBx1bsz9Y3szVu3L6UVBGV4eu DxjfujW/xhnIrarWjitgErEkf0p6ya+MgwqMo90+smPPMFZ4PGOPHZ03IC7niSBZWMT9 9L6m+CWAXWWkHg8UXEtZCAcmtHJMbcX8Xy3CU= MIME-Version: 1.0 Received: by 10.231.32.66 with SMTP id b2mr6387454ibd.89.1303375514335; Thu, 21 Apr 2011 01:45:14 -0700 (PDT) Received: by 10.231.200.140 with HTTP; Thu, 21 Apr 2011 01:45:14 -0700 (PDT) Date: Thu, 21 Apr 2011 12:45:14 +0400 Message-ID: From: cyberGn0m To: freebsd-net@freebsd.org X-Mailman-Approved-At: Thu, 21 Apr 2011 10:59:00 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 09:16:33 -0000 Hi all Some other investigations done and I found the following: device still receives data but due to unknown (for me) reason data can't be processed and when msk_handle_events called event ring does not contains OP_RXSTAT events. And after a while RX overrun happens. I tried to change some code but with no success. From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 14:53:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8379E106568B for ; Thu, 21 Apr 2011 14:53:59 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9538FC08 for ; Thu, 21 Apr 2011 14:53:59 +0000 (UTC) Received: from pool-141-154-217-103.bos.east.verizon.net ([141.154.217.103] helo=homobox.opal.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QCvGY-000HqL-Ir; Thu, 21 Apr 2011 14:53:58 +0000 Received: from opal.com (localhost [IPv6:::1]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id p3LErurr072424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 10:53:57 -0400 (EDT) (envelope-from fbsd@opal.com) Received: from shibato.opal.com ([2001:470:8cb8:3:221:63ff:fe5a:c9a7] helo=shibato.opal.com) with IPv6:587 by opal.com; 21 Apr 2011 10:53:56 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 141.154.217.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18kKb8IiEXGKbc932Vmzf8f Date: Thu, 21 Apr 2011 10:53:56 -0400 From: "J.R. Oldroyd" To: lev@freebsd.org Message-ID: <20110421105356.51d881ca@shibato.opal.com> In-Reply-To: <969959848.20110421024515@serebryakov.spb.ru> References: <969959848.20110421024515@serebryakov.spb.ru> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:53:59 -0000 On Thu, 21 Apr 2011 02:45:15 +0400, Lev Serebryakov wrote: > > Hello, Freebsd-net. > > Is here any stateless dhcp6 solution for FreeBSD? > > I need only distribute IPv6 DNS server addresses to clients, but not > prefixes or address information. > DHCP is stateful. If you want stateless, you need IPv6 RDNSS router advertisements. Just over a month ago on this list, I posted patches for IPv6 stateless autoconfiguration of DNS information. There are four parts to the patch: - changes to rtadvd to send the DNS info - changes to rtsold to receive it - a new script, resolvconf(8), to manage resolv.conf updates - changes to /sbin/dhclient-script to use resolvconf(8) (so that IPv4 DHCP and IPv6 RA info can co-exist) These patches conform to RFC 6106. Since you just want to send DNS info and not prefixes, you can use these patches in rtadvd and just configure rdnss info and no prefix info. The patches are here: http://opal.com/jr/freebsd/rdnss/ I've since filed a PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=156259) to have this reviewed and committed. -jr From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 15:08:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 727C7106566C for ; Thu, 21 Apr 2011 15:08:38 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id AB2E28FC14 for ; Thu, 21 Apr 2011 15:08:37 +0000 (UTC) Received: (qmail 61422 invoked from network); 21 Apr 2011 15:08:35 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Apr 2011 15:08:35 -0000 Date: Thu, 21 Apr 2011 17:08:35 +0200 (CEST) Message-Id: <20110421.170835.78742526.sthaug@nethelp.no> To: fbsd@opal.com From: sthaug@nethelp.no In-Reply-To: <20110421105356.51d881ca@shibato.opal.com> References: <969959848.20110421024515@serebryakov.spb.ru> <20110421105356.51d881ca@shibato.opal.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 15:08:38 -0000 > > Is here any stateless dhcp6 solution for FreeBSD? > > > > I need only distribute IPv6 DNS server addresses to clients, but not > > prefixes or address information. > > > > DHCP is stateful. If you want stateless, you need IPv6 RDNSS router > advertisements. Claiming that DHCP is (always) stateful is wrong. DHCP can be stateful or stateless - it depends on what kind of information you ask for, and the type of DHCP request. For DHCPv4 - you can use the DHCPINFORM request to ask for DNS servers and similar, without the server storing any state. For DHCPv6 - you can use the Information-request in a similar way. See RFC 3736, "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", . ISC DHCP version 4 implements Information-request. See for instance file dhcpv6.c, routine dhcpv6_information_request. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 16:36:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EDDE1065673; Thu, 21 Apr 2011 16:36:54 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DFB378FC15; Thu, 21 Apr 2011 16:36:53 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bc6b:a78d:dcd1:3a34]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id DCCB74AC42; Thu, 21 Apr 2011 20:36:51 +0400 (MSD) Date: Thu, 21 Apr 2011 20:36:48 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1615960936.20110421203648@serebryakov.spb.ru> To: "J.R. Oldroyd" In-Reply-To: <20110421105356.51d881ca@shibato.opal.com> References: <969959848.20110421024515@serebryakov.spb.ru> <20110421105356.51d881ca@shibato.opal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:36:54 -0000 Hello, J.R.. You wrote 21 =E0=EF=F0=E5=EB=FF 2011 =E3., 18:53:56: >> I need only distribute IPv6 DNS server addresses to clients, but not >> prefixes or address information. > DHCP is stateful. If you want stateless, you need IPv6 RDNSS router > advertisements. Information-Request message doesn't need state on server side. And IPv6 RDNSS is good thing, but doesn't supported by Windows (yet?)... :( > Since you just want to send DNS info and not prefixes, you can use these > patches in rtadvd and just configure rdnss info and no prefix info. I want to advertise Prefixes and routes via pure IPv6 mechanisms (rtadv), as it supported by all known IPv6-enabled systems. And DNS needs DHCPv6 for Windows clients :( > I've since filed a PR > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D156259) > to have this reviewed and committed. Great! I looks like very valuable addition to FreeBSD, but, unfortunately, it doesn't help client Windows machines in any way :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 16:44:11 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1267106564A; Thu, 21 Apr 2011 16:44:11 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95B528FC1B; Thu, 21 Apr 2011 16:44:11 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bc6b:a78d:dcd1:3a34]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id B23E24AC42; Thu, 21 Apr 2011 20:44:10 +0400 (MSD) Date: Thu, 21 Apr 2011 20:44:08 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <9723922.20110421204408@serebryakov.spb.ru> To: "J.R. Oldroyd" In-Reply-To: <20110421105356.51d881ca@shibato.opal.com> References: <969959848.20110421024515@serebryakov.spb.ru> <20110421105356.51d881ca@shibato.opal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:44:11 -0000 Hello, J.R.. You wrote 21 =E0=EF=F0=E5=EB=FF 2011 =E3., 18:53:56: > - changes to rtadvd to send the DNS info BTW, does this change allow to announce ``default'' DNS info (from /etc/resolv.conf) without rtadvd.conf file, as now rtadv announce ``default'' (interface's) prefixes without config. It is good feature, as it allow to have addresses only in on place for simple configs. And duplication of information (addresses in rc.conf and rtadvd.conf, DNSes in resolv.conf and rtadvd.conf) looks excessive. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 20:46:37 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736F1106566C; Thu, 21 Apr 2011 20:46:37 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D1B0E8FC15; Thu, 21 Apr 2011 20:46:36 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p3LKX4Ze091423; Thu, 21 Apr 2011 22:33:05 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p3LKX4qP091422; Thu, 21 Apr 2011 22:33:04 +0200 (CEST) (envelope-from marius) Date: Thu, 21 Apr 2011 22:33:04 +0200 From: Marius Strobl To: arch@freebsd.org, net@freebsd.org Message-ID: <20110421203304.GA91381@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC further mii(4) changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:46:37 -0000 Hi, with the addition of mii_attach() and fleshing out the generic flow control I've pretty much brought the FreeBSD mii(4) in line with NetBSD and OpenBSD as much as can be done without breaking the API or ABI, resulting in changes that could be MFC'ed. As you're probably aware however, especially NetBSD fixed and improved their mii(4) over time since it was initially ported to FreeBSD. I think now that stable/7 is basically closed as 7.4 was the last release based on it, 9.0 being right around the corner and probably also only 2-3 further releases being based on stable/8 I think now is actually a good time to incorporate that work and commit any other ABI/API-breaking changes to mii(4). I've prepared a patch which merges all relevant changes from NetBSD I'm ware of and implements some other stuff I had in mind: http://people.freebsd.org/~marius/mii_abi_breaking.diff A list of the anticipated changes is below. The most painful change likely is the fix for the OUI bit reversion problem, which on one hand once again allows us to mostly share miidevs with NetBSD but on the other hand won't allow us to MFC updates of this file verbatim to the existing stable branches in the future (IIRC at least imp@ also was in favor for fixing this bug at some point in time though). An earlier version of this patch was already reviewed by yongari@ (support for setting BMCR_LOOP/MIIF_NOLOOP was removed completely instead of extended and some entries in miidevs fixed, both based on his feedback). If there are no objections I'll commit these changes on April 30th. - Remove attempts to implement setting of BMCR_LOOP/MIIF_NOLOOP (reporting IFM_LOOP based on BMCR_LOOP is left in place though as it might provide useful for debugging). For most mii(4) drivers it was unclear whether the PHYs driven by them actually support loopback or not. Moreover, typically loopback mode also needs to be activated on the MAC, which none of the Ethernet drivers using mii(4) implements. Given that loopback media has no real use (and obviously hardly had a chance to actually work) besides for driver development (which just loopback mode should be sufficient for though, i.e one doesn't necessary need support for loopback media) support for it is just dropped as both NetBSD and OpenBSD already did quite some time ago. - Let mii_phy_add_media() also announce the support of IFM_NONE. - Restructure the PHY entry points to use a structure of entry points instead of discrete function pointers, and extend this to include a "reset" entry point. Make sure any PHY-specific reset routine is always used, and provide one for lxtphy(4) which disables MII interrupts (as is done for a few other PHYs we have drivers for). This includes changing NIC drivers which previously just called the generic mii_phy_reset() to now actually call the PHY-specific reset routine, which might be crucial in some cases. While at it, the redundant checks in these NIC drivers for mii->mii_instance not being zero before calling the reset routines were removed because as soon as one PHY driver attaches mii->mii_instance is incremented and we hardly can end up in their media change callbacks etc if no PHY driver has attached as mii_attach() would have failed in that case and not attach a miibus(4) instance. Consequently, NIC drivers now no longer should call mii_phy_reset() directly, so it was removed from EXPORT_SYMS. - Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe(). The purpose of that function is to perform the common steps to attach a PHY driver instance and to hook it up to the miibus(4) instance and to optionally also handle the probing, addition and initialization of the supported media. So all a PHY driver without any special requirements has to do in its bus attach method is to call mii_phy_dev_attach() along with PHY-specific MIIF_* flags, a pointer to its PHY functions and the add_media set to one. All PHY drivers were updated to take advantage of mii_phy_dev_attach() as appropriate. Along with these changes the capability mask was added to the mii_softc structure so PHY drivers taking advantage of mii_phy_dev_attach() but still handling media on their own do not need to fiddle with the MII attach arguments anyway. - Keep track of the PHY offset in the mii_softc structure. This is done for compatibility with NetBSD/OpenBSD. - Keep track of the PHY's OUI, model and revision in the mii_softc structure. Several PHY drivers require this information also after attaching and previously had to wrap their own softc around mii_softc. NetBSD/OpenBSD also keep track of the model and revision on their mii_softc structure. All PHY drivers were updated to take advantage as appropriate. - Convert the mebers of the MII data structure to unsigned where appropriate. This is partly inspired by NetBSD/OpenBSD. - According to IEEE 802.3-2002 the bits actually have to be reversed when mapping an OUI to the MII ID registers. All PHY drivers and miidevs where changed as necessary. Actually this now again allows to largely share miidevs with NetBSD, which fixed this problem already 9 years ago. Consequently miidevs was synced as far as possible. - Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that weren't explicitly converted to support flow control before. It's unclear whether flow control actually works with these but typically it should and their net behavior should be more correct with these changes in place than without if the MAC driver sets MIIF_DOPAUSE. Marius From owner-freebsd-net@FreeBSD.ORG Thu Apr 21 22:39:03 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C8841065742; Thu, 21 Apr 2011 22:39:03 +0000 (UTC) (envelope-from strizhov@netsec.colostate.edu) Received: from alpha.netsec.colostate.edu (alpha.netsec.colostate.edu [129.82.138.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA718FC17; Thu, 21 Apr 2011 22:39:03 +0000 (UTC) Received: from [10.84.44.150] (unknown [10.84.44.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alpha.netsec.colostate.edu (Postfix) with ESMTPSA id AEE50A81F9; Thu, 21 Apr 2011 16:21:23 -0600 (MDT) Message-ID: <4DB0ADB9.4080009@netsec.colostate.edu> Date: Thu, 21 Apr 2011 16:20:41 -0600 From: Mikhail Strizhov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: lev@freebsd.org References: <969959848.20110421024515@serebryakov.spb.ru> In-Reply-To: <969959848.20110421024515@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: stateless dhcp6 server for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:39:03 -0000 On 04/20/2011 04:45 PM, Lev Serebryakov wrote: > Hello, Freebsd-net. > > Is here any stateless dhcp6 solution for FreeBSD? > > isc-dhcp 4.1 seems to not support statless mode by server > > dibbler is not ported to FreeBSD. > > dhcp6s (WIDE-dhcpd) works only with one interface... It is possible, > of course, to run multiple instances of dhcp6s for multiple > interfaces, but it doesn't look very convenient. > > I need only distribute IPv6 DNS server addresses to clients, but not > prefixes or address information. > /usr/ports/net/radvd ? -- Sincerely, Mikhail Strizhov Web: http://www.netsec.colostate.edu/~strizhov Email: strizhov@netsec.colostate.edu From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 10:07:16 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2004106566B; Fri, 22 Apr 2011 10:07:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 42E518FC13; Fri, 22 Apr 2011 10:07:16 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CCBEE25D37C7; Fri, 22 Apr 2011 10:07:14 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1568D159D780; Fri, 22 Apr 2011 10:07:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id NbidSIneQdIr; Fri, 22 Apr 2011 10:07:13 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C8AEF159D770; Fri, 22 Apr 2011 10:07:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110421203304.GA91381@alchemy.franken.de> Date: Fri, 22 Apr 2011 10:07:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110421203304.GA91381@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: arch@freebsd.org, net@freebsd.org Subject: Re: RFC further mii(4) changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 10:07:16 -0000 On Apr 21, 2011, at 8:33 PM, Marius Strobl wrote: Hi, I fear the change is too big for me to review currently. One thing I am still pondering is whether we would be able to reserve = enough spares (wherever needed) to be able to eventually allow to = query-through and gather a lot more information than we currently expose = via ifconfig. It would be really great to be able to ask for all the = bits. Not sure how linux for example handles that for mii-tool/ethtool = or how those things work, but .. well you get it. I should not forget to mention that I think what you are trying to do in = harmonizing things currently is excellent progress! Bjoern --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 12:09:11 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84228106564A; Fri, 22 Apr 2011 12:09:11 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D484B8FC19; Fri, 22 Apr 2011 12:09:10 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p3MC99j8002405; Fri, 22 Apr 2011 14:09:09 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p3MC99xW002404; Fri, 22 Apr 2011 14:09:09 +0200 (CEST) (envelope-from marius) Date: Fri, 22 Apr 2011 14:09:09 +0200 From: Marius Strobl To: "Bjoern A. Zeeb" Message-ID: <20110422120909.GO38455@alchemy.franken.de> References: <20110421203304.GA91381@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, net@freebsd.org Subject: Re: RFC further mii(4) changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:09:11 -0000 On Fri, Apr 22, 2011 at 10:07:11AM +0000, Bjoern A. Zeeb wrote: > On Apr 21, 2011, at 8:33 PM, Marius Strobl wrote: > > Hi, Hi > > I fear the change is too big for me to review currently. Given that the majority of changes break backwards compatibility in some way I intend to comitting them in one pass rather than splitting them up, which unfortunately results in a rather large patch ... > > One thing I am still pondering is whether we would be able to reserve enough spares (wherever needed) to be able to eventually allow to query-through and gather a lot more information than we currently expose via ifconfig. It would be really great to be able to ask for all the bits. Not sure how linux for example handles that for mii-tool/ethtool or how those things work, but .. well you get it. > Providing functionality akin mii-tool/ethtool is also something I'd like to see. Unfortunately, I currently lack the time to work on that, maybe next year as a GSoC or some such, in case someone is willing to mentor this time :) However, I think when going a route similar to pci(4)/pciconf(8) (without repeating their mistakes) it should be possible to implement that without breaking the ABI. Marius From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 14:22:22 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8230A106566C; Fri, 22 Apr 2011 14:22:22 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7E48FC0C; Fri, 22 Apr 2011 14:22:22 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 07:10:21 -0700 From: Ben Hutchings To: Marius Strobl In-Reply-To: <20110422120909.GO38455@alchemy.franken.de> References: <20110421203304.GA91381@alchemy.franken.de> <20110422120909.GO38455@alchemy.franken.de> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Date: Fri, 22 Apr 2011 15:10:14 +0100 Message-ID: <1303481415.4129.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2011 14:10:21.0905 (UTC) FILETIME=[047BDC10:01CC00F7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18088.005 X-TM-AS-Result: No--20.306500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Bjoern A. Zeeb" , net@freebsd.org, arch@freebsd.org Subject: Re: RFC further mii(4) changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:22:22 -0000 On Fri, 2011-04-22 at 14:09 +0200, Marius Strobl wrote: > On Fri, Apr 22, 2011 at 10:07:11AM +0000, Bjoern A. Zeeb wrote: [...] > > One thing I am still pondering is whether we would be able to reserve enough spares (wherever needed) to be able to eventually allow to query-through and gather a lot more information than we currently expose via ifconfig. It would be really great to be able to ask for all the bits. Not sure how linux for example handles that for mii-tool/ethtool or how those things work, but .. well you get it. > > > > Providing functionality akin mii-tool/ethtool is also something I'd > like to see. Unfortunately, I currently lack the time to work on that, > maybe next year as a GSoC or some such, in case someone is willing to > mentor this time :) However, I think when going a route similar to > pci(4)/pciconf(8) (without repeating their mistakes) it should be > possible to implement that without breaking the ABI. mii-tool uses the MDIO ioctls, wherease ethtool uses the relatively high-level ethtool API. Note that mii-tool itself is unmaintained and needs some unofficial patches to support even 1G PHYs. The MDIO ioctls all use struct ifreq with an instance of struct mii_ioctl_data in the ifr_ifru field. See and . SIOCGMIIPHY: Set the phy_id field to the address of the PHY that the net device is using. (It is not specified what to do if the device is not using an MDIO-manageable PHY.) SIOCGMIIREG: Read the register at the address specified by phy_id and reg_num. Set val_out to the register value. SIOCSMIIREG: Write the register at the addres specified by phy_id and reg_num, with the value from val_in. For clause 45 MDIO (as used by 10G and some other PHYs), the phy_id for SIOC{G,S}MIIREG (but not SIOCGMIIPHY) provides both PRT and DEV addresses, as specified in . Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 14:42:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD39106575F for ; Fri, 22 Apr 2011 14:42:48 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9EABE8FC15 for ; Fri, 22 Apr 2011 14:42:48 +0000 (UTC) Received: by vws18 with SMTP id 18so671441vws.13 for ; Fri, 22 Apr 2011 07:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RgTBU5ATUX/IqwqGFupO2HFypiMdsVyCrDR+S1BWV0o=; b=q4wrXF+mELvQh0ZtqdL3X7+kTLWHRNLgSxe9Zla9YR2heJs7JCEHPwuOapaeIr9yOR Gq5wsO+wvGWkhmg6tXJGkBZXk5t3tlSyVoOJCDBch0KgnkbrWPzcOT4y4URIveuIZZoB +SoeLgSUsuiky4u6UkaTZx9+DPtCAm4nGq3Io= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lP9wgVlvEkiQwyt44MUPybX02TQJmqllvVWnNbFM83rCDUHxOe/hfRQ2KcqTHJIg7r s0o11qC192u4KhRRJR2z6mWy/p1dO9q17fPLjo9EjMbqmxGGFFYS6ZkkJkFsEwv3/w+8 48BUeOiCNrPNb/+ZLfDFbooyoc5nWZMvi/JZA= MIME-Version: 1.0 Received: by 10.52.107.195 with SMTP id he3mr1774961vdb.12.1303483367741; Fri, 22 Apr 2011 07:42:47 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.167.105 with HTTP; Fri, 22 Apr 2011 07:42:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 16:42:47 +0200 X-Google-Sender-Auth: psjWPiZ70PB-KXAlwKPjPKI3o5E Message-ID: From: "K. Macy" To: cyberGn0m Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:42:50 -0000 I've had the same problem on my Shuttle box on both Linux and FreeBSD. I work around it by disabling auto-negotiation and forcing it to 100Mbit. On Thu, Apr 21, 2011 at 10:45 AM, cyberGn0m wrote: > Hi all > > Some other investigations done and I found the following: device still > receives data but due to unknown (for me) reason data can't be processed and > when msk_handle_events called event ring does not contains OP_RXSTAT events. > And after a while RX overrun happens. I tried to change some code but with > no success. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 14:58:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CE41065672 for ; Fri, 22 Apr 2011 14:58:44 +0000 (UTC) (envelope-from cy6ergn0m@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF0688FC0C for ; Fri, 22 Apr 2011 14:58:44 +0000 (UTC) Received: by iwn33 with SMTP id 33so735599iwn.13 for ; Fri, 22 Apr 2011 07:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Myhb6+JcqrJSG6Y+JOvJwyel/EJ3ZpNGa5hEq6OU0iA=; b=rxxaBBeddYn/drHRJ/yk6rNTm1so0pjo/JmlXOBRyOeGa8/DTPe78fQHDg+qrDMBO3 cdrKY33MM99rIgWb5ieK2ZKHVAewQDyR4xGT8xoGd3yQK+IhWYVUCLvzBrulbAeCRsPX YWPJ/skLHTC3DyFNP/y+rH8O6CiE/SOw/zp30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O8GY5r8c2rjEn4L/ncY72shKk2xqVZFlYycF/n60Md0ephCpKh2lOFreCcyuMPxxId vx0zd3D/GP0mnkBqg63ILo2dk2iae/2J30prfGCFZCenaMiyHKh+kUVsYPiIueW63ph5 hebYhQkFxuPxk08hTTDsBQr+FImPUFYCj0n/k= MIME-Version: 1.0 Received: by 10.42.224.198 with SMTP id ip6mr1291857icb.407.1303484323823; Fri, 22 Apr 2011 07:58:43 -0700 (PDT) Received: by 10.231.208.12 with HTTP; Fri, 22 Apr 2011 07:58:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 18:58:43 +0400 Message-ID: From: cyberGn0m To: "K. Macy" X-Mailman-Approved-At: Fri, 22 Apr 2011 15:17:39 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:58:45 -0000 At Linux I have no problems with this device. How to disable negotiation? 2011/4/22 K. Macy > I've had the same problem on my Shuttle box on both Linux and FreeBSD. > I work around it by disabling auto-negotiation and forcing it to > 100Mbit. > > On Thu, Apr 21, 2011 at 10:45 AM, cyberGn0m wrote: > > Hi all > > > > Some other investigations done and I found the following: device still > > receives data but due to unknown (for me) reason data can't be processe= d > and > > when msk_handle_events called event ring does not contains OP_RXSTAT > events. > > And after a while RX overrun happens. I tried to change some code but > with > > no success. > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > --=20 ----------------------------------------------------------------- =D0=92=D1=81=D0=B5=D0=B3=D0=BE =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88= =D0=B5=D0=B3=D0=BE Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 469D7106564A for ; Fri, 22 Apr 2011 15:22:34 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E94A28FC0A for ; Fri, 22 Apr 2011 15:22:33 +0000 (UTC) Received: by vws18 with SMTP id 18so703957vws.13 for ; Fri, 22 Apr 2011 08:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pNoV3NUns+pWc0sUe7m2Yfz7iozR0xSafzx0vtNWohg=; b=F1zmgYqXddhZZaLzhtWoy94VlwMdDNK/njrwthWQG9pac6pEj9LyQMKLc0JjNdh5k3 Ok66qnhOWz1fIwC3EXQultd8Qu6cdkFmLoxF/VI0B3xyv7S77BkzxOr2hUIQYKWKKb7Q YcOuJhY2PfCHy/ou+P5FT2lztcA6eOWYS2N/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ELY8IYsvSQFzSXQu11B4rM0cMmtgd7ItCOpLKLqeDMBaBLsYrfLVGmuZJRtBtXJJ/f T4iUjnrwcuWG9uCC9lPUqiA3OVS6psG9IT5pp/+coFLdoIA8afnflqfZiG9JHfitBB2/ 60s3g3xzJsFwAQg+9vv3PH12W4W1MfBt2uvL4= MIME-Version: 1.0 Received: by 10.52.90.73 with SMTP id bu9mr1770998vdb.92.1303485751897; Fri, 22 Apr 2011 08:22:31 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.167.105 with HTTP; Fri, 22 Apr 2011 08:22:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 17:22:31 +0200 X-Google-Sender-Auth: xmiv7AudjGla_i-kFeyhv2V9rHo Message-ID: From: "K. Macy" To: cyberGn0m Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 15:22:34 -0000 On Fri, Apr 22, 2011 at 4:58 PM, cyberGn0m wrote: > At Linux I have no problems with this device. How to disable negotiation? I don't think disabling checksums and tso are necessary, but they don't really matter at 100Mbps. # This file now contains just the overrides from /etc/defaults/rc.conf. sshd_enable=3D"YES" ifconfig_msk0=3D"media 100TX -txcsum -rxcsum -tso" ifconfig_msk1=3D"media 100TX -txcsum -rxcsum -tso" moused_enable=3D"YES" hald_enable=3D"YES" dbus_enable=3D"YES" hostname=3D"shuttle1.burblefest.com" #ifconfig_msk1=3D"inet 10.0.1.8 netmask 0xffffff00" #defaultrouter=3D"10.0.1.1" I've been setting the IP later on in boot. > > 2011/4/22 K. Macy > >> I've had the same problem on my Shuttle box on both Linux and FreeBSD. >> I work around it by disabling auto-negotiation and forcing it to >> 100Mbit. >> >> On Thu, Apr 21, 2011 at 10:45 AM, cyberGn0m wrote: >> > Hi all >> > >> > Some other investigations done and I found the following: device still >> > receives data but due to unknown (for me) reason data can't be process= ed >> and >> > when msk_handle_events called event ring does not contains OP_RXSTAT >> events. >> > And after a while RX overrun happens. I tried to change some code but >> with >> > no success. >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > >> > > > > -- > ----------------------------------------------------------------- > =F7=D3=C5=C7=CF =CE=C1=C9=CC=D5=DE=DB=C5=C7=CF > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 16:26:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17FCB1065670 for ; Fri, 22 Apr 2011 16:26:37 +0000 (UTC) (envelope-from prvs=10936998ff=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE128FC08 for ; Fri, 22 Apr 2011 16:26:37 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 22 Apr 2011 17:15:37 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 22 Apr 2011 17:15:36 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([217.41.255.142]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013012947.msg for ; Fri, 22 Apr 2011 17:15:35 +0100 X-MDRemoteIP: 217.41.255.142 X-Return-Path: prvs=10936998ff=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <521514204B99427691043FF127B6E841@multiplay.co.uk> From: "Steven Hartland" To: , "Vogel, Jack" References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> Date: Fri, 22 Apr 2011 17:15:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:26:38 -0000 Hi Jack do you have any idea what's going on here as it very disruptive for every IP change to cause total outage on the machine? ----- Original Message ----- From: "Steven Hartland" To: Sent: Wednesday, April 20, 2011 2:37 PM Subject: Intel ix (X520) disconnects when manipulating ips? > Seems there's an issue with the intel ix driver which causes > it to bin connections when you manipulate ip aliases. > > This causes issues on boot when jails start as it bins other > active sessions. > > Is this a know issue? > > Running 8.2-RELEASE amd64 here. > > Regards > Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 16:45:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 255D6106566C for ; Fri, 22 Apr 2011 16:45:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id D16CA8FC0A for ; Fri, 22 Apr 2011 16:45:58 +0000 (UTC) Received: by gxk28 with SMTP id 28so245306gxk.13 for ; Fri, 22 Apr 2011 09:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3hhmAkP4hUoqBhJ7jZTHQNuWn6FdQaAvhn+4SoxG/BY=; b=jgB8q1sh16cNofdsQKsOlxgXmMenEo/eA5UMRL5H+Lae1ITkivnDB1L4CUV+7vk96O KmNfbAzDkg9fTOxq/Sh37Vpw74xYx+LVxQLSbHL1UnWuUJKVERiLJQ26cAFeCt8fALGA 9EzQ+otnW9fzGrw820h1kgMylx3sgQwIGzDaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fh3dg1l7Hu4ayiYY1bxBbaXIF4PbPp2L27ZdRSe9HP1XGhGFwAON52T47jc1pJ61uc zJ6vKmSnNuh66zhsVxCX/stJ61p4zGtCjZ+MdXZse8frxGit0q82IjwxGwKOSgEwJgTU z1uvGsW0tTguXsuth2tLYcXZJ7Yo74+LlyV/M= MIME-Version: 1.0 Received: by 10.150.74.2 with SMTP id w2mr1029329yba.335.1303490756858; Fri, 22 Apr 2011 09:45:56 -0700 (PDT) Received: by 10.150.49.14 with HTTP; Fri, 22 Apr 2011 09:45:56 -0700 (PDT) In-Reply-To: <521514204B99427691043FF127B6E841@multiplay.co.uk> References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> <521514204B99427691043FF127B6E841@multiplay.co.uk> Date: Fri, 22 Apr 2011 09:45:56 -0700 Message-ID: From: Jack Vogel To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:45:59 -0000 Please give me the exact steps that are performed that create this, not sure what you mean by "manipulate ip aliases", if you mean ifconfig ix0 address, then this has always caused a reinit of the device, the same behavior is in the 1G devices. Or do you mean something else? Oh, and while at it, pciconf -lv Jack On Fri, Apr 22, 2011 at 9:15 AM, Steven Hartland wrote: > Hi Jack do you have any idea what's going on here as it very disruptive > for every IP change to cause total outage on the machine? > > ----- Original Message ----- From: "Steven Hartland" < > killing@multiplay.co.uk> > To: > Sent: Wednesday, April 20, 2011 2:37 PM > Subject: Intel ix (X520) disconnects when manipulating ips? > > > Seems there's an issue with the intel ix driver which causes >> it to bin connections when you manipulate ip aliases. >> >> This causes issues on boot when jails start as it bins other >> active sessions. >> >> Is this a know issue? >> >> Running 8.2-RELEASE amd64 here. >> >> Regards >> Steve >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 17:11:43 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C563106566C for ; Fri, 22 Apr 2011 17:11:43 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 319E28FC08 for ; Fri, 22 Apr 2011 17:11:42 +0000 (UTC) Received: by ewy1 with SMTP id 1so281040ewy.13 for ; Fri, 22 Apr 2011 10:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FsG/drcCTcDvlhMwDDTjzhBnRAiPTdFGAraK4SpVW9A=; b=vgd0jAWxK0CgggifhsaY2SJregZllR8oI6D5TxzkM0C3tXJJUuQF1p4ZXkmnLuFhqQ jBaK42GoMBWAUgUFm73KJaJSme1JXVfz4enAyA1RTEMtyjuB6OwL3YGn3vTTDU9eXiuw XmtsoyYQ3SQ/BaynXcKLwfHasNI3xj1wEYJDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mb8hOQtfOs95OvFpxXsR75Lya6bnel53GB6ZoB/RfFaZGt61XD7qFi2gI0ICW/xwl/ HWF3M18ify3Qgeyy7NiHY/w8v2MYk+/3sJlx6sig8o5zX33rOho2HkmxqVynalKU9dod Dj4bUA+lf/1SnS1FpCvYqHqLASBnztffzIqXA= MIME-Version: 1.0 Received: by 10.213.20.218 with SMTP id g26mr772455ebb.133.1303490607243; Fri, 22 Apr 2011 09:43:27 -0700 (PDT) Received: by 10.213.4.209 with HTTP; Fri, 22 Apr 2011 09:43:27 -0700 (PDT) In-Reply-To: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> Date: Fri, 22 Apr 2011 12:43:27 -0400 Message-ID: From: Ryan Stone To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:11:43 -0000 On Wed, Apr 20, 2011 at 9:37 AM, Steven Hartland wrote: > Seems there's an issue with the intel ix driver which causes > it to bin connections when you manipulate ip aliases. > > This causes issues on boot when jails start as it bins other > active sessions. > > Is this a know issue? > > Running 8.2-RELEASE amd64 here. > > =A0 Regards > =A0 Steve If this is going to be solved you need to provide a lot more detail than this. What are the exact symptoms that you are experiencing? Why have you concluded that the ixgbe driver is the cause? Can you provide a reproducible testcase that demonstrates the problem? From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 19:39:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D299106564A; Fri, 22 Apr 2011 19:39:02 +0000 (UTC) (envelope-from cy6ergn0m@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1291F8FC0A; Fri, 22 Apr 2011 19:39:01 +0000 (UTC) Received: by iyj12 with SMTP id 12so956215iyj.13 for ; Fri, 22 Apr 2011 12:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tcIuHKefWLQi8V3rcdNUCPqxx5Rqa/r2qHxTjUTuTjc=; b=ZDgt2gAZC1qCza/s3Dd3zTDFuw3H1yC5rNZWYZaYXo5eKoM5Jf+CQ5QYIwzw36O9Hv bcpMougfaHZ25q76x7WyjnSrc4xVoQrWMKiaTy2pahov+Z3fba96BAjbqiSjYK05NTXR xboXST6udM9B34F502/7f1IJTEHPKHs0Q3dx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WSQb6wvdalx5qsuQS99WoG3x3ghRTRTl4YN2u2uniY9/+5CsaneCYWxygStk9KzWjt NuBHH7YzbHz1Y5MQ98oYpHrIDBJQNgAtJcQ05Wq4hbT0+3MyypSovQoc/mWCq2Yk8Vib MSnwJ2rh+P74gqWisfWbY3RDO9df/mLz79fvM= MIME-Version: 1.0 Received: by 10.231.123.1 with SMTP id n1mr1103442ibr.67.1303501140340; Fri, 22 Apr 2011 12:39:00 -0700 (PDT) Received: by 10.231.208.12 with HTTP; Fri, 22 Apr 2011 12:39:00 -0700 (PDT) Received: by 10.231.208.12 with HTTP; Fri, 22 Apr 2011 12:39:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 16:39:00 -0300 Message-ID: From: cyberGn0m To: "K. Macy" X-Mailman-Approved-At: Fri, 22 Apr 2011 20:14:30 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 19:39:02 -0000 It looks like it helped me too. It's great. How did you found that workaround? Do you have ideas why negotiations breaks connection? - CG 22.04.2011 19:22 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "K. Macy" =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0=D0=BB: On Fri, Apr 22, 2011 at 4:58 PM, cyberGn0m wrote: > At Linux I have no problem... I don't think disabling checksums and tso are necessary, but they don't really matter at 100Mbps. # This file now contains just the overrides from /etc/defaults/rc.conf. sshd_enable=3D"YES" ifconfig_msk0=3D"media 100TX -txcsum -rxcsum -tso" ifconfig_msk1=3D"media 100TX -txcsum -rxcsum -tso" moused_enable=3D"YES" hald_enable=3D"YES" dbus_enable=3D"YES" hostname=3D"shuttle1.burblefest.com" #ifconfig_msk1=3D"inet 10.0.1.8 netmask 0xffffff00" #defaultrouter=3D"10.0.1.1" I've been setting the IP later on in boot. > > 2011/4/22 K. Macy > >> I've had the same problem on my Shuttle box on both ... From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 22:08:28 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4FF106566B for ; Fri, 22 Apr 2011 22:08:28 +0000 (UTC) (envelope-from prvs=10936998ff=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 76DC48FC19 for ; Fri, 22 Apr 2011 22:08:27 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 22 Apr 2011 23:08:03 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 22 Apr 2011 23:08:02 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([217.41.255.142]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013016224.msg for ; Fri, 22 Apr 2011 23:08:02 +0100 X-MDRemoteIP: 217.41.255.142 X-Return-Path: prvs=10936998ff=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Jack Vogel" References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk><521514204B99427691043FF127B6E841@multiplay.co.uk> Date: Fri, 22 Apr 2011 23:08:22 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 22:08:28 -0000 Sorry yes I did meant just add an ip alias to the nic or remove it e.g. ifconfig ix0 10.10.1.10/32 alias ifconfig ix0 10.10.1.10 -alias pciconf -lv hostb0@pci0:0:0:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40038086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400B Chipset Memory Controller Hub' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40218086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 1' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:3:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40238086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 3' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:5:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40258086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 5' class =3D bridge subclass =3D PCI-PCI pcib6@pci0:0:7:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40278086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 7' class =3D bridge subclass =3D PCI-PCI pcib10@pci0:0:9:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40298086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 9' class =3D bridge subclass =3D PCI-PCI none0@pci0:0:15:0: class=3D0x088000 card=3D0xa28015d9 chip=3D0x402f8086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset DMA/DCA Engine' class =3D base peripheral hostb1@pci0:0:16:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:16:1: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:16:2: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:0:16:3: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:0:16:4: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:0:17:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40318086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Coherency Engine, Data Manager and Snoop Filter.' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:0:21:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40358086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 0' class =3D bridge subclass =3D HOST-PCI hostb8@pci0:0:21:1: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40358086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 0' class =3D bridge subclass =3D HOST-PCI hostb9@pci0:0:22:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40368086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 1' class =3D bridge subclass =3D HOST-PCI hostb10@pci0:0:22:1: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40368086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 1' class =3D bridge subclass =3D HOST-PCI pcib11@pci0:0:28:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x26908086 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 PCIe Root Port 1' class =3D bridge subclass =3D PCI-PCI uhci0@pci0:0:29:0: class=3D0x0c0300 card=3D0xa28015d9 chip=3D0x26888086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB Universal Host Controller *1' class =3D serial bus subclass =3D USB uhci1@pci0:0:29:1: class=3D0x0c0300 card=3D0xa28015d9 chip=3D0x26898086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB Universal Host Controller *2' class =3D serial bus subclass =3D USB uhci2@pci0:0:29:2: class=3D0x0c0300 card=3D0xa28015d9 chip=3D0x268a8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB Universal Host Controller *3' class =3D serial bus subclass =3D USB ehci0@pci0:0:29:7: class=3D0x0c0320 card=3D0xa28015d9 chip=3D0x268c8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB2 Enhanced Host Controller' class =3D serial bus subclass =3D USB pcib12@pci0:0:30:0: class=3D0x060401 card=3D0xa28015d9 chip=3D0x244e8086 rev=3D0xd9 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0xa28015d9 chip=3D0x26708086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'LPC Interface Controller (631xESB/6321ESB/3100 )' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:31:1: class=3D0x01018a card=3D0xa28015d9 chip=3D0x269e8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Ultra ATA Storage Controller' class =3D mass storage subclass =3D ATA none1@pci0:0:31:3: class=3D0x0c0500 card=3D0xa28015d9 chip=3D0x269b8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'SMBus Controller (631xESB/6321ESB/3100)' class =3D serial bus subclass =3D SMBus pcib2@pci0:1:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x03708086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Segment-A PCI Express-to-PCI Express Bridge (80333)' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:1:0:2: class=3D0x060400 card=3D0x00000000 chip=3D0x03728086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Segment-B PCI Express-to-PCI Express Bridge (80333)' class =3D bridge subclass =3D PCI-PCI arcmsr0@pci0:2:14:0: class=3D0x010400 card=3D0x122017d3 chip=3D0x122017d3 rev=3D0x00 hdr=3D0x00 vendor =3D 'Areca Technology Corporation' device =3D 'ARC-1220 8-Port PCIe to SATA RAID Controller' class =3D mass storage subclass =3D RAID ix0@pci0:5:0:0: class=3D0x020000 card=3D0x00068086 chip=3D0x10fb8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet pcib7@pci0:6:0:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x35008086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB PCIe Upstream Port' class =3D bridge subclass =3D PCI-PCI pcib9@pci0:6:0:3: class=3D0x060400 card=3D0xa28015d9 chip=3D0x350c8086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB PCIe to PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI pcib8@pci0:7:0:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x35108086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB PCIe Downstream Port E1' class =3D bridge subclass =3D PCI-PCI igb0@pci0:10:0:0: class=3D0x020000 card=3D0x10a715d9 chip=3D0x10a78086 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82575EB Gigabit Network Connection' class =3D network subclass =3D ethernet igb1@pci0:10:0:1: class=3D0x020000 card=3D0x10a715d9 chip=3D0x10a78086 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82575EB Gigabit Network Connection' class =3D network subclass =3D ethernet vgapci0@pci0:12:1:0: class=3D0x030000 card=3D0xa28015d9 chip=3D0x515e1002 rev=3D0x02 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device =3D 'Radeon ES1000 (Radeon ES1000)' class =3D display subclass =3D VGA ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: freebsd-net@freebsd.org ; Vogel, Jack=20 Sent: Friday, April 22, 2011 5:45 PM Subject: Re: Intel ix (X520) disconnects when manipulating ips? Please give me the exact steps that are performed that create this, not sure what you mean by "manipulate ip aliases", if you mean ifconfig ix0 address, then this has always caused a reinit of the device, the same behavior is in the 1G devices. Or do you mean something else? Oh, and while at it, pciconf -lv Jack On Fri, Apr 22, 2011 at 9:15 AM, Steven Hartland wrote: Hi Jack do you have any idea what's going on here as it very disruptive for every IP change to cause total outage on the machine? ----- Original Message ----- From: "Steven Hartland" To: Sent: Wednesday, April 20, 2011 2:37 PM Subject: Intel ix (X520) disconnects when manipulating ips? Seems there's an issue with the intel ix driver which causes it to bin connections when you manipulate ip aliases. This causes issues on boot when jails start as it bins other active sessions. Is this a know issue? Running 8.2-RELEASE amd64 here. Regards Steve =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 22:13:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0496B106566C for ; Fri, 22 Apr 2011 22:13:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 948BF8FC08 for ; Fri, 22 Apr 2011 22:13:34 +0000 (UTC) Received: by vxc34 with SMTP id 34so991478vxc.13 for ; Fri, 22 Apr 2011 15:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zAJs1NCUuFFY2qhd+9JloUIVVAOK5EI9a68EcvMxMss=; b=xXbbcs3XlWCrouwsMCABMdelTeUX+zfLMhkt1Z3+T++BmETVVE4Fda0CVIRTYbTJ1J gy41KrUDxdV21gbKP3Nnz+/xyWZonaP18ewp/VQ4gvJAjo5WvopV1Zy21hziBsvtH6vT iiSFnqMTsAzztaobJgsBfEnaZh2Zd7xZhubx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=THTlRYe0tcTEwgoRSK1Kb/Ydq4I4xQaqken7LMHElFW1h6I+e5BrkvAQcWFV15d0mR 774MGm0Cia36lQevUi111VJuKuxgIBDk9Saogvh4AcOmXAZ9cFYmIdjWbjeg/97+NAjA mAtNbVT4ElnqHfB9N5gTm9b2Sv+WfRMIHE6Aw= MIME-Version: 1.0 Received: by 10.52.187.202 with SMTP id fu10mr2422169vdc.127.1303510413749; Fri, 22 Apr 2011 15:13:33 -0700 (PDT) Received: by 10.52.167.67 with HTTP; Fri, 22 Apr 2011 15:13:33 -0700 (PDT) In-Reply-To: References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> <521514204B99427691043FF127B6E841@multiplay.co.uk> Date: Fri, 22 Apr 2011 15:13:33 -0700 Message-ID: From: Jack Vogel To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 22:13:35 -0000 I see you have igb devices, if you do this with those interfaces is the behavior different? I will have to look into this, thanks for the report. Jack On Fri, Apr 22, 2011 at 3:08 PM, Steven Hartland wrote: > Sorry yes I did meant just add an ip alias to the nic or remove it > e.g. > ifconfig ix0 10.10.1.10/32 alias > ifconfig ix0 10.10.1.10 -alias > > pciconf -lv > hostb0@pci0:0:0:0: class=0x060000 card=0xa28015d9 chip=0x40038086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400B Chipset Memory Controller Hub' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0xa28015d9 chip=0x40218086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '5400 Series Chipset PCIe Port 1' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:3:0: class=0x060400 card=0xa28015d9 chip=0x40238086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '5400 Series Chipset PCIe Port 3' > class = bridge > subclass = PCI-PCI > pcib5@pci0:0:5:0: class=0x060400 card=0xa28015d9 chip=0x40258086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '5400 Series Chipset PCIe Port 5' > class = bridge > subclass = PCI-PCI > pcib6@pci0:0:7:0: class=0x060400 card=0xa28015d9 chip=0x40278086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '5400 Series Chipset PCIe Port 7' > class = bridge > subclass = PCI-PCI > pcib10@pci0:0:9:0: class=0x060400 card=0xa28015d9 chip=0x40298086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '5400 Series Chipset PCIe Port 9' > class = bridge > subclass = PCI-PCI > none0@pci0:0:15:0: class=0x088000 card=0xa28015d9 chip=0x402f8086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset DMA/DCA Engine' > class = base peripheral > hostb1@pci0:0:16:0: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset FSB Registers' > class = bridge > subclass = HOST-PCI > hostb2@pci0:0:16:1: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset FSB Registers' > class = bridge > subclass = HOST-PCI > hostb3@pci0:0:16:2: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset FSB Registers' > class = bridge > subclass = HOST-PCI > hostb4@pci0:0:16:3: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset FSB Registers' > class = bridge > subclass = HOST-PCI > hostb5@pci0:0:16:4: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset FSB Registers' > class = bridge > subclass = HOST-PCI > hostb6@pci0:0:17:0: class=0x060000 card=0xa28015d9 chip=0x40318086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset Coherency Engine, Data Manager and > Snoop Filter.' > class = bridge > subclass = HOST-PCI > hostb7@pci0:0:21:0: class=0x060000 card=0xa28015d9 chip=0x40358086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset Channel Control for FB-DIMM Branch 0' > class = bridge > subclass = HOST-PCI > hostb8@pci0:0:21:1: class=0x060000 card=0xa28015d9 chip=0x40358086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset Channel Control for FB-DIMM Branch 0' > class = bridge > subclass = HOST-PCI > hostb9@pci0:0:22:0: class=0x060000 card=0xa28015d9 chip=0x40368086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset Channel Control for FB-DIMM Branch 1' > class = bridge > subclass = HOST-PCI > hostb10@pci0:0:22:1: class=0x060000 card=0xa28015d9 chip=0x40368086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '5400 Series Chipset Channel Control for FB-DIMM Branch 1' > class = bridge > subclass = HOST-PCI > pcib11@pci0:0:28:0: class=0x060400 card=0xa28015d9 chip=0x26908086 > rev=0x09 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 PCIe Root Port 1' > class = bridge > subclass = PCI-PCI > uhci0@pci0:0:29:0: class=0x0c0300 card=0xa28015d9 chip=0x26888086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB Universal Host > Controller *1' > class = serial bus > subclass = USB > uhci1@pci0:0:29:1: class=0x0c0300 card=0xa28015d9 chip=0x26898086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB Universal Host > Controller *2' > class = serial bus > subclass = USB > uhci2@pci0:0:29:2: class=0x0c0300 card=0xa28015d9 chip=0x268a8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB Universal Host > Controller *3' > class = serial bus > subclass = USB > ehci0@pci0:0:29:7: class=0x0c0320 card=0xa28015d9 chip=0x268c8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB2 Enhanced Host > Controller' > class = serial bus > subclass = USB > pcib12@pci0:0:30:0: class=0x060401 card=0xa28015d9 chip=0x244e8086 > rev=0xd9 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface > to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0xa28015d9 chip=0x26708086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'LPC Interface Controller (631xESB/6321ESB/3100 )' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:31:1: class=0x01018a card=0xa28015d9 chip=0x269e8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Ultra ATA Storage Controller' > class = mass storage > subclass = ATA > none1@pci0:0:31:3: class=0x0c0500 card=0xa28015d9 chip=0x269b8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'SMBus Controller (631xESB/6321ESB/3100)' > class = serial bus > subclass = SMBus > pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x03708086 > rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > device = 'Segment-A PCI Express-to-PCI Express Bridge (80333)' > class = bridge > subclass = PCI-PCI > pcib3@pci0:1:0:2: class=0x060400 card=0x00000000 chip=0x03728086 > rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > device = 'Segment-B PCI Express-to-PCI Express Bridge (80333)' > class = bridge > subclass = PCI-PCI > arcmsr0@pci0:2:14:0: class=0x010400 card=0x122017d3 chip=0x122017d3 > rev=0x00 hdr=0x00 > vendor = 'Areca Technology Corporation' > device = 'ARC-1220 8-Port PCIe to SATA RAID Controller' > class = mass storage > subclass = RAID > ix0@pci0:5:0:0: class=0x020000 card=0x00068086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > pcib7@pci0:6:0:0: class=0x060400 card=0xa28015d9 chip=0x35008086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB PCIe Upstream Port' > class = bridge > subclass = PCI-PCI > pcib9@pci0:6:0:3: class=0x060400 card=0xa28015d9 chip=0x350c8086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB PCIe to PCI-X Bridge' > class = bridge > subclass = PCI-PCI > pcib8@pci0:7:0:0: class=0x060400 card=0xa28015d9 chip=0x35108086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB PCIe Downstream Port E1' > class = bridge > subclass = PCI-PCI > igb0@pci0:10:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82575EB Gigabit Network Connection' > class = network > subclass = ethernet > igb1@pci0:10:0:1: class=0x020000 card=0x10a715d9 chip=0x10a78086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82575EB Gigabit Network Connection' > class = network > subclass = ethernet > vgapci0@pci0:12:1:0: class=0x030000 card=0xa28015d9 chip=0x515e1002 > rev=0x02 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'Radeon ES1000 (Radeon ES1000)' > class = display > subclass = VGA > > ----- Original Message ----- > *From:* Jack Vogel > *To:* Steven Hartland > *Cc:* freebsd-net@freebsd.org ; Vogel, Jack > *Sent:* Friday, April 22, 2011 5:45 PM > *Subject:* Re: Intel ix (X520) disconnects when manipulating ips? > > Please give me the exact steps that are performed that create this, not > sure what you mean by "manipulate ip aliases", if you mean ifconfig ix0 > address, > then this has always caused a reinit of the device, the same behavior is in > the > 1G devices. Or do you mean something else? > > Oh, and while at it, pciconf -lv > > Jack > > > On Fri, Apr 22, 2011 at 9:15 AM, Steven Hartland wrote: > >> Hi Jack do you have any idea what's going on here as it very disruptive >> for every IP change to cause total outage on the machine? >> >> ----- Original Message ----- From: "Steven Hartland" < >> killing@multiplay.co.uk> >> To: >> Sent: Wednesday, April 20, 2011 2:37 PM >> Subject: Intel ix (X520) disconnects when manipulating ips? >> >> >> Seems there's an issue with the intel ix driver which causes >>> it to bin connections when you manipulate ip aliases. >>> >>> This causes issues on boot when jails start as it bins other >>> active sessions. >>> >>> Is this a know issue? >>> >>> Running 8.2-RELEASE amd64 here. >>> >>> Regards >>> Steve >>> >> >> ================================================ >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of misdirection, >> the recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 <%2B44%20845%20868%201337> >> or return the E.mail to postmaster@multiplay.co.uk. >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 22:35:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA10106566B for ; Fri, 22 Apr 2011 22:35:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBC9E8FC12 for ; Fri, 22 Apr 2011 22:35:17 +0000 (UTC) Received: by vws18 with SMTP id 18so992867vws.13 for ; Fri, 22 Apr 2011 15:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gyBRC16Bhh+V6vYJ9wriGfMH2qEVYL8W6z1UjKYxOiU=; b=bih0iQJZs2nNBqWYrwCC2eiDLH6dQ5gVlA2Az//SDLB6BdN0nNo0gt/TGYB/3uiV0b QfyuO5Oq2bkvcXb331WDKOGLh1EjKD0KvQ1dZDfoFm4w8m1tzq7dkXEqsOHZy0IKG7K6 H5mGNc/fPFmkCfJvCn5dwkbrqrORfArfOvdcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Tl5ncdKl6JvvurQut576DCvmqfHHUcuDDNje9yoiOmc3Pr5pRozFYOS5idMhL3dtb6 yZs+3NIg1Cc1KukXvFJiFa74wvzQBbjh+FGIAEhScBQxd6wzBFD0vEJsaAMU1ZDZKxyU 3mWmZlJc/ux74LQAbuJl2Re1Kn6Ub3N4Z4v6M= MIME-Version: 1.0 Received: by 10.52.89.49 with SMTP id bl17mr2347626vdb.207.1303511716845; Fri, 22 Apr 2011 15:35:16 -0700 (PDT) Received: by 10.52.167.67 with HTTP; Fri, 22 Apr 2011 15:35:16 -0700 (PDT) In-Reply-To: References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> <521514204B99427691043FF127B6E841@multiplay.co.uk> Date: Fri, 22 Apr 2011 15:35:16 -0700 Message-ID: From: Jack Vogel To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 22:35:18 -0000 OK, did some testing, this re-init with link transition will happen on both the 1G drivers as well as ixgbe, its due to the stack/ioctl behavior when you do the ifconfig. So, what are you comparing this to that DOESN'T do this?? If this were to be kept from happening I'm not sure where the responsible code would be but I'm pretty sure its not in the driver :) Jack On Fri, Apr 22, 2011 at 3:13 PM, Jack Vogel wrote: > I see you have igb devices, if you do this with those interfaces is the > behavior different? > > I will have to look into this, thanks for the report. > > Jack > > > > On Fri, Apr 22, 2011 at 3:08 PM, Steven Hartland wrote: > >> Sorry yes I did meant just add an ip alias to the nic or remove it >> e.g. >> ifconfig ix0 10.10.1.10/32 alias >> ifconfig ix0 10.10.1.10 -alias >> >> pciconf -lv >> hostb0@pci0:0:0:0: class=0x060000 card=0xa28015d9 chip=0x40038086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400B Chipset Memory Controller Hub' >> class = bridge >> subclass = HOST-PCI >> pcib1@pci0:0:1:0: class=0x060400 card=0xa28015d9 chip=0x40218086 >> rev=0x20 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset PCIe Port 1' >> class = bridge >> subclass = PCI-PCI >> pcib4@pci0:0:3:0: class=0x060400 card=0xa28015d9 chip=0x40238086 >> rev=0x20 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset PCIe Port 3' >> class = bridge >> subclass = PCI-PCI >> pcib5@pci0:0:5:0: class=0x060400 card=0xa28015d9 chip=0x40258086 >> rev=0x20 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset PCIe Port 5' >> class = bridge >> subclass = PCI-PCI >> pcib6@pci0:0:7:0: class=0x060400 card=0xa28015d9 chip=0x40278086 >> rev=0x20 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset PCIe Port 7' >> class = bridge >> subclass = PCI-PCI >> pcib10@pci0:0:9:0: class=0x060400 card=0xa28015d9 chip=0x40298086 >> rev=0x20 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset PCIe Port 9' >> class = bridge >> subclass = PCI-PCI >> none0@pci0:0:15:0: class=0x088000 card=0xa28015d9 chip=0x402f8086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset DMA/DCA Engine' >> class = base peripheral >> hostb1@pci0:0:16:0: class=0x060000 card=0xa28015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset FSB Registers' >> class = bridge >> subclass = HOST-PCI >> hostb2@pci0:0:16:1: class=0x060000 card=0xa28015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset FSB Registers' >> class = bridge >> subclass = HOST-PCI >> hostb3@pci0:0:16:2: class=0x060000 card=0xa28015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset FSB Registers' >> class = bridge >> subclass = HOST-PCI >> hostb4@pci0:0:16:3: class=0x060000 card=0xa28015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset FSB Registers' >> class = bridge >> subclass = HOST-PCI >> hostb5@pci0:0:16:4: class=0x060000 card=0xa28015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset FSB Registers' >> class = bridge >> subclass = HOST-PCI >> hostb6@pci0:0:17:0: class=0x060000 card=0xa28015d9 chip=0x40318086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset Coherency Engine, Data Manager and >> Snoop Filter.' >> class = bridge >> subclass = HOST-PCI >> hostb7@pci0:0:21:0: class=0x060000 card=0xa28015d9 chip=0x40358086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >> 0' >> class = bridge >> subclass = HOST-PCI >> hostb8@pci0:0:21:1: class=0x060000 card=0xa28015d9 chip=0x40358086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >> 0' >> class = bridge >> subclass = HOST-PCI >> hostb9@pci0:0:22:0: class=0x060000 card=0xa28015d9 chip=0x40368086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >> 1' >> class = bridge >> subclass = HOST-PCI >> hostb10@pci0:0:22:1: class=0x060000 card=0xa28015d9 chip=0x40368086 >> rev=0x20 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >> 1' >> class = bridge >> subclass = HOST-PCI >> pcib11@pci0:0:28:0: class=0x060400 card=0xa28015d9 chip=0x26908086 >> rev=0x09 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB/3100 PCIe Root Port 1' >> class = bridge >> subclass = PCI-PCI >> uhci0@pci0:0:29:0: class=0x0c0300 card=0xa28015d9 chip=0x26888086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB/3100 Chipset USB Universal Host >> Controller *1' >> class = serial bus >> subclass = USB >> uhci1@pci0:0:29:1: class=0x0c0300 card=0xa28015d9 chip=0x26898086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB/3100 Chipset USB Universal Host >> Controller *2' >> class = serial bus >> subclass = USB >> uhci2@pci0:0:29:2: class=0x0c0300 card=0xa28015d9 chip=0x268a8086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB/3100 Chipset USB Universal Host >> Controller *3' >> class = serial bus >> subclass = USB >> ehci0@pci0:0:29:7: class=0x0c0320 card=0xa28015d9 chip=0x268c8086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB/3100 Chipset USB2 Enhanced Host >> Controller' >> class = serial bus >> subclass = USB >> pcib12@pci0:0:30:0: class=0x060401 card=0xa28015d9 chip=0x244e8086 >> rev=0xd9 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface >> to PCI Bridge' >> class = bridge >> subclass = PCI-PCI >> isab0@pci0:0:31:0: class=0x060100 card=0xa28015d9 chip=0x26708086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'LPC Interface Controller (631xESB/6321ESB/3100 )' >> class = bridge >> subclass = PCI-ISA >> atapci0@pci0:0:31:1: class=0x01018a card=0xa28015d9 chip=0x269e8086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB/3100 Ultra ATA Storage Controller' >> class = mass storage >> subclass = ATA >> none1@pci0:0:31:3: class=0x0c0500 card=0xa28015d9 chip=0x269b8086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'SMBus Controller (631xESB/6321ESB/3100)' >> class = serial bus >> subclass = SMBus >> pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x03708086 >> rev=0x00 hdr=0x01 >> vendor = 'Intel Corporation' >> device = 'Segment-A PCI Express-to-PCI Express Bridge (80333)' >> class = bridge >> subclass = PCI-PCI >> pcib3@pci0:1:0:2: class=0x060400 card=0x00000000 chip=0x03728086 >> rev=0x00 hdr=0x01 >> vendor = 'Intel Corporation' >> device = 'Segment-B PCI Express-to-PCI Express Bridge (80333)' >> class = bridge >> subclass = PCI-PCI >> arcmsr0@pci0:2:14:0: class=0x010400 card=0x122017d3 chip=0x122017d3 >> rev=0x00 hdr=0x00 >> vendor = 'Areca Technology Corporation' >> device = 'ARC-1220 8-Port PCIe to SATA RAID Controller' >> class = mass storage >> subclass = RAID >> ix0@pci0:5:0:0: class=0x020000 card=0x00068086 chip=0x10fb8086 rev=0x01 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> pcib7@pci0:6:0:0: class=0x060400 card=0xa28015d9 chip=0x35008086 >> rev=0x01 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB PCIe Upstream Port' >> class = bridge >> subclass = PCI-PCI >> pcib9@pci0:6:0:3: class=0x060400 card=0xa28015d9 chip=0x350c8086 >> rev=0x01 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB PCIe to PCI-X Bridge' >> class = bridge >> subclass = PCI-PCI >> pcib8@pci0:7:0:0: class=0x060400 card=0xa28015d9 chip=0x35108086 >> rev=0x01 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '631xESB/632xESB PCIe Downstream Port E1' >> class = bridge >> subclass = PCI-PCI >> igb0@pci0:10:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82575EB Gigabit Network Connection' >> class = network >> subclass = ethernet >> igb1@pci0:10:0:1: class=0x020000 card=0x10a715d9 chip=0x10a78086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82575EB Gigabit Network Connection' >> class = network >> subclass = ethernet >> vgapci0@pci0:12:1:0: class=0x030000 card=0xa28015d9 chip=0x515e1002 >> rev=0x02 hdr=0x00 >> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >> device = 'Radeon ES1000 (Radeon ES1000)' >> class = display >> subclass = VGA >> >> ----- Original Message ----- >> *From:* Jack Vogel >> *To:* Steven Hartland >> *Cc:* freebsd-net@freebsd.org ; Vogel, Jack >> *Sent:* Friday, April 22, 2011 5:45 PM >> *Subject:* Re: Intel ix (X520) disconnects when manipulating ips? >> >> Please give me the exact steps that are performed that create this, not >> sure what you mean by "manipulate ip aliases", if you mean ifconfig ix0 >> address, >> then this has always caused a reinit of the device, the same behavior is >> in the >> 1G devices. Or do you mean something else? >> >> Oh, and while at it, pciconf -lv >> >> Jack >> >> >> On Fri, Apr 22, 2011 at 9:15 AM, Steven Hartland > > wrote: >> >>> Hi Jack do you have any idea what's going on here as it very disruptive >>> for every IP change to cause total outage on the machine? >>> >>> ----- Original Message ----- From: "Steven Hartland" < >>> killing@multiplay.co.uk> >>> To: >>> Sent: Wednesday, April 20, 2011 2:37 PM >>> Subject: Intel ix (X520) disconnects when manipulating ips? >>> >>> >>> Seems there's an issue with the intel ix driver which causes >>>> it to bin connections when you manipulate ip aliases. >>>> >>>> This causes issues on boot when jails start as it bins other >>>> active sessions. >>>> >>>> Is this a know issue? >>>> >>>> Running 8.2-RELEASE amd64 here. >>>> >>>> Regards >>>> Steve >>>> >>> >>> ================================================ >>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>> the person or entity to whom it is addressed. In the event of misdirection, >>> the recipient is prohibited from using, copying, printing or otherwise >>> disseminating it or any information contained in it. >>> In the event of misdirection, illegible or incomplete transmission please >>> telephone +44 845 868 1337 <%2B44%20845%20868%201337> >>> or return the E.mail to postmaster@multiplay.co.uk. >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >> ================================================ >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of misdirection, >> the recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> > > From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 22:59:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CC37106566B for ; Fri, 22 Apr 2011 22:59:09 +0000 (UTC) (envelope-from prvs=10936998ff=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 336C18FC15 for ; Fri, 22 Apr 2011 22:59:07 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 22 Apr 2011 23:58:44 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 22 Apr 2011 23:58:44 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([217.41.255.142]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013016832.msg for ; Fri, 22 Apr 2011 23:58:44 +0100 X-MDRemoteIP: 217.41.255.142 X-Return-Path: prvs=10936998ff=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <3907840C807248E3870B360E6FFCB42B@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk><521514204B99427691043FF127B6E841@multiplay.co.uk> Date: Fri, 22 Apr 2011 23:59:02 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 22:59:09 -0000 Yes that works just as expected, never had this behaviour with any nic. Noticed straight away when we swapped from the igb (was em on 7.0) as when the jails on the machines booted they broke services on the main machine which where in the middle of initialising when the network went down again. Regards Steve ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: freebsd-net@freebsd.org ; Vogel, Jack=20 Sent: Friday, April 22, 2011 11:13 PM Subject: Re: Intel ix (X520) disconnects when manipulating ips? I see you have igb devices, if you do this with those interfaces is the behavior different? I will have to look into this, thanks for the report. Jack On Fri, Apr 22, 2011 at 3:08 PM, Steven Hartland wrote: Sorry yes I did meant just add an ip alias to the nic or remove it e.g. ifconfig ix0 10.10.1.10/32 alias ifconfig ix0 10.10.1.10 -alias pciconf -lv hostb0@pci0:0:0:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40038086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400B Chipset Memory Controller Hub' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40218086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 1' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:3:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40238086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 3' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:5:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40258086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 5' class =3D bridge subclass =3D PCI-PCI pcib6@pci0:0:7:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40278086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 7' class =3D bridge subclass =3D PCI-PCI pcib10@pci0:0:9:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x40298086 rev=3D0x20 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset PCIe Port 9' class =3D bridge subclass =3D PCI-PCI none0@pci0:0:15:0: class=3D0x088000 card=3D0xa28015d9 chip=3D0x402f8086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset DMA/DCA Engine' class =3D base peripheral hostb1@pci0:0:16:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:16:1: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:16:2: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:0:16:3: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:0:16:4: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40308086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset FSB Registers' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:0:17:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40318086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Coherency Engine, Data Manager and Snoop Filter.' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:0:21:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40358086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 0' class =3D bridge subclass =3D HOST-PCI hostb8@pci0:0:21:1: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40358086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 0' class =3D bridge subclass =3D HOST-PCI hostb9@pci0:0:22:0: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40368086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 1' class =3D bridge subclass =3D HOST-PCI hostb10@pci0:0:22:1: class=3D0x060000 card=3D0xa28015d9 chip=3D0x40368086 rev=3D0x20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5400 Series Chipset Channel Control for FB-DIMM Branch 1' class =3D bridge subclass =3D HOST-PCI pcib11@pci0:0:28:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x26908086 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 PCIe Root Port 1' class =3D bridge subclass =3D PCI-PCI uhci0@pci0:0:29:0: class=3D0x0c0300 card=3D0xa28015d9 chip=3D0x26888086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB Universal Host Controller *1' class =3D serial bus subclass =3D USB uhci1@pci0:0:29:1: class=3D0x0c0300 card=3D0xa28015d9 chip=3D0x26898086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB Universal Host Controller *2' class =3D serial bus subclass =3D USB uhci2@pci0:0:29:2: class=3D0x0c0300 card=3D0xa28015d9 chip=3D0x268a8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB Universal Host Controller *3' class =3D serial bus subclass =3D USB ehci0@pci0:0:29:7: class=3D0x0c0320 card=3D0xa28015d9 chip=3D0x268c8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Chipset USB2 Enhanced Host Controller' class =3D serial bus subclass =3D USB pcib12@pci0:0:30:0: class=3D0x060401 card=3D0xa28015d9 chip=3D0x244e8086 rev=3D0xd9 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0xa28015d9 chip=3D0x26708086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'LPC Interface Controller (631xESB/6321ESB/3100 )' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:31:1: class=3D0x01018a card=3D0xa28015d9 chip=3D0x269e8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB/3100 Ultra ATA Storage Controller' class =3D mass storage subclass =3D ATA none1@pci0:0:31:3: class=3D0x0c0500 card=3D0xa28015d9 chip=3D0x269b8086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'SMBus Controller (631xESB/6321ESB/3100)' class =3D serial bus subclass =3D SMBus pcib2@pci0:1:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x03708086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Segment-A PCI Express-to-PCI Express Bridge (80333)' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:1:0:2: class=3D0x060400 card=3D0x00000000 chip=3D0x03728086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Segment-B PCI Express-to-PCI Express Bridge (80333)' class =3D bridge subclass =3D PCI-PCI arcmsr0@pci0:2:14:0: class=3D0x010400 card=3D0x122017d3 chip=3D0x122017d3 rev=3D0x00 hdr=3D0x00 vendor =3D 'Areca Technology Corporation' device =3D 'ARC-1220 8-Port PCIe to SATA RAID Controller' class =3D mass storage subclass =3D RAID ix0@pci0:5:0:0: class=3D0x020000 card=3D0x00068086 chip=3D0x10fb8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet pcib7@pci0:6:0:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x35008086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB PCIe Upstream Port' class =3D bridge subclass =3D PCI-PCI pcib9@pci0:6:0:3: class=3D0x060400 card=3D0xa28015d9 chip=3D0x350c8086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB PCIe to PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI pcib8@pci0:7:0:0: class=3D0x060400 card=3D0xa28015d9 chip=3D0x35108086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '631xESB/632xESB PCIe Downstream Port E1' class =3D bridge subclass =3D PCI-PCI igb0@pci0:10:0:0: class=3D0x020000 card=3D0x10a715d9 chip=3D0x10a78086 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82575EB Gigabit Network Connection' class =3D network subclass =3D ethernet igb1@pci0:10:0:1: class=3D0x020000 card=3D0x10a715d9 chip=3D0x10a78086 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82575EB Gigabit Network Connection' class =3D network subclass =3D ethernet vgapci0@pci0:12:1:0: class=3D0x030000 card=3D0xa28015d9 chip=3D0x515e1002 rev=3D0x02 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device =3D 'Radeon ES1000 (Radeon ES1000)' class =3D display subclass =3D VGA ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: freebsd-net@freebsd.org ; Vogel, Jack=20 Sent: Friday, April 22, 2011 5:45 PM Subject: Re: Intel ix (X520) disconnects when manipulating ips? Please give me the exact steps that are performed that create this, not sure what you mean by "manipulate ip aliases", if you mean ifconfig ix0 address, then this has always caused a reinit of the device, the same behavior is in the 1G devices. Or do you mean something else? Oh, and while at it, pciconf -lv Jack On Fri, Apr 22, 2011 at 9:15 AM, Steven Hartland wrote: Hi Jack do you have any idea what's going on here as it very disruptive for every IP change to cause total outage on the machine? ----- Original Message ----- From: "Steven Hartland" To: Sent: Wednesday, April 20, 2011 2:37 PM Subject: Intel ix (X520) disconnects when manipulating ips? Seems there's an issue with the intel ix driver which causes it to bin connections when you manipulate ip aliases. This causes issues on boot when jails start as it bins other active sessions. Is this a know issue? Running 8.2-RELEASE amd64 here. Regards Steve =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Fri Apr 22 23:06:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CA301065670 for ; Fri, 22 Apr 2011 23:06:56 +0000 (UTC) (envelope-from prvs=10936998ff=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1DEF48FC08 for ; Fri, 22 Apr 2011 23:06:55 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 23 Apr 2011 00:06:33 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 23 Apr 2011 00:06:32 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([217.41.255.142]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013016936.msg for ; Sat, 23 Apr 2011 00:06:32 +0100 X-MDRemoteIP: 217.41.255.142 X-Return-Path: prvs=10936998ff=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Jack Vogel" References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk><521514204B99427691043FF127B6E841@multiplay.co.uk> Date: Sat, 23 Apr 2011 00:06:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: freebsd-net@freebsd.org, "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 23:06:56 -0000 Just double checked on igb1 on the same machine, adding an alias causes no loss in network from the primary or existing ip aliases for the nic. So this should be eliminating most variables except the driver? Regards Steve ----- Original Message ----- From: "Jack Vogel" To: "Steven Hartland" Cc: ; "Vogel, Jack" Sent: Friday, April 22, 2011 11:35 PM Subject: Re: Intel ix (X520) disconnects when manipulating ips? > OK, did some testing, this re-init with link transition will happen on both > the 1G > drivers as well as ixgbe, its due to the stack/ioctl behavior when you do > the > ifconfig. > > So, what are you comparing this to that DOESN'T do this?? If this were to > be kept from happening I'm not sure where the responsible code would be > but I'm pretty sure its not in the driver :) ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Apr 23 00:08:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFAEA106564A for ; Sat, 23 Apr 2011 00:08:44 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 953F08FC08 for ; Sat, 23 Apr 2011 00:08:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 0CCBA446007; Fri, 22 Apr 2011 20:09:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYu35x95wwHt; Fri, 22 Apr 2011 20:09:11 -0400 (EDT) Received: from [192.168.1.103] (c-174-54-254-163.hsd1.pa.comcast.net [174.54.254.163]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 93AAA446001; Fri, 22 Apr 2011 20:09:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer X-Priority: 3 In-Reply-To: Date: Fri, 22 Apr 2011 20:08:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <036FCFE4-98BA-4B90-A060-4597B68A3596@averesystems.com> References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk><521514204B99427691043FF127B6E841@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Jack Vogel , "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 00:08:45 -0000 Hello Steve and Jack, You need to handle the SIOCSIFADDR ioctl or it gets passed up the stack = to ether_ioctl(). When it goes up the interface gets reset. See the = comments in em_ioctl() and igb_ioctl(). We fixed this in ixgbe in our internal tree and it seems to work fine = with 82598 and 82599. You also need to include opt_inet.h for the INET = #define to be valid. -Andrew On Apr 22, 2011, at 7:06 PM, Steven Hartland wrote: > Just double checked on igb1 on the same machine, adding an alias = causes > no loss in network from the primary or existing ip aliases for the = nic. >=20 > So this should be eliminating most variables except the driver? >=20 > Regards > Steve >=20 > ----- Original Message ----- From: "Jack Vogel" > To: "Steven Hartland" > Cc: ; "Vogel, Jack" > Sent: Friday, April 22, 2011 11:35 PM > Subject: Re: Intel ix (X520) disconnects when manipulating ips? >=20 >=20 >> OK, did some testing, this re-init with link transition will happen = on both >> the 1G >> drivers as well as ixgbe, its due to the stack/ioctl behavior when = you do >> the >> ifconfig. >> So, what are you comparing this to that DOESN'T do this?? If this = were to >> be kept from happening I'm not sure where the responsible code would = be >> but I'm pretty sure its not in the driver :) >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. = and the person or entity to whom it is addressed. In the event of = misdirection, the recipient is prohibited from using, copying, printing = or otherwise disseminating it or any information contained in it.=20 > In the event of misdirection, illegible or incomplete transmission = please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Sat Apr 23 01:06:10 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 651E2106566B for ; Sat, 23 Apr 2011 01:06:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1067A8FC16 for ; Sat, 23 Apr 2011 01:06:09 +0000 (UTC) Received: by vxc34 with SMTP id 34so1065175vxc.13 for ; Fri, 22 Apr 2011 18:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4uzC9XtvC+YhvpFKrl7Y+ep3ADbTVrvaYremW3ZFh58=; b=T03a0QLgQIIHMLgZ6vCa7djEe6m0PN/TyCui7HwItsQc2Sd9fe6QFRYr03ZLMToYDR g/MOjupe3xgsZDdbltL2qz4Z1PnFu6rYIZONIZt7Vn2xYtTrP1m/Tki2bGs62m0nq+pH AlKyrJqNKCzNJXkwZ4b12nXyK3wHg6lrliat0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oTP2LJGGucGTnPp/IcmoaPeeqhUYpYxg36qjDC9ZyJreK5lyECkLX7DZA1sq4PHhCJ Wtl15VAJoGlBL5hIF2nsFfxrxyTTvDSXx90gVU6rpHTPe/PGMQQ7LxeRbnaZ28GbOfLw r+CI2BNv+d5rpgqoD7xRs8hrQa6falqWqFziE= MIME-Version: 1.0 Received: by 10.52.107.98 with SMTP id hb2mr2462608vdb.247.1303520769158; Fri, 22 Apr 2011 18:06:09 -0700 (PDT) Received: by 10.52.167.67 with HTTP; Fri, 22 Apr 2011 18:06:09 -0700 (PDT) In-Reply-To: <036FCFE4-98BA-4B90-A060-4597B68A3596@averesystems.com> References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> <521514204B99427691043FF127B6E841@multiplay.co.uk> <036FCFE4-98BA-4B90-A060-4597B68A3596@averesystems.com> Date: Fri, 22 Apr 2011 18:06:09 -0700 Message-ID: From: Jack Vogel To: Andrew Boyer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Steven Hartland , "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 01:06:10 -0000 Whoops, I see what you're talking about Andrew, OK, I get it, Steve I have another set of changes to get into ixgbe soon anyway, I'll roll this change up with that and then let you test it as soon as I get something ready, ok? Early next week. Jack On Fri, Apr 22, 2011 at 5:08 PM, Andrew Boyer wrote: > Hello Steve and Jack, > You need to handle the SIOCSIFADDR ioctl or it gets passed up the stack to > ether_ioctl(). When it goes up the interface gets reset. See the comments > in em_ioctl() and igb_ioctl(). > > We fixed this in ixgbe in our internal tree and it seems to work fine with > 82598 and 82599. You also need to include opt_inet.h for the INET #define > to be valid. > > -Andrew > > On Apr 22, 2011, at 7:06 PM, Steven Hartland wrote: > > > Just double checked on igb1 on the same machine, adding an alias causes > > no loss in network from the primary or existing ip aliases for the nic. > > > > So this should be eliminating most variables except the driver? > > > > Regards > > Steve > > > > ----- Original Message ----- From: "Jack Vogel" > > To: "Steven Hartland" > > Cc: ; "Vogel, Jack" > > Sent: Friday, April 22, 2011 11:35 PM > > Subject: Re: Intel ix (X520) disconnects when manipulating ips? > > > > > >> OK, did some testing, this re-init with link transition will happen on > both > >> the 1G > >> drivers as well as ixgbe, its due to the stack/ioctl behavior when you > do > >> the > >> ifconfig. > >> So, what are you comparing this to that DOESN'T do this?? If this were > to > >> be kept from happening I'm not sure where the responsible code would be > >> but I'm pretty sure its not in the driver :) > > > > > > ================================================ > > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirection, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > > or return the E.mail to postmaster@multiplay.co.uk. > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > From owner-freebsd-net@FreeBSD.ORG Sat Apr 23 04:48:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B06A7106564A for ; Sat, 23 Apr 2011 04:48:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 618388FC12 for ; Sat, 23 Apr 2011 04:48:11 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p3N4m8Ke055202 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Apr 2011 21:48:10 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DB25A39.3050301@freebsd.org> Date: Fri, 22 Apr 2011 21:48:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jack Vogel References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk> <521514204B99427691043FF127B6E841@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Steven Hartland , "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 04:48:12 -0000 On 4/22/11 3:35 PM, Jack Vogel wrote: > OK, did some testing, this re-init with link transition will happen on both > the 1G > drivers as well as ixgbe, its due to the stack/ioctl behavior when you do > the > ifconfig. > > So, what are you comparing this to that DOESN'T do this?? If this were to > be kept from happening I'm not sure where the responsible code would be > but I'm pretty sure its not in the driver :) Long standing behaviour when adding aliases is that no interruption is expected on the main address. Now this probably doesn't happen too often, but it'd be really annoying to have services interrupted on systems that add and subtract aliases regularly. (I have had such systems on load-sharing setups) Things could have changed and I suspect that it's harder and harder to achieve as chips get smarter, never the less, all the dumber chips I've used give this behaviour. (not shutting down the main address) > Jack > > > On Fri, Apr 22, 2011 at 3:13 PM, Jack Vogel wrote: > >> I see you have igb devices, if you do this with those interfaces is the >> behavior different? >> >> I will have to look into this, thanks for the report. >> >> Jack >> >> >> >> On Fri, Apr 22, 2011 at 3:08 PM, Steven Hartlandwrote: >> >>> Sorry yes I did meant just add an ip alias to the nic or remove it >>> e.g. >>> ifconfig ix0 10.10.1.10/32 alias >>> ifconfig ix0 10.10.1.10 -alias >>> >>> pciconf -lv >>> hostb0@pci0:0:0:0: class=0x060000 card=0xa28015d9 chip=0x40038086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400B Chipset Memory Controller Hub' >>> class = bridge >>> subclass = HOST-PCI >>> pcib1@pci0:0:1:0: class=0x060400 card=0xa28015d9 chip=0x40218086 >>> rev=0x20 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset PCIe Port 1' >>> class = bridge >>> subclass = PCI-PCI >>> pcib4@pci0:0:3:0: class=0x060400 card=0xa28015d9 chip=0x40238086 >>> rev=0x20 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset PCIe Port 3' >>> class = bridge >>> subclass = PCI-PCI >>> pcib5@pci0:0:5:0: class=0x060400 card=0xa28015d9 chip=0x40258086 >>> rev=0x20 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset PCIe Port 5' >>> class = bridge >>> subclass = PCI-PCI >>> pcib6@pci0:0:7:0: class=0x060400 card=0xa28015d9 chip=0x40278086 >>> rev=0x20 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset PCIe Port 7' >>> class = bridge >>> subclass = PCI-PCI >>> pcib10@pci0:0:9:0: class=0x060400 card=0xa28015d9 chip=0x40298086 >>> rev=0x20 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset PCIe Port 9' >>> class = bridge >>> subclass = PCI-PCI >>> none0@pci0:0:15:0: class=0x088000 card=0xa28015d9 chip=0x402f8086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset DMA/DCA Engine' >>> class = base peripheral >>> hostb1@pci0:0:16:0: class=0x060000 card=0xa28015d9 chip=0x40308086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset FSB Registers' >>> class = bridge >>> subclass = HOST-PCI >>> hostb2@pci0:0:16:1: class=0x060000 card=0xa28015d9 chip=0x40308086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset FSB Registers' >>> class = bridge >>> subclass = HOST-PCI >>> hostb3@pci0:0:16:2: class=0x060000 card=0xa28015d9 chip=0x40308086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset FSB Registers' >>> class = bridge >>> subclass = HOST-PCI >>> hostb4@pci0:0:16:3: class=0x060000 card=0xa28015d9 chip=0x40308086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset FSB Registers' >>> class = bridge >>> subclass = HOST-PCI >>> hostb5@pci0:0:16:4: class=0x060000 card=0xa28015d9 chip=0x40308086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset FSB Registers' >>> class = bridge >>> subclass = HOST-PCI >>> hostb6@pci0:0:17:0: class=0x060000 card=0xa28015d9 chip=0x40318086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset Coherency Engine, Data Manager and >>> Snoop Filter.' >>> class = bridge >>> subclass = HOST-PCI >>> hostb7@pci0:0:21:0: class=0x060000 card=0xa28015d9 chip=0x40358086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >>> 0' >>> class = bridge >>> subclass = HOST-PCI >>> hostb8@pci0:0:21:1: class=0x060000 card=0xa28015d9 chip=0x40358086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >>> 0' >>> class = bridge >>> subclass = HOST-PCI >>> hostb9@pci0:0:22:0: class=0x060000 card=0xa28015d9 chip=0x40368086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >>> 1' >>> class = bridge >>> subclass = HOST-PCI >>> hostb10@pci0:0:22:1: class=0x060000 card=0xa28015d9 chip=0x40368086 >>> rev=0x20 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '5400 Series Chipset Channel Control for FB-DIMM Branch >>> 1' >>> class = bridge >>> subclass = HOST-PCI >>> pcib11@pci0:0:28:0: class=0x060400 card=0xa28015d9 chip=0x26908086 >>> rev=0x09 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB/3100 PCIe Root Port 1' >>> class = bridge >>> subclass = PCI-PCI >>> uhci0@pci0:0:29:0: class=0x0c0300 card=0xa28015d9 chip=0x26888086 >>> rev=0x09 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB/3100 Chipset USB Universal Host >>> Controller *1' >>> class = serial bus >>> subclass = USB >>> uhci1@pci0:0:29:1: class=0x0c0300 card=0xa28015d9 chip=0x26898086 >>> rev=0x09 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB/3100 Chipset USB Universal Host >>> Controller *2' >>> class = serial bus >>> subclass = USB >>> uhci2@pci0:0:29:2: class=0x0c0300 card=0xa28015d9 chip=0x268a8086 >>> rev=0x09 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB/3100 Chipset USB Universal Host >>> Controller *3' >>> class = serial bus >>> subclass = USB >>> ehci0@pci0:0:29:7: class=0x0c0320 card=0xa28015d9 chip=0x268c8086 >>> rev=0x09 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB/3100 Chipset USB2 Enhanced Host >>> Controller' >>> class = serial bus >>> subclass = USB >>> pcib12@pci0:0:30:0: class=0x060401 card=0xa28015d9 chip=0x244e8086 >>> rev=0xd9 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface >>> to PCI Bridge' >>> class = bridge >>> subclass = PCI-PCI >>> isab0@pci0:0:31:0: class=0x060100 card=0xa28015d9 chip=0x26708086 >>> rev=0x09 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'LPC Interface Controller (631xESB/6321ESB/3100 )' >>> class = bridge >>> subclass = PCI-ISA >>> atapci0@pci0:0:31:1: class=0x01018a card=0xa28015d9 chip=0x269e8086 >>> rev=0x09 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB/3100 Ultra ATA Storage Controller' >>> class = mass storage >>> subclass = ATA >>> none1@pci0:0:31:3: class=0x0c0500 card=0xa28015d9 chip=0x269b8086 >>> rev=0x09 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'SMBus Controller (631xESB/6321ESB/3100)' >>> class = serial bus >>> subclass = SMBus >>> pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x03708086 >>> rev=0x00 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = 'Segment-A PCI Express-to-PCI Express Bridge (80333)' >>> class = bridge >>> subclass = PCI-PCI >>> pcib3@pci0:1:0:2: class=0x060400 card=0x00000000 chip=0x03728086 >>> rev=0x00 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = 'Segment-B PCI Express-to-PCI Express Bridge (80333)' >>> class = bridge >>> subclass = PCI-PCI >>> arcmsr0@pci0:2:14:0: class=0x010400 card=0x122017d3 chip=0x122017d3 >>> rev=0x00 hdr=0x00 >>> vendor = 'Areca Technology Corporation' >>> device = 'ARC-1220 8-Port PCIe to SATA RAID Controller' >>> class = mass storage >>> subclass = RAID >>> ix0@pci0:5:0:0: class=0x020000 card=0x00068086 chip=0x10fb8086 rev=0x01 >>> hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = network >>> subclass = ethernet >>> pcib7@pci0:6:0:0: class=0x060400 card=0xa28015d9 chip=0x35008086 >>> rev=0x01 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB PCIe Upstream Port' >>> class = bridge >>> subclass = PCI-PCI >>> pcib9@pci0:6:0:3: class=0x060400 card=0xa28015d9 chip=0x350c8086 >>> rev=0x01 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB PCIe to PCI-X Bridge' >>> class = bridge >>> subclass = PCI-PCI >>> pcib8@pci0:7:0:0: class=0x060400 card=0xa28015d9 chip=0x35108086 >>> rev=0x01 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '631xESB/632xESB PCIe Downstream Port E1' >>> class = bridge >>> subclass = PCI-PCI >>> igb0@pci0:10:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82575EB Gigabit Network Connection' >>> class = network >>> subclass = ethernet >>> igb1@pci0:10:0:1: class=0x020000 card=0x10a715d9 chip=0x10a78086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82575EB Gigabit Network Connection' >>> class = network >>> subclass = ethernet >>> vgapci0@pci0:12:1:0: class=0x030000 card=0xa28015d9 chip=0x515e1002 >>> rev=0x02 hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'Radeon ES1000 (Radeon ES1000)' >>> class = display >>> subclass = VGA >>> >>> ----- Original Message ----- >>> *From:* Jack Vogel >>> *To:* Steven Hartland >>> *Cc:* freebsd-net@freebsd.org ; Vogel, Jack >>> *Sent:* Friday, April 22, 2011 5:45 PM >>> *Subject:* Re: Intel ix (X520) disconnects when manipulating ips? >>> >>> Please give me the exact steps that are performed that create this, not >>> sure what you mean by "manipulate ip aliases", if you mean ifconfig ix0 >>> address, >>> then this has always caused a reinit of the device, the same behavior is >>> in the >>> 1G devices. Or do you mean something else? >>> >>> Oh, and while at it, pciconf -lv >>> >>> Jack >>> >>> >>> On Fri, Apr 22, 2011 at 9:15 AM, Steven Hartland>>> wrote: >>>> Hi Jack do you have any idea what's going on here as it very disruptive >>>> for every IP change to cause total outage on the machine? >>>> >>>> ----- Original Message ----- From: "Steven Hartland"< >>>> killing@multiplay.co.uk> >>>> To: >>>> Sent: Wednesday, April 20, 2011 2:37 PM >>>> Subject: Intel ix (X520) disconnects when manipulating ips? >>>> >>>> >>>> Seems there's an issue with the intel ix driver which causes >>>>> it to bin connections when you manipulate ip aliases. >>>>> >>>>> This causes issues on boot when jails start as it bins other >>>>> active sessions. >>>>> >>>>> Is this a know issue? >>>>> >>>>> Running 8.2-RELEASE amd64 here. >>>>> >>>>> Regards >>>>> Steve >>>>> >>>> ================================================ >>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>> the person or entity to whom it is addressed. In the event of misdirection, >>>> the recipient is prohibited from using, copying, printing or otherwise >>>> disseminating it or any information contained in it. >>>> In the event of misdirection, illegible or incomplete transmission please >>>> telephone +44 845 868 1337<%2B44%20845%20868%201337> >>>> or return the E.mail to postmaster@multiplay.co.uk. >>>> >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>> >>> ================================================ >>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>> the person or entity to whom it is addressed. In the event of misdirection, >>> the recipient is prohibited from using, copying, printing or otherwise >>> disseminating it or any information contained in it. >>> >>> In the event of misdirection, illegible or incomplete transmission please >>> telephone +44 845 868 1337 >>> or return the E.mail to postmaster@multiplay.co.uk. >>> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Apr 23 04:49:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03FD106564A for ; Sat, 23 Apr 2011 04:49:52 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id C87898FC16 for ; Sat, 23 Apr 2011 04:49:52 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p3N4nnwr055213 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Apr 2011 21:49:50 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DB25A9E.5040008@freebsd.org> Date: Fri, 22 Apr 2011 21:50:38 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andrew Boyer References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk><521514204B99427691043FF127B6E841@multiplay.co.uk> <036FCFE4-98BA-4B90-A060-4597B68A3596@averesystems.com> In-Reply-To: <036FCFE4-98BA-4B90-A060-4597B68A3596@averesystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Steven Hartland , Jack Vogel , "Vogel, Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 04:49:53 -0000 On 4/22/11 5:08 PM, Andrew Boyer wrote: > Hello Steve and Jack, > You need to handle the SIOCSIFADDR ioctl or it gets passed up the stack to ether_ioctl(). When it goes up the interface gets reset. See the comments in em_ioctl() and igb_ioctl(). > > We fixed this in ixgbe in our internal tree and it seems to work fine with 82598 and 82599. You also need to include opt_inet.h for the INET #define to be valid. so, what else have you fixed? :-) > -Andrew > > On Apr 22, 2011, at 7:06 PM, Steven Hartland wrote: > >> Just double checked on igb1 on the same machine, adding an alias causes >> no loss in network from the primary or existing ip aliases for the nic. >> >> So this should be eliminating most variables except the driver? >> >> Regards >> Steve >> >> ----- Original Message ----- From: "Jack Vogel" >> To: "Steven Hartland" >> Cc:; "Vogel, Jack" >> Sent: Friday, April 22, 2011 11:35 PM >> Subject: Re: Intel ix (X520) disconnects when manipulating ips? >> >> >>> OK, did some testing, this re-init with link transition will happen on both >>> the 1G >>> drivers as well as ixgbe, its due to the stack/ioctl behavior when you do >>> the >>> ifconfig. >>> So, what are you comparing this to that DOESN'T do this?? If this were to >>> be kept from happening I'm not sure where the responsible code would be >>> but I'm pretty sure its not in the driver :) >> >> ================================================ >> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Sat Apr 23 09:38:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35332106566B for ; Sat, 23 Apr 2011 09:38:40 +0000 (UTC) (envelope-from prvs=1094a6921b=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id B4BB68FC14 for ; Sat, 23 Apr 2011 09:38:39 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 23 Apr 2011 10:28:09 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 23 Apr 2011 10:28:09 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([217.41.255.142]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013023720.msg for ; Sat, 23 Apr 2011 10:28:08 +0100 X-MDRemoteIP: 217.41.255.142 X-Return-Path: prvs=1094a6921b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <476EA86052BC4305A3126F47FAB45252@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" , "Andrew Boyer" References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk><521514204B99427691043FF127B6E841@multiplay.co.uk><036FCFE4-98BA-4B90-A060-4597B68A3596@averesystems.com> Date: Sat, 23 Apr 2011 10:28:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: freebsd-net@freebsd.org, "Vogel,Jack" Subject: Re: Intel ix (X520) disconnects when manipulating ips? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 09:38:40 -0000 Thanks Jack / Andrew that would be awesome :) ----- Original Message ----- From: "Jack Vogel" > Whoops, I see what you're talking about Andrew, OK, I get it, Steve I have > another > set of changes to get into ixgbe soon anyway, I'll roll this change up with > that and > then let you test it as soon as I get something ready, ok? Early next week. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Apr 23 15:29:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6623D1065672 for ; Sat, 23 Apr 2011 15:29:19 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp6.uk.umis.net (smtp6.mail.clearhost.co.uk [IPv6:2001:1420::25:106]) by mx1.freebsd.org (Postfix) with ESMTP id 0794F8FC1C for ; Sat, 23 Apr 2011 15:29:18 +0000 (UTC) Received: from kate.prtsystems.ltd.uk ([217.65.165.35]) by smtp6.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QDelo-0005Ck-P4; Sat, 23 Apr 2011 15:29:16 +0000 Message-ID: <4DB2F04C.9000006@prt.org> Date: Sat, 23 Apr 2011 16:29:16 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4DADD913.5010208@prt.org> <20110419220907.GD1637@michelle.cdnetworks.com> <4DAEBB67.7070303@prt.org> <20110420131613.GA84319@alchemy.franken.de> <4DAEDE27.8080205@prt.org> <20110420134459.GL38455@alchemy.franken.de> <4DAEF9F8.5070305@prt.org> <20110420171813.GA8566@michelle.cdnetworks.com> In-Reply-To: <20110420171813.GA8566@michelle.cdnetworks.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Marius Strobl Subject: Re: Broadcom BCM57765 support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 15:29:19 -0000 Hi, Good news - I have success! On 20/04/2011 18:18, YongHyeon PYUN wrote: > Ok, that would indicate there is an interrupt delivery issue if all > others changes(including Marius' patch) are correct. Because there > is no publicly available data sheet for BCM57765 yet I'm not sure > what is real difference between BCM5717 and BCM57765. However I > guess they require similar hardware configuration. Both BCM5717 and > BCM57765 will use tagged status feature of controller if MSI is > available. And NVIDIA bridge controller is known to have MSI issues > for a long time in FreeBSD. Please check whether you received any > interrupts for bge(4) with vmstat(8). If you see no interrupt from > the output, either try disabling MSI or apply r219737 and r219740 > and see whether that makes any difference. The problem is definitely with the interrupts. I saw nothing for bge in vmstat with MSI enabled. Rebooting with MSI disabled and all works well so far - I haven't done a lot of testing yet, but it has been operating with pings / file transfers for over 1 hour now without problems. Apologies for asking such a basic question, but I've typically downloaded latest sources etc. from HEAD via cvsweb in the past when I needed them. How do I locate the r219737 and r219740 changes on their own to try them out with MSI enabled? I'm guessing I'll need to cvsup the relevant sources but I can't see how to find out what I need. Thanks, Paul.