From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 3 15:11:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4C4FF17 for ; Mon, 3 Dec 2012 15:11:52 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7891E8FC13 for ; Mon, 3 Dec 2012 15:11:51 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id qB3FBQwo020900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Dec 2012 15:11:27 GMT Date: Mon, 03 Dec 2012 15:11:21 +0000 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: Two Intel E31220L 9.0-Stable systems, 'kern.random' missing on one? Message-ID: <019F3C674FEE8BF6DB530F39@MightyAtom.tdx.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:11:53 -0000 Hi, I have two SuperMicro E31220L based systems - both had identical /etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of 2012/12/03). Now I've noticed of them complains at boot time that a bunch of OID's are missing - and sure enough: " sysctl kern.random sysctl: unknown oid 'kern.random' " But the other system returns these fine. One system ID's as 'Intel E31220L @ 2.20Ghz' - the other ID's as 'Intel E31220L V2 @ 2.30Ghz' the V2 system is apparently 'missing' the kern.random stuff. The only reason I can think for the OID's not being present is if one system is using hardware RNG? - Though 'man 4 random' states: "The only hardware implementation currently is for the VIA C3 Nehemiah (stepping 3 or greater) CPU. More will be added in the future." Is there any other reason why they would have 'disappeared' on the non V2 system? (in fact, looking at the Feature2 line I can see 'RDRAND' on the V2 system, hmm so I'm guessing that's it?!) Thanks, -Karl From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 3 17:09:55 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11A65693 for ; Mon, 3 Dec 2012 17:09:55 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 931238FC1A for ; Mon, 3 Dec 2012 17:09:54 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1383633bkc.13 for ; Mon, 03 Dec 2012 09:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=UQNbYI1GincNcbbrxdib9ekyy1H2g0V4bxXERdcDjyk=; b=U24yQXITzObhMc3fSCKSyZB5MrDYJQn4zBZnsAGEVMibhTiyL7fTOfNjy4CKVbTUwC vOJdBR2e6pyTPY9xy+95QdxD7X2q4BYfF4cciIBavzsCAroR81KYP4l32C93doZk7wQz YSqp2O+XSSeemdShUOcnrpGzs/kXxRFeJ5e/vDk6ML0FOCNZDBBATAwSlljCNHVXGH87 FRr+5wgsn1xBuQiWSEfGM46t8A+Ci1RHfVUZqcOdr3ISrt1s5WenrdFhVg55M80dCbLf zv/VDPvGNsBRv9acLWfYgiWasa37vJjuLhrqMvKuEfCEgX1Cp4M28EVeOKuNznWTXee4 geBA== Received: by 10.204.156.81 with SMTP id v17mr3046446bkw.18.1354554587912; Mon, 03 Dec 2012 09:09:47 -0800 (PST) Received: from DOMYPC ([193.198.56.247]) by mx.google.com with ESMTPS id l17sm7921844bkw.12.2012.12.03.09.09.46 (version=SSLv3 cipher=OTHER); Mon, 03 Dec 2012 09:09:47 -0800 (PST) Message-ID: <20121203.170951.188.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: $* and $@ exhibit same behaviour -> those of $* Date: Mon, 03 Dec 2012 18:09:51 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:09:55 -0000 I've noticed this under = 9.0-RELEASE-p5=0D=0A=0D=0A=0D=0A#!/bin/sh=0D=0A#####################################################=0D=0Aftest_dot = ()=0D=0A{=0D=0A local i=0D=0A=0D=0A for i in $*=0D=0A {=0D=0A = echo "$i"=0D=0A }=0D=0A}=0D=0A=0D=0Aftest_monkey ()=0D=0A{=0D=0A = local i=0D=0A=0D=0A for i in $@=0D=0A {=0D=0A echo = "$i"=0D=0A }=0D=0A}=0D=0A=0D=0A=0D=0Aecho = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0Aftest_dot one 'spaced path' two = ''=0D=0Aecho =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0Aftest_monkey one = 'spaced path' two ''=0D=0Aecho = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A=0D=0Aexit = 55=0D=0A=0D=0A=0D=0A=0D=0AOutput:=0D=0A-------=0D=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0Aone=0D=0Aspaced=0D=0Apath=0D=0Atwo=0D=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0Aone=0D=0Aspaced=0D=0Apath=0D=0Atwo=0D=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A=0D=0A=0D=0AExpected = output = is:=0D=0A-------------------=0D=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0Aone=0D=0Aspaced=0D=0Apath=0D=0Atwo=0D=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0Aone=0D=0Aspaced = path=0D=0Atwo=0D=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A=0D=0A=0D=0AI = hope fix'll get into 9.1=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 3 17:24:13 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45A4AACA for ; Mon, 3 Dec 2012 17:24:13 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE1A48FC16 for ; Mon, 3 Dec 2012 17:24:12 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1393551bkc.13 for ; Mon, 03 Dec 2012 09:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:in-reply-to:references:x-mailer; bh=2O8GBPXIFV7/RvsgvfhdYDnTmXZGan0LPmeYZ5WrvwQ=; b=Z6HqxfvE5AG80kU8Eg6EE+yHiDtAmqWaUo9zDkUGLgWoJsjDHmk+amh/eURXsymEwD MhvNTJPHJ/X8ZzqER+XMAIAcSc9JiTWEh5pPRSZ89BuiUGe6rLbiAFW+AHiRh1U1NVYv fYLPu2K9kmsLj4dRdrW+nEvmUDgI/4OMdi6MnprCzWfrAPZYK70+m59o5tyfr2OAHv5+ UfYuMa40mS2+adZZiOm98aU1wohI8ctWqM35Bd4qEZKRacUJJnUesFzq021PIzgXQ3QG ct00xhnxUFLb2ZikiCwMem/JnRj48qyrFgAeLPBIUplWZq1Qd3XgEFZe5XjAqYUc2WqS 1rLQ== Received: by 10.204.147.25 with SMTP id j25mr3065266bkv.36.1354555451812; Mon, 03 Dec 2012 09:24:11 -0800 (PST) Received: from DOMYPC ([193.198.56.247]) by mx.google.com with ESMTPS id c10sm7934370bkw.1.2012.12.03.09.24.09 (version=SSLv3 cipher=OTHER); Mon, 03 Dec 2012 09:24:10 -0800 (PST) Message-ID: <20121203.172415.072.3@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: Re: $* and $@ exhibit same behaviour -> those of $* Date: Mon, 03 Dec 2012 18:24:15 +0100 In-Reply-To: <70552161-B8BC-41EA-A734-A4244C3261C8@gmail.com> References: <20121203.170951.188.1@DOMY-PC> <70552161-B8BC-41EA-A734-A4244C3261C8@gmail.com> X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:24:13 -0000 > Looks fine to me. Try quoting $@ in ftest_monkey. > -Garrett Yes, it did a trick. That tiny detail. Thanks From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 3 17:24:29 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51F9DBB6 for ; Mon, 3 Dec 2012 17:24:29 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id D76AD8FC08 for ; Mon, 3 Dec 2012 17:24:28 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=YemAC1 Eb7fy0JJlCWK5tIafGyBPXz/ZENefyrTabZ8c+gC4uwabj2kg+TtPnLqZ7Pt8IUZ 1Rhn1rtMVA03ZE+4MGQmBHruxHfAa52+FrOEqd1576YebfTvmUbapQe/pN1Q4YMp qNqgMP4roGdjZ3BAfx36SKQlJXrUQHEguT7II= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=E5YhcpSW1wuv UwLJ+mCxUEGN+yg/6GLoGqwWZv/afP4=; b=R8A5GPgrDFJ0VR/IfAVjAiM8C+tk KeTAp7JaNdDIOIUQkVrqYw+xgZrRn6zFRgq8TcjjlMJ2POHjnkeIo6eXFS3TfiqA IJBRLFKHpeyUTZwV0j38P0MBTRt3SABxsY1aAdegXjTjnn6hdLkSZ2nWI/Rpvetw L43xElS0DXjfcd0= Received: (qmail 63382 invoked from network); 3 Dec 2012 11:24:21 -0600 Received: from unknown (HELO ?192.168.0.74?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 3 Dec 2012 11:24:21 -0600 Message-ID: <50BCE044.3050202@shatow.net> Date: Mon, 03 Dec 2012 11:24:20 -0600 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rank1seeker@gmail.com Subject: Re: $* and $@ exhibit same behaviour -> those of $* References: <20121203.170951.188.1@DOMY-PC> In-Reply-To: <20121203.170951.188.1@DOMY-PC> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:24:29 -0000 On 12/3/2012 11:09 AM, rank1seeker@gmail.com wrote: > I've noticed this under 9.0-RELEASE-p5 > > > #!/bin/sh > ##################################################### > ftest_dot () > { > local i > > for i in $* > { > echo "$i" > } > } > > ftest_monkey () > { > local i > > for i in $@ > { > echo "$i" > } > } > >From my understanding, used in that context, they should be the same. $* Expands to the positional parameters, starting from one. When the expansion occurs within a double-quoted string it expands to a single field with the value of each parameter separated by the first character of the IFS variable, or by a space if IFS is unset. $@ Expands to the positional parameters, starting from one. When the expansion occurs within double-quotes, each positional param‐ eter expands as a separate argument. If there are no positional parameters, the expansion of @ generates zero arguments, even when @ is double-quoted. What this basically means, for example, is if $1 is “abc” and $2 is “def ghi”, then "$@" expands to the two arguments: "abc" "def ghi" Note the first sentence in both. The difference only occurs when used inside quotes, i.e. "$@" and "$*" Bryan From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 3 18:50:27 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE7657CF; Mon, 3 Dec 2012 18:50:27 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 437E88FC12; Mon, 3 Dec 2012 18:50:25 +0000 (UTC) Received: from mart.js.berklix.net (p57BCF7D2.dip.t-dialin.net [87.188.247.210]) (authenticated bits=128) by tower.berklix.org (8.14.4/8.14.4) with ESMTP id qB3Ip7lh089541; Mon, 3 Dec 2012 19:51:08 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id qB3IoDHZ030148; Mon, 3 Dec 2012 19:50:13 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id qB3Io7nT093977; Mon, 3 Dec 2012 19:50:13 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201212031850.qB3Io7nT093977@fire.js.berklix.net> To: hackers@freebsd.org Subject: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Mon, 03 Dec 2012 19:50:07 +0100 Sender: jhs@berklix.com Cc: re@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:50:27 -0000 Hi hackers@freebsd.org There is a missing double quote " in 8.3 & 9.0 & 9.1RC2 src/etc/sendmail/freebsd.mc 8.2-RELEASE & earlier are OK. Here's a diff -c to .mc The diff is not to fix it, but to help generate a freebsd.cf to understand the difference. The patch for a fix would befar more trivial :-) ------ *** 9.1-RC3/src/etc/sendmail/freebsd.mc Mon Oct 29 21:16:44 2012 --- 9.1-RC3/src+debug/etc/sendmail/freebsdjhs.mc Mon Dec 3 18:44:33 2012 *************** *** 66,75 **** dnl For that, visit dnl http://www.google.com/Top/Computers/Internet/E-mail/Spam/Blacklists/ ! dnl Uncomment to activate your chosen DNS based blacklist ! dnl FEATURE(dnsbl, `dnsbl.example.com') ! dnl Alternatively, you can provide your own server and rejection message: ! dnl FEATURE(dnsbl, `dnsbl.example.com', ``"550 Mail from " $&{client_addr} " rejected'') dnl Dialup users should uncomment and define this appropriately dnl define(`SMART_HOST', `your.isp.mail.server') --- 66,77 ---- dnl For that, visit dnl http://www.google.com/Top/Computers/Internet/E-mail/Spam/Blacklists/ ! # Uncomment to activate your chosen DNS based blacklist ! FEATURE(dnsbl, `jhs0.dnsbl.example.com') ! # Alternatively, you can provide your own server and rejection message: ! FEATURE(dnsbl, `jhs3.dnsbl.example.com', ``"550 Mail from " $&{client_addr} " rejected'') ! # original line above has 3 x " , line below has 4 ! FEATURE(dnsbl, `jhs4.dnsbl.example.com', ``"550 Mail from " $&{client_addr} " rejected"'') dnl Dialup users should uncomment and define this appropriately dnl define(`SMART_HOST', `your.isp.mail.server') ------ The .cf output is ------ # DNS based IP address spam list jhs0.dnsbl.example.com R$* $: $&{client_addr} R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.jhs0.dnsbl.example.com. $: OK $) ROK $: OKSOFAR R$+ $: TMPOK R$+ $#error $@ 5.7.1 $: "550 Rejected: " $&{client_addr} " listed at jhs0.dnsbl.example.com" # DNS based IP address spam list jhs3.dnsbl.example.com R$* $: $&{client_addr} R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.jhs3.dnsbl.example.com. $: OK $) ROK $: OKSOFAR R$+ $: TMPOK R$+ $#error $@ 5.7.1 $: "550 Mail from " $&{client_addr} " rejected # DNS based IP address spam list jhs4.dnsbl.example.com R$* $: $&{client_addr} R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.jhs4.dnsbl.example.com. $: OK $) ROK $: OKSOFAR R$+ $: TMPOK R$+ $#error $@ 5.7.1 $: "550 Mail from " $&{client_addr} " rejected" ------ Above, jhs3 seems bad & jhs4 seems good. A copy of this diff + follow up is in http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/etc/sendmail/freebsd.mc.REL=ALL.diff The error appeared in 8.3 & 9.0 & 9.1RC3, it was OK earlier : 4.11-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', `"550 Mail from " $&{client_addr} " rejected, see http://mail-abuse.org/cgi-bin/lookup?" $&{client_addr}') 6.4-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see http://mail-abuse.org/cgi-bin/lookup?" $&{client_addr}'') 7.3-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see http://mail-abuse.org/cgi-bin/lookup?" $&{client_addr}'') 7.4-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see http://mail-abuse.org/cgi-bin/lookup?" $&{client_addr}'') 8.2-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see http://mail-abuse.org/cgi-bin/lookup?" $&{client_addr}'') 8.3-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `dnsbl.example.com', ``"550 Mail from " $&{client_addr} " rejected'') 9.0-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `dnsbl.example.com', ``"550 Mail from " $&{client_addr} " rejected'') 9.1-RC3//src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `dnsbl.example.com', ``"550 Mail from " $&{client_addr} " rejected'') Why others didnt notice earlier: It's just a comment, I assume not checked by anything automatic at freebsd.org. How I caught it: I have my own src/etc/sendmail/ Makefile diffs & fdef'd common.cpp that generates various .mc files for each of my hosts, & many versions, which filters the .cpp to create .mcfiles, inc. a check file that should be an exact match with that version's freebsd.mc ... & cpp complained: unmatched ". I will send-pr unless I hear otherwise. But as 9.1-RELEASE is imminent, & it would be a trivial anodyne fix to a comment for re@ , so they want to fix, so cc'd to re@. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 00:10:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6895024A for ; Tue, 4 Dec 2012 00:10:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 079BE8FC0C for ; Tue, 4 Dec 2012 00:10:25 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB40AMlT092891; Tue, 4 Dec 2012 02:10:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB40AMlT092891 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB40AMlc092890; Tue, 4 Dec 2012 02:10:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Dec 2012 02:10:22 +0200 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Two Intel E31220L 9.0-Stable systems, 'kern.random' missing on one? Message-ID: <20121204001022.GM3013@kib.kiev.ua> References: <019F3C674FEE8BF6DB530F39@MightyAtom.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zMJiK8ZuAkzScPs5" Content-Disposition: inline In-Reply-To: <019F3C674FEE8BF6DB530F39@MightyAtom.tdx.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 00:10:26 -0000 --zMJiK8ZuAkzScPs5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 03, 2012 at 03:11:21PM +0000, Karl Pielorz wrote: >=20 > Hi, >=20 > I have two SuperMicro E31220L based systems - both had identical=20 > /etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of=20 > 2012/12/03). >=20 > Now I've noticed of them complains at boot time that a bunch of OID's are= =20 > missing - and sure enough: >=20 > " > sysctl kern.random > sysctl: unknown oid 'kern.random' > " >=20 > But the other system returns these fine. >=20 > One system ID's as 'Intel E31220L @ 2.20Ghz' - the other ID's as 'Intel= =20 > E31220L V2 @ 2.30Ghz' the V2 system is apparently 'missing' the kern.rand= om=20 > stuff. >=20 > The only reason I can think for the OID's not being present is if one=20 > system is using hardware RNG? - Though 'man 4 random' states: >=20 > "The only hardware implementation currently is for the > VIA C3 Nehemiah (stepping 3 or greater) CPU. More will be added in = the > future." >=20 > Is there any other reason why they would have 'disappeared' on the non V2= =20 > system? (in fact, looking at the Feature2 line I can see 'RDRAND' on the = V2=20 > system, hmm so I'm guessing that's it?!) You noted that RDRAND is supported by your hardware. And indeed, FreeBSD got the RDRAND (aka Bull Mountain) hardware random number generator support recently. =46rom my reading of the sys/dev/random code, the kern.random OID is only instantiated if the software implementation is selected. If you prefer software, you can disable RDRAND with hw.ivy_rng_enable=3D0 tunable. --zMJiK8ZuAkzScPs5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQvT9tAAoJEJDCuSvBvK1BvHMP/1vFEH3p/QS+3xVFMbhxiDOZ X8p+6GFyAHdBOx93fdkuxmRFrpv9fx5b3ur+vMWOmveQfKvu+vgSgch+2zlHubN1 6EmMVSzae/AtFz42bNxM+Pp0Z83bSzbuSmz+FdnzyW0bt3XBxKbyVANmTVEXs2ID UjRHGAEQov1FUto3aL/IuATiAdAbj3WceCIkHHbKGP9zqxN4sCTn8NrxSQ70pwMB Wlc9nYTZsZquH3GX7hCh6nmm9XlVoR3DQyAwIauBBFtGXNRKSTNaw65aI+uHmNWO QLg2sWnaYm2SVC2DQj3CQL7fW0p2BXBWh5QDGCAsFskwREZgtVdV+VRjDmVYwBfP hXUIrHgxWCV6B2Fx5Afx+2wYKZK1oewn4KpBzg4wZXQF84hNGQ6mQpxzMxkikJvG xI1xAr7JWUho/2WFQeRT08N6hJfAPxPFYjr1euA1OKS24roy8seV3QHFEWQ2QS19 ECyQ9Rov2zE4ez2t82kmMjQ+bbaDoIOGioJeR53Z2lhH4Q+4vMxD9VVYLIEBsU0I FNLdCIzG+IjTrQHNlMd+6m6XLiSDIhztetEacHbKh4fSC0kP83XzKtxu/DAC14Sd 2kE6Sp83kKEYuSosUncEYPCUDbkbBnpELIYTo+xXBK91W1BNAKI4DQmce9FOuy1z 7OrTaotQ1E29CvHxkPVk =OHvM -----END PGP SIGNATURE----- --zMJiK8ZuAkzScPs5-- From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 02:25:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3BDC21D for ; Tue, 4 Dec 2012 02:25:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7145D8FC08 for ; Tue, 4 Dec 2012 02:25:53 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so2383379qcs.13 for ; Mon, 03 Dec 2012 18:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vAWXUf+asw0gGaMdYswn/B3StrVgFHqigiZpm6Fiibs=; b=YveBlSWZHbgoi61t8idClr0cV8xrUH3fQ0rg6kYfg28n33dKGSqNPq12TGKd+QmFTi a9whvzuDRHUcfAr0wPVVpar7PuFJILMmjP0+9XgsFyIO/I4mc2xvqVuw8EdtdqIYpQnz kbjqBWsQVywQ4R+2dw0CssH09KNF12InjylL/Nja4kvEz5I8aj12+MEszeufsSsGCvHr ycKTHFlxQIGdgWK681Y6d9H+hNy4IBjlsQUluRJlNGp0AaDneRAkcAg2xdJmoLWxXfbe AvSbxtW+h0lUFhz2Prt2e4c6VDJUdUENRcQd3ESvEyKemA6w2jZtUDXC6r3VFolN9z7n e4pw== MIME-Version: 1.0 Received: by 10.229.180.25 with SMTP id bs25mr4813940qcb.20.1354587952650; Mon, 03 Dec 2012 18:25:52 -0800 (PST) Received: by 10.49.39.202 with HTTP; Mon, 3 Dec 2012 18:25:52 -0800 (PST) Date: Mon, 3 Dec 2012 21:25:52 -0500 Message-ID: Subject: [PATCH] Bugs in DTrace debug locking code From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 02:25:53 -0000 DTrace has an unused logging facility built-in. The logging is intended to be safe to be called from the handler of a DTrace probe (what DTrace calls "probe context"). Because a DTrace probe could be enabled almost anywhere in the kernel, this means that it can't use standard FreeBSD synchronization primitives, and so it has rolled its own spin lock. As so often happens when rolling your own synchronization, there are several bugs here: 1) It doesn't use spinlock_enter/spinlock_exit, which means that a thread holding a spin lock can be switched out. A subsequent thread could be starved trying to acquire the lock (worse, there's the chance of a nasty case of priority inversion here, where a low-priority thread holds the lock but cannot run because a high-priority thread is spinning on that same lock). This is the bug that caused me to start looking into this code: I saw a situation where a user thread had taken the lock and subsequently been switched out, and a softclock thread starved waiting for the spin lock. 2) The code uses per-CPU buffers and thus has a lock for every CPU. It ends up doing the following in many cases: dtrace_debug_lock(curcpu); //... dtrace_debug_unlock(curcpu); There is nothing that guarantees that the thread can not have migrated to a new CPU in the meantime. 3) The locks do not use acquire and release memory barriers. 4) The locks are all right next to each other in memory, so false sharing will defeat much of the purpose of having per-CPU buffers in the first place. 5) The locks do not record their owner, make it difficult to debug problems with them. (There is a sixth problem, namely that this code is compiled into the kernel when nothing in the tree uses this log facility, but there is still some code paths which check for log messages. That's why I saw my crash in #1 in the first place. I plan on taking it out in a separate commit.) The following patch addresses these issues. I've tried stress-testing DTrace but I've been unable to reproduce my original crash on head. Any comments or objections? Index: sys/cddl/dev/dtrace/dtrace_debug.c =================================================================== --- sys/cddl/dev/dtrace/dtrace_debug.c (revision 243795) +++ sys/cddl/dev/dtrace/dtrace_debug.c (working copy) @@ -39,6 +39,7 @@ struct dtrace_debug_data { char bufr[DTRACE_DEBUG_BUFR_SIZE]; + uintptr_t lock; char *first; char *last; char *next; @@ -46,12 +47,14 @@ static char dtrace_debug_bufr[DTRACE_DEBUG_BUFR_SIZE]; -static volatile u_long dtrace_debug_flag[MAXCPU]; - static void dtrace_debug_lock(int cpu) { - while (dtrace_cmpset_long(&dtrace_debug_flag[cpu], 0, 1) == 0) + uintptr_t tid; + + tid = (uintptr_t)curthread; + spinlock_enter(); + while (atomic_cmpset_acq_long(&dtrace_debug_data[cpu].lock, 0, tid) == 0) /* Loop until the lock is obtained. */ ; } @@ -59,7 +62,8 @@ static void dtrace_debug_unlock(int cpu) { - dtrace_debug_flag[cpu] = 0; + atomic_store_rel_long(&dtrace_debug_data[cpu].lock, 0); + spinlock_exit(); } static void @@ -151,10 +155,11 @@ */ static __inline void -dtrace_debug__putc(char c) +dtrace_debug__putc(int cpu, char c) { - struct dtrace_debug_data *d = &dtrace_debug_data[curcpu]; + struct dtrace_debug_data *d; + d = &dtrace_debug_data[cpu]; *d->next++ = c; if (d->next == d->last) @@ -172,24 +177,30 @@ static void __used dtrace_debug_putc(char c) { - dtrace_debug_lock(curcpu); + int cpu; - dtrace_debug__putc(c); + cpu = curcpu; + dtrace_debug_lock(cpu); - dtrace_debug_unlock(curcpu); + dtrace_debug__putc(cpu, c); + + dtrace_debug_unlock(cpu); } static void __used dtrace_debug_puts(const char *s) { - dtrace_debug_lock(curcpu); + int cpu; + cpu = curcpu; + dtrace_debug_lock(cpu); + while (*s != '\0') - dtrace_debug__putc(*s++); + dtrace_debug__putc(cpu, *s++); - dtrace_debug__putc('\0'); + dtrace_debug__putc(cpu, '\0'); - dtrace_debug_unlock(curcpu); + dtrace_debug_unlock(cpu); } /* @@ -219,7 +230,7 @@ #define MAXNBUF (sizeof(intmax_t) * NBBY + 1) static void -dtrace_debug_vprintf(const char *fmt, va_list ap) +dtrace_debug_vprintf(int cpu, const char *fmt, va_list ap) { char nbuf[MAXNBUF]; const char *p, *percent, *q; @@ -243,10 +254,10 @@ width = 0; while ((ch = (u_char)*fmt++) != '%' || stop) { if (ch == '\0') { - dtrace_debug__putc('\0'); + dtrace_debug__putc(cpu, '\0'); return; } - dtrace_debug__putc(ch); + dtrace_debug__putc(cpu, ch); } percent = fmt - 1; qflag = 0; lflag = 0; ladjust = 0; sharpflag = 0; neg = 0; @@ -266,7 +277,7 @@ ladjust = 1; goto reswitch; case '%': - dtrace_debug__putc(ch); + dtrace_debug__putc(cpu, ch); break; case '*': if (!dot) { @@ -301,7 +312,7 @@ num = (u_int)va_arg(ap, int); p = va_arg(ap, char *); for (q = dtrace_debug_ksprintn(nbuf, num, *p++, NULL, 0); *q;) - dtrace_debug__putc(*q--); + dtrace_debug__putc(cpu, *q--); if (num == 0) break; @@ -309,19 +320,20 @@ for (tmp = 0; *p;) { n = *p++; if (num & (1 << (n - 1))) { - dtrace_debug__putc(tmp ? ',' : '<'); + dtrace_debug__putc(cpu, + tmp ? ',' : '<'); for (; (n = *p) > ' '; ++p) - dtrace_debug__putc(n); + dtrace_debug__putc(cpu, n); tmp = 1; } else for (; *p > ' '; ++p) continue; } if (tmp) - dtrace_debug__putc('>'); + dtrace_debug__putc(cpu, '>'); break; case 'c': - dtrace_debug__putc(va_arg(ap, int)); + dtrace_debug__putc(cpu, va_arg(ap, int)); break; case 'D': up = va_arg(ap, u_char *); @@ -329,12 +341,12 @@ if (!width) width = 16; while(width--) { - dtrace_debug__putc(hex2ascii(*up >> 4)); - dtrace_debug__putc(hex2ascii(*up & 0x0f)); + dtrace_debug__putc(cpu, hex2ascii(*up >> 4)); + dtrace_debug__putc(cpu, hex2ascii(*up & 0x0f)); up++; if (width) for (q=p;*q;q++) - dtrace_debug__putc(*q); + dtrace_debug__putc(cpu, *q); } break; case 'd': @@ -406,12 +418,12 @@ if (!ladjust && width > 0) while (width--) - dtrace_debug__putc(padc); + dtrace_debug__putc(cpu, padc); while (n--) - dtrace_debug__putc(*p++); + dtrace_debug__putc(cpu, *p++); if (ladjust && width > 0) while (width--) - dtrace_debug__putc(padc); + dtrace_debug__putc(cpu, padc); break; case 't': tflag = 1; @@ -485,32 +497,32 @@ if (!ladjust && padc != '0' && width && (width -= tmp) > 0) while (width--) - dtrace_debug__putc(padc); + dtrace_debug__putc(cpu, padc); if (neg) - dtrace_debug__putc('-'); + dtrace_debug__putc(cpu, '-'); if (sharpflag && num != 0) { if (base == 8) { - dtrace_debug__putc('0'); + dtrace_debug__putc(cpu, '0'); } else if (base == 16) { - dtrace_debug__putc('0'); - dtrace_debug__putc('x'); + dtrace_debug__putc(cpu, '0'); + dtrace_debug__putc(cpu, 'x'); } } if (!ladjust && width && (width -= tmp) > 0) while (width--) - dtrace_debug__putc(padc); + dtrace_debug__putc(cpu, padc); while (*p) - dtrace_debug__putc(*p--); + dtrace_debug__putc(cpu, *p--); if (ladjust && width && (width -= tmp) > 0) while (width--) - dtrace_debug__putc(padc); + dtrace_debug__putc(cpu, padc); break; default: while (percent < fmt) - dtrace_debug__putc(*percent++); + dtrace_debug__putc(cpu, *percent++); /* * Since we ignore an formatting argument it is no * longer safe to obey the remaining formatting @@ -522,23 +534,26 @@ } } - dtrace_debug__putc('\0'); + dtrace_debug__putc(cpu, '\0'); } void dtrace_debug_printf(const char *fmt, ...) { va_list ap; + int cpu; - dtrace_debug_lock(curcpu); + cpu = curcpu; + dtrace_debug_lock(cpu); + va_start(ap, fmt); - dtrace_debug_vprintf(fmt, ap); + dtrace_debug_vprintf(cpu, fmt, ap); va_end(ap); - dtrace_debug_unlock(curcpu); + dtrace_debug_unlock(cpu); } #else From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 08:24:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A003B48B for ; Tue, 4 Dec 2012 08:24:49 +0000 (UTC) (envelope-from litherum@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1BB8FC12 for ; Tue, 4 Dec 2012 08:24:48 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so425635wib.13 for ; Tue, 04 Dec 2012 00:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=ntCsSe4HcqoAc1dbpbVVWQTtWOhTNnTYjWb0LI2FCi4=; b=g+3pAMDU+BABXG8nNEytKJ3NdmFSPN6tE4KL9L8u+qr7bE9rtCjBw3XFSl7ryhC1/U xtIhjRKpZkqcpotRxTApOYRPj4w2jxsbvHfI2ByzX6yG0imKHRodl2JZPr0vqlPIvYs/ kFmIq4DwdaeyljTkCHwcgjKpXsaRnjxC6whEaQOdUgoorrii5J26ZmCx3bzhhi2oxLod +LWP7T+HHlmvaKDgMnKGoH/uyMZFsmN8IbYHvS6gJ3E7bJuMAnOXpWCzpMbJFsyNIT6X 3LW0n9sYvJWGNV50+KYF5q/AJOIYH6fTuwvc4vrRw7FuKiLp05vL3+4/5qpDzj6HyLHr twgw== Received: by 10.216.82.10 with SMTP id n10mr4382837wee.126.1354609488032; Tue, 04 Dec 2012 00:24:48 -0800 (PST) MIME-Version: 1.0 Sender: litherum@gmail.com Received: by 10.216.71.13 with HTTP; Tue, 4 Dec 2012 00:24:27 -0800 (PST) From: "Myles C. Maxfield" Date: Tue, 4 Dec 2012 00:24:27 -0800 X-Google-Sender-Auth: OJY0Pfi7DuObuo7BRn4-bGKZvvQ Message-ID: Subject: libc with debugging symbols? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:24:49 -0000 Hello, all, I'm interested in learning about the internals of how libc works, so I was hoping to link a test application with a version of libc that has debugging symbols (reading the raw sources only gets me so far). The version of libc that comes with FreeBSD doesn't have debugging symbols (nor should it), so I'm wondering if there is a way to install / compile my own. I have very na=EFvely checked out libc from /base/head at svn.freebsd.org, crossed my fingers, and ran 'make', but that didn't work (for many reasons, I'm sure). This leads me to the following questions: 1. Is it possible to check out the sources of libc (and possibly other libraries) as they were when the FreeBSD 9.0 release was being compiled (since that's what I'm running)? Is there a way to map this to a particular SVN revision? 2. Is there a listing of the tools and versions used to compile libc at that time? 3. Many other unix-like distributions have something like a libc-dbg package in their package manager. Do you think this would be worthwhile or even acceptable for me to try to create something similar in the ports database? (I couldn't find anything that already exists) Thanks, Myles C. Maxfield From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 10:06:57 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05A099CB for ; Tue, 4 Dec 2012 10:06:57 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id B40718FC12 for ; Tue, 4 Dec 2012 10:06:56 +0000 (UTC) Received: from [192.168.187.69] (unknown [87.54.33.251]) by csmtp2.one.com (Postfix) with ESMTPA id 98C01304301A; Tue, 4 Dec 2012 10:06:55 +0000 (UTC) From: Erik Cederstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [CFT/RFC] Make crunched compatible with external linkers Date: Tue, 4 Dec 2012 11:06:56 +0100 Message-Id: <779286D2-F710-45FF-8C38-59513B5C1B7D@cederstrand.dk> To: FreeBSD Hackers Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: pete X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 10:06:57 -0000 Hello hackers, The following PR patches crunchide(1) to accept object files produced by = the gold and mclinker linkers: = http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin%2F174011 On behalf of the submitter, I'd like to request a review of the patch, = and testing of crunchide/crunchgen especially on SPARC and ARM. Thanks, Erik= From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 15:48:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F593D07 for ; Tue, 4 Dec 2012 15:48:04 +0000 (UTC) (envelope-from imp@bsdimp.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 C83978FC12 for ; Tue, 4 Dec 2012 15:48:03 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so5012452obc.13 for ; Tue, 04 Dec 2012 07:48:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4h8EptCmonJ6c7KiXfjq42jpzUI4KHzJHq8ABZwVpgM=; b=VVXvbewy35i3bmcp6n3NKO8+3wKmKbJkqXvXsWMnGXqeZqCt6EKradqB3Clt2aWIoe hR3Wr9desGiEobDl1W3BZpk/BeazjXCZrtc5RWxsux7QmugStCurCq2XqZkuws7ttqHr mOEhxOcptzC8Aifm741i//1pIJuEwj/K8mYkAqqwmt6XRKmVY7My5GYIqS2/B1IUeZPL xv5zIhQquFzfAaTrVwEE7OWrB9ILufwoF7IjwOI0VQH9ghsOBV7W+g6/8PZ/jmx/c6b+ MD9YqtRB3QCF9swmorGWTxHLATg2H0Dw/XXe1H1fiVHeAiWy9Vqdx1FyoWmQ0VPs4+oO MsGw== Received: by 10.60.24.97 with SMTP id t1mr8876849oef.6.1354636083232; Tue, 04 Dec 2012 07:48:03 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id h2sm1046835obn.11.2012.12.04.07.48.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2012 07:48:02 -0800 (PST) Sender: Warner Losh Subject: Re: libc with debugging symbols? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: Date: Tue, 4 Dec 2012 08:47:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D83C1F8-16D4-44A5-9C12-146FC77B3E65@bsdimp.com> References: To: "Myles C. Maxfield" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmXlTd2Q7jCfSAa7GCDuU8mmAn3APLm0L5h4jXVQwEJDcfITtduNph9Ci0JyoHaKb7vFeui Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 15:48:04 -0000 On Dec 4, 2012, at 1:24 AM, Myles C. Maxfield wrote: > Hello, all, > I'm interested in learning about the internals of how libc works, so I = was > hoping to link a test application with a version of libc that has = debugging > symbols (reading the raw sources only gets me so far). The version of = libc > that comes with FreeBSD doesn't have debugging symbols (nor should = it), so > I'm wondering if there is a way to install / compile my own. >=20 > I have very na=EFvely checked out libc from /base/head at = svn.freebsd.org, > crossed my fingers, and ran 'make', but that didn't work (for many = reasons, > I'm sure). This leads me to the following questions: >=20 > 1. Is it possible to check out the sources of libc (and possibly other > libraries) as they were when the FreeBSD 9.0 release was being = compiled > (since that's what I'm running)? Is there a way to map this to a = particular > SVN revision? Yes. The handbook should cover the different possibilities, but you'll = want to check out the code from http://svn.freebsd.org/base/releng/9.0 > 2. Is there a listing of the tools and versions used to compile libc = at > that time? It's all in what you checked out using the above link. > 3. Many other unix-like distributions have something like a libc-dbg > package in their package manager. Do you think this would be = worthwhile or > even acceptable for me to try to create something similar in the ports > database? (I couldn't find anything that already exists) That's an interesting idea. However, it is easy enough to build what = you need: cd svn-root-location # change this to the real path cd lib/libc make DEBUG_FLAGS=3D-g obj all install clean should suffice. It will add a bunch of space to your root and /usr = partitions, iirc, but disks these days are so huge you won't notice. If = you do, you can install to a different location using DESTDIR. Due to = some interaction between different parts of the system that's a smidge = more complex: cd svn-root-location make redistribute cd lib/libc make DEBUG_FLAGS=3D-g obj all install clean DESTDIR=3D/some/other/path If you are hacking on libc, you can omit the 'clean' step. If you are = rebuilding libc, you can omit the 'obj' after the first time. If you are = hacking on amd64, you may want to add WITHOUT_LIB32=3Dt to the command = line to disable the 32-bit build. To rebuild libc takes just a couple of minutes. Hope this helps. Warner= From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 18:42:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F5C5273; Tue, 4 Dec 2012 18:42:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 318348FC17; Tue, 4 Dec 2012 18:42:47 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 84637B95D; Tue, 4 Dec 2012 13:42:46 -0500 (EST) From: John Baldwin To: Andre Oppermann Subject: Re: kernel module parallel build? Date: Tue, 4 Dec 2012 10:52:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <5083D84E.50903@freebsd.org> <201210220928.52778.jhb@freebsd.org> <5096C79E.6020400@freebsd.org> In-Reply-To: <5096C79E.6020400@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212041052.51476.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 04 Dec 2012 13:42:46 -0500 (EST) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:42:47 -0000 On Sunday, November 04, 2012 2:53:02 pm Andre Oppermann wrote: > On 22.10.2012 15:28, John Baldwin wrote: > > On Sunday, October 21, 2012 7:11:10 am Andre Oppermann wrote: > >> What's keeping kernel modules from building in parallel with > >> "make -j8"? > > > > They don't for you? They do for me either via 'make buildkernel' > > or the old method. > > They do, but only partially. Within a module the files are built > in parallel. However the module directories seem to be serialized. > I'm a Makefile noob though. Hmm, I certainly see the module directories being built in parallel. Some of the make jobs may not be as obvious since links are silent (no output unless there is an error). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 19:11:44 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3BF4D4C for ; Tue, 4 Dec 2012 19:11:44 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 718358FC12 for ; Tue, 4 Dec 2012 19:11:44 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id qB4JBejG057342; Tue, 4 Dec 2012 14:11:40 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id qB4JBeZc057341; Tue, 4 Dec 2012 14:11:40 -0500 (EST) (envelope-from lidl) Date: Tue, 4 Dec 2012 14:11:40 -0500 From: Kurt Lidl To: Erik Cederstrand Subject: Re: [CFT/RFC] Make crunched compatible with external linkers Message-ID: <20121204191140.GA56790@pix.net> References: <779286D2-F710-45FF-8C38-59513B5C1B7D@cederstrand.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <779286D2-F710-45FF-8C38-59513B5C1B7D@cederstrand.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers , pete X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:11:44 -0000 On Tue, Dec 04, 2012 at 11:06:56AM +0100, Erik Cederstrand wrote: > Hello hackers, > > The following PR patches crunchide(1) to accept object files produced by the gold and mclinker linkers: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F174011 > > On behalf of the submitter, I'd like to request a review of the patch, and testing of crunchide/crunchgen especially on SPARC and ARM. I applied this patch to a 9/stable source tree, and was able to "buildworld" with it in place, on my sparc64 machine. I know that's not a great test case, but the patched binary is good enough to generate the objects that are needed for the 'rescue' binary. And that binary runs at least a trivial test of '/usr/obj/usr/src/rescue/rescue/rescue ifconfig -a' and produces correct output. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 19:41:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA8065A3; Tue, 4 Dec 2012 19:41:33 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1073A8FC1C; Tue, 4 Dec 2012 19:41:32 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so3968125vbi.18 for ; Tue, 04 Dec 2012 11:41:32 -0800 (PST) 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=IV+2MC5RVAnCQuSnL1ZGSRpizSBhR+ONuY7EWdd2Hg0=; b=bVVgWCop0o39/v1gM+aO1thqBgLctYc8FA8OgTPEmqizGqRXjMRz4k4J++5cU2WfYQ txI4EQPMdjEvwlTZ6XpdLpr3nnuLReEWWOoSUEBfLoeKkMP1If3rnw44mztH34wluduS A8sJTBq7RSb2vBY7gtwvc6p56kHTDbUxsUBh78uYlCusy40iA5rDwNNAFtI5koFJmgqg 2ulgv57TWIOL8gOVG9zBPL2YJI0WFph1z+Gs2TW77Qafv+IGis31vHtSHtCJTOk5vJe2 Dn7YtRbIqn1ycqGNsrtVHMHKcIiYj/AtATVPnVS0JF0rJbPcqOzcIPG/p6pfnJYAldeA Ckww== MIME-Version: 1.0 Received: by 10.58.240.107 with SMTP id vz11mr12916352vec.45.1354650092526; Tue, 04 Dec 2012 11:41:32 -0800 (PST) Received: by 10.58.207.114 with HTTP; Tue, 4 Dec 2012 11:41:32 -0800 (PST) In-Reply-To: <201212041052.51476.jhb@freebsd.org> References: <5083D84E.50903@freebsd.org> <201210220928.52778.jhb@freebsd.org> <5096C79E.6020400@freebsd.org> <201212041052.51476.jhb@freebsd.org> Date: Tue, 4 Dec 2012 14:41:32 -0500 Message-ID: Subject: Re: kernel module parallel build? From: Ryan Stone To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current , Andre Oppermann X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:41:33 -0000 On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin wrote: > Hmm, I certainly see the module directories being built in parallel. Some > of > the make jobs may not be as obvious since links are silent (no output > unless > there is an error). > > This is definitely not the behaviour that I see trying to build any version of FreeBSD. I see the same behaviour as Andre: the depend and all targets both iterate through the module directories sequentially. It never builds two module subdirectories concurrently. From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 20:28:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03FA4D06 for ; Tue, 4 Dec 2012 20:28:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id AAFD38FC0C for ; Tue, 4 Dec 2012 20:28:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJdbvlCDaFvO/2dsb2JhbABEhjO4EnOCSIELAg0ZAokCnwyOUII/kFaBIowvghSBEwOIX40kkEeDEIID X-IronPort-AV: E=Sophos;i="4.84,217,1355115600"; d="scan'208";a="3079964" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 04 Dec 2012 15:28:37 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BCAB8B3EE1 for ; Tue, 4 Dec 2012 15:28:37 -0500 (EST) Date: Tue, 4 Dec 2012 15:28:37 -0500 (EST) From: Rick Macklem To: freebsd-hackers@freebsd.org Message-ID: <1019659624.1136294.1354652917707.JavaMail.root@erie.cs.uoguelph.ca> Subject: naming a .h file for kernel use only MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 20:28:45 -0000 Hi, For my NFSv4.1 client work, I've taken a few definitions out of a kernel rpc .c file and put them in a .h file so that they can be included in other sys/rpc .c files. I've currently named the file _krpc.h. I thought I'd check if this is a reasonable name before doing the "big commit" of the NFSv4.1 stuff to head. (I have a vague notion that a leading "_" would indicate "not for public use", but I am not sure?) Thanks in advance for naming suggestions for this file, rick From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 4 21:56:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76760353 for ; Tue, 4 Dec 2012 21:56:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D38338FC0C for ; Tue, 4 Dec 2012 21:56:25 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB4LuMih025313; Tue, 4 Dec 2012 23:56:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB4LuMih025313 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB4LuLod025312; Tue, 4 Dec 2012 23:56:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Dec 2012 23:56:21 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: naming a .h file for kernel use only Message-ID: <20121204215621.GT3013@kib.kiev.ua> References: <1019659624.1136294.1354652917707.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sOuRR0jXHR3ukxKL" Content-Disposition: inline In-Reply-To: <1019659624.1136294.1354652917707.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 21:56:26 -0000 --sOuRR0jXHR3ukxKL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 04, 2012 at 03:28:37PM -0500, Rick Macklem wrote: > Hi, >=20 > For my NFSv4.1 client work, I've taken a few definitions out of a > kernel rpc .c file and put them in a .h file so that they can > be included in other sys/rpc .c files. >=20 > I've currently named the file _krpc.h. I thought I'd check if > this is a reasonable name before doing the "big commit" of the > NFSv4.1 stuff to head. (I have a vague notion that a leading "_" > would indicate "not for public use", but I am not sure?) >=20 > Thanks in advance for naming suggestions for this file, rick I believe that _thing.h is the convention for the headers that are never directly included by the .c files. It is there to hide some shared parts of other includes, for consumption by includes. Why not move the stuff to sys/nfs/krpc.h ? BTW, this file lacks the include guards. --sOuRR0jXHR3ukxKL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQvnGFAAoJEJDCuSvBvK1BrxQP/j+U6AWYSjkiph6Gj+rCkF0N SICY09jqfgRO4U9x4+MAdeX7M1HjJxGSroZDw2N0LH9m6ooQDjLmmyA1fKM2IZpb aRGXMrgP1I2KBNc0MyQaJBZwClZlpXcNboDRIxKSyF8DvNgUo4DbMEbBkvdLYi3X VEmlNTPS43NFlgc/qYwqFZ94cuGGtV85aSDU3ZGDLE/fHtl+9WCmfkt5e4ieDx0R LBDIAKKeouDPRKKqMca37OAiJ09y7EQoUoHf1Vj0wNoUNUxFgca41m93aQJkBfpO dNXQb2Cg8m21nM8QniOGLZ6lU9/3/Rpk2zB4DR/RBGGxEr7EAcOLMBSX9qguOOhC WGp9gBodkMzwjlAqQ03fCTXjMZnt0PRjoO7yLDhRdxb2W/TjKgGxUoQPjWwQ0XJp jCG6CtA4fm6zcrjm4fjLHzWDqU7um7gLMZSizYuXw9r3zJ8K1W0Hr8Pyg9bKRozs um0/isqRGTYIirAaE0Yt7t/TUPFuI8YI7MEYeqB2LlwvnOFMxNe/1TyrQI5Po/CQ EBVjO5UXufbxh+XTRLiBYjyvdRSONxr7EbUf/Wth65xQKhs0axZ1nv958QT++lgk sT4yBF+sLAa43dNVVt4eVCrKu/RPT2TzDOkOpMp1tpjcCN3Z2GGcZVFOJnQ2Fpe7 FqZSHj10w60v8+6L1s5u =5eBN -----END PGP SIGNATURE----- --sOuRR0jXHR3ukxKL-- From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 01:21:34 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D38D2396; Wed, 5 Dec 2012 01:21:34 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 41B398FC12; Wed, 5 Dec 2012 01:21:33 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBE7DC.dip.t-dialin.net [93.203.231.220]) (authenticated bits=128) by tower.berklix.org (8.14.4/8.14.4) with ESMTP id qB51MIsf003544; Wed, 5 Dec 2012 02:22:20 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id qB51LLAY040477; Wed, 5 Dec 2012 02:21:21 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id qB51LEdH048725; Wed, 5 Dec 2012 02:21:20 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201212050121.qB51LEdH048725@fire.js.berklix.net> To: hackers@freebsd.org, re@freebsd.org Subject: Re: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 03 Dec 2012 19:50:07 +0100." <201212031850.qB3Io7nT093977@fire.js.berklix.net> Date: Wed, 05 Dec 2012 02:21:14 +0100 Sender: jhs@berklix.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 01:21:34 -0000 > There is a missing double quote " in > 8.3 & 9.0 & 9.1RC2 src/etc/sendmail/freebsd.mc > 8.2-RELEASE & earlier are OK. > I will send-pr unless I hear otherwise. I sent a patch, & received this Message-id: <201212041520.qB4FK0PN030353@freefall.freebsd.org> Date: Tue, 4 Dec 2012 15:20:00 GMT (16:20 CET) It has the internal identification `bin/174108'. http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 >Category: bin >Responsible: freebsd-bugs >Synopsis: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc >Arrival-Date: Tue Dec 04 15:20:00 UTC 2012 At Wed Dec 5 02:16:29 CET 2012 the web ref fails: http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 There is no bug in the bin category beyond 174103 Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 01:58:52 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 416C5D21 for ; Wed, 5 Dec 2012 01:58:52 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A3FC38FC16 for ; Wed, 5 Dec 2012 01:58:51 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so4848310lah.13 for ; Tue, 04 Dec 2012 17:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/5+4dLSmtdPHMnp7r/oqi8AceibuOM+GiU5K+7s6xQk=; b=DEnJ4xBR9eRCNza5zDiJ7U4T969IDTI+BFPxqzoQ1zx7vc8pYsFVYvK2Jmo2Hofc/k SBVPs3kcpeSwi8eide4UMOgo6DiimmrBk2yrj+BFVK4lwhe36x07qho5eTRevhA/a6lI Zi8jP/4zLxtUyY9VGTHIxJN0GPmmPp1izAio4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/5+4dLSmtdPHMnp7r/oqi8AceibuOM+GiU5K+7s6xQk=; b=LbFvZY5eo/jWGrTpHc5fFUnjAM4fJhL1CtxTgTh44h7UD7imitmpDtDo/RlueXU9FS PqRSrq1MLFD/ipi3Vn97ySHFoHR6X9Y1dp08fNBKYjls5D9QSTklzbaWs3Cvth3JHUH8 9CeJLACYn19zK+E3wyFe/jh3gPYBItAPOPNePcrXkKc73OQU+weGQqbchau/8uzK0kv4 ffRdm8H81TNTrVATIIgV1n6+KL0LMFbcJ0+VVWJekQVaiDyfMbqOgDEl8he3EJSEZIvW IHuQDVcBASH9HPgXtahlnLGZk5OIoZ73JSc5NxArnNCvB5PwXmDwcOFwAo+4+UZ1ifvS 1wOg== Received: by 10.112.29.104 with SMTP id j8mr4940022lbh.0.1354672730503; Tue, 04 Dec 2012 17:58:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.110.225 with HTTP; Tue, 4 Dec 2012 17:58:20 -0800 (PST) In-Reply-To: <201212050121.qB51LEdH048725@fire.js.berklix.net> References: <201212031850.qB3Io7nT093977@fire.js.berklix.net> <201212050121.qB51LEdH048725@fire.js.berklix.net> From: Eitan Adler Date: Tue, 4 Dec 2012 20:58:20 -0500 Message-ID: Subject: Re: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc To: "Julian H. Stacey" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlquP665SdyRr7W5oFHaVifvB4z2qF9kKI7XRnKc5OKu8U4NGtniH9dGpYNIMq9NeFjtTeC Cc: hackers@freebsd.org, re@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 01:58:52 -0000 On 4 December 2012 20:21, Julian H. Stacey wrote: > At Wed Dec 5 02:16:29 CET 2012 the web ref fails: > http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 > There is no bug in the bin category beyond 174103 This is a known issue. I'm not sure what is causing it. Your bug made it (check the freebsd-bugs mailing list) but the web interface can't find it. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 02:24:04 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 650C7665; Wed, 5 Dec 2012 02:24:04 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id D18778FC14; Wed, 5 Dec 2012 02:24:03 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBE7DC.dip.t-dialin.net [93.203.231.220]) (authenticated bits=128) by tower.berklix.org (8.14.4/8.14.4) with ESMTP id qB52OrZW003875; Wed, 5 Dec 2012 03:24:54 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id qB52NugE040919; Wed, 5 Dec 2012 03:23:56 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id qB52Nimr049278; Wed, 5 Dec 2012 03:23:50 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201212050223.qB52Nimr049278@fire.js.berklix.net> To: Eitan Adler Subject: Re: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 04 Dec 2012 20:58:20 EST." Date: Wed, 05 Dec 2012 03:23:44 +0100 Sender: jhs@berklix.com Cc: hackers@freebsd.org, re@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 02:24:04 -0000 Hi, Reference: > From: Eitan Adler > Date: Tue, 4 Dec 2012 20:58:20 -0500 > Message-id: Eitan Adler wrote: > On 4 December 2012 20:21, Julian H. Stacey wrote: > > At Wed Dec 5 02:16:29 CET 2012 the web ref fails: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 > > There is no bug in the bin category beyond 174103 > > This is a known issue. I'm not sure what is causing it. > > Your bug made it (check the freebsd-bugs mailing list) but the web > interface can't find it. > -- > Eitan Adler Thanks Eitan, OK I see http://lists.freebsd.org/pipermail/freebsd-bugs/2012-December/051052.html Garrett C mentioned it was slow & wait a bit. Maybe something behind cgi/query-pr only builds index hash tables infrequently, crontab driven, Tue, 4 Dec 2012 15:20:00 GMT (16:20 CET) to Wed Dec 5 03:18:59 CET 2012 is near 11 hours. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 03:03:40 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBA661ED for ; Wed, 5 Dec 2012 03:03:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38C1E8FC18 for ; Wed, 5 Dec 2012 03:03:39 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so4882942lah.13 for ; Tue, 04 Dec 2012 19:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n7bJUUsPHnxYEbfjEuCfkRKTPKafq+TlLANy8be2qAE=; b=NDmLQ5kiJFILOCF+R6mtsetjJAsjHXS4nUuEf2zhk91JbjuWNHTnuWEqJyutyr4/lr q7nLg9OFNcAsuFh2bRWjz7JpbzKRoTBLgWciBBExrKysj75nKQO2nZKsu+2xwQNQNg1F OkpzbPgTtTLRpOrNUc05cLeGcfrh2FIZX619s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=n7bJUUsPHnxYEbfjEuCfkRKTPKafq+TlLANy8be2qAE=; b=TJaHWbwUiOwLXR0v/VH0ByrInNN2FscIp9aok7b12vGt6CClBSiO3xWG/TazhqGYL0 1M+9QAAj7G95Uzr9LLW71PsiPFwp6Lwi9fAVQm5VCuDKZvFux3N4ETr834WtaloVrPQU QTgJ6mu7MEuwSzDlcKuKYKqlSi89IKntMYV5kkwOa2wcmvSCzK8v771YNCViPag4wx6s nVjwktpydNdFn8RDOGtNXjlYRm8n5NavPdoBWtrgCevT5qI+k+elPQfpglf4JF8q6DfQ HzTjCbRvCXXwA3zivJC6PKGGk4N5L1E6pQk8JW7kfB/DA8yZcsB1xcjTkySWGuOIvytI q9jA== Received: by 10.112.29.129 with SMTP id k1mr6838003lbh.102.1354676613481; Tue, 04 Dec 2012 19:03:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.110.225 with HTTP; Tue, 4 Dec 2012 19:03:03 -0800 (PST) In-Reply-To: <201212050223.qB52Nimr049278@fire.js.berklix.net> References: <201212050223.qB52Nimr049278@fire.js.berklix.net> From: Eitan Adler Date: Tue, 4 Dec 2012 22:03:03 -0500 Message-ID: Subject: Re: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc To: "Julian H. Stacey" , Cluster Administrators Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnS14+FHhoXAgJOOL0DYDIl9rnY4rZAELAvQjveQCXUZmfN9W8BsdtmNE8brKRyGnb7uFox Cc: hackers@freebsd.org, re@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 03:03:40 -0000 On 4 December 2012 21:23, Julian H. Stacey wrote: > Hi, > Reference: >> From: Eitan Adler >> Date: Tue, 4 Dec 2012 20:58:20 -0500 >> Message-id: > > Eitan Adler wrote: >> On 4 December 2012 20:21, Julian H. Stacey wrote: >> > At Wed Dec 5 02:16:29 CET 2012 the web ref fails: >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 >> > There is no bug in the bin category beyond 174103 >> >> This is a known issue. I'm not sure what is causing it. >> >> Your bug made it (check the freebsd-bugs mailing list) but the web >> interface can't find it. >> -- >> Eitan Adler > > Thanks Eitan, OK I see > http://lists.freebsd.org/pipermail/freebsd-bugs/2012-December/051052.html > > Garrett C mentioned it was slow & wait a bit. Normally it takes about 15 minutes for it to sync and cron to catch up. Something else is going on here. Clusteradm, can you comment? -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 03:16:50 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 056A3615; Wed, 5 Dec 2012 03:16:50 +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 977938FC14; Wed, 5 Dec 2012 03:16:49 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so5857351obc.13 for ; Tue, 04 Dec 2012 19:16:48 -0800 (PST) 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=0ZM2pPWSrIbXOrU9e+gFdwAqPFWnuKBHf5X4TtXiefs=; b=e9gbyf3M6mrpkn1Dfi3VVYpwQRG6z9hCjbRYp/g8ZC0xiWI8TPbHjc3TzGBVYUUs70 B4uaLqumWgbBb0hoBZjAqM/HycI6LleJHSd3lqocpntO0uYk64CFqX1iV3MS90SPDsaT Dlpy2ar7qA6HDBktgRjos1+5zjiInovhJ8RCMH+DlS00OA0QvsaHSY3T98x/xjVZDkGN Cz87d6p7ePeMvhx+16WWO1Z0+1xzNgFofYc3vBcajVf6KhXj1vbAtH5yq9g7+HLbwuG/ 2hmReQzyrLq32wBtRxKi9/UBI6BMIsuQokovEf2mmF84fAi+FdAEoS0T+uN01wyYTNug I+8g== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr13565939oeg.17.1354677408615; Tue, 04 Dec 2012 19:16:48 -0800 (PST) Received: by 10.76.143.33 with HTTP; Tue, 4 Dec 2012 19:16:48 -0800 (PST) In-Reply-To: References: <201212050223.qB52Nimr049278@fire.js.berklix.net> Date: Tue, 4 Dec 2012 19:16:48 -0800 Message-ID: Subject: Re: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc From: Garrett Cooper To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: "Julian H. Stacey" , hackers@freebsd.org, re@freebsd.org, Cluster Administrators X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 03:16:50 -0000 On Tue, Dec 4, 2012 at 7:03 PM, Eitan Adler wrote: > On 4 December 2012 21:23, Julian H. Stacey wrote: >> Hi, >> Reference: >>> From: Eitan Adler >>> Date: Tue, 4 Dec 2012 20:58:20 -0500 >>> Message-id: >> >> Eitan Adler wrote: >>> On 4 December 2012 20:21, Julian H. Stacey wrote: >>> > At Wed Dec 5 02:16:29 CET 2012 the web ref fails: >>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 >>> > There is no bug in the bin category beyond 174103 >>> >>> This is a known issue. I'm not sure what is causing it. >>> >>> Your bug made it (check the freebsd-bugs mailing list) but the web >>> interface can't find it. >>> -- >>> Eitan Adler >> >> Thanks Eitan, OK I see >> http://lists.freebsd.org/pipermail/freebsd-bugs/2012-December/051052.html >> >> Garrett C mentioned it was slow & wait a bit. > > Normally it takes about 15 minutes for it to sync and cron to catch > up. Something else is going on here. Clusteradm, can you comment? It took almost an hour on Sunday, FYI. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 06:43:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5693FF9 for ; Wed, 5 Dec 2012 06:43:26 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 586768FC08 for ; Wed, 5 Dec 2012 06:43:26 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so5005998lah.13 for ; Tue, 04 Dec 2012 22:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yV4Xk01ciTmmv7XuPXmaXo6NXSNpz6GMobvQ3ew6cjk=; b=UAdYq7co76w/lFkeMcPp6ZawQciG2nY4n2qpi21EsJVJ485Us47hiFOCjIazSZr+cT Z3jtxZgWydc87DLibK5MfFURjjskAWPSRHEooLRkdG8WdSBecNv0OTe1h8umtZqdltZU 2A6nKx/jCKJtYaVEe13o86hNmj7xEz3T4jYwXBeT6JLGRhqzAXrSidX3rifT2mjAQz6g 6CY7j+EAzesMzVTyd7DeKbK14EVcgfDEWgl9BuopWGyYztA7bp75kRrKhtXtvCCRTCgD 5K9bEfB+IwDywp9QGGx4T3qdclJ3GBKJM42Oe1j1H4/JLFkuMrYO7ptmaiw/0A8HIGkK im0Q== MIME-Version: 1.0 Received: by 10.152.102.234 with SMTP id fr10mr15717227lab.28.1354689805089; Tue, 04 Dec 2012 22:43:25 -0800 (PST) Received: by 10.112.139.71 with HTTP; Tue, 4 Dec 2012 22:43:24 -0800 (PST) Date: Wed, 5 Dec 2012 12:13:24 +0530 Message-ID: Subject: ELF symtab and ddbsymtab difference From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 06:43:26 -0000 This is regarding the fields in the structure "elf_file_t" in link_elf.c. For some kernel modules the symtab field is different from the ddbsymtab field for some it is the same, would like to know what is the difference between the two and how to enable ddbsymtab? Does enabling "-g" in CFLAGS make the binary build the ddbsymtab different from symtab? The problem is lookup for some symbols in the kernel module that I built returns with undefined, on inspecting it was getting a ENOENT from the function link_elf_lookup_symbol() { ... /* If we have not found it, look at the full table (if loaded) */ if (ef->symtab == ef->ddbsymtab) return (ENOENT); ... } -- Shrikanth R K From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 09:54:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32A0FD08; Wed, 5 Dec 2012 09:54:25 +0000 (UTC) (envelope-from mashtizadeh@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 C7F228FC13; Wed, 5 Dec 2012 09:54:24 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so6163723obc.13 for ; Wed, 05 Dec 2012 01:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4n88mFKnaNLQdudBx1w+UXeZhpWT/NJWn5OfZYo3jlg=; b=iJUeN1/IfyDUFIHKjucISZw1ekxVs0trFI7rKFfg2+qMqui1H9sh+LnPXUjuqdujtU JrWoVSbQBw+nfi9lBjNGTdeYQ2wgwhzu1s4Xo5keGBPg57yUodm648Cr3YsPaeZJs/9y aNsU+TmYhYVvVACa+E7kjoxgb9reNzpSFQspxKn2aSuaxqWxY3B/ByVqGPAQCsRQMz9e 3O5mvKZIy6bU0Nn4gi/rJDzIm8wrUCTISZKPbmODuFGzRmKGbhrpFpYMuq6RE1I4Odrn 7K4VcktulyS+4bbEssvlu/bn0o+g4UbkkdBEmgKLbU1jip7BkDxFnse0gaRtO131GgBA AMyQ== MIME-Version: 1.0 Received: by 10.182.240.45 with SMTP id vx13mr10277803obc.21.1354701258542; Wed, 05 Dec 2012 01:54:18 -0800 (PST) Received: by 10.76.143.199 with HTTP; Wed, 5 Dec 2012 01:54:18 -0800 (PST) Date: Wed, 5 Dec 2012 01:54:18 -0800 Message-ID: Subject: GELI on USB From: Ali Mashtizadeh To: FreeBSD Hackers , freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:54:25 -0000 I think I found a possible bug in 9.1 where I configured an encrypted root partition on a USB key and I have trouble entering the password from what seems like a race. 1. GELI first prints to ask for my password on the root, but immediately is interrupted with a message saying that the root failed to mount with error 19. As shown here: http://www.mashtizadeh.com/usbnotwaiting.jpg When I type the file system path some characters are missing. It appears that geli and the prompt for root are both reading the USB keyboard input. When setting kern.geom.eli.visible_passphrase=3D1 then all characters are printed on the screen, but the prompt seems to receive bad input. Is there a way to prevent the root mount failing immediately? I set the boot flag and it seems this works properly on some hardware. --=20 Ali Mashtizadeh =D8=B9=D9=84=DB=8C =D9=85=D8=B4=D8=AA=DB=8C =D8=B2=D8=A7=D8=AF=D9=87 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 11:48:26 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65C07AC8 for ; Wed, 5 Dec 2012 11:48:26 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B3BC48FC13 for ; Wed, 5 Dec 2012 11:48:25 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so5281713lah.13 for ; Wed, 05 Dec 2012 03:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D/RUfE5UDkdEPFqWSOQkt3LfNJqr7MgxDDEJnLoYurA=; b=KbBTgddOGMxvholgX9QuCxFEZG4LvOmIMEUFrKihY5+YMLj83k/KYIApP9rQMd2Ljl Zxj+nBrueQKYTql3tMi42Sc1xGEsgk/34Zhj+l3hA+N1YTG3JYVLr43v/WZBNOZ/aIr8 6ZVoh2wZmVbNrPwc9Ci0+tOpUOKWTyPSmZ8vU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=D/RUfE5UDkdEPFqWSOQkt3LfNJqr7MgxDDEJnLoYurA=; b=L3yDBMXFu95kQbsZJC63PrElnyA6PE7FSEx23W75nYGitqRMIaVL0QFVEQ3Qj7im41 qVz9D6EBrV413XSA9aTqhLIY/lywx4C6Iv7ksrzlomXjT9TqDgC5041UzAn5MppYSlV1 j/YLOmlTef1neTju0klfmTUs8swHrV6Kx36WHNrTlk5egEBt53uc18tetf3d6Qqu8r1d qpNmY5skTY2+v05qciSm4MwDBmsZS53byHdJaxLv1yi2oHRzq1C8S6AUYTSpu7n7aWmw u1V7kEkhLKIqSDQq45PP04vIP7Vo9C1Y45jcfxdnfmSodssSBC6Duf9YJf5T7sfCdUbT OFZw== MIME-Version: 1.0 Received: by 10.112.37.200 with SMTP id a8mr1097114lbk.92.1354708104008; Wed, 05 Dec 2012 03:48:24 -0800 (PST) Sender: simon@qxnitro.org Received: by 10.112.134.196 with HTTP; Wed, 5 Dec 2012 03:48:23 -0800 (PST) X-Originating-IP: [2620:0:1040:204:a9f5:16a1:59a7:4e52] In-Reply-To: References: <201212050223.qB52Nimr049278@fire.js.berklix.net> Date: Wed, 5 Dec 2012 11:48:23 +0000 X-Google-Sender-Auth: JmxLQLAmH4VwdXRmiJ3A9gVT3Ks Message-ID: Subject: Re: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc From: "Simon L. B. Nielsen" To: Peter Wemm Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnc43iV6LgoFc5q+ZEmR55ELH2VQFNPNMmLlMWqOueVBKriAtegfDGew0e9kk15bNmJtHpn Cc: re@freebsd.org, Garrett Cooper , Eitan Adler , "Julian H. Stacey" , hackers@freebsd.org, Cluster Administrators X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 11:48:26 -0000 On 5 December 2012 07:02, Peter Wemm wrote: > On Tue, Dec 4, 2012 at 7:16 PM, Garrett Cooper wrote: >> On Tue, Dec 4, 2012 at 7:03 PM, Eitan Adler wrote: >>> On 4 December 2012 21:23, Julian H. Stacey wrote: >>>> Hi, >>>> Reference: >>>>> From: Eitan Adler >>>>> Date: Tue, 4 Dec 2012 20:58:20 -0500 >>>>> Message-id: >>>> >>>> Eitan Adler wrote: >>>>> On 4 December 2012 20:21, Julian H. Stacey wrote: >>>>> > At Wed Dec 5 02:16:29 CET 2012 the web ref fails: >>>>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 >>>>> > There is no bug in the bin category beyond 174103 >>>>> >>>>> This is a known issue. I'm not sure what is causing it. >>>>> >>>>> Your bug made it (check the freebsd-bugs mailing list) but the web >>>>> interface can't find it. >>>>> -- >>>>> Eitan Adler >>>> >>>> Thanks Eitan, OK I see >>>> http://lists.freebsd.org/pipermail/freebsd-bugs/2012-December/051052.html >>>> >>>> Garrett C mentioned it was slow & wait a bit. >>> >>> Normally it takes about 15 minutes for it to sync and cron to catch >>> up. Something else is going on here. Clusteradm, can you comment? >> >> It took almost an hour on Sunday, FYI. >> -Garrett > > cvsup and cvsupd started giving SIGBUS after the last installworld. I > haven't looked too closely yet. > > I am inclined to replace the data transfer from freefall -> > www.freebsd.org with a straight up rsync. Want me to look at that? -- Simon L. B. Nielsen From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 07:02:22 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CA7247E for ; Wed, 5 Dec 2012 07:02:22 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F9D28FC0C for ; Wed, 5 Dec 2012 07:02:21 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo14so5158035vcb.13 for ; Tue, 04 Dec 2012 23:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WQ07hR6ZQviduT07uegdaG0+q1Ly7yI7dhNArttL1uk=; b=d2crjd/eiwOXkzawPJmE+2RvlihW+lhqTDQp2U4QnHmM4P16Ytq7GW9OAgSxLFlGDd lHvQLKXyUDlG0P/2BUPChvC79NvPs5gdk2F90vTTOnYE9k/d7hCsvXZszvew8qNgbvI2 6XXKO1qRWHFnuHZ5nNW08K65MQ/1BLnHCTa1k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=WQ07hR6ZQviduT07uegdaG0+q1Ly7yI7dhNArttL1uk=; b=Cl04VVEltUp9+HqAx4djyIh9LODJiU1R8P3ZL5j/j3ucsazxWo2WOHs2gcWn3aWMPC iyqbvhsz0fNzq1DRrDQBdjyEbOEmf5zUG2sH9ppIAsmZd81bfFPzG/4Daqs7eQOJdyFk OnwMfiX3WozJofuDJQ+8WMr6YL+EVmpfWKK9LdpPYsi3hRs47m4nDqW1uaN3dgylhTR7 NfQAzYKNWoLqjK0DRrXiOlJHgG0CoiV/imZ29B1E74mEAjDlgztQo+jHsY1+iWS//2iQ 3vFarUShzkxWthxj0yuCcrunwAUMnuq/nYQUbzsdqhkDib9CsMoM6+UjE/lcaxXYrw6i WTxA== MIME-Version: 1.0 Received: by 10.52.75.135 with SMTP id c7mr12349306vdw.46.1354690934649; Tue, 04 Dec 2012 23:02:14 -0800 (PST) Received: by 10.220.132.14 with HTTP; Tue, 4 Dec 2012 23:02:14 -0800 (PST) In-Reply-To: References: <201212050223.qB52Nimr049278@fire.js.berklix.net> Date: Tue, 4 Dec 2012 23:02:14 -0800 Message-ID: Subject: Re: Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc From: Peter Wemm To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlMEMkIH6JtjuAgrTDfR+vuHZOP5XsK825vzJoffGe6Oj4v9AlQ9274b+sn5nGmkG9wlLx6 X-Mailman-Approved-At: Wed, 05 Dec 2012 12:50:37 +0000 Cc: Eitan Adler , "Julian H. Stacey" , hackers@freebsd.org, re@freebsd.org, Cluster Administrators X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 07:02:22 -0000 On Tue, Dec 4, 2012 at 7:16 PM, Garrett Cooper wrote: > On Tue, Dec 4, 2012 at 7:03 PM, Eitan Adler wrote: >> On 4 December 2012 21:23, Julian H. Stacey wrote: >>> Hi, >>> Reference: >>>> From: Eitan Adler >>>> Date: Tue, 4 Dec 2012 20:58:20 -0500 >>>> Message-id: >>> >>> Eitan Adler wrote: >>>> On 4 December 2012 20:21, Julian H. Stacey wrote: >>>> > At Wed Dec 5 02:16:29 CET 2012 the web ref fails: >>>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 >>>> > There is no bug in the bin category beyond 174103 >>>> >>>> This is a known issue. I'm not sure what is causing it. >>>> >>>> Your bug made it (check the freebsd-bugs mailing list) but the web >>>> interface can't find it. >>>> -- >>>> Eitan Adler >>> >>> Thanks Eitan, OK I see >>> http://lists.freebsd.org/pipermail/freebsd-bugs/2012-December/051052.html >>> >>> Garrett C mentioned it was slow & wait a bit. >> >> Normally it takes about 15 minutes for it to sync and cron to catch >> up. Something else is going on here. Clusteradm, can you comment? > > It took almost an hour on Sunday, FYI. > -Garrett cvsup and cvsupd started giving SIGBUS after the last installworld. I haven't looked too closely yet. I am inclined to replace the data transfer from freefall -> www.freebsd.org with a straight up rsync. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 15:12:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 077C6433; Wed, 5 Dec 2012 15:12:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB6F8FC0C; Wed, 5 Dec 2012 15:12:11 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so5652695lbb.13 for ; Wed, 05 Dec 2012 07:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0ecrfHu4UyuAvGiXNG9LxQWcNjTnHVOzeePJ8+DT+Ao=; b=UWJwBmRmy2tzZRYzaY152+sytb4GofG4EaF2EzY4+sThCkUPIzXAjtPRYU2E5UxNc4 bIt7HMDTmfliObmoUOx/9MqFGnQVQe82qNyAZXu8I09SgaMUIRSMVjAIRPPLaiZDRSKH WCqcJeIr7/6F5LwCL6KYqSS+0Bztgkdf8PtcrcOSLLe8hrYR2r/YSx3KwQbSrD2taRZH nj879Xx9wbZHW62J9y8bLJkNRg85uhHxcJsqcfS35vJo6jumDOKOUv9kTYxIrBrZe39c qMScDfg5L1mbv8TejvOZnGIDuVOi2BVDsd+yZL1jLD/daNhqLcubpb4NKC3v9LQ5Ov7f nDPQ== MIME-Version: 1.0 Received: by 10.112.28.98 with SMTP id a2mr7442291lbh.110.1354720330636; Wed, 05 Dec 2012 07:12:10 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.84.193 with HTTP; Wed, 5 Dec 2012 07:12:10 -0800 (PST) In-Reply-To: <50B74F9C.40106@FreeBSD.org> References: <50A4E8C0.5030608@FreeBSD.org> <50A552C5.5060703@FreeBSD.org> <50A650C2.7060407@FreeBSD.org> <50B74F9C.40106@FreeBSD.org> Date: Wed, 5 Dec 2012 15:12:10 +0000 X-Google-Sender-Auth: rrwwsdVO9li9ap8DbBaA2ObzOjo Message-ID: Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 15:12:13 -0000 On Thu, Nov 29, 2012 at 12:05 PM, Andriy Gapon wrote: > on 16/11/2012 16:42 Andriy Gapon said the following: >> on 15/11/2012 23:44 Attilio Rao said the following: >>> Do you think you can test this patch?: >>> http://www.freebsd.org/~attilio/lockmgr_forcerec.patch >> >> I will use this patch in my tree, but I think that it is effectively already quite >> well tested by using INVARIANTS+WITNESS. >> > > I've been using this patch in both debug and non-debug environments and I have not > run into any issues. Please commit when you get a chance. > Thank you. Committed as r243900, please proceed with manpage cleanup. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 16:00:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1E00FF for ; Wed, 5 Dec 2012 16:00:35 +0000 (UTC) (envelope-from timon@timon.net.nz) Received: from frost.plasmahost.ru (plasmahost.ru [178.63.60.242]) by mx1.freebsd.org (Postfix) with ESMTP id 52DB78FC12 for ; Wed, 5 Dec 2012 16:00:34 +0000 (UTC) Received: from timon.home.timon.net.nz ([87.242.97.4]) (AUTH: PLAIN timon@timon.net.nz, TLS: TLSv1/SSLv3,256bits,CAMELLIA256-SHA) by frost.plasmahost.ru with ESMTPSA; Wed, 05 Dec 2012 15:54:37 +0000 id 0000F5EA.0000000050BF6E3E.0000A98A Message-ID: <50BF6E6B.2070203@timon.net.nz> Date: Wed, 05 Dec 2012 19:55:23 +0400 From: Alexandr Matveev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: sleepq problem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:00:35 -0000 Hello, I'm writing a storage controller driver for 9.0-RELEASE-p4 and i'm using sleepq at initialization to sleep until command is processed by controller: struct command { <...> uint8_t done; }; void send_command_and_wait(struct command *cmd) { command->done = 0; send_command(cmd); for (;;) { sleepq_lock(&command->done); if (command->done) break; sleepq_add(&command->done, NULL, "wait for completion", SLEEPQ_SLEEP, 0); sleepq_wait(&command->done, 0); } sleepq_release(&command->done); } Interrupt handler calls special function when command is processed: void command_finish(struct command *cmd) { sleepq_lock(&command->done); command->done = 1; sleepq_signal(&command->done, SLEEPQ_SLEEP, 0, 0); sleepq_release(&command->done); } This code panics very often with following messages: Sleeping thread (tid 100248, pid 1859) owns a non-sleepable lock sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 send_command_and_wait() at send_command_with_retry+0x77 <...> panic: sleeping thread cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 propagate_priority() at propagate_priority+0x161 turnstile_wait() at turnstile_wait+0x1b8 _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 _mtx_lock_flags() at _mtx_lock_flags+0x96 softclock() at softclock+0x25e intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0x96 fork_exit() at fork_exit+0x11d fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80002fad00, rbp = 0 --- Where tid 100248 is my driver thread which is sleeping & waiting for command completion: db> show thread 100248 Thread 100243 at 0xfffffe0146aa98c0: proc (pid 1859): 0xfffffe02a6815488 name: kldload stack: 0xffffff8464bf2000-0xffffff8464bf5fff flags: 0x4 pflags: 0 state: INHIBITED: {SLEEPING} wmesg: wait for completion wchan: 0xffffff8464c1e244 priority: 127 container lock: sleepq chain (0xffffffff81101af8) But I can't understand what goes wrong. Sleepq chain lock is owned by the other thread: db> show lock 0xffffffff81101af8 class: spin mutex name: sleepq chain flags: {SPIN, RECURSE} state: {OWNED} owner: 0xfffffe0008377000 (tid 100019, pid 12, "swi4: clock") Unfortunately, I can't find any examples of using sleepq in drivers. What am I missing or don't understand? -- Alexandr Matveev From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 16:20:05 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF7843E4 for ; Wed, 5 Dec 2012 16:20:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4458F8FC13 for ; Wed, 5 Dec 2012 16:20:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA15660; Wed, 05 Dec 2012 18:20:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50BF7431.8080109@FreeBSD.org> Date: Wed, 05 Dec 2012 18:20:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexandr Matveev Subject: Re: sleepq problem References: <50BF6E6B.2070203@timon.net.nz> In-Reply-To: <50BF6E6B.2070203@timon.net.nz> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:20:06 -0000 on 05/12/2012 17:55 Alexandr Matveev said the following: > Hello, > > I'm writing a storage controller driver for 9.0-RELEASE-p4 and i'm using > sleepq at initialization to sleep until command is processed by controller: > > struct command { > <...> > uint8_t done; > }; > > void send_command_and_wait(struct command *cmd) > { > command->done = 0; > > send_command(cmd); > > for (;;) { > sleepq_lock(&command->done); > if (command->done) > break; > sleepq_add(&command->done, NULL, "wait for completion", > SLEEPQ_SLEEP, 0); > sleepq_wait(&command->done, 0); > } > sleepq_release(&command->done); > } > > Interrupt handler calls special function when command is processed: > > void command_finish(struct command *cmd) > { > sleepq_lock(&command->done); > command->done = 1; > sleepq_signal(&command->done, SLEEPQ_SLEEP, 0, 0); > sleepq_release(&command->done); > } > > This code panics very often with following messages: > > Sleeping thread (tid 100248, pid 1859) owns a non-sleepable lock > sched_switch() at sched_switch+0xf1 > mi_switch() at mi_switch+0x170 > sleepq_wait() at sleepq_wait+0x44 > send_command_and_wait() at send_command_with_retry+0x77 > <...> > panic: sleeping thread > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > propagate_priority() at propagate_priority+0x161 > turnstile_wait() at turnstile_wait+0x1b8 > _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 > _mtx_lock_flags() at _mtx_lock_flags+0x96 > softclock() at softclock+0x25e > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > ithread_loop() at ithread_loop+0x96 > fork_exit() at fork_exit+0x11d > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80002fad00, rbp = 0 --- > > Where tid 100248 is my driver thread which is sleeping & waiting for command > completion: > db> show thread 100248 > Thread 100243 at 0xfffffe0146aa98c0: > proc (pid 1859): 0xfffffe02a6815488 > name: kldload > stack: 0xffffff8464bf2000-0xffffff8464bf5fff > flags: 0x4 pflags: 0 > state: INHIBITED: {SLEEPING} > wmesg: wait for completion wchan: 0xffffff8464c1e244 > priority: 127 > container lock: sleepq chain (0xffffffff81101af8) > > But I can't understand what goes wrong. Sleepq chain lock is owned by > the other thread: > db> show lock 0xffffffff81101af8 > class: spin mutex > name: sleepq chain > flags: {SPIN, RECURSE} > state: {OWNED} > owner: 0xfffffe0008377000 (tid 100019, pid 12, "swi4: clock") > > Unfortunately, I can't find any examples of using sleepq in drivers. > What am I missing or don't understand? > You should not use sleepq, it's too low level. See locking(9) and follow references from there. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 16:55:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A324D2B; Wed, 5 Dec 2012 16:55:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 582828FC19; Wed, 5 Dec 2012 16:55:41 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 91F22B982; Wed, 5 Dec 2012 11:55:40 -0500 (EST) From: John Baldwin To: Ryan Stone Subject: Re: kernel module parallel build? Date: Wed, 5 Dec 2012 11:42:17 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <5083D84E.50903@freebsd.org> <201212041052.51476.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201212051142.18361.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Dec 2012 11:55:40 -0500 (EST) Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current , Andre Oppermann X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:55:41 -0000 On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: > On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin wrote: > > > Hmm, I certainly see the module directories being built in parallel. Some > > of > > the make jobs may not be as obvious since links are silent (no output > > unless > > there is an error). > > > > > This is definitely not the behaviour that I see trying to build any version > of FreeBSD. I see the same behaviour as Andre: the depend and all targets > both iterate through the module directories sequentially. It never builds > two module subdirectories concurrently. Hmm, I think I was confused by seeing kernel builds intermingle with the associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see similar things in world builds where I will see parallel builds of bin vs sbin vs usr.bin vs usr.sbin, but within each of those directories the builds go sequentially. I think you would need to change bsd.subdir.mk if you want to fix this. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 17:10:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8CC411D; Wed, 5 Dec 2012 17:10:55 +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 5558B8FC12; Wed, 5 Dec 2012 17:10:54 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so6702637obc.13 for ; Wed, 05 Dec 2012 09:10:53 -0800 (PST) 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=XYAPddngr9L7fJ9VydupsjPLhbU1hX7bwVFule992OQ=; b=LNBm3PrJ48NIH1ZuVRPSnlC2IylHKfVpkobZqUghiLH8xUjUpgMcz5hmvRo5rg5Ki7 19YXppLJn6JO0s9X+7TbNYQj2PU0NBflCE4vEV67KGweiSitx4gfw8BVRzK5Qj6DOUDd XMu3s+OLYKQ8Be426AbdetH68YDwyLu7huK1666oaMpNUdMEhActwYsj6xtNQST9yK7U fGTfQEgwNANIfVAyersLtV4NnFGE6DPoVVqv3AcISQV11IVPE1a8q/EBgAwQzWdXa34X ca6Yn7RtAJ0IiC0s6hjqmv1WJDV3YwJEtcg33VHk3tUduvAmv07wMgzLSRKP1uURRmv+ NM+w== MIME-Version: 1.0 Received: by 10.60.21.167 with SMTP id w7mr14303488oee.18.1354727453242; Wed, 05 Dec 2012 09:10:53 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 5 Dec 2012 09:10:53 -0800 (PST) In-Reply-To: <201212051142.18361.jhb@freebsd.org> References: <5083D84E.50903@freebsd.org> <201212041052.51476.jhb@freebsd.org> <201212051142.18361.jhb@freebsd.org> Date: Wed, 5 Dec 2012 09:10:53 -0800 Message-ID: Subject: Re: kernel module parallel build? From: Garrett Cooper To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Andre Oppermann , FreeBSD Current , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:10:55 -0000 On Wed, Dec 5, 2012 at 8:42 AM, John Baldwin wrote: > On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: >> On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin wrote: >> >> > Hmm, I certainly see the module directories being built in parallel. Some >> > of >> > the make jobs may not be as obvious since links are silent (no output >> > unless >> > there is an error). >> > >> > >> This is definitely not the behaviour that I see trying to build any version >> of FreeBSD. I see the same behaviour as Andre: the depend and all targets >> both iterate through the module directories sequentially. It never builds >> two module subdirectories concurrently. > > Hmm, I think I was confused by seeing kernel builds intermingle with the > associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see > similar things in world builds where I will see parallel builds of bin vs sbin > vs usr.bin vs usr.sbin, but within each of those directories the builds go > sequentially. I think you would need to change bsd.subdir.mk if you want to > fix this. Correct: 45 @${_+_}for entry in ${SUBDIR}; do \ ^^^^^^^^^^^^^^^^^^^ This is where things get serialized ^^^^^^^^^^^^^^^^^^^^^^^^ 46 if test -d ${.CURDIR}/$${entry}.${MACHINE_ARCH}; then \ Same thing applies for buildkernel building modules because it just wraps around bsd.subdir.mk in sys/modules/Makefile . Enhancing it to be parallel would introduce potential races. Some of the work sjg's doing with meta make will make this unnecessary from a buildworld perspective, but I'm not sure about buildkernel. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 17:39:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 461A67A3 for ; Wed, 5 Dec 2012 17:39:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ye0-f182.google.com (mail-ye0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA7988FC0C for ; Wed, 5 Dec 2012 17:39:45 +0000 (UTC) Received: by mail-ye0-f182.google.com with SMTP id q5so941135yen.13 for ; Wed, 05 Dec 2012 09:39:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=GoSbY9kltS9CJ5mQfqSwT59gwKFwCcTFcRdRvRq6xhc=; b=Bh/CTOCuTqKCXzFjVUfk3uTxjZ2Tl8we6nyAdKM5+x35wpSoFEZ/PMl+I/hVZRyW2x 004l7Cyrs3JGXrbUknJmiB/asHexJAuwQ71KSHKXKN35mPSS/he4WEs2AKhvxDfk4B86 KVdy1LypXl+IFsHG7WDhX/92vpd0q1ta/Eko8JP86V2b6YZmdAhQQDMHjttXQg+bczfd FRtHjtKg/notd196Lb89i+rBvNhEZeaiQIQ01cO6AzmZwpXRvvW+t38THeGz1q8MSiWt IfAC3hZ1eegj+HeVCUfoBArZLXxRgVt0lLAL6DVOh7zbJyUEzny4iZb0DRjplvGaVVX/ 5/qA== Received: by 10.236.138.10 with SMTP id z10mr21233511yhi.39.1354729179647; Wed, 05 Dec 2012 09:39:39 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id v4sm5258863ank.9.2012.12.05.09.39.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 09:39:38 -0800 (PST) Sender: Warner Losh Subject: Re: kernel module parallel build? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201212051142.18361.jhb@freebsd.org> Date: Wed, 5 Dec 2012 10:39:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EC857C9-4C1B-467D-8499-B493401B64BC@bsdimp.com> References: <5083D84E.50903@freebsd.org> <201212041052.51476.jhb@freebsd.org> <201212051142.18361.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlh8lzLIZdW85w94NCHNI99d/HNWgcfFTjO5byeWCC3KLRpCz1NtVcmx8vqd/hp9cVGXKET Cc: "freebsd-hackers@freebsd.org" , Andre Oppermann , FreeBSD Current , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:39:46 -0000 On Dec 5, 2012, at 9:42 AM, John Baldwin wrote: > On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: >> On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin = wrote: >>=20 >>> Hmm, I certainly see the module directories being built in parallel. = Some >>> of >>> the make jobs may not be as obvious since links are silent (no = output >>> unless >>> there is an error). >>>=20 >>>=20 >> This is definitely not the behaviour that I see trying to build any = version >> of FreeBSD. I see the same behaviour as Andre: the depend and all = targets >> both iterate through the module directories sequentially. It never = builds >> two module subdirectories concurrently. >=20 > Hmm, I think I was confused by seeing kernel builds intermingle with = the=20 > associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think = I see=20 > similar things in world builds where I will see parallel builds of bin = vs sbin=20 > vs usr.bin vs usr.sbin, but within each of those directories the = builds go=20 > sequentially. I think you would need to change bsd.subdir.mk if you = want to=20 > fix this. The builds are in parallel, just that the parallelism is low because it = is only parallel within the module being built. Would love to see a fix. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 23:52:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4F85687 for ; Wed, 5 Dec 2012 23:52:00 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5F08FC13 for ; Wed, 5 Dec 2012 23:52:00 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so49904wib.13 for ; Wed, 05 Dec 2012 15:51:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=qU6ogtwuOd174fzk6RQ+Um64qx0a4rOW8X/FXj4rDt8=; b=i5BdvGhY53+kBobPT7mRJTKAUFxN3EcnotyMyiCkj3sfSWJWG5z8eca/EXKd+sB9zk c9rwDwNi5RNMhdJugSP0EAs3fC6Gufagc1RqsiXkWjJi3Xzu2EsizzsuCo294jt1oli4 sJLlEfCgvVhglBFwWicj0BWIgxPwkEHtF4UWVSh8C2MR1W0u3dSxoeGrNZhQawTGpnMv RyCGm8KWaCvF9zze1uiRxf6ojzc7JI/d+JEhA6aioNr6fzG608Z7f43W8GA4GZX6dq5t 1v/jWq/y35QzbRIm5uZY7ptxyJytBxnBpZx5FM/YuEwqDxQ+Lq/pndzJN5gPNy0CggUF dEuA== Received: by 10.216.141.134 with SMTP id g6mr7062179wej.52.1354751519440; Wed, 05 Dec 2012 15:51:59 -0800 (PST) Received: from [10.9.246.181] ([92.90.20.47]) by mx.google.com with ESMTPS id dw4sm8657137wib.1.2012.12.05.15.51.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 15:51:58 -0800 (PST) References: <5083D84E.50903@freebsd.org> <201212041052.51476.jhb@freebsd.org> <201212051142.18361.jhb@freebsd.org> <0EC857C9-4C1B-467D-8499-B493401B64BC@bsdimp.com> In-Reply-To: <0EC857C9-4C1B-467D-8499-B493401B64BC@bsdimp.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <20E25F79-2C53-45FD-BB7F-060AC9B26245@my.gd> X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Subject: Re: kernel module parallel build? Date: Thu, 6 Dec 2012 00:51:17 +0100 To: Warner Losh X-Gm-Message-State: ALoCoQk4bEuFTohImoMcG6J3FRb7JYrFR2KRNymEaocNvNl87W39Jic2n3LrjhHffKvjHHKJafY4 Cc: "freebsd-hackers@freebsd.org" , Ryan Stone , FreeBSD Current , AndreOppermann X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:52:01 -0000 On 5 Dec 2012, at 18:39, Warner Losh wrote: >=20 > On Dec 5, 2012, at 9:42 AM, John Baldwin wrote: >=20 >> On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: >>> On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin wrote: >>>=20 >>>> Hmm, I certainly see the module directories being built in parallel. S= ome >>>> of >>>> the make jobs may not be as obvious since links are silent (no output >>>> unless >>>> there is an error). >>>>=20 >>>>=20 >>> This is definitely not the behaviour that I see trying to build any vers= ion >>> of FreeBSD. I see the same behaviour as Andre: the depend and all targe= ts >>> both iterate through the module directories sequentially. It never buil= ds >>> two module subdirectories concurrently. >>=20 >> Hmm, I think I was confused by seeing kernel builds intermingle with the=20= >> associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I s= ee=20 >> similar things in world builds where I will see parallel builds of bin vs= sbin=20 >> vs usr.bin vs usr.sbin, but within each of those directories the builds g= o=20 >> sequentially. I think you would need to change bsd.subdir.mk if you want= to=20 >> fix this. >=20 > The builds are in parallel, just that the parallelism is low because it is= only parallel within the module being built. Would love to see a fix. >=20 > Warner >=20 All trolling aside, I believe an awesome fix to be setting module override i= n /etc/make.conf to only build the 4-5 specific modules one needs. To be honest I think this configuration tweak should be advertised a bit mor= e as it definitely speeds up kernel builds. I would be happy to check if this is advertised in the handbook in the "rebu= ilding kernel" section and enhance its visibility if required. I can provide en_US and fr_FR.= From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 5 23:59:51 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 515D58BA for ; Wed, 5 Dec 2012 23:59:51 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D418F8FC14 for ; Wed, 5 Dec 2012 23:59:50 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so4038521eek.13 for ; Wed, 05 Dec 2012 15:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=v+ZiqTe0a9xZYz7hmJ5N7ma+nc5XIYDk6NkwioOf0HQ=; b=S2BwWkupH8Hycbf9H9RBcapSAcB3aHhdxTEuh/GDwQwB36ykCPWDwG7Kj2eOXVQaTB JlmcJ45g+GNwtg8TTufNmSr5BgqWMxwl+zxWCt+D+GTOTMl2ZSh3Dw9X3LxLRpS5RlEJ hbH2fvgI+Y/YxIb7RIr9GstkMQoQVBAQ/BSY3ceIQ2rPUXRxh2lxdPYoKwQWFHH/NcEc FK+0mc44G3iQuDcHvUei8lT9IZLtpe8mlklnQViQam8vNjFrJtQgve3YwPNpgI6VRus2 2ktyQ3tVLwTvQe+RfyOSF2vnw0bydfFfzbBn0WQclioRCSGHRE9LkRewdU9fH2Ut6bVF 2VRA== MIME-Version: 1.0 Received: by 10.14.198.67 with SMTP id u43mr66689408een.7.1354751989627; Wed, 05 Dec 2012 15:59:49 -0800 (PST) Received: by 10.14.3.133 with HTTP; Wed, 5 Dec 2012 15:59:49 -0800 (PST) Date: Wed, 5 Dec 2012 15:59:49 -0800 Message-ID: Subject: KVERIFY for non-debug invariants? From: Vijay Singh To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:59:51 -0000 All. KASSERT() is a really need way of expressing invariants when INVARIANTS is defined. However for regular, non-INVARIANTS code folks have the typical if() panic() combos, or private macros. Would a KVERIFY() that does this in non-INVARIANTS code make sense? -vijay From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 00:28:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E9F863A; Thu, 6 Dec 2012 00:28:37 +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 D01728FC0C; Thu, 6 Dec 2012 00:28:36 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so7495923oag.13 for ; Wed, 05 Dec 2012 16:28:36 -0800 (PST) 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=ak54N44hEGocepL0dmjasupBIMowA6PFKbHFCOZ7Q6c=; b=W1jRiaduyjqadlhuKr3tdMQJwT2z1cpKvb3Zz/4qf6WSuOpJ64Qb1i1fHc6BK6ejL5 lIMssEjepEdYeb6FgSHC9wfpnryC/mG27Xw8QjmmPwGA/dyYxYBWNlVIe/6ceNheKlTk glAUTVp9IeqeFbabH5KK/SRpSSP1Y762hcBvfa5oVyel/TBLif7Pht5rtjzZAaFiFO9T kcR0d/fsGJRnrE01aQh/N2vFt6XvxsrS4jrGHJkiDJHR3CjPdfMQoOfiG93KQ8wb3Cwe rQ8rfAMLJDztZnJs+60PK1/Pg4KB7mmlqghUulS+2pTZdGen2KXpZqK4dRwIFI3xKEmm WxkA== MIME-Version: 1.0 Received: by 10.60.170.114 with SMTP id al18mr15627561oec.56.1354753716399; Wed, 05 Dec 2012 16:28:36 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 5 Dec 2012 16:28:36 -0800 (PST) In-Reply-To: <20E25F79-2C53-45FD-BB7F-060AC9B26245@my.gd> References: <5083D84E.50903@freebsd.org> <201212041052.51476.jhb@freebsd.org> <201212051142.18361.jhb@freebsd.org> <0EC857C9-4C1B-467D-8499-B493401B64BC@bsdimp.com> <20E25F79-2C53-45FD-BB7F-060AC9B26245@my.gd> Date: Wed, 5 Dec 2012 16:28:36 -0800 Message-ID: Subject: Re: kernel module parallel build? From: Garrett Cooper To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , AndreOppermann , FreeBSD Current , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:28:37 -0000 On Wed, Dec 5, 2012 at 3:51 PM, Damien Fleuriot wrote: ... > All trolling aside, I believe an awesome fix to be setting module override in /etc/make.conf to only build the 4-5 specific modules one needs. > > To be honest I think this configuration tweak should be advertised a bit more as it definitely speeds up kernel builds. > > I would be happy to check if this is advertised in the handbook in the "rebuilding kernel" section and enhance its visibility if required. > > I can provide en_US and fr_FR. +1. Please write it up if you can; it's much quicker/better than the kitchen sink approach if you know what you're doing and don't have to build for a large set of platforms. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 02:39:59 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96296D88 for ; Thu, 6 Dec 2012 02:39:59 +0000 (UTC) (envelope-from pete.chou@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 077D78FC0C for ; Thu, 6 Dec 2012 02:39:58 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so6149242lah.13 for ; Wed, 05 Dec 2012 18:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=GE1Yfm5bl5y+GKXVijFItiEiY+3DCx8P+xsaw0VwR7o=; b=utIGt4m4h7isgpi64Us/RGEZG6TeY+XpXYtA9FkTI72CFlrhcHdoMoJTsqpgjso2QS fZnssjuOwIbCi2x0cvanBudNwzpuF2L0Ys4Ni/Zm1C9fAoOo9bMQahvRvKmU0mAeeaSE MY4ta8I7UTzCpk2zrecszFntr+vwy90cWS+w/dzi3kIfksbCTrLAZKp/QD7ziIHoDS4V dvVrbxnY1d9Bi9UkkhjmcCMDWZAhSWmyfSFzXST77798xCa31zr9cHilhQB1wC9Gn1/2 f3e/LeXLsjt7u7Q70+6PJjjfF20bBWk/m6ZTHPukO6/C/+1KMUdBK9IKWerRNmo3/m5V yozA== Received: by 10.112.44.161 with SMTP id f1mr241708lbm.29.1354761597503; Wed, 05 Dec 2012 18:39:57 -0800 (PST) MIME-Version: 1.0 Sender: pete.chou@gmail.com Received: by 10.114.69.131 with HTTP; Wed, 5 Dec 2012 18:39:27 -0800 (PST) In-Reply-To: <20121204191140.GA56790@pix.net> References: <779286D2-F710-45FF-8C38-59513B5C1B7D@cederstrand.dk> <20121204191140.GA56790@pix.net> From: pete Date: Thu, 6 Dec 2012 10:39:27 +0800 X-Google-Sender-Auth: CXaIDgx_S-gvsWWyLmjNdbp52Yg Message-ID: Subject: Re: [CFT/RFC] Make crunched compatible with external linkers To: Kurt Lidl X-Mailman-Approved-At: Thu, 06 Dec 2012 03:18:21 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers , Erik Cederstrand X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 02:39:59 -0000 On Wed, Dec 5, 2012 at 3:11 AM, Kurt Lidl wrote: > On Tue, Dec 04, 2012 at 11:06:56AM +0100, Erik Cederstrand wrote: > > Hello hackers, > > > > The following PR patches crunchide(1) to accept object files produced by > the gold and mclinker linkers: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F174011 > > > > On behalf of the submitter, I'd like to request a review of the patch, > and testing of crunchide/crunchgen especially on SPARC and ARM. > > I applied this patch to a 9/stable source tree, and was able to > "buildworld" with it in place, on my sparc64 machine. > > I know that's not a great test case, but the patched binary > is good enough to generate the objects that are needed for the > 'rescue' binary. And that binary runs at least a trivial test > of '/usr/obj/usr/src/rescue/rescue/rescue ifconfig -a' and > produces correct output. > > -Kurt > Really thanks for your help! This patch is for crunchide to handle ELF object file in a more general way, but not be limited to the custom section layout (i.e., section headers, .symtab, and then .strtab are @EOF). And if we are still using ld(1), I think the patched crunchide should produce exactly the same output as before. Then the rescue binary would also be the same. I checked and verified the intermediate object files and rescue binary (via binary diff) on X86 FreeBSD 9.0. If you can also kindly help check this on different archs and feedback, I think the result will be very helpful. Thanks, Pete From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 09:22:07 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E4F9486; Thu, 6 Dec 2012 09:22:07 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id B50B88FC0C; Thu, 6 Dec 2012 09:22:06 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 9CE181396F5; Thu, 6 Dec 2012 11:22:03 +0200 (EET) Date: Thu, 6 Dec 2012 11:22:03 +0200 From: Jaakko Heinonen To: freebsd-hackers@FreeBSD.org Subject: calendar(1) regressions Message-ID: <20121206092202.GA2182@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: edwin@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:22:07 -0000 Hi, Unfortunately r205821 [1] has caused several regressions to calendar(1). Relevant PRs: bin/157718 bin/162211 bin/168785 bin/170930 Some regressions were fixed in summer 2011 but they are still lacking MFCs. Is anyone aware of possible problems that reverting calendar(1) to pre-r205821 version would cause? (Of course excluding the actual calendar files.) [1] http://svnweb.freebsd.org/base?view=revision&revision=205821 -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 09:26:26 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 820B96EF for ; Thu, 6 Dec 2012 09:26:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 553F08FC15 for ; Thu, 6 Dec 2012 09:26:26 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CE23246B2D; Thu, 6 Dec 2012 04:26:25 -0500 (EST) Date: Thu, 6 Dec 2012 09:26:25 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vijay Singh Subject: Re: KVERIFY for non-debug invariants? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:26:26 -0000 On Wed, 5 Dec 2012, Vijay Singh wrote: > All. KASSERT() is a really need way of expressing invariants when INVARIANTS > is defined. However for regular, non-INVARIANTS code folks have the typical > if() panic() combos, or private macros. Would a KVERIFY() that does this in > non-INVARIANTS code make sense? I'd certainly be fine with something like this. It might be worth posting to arch@ with a code example, as hackers@ has a subset of the potentially interested audience. INVARIANTS has got a bit heavier-weight over the years -- the main thing I run into in higher-performance scenarios is its additional UMA debugging, which causes a global lock to be acquired during sanity checks. It might be worth our pondering adding a new configure option for particularly slow invariant tests -- e.g., INVARIANTS_SLOW ... or maybe just INVARIANTS_UMA. However, that's a different issue. (I sort of feel that things labeled "assert" should be something we can turn on in production... so maybe INVARIANTS/KASSERT mission-creep is the issue.) Robert From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 15:19:08 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96D60A73 for ; Thu, 6 Dec 2012 15:19:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C88B28FC08 for ; Thu, 6 Dec 2012 15:19:07 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA29608 for ; Thu, 06 Dec 2012 17:19:00 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C0B763.8000004@FreeBSD.org> Date: Thu, 06 Dec 2012 17:18:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD Hackers Subject: huge ktr buffer X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:19:08 -0000 So I configured a kernel with the following option: options KTR_ENTRIES="(1024UL*1024)" then booted the kernel and did $ sysctl debug.ktr.clear=1 and got an insta-reboot. No panic, nothing, just a reset. I suspect that the huge static buffer resulting from the above option could be a cause. But I would like to understand the details, if possible. Also, perhaps ktr could be a little bit more sophisticated with its buffer than just using a static array. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 15:43:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8126C1E9; Thu, 6 Dec 2012 15:43:39 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE288FC08; Thu, 6 Dec 2012 15:43:38 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so6579483vbi.18 for ; Thu, 06 Dec 2012 07:43:38 -0800 (PST) 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=r2AlEqiEgz/EZUmxzFTzh9MW8dPGwk5ABCSWKcNYI4g=; b=Q7ChwIlm7Si8WudTTxf+iepJ0uUA54ICPMK2jZ5WUgUk9GS+XifainE6hcEwhu581a rHSAducgqcebB6dMP38tqjUhvCgth5Z+ZRfoLxx0FcNVWuFIMDP2uoh5JNutSO+AIPUo couyb9J5zn8YiwDUI8fRjuAv/2QaXg0YMf9opcJtOhKvxOYzDdAPjbXlvhXCZenmUBah 69cxKmlJCsZCCNyFLtmPj7T6J7RQoAuPR+tPKAlc0tAsAwY6TB0HG4ZU28VtO/9/z/gD EivLpIM9IzkeJc2Crwl6WTV8umaTfwEYLDYgHKxUKfSz7JLx6Wojh8JDpXDLz3G0u3/z zARQ== MIME-Version: 1.0 Received: by 10.52.27.138 with SMTP id t10mr1227299vdg.81.1354808618362; Thu, 06 Dec 2012 07:43:38 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Thu, 6 Dec 2012 07:43:38 -0800 (PST) In-Reply-To: <50C0B763.8000004@FreeBSD.org> References: <50C0B763.8000004@FreeBSD.org> Date: Thu, 6 Dec 2012 16:43:38 +0100 X-Google-Sender-Auth: Y1auB49ZZ8ANa9HiOvQIzllNogI Message-ID: Subject: Re: huge ktr buffer From: Davide Italiano To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: alc@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:43:39 -0000 On Thu, Dec 6, 2012 at 4:18 PM, Andriy Gapon wrote: > > So I configured a kernel with the following option: > options KTR_ENTRIES="(1024UL*1024)" > then booted the kernel and did > $ sysctl debug.ktr.clear=1 > and got an insta-reboot. > > No panic, nothing, just a reset. > > I suspect that the huge static buffer resulting from the above option could be a > cause. But I would like to understand the details, if possible. > > Also, perhaps ktr could be a little bit more sophisticated with its buffer than > just using a static array. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" It was a while ago, but running r238886 built using the following kernel configuration file: http://people.freebsd.org/~davide/DEBUG I found a similar issue. The machine paniced: fatal trap 12 with interrupt disable in early boot (even before the appareance of the Berkley logo). Basically, my configuration file is just GENERIC with slight modifications, in particular debugging options (WITNESS, INVARIANTS, etc..) turned on and the following KTR options enabled: options KTR options KTR_COMPILE=(KTR_CALLOUT|KTR_PROC) options KTR_MASK=(KTR_CALLOUT|KTR_PROC) options KTR_ENTRIES=524288 It seems the issue is related to KTR itself, and in particular to the value of KTR_ENTRIES. As long as this value is little (e.g. 2048) everything works fine and the boot sequence ends. If I choose 524288 (the value you can also see from the kernel conf file) the fatal trap occurs. Even though it was really difficult to me to get some informations because the fail happens too early, I put some printf() within the code and I isolated the point in which the kernel dies: (sys/amd64/amd64/machdep.c, in getmemsize()) 1540 /* 1541 * map page into kernel: valid, read/write,non-cacheable 1542 */ 1543 *pte = pa | PG_V | PG_RW | PG_N; As also Alan suggested, a way to workaround the problem is to increase NKPT value (e.g. from 32 to 64). Obviously, this is not a proper fix. For a proper fix the kernel needs to be able to dynamically set the size of NKPT. In this particular case, this wouldn't be too hard, but there is a different case, where people preload a large memory disk image at boot time that isn't so easy to fix. Thanks, Davide From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 17:48:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3301E455; Thu, 6 Dec 2012 17:48:35 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id E9E0F8FC16; Thu, 6 Dec 2012 17:48:34 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 7F4B04601F1; Thu, 6 Dec 2012 11:48:28 -0600 (CST) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 7D2F74601E3; Thu, 6 Dec 2012 11:48:28 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 1omJ_0G2pIoM; Thu, 6 Dec 2012 11:48:28 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id EF93F460160; Thu, 6 Dec 2012 11:48:27 -0600 (CST) Message-ID: <50C0DA60.9090706@rice.edu> Date: Thu, 06 Dec 2012 11:48:16 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Davide Italiano Subject: Re: huge ktr buffer References: <50C0B763.8000004@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, FreeBSD Hackers , Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:48:35 -0000 On 12/06/2012 09:43, Davide Italiano wrote: > On Thu, Dec 6, 2012 at 4:18 PM, Andriy Gapon wrote: >> So I configured a kernel with the following option: >> options KTR_ENTRIES="(1024UL*1024)" >> then booted the kernel and did >> $ sysctl debug.ktr.clear=1 >> and got an insta-reboot. >> >> No panic, nothing, just a reset. >> >> I suspect that the huge static buffer resulting from the above option could be a >> cause. But I would like to understand the details, if possible. >> >> Also, perhaps ktr could be a little bit more sophisticated with its buffer than >> just using a static array. >> >> -- >> Andriy Gapon >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > It was a while ago, but running r238886 built using the following > kernel configuration file: > http://people.freebsd.org/~davide/DEBUG I found a similar issue. > The machine paniced: fatal trap 12 with interrupt disable in early boot > (even before the appareance of the Berkley logo). > Basically, my configuration file is just GENERIC with slight > modifications, in particular debugging options (WITNESS, INVARIANTS, > etc..) turned on and the following KTR options enabled: > > options KTR > options KTR_COMPILE=(KTR_CALLOUT|KTR_PROC) > options KTR_MASK=(KTR_CALLOUT|KTR_PROC) > options KTR_ENTRIES=524288 > > It seems the issue is related to KTR itself, and in particular to the > value of KTR_ENTRIES. As long as this value is little (e.g. 2048) > everything works fine and the boot sequence ends. If I choose 524288 > (the value you can also see from the kernel conf file) the fatal trap > occurs. > > Even though it was really difficult to me to get some informations > because the fail happens too early, I put some printf() within the > code and I isolated the point in which the kernel dies: > (sys/amd64/amd64/machdep.c, in getmemsize()) > > 1540 /* > 1541 * map page into kernel: valid, read/write,non-cacheable > 1542 */ > 1543 *pte = pa | PG_V | PG_RW | PG_N; > > > As also Alan suggested, a way to workaround the problem is to increase > NKPT value (e.g. from 32 to 64). Obviously, this is not a proper fix. > For a proper fix the kernel needs to be able to dynamically set the > size of NKPT. In this particular case, this wouldn't be too hard, but > there is a different case, where people preload a large memory disk > image at boot time that isn't so easy to fix. Andriy makes a good suggestion. One that I think should be easy to implement. The KTR code already supports the use of a dynamically allocated KTR buffer. (See sysctl_debug_ktr_entries().) Let's take advantage of this. Place a cap on the size of the (compile-time) statically allocated buffer. However, use this buffer early in the kernel initialization process, specifically, up until SI_ORDER_KMEM has completed. At that point, switch to a dynamically allocated buffer and copy over the entries from the statically allocated buffer. Relatively speaking, SI_ORDER_KMEM is early enough in the boot process, that I doubt many people wanting an enormous KTR buffer will be impacted by the cap. In fact, I think you could implement overflow detection without pessimizing the KTR code. Alan P.S. There are other reasons that having an enormous statically allocated array in the kernel is undesirable. The first that comes to mind is that it eats up memory at low physical addresses, which is sometimes needed for special purposes. So, I think there are good reasons besides the NKPT issue to shift the KTR code to dynamic allocation. From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 19:28:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE049697; Thu, 6 Dec 2012 19:28:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BDAA8FC13; Thu, 6 Dec 2012 19:28:44 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 00475B91A; Thu, 6 Dec 2012 14:28:43 -0500 (EST) From: John Baldwin To: Damien Fleuriot Subject: Re: kernel module parallel build? Date: Thu, 6 Dec 2012 11:19:30 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <5083D84E.50903@freebsd.org> <0EC857C9-4C1B-467D-8499-B493401B64BC@bsdimp.com> <20E25F79-2C53-45FD-BB7F-060AC9B26245@my.gd> In-Reply-To: <20E25F79-2C53-45FD-BB7F-060AC9B26245@my.gd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212061119.30524.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 06 Dec 2012 14:28:44 -0500 (EST) Cc: "freebsd-hackers@freebsd.org" , Ryan Stone , FreeBSD Current , AndreOppermann X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:28:44 -0000 On Wednesday, December 05, 2012 6:51:17 pm Damien Fleuriot wrote: > > On 5 Dec 2012, at 18:39, Warner Losh wrote: > > > > > On Dec 5, 2012, at 9:42 AM, John Baldwin wrote: > > > >> On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: > >>> On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin wrote: > >>> > >>>> Hmm, I certainly see the module directories being built in parallel. Some > >>>> of > >>>> the make jobs may not be as obvious since links are silent (no output > >>>> unless > >>>> there is an error). > >>>> > >>>> > >>> This is definitely not the behaviour that I see trying to build any version > >>> of FreeBSD. I see the same behaviour as Andre: the depend and all targets > >>> both iterate through the module directories sequentially. It never builds > >>> two module subdirectories concurrently. > >> > >> Hmm, I think I was confused by seeing kernel builds intermingle with the > >> associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see > >> similar things in world builds where I will see parallel builds of bin vs sbin > >> vs usr.bin vs usr.sbin, but within each of those directories the builds go > >> sequentially. I think you would need to change bsd.subdir.mk if you want to > >> fix this. > > > > The builds are in parallel, just that the parallelism is low because it is only parallel within the module being built. Would love to see a fix. > > > > Warner > > > > All trolling aside, I believe an awesome fix to be setting module override in /etc/make.conf to only build the 4-5 specific modules one needs. > > To be honest I think this configuration tweak should be advertised a bit more as it definitely speeds up kernel builds. > > I would be happy to check if this is advertised in the handbook in the "rebuilding kernel" section and enhance its visibility if required. > > I can provide en_US and fr_FR. Better than doing it in /etc/make.conf (or /etc/src.conf) is doing it direclty in the kernel config file itself via makeoptions MODULES_OVERRIDE="foo" You can use multiple of these (with +=) in a config file as well. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 21:58:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22B6595C for ; Thu, 6 Dec 2012 21:58:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D0FDC8FC13 for ; Thu, 6 Dec 2012 21:58:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAIABsUwVCDaFvO/2dsb2JhbABEhjS2dQQEgRRzgkiBAwgCDRkCS4g3oTSOUJJqgSKMMYIWgRMDiF+NJIlNhnqDEYIE X-IronPort-AV: E=Sophos;i="4.84,233,1355115600"; d="scan'208";a="3711414" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 06 Dec 2012 16:58:40 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E6B83B3EA2 for ; Thu, 6 Dec 2012 16:58:40 -0500 (EST) Date: Thu, 6 Dec 2012 16:58:40 -0500 (EST) From: Rick Macklem To: freebsd-hackers@freebsd.org Message-ID: <886101549.1211675.1354831120890.JavaMail.root@erie.cs.uoguelph.ca> Subject: any arch not pack uint32_t x[2]? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 21:58:43 -0000 Hi, The subject line pretty well says it. I am about ready to commit the NFSv4.1 client patches, but I had better ask this dump question first. Is there any architecture where: uint32_t x[2]; isn't packed? (Or, sizeof(x) != 8, if you prefer.) As you might have guessed, if the answer is "yes", I have some code fixin to do, rick From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 23:11:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 532EC2DC for ; Thu, 6 Dec 2012 23:11:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E47AC8FC08 for ; Thu, 6 Dec 2012 23:11:29 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB6NBM8E032697; Fri, 7 Dec 2012 01:11:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB6NBM8E032697 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB6NBMVv032696; Fri, 7 Dec 2012 01:11:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 7 Dec 2012 01:11:22 +0200 From: Konstantin Belousov To: Shrikanth Kamath Subject: Re: ELF symtab and ddbsymtab difference Message-ID: <20121206231122.GE3013@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hRQRnCc2hL38uoUj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:11:30 -0000 --hRQRnCc2hL38uoUj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 05, 2012 at 12:13:24PM +0530, Shrikanth Kamath wrote: > This is regarding the fields in the structure "elf_file_t" in link_elf.c. > For some kernel modules the symtab field is different from the ddbsymtab > field for some it is the same, would like to know what is the difference > between the two and how to enable ddbsymtab? Assuming we are talking about the link_elf.c and not about link_elf_obj.c. The symtab and ddbsymtab are first initialized from the dynamic symbol table in the module, and later, in the process of loading the module, if the non-dynamic symbol table is present, ddbsymtab is rewritten to point to the table. >=20 > Does enabling "-g" in CFLAGS make the binary build the ddbsymtab different > from symtab? No. It is strip done on the module which could result in the removal of the non-dynamic symtab. >=20 > The problem is lookup for some symbols in the kernel module that I built > returns with undefined, on inspecting it was getting a ENOENT from the > function > link_elf_lookup_symbol() > { > ... > /* If we have not found it, look at the full table (if loaded) */ > if (ef->symtab =3D=3D ef->ddbsymtab) > return (ENOENT); > ... > } It is not the problem. It just means that you dynamic symbol table does not contain the needed symbol, which is the problem. As a coincident, you also stripped your module, making the problem to be exposed. I guess that you should look at the EXPORT_SYMS feature of the module Makefiles. But I also remember there were some bugs. --hRQRnCc2hL38uoUj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQwSYZAAoJEJDCuSvBvK1B5bQP+gOsuyPIj4GrcOUt70uVDysS dRWogfQmrBS1CMxflHvEmeR7xvkPwdbYBlPyWcJ4sIKsjQ9GayELHJ+Hm2eD4F4J reuiG6uvBUBRbVaPMalGkjbZ1xgyJL5LAvc8avxlnFl9Hrw39c8gzse/+AZAB+O/ N3bJQ5YxNTXWrp5PZaSOMAuNpYxPLrfjuQxEkCjmDKZ9gbtUgSLrCsadQizrjQlt PojTy3kzTKdt9PM67ZMLI1ahLtOxpghuzZ96M5yJOwqFadpvg9XS5HHTDSu/0XoI gq2wdPEO4HYLoXnUszvgEZ1x3xzoLPD4V1Z6XG5PYKeei2BBK3cujYml3qz6LQ5L SVDjszyiUgi7j33+djaPZZHKiB1Jiti63Kw2t17G1miYlS2Q/LWS3H9ZXd1JuEm/ xcMr1jslMKFCfDa+W9dwYN3hGW4z3ypDmV31N/ZjHp0i982FXdA1BAQcZMBuyb5B 2xAJfvXomrzBXLXaGGsRMYjL+VMXnjkDb3rXSJOyWJP4FiFpVD++xPQehfFfKHtw eKD7mUXtQD0k1PsIHqZ3veHKrnLmW6RyhlCA7WkJ4dTS4bJiK5lW93vbaC/ikrTO RClUdHsjmOJcxu4buzOMYraOozuz56Z6ClbzbaqagqCrj/kP8h7F59g+en9uGnTJ jGeuWqCR8O3Y/YT3TOOE =bkzM -----END PGP SIGNATURE----- --hRQRnCc2hL38uoUj-- From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 06:05:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C697C89E for ; Fri, 7 Dec 2012 06:05:32 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF0D8FC13 for ; Fri, 7 Dec 2012 06:05:31 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so113031lah.13 for ; Thu, 06 Dec 2012 22:05:30 -0800 (PST) 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=x/IpW1l0sePx/cjzxYgEhQjDV8bW5tkJLXj64myYAcE=; b=pMaMJKcvpn+jPXoLJ/EbsA/yhD2rUCV8X/prZdI6i7smPaIjd5Q7tqL+sk/m6Nn4K+ 31AUftOWdI2/jesHzacjuQljkcZromADLhkjSRQP8Kcz143EGEZnGMthXi4pce2/nl2z t4y01flvdeceP1VYwrJWyDeTPIlH41YXwR+gf4CJgI4i5zbnafstc+jrfBX4kP5Bb3rq /a3X60IgLffz4+36LYVuS14toIJfiHxa6Iegjznl3vIuysKSnR98AXEVpyvG1Xu+2VAB dSLQKx5jeiYrYkJ1QBwUkiPXQU9xR+E9AiJIcdaBLQw/JLeYt58feuDSiDXnuoOQ58qF +q8Q== MIME-Version: 1.0 Received: by 10.152.108.42 with SMTP id hh10mr4314887lab.4.1354860330733; Thu, 06 Dec 2012 22:05:30 -0800 (PST) Received: by 10.112.139.71 with HTTP; Thu, 6 Dec 2012 22:05:30 -0800 (PST) In-Reply-To: <20121206231122.GE3013@kib.kiev.ua> References: <20121206231122.GE3013@kib.kiev.ua> Date: Fri, 7 Dec 2012 11:35:30 +0530 Message-ID: Subject: Re: ELF symtab and ddbsymtab difference From: Shrikanth Kamath To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 06:05:32 -0000 Thanks Konstantin, yeah I think there were two levels of strip happening, one removing the debug sections and another was removing the .strtab and .symtab. I have EXPORT_SYMS = YES in my Makefile but that was not helping as the variables in context are declared static (they are going into the .bss). Making it un-static helps or avoiding the second level strip helps too.. -- Shrikanth R K On Fri, Dec 7, 2012 at 4:41 AM, Konstantin Belousov wrote: > On Wed, Dec 05, 2012 at 12:13:24PM +0530, Shrikanth Kamath wrote: >> This is regarding the fields in the structure "elf_file_t" in link_elf.c. >> For some kernel modules the symtab field is different from the ddbsymtab >> field for some it is the same, would like to know what is the difference >> between the two and how to enable ddbsymtab? > Assuming we are talking about the link_elf.c and not about link_elf_obj.c. > The symtab and ddbsymtab are first initialized from the dynamic symbol > table in the module, and later, in the process of loading the module, if > the non-dynamic symbol table is present, ddbsymtab is rewritten to point > to the table. > >> >> Does enabling "-g" in CFLAGS make the binary build the ddbsymtab different >> from symtab? > No. It is strip done on the module which could result in the removal of the > non-dynamic symtab. > >> >> The problem is lookup for some symbols in the kernel module that I built >> returns with undefined, on inspecting it was getting a ENOENT from the >> function >> link_elf_lookup_symbol() >> { >> ... >> /* If we have not found it, look at the full table (if loaded) */ >> if (ef->symtab == ef->ddbsymtab) >> return (ENOENT); >> ... >> } > > It is not the problem. It just means that you dynamic symbol table does > not contain the needed symbol, which is the problem. As a coincident, > you also stripped your module, making the problem to be exposed. > > I guess that you should look at the EXPORT_SYMS feature of the module > Makefiles. But I also remember there were some bugs. From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 09:07:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0338EAAC; Fri, 7 Dec 2012 09:07:08 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id A10958FC13; Fri, 7 Dec 2012 09:07:07 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id qB7976q0008651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Dec 2012 03:07:06 -0600 Received: from [10.0.0.102] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 7 Dec 2012 03:07:05 -0600 Content-Type: text/plain; charset="us-ascii" Subject: Re: loader and ficl/Forth help MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske Date: Fri, 7 Dec 2012 01:07:04 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> To: FreeBSD Hackers X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-12-06_08:2012-12-06,2012-12-06,1970-01-01 signatures=0 Cc: Devin Teske X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 09:07:08 -0000 On Sun, Feb 24, 2008 at 14:21:24 -0800, Jeremy Chadwick wrote: > > On Sun, Feb 24, 2008 at 02:01:14PM -0800, Jeremy Chadwick wrote: > > ... I'll submit a PR for the whole thing. We can hash out > > details/improvements there. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D121064 >=20 I've made some improvements to the supplied patch. Said improvements should= address the previous issues that were preventing this from going in. Can someone test the newly-attached patch.txt and get back to me? --=20 Cheers, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 12:19:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44A0EF2A for ; Fri, 7 Dec 2012 12:19:23 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id E19818FC0C for ; Fri, 7 Dec 2012 12:19:22 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Tgwtk-0001HO-0w; Fri, 07 Dec 2012 14:19:20 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 45C9D1CC21; Fri, 7 Dec 2012 14:19:20 +0200 (EET) Date: Fri, 7 Dec 2012 14:19:20 +0200 From: Andrey Simonenko To: Rick Macklem Subject: Re: any arch not pack uint32_t x[2]? Message-ID: <20121207121920.GA17861@pm513-1.comsys.ntu-kpi.kiev.ua> References: <886101549.1211675.1354831120890.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <886101549.1211675.1354831120890.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-12-07 14:19:20 X-Connected-IP: 10.18.52.101:44477 X-Message-Linecount: 58 X-Body-Linecount: 43 X-Message-Size: 2586 X-Body-Size: 1895 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 12:19:23 -0000 On Thu, Dec 06, 2012 at 04:58:40PM -0500, Rick Macklem wrote: > Hi, > > The subject line pretty well says it. I am about ready > to commit the NFSv4.1 client patches, but I had better > ask this dump question first. > > Is there any architecture where: > uint32_t x[2]; > isn't packed? (Or, sizeof(x) != 8, if you prefer.) I had similar question some time ago, so I made some research in standards and got the following information ("WG14 N1548 Committee Draft" is used for references, exact definitions can be read in sections with numbers given in parentheses). Exact-width integer type intN_t is optional and designates a signed integer type with width N, without padding bits. Implementation cannot provide some intN_t types. The width of such integer types is given in bits. (7.20.1.1) An array type describes a contiguously allocated nonempty set of objects (6.2.5). (Some compilers allow to declare empty arrays with zero size.) The sizeof operator yields the size (in bytes) of its operand. When sizeof is applied to an operand that has type char, the result is 1. The sizeof operator can be used for computing numbers of elements in an array: sizeof(array) / sizeof(array[0]) (6.5.3.4). A byte consists of contiguous sequence of bits, number of bits in a byte is implementation defined (3.6). Using this information I think that sizeof(x) is equal to (2 * sizeof(x[0])) or (2 * sizeof(uint32_t)) and occupies exactly 64 bits in memory, but it is not necessarily equal to 8, since implementation can use different numbers of bits for one byte (or char). Also I think, that if an implementation supports uint8_t, then a pointer to uint8_t can be used for accessing each of 4 octets in a data of the uint32_t type. Please, correct these statements if they are wrong. There are "Everything you ever wanted to know about C types" series, that are related to this question. From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 15:39:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5ADDA98F; Fri, 7 Dec 2012 15:39:30 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B316C8FC13; Fri, 7 Dec 2012 15:39:29 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id qB7FdMUo019745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Dec 2012 09:39:22 -0600 Received: from [10.0.0.102] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 7 Dec 2012 09:39:21 -0600 Subject: Re: loader and ficl/Forth help MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/mixed; boundary="Apple-Mail=_0A50479D-638A-44CA-B3F7-F7F7D3339F14" From: Devin Teske In-Reply-To: <20121207102836.GA1808@a91-153-116-96.elisa-laajakaista.fi> Date: Fri, 7 Dec 2012 07:39:20 -0800 Message-ID: References: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> <20121207102836.GA1808@a91-153-116-96.elisa-laajakaista.fi> To: Jaakko Heinonen X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-12-06_08:2012-12-06,2012-12-06,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:39:30 -0000 --Apple-Mail=_0A50479D-638A-44CA-B3F7-F7F7D3339F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Thanks for testing Jaakko. Can you re-test with the attached patch? I cleaned things up a bit while addressing the problem that a later call to= f_double was un-doing the previous installation of the ASCII charset. This new patch should work (and I re-tested, having had ample sleep this ti= me). --=20 Thanks in advance, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --Apple-Mail=_0A50479D-638A-44CA-B3F7-F7F7D3339F14 Content-Disposition: attachment; filename="patch.txt" Content-Type: text/plain; name="patch.txt" Content-Transfer-Encoding: 7bit Index: support.4th =================================================================== --- support.4th (revision 242835) +++ support.4th (working copy) @@ -201,6 +201,42 @@ create last_module_option sizeof module.next allot : getenv? getenv -1 = if false else drop true then ; +\ determine if a word appears in a string, case-insensitive +: contains? ( addr1 len1 addr2 len2 -- 0 | -1 ) + 2 pick 0= if 2drop 2drop true exit then + dup 0= if 2drop 2drop false exit then + begin + begin + swap dup c@ dup 32 = over 9 = or + over 10 = or over 13 = or swap drop + while 1+ swap 1- repeat + swap 2 pick 1- over < + while + 2over 2over drop over compare-insensitive 0= if + 2 pick over = if 2drop 2drop true exit then + 2 pick tuck - -rot + swap over c@ dup 32 = + over 9 = or over 10 = or over 13 = or + swap drop if 2drop 2drop true exit then + then begin + swap dup c@ + dup 32 = over 9 = or over 10 = or over 13 = or + swap drop if false else true then 2 pick 0> and + while 1+ swap 1- repeat + swap + repeat + 2drop 2drop false +; + +: boot_serial? ( -- 0 | -1 ) + s" console" getenv dup -1 <> if + s" comconsole" 2swap contains? + else drop false then + s" boot_serial" getenv dup -1 <> if + s" YES" compare-insensitive 0= + else drop false then + or ( true if either console contains comconsole or boot_serial=YES ) +; + \ Private definitions vocabulary support-functions Index: frames.4th =================================================================== --- frames.4th (revision 242835) +++ frames.4th (working copy) @@ -12,6 +12,11 @@ variable rt_el variable rb_el variable fill +\ ASCII frames (used when serial console is detected) + 45 constant ascii_dash +124 constant ascii_pipe + 43 constant ascii_plus + s" arch-pc98" environment? [if] \ Single frames 149 constant sh_el @@ -63,7 +68,17 @@ s" arch-pc98" environment? [if] loop ; +: f_ascii ( -- ) ( -- ) \ set frames to ascii + ascii_dash h_el ! + ascii_pipe v_el ! + ascii_plus lt_el ! + ascii_plus lb_el ! + ascii_plus rt_el ! + ascii_plus rb_el ! +; + : f_single ( -- ) \ set frames to single + boot_serial? if f_ascii exit then sh_el h_el ! sv_el v_el ! slt_el lt_el ! @@ -73,6 +88,7 @@ s" arch-pc98" environment? [if] ; : f_double ( -- ) \ set frames to double + boot_serial? if f_ascii exit then dh_el h_el ! dv_el v_el ! dlt_el lt_el ! --Apple-Mail=_0A50479D-638A-44CA-B3F7-F7F7D3339F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Dec 7, 2012, at 2:28 AM, Jaakko Heinonen wrote: > On 2012-12-07, Devin Teske wrote: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D121064 >>>=20 >>=20 >> I've made some improvements to the supplied patch. Said improvements = should address the previous issues that were preventing this from going = in. >>=20 >> Can someone test the newly-attached patch.txt and get back to me? >=20 > I tried the latest patch in the PR and it didn't work for me. I have = the > following line in my /boot/loader.conf: >=20 > console=3D"comconsole" >=20 > Attached is a screenshot from the menu. It's still using non-ASCII > characters. >=20 > --=20 > Jaakko > --Apple-Mail=_0A50479D-638A-44CA-B3F7-F7F7D3339F14-- From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 19:27:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BAB1907; Fri, 7 Dec 2012 19:27:11 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9728FC12; Fri, 7 Dec 2012 19:27:10 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 263FD216581; Fri, 7 Dec 2012 21:27:00 +0200 (EET) Date: Fri, 7 Dec 2012 21:26:59 +0200 From: Jaakko Heinonen To: Devin Teske Subject: Re: loader and ficl/Forth help Message-ID: <20121207192659.GB1808@a91-153-116-96.elisa-laajakaista.fi> References: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> <20121207102836.GA1808@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:27:11 -0000 On 2012-12-07, Devin Teske wrote: > Can you re-test with the attached patch? Works for me. Thanks! http://people.freebsd.org/~jh/misc/menu-patched.png -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 19:41:19 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DE9AC2C for ; Fri, 7 Dec 2012 19:41:19 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 078EF8FC08 for ; Fri, 7 Dec 2012 19:41:18 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id qB7JfGHw094968; Fri, 7 Dec 2012 14:41:16 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id qB7JfG0B094967; Fri, 7 Dec 2012 14:41:16 -0500 (EST) (envelope-from lidl) Date: Fri, 7 Dec 2012 14:41:16 -0500 From: Kurt Lidl To: pete Subject: Re: [CFT/RFC] Make crunched compatible with external linkers Message-ID: <20121207194115.GA94794@pix.net> References: <779286D2-F710-45FF-8C38-59513B5C1B7D@cederstrand.dk> <20121204191140.GA56790@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers , Erik Cederstrand X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:41:19 -0000 On Thu, Dec 06, 2012 at 10:39:27AM +0800, pete wrote: > On Wed, Dec 5, 2012 at 3:11 AM, Kurt Lidl wrote: > > > On Tue, Dec 04, 2012 at 11:06:56AM +0100, Erik Cederstrand wrote: > > > Hello hackers, > > > > > > The following PR patches crunchide(1) to accept object files produced by > > the gold and mclinker linkers: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F174011 > > > > > > On behalf of the submitter, I'd like to request a review of the patch, > > and testing of crunchide/crunchgen especially on SPARC and ARM. > > > > I applied this patch to a 9/stable source tree, and was able to > > "buildworld" with it in place, on my sparc64 machine. > > > > I know that's not a great test case, but the patched binary > > is good enough to generate the objects that are needed for the > > 'rescue' binary. And that binary runs at least a trivial test > > of '/usr/obj/usr/src/rescue/rescue/rescue ifconfig -a' and > > produces correct output. > > > > -Kurt > > > > Really thanks for your help! > > This patch is for crunchide to handle ELF object file in a more general > way, but not be limited to the custom section layout (i.e., section > headers, .symtab, and then .strtab are @EOF). And if we are still using > ld(1), I think the patched crunchide should produce exactly the same output > as before. Then the rescue binary would also be the same. > > I checked and verified the intermediate object files and rescue binary (via > binary diff) on X86 FreeBSD 9.0. If you can also kindly help check this on > different archs and feedback, I think the result will be very helpful. Well, I updated my sparc64 machine's source tree to the latest stable/9 code, and then did two complete buildworld runs, one without the changes to the crunchide code, and second with the crunchide changes. Diffing the obj tree (selectively) shows: root@spork-143: diff -r usr.modified/src/rescue usr/src/rescue Files usr.modified/src/rescue/librescue/librescue.a and usr/src/rescue/librescue/librescue.a differ root@spork-144: md5 usr.modified/src/rescue/rescue/rescue usr/src/rescue/rescue/rescue MD5 (usr.modified/src/rescue/rescue/rescue) = 75fc2a1b06ae38df2be668eff7cec72e MD5 (usr/src/rescue/rescue/rescue) = 75fc2a1b06ae38df2be668eff7cec72e And: root@spork-143: diff -r usr.modified/src/usr.sbin/crunch usr/src/usr.sbin/crunch diff -r usr.modified/src/usr.sbin/crunch/crunchide/.depend usr/src/usr.sbin/crunch/crunchide/.depend 65,68d64 < /usr/obj/usr/src/tmp/usr/include/limits.h \ < /usr/obj/usr/src/tmp/usr/include/sys/limits.h \ < /usr/obj/usr/src/tmp/usr/include/machine/_limits.h \ < /usr/obj/usr/src/tmp/usr/include/sys/syslimits.h \ Files usr.modified/src/usr.sbin/crunch/crunchide/crunchide and usr/src/usr.sbin/crunch/crunchide/crunchide differ Files usr.modified/src/usr.sbin/crunch/crunchide/exec_elf64.o and usr/src/usr.sbin/crunch/crunchide/exec_elf64.o differ So, the crunchide binaries are different (as expected) and the resulting 'rescue' binary is identical. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 19:50:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46930E18; Fri, 7 Dec 2012 19:50:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB538FC12; Fri, 7 Dec 2012 19:50:38 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so884412lbb.13 for ; Fri, 07 Dec 2012 11:50:37 -0800 (PST) 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=Lg3Z3QSH4XSx5skZVn0tsVhoy4NRNdrCf/ce3QCC2pM=; b=uW3OCEJ+/eX6n2fHaaw2cAMhV0hteGdYcDPgAELoVgmyzv5rCubzPrDGX2knbpiCTE /jNiekbCHeEyD25TtH+xznD7lXvk7ovLMNyxWdpging7ibklrLo+oivXdhp0MOdBf1s4 dtdY9CiuQgNY3gYvUmrAcB41SQlsxwIRjyckhmoUykrj2f1343nau8MYYUaA7ROnL7Ze AfzI2ZkC7oZWUJflT0PJZOUVmjAcnq0eKIJ+kdDb3V1z82CaJGQr0OOwopzw26NfEzwa WZUL3k9gnA4kvpX2p8NWvJv5NP4adl8m1Gd/HLCEdG990HJWudedJinsqBFcGsM8Z3Ij Q+Fg== MIME-Version: 1.0 Received: by 10.112.29.104 with SMTP id j8mr3037014lbh.0.1354909836984; Fri, 07 Dec 2012 11:50:36 -0800 (PST) Received: by 10.112.99.70 with HTTP; Fri, 7 Dec 2012 11:50:36 -0800 (PST) In-Reply-To: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> References: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> Date: Fri, 7 Dec 2012 11:50:36 -0800 Message-ID: Subject: Re: loader and ficl/Forth help From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:50:39 -0000 On Fri, Dec 7, 2012 at 1:07 AM, Devin Teske wrote: ... > I've made some improvements to the supplied patch. Said improvements should address the previous issues that were preventing this from going in. > > Can someone test the newly-attached patch.txt and get back to me? The patch seems to be missing a few checks (boot_multicons, boot -D, etc). I really wish this stuff was properly consolidated/cleaned up -- loader.conf's console stuff is a hodgepodge mess of duplicated/obfuscated user knobs. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 20:07:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3673631F; Fri, 7 Dec 2012 20:07:22 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id EB94F8FC0C; Fri, 7 Dec 2012 20:07:21 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id qB7K7KZ7015862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Dec 2012 14:07:20 -0600 Received: from [10.0.0.102] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 7 Dec 2012 14:07:20 -0600 Subject: Re: loader and ficl/Forth help MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Devin Teske In-Reply-To: Date: Fri, 7 Dec 2012 12:07:18 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <13F96785-E0F3-4EC2-826E-070366D4A963@fisglobal.com> References: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-12-07_01:2012-12-07,2012-12-07,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:07:22 -0000 On Dec 7, 2012, at 11:50 AM, Garrett Cooper wrote: > On Fri, Dec 7, 2012 at 1:07 AM, Devin Teske w= rote: >=20 > ... >=20 >> I've made some improvements to the supplied patch. Said improvements sho= uld address the previous issues that were preventing this from going in. >>=20 >> Can someone test the newly-attached patch.txt and get back to me? >=20 > The patch seems to be missing a few checks (boot_multicons, boot > -D, etc). I really wish this stuff was properly consolidated/cleaned > up -- loader.conf's console stuff is a hodgepodge mess of > duplicated/obfuscated user knobs. > Thanks, > -Garrett I'll look into boot_multicons. However, w/respect to "boot -D", I believe that would be after the menu, so= is past the point at which we need the functionality (in drawing frames fr= om frames.4th). Also, you replied to an earlier e-mail in the thread, do note that there's = an updated patch that centralizes the logic to "boot_serial?" function whic= h returns boolean based on multiple conditions (currently takes $console an= d $boot_serial into consideration -- should be trivial to add a check for b= oot_multicons). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 20:33:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0555BB3C; Fri, 7 Dec 2012 20:33:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 447888FC12; Fri, 7 Dec 2012 20:33:16 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so842443lah.13 for ; Fri, 07 Dec 2012 12:33:16 -0800 (PST) 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:content-transfer-encoding; bh=eDQuShOwbepPSnlt5lEldgugL68DkXSaVv48uvWe3pI=; b=qIVAmRaD4QSgpR4pOuS/tkFohrjx7GuxI6723Ss6iLp8+ipjSZ9Xx6kPmcfOJRhej8 Rh/lvFMGgmhyH+kgQIKk59N2lLohKCD2YTpT9Pe5DYxvkq9KQ35OzfzAtYNVMLqOJL7P IkeIyNZ4WjsOtEq8Cw3fyAmnZikcjTDhstvhbeDdOuu2AS1yofw77XY0Cwk2N0QzfSjH HXbV5GLYyLONf47QMt1IVccs0pBSM/pENyYIutIrW+wyPg0oPgHoWReuDaeKBRq6BJpw rR3reFp9m45bI2TeyOOO3ISeGk5kQszMMemuKEvRCsRzy7ShDs0oAHKCxnW5BHU5H0SA DO/Q== MIME-Version: 1.0 Received: by 10.152.45.229 with SMTP id q5mr6527459lam.34.1354912396078; Fri, 07 Dec 2012 12:33:16 -0800 (PST) Received: by 10.112.99.70 with HTTP; Fri, 7 Dec 2012 12:33:15 -0800 (PST) In-Reply-To: <13F96785-E0F3-4EC2-826E-070366D4A963@fisglobal.com> References: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> <13F96785-E0F3-4EC2-826E-070366D4A963@fisglobal.com> Date: Fri, 7 Dec 2012 12:33:15 -0800 Message-ID: Subject: Re: loader and ficl/Forth help From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:33:18 -0000 On Fri, Dec 7, 2012 at 12:07 PM, Devin Teske wr= ote: ... > I'll look into boot_multicons. > > However, w/respect to "boot -D", I believe that would be after the menu, = so is past the point at which we need the functionality (in drawing frames = from frames.4th). > > Also, you replied to an earlier e-mail in the thread, do note that there'= s an updated patch that centralizes the logic to "boot_serial?" function wh= ich returns boolean based on multiple conditions (currently takes $console = and $boot_serial into consideration -- should be trivial to add a check for= boot_multicons). You're correct; boot -D is for after boot and this only affects loader(8): -D boot with the dual console configuration. In th= e single configuration, the console will be either the internal display or the serial port, dependi= ng on the state of the -h option below. In the dua= l console configuration, both the internal display and the serial port will become the console at t= he same time, regardless of the state of the -h option. Rereading loader(8)'s entry on multicons, it might be a non-issue as well, given that it's only saying "kernel": boot_multicons Enables multiple console support in the kernel early on boot= . In a running system, console configuration can be manipulate= d by the conscontrol(8) utility. A grep of sys/boot suggests it's an alias for -D: $ grep -r multicons . ./userboot/userboot/bootinfo.c: {"boot_multicons", RB_MULTIPLE}, ./sparc64/loader/metadata.c: {"boot_multicons", RB_MULTIPLE}, ./forth/loader.conf:#boot_multicons=3D"" # -D: Use multiple consoles ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ./powerpc/ofw/metadata.c: {"boot_multicons", RB_MULTIPLE}, ./powerpc/ps3/metadata.c: {"boot_multicons", RB_MULTIPLE}, ./i386/libi386/comconsole.c: getenv("boot_multicons") !=3D NULL) { ./i386/libi386/bootinfo.c: {"boot_multicons", RB_MULTIPLE}, ./i386/efi/bootinfo.c: { "boot_multicons", RB_MULTIPLE}, ./pc98/libpc98/comconsole.c: getenv("boot_multicons") !=3D NULL) { ./common/loader.8:.It Va boot_multicons ./common/help.common:# Tset Sboot_multicons DUse multiple consoles ./common/help.common: set boot_multicons ./ia64/common/bootinfo.c: { "boot_multicons", RB_MULTIPLE}, ./uboot/common/metadata.c: {"boot_multicons", RB_MULTIPLE}, However, sys/boot/i386/libi386/comconsole.c is doing some matching based on the environment variable, so I'd need to look into the call flow further to better understand what's being achieved. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 20:44:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 068E61B2; Fri, 7 Dec 2012 20:44:38 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B54388FC12; Fri, 7 Dec 2012 20:44:37 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id qB7Kia0s018508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Dec 2012 14:44:36 -0600 Received: from [10.0.0.102] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 7 Dec 2012 14:44:35 -0600 Subject: Re: loader and ficl/Forth help MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/mixed; boundary="Apple-Mail=_C87912D6-5E37-4720-976F-F6BD7A650FD8" From: Devin Teske In-Reply-To: Date: Fri, 7 Dec 2012 12:44:34 -0800 Message-ID: References: <3386ABA0-B05E-4E52-B9F7-35555A8AAFDA@fisglobal.com> <13F96785-E0F3-4EC2-826E-070366D4A963@fisglobal.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-12-07_01:2012-12-07,2012-12-07,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:44:38 -0000 --Apple-Mail=_C87912D6-5E37-4720-976F-F6BD7A650FD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Dec 7, 2012, at 12:33 PM, Garrett Cooper wrote: > On Fri, Dec 7, 2012 at 12:07 PM, Devin Teske = wrote: >=20 > ... >=20 >> I'll look into boot_multicons. >>=20 >> However, w/respect to "boot -D", I believe that would be after the menu,= so is past the point at which we need the functionality (in drawing frames= from frames.4th). >>=20 >> Also, you replied to an earlier e-mail in the thread, do note that there= 's an updated patch that centralizes the logic to "boot_serial?" function w= hich returns boolean based on multiple conditions (currently takes $console= and $boot_serial into consideration -- should be trivial to add a check fo= r boot_multicons). >=20 > You're correct; boot -D is for after boot and this only affects loader(8): >=20 > -D boot with the dual console configuration. In t= he > single configuration, the console will be either > the internal display or the serial port, depend= ing > on the state of the -h option below. In the du= al > console configuration, both the internal display > and the serial port will become the console at = the > same time, regardless of the state of the -h > option. >=20 > Rereading loader(8)'s entry on multicons, it might be a non-issue as > well, given that it's only saying "kernel": >=20 > boot_multicons > Enables multiple console support in the kernel early on boo= t. > In a running system, console configuration can be manipulat= ed > by the conscontrol(8) utility. >=20 > A grep of sys/boot suggests it's an alias for -D: >=20 > $ grep -r multicons . > ./userboot/userboot/bootinfo.c: {"boot_multicons", RB_MULTIPLE}, > ./sparc64/loader/metadata.c: {"boot_multicons", RB_MULTIPLE}, > ./forth/loader.conf:#boot_multicons=3D"" # -D: Use multiple consoles > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ./powerpc/ofw/metadata.c: {"boot_multicons", RB_MULTIPLE}, > ./powerpc/ps3/metadata.c: {"boot_multicons", RB_MULTIPLE}, > ./i386/libi386/comconsole.c: getenv("boot_multicons") !=3D NULL) { > ./i386/libi386/bootinfo.c: {"boot_multicons", RB_MULTIPLE}, > ./i386/efi/bootinfo.c: { "boot_multicons", RB_MULTIPLE}, > ./pc98/libpc98/comconsole.c: getenv("boot_multicons") !=3D NULL) { > ./common/loader.8:.It Va boot_multicons > ./common/help.common:# Tset Sboot_multicons DUse multiple consoles > ./common/help.common: set boot_multicons > ./ia64/common/bootinfo.c: { "boot_multicons", RB_MULTIPLE}, > ./uboot/common/metadata.c: {"boot_multicons", RB_MULTIPLE}, >=20 > However, sys/boot/i386/libi386/comconsole.c is doing some matching > based on the environment variable, so I'd need to look into the call > flow further to better understand what's being achieved. >=20 Can you review the following patch for inclusion to HEAD? I do believe this new patch gets us where we need to be=85 _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --Apple-Mail=_C87912D6-5E37-4720-976F-F6BD7A650FD8 Content-Disposition: attachment; filename="patch.txt" Content-Type: text/plain; name="patch.txt" Content-Transfer-Encoding: 7bit Index: support.4th =================================================================== --- support.4th (revision 242835) +++ support.4th (working copy) @@ -201,6 +201,46 @@ create last_module_option sizeof module.next allot : getenv? getenv -1 = if false else drop true then ; +\ determine if a word appears in a string, case-insensitive +: contains? ( addr1 len1 addr2 len2 -- 0 | -1 ) + 2 pick 0= if 2drop 2drop true exit then + dup 0= if 2drop 2drop false exit then + begin + begin + swap dup c@ dup 32 = over 9 = or + over 10 = or over 13 = or swap drop + while 1+ swap 1- repeat + swap 2 pick 1- over < + while + 2over 2over drop over compare-insensitive 0= if + 2 pick over = if 2drop 2drop true exit then + 2 pick tuck - -rot + swap over c@ dup 32 = + over 9 = or over 10 = or over 13 = or + swap drop if 2drop 2drop true exit then + then begin + swap dup c@ + dup 32 = over 9 = or over 10 = or over 13 = or + swap drop if false else true then 2 pick 0> and + while 1+ swap 1- repeat + swap + repeat + 2drop 2drop false +; + +: boot_serial? ( -- 0 | -1 ) + s" console" getenv dup -1 <> if + s" comconsole" 2swap contains? + else drop false then + s" boot_serial" getenv dup -1 <> if + swap drop 0> + else drop false then + or \ console contains comconsole ( or ) boot_serial + s" boot_multicons" getenv dup -1 <> if + swap drop 0> + else drop false then + or \ previous boolean ( or ) boot_multicons +; + \ Private definitions vocabulary support-functions Index: frames.4th =================================================================== --- frames.4th (revision 242835) +++ frames.4th (working copy) @@ -12,6 +12,11 @@ variable rt_el variable rb_el variable fill +\ ASCII frames (used when serial console is detected) + 45 constant ascii_dash +124 constant ascii_pipe + 43 constant ascii_plus + s" arch-pc98" environment? [if] \ Single frames 149 constant sh_el @@ -63,7 +68,17 @@ s" arch-pc98" environment? [if] loop ; +: f_ascii ( -- ) ( -- ) \ set frames to ascii + ascii_dash h_el ! + ascii_pipe v_el ! + ascii_plus lt_el ! + ascii_plus lb_el ! + ascii_plus rt_el ! + ascii_plus rb_el ! +; + : f_single ( -- ) \ set frames to single + boot_serial? if f_ascii exit then sh_el h_el ! sv_el v_el ! slt_el lt_el ! @@ -73,6 +88,7 @@ s" arch-pc98" environment? [if] ; : f_double ( -- ) \ set frames to double + boot_serial? if f_ascii exit then dh_el h_el ! dv_el v_el ! dlt_el lt_el ! --Apple-Mail=_C87912D6-5E37-4720-976F-F6BD7A650FD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" NOTE: I'm taking into consideration within the new "boot_serial?" = function that /boot/defaults/loader.conf says this about boot_serial and = boot_multicons=85 # The following boot_ variables are enabled by setting them to any = value. # Their presence in the kernel environment (see kenv(1)) has the same # effect as setting the given boot flag (see boot(8)). --=20 Devin= --Apple-Mail=_C87912D6-5E37-4720-976F-F6BD7A650FD8-- From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 8 00:18:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51171459 for ; Sat, 8 Dec 2012 00:18:58 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 2823B8FC12 for ; Sat, 8 Dec 2012 00:18:57 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 58F335081A for ; Fri, 7 Dec 2012 16:18:57 -0800 (PST) To: freebsd-hackers@freebsd.org Subject: 9.x -- New Install -- serious partition misalignment Date: Fri, 07 Dec 2012 16:18:57 -0800 Message-ID: <14190.1354925937@tristatelogic.com> From: "Ronald F. Guilmette" X-Mailman-Approved-At: Sat, 08 Dec 2012 03:33:04 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 00:18:58 -0000 My apologies if this is not the Right Place to raise this issue. I just now submitted the following PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=174269 (Please ignore the small typo in the title. That should have been "bsdinstall/partedit" not "basinstall/partedit".) Anyway, I wanted to know if anyone here has an opinion that (a) I am crazy, and ought to remain silent or else (b) there is something obvious that I missed or else (c) the problem described in the PR really is a horribly serious issue which is likely to screw up quite a lot of people/installations. If possibility (c) applies, then I would also like to know if anybody has any suggestions for how I might be able to get this problem escalated so that (hopefully) it gets dealt with before 9.1-RELEASE is finalized. Regards, rfg P.S. As noted in the PR, while doing a fresh install, if one selects the "Shell" method of partitioning, one is given a rather terse and cryptic instruction to "mount the system at /mnt" (after all of the manual partitioning has been done), but I have no idea how to do this properly, and thus, I have only two options... I can either (a) live without 9.x entirely (and also without support for my shiny new USB 3.0 port card) or else (b) I can accept the horrendous performance penality that is likely to ensue when I allow "partedit" to place my requested partitions at badly mis-aligned locations on my new "Advanced Format" hard disk. Neither possibility is particularly appealing. From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 8 05:07:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E35FBEF for ; Sat, 8 Dec 2012 05:07:03 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id D6B658FC15 for ; Sat, 8 Dec 2012 05:07:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Ezm0WfdwUQyoAA9mmH9r8KV9bk/dEvk6rZL3y8c04bU=; b=MSJx/aCDmYUWwdiTIgZs56oZh/o70bzFB3TpqcPKy4BNHbfmB0JkKi+A7FgYUXSW8kKeRFNN9usQmdx5OrC/oW82xCqvRhoa/vhSN+R3pkLWYQu+f4MACr+P4kypGRsT; Received: from [122.129.203.50] (port=58103 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1ThCcv-004LFh-0w; Fri, 07 Dec 2012 22:07:01 -0700 Date: Sat, 8 Dec 2012 12:06:58 +0700 From: Erich Dollansky To: "Ronald F. Guilmette" Subject: Re: 9.x -- New Install -- serious partition misalignment Message-ID: <20121208120658.4d115dc0@X220.ovitrap.com> In-Reply-To: <14190.1354925937@tristatelogic.com> References: <14190.1354925937@tristatelogic.com> Organization: ALO Green Technologies X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sat, 08 Dec 2012 14:42:27 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 05:07:03 -0000 Hi, On Fri, 07 Dec 2012 16:18:57 -0800 "Ronald F. Guilmette" wrote: > If possibility (c) applies, then I would also like to know if anybody > has any suggestions for how I might be able to get this problem > escalated so that (hopefully) it gets dealt with before 9.1-RELEASE > is finalized. 162 / 4 is 40.5. So, disk access on modern disks will be slower but not catastrophic. What irritates me more in this context is the fact that I have two card disks which are supposed to be identical. They come from the same factory but only one carries a label saying it has 4k sectors. I still would like to have at least two partitioning schemata available without much user interaction. At least one should allow the user to have /, /tmp, /var, /usr and /home in separated partitions. Call it the classic partitioning schema and have another one called modern. Erich From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 8 18:15:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54D1C87C for ; Sat, 8 Dec 2012 18:15:16 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id E13918FC12 for ; Sat, 8 Dec 2012 18:15:15 +0000 (UTC) Received: (qmail 57007 invoked by uid 89); 8 Dec 2012 18:13:51 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Dec 2012 18:13:51 -0000 Subject: Possible obscure socket leak when system under load and listener is slow to accept From: Richard Sharpe To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Sat, 08 Dec 2012 10:13:45 -0800 Message-ID: <1354990425.6752.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 18:15:16 -0000 Hi folks, Our QA group (at xxx) using Samba and smbtorture has been seeing a lot of cases where accept returns ECONNABORTED because the system load is high and Samba has a large listen backlog. Every now and then we get a crash in smbd or in winbindd and winbindd complains of too many open files in the system. In looking at kern_accept, it seems to me that FreeBSD can leak a socket when kern_accept calls soaccept on it but gets ECONNABORTED. This error is the only error returned from tcp_usr_accept. It seems like the socket taken off so_comp is never freed in this case and that there has been a call on soref on it as well, so that something like the following is needed in the error path: ==== //some-path/freebsd/sys/kern/uipc_syscalls.c#1 - /home/rsharpe/dev-src/packages/freebsd/sys/kern/uipc_syscalls.c ==== @@ -433,6 +433,14 @@ */ if (name) *namelen = 0; + /* + * We need to close the socket we unlinked + * so we do not leak it. + */ + ACCEPT_LOCK(); + SOCK_LOCK(so); + soclose(so); goto noconnection; } if (sa == NULL) { I think an soclose is needed at this point because soisconnected has been called on the socket. Do you think this analysis is reasonable? We are using FreeBSD 8.0 but it seems the same is true for 9.0. However, maybe I am wrong since I am not sure if the fdclose call would free the socket, but a quick look suggested that it doesn't. I would appreciate your feedback. From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 8 21:49:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ACE9882 for ; Sat, 8 Dec 2012 21:49:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 2538F8FC08 for ; Sat, 8 Dec 2012 21:49:44 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so383123wib.1 for ; Sat, 08 Dec 2012 13:49:38 -0800 (PST) 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=W4DY7KtSrPC1O3GdPM0qv5efgyEhI7D47Ne1NQipOTY=; b=EccgYqPSffzyq057Ts9ZCqwjWnX0bnHuX2HDMW6u/9jI7zBlS6ip9QiUv8NrLKue5a nQOWiIW5oCQxwhuojKw/2Vaz95H6s+bnIaa2wmG3kIWaIls6YeqgHAN0rDyh5FZbn8c6 hfKZltzHDs2BzHORbPv2t6WCqlLY2UJtlGxUhFQKTik4odbMpWmrrPZ1UBc6y8MgHKdM JznN+Cr9UfJYH3zTADidyJglQcMt1/MLlgOrT1G3qbbuIUTkn3eQ7/2mcM8iAV8yAblz ATzCc3WgBrC2Si7D6irUJYo5JoS60W9UUHS6mVIZgJak1PHUBhNMubpS0h5R9d1bWg/X 9fdg== MIME-Version: 1.0 Received: by 10.216.85.211 with SMTP id u61mr3814531wee.212.1355003378348; Sat, 08 Dec 2012 13:49:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 8 Dec 2012 13:49:38 -0800 (PST) In-Reply-To: <1354990425.6752.10.camel@localhost.localdomain> References: <1354990425.6752.10.camel@localhost.localdomain> Date: Sat, 8 Dec 2012 13:49:38 -0800 X-Google-Sender-Auth: HEZZqdXgYrPAfP7BEKXgmUMNar4 Message-ID: Subject: Re: Possible obscure socket leak when system under load and listener is slow to accept From: Adrian Chadd To: Richard Sharpe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 21:49:45 -0000 Hi, If this is a real leak, please file a PR so it doesn't get lost. *cough* let me rephrase that - so the eager PR beavers can keep chasing it iup. But, wow. Nice catch! Adrian On 8 December 2012 10:13, Richard Sharpe wrote: > Hi folks, > > Our QA group (at xxx) using Samba and smbtorture has been seeing a > lot of cases where accept returns ECONNABORTED because the system load > is high and Samba has a large listen backlog. > > Every now and then we get a crash in smbd or in winbindd and winbindd > complains of too many open files in the system. > > In looking at kern_accept, it seems to me that FreeBSD can leak a socket > when kern_accept calls soaccept on it but gets ECONNABORTED. This error > is the only error returned from tcp_usr_accept. > > It seems like the socket taken off so_comp is never freed in this case > and that there has been a call on soref on it as well, so that something > like the following is needed in the error path: > > ==== //some-path/freebsd/sys/kern/uipc_syscalls.c#1 > - /home/rsharpe/dev-src/packages/freebsd/sys/kern/uipc_syscalls.c ==== > @@ -433,6 +433,14 @@ > */ > if (name) > *namelen = 0; > + /* > + * We need to close the socket we unlinked > + * so we do not leak it. > + */ > + ACCEPT_LOCK(); > + SOCK_LOCK(so); > + soclose(so); > goto noconnection; > } > if (sa == NULL) { > > I think an soclose is needed at this point because soisconnected has > been called on the socket. > > Do you think this analysis is reasonable? > > We are using FreeBSD 8.0 but it seems the same is true for 9.0. However, > maybe I am wrong since I am not sure if the fdclose call would free the > socket, but a quick look suggested that it doesn't. > > I would appreciate your feedback. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 8 21:57:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7251AB1 for ; Sat, 8 Dec 2012 21:57:27 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDBD8FC13 for ; Sat, 8 Dec 2012 21:57:26 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 6A0625081A for ; Sat, 8 Dec 2012 13:57:25 -0800 (PST) To: freebsd-hackers@freebsd.org Subject: Re: 9.x -- New Install -- serious partition misalignment In-Reply-To: <20121208120658.4d115dc0@X220.ovitrap.com> Date: Sat, 08 Dec 2012 13:57:25 -0800 Message-ID: <23146.1355003845@tristatelogic.com> From: "Ronald F. Guilmette" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 21:57:27 -0000 In message <20121208120658.4d115dc0@X220.ovitrap.com>, Erich Dollansky wrote: >Hi, > >On Fri, 07 Dec 2012 16:18:57 -0800 >"Ronald F. Guilmette" wrote: > >> If possibility (c) applies, then I would also like to know if anybody >> has any suggestions for how I might be able to get this problem >> escalated so that (hopefully) it gets dealt with before 9.1-RELEASE >> is finalized. > >162 / 4 is 40.5. So, disk access on modern disks will be slower but not >catastrophic. Actually, it appears to me that the performance hit _will_ actually be rather entirely catastrophic. (But obviously it depends on what you are doing with the system in question. If you are just playing tetris on it, then no worries mate. But if you're doing some hardcore database stuff, you could be majorly screwed.) Take a simple example of an attempt to perform a single write+flush of a 4 KiB block to a location which is aligned to a 4 KiB boundary... relative to the start of the partition.... in each of two different partitions on two different drives. Assume that the fragment size (-f option for newfs) has been set to 4 KiB for both partitions, and that both partitions reside on so-called "Advanced Format" (4 KiB physical sector) drives. The only difference is that for one of these two partitions, the partition is NOT properly aligned. Scenario #1) In the case of the properly aligned partition, the kernel, knowing that the fragment size is 4 KiB, can simply write the (properly aligned) 4 KiB hunk of data to the drive and this will result is a single physical write operation on the drive. Scenario #2) Contrast that now with the case where the start of the partition is misaligned. In this case, because the kernel knows that the partition into which we are doing the write has a 4 KiB fragment size, and because it knows that the hunk of data we are writing is perfectly aligned to a 4 KiB boundary within that partition, the kernel again believes that it can still just push the new 4 Kib hunk of data out to the drive in a single operation... and it does. Inside the physical drive however, because the partition is misaligned, the results will be _two_ reads (of two adjacent physical 4 KiB sectors) followed by _two_ writes (of two adjacent physical 4 KiB sectors). Congratulations! Your perfectly tuned DB application now takes four times as long for each simple write operation. Performance has been degraded by a whopping 75% ! This is NOT an insignificant or trivial matter. In fact this is a screw up of major proportions, I do believe. This probably wouldn't be such a big deal if we were just talking about Linux. But FreeBSD has always prided itself on being a serious OS for serious people with serious work to do... like major server farms and such. In the context of high-end applications on high-end hardware where people are often trying to squeeze out that last drop of performance, the potentially massive... and stealthy... performance hit from partition misalignment... which will be seen/experienced on essentially all modern terabyte+ drives... is just simply unacceptable. Well, that's my opinion anyway. Regards, rfg P.S. Warren Block was kind enough to point out to me that he had already filesd a formal PR on this enormously serious bug way back in October of last year (2011): http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161720 and yet nothing has been done about it in all of the intervening 14 months. Apparently, the party most directly responsible for bsdinstall is Nathan Whitehorn, and judging from the date stamps on the material here: http://people.freebsd.org/~nwhitehorn/ a reasonable person might concude, with all due respect, that Mr. Whitehorn may in fact have "run down the curtain and joined the bleedin' choir invisibile" sometime during the month of April, 2011. I'll be e-mailing him momentarily to try to find out, one way or the other. From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 8 23:50:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4EE2C1E for ; Sat, 8 Dec 2012 23:50:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 138D38FC08 for ; Sat, 8 Dec 2012 23:50:14 +0000 (UTC) Received: (qmail 60999 invoked from network); 9 Dec 2012 01:19:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Dec 2012 01:19:48 -0000 Message-ID: <50C3D22D.3060008@freebsd.org> Date: Sun, 09 Dec 2012 00:50:05 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Richard Sharpe Subject: Re: Possible obscure socket leak when system under load and listener is slow to accept Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 23:50:15 -0000 > Hi folks, > > Our QA group (at xxx) using Samba and smbtorture has been seeing a > lot of cases where accept returns ECONNABORTED because the system load > is high and Samba has a large listen backlog. > > Every now and then we get a crash in smbd or in winbindd and winbindd > complains of too many open files in the system. > > In looking at kern_accept, it seems to me that FreeBSD can leak a socket > when kern_accept calls soaccept on it but gets ECONNABORTED. This error > is the only error returned from tcp_usr_accept. > > It seems like the socket taken off so_comp is never freed in this case > and that there has been a call on soref on it as well, so that something > like the following is needed in the error path: > > ==== //some-path/freebsd/sys/kern/uipc_syscalls.c#1 > - /home/rsharpe/dev-src/packages/freebsd/sys/kern/uipc_syscalls.c ==== > @@ -433,6 +433,14 @@ > */ > if (name) > *namelen = 0; > + /* > + * We need to close the socket we unlinked > + * so we do not leak it. > + */ > + ACCEPT_LOCK(); > + SOCK_LOCK(so); > + soclose(so); > goto noconnection; > } > if (sa == NULL) { > > I think an soclose is needed at this point because soisconnected has > been called on the socket. > > Do you think this analysis is reasonable? > > We are using FreeBSD 8.0 but it seems the same is true for 9.0. However, > maybe I am wrong since I am not sure if the fdclose call would free the > socket, but a quick look suggested that it doesn't. The fdclose should properly tear down the file descriptor. The call graph is: fdclose() -> fdrop() -> _fdrop() -> fo_close()/soo_close() -> soclose() -> sorele() -> sofree() -> sodealloc(). A socket leak would not count against "kern.maxfiles" unless the file descriptor leaks as well. So it is unlikely that this is the problem. Samba may open a large number of files (real files and sockets) and you may run into the maxfiles limit. You can check the limit with "sysctl kern.maxfiles" and increase it at boot time in boot/loader.conf with "kern.maxfiles=100000" for example. -- Andre