From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 01:53:08 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6899106564A for ; Sun, 7 Oct 2012 01:53:08 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3B58FC08 for ; Sun, 7 Oct 2012 01:53:07 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-178.belrs5.nsw.optusnet.com.au [220.239.248.178]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q971qwVM007278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Oct 2012 12:52:59 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q971qq5F047775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Oct 2012 12:52:52 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q971qpJP047593; Sun, 7 Oct 2012 12:52:51 +1100 (EST) (envelope-from peter) Date: Sun, 7 Oct 2012 12:52:51 +1100 From: Peter Jeremy To: Sergey Kandaurov Message-ID: <20121007015251.GB22291@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Darrel , current@freebsd.org Subject: Re: memory warnings r240891 | dmesgg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 01:53:08 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Oct-04 23:51:09 +0400, Sergey Kandaurov wrote: >On 4 October 2012 20:18, Darrel wrote: >> warning: total configured swap (2621440 pages) exceeds maximum >> recommended amount (1852656 pages). =2E.. >This is because kernel needs some memory to manage swap too. >Currently for amd64 this roughly reduces to the following rule >(My apologies in advance for the extra simplification): > >100MB RAM per 800MB swap space. That is oversimplified to the point of being wrong. As of HEAD r239255 and 9-stable r240097, there's no longer a limit on amd64. The limit is still required on 32-bit architectures due to the limited KVA available. The actual KVA requirements (RAM is only allocated when the swap space is actually used) is about 5MB KVA per 1GB swap. The default swzone for i386 was 32MiB - which is sufficient for ~7GB swap (the 1852656 pages reported above) and was increased to 34.5MB for i386 in r239730 to support ~8GB swap (this is also in r240097). (It's all approximate because of the way swap space is allocated using struct swblock). See the thread starting http://lists.freebsd.org/pipermail/freebsd-current/2012-August/035839.html for more details. --=20 Peter Jeremy --98e8jtXdkpgskNou Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBw4HMACgkQ/opHv/APuIeuQwCdHFvTbsM3kwfE8/tjSGZrHnT6 qP8AniNYq04HoqobIz4PQYeKIl8yL3Of =pS8X -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 10:23:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D93EC1065670; Sun, 7 Oct 2012 10:23:17 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 92F338FC0A; Sun, 7 Oct 2012 10:23:16 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 660D27300A; Sun, 7 Oct 2012 12:43:30 +0200 (CEST) Date: Sun, 7 Oct 2012 12:43:30 +0200 From: Luigi Rizzo To: Andrew Thompson Message-ID: <20121007104330.GA75115@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> 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: current@freebsd.org Subject: Re: sysctl-controlled key-value store ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:23:18 -0000 On Sun, Oct 07, 2012 at 12:57:42PM +1300, Andrew Thompson wrote: > On 7 October 2012 06:28, Luigi Rizzo wrote: > > Hi, > > in order to control some netmap feature (namely, which interfaces > > are attached to VALE switches), i would considering the use of > > a sysctl interface triggering a sysctl-proc, something of the form > > > > dev.netmap.switch.xyz=em0 ix1 > > dev.netmap.switch.foo=ix2 re0 > > Is it possible to use ifconfig? If a VALE switch was a pseudo > interface and you added real interfaces to it then it would be > consistent with the current networking fu. Good point, thanks for mentioning this: Could be done, but I consider the ifconfig one of the ugliest configuration mechanisms we have in FreeBSD so I'd rather not contribute to that. src/sbin/ifconfig/ has over 11K of C source, most of it just in charge of filling some obscure ioctl argument with limited error checking. For instance, ifbridge.c has 700 lines of code defines 38 commands or variants. All the code does is convert command line into one of the structs below defining the user-kernel interface. Most of them are used 1-2 times in total in the entire userland code (in ifconfig and bsnmpd/modules/snmp_bridge) struct ifdrv struct ifbifconf struct ifbreq struct ifbaconf struct ifbareq struct ifbropreq struct ifbrparam All the processing is done in the kernel. Performance is not a concern given the low frequency of these actions. What is the point of this complication ? One could just do things like sysctl dev.bridge.br3.priorit=16384 sysctl dev.bridge.br3.addm=re0 ... (and the like) with no complications on the kernel side and huge simplifications on the userland side and kernel-user ABI. Replace sysctl with sysfs or other mechanism of choice. ifieee80211 is even worse -- over 5000 lines of code, 153 between commands and arguments, and 31 different parameters: struct ieee80211_ath_ie struct ieee80211_channel struct ieee80211_chanswitch_req struct ieee80211_clone_params struct ieee80211_country_ie struct ieee80211_devcaps_req struct ieee80211_ie_htcap struct ieee80211_ie_htinfo struct ieee80211_meshconf_ie struct ieee80211_mimo_info struct ieee80211_regdomain struct ieee80211_regdomain_req struct ieee80211_roamparam struct ieee80211_roamparams_req struct ieee80211_scan_req struct ieee80211_tdma_param struct ieee80211_txparam struct ieee80211_txparams_req struct ieee80211_wme_acparams struct ieee80211_wme_info struct ieee80211_wme_param struct ieee80211req struct ieee80211req_chaninfo struct ieee80211req_chanlist struct ieee80211req_key struct ieee80211req_maclist struct ieee80211req_mesh_route struct ieee80211req_mlme struct ieee80211req_scan_result struct ieee80211req_sta_info struct ieee80211req_sta_req cheers luigi > Andrew > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 10:40:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 818B3106566C; Sun, 7 Oct 2012 10:40:56 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id 864688FC08; Sun, 7 Oct 2012 10:40:54 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 154285814; Sun, 07 Oct 2012 12:40:46 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org, hackers@freebsd.org Date: Sun, 7 Oct 2012 12:42:11 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <5070C1E9.5000405@sbcglobal.net> In-Reply-To: <5070C1E9.5000405@sbcglobal.net> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210071242.11932.hselasky@c2i.net> Cc: bugs@freebsd.org, Jin Guojun , current@freebsd.org Subject: Re: 9.1-RCs issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:40:56 -0000 On Sunday 07 October 2012 01:42:33 Jin Guojun wrote: > 1) moused stops functioning on 9.1-RC2. Neither PS2 nor USB mouse can work. > 9.1-RC1 has no such problem. > > 2) All i386 / amd64 of 9.1-RC1/RC2 have USB read failure -- see dmesg > output at end of this email. > ada0 is internal SATA drive for system disk -- s# partitions: /, /tmp, > /var, /usr > s1 -- 6.4-Release > s2 -- 8.3-Release > s3 -- 9.1-RC2 amd64 > s4 -- 9.1-RC2 i386 -- This slice also contains /home > da0 is external USB2 drive (300GB) plugged in USB2 port -- mounted on /mnt > Regarding USB, it might be some patches did not reach it for the RC's. Have you tried 9-stable, or any 10-current snapshots? --HPS From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 12:43:38 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F27161065670; Sun, 7 Oct 2012 12:43:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 742E38FC12; Sun, 7 Oct 2012 12:43:35 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 329237632; Sun, 07 Oct 2012 14:43:27 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Sun, 7 Oct 2012 14:44:52 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <5070C1E9.5000405@sbcglobal.net> <201210071242.11932.hselasky@c2i.net> In-Reply-To: <201210071242.11932.hselasky@c2i.net> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210071444.52845.hselasky@c2i.net> Cc: bugs@freebsd.org, hackers@freebsd.org, Jin Guojun , freebsd-usb@freebsd.org, current@freebsd.org Subject: Re: 9.1-RCs issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 12:43:38 -0000 On Sunday 07 October 2012 12:42:11 Hans Petter Selasky wrote: > On Sunday 07 October 2012 01:42:33 Jin Guojun wrote: > > 1) moused stops functioning on 9.1-RC2. Neither PS2 nor USB mouse can > > work. > > > > 9.1-RC1 has no such problem. > > > > 2) All i386 / amd64 of 9.1-RC1/RC2 have USB read failure -- see dmesg > > output at end of this email. > > ada0 is internal SATA drive for system disk -- s# partitions: /, /tmp, > > /var, /usr > > > > s1 -- 6.4-Release > > s2 -- 8.3-Release > > s3 -- 9.1-RC2 amd64 > > s4 -- 9.1-RC2 i386 -- This slice also contains /home > > > > da0 is external USB2 drive (300GB) plugged in USB2 port -- mounted on > > /mnt > > Regarding USB, it might be some patches did not reach it for the RC's. Have > you tried 9-stable, or any 10-current snapshots? > > --HPS s/reach/make --HPS From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 14:08:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C00B6106566B; Sun, 7 Oct 2012 14:08:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 12DBE8FC08; Sun, 7 Oct 2012 14:08:55 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so3657479pbb.13 for ; Sun, 07 Oct 2012 07:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=od0kDHiL/JBN+Q84ZTFV1NMf/feeWLJfv2ozoyvp/RU=; b=mO2hn/kUIFxB7Xjih4TQhFdIfG1t+3ZTTb7v0Z59t0wJXETW6c3OStCwadZbPxC78X 0taO4U2dYQbsyn1ySet2IBLkhMPodNP6stzG/+kRaPnMEwFzc7SRSubhqKv0sKYXfgAE sOyIaiO8irq35tZwAeVxIl9bIbxFfSMoLzlfstIbP3et7WsWWY+wix4Z2mWXMv38vQy1 JJu3mI+GndXzeCvvOx1K69RLcIF0IV7D3uRiWDzzYKh9/uHMxkzscFeg8pz4Jo5qFG/+ Pfx8Hq+SsVYU4P0+FUN3piMC1QmQ0zDip5IfHnINa8fWbkCnhpSXdYKZjITWIuo1TL/o Bivg== MIME-Version: 1.0 Received: by 10.68.222.37 with SMTP id qj5mr45196125pbc.132.1349618934499; Sun, 07 Oct 2012 07:08:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Sun, 7 Oct 2012 07:08:54 -0700 (PDT) In-Reply-To: <20121007104330.GA75115@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> Date: Sun, 7 Oct 2012 07:08:54 -0700 X-Google-Sender-Auth: K8rtCc4DGZycHaqUln26joWVyyo Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: sysctl-controlled key-value store ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 14:08:55 -0000 On 7 October 2012 03:43, Luigi Rizzo wrote: > > Good point, thanks for mentioning this: ew. ifconfig :-) > > Could be done, but I consider the ifconfig one of the ugliest > configuration mechanisms we have in FreeBSD so I'd rather not > contribute to that. Seconded; but compare to Linux which has mutiple different commands to do networking, as well as 'net'. :-) > src/sbin/ifconfig/ has over 11K of C source, most of it just in > charge of filling some obscure ioctl argument with limited error > checking. > > For instance, ifbridge.c has 700 lines of code defines 38 commands > or variants. All the code does is convert command line into one of [snip] > (and the like) with no complications on the kernel side and > huge simplifications on the userland side and kernel-user ABI. > Replace sysctl with sysfs or other mechanism of choice. > > > ifieee80211 is even worse -- over 5000 lines of code, > 153 between commands and arguments, and 31 different parameters: I'd personally like to break these kinds of things out into libraries so other C code can use them. I'm eventually going to do it to the net80211 code in ifconfig; maybe it's also worth doing to if_bridge for example. Doing configuration via sysctl can be hokey, especially when you use sysctl and sysfs to do things which change the sysctl/sysfs layout (by creating/destroying nodes as you change the configuration.) It's .. ew. Maybe for your bridge stuff its easy enough, but for something like net80211 where there's a lot of things to configure, doing it via sysctl would involve lots of parsing in the kernel.. and I like my kernels smaller. :-) Adrian From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 14:42:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBAF11065670; Sun, 7 Oct 2012 14:42:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 62B8B8FC0A; Sun, 7 Oct 2012 14:42:05 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A82417300A; Sun, 7 Oct 2012 17:02:19 +0200 (CEST) Date: Sun, 7 Oct 2012 17:02:19 +0200 From: Luigi Rizzo To: Adrian Chadd Message-ID: <20121007150219.GA76853@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> 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: current@freebsd.org Subject: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 14:42:07 -0000 [subject changed due to the shift of topic] On Sun, Oct 07, 2012 at 07:08:54AM -0700, Adrian Chadd wrote: > On 7 October 2012 03:43, Luigi Rizzo wrote: > > > > Good point, thanks for mentioning this: > > ew. ifconfig :-) > > > > > Could be done, but I consider the ifconfig one of the ugliest > > configuration mechanisms we have in FreeBSD so I'd rather not > > contribute to that. > > Seconded; but compare to Linux which has mutiple different commands to > do networking, as well as 'net'. :-) we do too -- we have arp, route, ifconfig, sysctl and possibly more that i am not aware of. Some ipfw features are controlled by sysctl, and there is code in ipfw that maps "ipfw do something" into "sysctl net.inet.ipfw.do.something-under-another-name" I am not sure that a single frontend is the way to go. And I understand that there are opportunity reasons (importing external code, compatibility with others, etc.) which suggested to look at ifconfig as a general purpose frontend for interface manipulation. Coming to 802.11 (and I am using it just as an example): configuration of the various parameters is not too different from, say, manipulating the various features that are available in modern NICs: interrupt mitigation, queue parameters, multiqueue support, RSS, and so on. In this area linux has ethtool, while we have mostly device-specific sysctls. I'd love to have a device-independent mechanism to implement this. I do not think we need to go through the definition of a new ioctl/sockopt every time we find that a new parameter is required/useful. > > ifieee80211 is even worse -- over 5000 lines of code, > > 153 between commands and arguments, and 31 different parameters: > > I'd personally like to break these kinds of things out into libraries > so other C code can use them. my point was that this type of configuration is rarely if ever done outside setup or management scripts, at an incredibly low rate and as such does not need a C API (which in case the sysctl gives you). > I'm eventually going to do it to the net80211 code in ifconfig; maybe > it's also worth doing to if_bridge for example. > > Doing configuration via sysctl can be hokey, especially when you use > sysctl and sysfs to do things which change the sysctl/sysfs layout (by > creating/destroying nodes as you change the configuration.) It's .. can you elaborate ? If i destroy an interface (or disable a function) and kill a subtree, and this causes a subsequent configuration of the non-existing parameter to fail, what is wrong with that ? > ew. > > Maybe for your bridge stuff its easy enough, but for something like > net80211 where there's a lot of things to configure, doing it via > sysctl would involve lots of parsing in the kernel.. and I like my > kernels smaller. :-) Here too i kind of fail to see how much additional parsing you would need in the kernel when using sysctl as opposed to ioctl(), so an example would help. Integers and strcmp do not require any parsing, and some small functions to parse MAC/IP addresses or chanlist arguments are not going to cause incredible bloat (and besides i think they already exist in multiple versions in the various userspace utilities). cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 15:11:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D1E6106564A for ; Sun, 7 Oct 2012 15:11:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id DEC798FC08 for ; Sun, 7 Oct 2012 15:11:28 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q97FBSTR072097 for ; Sun, 7 Oct 2012 08:11:28 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q97FBSiE072096 for current@freebsd.org; Sun, 7 Oct 2012 08:11:28 -0700 (PDT) (envelope-from david) Date: Sun, 7 Oct 2012 08:11:28 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20121007151128.GL23688@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6AC2iLg5WpuQM9hq" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 15:11:30 -0000 --6AC2iLg5WpuQM9hq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I started seeing these messages spewed (to both console & /var/log/messages) following an update from: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #697 241222= M: Fri Oct 5 05:32:19 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 to FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #698 241245= M: Sat Oct 6 08:01:23 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 and I'm still seeing them as of FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #699 241309= M: Sun Oct 7 07:35:41 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 E.g.: Oct 6 08:24:10 g1-227 kernel: wlan0: Ethernet address: 00:21:6a:26:34:c0 Oct 6 08:24:10 g1-227 kernel: Expensive timeout(9) function: 0xc0c27520(0)= 0.010540166 s Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 10200 Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 10200 Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 18105 Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 18105 Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 17340 Oct 6 08:24:10 g1-227 last message repeated 3 times Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 19380 Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 10200 Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 19380 Oct 6 08:24:10 g1-227 last message repeated 4 times =2E.. or (more recently): Oct 7 07:58:53 g1-227 kernel: wlan0: Ethernet address: 00:21:6a:26:34:c0 Oct 7 07:58:53 g1-227 kernel: Expensive timeout(9) function: 0xc0c27550(0)= 0.011038204 s Oct 7 07:58:53 g1-227 kernel: in_cksum_skip: out of data by 18105 Oct 7 07:58:53 g1-227 kernel: in_cksum_skip: out of data by 18105 Oct 7 07:58:53 g1-227 kernel: in_cksum_skip: out of data by 17340 Oct 7 07:58:53 g1-227 last message repeated 3 times Oct 7 07:58:53 g1-227 kernel: in_cksum_skip: out of data by 10200 Oct 7 07:58:53 g1-227 kernel: in_cksum_skip: out of data by 19380 Oct 7 07:58:54 g1-227 last message repeated 4 times =2E.. As far as I have been able to tell so far, the machine (my laptop) is not exhibiting any (aother) indications of problems. I confess that I am not entirely clear on what information the message is apparently trying to convey (let alone what I can or should do about it -- if anything). Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --6AC2iLg5WpuQM9hq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBxm58ACgkQmprOCmdXAD0l8QCeO6gSeFZZ/KylR+AIx2AO+tyJ RpgAn2Ob1pFzFvFT6pt4C0mJqtEiHS5r =2LCd -----END PGP SIGNATURE----- --6AC2iLg5WpuQM9hq-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 15:16:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C7EC106564A for ; Sun, 7 Oct 2012 15:16:48 +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 89C3F8FC0C for ; Sun, 7 Oct 2012 15:16:47 +0000 (UTC) Received: (qmail 4892 invoked from network); 7 Oct 2012 15:10:04 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 Oct 2012 15:10:04 -0000 Date: Sun, 07 Oct 2012 17:10:04 +0200 (CEST) Message-Id: <20121007.171004.74748690.sthaug@nethelp.no> To: rizzo@iet.unipi.it From: sthaug@nethelp.no In-Reply-To: <20121007150219.GA76853@onelab2.iet.unipi.it> References: <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> 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: adrian@freebsd.org, current@freebsd.org Subject: Re: sysctl vs ifconfig vs other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 15:16:48 -0000 > > Seconded; but compare to Linux which has mutiple different commands to > > do networking, as well as 'net'. :-) > > we do too -- we have arp, route, ifconfig, sysctl and possibly > more that i am not aware of. Note that at least arp, route and ifconfig have been there since very early BSD releases (they predate FreeBSD, as far as I know). sysctl is from BSD 4.4 (I think, but I'm very willing to be corrected here). What I'm trying to say here is that arp, route and ifconfig are in some sense the original BSD commands to set/change networking params. The Linux camp saw the need to introduce a new command ("ip") to do a lot of what we do with ifconfig (e.g. VLAN manipulation) while FreeBSD chose to add to the ifconfig command. I prefer the FreeBSD way - but this is a matter of personal taste. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 15:20:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 064661065672; Sun, 7 Oct 2012 15:20:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 145BD8FC12; Sun, 7 Oct 2012 15:20:10 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q97FKHSJ032806; Sun, 7 Oct 2012 18:20:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q97FK5Mb005146; Sun, 7 Oct 2012 18:20:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q97FK5j7005145; Sun, 7 Oct 2012 18:20:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 7 Oct 2012 18:20:05 +0300 From: Konstantin Belousov To: amd64@freebsd.org Message-ID: <20121007152005.GX35915@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+y7rRxfO4bOZsSs1" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: Unwind annotations for the libc and libthr asm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 15:20:12 -0000 --+y7rRxfO4bOZsSs1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please find below the patch to add the unwind annotations for the libc and libthr assembler routines on amd64. The change shall have no impact on the execution of the changed code, because no functions there ever generate C++ exception or call a function that could generate exception. The addition of the annotations significantly improves the results of the libunwind test suite on FreeBSD/amd64. We are still not on par with Linux, mainly due to the lack of the unwind annotations for the signal trampolines. Fixing this requires VDSO. The addition of the annotations is rather tedious and unrelieved work, so I am sure that there are left bugs. Bugs would affect both libunwind and gdb, but what I see looks like a step forward anyway. Any comments ? diff --git a/lib/libc/amd64/SYS.h b/lib/libc/amd64/SYS.h index a232383..3101be5 100644 --- a/lib/libc/amd64/SYS.h +++ b/lib/libc/amd64/SYS.h @@ -41,15 +41,25 @@ .set CNAME(x),CNAME(__CONCAT(__sys_,x)); \ .weak CNAME(__CONCAT(_,x)); \ .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ - mov __CONCAT($SYS_,x),%eax; KERNCALL; \ - jb HIDENAME(cerror); ret; \ + mov __CONCAT($SYS_,x),%eax; \ + .cfi_undefined %rax; \ + KERNCALL; \ + jb HIDENAME(cerror); \ + ret; \ END(__CONCAT(__sys_,x)) =20 #define PSEUDO(x) ENTRY(__CONCAT(__sys_,x)); \ .weak CNAME(__CONCAT(_,x)); \ .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ - mov __CONCAT($SYS_,x),%eax; KERNCALL; \ - jb HIDENAME(cerror); ret; \ + mov __CONCAT($SYS_,x),%eax; \ + .cfi_undefined %rax; \ + KERNCALL; \ + jb HIDENAME(cerror); \ + ret; \ END(__CONCAT(__sys_,x)) =20 -#define KERNCALL movq %rcx, %r10; syscall +#define KERNCALL movq %rcx,%r10; \ + .cfi_undefined %r10; \ + .cfi_register %rcx,%r10; \ + syscall; \ + .cfi_undefined %rax,%rdx diff --git a/lib/libc/amd64/gen/_setjmp.S b/lib/libc/amd64/gen/_setjmp.S index 9035632..84cc0c9 100644 --- a/lib/libc/amd64/gen/_setjmp.S +++ b/lib/libc/amd64/gen/_setjmp.S @@ -48,7 +48,9 @@ __FBSDID("$FreeBSD$"); =20 ENTRY(_setjmp) movq %rdi,%rax + .cfi_register %rdi,%rax movq 0(%rsp),%rdx /* retval */ + .cfi_undefined %rdx movq %rdx, 0(%rax) /* 0; retval */ movq %rbx, 8(%rax) /* 1; rbx */ movq %rsp,16(%rax) /* 2; rsp */ @@ -60,6 +62,7 @@ ENTRY(_setjmp) fnstcw 64(%rax) /* 8; fpu cw */ stmxcsr 68(%rax) /* and mxcsr */ xorq %rax,%rax + .cfi_undefined %rax ret END(_setjmp) =20 @@ -67,17 +70,30 @@ END(_setjmp) .set CNAME(_longjmp),CNAME(___longjmp) ENTRY(___longjmp) movq %rdi,%rdx + .cfi_undefined %rdx + .cfi_register %rdi,%rdx /* Restore the mxcsr, but leave exception flags intact. */ stmxcsr -4(%rsp) movl 68(%rdx),%eax + .cfi_undefined %rax andl $0xffffffc0,%eax movl -4(%rsp),%edi + .cfi_undefined %rdi andl $0x3f,%edi xorl %eax,%edi movl %edi,-4(%rsp) ldmxcsr -4(%rsp) movq %rsi,%rax /* retval */ + .cfi_def_cfa %rdx,16 + .cfi_offset %rbx,8 + .cfi_offset %rbp,24 + .cfi_offset %r12,32 + .cfi_offset %r13,40 + .cfi_offset %r14,48 + .cfi_offset %r15,56 movq 0(%rdx),%rcx + .cfi_undefined %rcx + .cfi_return_column %rcx movq 8(%rdx),%rbx movq 16(%rdx),%rsp movq 24(%rdx),%rbp diff --git a/lib/libc/amd64/gen/rfork_thread.S b/lib/libc/amd64/gen/rfork_t= hread.S index 5e764db..9ce0484 100644 --- a/lib/libc/amd64/gen/rfork_thread.S +++ b/lib/libc/amd64/gen/rfork_thread.S @@ -46,7 +46,11 @@ __FBSDID("$FreeBSD$"); =20 ENTRY(rfork_thread) pushq %rbx + .cfi_adjust_cfa_offset 8 + .cfi_offset %rbx,-8 pushq %r12 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r12,-16 movq %rdx, %rbx movq %rcx, %r12 =20 @@ -63,7 +67,11 @@ ENTRY(rfork_thread) cmpl $0, %edx jnz 1f popq %r12 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r12 popq %rbx + .cfi_adjust_cfa_offset -8 + .cfi_restore %rbx ret =20 /* @@ -73,6 +81,7 @@ ENTRY(rfork_thread) */ 1: movq %rsi, %rsp + .cfi_def_cfa_register %rsi movq %r12, %rdi=20 call *%rbx movl %eax, %edi @@ -92,7 +101,11 @@ ENTRY(rfork_thread) */ 2: popq %r12 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r12 popq %rbx + .cfi_adjust_cfa_offset -8 + .cfi_restore %rbx jmp HIDENAME(cerror) END(rfork_thread) =20 diff --git a/lib/libc/amd64/gen/setjmp.S b/lib/libc/amd64/gen/setjmp.S index 47772be..356d34c 100644 --- a/lib/libc/amd64/gen/setjmp.S +++ b/lib/libc/amd64/gen/setjmp.S @@ -50,13 +50,21 @@ __FBSDID("$FreeBSD$"); =20 ENTRY(setjmp) pushq %rdi + .cfi_adjust_cfa_offset 8 movq %rdi,%rcx + .cfi_undefined %rcx + .cfi_register %rdi,%rcx movq $1,%rdi /* SIG_BLOCK */ + .cfi_undefined %rdi movq $0,%rsi /* (sigset_t*)set */ + .cfi_undefined %rsi leaq 72(%rcx),%rdx /* 9,10; (sigset_t*)oset */ + .cfi_undefined %rdx /* stack is 16-byte aligned */ call PIC_PLT(CNAME(_sigprocmask)) popq %rdi + .cfi_adjust_cfa_offset -8 + .cfi_restore %rdi movq %rdi,%rcx movq 0(%rsp),%rdx /* retval */ movq %rdx, 0(%rcx) /* 0; retval */ @@ -77,28 +85,51 @@ END(setjmp) .set CNAME(longjmp),CNAME(__longjmp) ENTRY(__longjmp) pushq %rdi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rdi,-8 pushq %rsi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rsi,-16 movq %rdi,%rdx + .cfi_undefined %rdx + .cfi_register %rdi,%rdx movq $3,%rdi /* SIG_SETMASK */ leaq 72(%rdx),%rsi /* (sigset_t*)set */ movq $0,%rdx /* (sigset_t*)oset */ subq $0x8,%rsp /* make the stack 16-byte aligned */ + .cfi_adjust_cfa_offset 8 call PIC_PLT(CNAME(_sigprocmask)) addq $0x8,%rsp + .cfi_adjust_cfa_offset -8 popq %rsi + .cfi_adjust_cfa_offset -8 + .cfi_restore %rsi popq %rdi /* jmpbuf */ + .cfi_adjust_cfa_offset -8 + .cfi_restore %rdi movq %rdi,%rdx + .cfi_register %rdi,%rdx /* Restore the mxcsr, but leave exception flags intact. */ stmxcsr -4(%rsp) movl 68(%rdx),%eax andl $0xffffffc0,%eax movl -4(%rsp),%edi + .cfi_undefined %rdi andl $0x3f,%edi xorl %eax,%edi movl %edi,-4(%rsp) ldmxcsr -4(%rsp) movq %rsi,%rax /* retval */ + .cfi_def_cfa %rdx,16 + .cfi_offset %rbx,8 + .cfi_offset %rbp,24 + .cfi_offset %r12,32 + .cfi_offset %r13,40 + .cfi_offset %r14,48 + .cfi_offset %r15,56 movq 0(%rdx),%rcx + .cfi_undefined %rcx + .cfi_return_column %rcx movq 8(%rdx),%rbx movq 16(%rdx),%rsp movq 24(%rdx),%rbp diff --git a/lib/libc/amd64/gen/sigsetjmp.S b/lib/libc/amd64/gen/sigsetjmp.S index ef90bc6..c264740 100644 --- a/lib/libc/amd64/gen/sigsetjmp.S +++ b/lib/libc/amd64/gen/sigsetjmp.S @@ -58,14 +58,22 @@ ENTRY(sigsetjmp) testl %esi,%esi jz 2f pushq %rdi + .cfi_adjust_cfa_offset -8 movq %rdi,%rcx + .cfi_undefined %rcx + .cfi_register %rdi,%rcx movq $1,%rdi /* SIG_BLOCK */ movq $0,%rsi /* (sigset_t*)set */ leaq 72(%rcx),%rdx /* 9,10 (sigset_t*)oset */ + .cfi_undefined %rdx /* stack is 16-byte aligned */ call PIC_PLT(CNAME(_sigprocmask)) popq %rdi + .cfi_adjust_cfa_offset 8 + .cfi_restore %rdi 2: movq %rdi,%rcx + .cfi_undefined %rcx + .cfi_register %rdi,%rcx movq 0(%rsp),%rdx /* retval */ movq %rdx, 0(%rcx) /* 0; retval */ movq %rbx, 8(%rcx) /* 1; rbx */ @@ -86,8 +94,14 @@ ENTRY(__siglongjmp) cmpl $0,88(%rdi) jz 2f movq %rdi,%rdx + .cfi_undefined %rdx + .cfi_register %rdi,%rdx pushq %rdi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rdi,-8 pushq %rsi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rsi,-16 movq $3,%rdi /* SIG_SETMASK */ leaq 72(%rdx),%rsi /* (sigset_t*)set */ movq $0,%rdx /* (sigset_t*)oset */ @@ -95,10 +109,23 @@ ENTRY(__siglongjmp) call PIC_PLT(CNAME(_sigprocmask)) addq $0x8,%rsp popq %rsi + .cfi_adjust_cfa_offset -8 + .cfi_restore %rsi popq %rdi /* jmpbuf */ + .cfi_adjust_cfa_offset -8 + .cfi_restore %rdi 2: movq %rdi,%rdx movq %rsi,%rax /* retval */ + .cfi_def_cfa %rdx,16 + .cfi_offset %rbx,8 + .cfi_offset %rbp,24 + .cfi_offset %r12,32 + .cfi_offset %r13,40 + .cfi_offset %r14,48 + .cfi_offset %r15,56 movq 0(%rdx),%rcx + .cfi_undefined %rcx + .cfi_return_column %rcx movq 8(%rdx),%rbx movq 16(%rdx),%rsp movq 24(%rdx),%rbp diff --git a/lib/libc/amd64/string/bcopy.S b/lib/libc/amd64/string/bcopy.S index cc38f47..378cb45 100644 --- a/lib/libc/amd64/string/bcopy.S +++ b/lib/libc/amd64/string/bcopy.S @@ -54,9 +54,12 @@ ENTRY(bcopy) movq %rdi,%rax /* return dst */ #else xchgq %rdi,%rsi + .cfi_register %rdi,%rsi + .cfi_register %rsi,%rdi #endif movq %rdx,%rcx movq %rdi,%r8 + .cfi_undefined %r8 subq %rsi,%r8 cmpq %rcx,%r8 /* overlapping? */ jb 1f @@ -64,6 +67,8 @@ ENTRY(bcopy) shrq $3,%rcx /* copy by words */ rep movsq + .cfi_undefined %rdi + .cfi_undefined %rsi movq %rdx,%rcx andq $7,%rcx /* any bytes left? */ rep @@ -71,7 +76,9 @@ ENTRY(bcopy) ret 1: addq %rcx,%rdi /* copy backwards. */ + .cfi_undefined %rdi addq %rcx,%rsi + .cfi_undefined %rsi std andq $7,%rcx /* any fractional bytes? */ decq %rdi diff --git a/lib/libc/amd64/string/bzero.S b/lib/libc/amd64/string/bzero.S index cf46a2a..e2acb56 100644 --- a/lib/libc/amd64/string/bzero.S +++ b/lib/libc/amd64/string/bzero.S @@ -27,6 +27,7 @@ ENTRY(bzero) negq %rcx andq $7,%rcx subq %rcx,%rsi + .cfi_undefined %rsi rep /* zero until word aligned */ stosb =20 diff --git a/lib/libc/amd64/string/memcmp.S b/lib/libc/amd64/string/memcmp.S index 66d64a0..a794238 100644 --- a/lib/libc/amd64/string/memcmp.S +++ b/lib/libc/amd64/string/memcmp.S @@ -17,6 +17,8 @@ ENTRY(memcmp) shrq $3,%rcx repe cmpsq + .cfi_undefined %rsi + .cfi_undefined %rdi jne L5 /* do we match so far? */ =20 movq %rdx,%rcx /* compare remainder by bytes */ diff --git a/lib/libc/amd64/string/memset.S b/lib/libc/amd64/string/memset.S index 84d1562..bec8654 100644 --- a/lib/libc/amd64/string/memset.S +++ b/lib/libc/amd64/string/memset.S @@ -16,6 +16,7 @@ ENTRY(memset) andq $0xff,%rax movq %rdx,%rcx movq %rdi,%r11 + .cfi_undefined %r11 =20 cld /* set fill direction forward */ =20 @@ -45,6 +46,7 @@ ENTRY(memset) movq %rdx,%rcx /* set until word aligned */ rep stosb + .cfi_undefined %rdi =20 movq %r8,%rcx shrq $3,%rcx /* set by words */ @@ -55,6 +57,7 @@ ENTRY(memset) andq $7,%rcx L1: rep stosb + .cfi_undefined %rdi movq %r11,%rax =20 ret diff --git a/lib/libc/amd64/string/stpcpy.S b/lib/libc/amd64/string/stpcpy.S index 52ac69c..95054dc 100644 --- a/lib/libc/amd64/string/stpcpy.S +++ b/lib/libc/amd64/string/stpcpy.S @@ -24,7 +24,9 @@ __FBSDID("$FreeBSD$"); ENTRY(stpcpy) __stpcpy: movabsq $0x0101010101010101,%r8 + .cfi_undefined %r8 movabsq $0x8080808080808080,%r9 + .cfi_undefined %r9 =20 /* * Align source to a word boundary. @@ -35,8 +37,10 @@ __stpcpy: je .Lword_aligned movb (%rsi),%dl incq %rsi + .cfi_undefined %rsi movb %dl,(%rdi) incq %rdi + .cfi_undefined %rdi testb %dl,%dl jne .Lalign movq %rdi,%rax @@ -51,6 +55,7 @@ __stpcpy: movq (%rsi),%rdx movq %rdx,%rcx addq $8,%rsi + .cfi_undefined %rsi subq %r8,%rcx testq %r9,%rcx je .Lloop @@ -64,6 +69,7 @@ __stpcpy: testb %dl,%dl /* 1st byte =3D=3D 0? */ je .Ldone incq %rdi + .cfi_undefined %rdi =20 shrq $8,%rdx movb %dl,(%rdi) diff --git a/lib/libc/amd64/string/strcat.S b/lib/libc/amd64/string/strcat.S index 7b5a1dd..daaaac1 100644 --- a/lib/libc/amd64/string/strcat.S +++ b/lib/libc/amd64/string/strcat.S @@ -33,6 +33,7 @@ ENTRY(strcat) .Lscan_loop: movq (%rdi),%rdx addq $8,%rdi + .cfi_undefined %rdi subq %r8,%rdx testq %r9,%rdx je .Lscan_loop @@ -91,6 +92,7 @@ ENTRY(strcat) je .Lcopy_aligned movb (%rsi),%dl incq %rsi + .cfi_undefined %rsi movb %dl,(%rdi) incq %rdi testb %dl,%dl @@ -101,10 +103,12 @@ ENTRY(strcat) .Lcopy_loop: movq %rdx,(%rdi) addq $8,%rdi + .cfi_undefined %rdi .Lcopy_aligned: movq (%rsi),%rdx movq %rdx,%rcx addq $8,%rsi + .cfi_undefined %rsi subq %r8,%rcx testq %r9,%rcx je .Lcopy_loop diff --git a/lib/libc/amd64/string/strcmp.S b/lib/libc/amd64/string/strcmp.S index 07009c1..2132187 100644 --- a/lib/libc/amd64/string/strcmp.S +++ b/lib/libc/amd64/string/strcmp.S @@ -20,8 +20,10 @@ ENTRY(strcmp) je .Ls1aligned movb (%rdi),%al incq %rdi + .cfi_undefined %rdi movb (%rsi),%dl incq %rsi + .cfi_undefined %rsi testb %al,%al je .Ldone cmpb %al,%dl diff --git a/lib/libc/amd64/sys/brk.S b/lib/libc/amd64/sys/brk.S index 4048ae6..76e6280 100644 --- a/lib/libc/amd64/sys/brk.S +++ b/lib/libc/amd64/sys/brk.S @@ -42,14 +42,18 @@ __FBSDID("$FreeBSD$"); .globl HIDENAME(minbrk) ENTRY(_brk) pushq %rdi + .cfi_adjust_cfa_offset 8 jmp ok END(_brk) =20 ENTRY(brk) pushq %rdi + .cfi_adjust_cfa_offset 8 movq %rdi,%rax + .cfi_undefined %rax #ifdef PIC movq PIC_GOT(HIDENAME(minbrk)),%rdx + .cfi_undefined %rdx cmpq %rax,(%rdx) #else cmpq %rax,HIDENAME(minbrk)(%rip) @@ -60,8 +64,10 @@ ENTRY(brk) #else movq HIDENAME(minbrk)(%rip),%rdi #endif + .cfi_undefined %rdi ok: movq $SYS_break,%rax + .cfi_undefined %rax KERNCALL jb err movq 0(%rsp),%rax @@ -73,9 +79,11 @@ ok: #endif movq $0,%rax popq %rdi + .cfi_adjust_cfa_offset -8 ret err: addq $8, %rsp + .cfi_adjust_cfa_offset -8 jmp HIDENAME(cerror) END(brk) =20 diff --git a/lib/libc/amd64/sys/cerror.S b/lib/libc/amd64/sys/cerror.S index d01cf4a..43032e4 100644 --- a/lib/libc/amd64/sys/cerror.S +++ b/lib/libc/amd64/sys/cerror.S @@ -48,12 +48,21 @@ __FBSDID("$FreeBSD$"); .globl CNAME(__error) .type CNAME(__error),@function HIDENAME(cerror): + .cfi_startproc pushq %rax + .cfi_adjust_cfa_offset 8 + .cfi_offset %rax,0 call PIC_PLT(CNAME(__error)) popq %rcx + .cfi_adjust_cfa_offset -8 + .cfi_undefined %rcx + .cfi_register %rax,%rcx movl %ecx,(%rax) movq $-1,%rax + .cfi_undefined %rax movq $-1,%rdx + .cfi_undefined %rdx ret + .cfi_endproc =20 .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/amd64/sys/exect.S b/lib/libc/amd64/sys/exect.S index 04a97ed..ce5e717 100644 --- a/lib/libc/amd64/sys/exect.S +++ b/lib/libc/amd64/sys/exect.S @@ -41,11 +41,17 @@ __FBSDID("$FreeBSD$"); =20 ENTRY(exect) movq $SYS_execve,%rax + .cfi_undefined %rax pushfq + .cfi_adjust_cfa_offset 8 popq %r8 + .cfi_adjust_cfa_offset -8 + .cfi_undefined %r8 orq $PSL_T,%r8 pushq %r8 + .cfi_adjust_cfa_offset 8 popfq + .cfi_adjust_cfa_offset -8 KERNCALL jmp HIDENAME(cerror) END(exect) diff --git a/lib/libc/amd64/sys/getcontext.S b/lib/libc/amd64/sys/getcontex= t.S index 1128796..94c894c 100644 --- a/lib/libc/amd64/sys/getcontext.S +++ b/lib/libc/amd64/sys/getcontext.S @@ -40,10 +40,22 @@ __FBSDID("$FreeBSD$"); .set getcontext,__sys_getcontext ENTRY(__sys_getcontext) movq (%rsp),%rsi /* save getcontext return address */ + .cfi_undefined %rsi mov $SYS_getcontext,%rax + .cfi_undefined %rax KERNCALL jb HIDENAME(cerror) addq $8,%rsp /* remove stale (setcontext) return address */ + /* + * The instruction above adjusted top of the stack so that the stack + * does not contain a return address anymore. But, due to the red + * zone existence, return address value right below the top of stack + * is non-volatile. Try to describe the trick to unwinder by claiming + * that the standard call frame is one long word below top of the + * stack. + */ + .cfi_adjust_cfa_offset 8 + .cfi_return_column %rsi jmp *%rsi /* restore return address */ END(__sys_getcontext) =20 diff --git a/lib/libc/amd64/sys/pipe.S b/lib/libc/amd64/sys/pipe.S index 8d089db..6eee962 100644 --- a/lib/libc/amd64/sys/pipe.S +++ b/lib/libc/amd64/sys/pipe.S @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$"); .set pipe,__sys_pipe ENTRY(__sys_pipe) mov $SYS_pipe,%rax + .cfi_undefined %rax KERNCALL jb HIDENAME(cerror) movl %eax,(%rdi) /* %rdi is preserved by syscall */ diff --git a/lib/libc/amd64/sys/ptrace.S b/lib/libc/amd64/sys/ptrace.S index 9c4628d..5dbde65 100644 --- a/lib/libc/amd64/sys/ptrace.S +++ b/lib/libc/amd64/sys/ptrace.S @@ -40,8 +40,10 @@ __FBSDID("$FreeBSD$"); =20 ENTRY(ptrace) xorl %eax,%eax + .cfi_undefined %rax #ifdef PIC movq PIC_GOT(CNAME(errno)),%r8 + .cfi_undefined %r8 movl %eax,(%r8) #else movl %eax,CNAME(errno)(%rip) diff --git a/lib/libc/amd64/sys/reboot.S b/lib/libc/amd64/sys/reboot.S index fd04ef4..57fa2df 100644 --- a/lib/libc/amd64/sys/reboot.S +++ b/lib/libc/amd64/sys/reboot.S @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$"); .set reboot,__sys_reboot ENTRY(__sys_reboot) mov $SYS_reboot,%rax + .cfi_undefined %rax KERNCALL jb HIDENAME(cerror) iretq diff --git a/lib/libc/amd64/sys/sbrk.S b/lib/libc/amd64/sys/sbrk.S index 0332aae..f0e3c6b 100644 --- a/lib/libc/amd64/sys/sbrk.S +++ b/lib/libc/amd64/sys/sbrk.S @@ -49,16 +49,22 @@ HIDENAME(curbrk): .quad CNAME(_end) =20 ENTRY(sbrk) pushq %rdi + .cfi_adjust_cfa_offset 8 movq %rdi,%rcx + .cfi_register %rdi,%rcx #ifdef PIC movq PIC_GOT(HIDENAME(curbrk)),%rdx + .cfi_undefined %rdx movq (%rdx),%rax + .cfi_undefined %rax #else movq HIDENAME(curbrk)(%rip),%rax + .cfi_undefined %rax #endif testq %rcx,%rcx jz back addq %rax,%rdi + .cfi_undefined %rdi mov $SYS_break,%eax KERNCALL jb err @@ -69,6 +75,7 @@ ENTRY(sbrk) movq HIDENAME(curbrk)(%rip),%rax #endif movq 0(%rsp), %rcx + .cfi_undefined %rcx #ifdef PIC addq %rcx,(%rdx) #else @@ -76,9 +83,11 @@ ENTRY(sbrk) #endif back: addq $8, %rsp + .cfi_adjust_cfa_offset -8 ret err: addq $8, %rsp + .cfi_adjust_cfa_offset -8 jmp HIDENAME(cerror) END(sbrk) =20 diff --git a/lib/libc/amd64/sys/setlogin.S b/lib/libc/amd64/sys/setlogin.S index a451491..86b220c 100644 --- a/lib/libc/amd64/sys/setlogin.S +++ b/lib/libc/amd64/sys/setlogin.S @@ -46,10 +46,12 @@ __FBSDID("$FreeBSD$"); .set setlogin,__sys_setlogin ENTRY(__sys_setlogin) mov $SYS_setlogin,%rax + .cfi_undefined %rax KERNCALL jb HIDENAME(cerror) #ifdef PIC movq PIC_GOT(CNAME(_logname_valid)),%rdx + .cfi_undefined %rdx movl $0,(%rdx) #else movl $0,CNAME(_logname_valid)(%rip) diff --git a/lib/libc/amd64/sys/vfork.S b/lib/libc/amd64/sys/vfork.S index 2afba58..c2673da 100644 --- a/lib/libc/amd64/sys/vfork.S +++ b/lib/libc/amd64/sys/vfork.S @@ -44,12 +44,18 @@ __FBSDID("$FreeBSD$"); .set vfork,__sys_vfork ENTRY(__sys_vfork) popq %rsi /* fetch return address (%rsi preserved) */ + /* See a comment in getcontext.S */ + .cfi_adjust_cfa_offset -8 + .cfi_undefined %rsi + .cfi_return_column %rsi mov $SYS_vfork,%rax + .cfi_undefined %rax KERNCALL jb 1f jmp *%rsi 1: pushq %rsi + .cfi_adjust_cfa_offset 8 jmp HIDENAME(cerror) END(__sys_vfork) =20 diff --git a/lib/libthr/arch/amd64/amd64/_umtx_op_err.S b/lib/libthr/arch/a= md64/amd64/_umtx_op_err.S index b54fe64..36d6cf4 100644 --- a/lib/libthr/arch/amd64/amd64/_umtx_op_err.S +++ b/lib/libthr/arch/amd64/amd64/_umtx_op_err.S @@ -29,10 +29,20 @@ #include #include =20 -#define RSYSCALL_ERR(x) ENTRY(__CONCAT(x, _err)); \ - mov __CONCAT($SYS_,x),%rax; KERNCALL; ret;=20 +#define RSYSCALL_ERR(x) \ + ENTRY(__CONCAT(x, _err)); \ + mov __CONCAT($SYS_,x),%rax; \ + .cfi_undefined %rax; \ + KERNCALL; \ + ret; \ + END(__CONCAT(x, _err)) =20 -#define KERNCALL movq %rcx, %r10; syscall +#define KERNCALL \ + movq %rcx,%r10; \ + .cfi_undefined %r10; \ + .cfi_register %rcx,%r10; \ + syscall; \ + .cfi_undefined %rax,%rdx =20 RSYSCALL_ERR(_umtx_op) =20 diff --git a/sys/amd64/include/asm.h b/sys/amd64/include/asm.h index 7efd642..75603ec 100644 --- a/sys/amd64/include/asm.h +++ b/sys/amd64/include/asm.h @@ -59,25 +59,37 @@ #define _START_ENTRY .text; .p2align 4,0x90 =20 #define _ENTRY(x) _START_ENTRY; \ - .globl CNAME(x); .type CNAME(x),@function; CNAME(x): + .globl CNAME(x); .type CNAME(x),@function; \ + CNAME(x): .cfi_startproc =20 #ifdef PROF -#define ALTENTRY(x) _ENTRY(x); \ - pushq %rbp; movq %rsp,%rbp; \ +#define ALTENTRY(x) _ENTRY(x); \ + pushq %rbp; \ + .cfi_adjust_cfa_offset 8; \ + .cfi_offset %rbp,0 \ + movq %rsp,%rbp; \ call PIC_PLT(HIDENAME(mcount)); \ - popq %rbp; \ + popq %rbp; \ + .cfi_adjust_cfa_offset -8; \ + .cfi_restore %rbp; \ jmp 9f -#define ENTRY(x) _ENTRY(x); \ - pushq %rbp; movq %rsp,%rbp; \ +#define ENTRY(x) _ENTRY(x); \ + pushq %rbp; \ + .cfi_adjust_cfa_offset 8; \ + .cfi_offset %rbp,0 \ + movq %rsp,%rbp; \ call PIC_PLT(HIDENAME(mcount)); \ - popq %rbp; \ + popq %rbp; \ + .cfi_adjust_cfa_offset -8; \ + .cfi_restore %rbp; \ 9: #else #define ALTENTRY(x) _ENTRY(x) #define ENTRY(x) _ENTRY(x) #endif =20 -#define END(x) .size x, . - x +#define END(x) .cfi_endproc; \ + .size x, . - x =20 #define RCSID(x) .text; .asciz x =20 --+y7rRxfO4bOZsSs1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBxnaUACgkQC3+MBN1Mb4jQygCg87K1V2LfE7UKv5xm+Pn8qx1G iNAAoJZj+vftlW4y42HycBsJn5yQ2Hy7 =Wbsk -----END PGP SIGNATURE----- --+y7rRxfO4bOZsSs1-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 15:23:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 840AC1065670; Sun, 7 Oct 2012 15:23:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA148FC19; Sun, 7 Oct 2012 15:23:24 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4123388oag.13 for ; Sun, 07 Oct 2012 08:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lLluG1U+9IWAA/VflQbstJIAp4sTqNX/0FqnQdxX9gU=; b=t5hRUUqIG0JghxFtohWYSHyZQvMiowh+jJYhKx1gggmjy3im19h2sKAG/eGZawaCeP npZAHcVnRN5+VviTwhtAiQjTQ0jxjObkR/8uWH0vpYo2NOysFKyesl4xbdIGUgb+UjUl fWyyeLXry+n1Uw4RtM884xIucClee91MMBtM8nQzqJ/Xv9/F48F8BOZake7UhRSsmufi jf8O3j4CLmO84fae0ys/06/hYPK2IC+gwgNP01j2m9/K37q98a2WTowEwq/LcxQ0gqbJ XsKNUtcDsAA5GD73Ijy2vcnlaGN2OUtuK2f6VvQrFJYu1AZxx6c4W2cocviLaiED7yMt sVGQ== MIME-Version: 1.0 Received: by 10.182.218.37 with SMTP id pd5mr11166709obc.24.1349623403573; Sun, 07 Oct 2012 08:23:23 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Sun, 7 Oct 2012 08:23:23 -0700 (PDT) In-Reply-To: <20121007150219.GA76853@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> Date: Sun, 7 Oct 2012 08:23:23 -0700 Message-ID: From: Garrett Cooper To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , current@freebsd.org Subject: Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 15:23:25 -0000 On Sun, Oct 7, 2012 at 8:02 AM, Luigi Rizzo wrote: > [subject changed due to the shift of topic] > > On Sun, Oct 07, 2012 at 07:08:54AM -0700, Adrian Chadd wrote: >> On 7 October 2012 03:43, Luigi Rizzo wrote: >> > >> > Good point, thanks for mentioning this: >> >> ew. ifconfig :-) >> >> > >> > Could be done, but I consider the ifconfig one of the ugliest >> > configuration mechanisms we have in FreeBSD so I'd rather not >> > contribute to that. >> >> Seconded; but compare to Linux which has mutiple different commands to >> do networking, as well as 'net'. :-) > > we do too -- we have arp, route, ifconfig, sysctl and possibly > more that i am not aware of. Some ipfw features are controlled > by sysctl, and there is code in ipfw that maps "ipfw do something" > into "sysctl net.inet.ipfw.do.something-under-another-name" > > I am not sure that a single frontend is the way to go. > > And I understand that there are opportunity reasons (importing > external code, compatibility with others, etc.) which suggested to > look at ifconfig as a general purpose frontend for interface > manipulation. > > Coming to 802.11 (and I am using it just as an example): > configuration of the various parameters is not too different from, > say, manipulating the various features that are available in modern > NICs: interrupt mitigation, queue parameters, multiqueue support, > RSS, and so on. In this area linux has ethtool, while we have > mostly device-specific sysctls. > > I'd love to have a device-independent mechanism to implement this. > I do not think we need to go through the definition of a new > ioctl/sockopt every time we find that a new parameter is > required/useful. > >> > ifieee80211 is even worse -- over 5000 lines of code, >> > 153 between commands and arguments, and 31 different parameters: >> >> I'd personally like to break these kinds of things out into libraries >> so other C code can use them. > > my point was that this type of configuration is rarely if > ever done outside setup or management scripts, at an incredibly > low rate and as such does not need a C API (which in case the > sysctl gives you). > >> I'm eventually going to do it to the net80211 code in ifconfig; maybe >> it's also worth doing to if_bridge for example. >> >> Doing configuration via sysctl can be hokey, especially when you use >> sysctl and sysfs to do things which change the sysctl/sysfs layout (by >> creating/destroying nodes as you change the configuration.) It's .. > > can you elaborate ? If i destroy an interface (or disable a function) > and kill a subtree, and this causes a subsequent configuration of the > non-existing parameter to fail, what is wrong with that ? > >> ew. >> >> Maybe for your bridge stuff its easy enough, but for something like >> net80211 where there's a lot of things to configure, doing it via >> sysctl would involve lots of parsing in the kernel.. and I like my >> kernels smaller. :-) > > Here too i kind of fail to see how much additional parsing you would > need in the kernel when using sysctl as opposed to ioctl(), so > an example would help. > Integers and strcmp do not require any parsing, > and some small functions to parse MAC/IP addresses or chanlist > arguments are not going to cause incredible bloat (and besides > i think they already exist in multiple versions in the various > userspace utilities). FWIW, I don't think that the problem is necessarily the fact that one should do it either via ioctl, kvm, sysctl, etc: having a library/set of interfaces as Adrian suggested would be indispensable for a number of groups that copy code from FreeBSD net utilities wholesale -- effectively forking it the code, which in turn becomes a burden to the project/company hacking on the code, and a loss to the community if it's not given back. It would also make FreeBSD adoption a whole lot easier for outside projects like net-snmp, as well as tools that should be more tightly integrated into base OSes for networking configuration and statistics, jail management, etc. If something isn't done to make these interfaces more usable in a generic manner and clean from the get-go, it doesn't matter what interface I'll be getting the information via. The BSD socket interfaces are extremely well thought out, but bits outside of struct sockaddr* (e.g. stuff in net/...) could be better documented (unfortunately the Unix Networking books are a bit long in the tooth, in part because the original author passed on :(..). My 2 cents for what little it may be worth, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 15:33:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CADD2106566C; Sun, 7 Oct 2012 15:33:41 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 823238FC18; Sun, 7 Oct 2012 15:33:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 099527300A; Sun, 7 Oct 2012 17:53:56 +0200 (CEST) Date: Sun, 7 Oct 2012 17:53:56 +0200 From: Luigi Rizzo To: Garrett Cooper Message-ID: <20121007155356.GA77558@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> 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: Adrian Chadd , current@freebsd.org Subject: Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 15:33:41 -0000 On Sun, Oct 07, 2012 at 08:23:23AM -0700, Garrett Cooper wrote: > On Sun, Oct 7, 2012 at 8:02 AM, Luigi Rizzo wrote: ... > FWIW, I don't think that the problem is necessarily the fact that one > should do it either via ioctl, kvm, sysctl, etc: having a library/set > of interfaces as Adrian suggested would be indispensable for a number > of groups that copy code from FreeBSD net utilities wholesale -- actually, the mechanism does matter, and exactly for the reason you mention. Access through sysctl is incredibly easy from both userspace and from a C application, because all the work is done in the kernel side, whereas other mechanisms (ioctl, i'd rather leave kvm apart as we really don't want that!) require the definition of a specific API (ioctl, structs) _and_ some amount of wrapping code in userspace. cheers luigi > effectively forking it the code, which in turn becomes a burden to the > project/company hacking on the code, and a loss to the community if > it's not given back. It would also make FreeBSD adoption a whole lot > easier for outside projects like net-snmp, as well as tools that > should be more tightly integrated into base OSes for networking > configuration and statistics, jail management, etc. > > If something isn't done to make these interfaces more usable in a > generic manner and clean from the get-go, it doesn't matter what > interface I'll be getting the information via. The BSD socket > interfaces are extremely well thought out, but bits outside of struct > sockaddr* (e.g. stuff in net/...) could be better documented > (unfortunately the Unix Networking books are a bit long in the tooth, > in part because the original author passed on :(..). > > My 2 cents for what little it may be worth, > -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 16:16:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3B44106566B for ; Sun, 7 Oct 2012 16:16:57 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0D88FC08 for ; Sun, 7 Oct 2012 16:16:57 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 64B5B60EE; Sun, 7 Oct 2012 12:16:56 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=HWyQtNQ6eWhR3dM1m2BGgHMkWWiRKIe7LfO5l56plhQ109LKBWa0kM4oXDexneY8v x1jvpnIerea4kVOWRmwxo5YYaM3aSafybskf3hywnAVQd20dmplwFFcDtMUtkTK Message-ID: <5071AAF6.9020009@protected-networks.net> Date: Sun, 07 Oct 2012 12:16:54 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: David Wolfskill References: <20121007151128.GL23688@albert.catwhisker.org> In-Reply-To: <20121007151128.GL23688@albert.catwhisker.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 16:16:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/07/12 11:11, David Wolfskill wrote: > I started seeing these messages spewed (to both console & > /var/log/messages) following an update from: > > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #697 241222M: Fri Oct 5 05:32:19 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > to > > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #698 241245M: Sat Oct 6 08:01:23 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > and I'm still seeing them as of > > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #699 241309M: Sun Oct 7 07:35:41 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > E.g.: > Oct 6 08:24:10 g1-227 kernel: wlan0: Ethernet address: 00:21:6a:26:34:c0 > Oct 6 08:24:10 g1-227 kernel: Expensive timeout(9) function: 0xc0c27520(0) 0.010540166 s > Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 10200 +1 on a laptop running with: re0: port 0x2000-0x20ff mem 0xf0700000-0xf0700fff,0xf0200000-0xf0203fff irq 17 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:0a:cd:1d:30:a2 I thought it may have had something to do with a VirtualBox module, so I recompiled that too .. no joy :-( imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBxqvYACgkQQv9rrgRC1JJs9ACgoujiYzItMOIp1GBE8HX0L0nv O5YAmwY/ooxzVXIg1W9iiTtrfLHHrLO8 =pA4D -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 16:17:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB5FC106578E; Sun, 7 Oct 2012 16:17:15 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B42948FC0C; Sun, 7 Oct 2012 16:17:10 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q97GH4ep014714; Sun, 7 Oct 2012 10:17:04 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q97GGfM0078240; Sun, 7 Oct 2012 10:16:41 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Luigi Rizzo In-Reply-To: <20121007155356.GA77558@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> <20121007155356.GA77558@onelab2.iet.unipi.it> Content-Type: text/plain; charset="us-ascii" Date: Sun, 07 Oct 2012 10:16:40 -0600 Message-ID: <1349626600.1112.30.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Adrian Chadd , current@freebsd.org Subject: Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 16:17:15 -0000 On Sun, 2012-10-07 at 17:53 +0200, Luigi Rizzo wrote: > Access through sysctl is incredibly easy from both userspace and > from a C application, because all the work is done in the kernel > side, whereas other mechanisms (ioctl, i'd rather leave kvm apart > as we really don't want that!) require the definition of a specific > API (ioctl, structs) _and_ some amount of wrapping code in userspace. > > cheers > luigi A potential problem with sysctl is its "one thing at a time" nature. When you pack up a bunch of related data into a structure and hand it off to an implementation, that implementation can pretty easily make sure that all the data related to the config request is sane. If you have to make a series of sysctl calls to achieve some complex config task, what happens when you're 2/3 of the way through the series and a call fails? Who backs out the partial config that got accomplished? If you go too far down this path you end up with something that looks a lot like the unmitigated mess which is the SNMP control API. -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:03:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9888A106564A for ; Sun, 7 Oct 2012 17:03:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 560408FC12 for ; Sun, 7 Oct 2012 17:03:05 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4179612oag.13 for ; Sun, 07 Oct 2012 10:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iRSEcWQZ3RcgP0M9w4mWr7rU9vK+nFbQ80IchReDULU=; b=mGXnLy4f8i07FWerHFvinS2AJynU6U0Uq+nDbchaAjJ3eIhPhTlcZtdel7AnuUqxri xeXrnmKrbePtbfL1sL5Va+I7z3wz5aYE6aPtmTS2ezdsZZJRnOSVhfAWzLZgGOXBSIWX 0qpWs+2dbGsYDDlpk/VdbHZ3osUSOQeLS1yNRsSs6nRlU/uGZ9I0+ULvUNlvBhU6ifZG 9lgD90b2EO8gmVgqVLudHFwG2n80WWwHWspFrvDY7k8J8PTwmNqd+L931HwBzfzAa2gf cWyem6rbxECqJh1tup5rhtlwvnwnXq0GTdZ3ci3rNjDGw183CbzP9xeM4xKi2FbWmVaG PlYQ== MIME-Version: 1.0 Received: by 10.60.170.15 with SMTP id ai15mr3021593oec.62.1349629384146; Sun, 07 Oct 2012 10:03:04 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Sun, 7 Oct 2012 10:03:04 -0700 (PDT) In-Reply-To: <5071AAF6.9020009@protected-networks.net> References: <20121007151128.GL23688@albert.catwhisker.org> <5071AAF6.9020009@protected-networks.net> Date: Sun, 7 Oct 2012 10:03:04 -0700 Message-ID: From: Garrett Cooper To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:03:05 -0000 On Sun, Oct 7, 2012 at 9:16 AM, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/07/12 11:11, David Wolfskill wrote: >> I started seeing these messages spewed (to both console & >> /var/log/messages) following an update from: >> >> FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #697 241222M: Fri Oct 5 05:32:19 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 >> >> to >> >> FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #698 241245M: Sat Oct 6 08:01:23 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 >> >> and I'm still seeing them as of >> >> FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #699 241309M: Sun Oct 7 07:35:41 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 >> >> E.g.: >> Oct 6 08:24:10 g1-227 kernel: wlan0: Ethernet address: 00:21:6a:26:34:c0 >> Oct 6 08:24:10 g1-227 kernel: Expensive timeout(9) function: 0xc0c27520(0) 0.010540166 s >> Oct 6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 10200 > > +1 on a laptop running with: > > re0: port > 0x2000-0x20ff mem 0xf0700000-0xf0700fff,0xf0200000-0xf0203fff irq 17 at > device 0.0 on pci3 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x28000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 00:0a:cd:1d:30:a2 > > I thought it may have had something to do with a VirtualBox module, so I > recompiled that too .. no joy :-( Maybe these revisions had something to do with it... (r241245 is more likely)? ------------------------------------------------------------------------ r241245 | glebius | 2012-10-06 03:02:11 -0700 (Sat, 06 Oct 2012) | 19 lines A step in resolving mess with byte ordering for AF_INET. After this change: - All packets in NETISR_IP queue are in net byte order. - ip_input() is entered in net byte order and converts packet to host byte order right _after_ processing pfil(9) hooks. - ip_output() is entered in host byte order and converts packet to net byte order right _before_ processing pfil(9) hooks. - ip_fragment() accepts and emits packet in net byte order. - ip_forward(), ip_mloopback() use host byte order (untouched actually). - ip_fastforward() no longer modifies packet at all (except ip_ttl). - Swapping of byte order there and back removed from the following modules: pf(4), ipfw(4), enc(4), if_bridge(4). - Swapping of byte order added to ipfilter(4), based on __FreeBSD_version - __FreeBSD_version bumped. - pfil(9) manual page updated. Reviewed by: ray, luigi, eri, melifaro Tested by: glebius (LE), ray (BE) ------------------------------------------------------------------------ r241244 | glebius | 2012-10-06 00:06:57 -0700 (Sat, 06 Oct 2012) | 5 lines The pfil(9) layer guarantees us presence of the protocol header, so remove extra check, that is always false. P.S. Also, goto there lead to unlocking a not locked rwlock. ------------------------------------------------------------------------ Did you rebuild all of your modules, and (for David) are you running any firmware blobs with your wireless NIC? Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:05:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1D4F106564A; Sun, 7 Oct 2012 17:05:25 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36A5D8FC12; Sun, 7 Oct 2012 17:05:25 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id y23so1552414qad.13 for ; Sun, 07 Oct 2012 10:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=dKIpYVxTb7X1/hPg0cDZziqu7SY5ccfc1fDa2oUG+fA=; b=nUkQ5p1mkVql+2GFPiGLEt6M0eRWSgeU/uaOqVGp+CRUParnSzqMt2PL5P/L7QjO1H zuoYejQv0At5uKcEyTBhzkp+/YsiCKo3+fwE7li+80Nvhj9ZKjFpwnKgDXKxbYL+jlJI hG/rusxSXCVdqvKsBmRKfx+uyrpuWdDcFfX56zmtFRmUD7BB8wswWEJB7Ruw3wbSY3z7 3XSIwTX5fPagtkG+IijCUfzzmCtUjuq3eGmwZzH67rqRcOoY39O+w4p76GsOhK8oqNQV VCkZ9iemJnFs2MkKkpDMUMbgU4msOi6l07OHrR4Kx6/wiO+W4sT95ZjOaO71ZganLl4R jjXg== Received: by 10.224.180.7 with SMTP id bs7mr26273659qab.37.1349629524479; Sun, 07 Oct 2012 10:05:24 -0700 (PDT) Received: from narn.knownspace (pool-108-48-127-15.washdc.fios.verizon.net. [108.48.127.15]) by mx.google.com with ESMTPS id dz9sm15713661qab.6.2012.10.07.10.05.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 10:05:24 -0700 (PDT) Date: Sun, 7 Oct 2012 13:05:21 -0400 From: Justin Hibbits To: Ian Lepore Message-ID: <20121007130521.76dc7e5e@narn.knownspace> In-Reply-To: <1349626600.1112.30.camel@revolution.hippie.lan> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> <20121007155356.GA77558@onelab2.iet.unipi.it> <1349626600.1112.30.camel@revolution.hippie.lan> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; powerpc-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Adrian Chadd , Luigi Rizzo , current@freebsd.org Subject: Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:05:25 -0000 On Sun, 07 Oct 2012 10:16:40 -0600 Ian Lepore wrote: > On Sun, 2012-10-07 at 17:53 +0200, Luigi Rizzo wrote: > > Access through sysctl is incredibly easy from both userspace and > > from a C application, because all the work is done in the kernel > > side, whereas other mechanisms (ioctl, i'd rather leave kvm apart > > as we really don't want that!) require the definition of a specific > > API (ioctl, structs) _and_ some amount of wrapping code in > > userspace. > > > > cheers > > luigi > > A potential problem with sysctl is its "one thing at a time" nature. > When you pack up a bunch of related data into a structure and hand it > off to an implementation, that implementation can pretty easily make > sure that all the data related to the config request is sane. If you > have to make a series of sysctl calls to achieve some complex config > task, what happens when you're 2/3 of the way through the series and a > call fails? Who backs out the partial config that got accomplished? > > If you go too far down this path you end up with something that looks > a lot like the unmitigated mess which is the SNMP control API. > > -- Ian I agree with Ian here. As messy as ioctl+structs are from a user standpoint, they're the easiest way to guarantee atomic configuration changes. - Justin From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:43:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA730106566C for ; Sun, 7 Oct 2012 17:43:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 789E08FC0C for ; Sun, 7 Oct 2012 17:43:32 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q97HhVc3002657; Sun, 7 Oct 2012 10:43:31 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q97HhVJV002656; Sun, 7 Oct 2012 10:43:31 -0700 (PDT) (envelope-from david) Date: Sun, 7 Oct 2012 10:43:31 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20121007174331.GA2583@albert.catwhisker.org> References: <20121007151128.GL23688@albert.catwhisker.org> <5071AAF6.9020009@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:43:32 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 07, 2012 at 10:03:04AM -0700, Garrett Cooper wrote: > ... > Maybe these revisions had something to do with it... (r241245 is > more likely)? >=20 > ------------------------------------------------------------------------ > r241245 | glebius | 2012-10-06 03:02:11 -0700 (Sat, 06 Oct 2012) | 19 lin= es >=20 > A step in resolving mess with byte ordering for AF_INET. After this cha= nge: > ...=20 > ------------------------------------------------------------------------ > r241244 | glebius | 2012-10-06 00:06:57 -0700 (Sat, 06 Oct 2012) | 5 lines >=20 > The pfil(9) layer guarantees us presence of the protocol header, > so remove extra check, that is always false. > ... =20 > Did you rebuild all of your modules, and (for David) are you > running any firmware blobs with your wireless NIC? Yes; when I update, my changes from the process in src/UPDATING generally augment what's there (e.g., to clear /usr/include & /usr/share/man before the make installworld). And the NIC that's in use (at home -- and most other places) on the laptop is iwn(4), so yes, there is a firmware blob: 4 1 0xc138a000 54e38 iwn5000fw.ko (Well, that particular line is from kldstat when it's running stable/9; I just checked the head slice, and the blob had been rebuilt (based on mtime), and has contents different from the contents in stable/9: g1-227(9.1-P)[3] md5 /{,S4/}boot/kernel/iwn5000fw.ko MD5 (/boot/kernel/iwn5000fw.ko) =3D 8f98e8f28c70fe801c73aec4f717973f MD5 (/S4/boot/kernel/iwn5000fw.ko) =3D a0150e03bfd307595ab37b0924252844 g1-227(9.1-P)[4] ls -lT !$ ls -lT /{,S4/}boot/kernel/iwn5000fw.ko -r-xr-xr-x 1 root wheel 345868 Oct 7 07:48:46 2012 /S4/boot/kernel/iwn5= 000fw.ko -r-xr-xr-x 1 root wheel 344416 Oct 7 04:51:11 2012 /boot/kernel/iwn5000= fw.ko g1-227(9.1-P)[5]=20 FWIW.) As noted, the message does not appear to be associated with (other) unwanted behavior, so I wouldn't consider this of earth-shattering importance. It just seemed rather odd, and I got to wondering if the developer who committed the change had intended this result. And if said result was actually of use to anyone. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBxv0IACgkQmprOCmdXAD3L/QCff6zeAwusPRHRTB7ZAtzNL/F3 whwAnisKKAdibkNJ5qEuk8TiH2hduH+1 =AkiV -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 15:28:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E4991065670 for ; Sun, 7 Oct 2012 15:28:18 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 5692A8FC0C for ; Sun, 7 Oct 2012 15:28:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:From:Date; bh=ru4Q+DQbpe5yelnI18aWP9fYw8A4C6JT31r3csTcWLc=; b=kMBKhdxsryMOQcWam5ZleMifKFhyOcgEzuKnWMn0OhBlL0AVwEkCWj4gOyHlN/8cPD1qZCAzM4UVJ2VvmEGRbrV4ex8gf6yRfgi6r6/C4DTC6yVR92ScpFHuJH0/bXFoW4ZNSZfETPe8dlmnwMIFv7nKUoDJzjhNT0iM0VCQmwc=; Received: from iglou1.iglou.com ([192.107.41.3]:62586 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TKsm2-00018E-UJ by authid with igloumta_auth for current@freebsd.org; Sun, 07 Oct 2012 11:28:10 -0400 Received: from shell1.iglou.com ([192.107.41.17]:57682 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TKsm1-0005zU-MZ; Sun, 07 Oct 2012 11:28:09 -0400 Date: Sun, 7 Oct 2012 11:28:09 -0400 (EDT) From: Darrel X-X-Sender: levitch@shell1 To: Peter Jeremy In-Reply-To: <20121007015251.GB22291@server.rulingia.com> Message-ID: References: <20121007015251.GB22291@server.rulingia.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Sun, 07 Oct 2012 17:48:44 +0000 Cc: Sergey Kandaurov , current@freebsd.org Subject: Re: memory warnings r240891 | dmesgg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 15:28:18 -0000 >>> warning: total configured swap (2621440 pages) exceeds maximum >>> recommended amount (1852656 pages). > ... >> This is because kernel needs some memory to manage swap too. >> Currently for amd64 this roughly reduces to the following rule >> (My apologies in advance for the extra simplification): >> >> 100MB RAM per 800MB swap space. > > That is oversimplified to the point of being wrong. As of HEAD > r239255 and 9-stable r240097, there's no longer a limit on amd64. The > limit is still required on 32-bit architectures due to the limited KVA > available. > The original poster; i.e., me, copied the error message directly from amd64 running r240891. Here is some information after /etc/fstab swap was left untouched and zfs swap was reduced: (11:14) dmesg | grep recommended warning: total configured swap (1854464 pages) exceeds maximum recommended amount (1852656 pages). (11:19) swapinfo -h Device 1K-blocks Used Avail Capacity /dev/zvol/bigD/swap 1126400 94M 1G 9% /dev/gpt/swap0.eli 3145728 93M 2.9G 3% /dev/gpt/swap1.eli 3145728 94M 2.9G 3% Total 7417856 282M 6.8G 4% I guess that we are seeing some swap actually in use now because buildkernel is running; i.e., > r241254. > The actual KVA requirements (RAM is only allocated when the swap space > is actually used) is about 5MB KVA per 1GB swap. The default swzone > for i386 was 32MiB - which is sufficient for ~7GB swap (the 1852656 > pages reported above) and was increased to 34.5MB for i386 in r239730 > to support ~8GB swap (this is also in r240097). (It's all approximate > because of the way swap space is allocated using struct swblock). > > See the thread starting > http://lists.freebsd.org/pipermail/freebsd-current/2012-August/035839.html > for more details. > Interesting. Yet from my first reading it seems like the limit was actually a warning and the warning still exists in amd64. I wonder if there is to run other than swapinfo, to actually see if swapinfo is correct in reporting that the swap in use is actually identical in size from each disk of the mirror and also 94M precisely from zfs swap? Thank you, Darrel From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:50:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AE5E1065672; Sun, 7 Oct 2012 17:50:52 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E67008FC23; Sun, 7 Oct 2012 17:50:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 498537300B; Sun, 7 Oct 2012 20:11:00 +0200 (CEST) Date: Sun, 7 Oct 2012 20:11:00 +0200 From: Luigi Rizzo To: Justin Hibbits Message-ID: <20121007181100.GA79447@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> <20121007155356.GA77558@onelab2.iet.unipi.it> <1349626600.1112.30.camel@revolution.hippie.lan> <20121007130521.76dc7e5e@narn.knownspace> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121007130521.76dc7e5e@narn.knownspace> User-Agent: Mutt/1.4.2.3i Cc: Garrett Cooper , Ian Lepore , Adrian Chadd , current@freebsd.org Subject: Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:50:52 -0000 On Sun, Oct 07, 2012 at 01:05:21PM -0400, Justin Hibbits wrote: > On Sun, 07 Oct 2012 10:16:40 -0600 > Ian Lepore wrote: > > > On Sun, 2012-10-07 at 17:53 +0200, Luigi Rizzo wrote: > > > Access through sysctl is incredibly easy from both userspace and > > > from a C application, because all the work is done in the kernel > > > side, whereas other mechanisms (ioctl, i'd rather leave kvm apart > > > as we really don't want that!) require the definition of a specific > > > API (ioctl, structs) _and_ some amount of wrapping code in > > > userspace. > > > > > > cheers > > > luigi > > > > A potential problem with sysctl is its "one thing at a time" nature. > > When you pack up a bunch of related data into a structure and hand it > > off to an implementation, that implementation can pretty easily make > > sure that all the data related to the config request is sane. If you > > have to make a series of sysctl calls to achieve some complex config > > task, what happens when you're 2/3 of the way through the series and a > > call fails? Who backs out the partial config that got accomplished? > > > > If you go too far down this path you end up with something that looks > > a lot like the unmitigated mess which is the SNMP control API. > > > > -- Ian > > I agree with Ian here. As messy as ioctl+structs are from a user > standpoint, they're the easiest way to guarantee atomic configuration > changes. Not a single function in ifbridge.c uses it (I have checked), and very likely the same happens for 802.11. sys/net80211/ieee80211_ioctl.h contains over 100 #define's for various subfunctions for the ioctl(s, SIOCS80211, &ireq) which are issued one at a time with no atomicity requirement. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:51:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EEAD1065674 for ; Sun, 7 Oct 2012 17:51:30 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 216838FC1B for ; Sun, 7 Oct 2012 17:51:30 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 614D360EE; Sun, 7 Oct 2012 13:51:22 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=KOOsJI0e2ZaEkt7ZnvwTIbmwnXAaW0kPvoivBID+cbYRgE/exFp3YW2MeBkH6CGzZ Ak+bowbLSAjlwK+MkqwjtyeJcqrlOn/8z/vzy7LLNyebTlAn/8AWHrEgQReOneW Message-ID: <5071C118.40302@protected-networks.net> Date: Sun, 07 Oct 2012 13:51:20 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Garrett Cooper References: <20121007151128.GL23688@albert.catwhisker.org> <5071AAF6.9020009@protected-networks.net> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:51:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/07/12 13:03, Garrett Cooper wrote: > Maybe these revisions had something to do with it... (r241245 is > more likely)? I reverted r241245 and the messages went away, > Did you rebuild all of your modules, and (for David) are you > running any firmware blobs with your wireless NIC? I always rebuild modules (system and ports) along with a new kernel, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBxwRgACgkQQv9rrgRC1JKNSACcCRivDwnKDuXsICL1f+Lxlq12 YWsAoKk0j6JfVVxA7K7In+4BIwaeLhc2 =AXZS -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:51:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A13251065670 for ; Sun, 7 Oct 2012 17:51:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAFB8FC08 for ; Sun, 7 Oct 2012 17:51:33 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4206687oag.13 for ; Sun, 07 Oct 2012 10:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4NnUfXivX6LfahrXx52fh66p2eXwXvobzzXCyNrN9g8=; b=CbO+JJy0woyl48AXBAinFSZBFkv01wFdj1m07AiwnLVBU4PBcAVgIckuupuEPG5zKX n5TTnqb2wjCYrrYAEGqZ5+/EhSgvqFulr5DBg5XrCxmDTgMCJBunp1No6Huc/e2TCbxS mT1SnnbAWYJ+LGIRBxg5QbC65WHT8IzGXfkVe+0qVPV6iF+xmJiPnVTnwYt0TEusqVOF n4/40yIQrrAfZ8TM7rwiLOm6RRntjsRUleKudzOfaR55aoxz/dVJ02yp+hS4zxymuYuN gSvxoTTU6M1wHJTyHfWXVoTAmHdT7SuwuJXEU3DW08vqtyT1AH9nmSTSbZR9GVBAotG8 ap7w== MIME-Version: 1.0 Received: by 10.182.144.70 with SMTP id sk6mr5941042obb.67.1349632292853; Sun, 07 Oct 2012 10:51:32 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Sun, 7 Oct 2012 10:51:32 -0700 (PDT) In-Reply-To: <20121007174331.GA2583@albert.catwhisker.org> References: <20121007151128.GL23688@albert.catwhisker.org> <5071AAF6.9020009@protected-networks.net> <20121007174331.GA2583@albert.catwhisker.org> Date: Sun, 7 Oct 2012 10:51:32 -0700 Message-ID: From: Garrett Cooper To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:51:33 -0000 On Sun, Oct 7, 2012 at 10:43 AM, David Wolfskill wrote: > On Sun, Oct 07, 2012 at 10:03:04AM -0700, Garrett Cooper wrote: >> ... >> Maybe these revisions had something to do with it... (r241245 is >> more likely)? >> >> ------------------------------------------------------------------------ >> r241245 | glebius | 2012-10-06 03:02:11 -0700 (Sat, 06 Oct 2012) | 19 lines >> >> A step in resolving mess with byte ordering for AF_INET. After this change: >> ... >> ------------------------------------------------------------------------ >> r241244 | glebius | 2012-10-06 00:06:57 -0700 (Sat, 06 Oct 2012) | 5 lines >> >> The pfil(9) layer guarantees us presence of the protocol header, >> so remove extra check, that is always false. >> ... > >> Did you rebuild all of your modules, and (for David) are you >> running any firmware blobs with your wireless NIC? > > Yes; when I update, my changes from the process in src/UPDATING > generally augment what's there (e.g., to clear /usr/include & > /usr/share/man before the make installworld). > > And the NIC that's in use (at home -- and most other places) on the > laptop is iwn(4), so yes, there is a firmware blob: > > 4 1 0xc138a000 54e38 iwn5000fw.ko > > (Well, that particular line is from kldstat when it's running stable/9; > I just checked the head slice, and the blob had been rebuilt (based on > mtime), and has contents different from the contents in stable/9: > > g1-227(9.1-P)[3] md5 /{,S4/}boot/kernel/iwn5000fw.ko > MD5 (/boot/kernel/iwn5000fw.ko) = 8f98e8f28c70fe801c73aec4f717973f > MD5 (/S4/boot/kernel/iwn5000fw.ko) = a0150e03bfd307595ab37b0924252844 > g1-227(9.1-P)[4] ls -lT !$ > ls -lT /{,S4/}boot/kernel/iwn5000fw.ko > -r-xr-xr-x 1 root wheel 345868 Oct 7 07:48:46 2012 /S4/boot/kernel/iwn5000fw.ko > -r-xr-xr-x 1 root wheel 344416 Oct 7 04:51:11 2012 /boot/kernel/iwn5000fw.ko > g1-227(9.1-P)[5] > > FWIW.) > > As noted, the message does not appear to be associated with (other) > unwanted behavior, so I wouldn't consider this of earth-shattering > importance. It just seemed rather odd, and I got to wondering if > the developer who committed the change had intended this result. > And if said result was actually of use to anyone. :-} Given that the issue is present on both your machine and Michael's, it's unlikely that it's firmware related (unless re(4) is doing something hacktacularly awesome!), but I just wanted to gather all the facts before something's brought up to glebius@, if the issue is indeed one of the two commits (or both) mentioned above. Could you guys please try reverting one or both of the commits to see if the issue goes away? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:52:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3E73106595F; Sun, 7 Oct 2012 17:52:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6003A8FC12; Sun, 7 Oct 2012 17:52:14 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so4139153obb.13 for ; Sun, 07 Oct 2012 10:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EXx3mdf89jIs918i4J6NS4ERGydj127iJqZdgtYRqlk=; b=avQvzUsOiqIMeJQGKPEs4WmtLAz58ZVGyOzwLeBUUu7F+fZsYHLig+05ipGA86sgO+ WOUeDth2AhJoz/05hIhAyTmwsPneO4ohbeszXsTBZwj6OvoaqwA4sb0z63b379b175w0 2R63+ohb3hJXTclX3pAKtgTki9AjcKoTGVcfQ1YJz1rDiyDoL9FEbShQK+XbMWvfmhNM QoSmWJMX6BiIFoXUEbwD2PWwAlL5924+IgSNbiIsdT8Z0yfw0MUJl+gJQLbv8iyNg1Au I5dVOzIiEJi9vZHi/4gsjAID2ZIioF3sm8ywuCsx2TKuwQXtFafBqYNqgTGWu+kKLwdL a1tA== MIME-Version: 1.0 Received: by 10.60.11.162 with SMTP id r2mr11161036oeb.114.1349632333731; Sun, 07 Oct 2012 10:52:13 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Sun, 7 Oct 2012 10:52:13 -0700 (PDT) In-Reply-To: <5071C118.40302@protected-networks.net> References: <20121007151128.GL23688@albert.catwhisker.org> <5071AAF6.9020009@protected-networks.net> <5071C118.40302@protected-networks.net> Date: Sun, 7 Oct 2012 10:52:13 -0700 Message-ID: From: Garrett Cooper To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: Gleb Smirnoff , current@freebsd.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:52:14 -0000 On Sun, Oct 7, 2012 at 10:51 AM, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/07/12 13:03, Garrett Cooper wrote: >> Maybe these revisions had something to do with it... (r241245 is >> more likely)? > > I reverted r241245 and the messages went away, > >> Did you rebuild all of your modules, and (for David) are you >> running any firmware blobs with your wireless NIC? > > I always rebuild modules (system and ports) along with a new kernel, Gleb CCed then. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 19:11:37 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C10D106566B for ; Sun, 7 Oct 2012 19:11:37 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 04B1E8FC12 for ; Sun, 7 Oct 2012 19:11:36 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q97JBTmK063824; Sun, 7 Oct 2012 23:11:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q97JBTdv063823; Sun, 7 Oct 2012 23:11:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 7 Oct 2012 23:11:29 +0400 From: Gleb Smirnoff To: Michael Butler Message-ID: <20121007191129.GJ34622@FreeBSD.org> References: <20121007151128.GL23688@albert.catwhisker.org> <5071AAF6.9020009@protected-networks.net> <5071C118.40302@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <5071C118.40302@protected-networks.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , current@FreeBSD.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 19:11:37 -0000 On Sun, Oct 07, 2012 at 01:51:20PM -0400, Michael Butler wrote: M> On 10/07/12 13:03, Garrett Cooper wrote: M> > Maybe these revisions had something to do with it... (r241245 is M> > more likely)? M> M> I reverted r241245 and the messages went away, I'll handle that. Sorry for breakage. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 19:32:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85C3B106566C; Sun, 7 Oct 2012 19:32:01 +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 E2A208FC16; Sun, 7 Oct 2012 19:32:00 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q97JDeSe091043 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 7 Oct 2012 12:13:41 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5071D464.9090208@freebsd.org> Date: Sun, 07 Oct 2012 12:13:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> In-Reply-To: <20121007150219.GA76853@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , current@freebsd.org Subject: Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 19:32:01 -0000 On 10/7/12 8:02 AM, Luigi Rizzo wrote: > Coming to 802.11 (and I am using it just as an example): > configuration of the various parameters is not too different from, > say, manipulating the various features that are available in modern > NICs: interrupt mitigation, queue parameters, multiqueue support, > RSS, and so on. In this area linux has ethtool, while we have > mostly device-specific sysctls. > > I'd love to have a device-independent mechanism to implement this. > I do not think we need to go through the definition of a new > ioctl/sockopt every time we find that a new parameter is > required/useful. this reminds me of the reason that we implemented a text based config mechanism for netgraph. A design goal was "you should never need a new executable in /sbin to configure a new netgraph node". no matter what the node is, you should be able to configure it from /sbin/ngctl. In a very loose description, you could say that the base netgraph module includes a parser that takes a grammar description that comes with each module. It knows how to convert arbitrary text config messages for a given module and convert them into the strict binary messages that are passed around and use in the netgraph nodes themselves. Could probably do with some polishing after 14 years, but as far as I know not a line of that code has been changed, and we now have over 50 netgraph node types. [...] > can you elaborate ? If i destroy an interface (or disable a > function) and kill a subtree, and this causes a subsequent > configuration of the non-existing parameter to fail, what is wrong > with that ? >> ew. >> >> Maybe for your bridge stuff its easy enough, but for something like >> net80211 where there's a lot of things to configure, doing it via >> sysctl would involve lots of parsing in the kernel.. and I like my >> kernels smaller. :-) > Here too i kind of fail to see how much additional parsing you would > need in the kernel when using sysctl as opposed to ioctl(), so > an example would help. > Integers and strcmp do not require any parsing, > and some small functions to parse MAC/IP addresses or chanlist > arguments are not going to cause incredible bloat (and besides > i think they already exist in multiple versions in the various > userspace utilities). > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 19:39:49 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C97CF1065672 for ; Sun, 7 Oct 2012 19:39:49 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 4340D8FC08 for ; Sun, 7 Oct 2012 19:39:49 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q97JdfPS063946; Sun, 7 Oct 2012 23:39:41 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q97JdfJB063945; Sun, 7 Oct 2012 23:39:41 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 7 Oct 2012 23:39:41 +0400 From: Gleb Smirnoff To: David Wolfskill , Michael Butler Message-ID: <20121007193941.GK34622@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <5071C118.40302@protected-networks.net> <20121007174331.GA2583@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , current@FreeBSD.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 19:39:49 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=koi8-r Content-Disposition: inline David and Michael, can you please build a kernel with attached patch and options KDB, and report what's the trace is. Unfortunately my iwn(4) is running on amd64, so I can reproduce exactly your case. -- Totus tuus, Glebius. --A6N2fC+uXW/VQSAv Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="in_cksum.backtrace.diff" Index: i386/i386/in_cksum.c =================================================================== --- i386/i386/in_cksum.c (revision 241328) +++ i386/i386/in_cksum.c (working copy) @@ -36,6 +36,7 @@ #include #include #include +#include #include #include @@ -204,6 +205,7 @@ caddr_t addr; union q_util q_util; union l_util l_util; + static int once = 0; len -= skip; for (; skip && m; m = m->m_next) { @@ -477,8 +479,12 @@ su.c[0] = *(char *)w; } - if (len) + if (len) { printf("%s: out of data by %d\n", __func__, len); + if (once == 0) + kdb_backtrace(); + once = 1; + } if (mlen == -1) { /* The last mbuf has odd # of bytes. Follow the standard (the odd byte is shifted left by 8 bits) */ --A6N2fC+uXW/VQSAv-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 21:55:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12B0C106566B; Sun, 7 Oct 2012 21:55:19 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id BA24A8FC16; Sun, 7 Oct 2012 21:55:18 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TKyoZ-003yXJ-6o>; Sun, 07 Oct 2012 23:55:11 +0200 Received: from e178018103.adsl.alicedsl.de ([85.178.18.103] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TKyoZ-0012eD-3C>; Sun, 07 Oct 2012 23:55:11 +0200 Message-ID: <5071FA38.5010705@zedat.fu-berlin.de> Date: Sun, 07 Oct 2012 23:55:04 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <20121007152005.GX35915@deviant.kiev.zoral.com.ua> In-Reply-To: <20121007152005.GX35915@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F65809845F6A9E48F236FF2" X-Originating-IP: 85.178.18.103 Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: Unwind annotations for the libc and libthr asm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 21:55:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F65809845F6A9E48F236FF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 10/07/12 17:20, schrieb Konstantin Belousov: > Please find below the patch to add the unwind annotations for the libc > and libthr assembler routines on amd64. The change shall have no impact= > on the execution of the changed code, because no functions there ever > generate C++ exception or call a function that could generate exception= =2E >=20 > The addition of the annotations significantly improves the results of > the libunwind test suite on FreeBSD/amd64. We are still not on par with= > Linux, mainly due to the lack of the unwind annotations for the signal > trampolines. Fixing this requires VDSO. >=20 [...] Regarding to VDSO support, what happened to this request to FBSD of the year 2010? http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031553.html= oh --------------enig2F65809845F6A9E48F236FF2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQcfo+AAoJEOgBcD7A/5N8dmEIAL8mpH92k6rOW3U01zjbzMTs kunLhENJbdrKsEaCVs/Jud/tcm1570CNTE2pqk9c8CLuodK1P2qmMW6pAf5NiFdi ClIMLlAuJKYm+OrFcTOw8KePzr8L++OImNJeZXyWf8aOh8DxWimEaZssuuzw0joA XUa2Dm34zvKFEVYmS/ynrTaOskWuoKVIxLI5v6vpiEuJ0ExoIJbuUguQzYsq6gZJ 2rt72mt2kJyXFg89gO0CSwPURLCaZTSj87fpVSAUJAIwYrh9fmxsn6yPKafW4/Hu sN6xyoKg+AiOWgOIJqBf6dpa/pkz5dORJyl2pFgX1sYsO58z9dKo/99JxAHvQIo= =JJ0G -----END PGP SIGNATURE----- --------------enig2F65809845F6A9E48F236FF2--