From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 06:52:23 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB1AC1065670; Sun, 26 Sep 2010 06:52:23 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 80B468FC0C; Sun, 26 Sep 2010 06:52:23 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8ED6B9CB0DA; Sun, 26 Sep 2010 08:52:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjH5PYS6Jpzv; Sun, 26 Sep 2010 08:52:21 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id F176A9CB1CB; Sun, 26 Sep 2010 08:52:20 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o8Q6qKrR049180; Sun, 26 Sep 2010 08:52:20 +0200 (CEST) (envelope-from rdivacky) Date: Sun, 26 Sep 2010 08:52:20 +0200 From: Roman Divacky To: bf1783@gmail.com Message-ID: <20100926065220.GA49055@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: jkoshy@FreeBSD.org, freebsd-current@FreeBSD.org, dim@FreeBSD.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 06:52:23 -0000 On Sat, Sep 25, 2010 at 08:55:51PM +0000, b. f. wrote: > Dmitry Andric wrote: > >On 2010-09-25 21:16, Paul B Mahol wrote: > >> When to expect to get rid of GNU as and other binutils tools? > > >Work is progressing steadily on the clang/llvm integrated assembler, > >which removes the need for an external assembler such as gas, and which > >should also reduce compile times further. This is really in alpha state > >right now, but Roman Divacky (who is one of the active contributors) can > >probably tell more about its progress. > > > >Another important component is of course the linker, but I am not aware > >of a similar project to replace that; excepting gold, but that is a > >GPLv3 project too, unfortunately. > > There has been another effort underway for some time: > > http://sourceforge.net/apps/trac/elftoolchain/ > > Perhaps some coordination between those working on llvm in FreeBSD, > and the elftoolchain project, would be helpful? there's not that much overlap between those two - in a case elftoolchain gets to implementing linker it would be sweet if it supported the same plugin API as "gold" so we can use LLVM LTO plugin there... beside that I dont see much point in teaching nm to see into llvm object files etc. (we already have tools for that) From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 07:34:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF683106564A for ; Sun, 26 Sep 2010 07:34:11 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC2F8FC0A for ; Sun, 26 Sep 2010 07:34:11 +0000 (UTC) Received: by bwz15 with SMTP id 15so3647824bwz.13 for ; Sun, 26 Sep 2010 00:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eyU4olscvMlq5iCZ5ZynHvWsjWuC0wSwSEX4YwIYpao=; b=OxBzKvGeR2jbhO2wT6tZq98WsnEAJD4BC+V7JRgOzBJwgBbMGoYx7Dn9FnytnBxMYa Zp12azJkeBi3VoNsraAUPcSJPT06H8qlMQdwXbfIfq1raO2Gs//3PS6GYDJmx58Lk8U5 pEE6c7G1N9G/zfBghWgFGIT7tV1Rr3elP1uDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ATehik7t9RjasMbm3WmJK3X+wVdZP71CrkWWhYX/bqTJ7COrrFD5Gxe/0+0BDsxsaR mCN/Nx27bbXnuru5kuXKRHynfXke+DPF6ktLUQODdSXGKg/8hG4qdGqz2iAEtywsJIjf wrEfBJs7Z2/0PnsRyeChTxVzLjGcu6/m2H/yo= MIME-Version: 1.0 Received: by 10.204.133.146 with SMTP id f18mr3913312bkt.97.1285486448424; Sun, 26 Sep 2010 00:34:08 -0700 (PDT) Received: by 10.204.97.208 with HTTP; Sun, 26 Sep 2010 00:34:08 -0700 (PDT) In-Reply-To: References: <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> <20100915.082513.802140508206832836.imp@bsdimp.com> Date: Sun, 26 Sep 2010 09:34:08 +0200 Message-ID: From: David DEMELIER To: Marcin Cieslak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 07:34:11 -0000 2010/9/25 Marcin Cieslak : >>> M. Warner Losh wrote: > >>: I agree but like Aleksandr said, almost 70% of dhcp code is already in >>: base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea >>: to keep some parts in the ports tree and move out from the base. >> >> Yea. =C2=A0I agree too. =C2=A0Just because BIND was EOLd in 6 isn't a gr= eat >> argument against dhcp server. =C2=A0Most of the code is there anyway, an= d >> it isn't evolving as fast as BIND. >> >> It would be very convenient to have this particular thing in the base, >> and we shouldn't be too dogmatic about never having any new 3rd party >> things in the base. =C2=A0After all, we just added more compression >> utilities to the base, and nobody said a peep. =C2=A0This is analogous: = we >> have good opportunity to integrate into the system, and users benefit >> from that integration. > > As a road-warrior consultant I really value having things like > bootpd, tftpd, bootparamd and similar software always there. > Many times I wished dhcpd was there, too. > > Another typical use - FreeBSD makes a good small network router out > of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing). > > I am not sure about the whole "modularization" goal - I think > the relatively monolythic nature is one of the FreeBSD's merits. > > For example, it's good to have NFSv4, Kerberos and required > userland daemons packaged in the base. I don't want to have > those done separately in a modular way (although Heimdal > we have is older then what their current trunk is). > We got stuck on connecting Linux boxes via NFSv4 to Solaris > and BSD because one of the userland modules in Linux was terribly > out of date and authenticating the user w/Kerberos was not possible. > > As we build a more complex networking landscape with VIMAGE and > friends I think that the benefits of better integration of dhcpd > in the base system (rc.d, rc.conf...) may outweigh its costs > (maintenance, bloat, etc.). > > //Marcin > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I agree that for some people it will be completely useless, but if we can disable it in src.conf everyone will be happy. Since FreeBSD is great for a router it's really fast to make a full working server without installing anything else. I agree for the 70% part of dhcp which is already present. In any case, src.conf(5) is still working and usable, isn't it? Kind regards, --=20 Demelier David From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 10:47:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2291065674 for ; Sun, 26 Sep 2010 10:47:07 +0000 (UTC) (envelope-from olivier.freebsd@free.fr) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by mx1.freebsd.org (Postfix) with ESMTP id 678A28FC18 for ; Sun, 26 Sep 2010 10:47:05 +0000 (UTC) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 76EE62CC47 for ; Sun, 26 Sep 2010 12:28:09 +0200 (CEST) Received: from lon92-4-82-226-188-149.fbx.proxad.net (unknown [82.226.188.149]) by smtp2-g21.free.fr (Postfix) with ESMTP id 339274B0032; Sun, 26 Sep 2010 12:27:59 +0200 (CEST) From: Olivier Certner To: Pawel Jakub Dawidek Date: Sun, 26 Sep 2010 12:21:50 +0200 User-Agent: KMail/1.9.10 References: <20100925174929.GD47356@garage.freebsd.pl> In-Reply-To: <20100925174929.GD47356@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201009261221.50490.olivier.freebsd@free.fr> Cc: freebsd-current@freebsd.org Subject: Re: Recent GELI additions. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 10:47:07 -0000 Hi, Thanks a lot for your efforts, Pawel! Geli is definitely awesome. Bye, Olivier Certner From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 11:13:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5121106566C for ; Sun, 26 Sep 2010 11:13:02 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 73BF78FC08 for ; Sun, 26 Sep 2010 11:13:02 +0000 (UTC) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id o8QArlhv063478 for ; Sun, 26 Sep 2010 12:53:48 +0200 (CEST) X-Ids: 166 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id D98578A3B7 for ; Sun, 26 Sep 2010 12:53:46 +0200 (CEST) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id E454640B6; Sun, 26 Sep 2010 12:55:07 +0000 (UTC) Date: Sun, 26 Sep 2010 12:55:07 +0000 From: Michel Talon To: freebsd-current@freebsd.org Message-ID: <20100926125507.GA41861@lpthe.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Miltered: at jchkmail.jussieu.fr with ID 4C9F263C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4C9F263C.000/134.157.10.1/parthe.lpthe.jussieu.fr/parthe.lpthe.jussieu.fr/ X-Mailman-Approved-At: Sun, 26 Sep 2010 11:22:26 +0000 Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 11:13:02 -0000 David DEMELIER said: > I agree that for some people it will be completely useless, but if we > can disable it in src.conf everyone will be happy. Since FreeBSD is > great for a router it's really fast to make a full working server > without installing anything else. What is the problem of installing something else? You are probably ignoring that many people are complaining about the presence of sendmail, bind, perl etc. in the base system from ages, indeed X and perl have been removed, and it is clear that the consensus is to make the base smaller not bigger. And frankly i have *very* hard time to think that a DHCP server in the base has any utility. why not maxima for example? I am interested in formal computation, you are interested in routers, another one likes images and would want gimp, and so on. -- Michel TALON From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 12:21:59 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A971065698; Sun, 26 Sep 2010 12:21:59 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id C54B48FC1B; Sun, 26 Sep 2010 12:21:58 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.0]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OzqEn-0002fX-UU; Sun, 26 Sep 2010 14:21:57 +0200 Message-ID: <4C9F3ADF.7070903@kkip.pl> Date: Sun, 26 Sep 2010 14:21:51 +0200 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dimitry Andric References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> <4C9B383A.6080008@FreeBSD.org> <4C9B38E2.7010403@kkip.pl> <4C9B6804.3070102@FreeBSD.org> <4C9C8A64.3000103@kkip.pl> <4C9C8FD9.1030305@FreeBSD.org> <4C9C95D7.40600@kkip.pl> <4C9CB702.50004@FreeBSD.org> In-Reply-To: <4C9CB702.50004@FreeBSD.org> X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.72 (build at 10-Jun-2010 13:05:33) X-Date: 2010-09-26 14:21:57 X-Connected-IP: 10.66.3.0:2980 X-Message-Linecount: 147 X-Body-Linecount: 134 X-Message-Size: 6178 X-Body-Size: 5182 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Roman Divacky , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 12:21:59 -0000 W dniu 2010-09-24 16:34, Dimitry Andric pisze: > On 2010-09-24 14:13, Bartosz Stec wrote: >>> Could you please try to rename this make.conf to e.g. >>> make.conf.disable, >>> and retry the world build? >> Still the same without make.conf. My personal guess is, that clang >> builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think >> CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by >> GCC with exactly the same make.conf has no problems with world >> building :) > > I still cannot reproduce your issue... To check, I have built world > with CPUTYPE=athlon-xp, verified it used "-O2 -pipe -march=athlon-xp" as > compilation flags for the world stage, and installed the resulting clang > executables. > > Those clang executables do not exhibit the same problem as yours do; > they can build tblgen (during the bootstrap-tools stage) fine. > > I suggest you comment out the CPUTYPE macro in make.conf for now, > rebuild your world with gcc, and then rebuild it with clang again, to > see if the issue goes away. Indeed, I was right. Problem is gone after hashing out CPUTYPE line, building world with GCC, and with clang after that. Now world is building without problems. But hey, i just realized that: # dmesg | grep -i cpu CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) I simply forgot that about a year ago I changed Athlon XP in this BOX to Athlon MP and I didn't changed CPUTYPE in make.conf... So maybe clang in fact did exactly what it should and created binary designed to other CPUTYPE ;) I don't know exact differences between Athlon XP/MP architecture (registers specially) but I just started another try with CPUTYPE=Athlon-mp and I will post results :) -- Bartosz Stec -- IT4Pro Bartosz Stec http://www.it4pro.pl tel: 607041002 E-Mail: bartosz.stec@it4pro.pl From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 12:54:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D408106566C for ; Sun, 26 Sep 2010 12:54:28 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9208FC16 for ; Sun, 26 Sep 2010 12:54:27 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.0]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OzqkE-0002jT-2B; Sun, 26 Sep 2010 14:54:25 +0200 Message-ID: <4C9F427B.3010904@kkip.pl> Date: Sun, 26 Sep 2010 14:54:19 +0200 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Erik Trulsson References: <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> <4C9B383A.6080008@FreeBSD.org> <4C9B38E2.7010403@kkip.pl> <4C9B6804.3070102@FreeBSD.org> <4C9C8A64.3000103@kkip.pl> <4C9C8FD9.1030305@FreeBSD.org> <4C9C95D7.40600@kkip.pl> <4C9CB702.50004@FreeBSD.org> <4C9F3ADF.7070903@kkip.pl> <20100926124244.GA34061@owl.midgard.homeip.net> In-Reply-To: <20100926124244.GA34061@owl.midgard.homeip.net> X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.72 (build at 10-Jun-2010 13:05:33) X-Date: 2010-09-26 14:54:25 X-Connected-IP: 10.66.3.0:3020 X-Message-Linecount: 191 X-Body-Linecount: 177 X-Message-Size: 8227 X-Body-Size: 7288 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 12:54:28 -0000 W dniu 2010-09-26 14:42, Erik Trulsson pisze: > On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote: >> W dniu 2010-09-24 16:34, Dimitry Andric pisze: >>> On 2010-09-24 14:13, Bartosz Stec wrote: >>>>> Could you please try to rename this make.conf to e.g. >>>>> make.conf.disable, >>>>> and retry the world build? >>>> Still the same without make.conf. My personal guess is, that clang >>>> builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think >>>> CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by >>>> GCC with exactly the same make.conf has no problems with world >>>> building :) >>> I still cannot reproduce your issue... To check, I have built world >>> with CPUTYPE=athlon-xp, verified it used "-O2 -pipe -march=athlon-xp" as >>> compilation flags for the world stage, and installed the resulting clang >>> executables. >>> >>> Those clang executables do not exhibit the same problem as yours do; >>> they can build tblgen (during the bootstrap-tools stage) fine. >>> >>> I suggest you comment out the CPUTYPE macro in make.conf for now, >>> rebuild your world with gcc, and then rebuild it with clang again, to >>> see if the issue goes away. >> Indeed, I was right. Problem is gone after hashing out CPUTYPE line, >> building world with GCC, and with clang after that. Now world is >> building without problems. >> >> But hey, i just realized that: >> >> # dmesg | grep -i cpu >> CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) >> >> I simply forgot that about a year ago I changed Athlon XP in this BOX to >> Athlon MP and I didn't changed CPUTYPE in make.conf... >> So maybe clang in fact did exactly what it should and created binary >> designed to other CPUTYPE ;) I don't know exact differences between >> Athlon XP/MP architecture (registers specially) but I just started >> another try with CPUTYPE=Athlon-mp and I will post results :) > The only difference between Athlon XP and Athlon MP is that the MP > variants are certified for multi-processor use (in reality most Athlon > XP also worked just fine in multi-processor systems, or could easily be > modified to do so.) Available instructions and registers are identical > between the two. Mobile variants of the Athlon XP should also be > identical from a programming point of view. > > > That's what I thought too, but in that case, why are they different optimisations available? In /usr/share/examples/etc/make.conf: # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 Or maybe some of them are in fact bywords to compiler? Still, my CURRENT box is at idle mostly, so I will experiment a little and see what I get. Cheers -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 12:57:57 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA9CF106564A for ; Sun, 26 Sep 2010 12:57:57 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 369AB8FC18 for ; Sun, 26 Sep 2010 12:57:57 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:34358 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1OzqZ7-0002QG-8h for current@freebsd.org; Sun, 26 Sep 2010 14:42:51 +0200 Received: (qmail 36739 invoked from network); 26 Sep 2010 14:42:44 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 26 Sep 2010 14:42:44 +0200 Received: (qmail 34161 invoked by uid 1001); 26 Sep 2010 14:42:44 +0200 Date: Sun, 26 Sep 2010 14:42:44 +0200 From: Erik Trulsson To: Bartosz Stec Message-ID: <20100926124244.GA34061@owl.midgard.homeip.net> References: <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> <4C9B383A.6080008@FreeBSD.org> <4C9B38E2.7010403@kkip.pl> <4C9B6804.3070102@FreeBSD.org> <4C9C8A64.3000103@kkip.pl> <4C9C8FD9.1030305@FreeBSD.org> <4C9C95D7.40600@kkip.pl> <4C9CB702.50004@FreeBSD.org> <4C9F3ADF.7070903@kkip.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C9F3ADF.7070903@kkip.pl> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1OzqZ7-0002QG-8h. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1OzqZ7-0002QG-8h 0a892774c3892b51374096ffdd89df53 Cc: Roman Divacky , Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 12:57:57 -0000 On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote: > W dniu 2010-09-24 16:34, Dimitry Andric pisze: > > On 2010-09-24 14:13, Bartosz Stec wrote: > >>> Could you please try to rename this make.conf to e.g. > >>> make.conf.disable, > >>> and retry the world build? > >> Still the same without make.conf. My personal guess is, that clang > >> builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think > >> CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by > >> GCC with exactly the same make.conf has no problems with world > >> building :) > > > > I still cannot reproduce your issue... To check, I have built world > > with CPUTYPE=athlon-xp, verified it used "-O2 -pipe -march=athlon-xp" as > > compilation flags for the world stage, and installed the resulting clang > > executables. > > > > Those clang executables do not exhibit the same problem as yours do; > > they can build tblgen (during the bootstrap-tools stage) fine. > > > > I suggest you comment out the CPUTYPE macro in make.conf for now, > > rebuild your world with gcc, and then rebuild it with clang again, to > > see if the issue goes away. > > Indeed, I was right. Problem is gone after hashing out CPUTYPE line, > building world with GCC, and with clang after that. Now world is > building without problems. > > But hey, i just realized that: > > # dmesg | grep -i cpu > CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) > > I simply forgot that about a year ago I changed Athlon XP in this BOX to > Athlon MP and I didn't changed CPUTYPE in make.conf... > So maybe clang in fact did exactly what it should and created binary > designed to other CPUTYPE ;) I don't know exact differences between > Athlon XP/MP architecture (registers specially) but I just started > another try with CPUTYPE=Athlon-mp and I will post results :) The only difference between Athlon XP and Athlon MP is that the MP variants are certified for multi-processor use (in reality most Athlon XP also worked just fine in multi-processor systems, or could easily be modified to do so.) Available instructions and registers are identical between the two. Mobile variants of the Athlon XP should also be identical from a programming point of view. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 13:19:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCB7D106564A for ; Sun, 26 Sep 2010 13:19:40 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB3D8FC0C for ; Sun, 26 Sep 2010 13:19:40 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.0]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ozr8Q-0000QH-JJ; Sun, 26 Sep 2010 15:19:37 +0200 Message-ID: <4C9F4857.2070801@kkip.pl> Date: Sun, 26 Sep 2010 15:19:19 +0200 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 References: <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> <4C9B383A.6080008@FreeBSD.org> <4C9B38E2.7010403@kkip.pl> <4C9B6804.3070102@FreeBSD.org> <4C9C8A64.3000103@kkip.pl> <4C9C8FD9.1030305@FreeBSD.org> <4C9C95D7.40600@kkip.pl> <4C9CB702.50004@FreeBSD.org> <4C9F3ADF.7070903@kkip.pl> <20100926124244.GA34061@owl.midgard.homeip.net> <4C9F427B.3010904@kkip.pl> In-Reply-To: <4C9F427B.3010904@kkip.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -7.6 X-Spam-Score-Int: -75 X-Exim-Version: 4.72 (build at 10-Jun-2010 13:05:33) X-Date: 2010-09-26 15:19:37 X-Connected-IP: 10.66.3.0:3181 X-Message-Linecount: 90 X-Body-Linecount: 77 X-Message-Size: 4139 X-Body-Size: 3191 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 13:19:40 -0000 W dniu 2010-09-26 14:54, Bartosz Stec pisze: > W dniu 2010-09-26 14:42, Erik Trulsson pisze: >> On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote: >>> W dniu 2010-09-24 16:34, Dimitry Andric pisze: >>>> On 2010-09-24 14:13, Bartosz Stec wrote: >>>>>> Could you please try to rename this make.conf to e.g. >>>>>> make.conf.disable, >>>>>> and retry the world build? >>>>> Still the same without make.conf. My personal guess is, that clang >>>>> builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't >>>>> think >>>>> CFLAGS=-O2 -pipe could do any harm, and also note that clang >>>>> builded by >>>>> GCC with exactly the same make.conf has no problems with world >>>>> building :) >>>> I still cannot reproduce your issue... To check, I have built world >>>> with CPUTYPE=athlon-xp, verified it used "-O2 -pipe >>>> -march=athlon-xp" as >>>> compilation flags for the world stage, and installed the resulting >>>> clang >>>> executables. >>>> >>>> Those clang executables do not exhibit the same problem as yours do; >>>> they can build tblgen (during the bootstrap-tools stage) fine. >>>> >>>> I suggest you comment out the CPUTYPE macro in make.conf for now, >>>> rebuild your world with gcc, and then rebuild it with clang again, to >>>> see if the issue goes away. >>> Indeed, I was right. Problem is gone after hashing out CPUTYPE line, >>> building world with GCC, and with clang after that. Now world is >>> building without problems. >>> >>> But hey, i just realized that: >>> >>> # dmesg | grep -i cpu >>> CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) >>> >>> I simply forgot that about a year ago I changed Athlon XP in this >>> BOX to >>> Athlon MP and I didn't changed CPUTYPE in make.conf... >>> So maybe clang in fact did exactly what it should and created binary >>> designed to other CPUTYPE ;) I don't know exact differences between >>> Athlon XP/MP architecture (registers specially) but I just started >>> another try with CPUTYPE=Athlon-mp and I will post results :) >> The only difference between Athlon XP and Athlon MP is that the MP >> variants are certified for multi-processor use (in reality most Athlon >> XP also worked just fine in multi-processor systems, or could easily be >> modified to do so.) Available instructions and registers are identical >> between the two. Mobile variants of the Athlon XP should also be >> identical from a programming point of view. >> >> >> > That's what I thought too, but in that case, why are they different > optimisations available? > In /usr/share/examples/etc/make.conf: > > # Currently the following CPU types are recognized: > # Intel x86 architecture: > # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 > # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 > > Or maybe some of them are in fact bywords to compiler? > > Still, my CURRENT box is at idle mostly, so I will experiment a little > and see what I get. > > Cheers > Argh, I assumed that 'Mobile Athlon XP' == 'Athlon MP' while it seem's that they aren't. CPUTYPE=athlon-xp was a right choice for my CPU. Sorry for mistake. -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 15:44:37 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 03E101065693 for ; Sun, 26 Sep 2010 15:44:36 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Mon, 27 Sep 2010 00:44:36 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org Message-Id: <20100927004436.997b82d7.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: psm(4) - synaptics touch pad strange behavier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 15:44:37 -0000 Hi psm(4) masters! I have trouble using Synaptics TouchPad, psm(4) on my CF-R9. The trouble is that the mouse cursor moves at random, and the mouse button is clicked without button action. I heard same trouble from ume@'s CF-R8. So I enabled options PSM_DEBUG=5 and traced psm's packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : FreeBSD 9.0-CURRENT #39: Sun Sep 26 22:07:37 JST 2010 nork@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64 : atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 Synaptics Touchpad v6.2 Model information: infoRot180: 0 infoPortrait: 0 infoSensor: 57 infoHardware: 80 infoNewAbs: 1 capPen: 0 infoSimplC: 1 infoGeometry: 2 Extended capabilities: capExtended: 1 capPassthrough: 0 capSleep: 1 capFourButtons: 0 capMultiFinger: 0 capPalmDetect: 1 Additional Buttons: 0 psm0: found Synaptics Touchpad psm0: flags 0x3000 irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons psm0: config:00007000, flags:00000008, packet size:6 psm0: syncmask:c0, syncbits:00 : atkbdc: atkbdc0 already exists; skipping it : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * service moused onestart - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 3b 47 c1 ~~ ~~ required, OK! synaptics signature, OK! psm: ENABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 01 64 ~~ ~~ bad.. synaptics signature, NG! psm0: lost interrupt? psm0: lost interrupt? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * touch to panel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - psmintr: 4a d0 ba 1e 90 d0 ~~ ~~ & 0xc0 must be 0xc0 & 0xc8 must be 0x80 These are NG. psmintr: Sync bytes now 00c0,00c0 ~~~~~~~~~ So mismatch! psmintr: bd 1d 90 be 1a 90 psmintr: out of sync (0080 != 0040) 1 cmds since last error. psmintr: discard a byte (1) psmintr: 1d 90 be 1a 90 59 psmintr: out of sync (0000 != 0040) 0 cmds since last error. psmintr: discard a byte (2) psmintr: 90 be 1a 90 59 d0 psmintr: out of sync (0080 != 0040) 0 cmds since last error. psmintr: discard a byte (3) psmintr: be 1a 90 59 d0 c1 psmintr: out of sync (0080 != 0040) 0 cmds since last error. psmintr: discard a byte (4) psmintr: 1a 90 59 d0 c1 19 psmintr: out of sync (0000 != 0040) 0 cmds since last error. psmintr: discard a byte (5) psmintr: 90 59 d0 c1 19 90 psmintr: out of sync (0080 != 0040) 0 cmds since last error. * Data is discarded, so broken data into proc_synaptics(). psmintr: re-enable the mouse. psm: DISABLE_DEV return code:00fa psm: ENABLE_DEV return code:00fa psmintr: 5c d0 ba 5d d0 aa psmintr: 7c 03 90 3c e7 90 psmintr: cf 6b c0 cf 71 c0 psmintr: out of sync (00c0 != 0040) 0 cmds since last error. psmintr: reset the mouse. psm0: current command byte: 0047 (reinitialize). psm: DISABLE_DEV return code:00fa kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: ENABLE_DEV return code:00fa psm: DISABLE_DEV return code:00fa psm: SET_RESOLUTION (3) 00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 03 64 ~~ ~~ bad.. synaptics signature, NG! psm: SET_RESOLUTION (3) 00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 03 64 ~~ ~~ bad.. synaptics signature, NG! psm: SET_SCALING11 return code:00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (3) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (3) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_RESOLUTION (3) 00fa psm: SEND_AUX_DEV_DATA return code:00fa psm: data 08 00 00 psm: SET_SAMPLING_RATE (200) 00fa psm: SET_SAMPLING_RATE (100) 00fa psm: SET_SAMPLING_RATE (80) 00fa psm: SEND_DEV_ID return code:00fa psm: device ID: 0000 psm: SET_SAMPLING_RATE (200) 00fa psm: SET_SAMPLING_RATE (200) 00fa psm: SET_SAMPLING_RATE (80) 00fa psm: SEND_DEV_ID return code:00fa psm: device ID: 0000 psm: SET_SAMPLING_RATE (200) 00fa psm: SET_SAMPLING_RATE (100) 00fa psm: SET_SAMPLING_RATE (80) 00fa psm: SET_SAMPLING_RATE (60) 00fa psm: SET_SAMPLING_RATE (40) 00fa psm: SET_SAMPLING_RATE (20) 00fa psm: SEND_DEV_ID return code:00fa psm: device ID: 0000 psm: SEND_DEV_ID return code:00fa psm: device ID: 0000 * start enable_synaptics() synaptics: BEGIN init psm: SET_SCALING11 return code:00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 02 47 16 ~~ ~~ extcmd(0x00)'s result is 0x16 synaptics signature, OK! Synaptics Touchpad v6.2 psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (3) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 39 a0 b2 ~~~~~ extcmd(0x03)'s result is OK like following: Model information: infoRot180: 0 infoPortrait: 0 infoSensor: 57 infoHardware: 80 infoNewAbs: 1 capPen: 0 infoSimplC: 1 infoGeometry: 2 psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (2) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status a0 47 51 ~~~~~ extcmd(0x02)'s result is OK like following: Extended capabilities: capExtended: 1 capPassthrough: 0 capSleep: 1 capFourButtons: 0 capMultiFinger: 0 capPalmDetect: 1 psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_RESOLUTION (1) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 00 00 ~~~~~ extcmd(0x09)'s result is OK like following: Additional Buttons: 0 psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 3b 47 41 ~~ ~~ extcmd(0x01)'s result is 0x41 synaptics signature, OK! psm: SET_RESOLUTION (3) 00fa <- 11------ psm: SET_RESOLUTION (0) 00fa <- --00---- psm: SET_RESOLUTION (0) 00fa <- ----00-- psm: SET_RESOLUTION (1) 00fa <- ------01 | or 0b11000001 = 0xc1 mode byte(0xc1) is set, OK. 0xc1 = Absolute mode with W, high packet rate psm: SET_SAMPLING_RATE (20) 00fa synaptics: END init (3 buttons) psm0: found Synaptics Touchpad * finish enable_synaptics() psm: SET_SAMPLING_RATE (100) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_SCALING11 return code:00fa psm: SET_STREAM_MODE return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 02 64 psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 3b 47 c1 psm: ENABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 01 64 psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * service moused stop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - psm0: lost interrupt? psm: DISABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 01 64 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I read Synaptics's "Synaptics PS/2 TouchPad Interfacing Guide", PN: 511-000275-01 Rev.A and sys/dev/atkbdc/psm.c. Accordingly these, I think no problem about implementing synaptics processing part, maybe. But read_aux_data_no_wait is really OK? Accordingly, my dumped data pointed out 'not synaptics data.'. Some initialization is required? I didn't know what. psmintr() in sys/dev/atkbdc/psm.c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - while((c = read_aux_data_no_wait(sc->kbdc)) != -1) { - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To fix this issue, should I do other? -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 17:22:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6383106566B; Sun, 26 Sep 2010 17:22:14 +0000 (UTC) (envelope-from inigoortizdeurbina@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 249C88FC0A; Sun, 26 Sep 2010 17:22:13 +0000 (UTC) Received: by eyx24 with SMTP id 24so1276890eyx.13 for ; Sun, 26 Sep 2010 10:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=7sGqYWzKJcY1Q9NkTdMuLdzS+5mYHpepEZyNR7Jl8/8=; b=JD97dVOPjuLY9qGhrP3NUmBgGHJsooHTfHp6jIF4MEeGJnYM0YANcef+gSdwgEZAy+ HPKW3z+IdtsvGivDV59CbLaxkiI/hr0ZD7VR2lFaX+YV1+5FbLsi4bTX7c0vtTKxm+G/ Ca5fEs5YeqmHNxlPURCFUnKzXaFX4jnxM2AWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=j/ejuhG5kO2zNOkKgYHPhslK1FDn+lYJrHaNQ0Q9poeXwZnpTrdGzHPsUvWS/ZHjrk PgsQ1MkpoyxBUFrGSu0HUqSCSNWuxB0shQ/FWIil/yuhtwEAs7lrAc51WWeS3LCDooFz lp/RE4HHfkiolARa6B2PFy+vJ0NS4BgXckcZY= MIME-Version: 1.0 Received: by 10.213.104.141 with SMTP id p13mr5124346ebo.64.1285519887598; Sun, 26 Sep 2010 09:51:27 -0700 (PDT) Received: by 10.14.119.203 with HTTP; Sun, 26 Sep 2010 09:51:27 -0700 (PDT) In-Reply-To: <20100925174929.GD47356@garage.freebsd.pl> References: <20100925174929.GD47356@garage.freebsd.pl> Date: Sun, 26 Sep 2010 18:51:27 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?= To: Pawel Jakub Dawidek , freebsd-current@freebsd.org, freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: Recent GELI additions. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 17:22:14 -0000 Indeed, truly impressive work. geli makes encryption a bliss :) Thank you very much pjd@! On 9/25/10, Pawel Jakub Dawidek wrote: > Hi. > > I'd like to inform about three new features in GELI available in HEAD: > > 1. AES-XTS encryption. XTS mode is a standard that is recommended these > days for storage encryption. This is the default now. AES-XTS support > was also added to opencrypto framework and aesni(4) driver. > > 2. Multiple encryption keys. GELI will use one encryption key for at > most 2^20 blocks (sectors), as it is not recommended to use the same > encryption key for too much data. It generates keys array from the > master key on attach and uses it accordingly. This is the default now. > > 3. Passphrase can now be loaded from a file (-J and -j options). > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 21:17:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5F81E1065674; Sun, 26 Sep 2010 21:17:57 +0000 (UTC) Date: Sun, 26 Sep 2010 21:17:57 +0000 From: Alexander Best To: Gordon Tetlow Message-ID: <20100926211757.GA3780@freebsd.org> References: <20100910024103.GA77780@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 21:17:57 -0000 On Sat Sep 11 10, Gordon Tetlow wrote: > On Thu, Sep 9, 2010 at 7:41 PM, Alexander Best wrote: > > > > Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages > > > would be appreciated. I'm new to manpage authoring and could use a > > review. > > > > you forgot the AUTHORS section in all of the man pages. ;) it's always nice > > to > > see who wrote the code by reading the man pages and not having to look at > > the > > source itself imho. > > > > It felt weird to promote myself like that. I might add it. There is > certainly precedent for either way. any news on when your work will hit HEAD? cheers. alex > > Gordon -- a13x From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 21:23:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59EA31065695; Sun, 26 Sep 2010 21:23:42 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id EECEF8FC20; Sun, 26 Sep 2010 21:23:41 +0000 (UTC) Received: by qwd6 with SMTP id 6so2857308qwd.13 for ; Sun, 26 Sep 2010 14:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7opovM8EQMTvY61+9PMW10XlbF2hiNy/IuwIcDChGco=; b=BIbphnSU9RUV3WijdcMwtMRc/VVtx8QTrCQzE1c4u7gC+BMjbAKgMkKp913pxO2wlM TPwAvpH3rEIL3uOyfrFCSktw3qFLsGDlXK1Jw/aF0X+mmdhYOaoVYwN7toNmZ+wzhX8U MtSrPGoWeTZNwVxqGQBzTtCS7YWFr06Qwm8e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GI6JrrOCjFSAZEZu83hierjnQKQTuZEhCXlyEtEDOqJbaDtQZL9nFCZCp91a491Hgs dKtf1qFEOfK53sfuIzSzldt9pn67cVvztNm+fyusj1FReNP4xVdGOHYLtpb3XRwSdMpw coWISNDM2GBWZQCkoyxn0oI8HxalPzFqlB/sA= MIME-Version: 1.0 Received: by 10.229.189.131 with SMTP id de3mr4899882qcb.183.1285534369672; Sun, 26 Sep 2010 13:52:49 -0700 (PDT) Received: by 10.229.52.30 with HTTP; Sun, 26 Sep 2010 13:52:49 -0700 (PDT) In-Reply-To: <20100927004436.997b82d7.nork@FreeBSD.org> References: <20100927004436.997b82d7.nork@FreeBSD.org> Date: Sun, 26 Sep 2010 16:52:49 -0400 Message-ID: From: David Horn To: Norikatsu Shigemura Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: psm(4) - synaptics touch pad strange behavier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 21:23:42 -0000 On Sun, Sep 26, 2010 at 11:44 AM, Norikatsu Shigemura wr= ote: > > Hi psm(4) masters! > > =A0 =A0 =A0 =A0I have trouble using Synaptics TouchPad, psm(4) on my CF-R= 9. > =A0 =A0 =A0 =A0The trouble is that the mouse cursor moves at random, and = the > =A0 =A0 =A0 =A0mouse button is clicked without button action. =A0I heard = same > =A0 =A0 =A0 =A0trouble from ume@'s CF-R8. > > =A0 =A0 =A0 =A0So I enabled options PSM_DEBUG=3D5 and traced psm's packet= s. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - - - - > =A0: > FreeBSD 9.0-CURRENT #39: Sun Sep 26 22:07:37 JST 2010 > =A0 =A0nork@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64 > =A0: > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0065 > Synaptics Touchpad v6.2 > =A0Model information: > =A0 infoRot180: 0 > =A0 infoPortrait: 0 > =A0 infoSensor: 57 > =A0 infoHardware: 80 > =A0 infoNewAbs: 1 > =A0 capPen: 0 > =A0 infoSimplC: 1 > =A0 infoGeometry: 2 > =A0Extended capabilities: > =A0 capExtended: 1 > =A0 capPassthrough: 0 > =A0 capSleep: 1 > =A0 capFourButtons: 0 > =A0 capMultiFinger: 0 > =A0 capPalmDetect: 1 > =A0Additional Buttons: 0 > psm0: found Synaptics Touchpad > psm0: flags 0x3000 irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68 > psm0: [GIANT-LOCKED] > psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons > psm0: config:00007000, flags:00000008, packet size:6 > psm0: syncmask:c0, syncbits:00 > =A0: > atkbdc: atkbdc0 already exists; skipping it > =A0: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - - - - > > =A0 =A0 =A0 =A0I read Synaptics's "Synaptics PS/2 TouchPad Interfacing Gu= ide", > =A0 =A0 =A0 =A0PN: 511-000275-01 Rev.A and sys/dev/atkbdc/psm.c. =A0Accor= dingly > =A0 =A0 =A0 =A0these, I think no problem about implementing synaptics pro= cessing > =A0 =A0 =A0 =A0part, maybe. > > =A0 =A0 =A0 =A0But read_aux_data_no_wait is really OK? =A0Accordingly, my= dumped > =A0 =A0 =A0 =A0data pointed out 'not synaptics data.'. =A0Some initializa= tion is > =A0 =A0 =A0 =A0required? =A0I didn't know what. > > psmintr() in sys/dev/atkbdc/psm.c > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - - - - > =A0 =A0 =A0 =A0while((c =3D read_aux_data_no_wait(sc->kbdc)) !=3D -1) { > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - - - - > > =A0 =A0 =A0 =A0To fix this issue, should I do other? > I have not looked at this code in a while, but I seem to remember having some problems when attempting to use the Synaptics extended support in psm(4).=A0=A0 I'm not certain if you are running with or without the loader tunable enabled for extended and/or a custom device.hints. Snippet from psm(4) man page LOADER TUNABLES Extended support for Synaptics touchpads can be enabled by setting hw.psm.synaptics_support to 1 at boot-time. This will enable psm to h= an- dle packets from guest devices (sticks) and extra buttons. Tap and drag gestures can be disabled by setting hw.psm.tap_enabled to= 0 at boot-time. Currently, this is only supported on Synaptics touchpad= s with Extended support disabled. The behaviour may be changed after boo= t by setting the sysctl with the same name and by restarting moused(8) using /etc/rc.d/moused. There is also some additional documentation for the extended support here: http://wiki.freebsd.org/SynapticsTouchpad The last I looked, I was successfully using synaptics touchpad with the loader tunables hw.psm.synaptics_support set to 0, and hw.psm.tap_enabled set to 0 (at least on my Dell 1520), so that the touchpad would just work like a normal mouse. I seem to remember a few pr's (84411) against psm synaptics support for your issue as well (including a potential patch), but best to check with some recent deveopers in this area. (Perhaps philip@ and/or dumbbell@ could chime in ?) Good Luck. -_Dave From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 00:08:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28AD5106566B for ; Mon, 27 Sep 2010 00:08:42 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id D955F8FC08 for ; Mon, 27 Sep 2010 00:08:41 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P00zs-0002iP-Jj for freebsd-current@freebsd.org; Mon, 27 Sep 2010 03:51:08 +0400 Date: Mon, 27 Sep 2010 03:53:14 +0400 From: Artemiev Igor To: freebsd-current@freebsd.org Message-ID: <20100926235313.GA4848@two.kliksys.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 8.3 Subject: netisr software flowid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 00:08:42 -0000 Hi. What is the status for software flowid calculation? I found the old netisr2 patch[1] from Robert Watson and took from there code for setting flowid in tcp_input with some changes[2]. It work for me very well (8.1-stable) - now the server can handle not transit traffic without drops up to 118Kpps 60MB/s incoming and up to 107Kpps 50MB/s outgoing, netisr dispatch packets via three threads by round-robin: 12 root -44 - 0K 336K CPU2 2 18:43 56.15% {swi1: netisr 2} 12 root -44 - 0K 336K RUN 3 18:41 54.49% {swi1: netisr 3} 12 root -44 - 0K 336K CPU0 0 18:39 50.39% {swi1: netisr 0} 12 root -68 - 0K 336K WAIT 1 8:01 18.07% {irq256: bge0} So, what the reason to exclude this code from final version? [1] http://www.watson.org/~robert/freebsd/netperf/20090523-netisr2.diff [2] http://gate.kliksys.ru/~ai/software_flowid.diff From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 02:19:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E90D106564A for ; Mon, 27 Sep 2010 02:19:13 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A88C8FC14 for ; Mon, 27 Sep 2010 02:19:12 +0000 (UTC) Received: by iwn34 with SMTP id 34so5508410iwn.13 for ; Sun, 26 Sep 2010 19:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=F4xsbsL8lYw82HkADPTClq8guFJJf6vTETMKKiJmJyw=; b=hnWMEcfOiSOWj/VSMwvC3iTKetuKXUF2Bz3GO3j9cTGu7wNT7lwL5/BlXAl/OiH3dF ds8spUgsc0QOutTxmANQEwr1BV03lHgWRwLcglrQrtTk+WmUpMtJTOTaezzHGXJUDY3W aAoaiO/RrDkka2Qdr1VQnwGrAPOAeqLjPvKIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jL5gRb5OEidqlmLK/td9L6DittTmHDykpUtxMn+vLRaIgLKaWWScNTJfc6jYgHL1c0 qk1UqhhmV/9usH/3qOumZ8G2vPyzAEQ0EP5TVqebspPsrxfIVxERpqBDr+kxr1mc4jWc 2M0DEaer2bs3r7Nsqqqkvk9y7TYGTQsV4Hyzk= MIME-Version: 1.0 Received: by 10.231.167.130 with SMTP id q2mr8133247iby.163.1285552271850; Sun, 26 Sep 2010 18:51:11 -0700 (PDT) Received: by 10.231.31.195 with HTTP; Sun, 26 Sep 2010 18:51:11 -0700 (PDT) Date: Mon, 27 Sep 2010 09:51:11 +0800 Message-ID: From: Buganini To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Subject: Parallelized scripting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 02:19:13 -0000 Hi, I just wrote a rough C program that may help to do parallelized scripting, for example, parallelized rc.d scripts. http://github.com/buganini/brackets in this way it is easy to use, no need to escape argv for multiple times. any comments are welcomed. Buganini From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 04:30:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D96BC1065670 for ; Mon, 27 Sep 2010 04:30:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-6.mx.aerioconnect.net [216.240.47.66]) by mx1.freebsd.org (Postfix) with ESMTP id A0F6D8FC16 for ; Mon, 27 Sep 2010 04:30:02 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8R45tV6004889 for ; Sun, 26 Sep 2010 21:05:55 -0700 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 9C2582D6018 for ; Sun, 26 Sep 2010 21:05:54 -0700 (PDT) Message-ID: <4CA0184B.7030506@freebsd.org> Date: Sun, 26 Sep 2010 21:06:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: -current under Xen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 04:30:02 -0000 After bruce C gave me the hint of kern.eventtimer.periodic=1, I was able to boot -current on my vps at rootbsd.com, but it hangs on reboot.. some time before the unmounts as the file systems need to be cleaned on the next successful boot. Has anyone had any experience with this? unfortunately I can't yet tell you the version of Xen in use there. From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 05:04:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5BF106564A for ; Mon, 27 Sep 2010 05:04:55 +0000 (UTC) (envelope-from ruschm@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7D48FC15 for ; Mon, 27 Sep 2010 05:04:55 +0000 (UTC) Received: by bwz15 with SMTP id 15so4091541bwz.13 for ; Sun, 26 Sep 2010 22:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=hDEPItltXPUYk/nPAKIqyOnfCUCzYpMMiz6If+z+Ei0=; b=m1Cv1cR5ZLYLOF7lwGNSoBjhlxsbhvwXhf+F8VyR3Yn6tmQStFNv+rklQuIhHP5yLz ukQg1q3lwYXd+AH9T1l9AYAAYrWr/qYL6BZrdO+Ua17Ar9h8NX+ajecAA4vx3KAbkcJZ O3w7DgjO9eX5HHPYfZLowq4omE26fqlgq37JU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iXvbam+4opGRoe6Gto2hpP41Ni3ksj7CTJpT1CvXBMGpHc/O+zcle5zFXHUOVSRTqu 4zzIB8zkWT/pkEUqRTKxaQsiwVmHF+KvnWND04H3oaz9GLsQiIKQ1WpZmYnohX6F1JDb tVdk3Vi45waZV7PFH6xFsuDiuanhr92u+p/js= MIME-Version: 1.0 Received: by 10.204.58.74 with SMTP id f10mr4713362bkh.161.1285562422387; Sun, 26 Sep 2010 21:40:22 -0700 (PDT) Received: by 10.204.79.70 with HTTP; Sun, 26 Sep 2010 21:40:22 -0700 (PDT) Date: Sun, 26 Sep 2010 23:40:22 -0500 Message-ID: From: "Michael R. Rusch" To: support@lists.pcbsd.org, current@freebsd.org X-Mailman-Approved-At: Mon, 27 Sep 2010 05:17:06 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ATI Radeon HD 3200 / HP Laptop (Using) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 05:04:55 -0000 I see that the Radeon HD 3200 needs r600_dri.so On the mailing list I saw on Dec 5, 2009 there was a patch here: http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058115.html Can anyone confirm that this was ever committed to FreeBSD Head and MFC;d 8.1 I cant get my 3D acceleration to work in KDE4 Cheerio! Michael -- Thanks, Michael Rusch ruschm@gmail.com twitter - @weeddude From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 07:46:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B69106564A; Mon, 27 Sep 2010 07:46:17 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 431D68FC0C; Mon, 27 Sep 2010 07:46:17 +0000 (UTC) Received: by iwn34 with SMTP id 34so5766418iwn.13 for ; Mon, 27 Sep 2010 00:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.73 with SMTP id bd9mr8748208ibb.134.1285573218785; Mon, 27 Sep 2010 00:40:18 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 27 Sep 2010 00:40:18 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> Date: Mon, 27 Sep 2010 09:40:18 +0200 Message-ID: From: Olivier Smedts To: Bartosz Stec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rene Ladan , Roman Divacky , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 07:46:17 -0000 2010/9/27 Olivier Smedts : > 2010/9/23 Bartosz Stec : >> =A0On 2010-09-23 08:51, Roman Divacky wrote: >>> >>> if you want to post any build-time numbers for clang please >>> >>> =A0 =A0 =A0 =A0 =A0 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS #-DN= DEBUG >>> >>> uncomment the -DNDEBUG on this line in lib/clang/clang.build.mk >>> and rebuild it otherwise you are using Release+Asserts build of >>> clang which is some 30% slower than the normal one... >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >> >> When i try to rebuild world again (machine has world and kernel builded = with >> clang) I cought following problem at the very beginning: >> >> -------------------------------------------------------------- >>>>> World build started on Thu Sep 23 12:46:55 CEST 2010 >> -------------------------------------------------------------- >> >> -------------------------------------------------------------- >>>>> Rebuilding the temporary build tree >> -------------------------------------------------------------- >> rm -rf /usr/obj/usr/src/tmp >> mkdir -p /usr/obj/usr/src/tmp/lib >> mkdir -p /usr/obj/usr/src/tmp/usr >> mkdir -p /usr/obj/usr/src/tmp/legacy/usr >> mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist =A0-p >> /usr/obj/usr/src/tmp/legacy/usr >/dev/null >> mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist =A0-p /usr/obj/usr/src/tmp= /usr >>>/dev/null >> mtree -deU -f /usr/src/etc/mtree/BSD.include.dist =A0-p >> /usr/obj/usr/src/tmp/usr/include >/dev/null >> ln -sf /usr/src/sys /usr/obj/usr/src/tmp >> >> -------------------------------------------------------------- >>>>> stage 1.1: legacy release compatibility shims >> -------------------------------------------------------------- >> cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp =A0INSTALL=3D"sh >> /usr/src/tools/install.sh" >> =A0PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/lega= cy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/= bin >> =A0WORLDTMP=3D/usr/obj/usr/src/tmp =A0VERSION=3D"FreeBSD 9.0-CURRENT i38= 6 900021" >> =A0MAKEFLAGS=3D"-m /usr/src/tools/build/mk =A0-m /usr/src/share/mk" make= -f >> Makefile.inc1 =A0DESTDIR=3D =A0BOOTSTRAPPING=3D900021 =A0SSP_CFLAGS=3D = =A0-DWITHOUT_HTML >> -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN =A0-DNO_PIC -DWITHOUT_PROFILE >> -DNO_SHARED =A0-DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF legacy >> =3D=3D=3D> tools/build (obj,includes,depend,all,install) >> /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/buil= d >> cd /usr/src/tools/build; make buildincludes; make installincludes >> rm -f .depend >> CC=3D'clang' mkdep -f .depend -a =A0 =A0-I/usr/obj/usr/src/tmp/legacy/us= r/include >> /usr/src/tools/build/dummy.c >> clang -O2 -pipe -std=3Dgnu99 =A0 -I/usr/obj/usr/src/tmp/legacy/usr/inclu= de -c >> /usr/src/tools/build/dummy.c >> building static egacy library >> ranlib libegacy.a >> sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 =A0 libegacy.a >> /usr/obj/usr/src/tmp/legacy/usr/lib >> >> -------------------------------------------------------------- >>>>> stage 1.2: bootstrap tools >> -------------------------------------------------------------- >> cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp =A0INSTALL=3D"sh >> /usr/src/tools/install.sh" >> =A0PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/lega= cy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/= bin >> =A0WORLDTMP=3D/usr/obj/usr/src/tmp =A0VERSION=3D"FreeBSD 9.0-CURRENT i38= 6 900021" >> =A0MAKEFLAGS=3D"-m /usr/src/tools/build/mk =A0-m /usr/src/share/mk" make= -f >> Makefile.inc1 =A0DESTDIR=3D =A0BOOTSTRAPPING=3D900021 =A0SSP_CFLAGS=3D = =A0-DWITHOUT_HTML >> -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN =A0-DNO_PIC -DWITHOUT_PROFILE >> -DNO_SHARED =A0-DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF bootstrap-tools >> =3D=3D=3D> lib/clang/libllvmsupport (obj,depend,all,install) >> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for >> /usr/src/lib/clang/libllvmsupport >> rm -f .depend >> CC=3D'clang' mkdep -f .depend -a >> =A0-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/in= clude >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I= . >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clan= g/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" >> -I/usr/obj/usr/src/tmp/legacy/usr/include >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regc= omp.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/rege= rror.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/rege= xec.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regf= ree.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regs= trlcpy.c >> CC=3D'clang' mkdep -f .depend -a >> =A0-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/in= clude >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I= . >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clan= g/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" >> -I/usr/obj/usr/src/tmp/legacy/usr/include >> =A0/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/A= PFloat.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APIn= t.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSI= nt.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allo= cator.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Comm= andLine.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Cons= tantRange.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Cras= hRecoveryContext.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGD= eltaAlgorithm.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debu= g.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Delt= aAlgorithm.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwar= f.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Erro= rHandling.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Fold= ingSet.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Form= attedStream.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Grap= hWriter.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Mana= gedStatic.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Memo= ryBuffer.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Plug= inLoader.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Pret= tyStackTrace.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Rege= x.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Smal= lPtrSet.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Smal= lVector.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Sour= ceMgr.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stat= istic.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngExtras.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngMap.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngPool.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngRef.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Targ= etRegistry.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Time= r.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Trip= le.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Twin= e.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/circ= ular_raw_ostream.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_= os_ostream.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_= ostream.cpp >> clang++ -O2 -pipe >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/in= clude >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I= . >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clan= g/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" -fno-exceptions >> -I/usr/obj/usr/src/tmp/legacy/usr/include -c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFl= oat.cpp >> Assertion failed: (false && "Ran out of registers during register >> allocation!"), function assignRegOrStackSlotAtInterval, file >> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegA= llocLinearScan.cpp, >> line 1196. >> Stack dump: >> 0. =A0 =A0 =A0Program arguments: /usr/bin/clang++ -cc1 -triple >> i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name APFloat.cpp >> -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases >> -target-cpu i486 -resource-dir /usr/lib/clang/2.8 -D LLVM_ON_UNIX -D >> LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -D NDEB= UG >> -D LLVM_HOSTTRIPLE=3D"i386-undermydesk-freebsd9.0" -I >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude >> -I /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -= I . >> -I >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include >> -I /usr/obj/usr/src/tmp/legacy/usr/include -O2 -ferror-limit 19 >> -fmessage-length 205 -fgnu-runtime -fdiagnostics-show-option >> -fcolor-diagnostics -o /tmp/cc-lvFfGd.s -x c++ >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFl= oat.cpp >> 1. parser at end of file >> 2. =A0 =A0 =A0Code generation >> 3. =A0 =A0 =A0Running pass 'Linear Scan Register Allocator' on function >> '@_ZN4llvm7APFloat28convertFromHexadecimalStringENS_9StringRefENS0_12rou= ndingModeE' >> clang++: error: clang frontend command failed due to signal 6 (use -v to= see >> invocation) >> *** Error code 250 > > Same error here with yesterday's -CURRENT, but not at the same time > (the running system was compiled using gcc) : > > # uname -a > FreeBSD z.gid0.org 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Sep 24 > 22:07:43 CEST 2010 =A0 =A0 root@z.gid0.org:/usr/obj/usr/src/sys/XPC =A0i3= 86 > # clang -v > FreeBSD clang version 2.8 (branches/release_28 114020) 20100917 > Target: i386-undermydesk-freebsd9.0 > Thread model: posix > # grep -vE '^#|^$' /etc/make.conf > KERNCONF=3DXPC > CPUTYPE=3Dathlon-xp > CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer > NO_CPU_CFLAGS=3Dyes > COPTFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer > NO_CPU_COPTFLAGS=3Dyes > WITHOUT_PROFILE=3Dyes > SUP_UPDATE=3Dyes > SUPFILE=3D/usr/share/examples/cvsup/standard-supfile > SUPHOST=3Dcvsup3.fr.freebsd.org > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > NO_WERROR=3D > WERROR=3D Sorry for replying to my own post. I'm currently retrying with "-DNDEBUG", as I have -fomit-frame-pointer in my CFLAGS (it breaks debugging and profiling). The box is quite slow, so I'll post the results later. Cheers > # make buildworld > [...] > =3D=3D=3D> gnu/lib/libgcc (obj,depend,all,install) > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc tm.h > TARGET_CPU_DEFAULT=3D"" =A0HEADERS=3D"options.h i386/i386.h i386/unix.h > i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h > freebsd-spec.h freebsd.h i386/freebsd.h defaults.h" =A0DEFINES=3D"" > /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h > echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc tconfig.h > TARGET_CPU_DEFAULT=3D"" =A0HEADERS=3D"auto-host.h ansidecl.h" > DEFINES=3D"USED_FOR_TARGET" =A0/bin/sh > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc options.h > LC_ALL=3DC awk -f > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/c.opt > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/common.opt > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.opt > > optionlist > LC_ALL=3DC awk -f > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk =A0-f > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk =A0< > optionlist > options.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h > ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwi= nd.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h > ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-def= ault.h > clang -c -O2 -pipe -march=3Dnative -fomit-frame-pointer -DIN_GCC > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED =A0-DHAVE_GTHR_DEFAULT > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. > -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 > -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 > -DElfW=3D__ElfN -o unwind-dw2.o > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > Assertion failed: (!spillIs.empty() && "No spill intervals?"), > function assignRegOrStackSlotAtInterval, file > /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAl= locLinearScan.cpp, > line 1287. > Stack dump: > 0. =A0 =A0 =A0Program arguments: /usr/obj/usr/src/tmp/usr/bin/clang -cc1 > -triple i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name > unwind-dw2.c -pic-level 2 -mconstructor-aliases -target-cpu athlon-mp > -resource-dir /usr/obj/usr/src/tmp/usr/lib/clang/2.8 -D IN_GCC -D > IN_LIBGCC2 -D __GCC_FLOAT_NOT_NEEDED -D HAVE_GTHR_DEFAULT -D > HIDE_EXPORTS -D __GLIBC__=3D3 -D ElfW=3D__ElfN -I > /usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I > /usr/src/gnu/lib/libgcc/../../../contrib/gcc -I . -I > /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -O2 -std=3Dgnu99 > -ferror-limit 19 -fmessage-length 118 -fvisibility hidden -fexceptions > -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o > /tmp/cc-UeLPOI.s -x c > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > 1. =A0 =A0 =A0 parser at end of file > 2. =A0 =A0 =A0Code generation > 3. =A0 =A0 =A0Running pass 'Linear Scan Register Allocator' on function > '@_Unwind_GetGR' > clang: error: clang frontend command failed due to signal 6 (use -v to > see invocation) > *** Error code 250 > > Stop in /usr/src/gnu/lib/libgcc. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > -- > Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 = X > www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ > > =A0 "Il y a seulement 10 sortes de gens dans le monde : > =A0 ceux qui comprennent le binaire, > =A0 et ceux qui ne le comprennent pas." > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 08:03:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62A9B1065698; Mon, 27 Sep 2010 08:03:03 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 13F6A8FC1E; Mon, 27 Sep 2010 08:03:02 +0000 (UTC) Received: by iwn34 with SMTP id 34so5779934iwn.13 for ; Mon, 27 Sep 2010 01:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.173.144 with SMTP id p16mr8609403ibz.108.1285572766788; Mon, 27 Sep 2010 00:32:46 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 27 Sep 2010 00:32:46 -0700 (PDT) In-Reply-To: <4C9B3207.2070302@kkip.pl> References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> Date: Mon, 27 Sep 2010 09:32:46 +0200 Message-ID: From: Olivier Smedts To: Bartosz Stec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rene Ladan , Roman Divacky , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 08:03:03 -0000 2010/9/23 Bartosz Stec : > =A0On 2010-09-23 08:51, Roman Divacky wrote: >> >> if you want to post any build-time numbers for clang please >> >> =A0 =A0 =A0 =A0 =A0 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS #-DND= EBUG >> >> uncomment the -DNDEBUG on this line in lib/clang/clang.build.mk >> and rebuild it otherwise you are using Release+Asserts build of >> clang which is some 30% slower than the normal one... >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > When i try to rebuild world again (machine has world and kernel builded w= ith > clang) I cought following problem at the very beginning: > > -------------------------------------------------------------- >>>> World build started on Thu Sep 23 12:46:55 CEST 2010 > -------------------------------------------------------------- > > -------------------------------------------------------------- >>>> Rebuilding the temporary build tree > -------------------------------------------------------------- > rm -rf /usr/obj/usr/src/tmp > mkdir -p /usr/obj/usr/src/tmp/lib > mkdir -p /usr/obj/usr/src/tmp/usr > mkdir -p /usr/obj/usr/src/tmp/legacy/usr > mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist =A0-p > /usr/obj/usr/src/tmp/legacy/usr >/dev/null > mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist =A0-p /usr/obj/usr/src/tmp/= usr >>/dev/null > mtree -deU -f /usr/src/etc/mtree/BSD.include.dist =A0-p > /usr/obj/usr/src/tmp/usr/include >/dev/null > ln -sf /usr/src/sys /usr/obj/usr/src/tmp > > -------------------------------------------------------------- >>>> stage 1.1: legacy release compatibility shims > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp =A0INSTALL=3D"sh > /usr/src/tools/install.sh" > =A0PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legac= y/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/b= in > =A0WORLDTMP=3D/usr/obj/usr/src/tmp =A0VERSION=3D"FreeBSD 9.0-CURRENT i386= 900021" > =A0MAKEFLAGS=3D"-m /usr/src/tools/build/mk =A0-m /usr/src/share/mk" make = -f > Makefile.inc1 =A0DESTDIR=3D =A0BOOTSTRAPPING=3D900021 =A0SSP_CFLAGS=3D = =A0-DWITHOUT_HTML > -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN =A0-DNO_PIC -DWITHOUT_PROFILE > -DNO_SHARED =A0-DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF legacy > =3D=3D=3D> tools/build (obj,includes,depend,all,install) > /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build > cd /usr/src/tools/build; make buildincludes; make installincludes > rm -f .depend > CC=3D'clang' mkdep -f .depend -a =A0 =A0-I/usr/obj/usr/src/tmp/legacy/usr= /include > /usr/src/tools/build/dummy.c > clang -O2 -pipe -std=3Dgnu99 =A0 -I/usr/obj/usr/src/tmp/legacy/usr/includ= e -c > /usr/src/tools/build/dummy.c > building static egacy library > ranlib libegacy.a > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 =A0 libegacy.a > /usr/obj/usr/src/tmp/legacy/usr/lib > > -------------------------------------------------------------- >>>> stage 1.2: bootstrap tools > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp =A0INSTALL=3D"sh > /usr/src/tools/install.sh" > =A0PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legac= y/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/b= in > =A0WORLDTMP=3D/usr/obj/usr/src/tmp =A0VERSION=3D"FreeBSD 9.0-CURRENT i386= 900021" > =A0MAKEFLAGS=3D"-m /usr/src/tools/build/mk =A0-m /usr/src/share/mk" make = -f > Makefile.inc1 =A0DESTDIR=3D =A0BOOTSTRAPPING=3D900021 =A0SSP_CFLAGS=3D = =A0-DWITHOUT_HTML > -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN =A0-DNO_PIC -DWITHOUT_PROFILE > -DNO_SHARED =A0-DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF bootstrap-tools > =3D=3D=3D> lib/clang/libllvmsupport (obj,depend,all,install) > /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for > /usr/src/lib/clang/libllvmsupport > rm -f .depend > CC=3D'clang' mkdep -f .depend -a > =A0-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/inc= lude > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang= /include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DNDEBUG > -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" > -I/usr/obj/usr/src/tmp/legacy/usr/include > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regco= mp.c > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/reger= ror.c > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regex= ec.c > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regfr= ee.c > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regst= rlcpy.c > CC=3D'clang' mkdep -f .depend -a > =A0-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/inc= lude > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang= /include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DNDEBUG > -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" > -I/usr/obj/usr/src/tmp/legacy/usr/include > =A0/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/AP= Float.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt= .cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSIn= t.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Alloc= ator.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Comma= ndLine.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Const= antRange.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Crash= RecoveryContext.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGDe= ltaAlgorithm.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debug= .cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Delta= Algorithm.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwarf= .cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Error= Handling.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Foldi= ngSet.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Forma= ttedStream.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Graph= Writer.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Manag= edStatic.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Memor= yBuffer.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Plugi= nLoader.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Prett= yStackTrace.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Regex= .cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Small= PtrSet.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Small= Vector.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Sourc= eMgr.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stati= stic.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Strin= gExtras.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Strin= gMap.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Strin= gPool.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Strin= gRef.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Targe= tRegistry.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Timer= .cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Tripl= e.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Twine= .cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/circu= lar_raw_ostream.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_o= s_ostream.cpp > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_o= stream.cpp > clang++ -O2 -pipe > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/inc= lude > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang= /include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DNDEBUG > -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" -fno-exceptions > -I/usr/obj/usr/src/tmp/legacy/usr/include -c > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFlo= at.cpp > Assertion failed: (false && "Ran out of registers during register > allocation!"), function assignRegOrStackSlotAtInterval, file > /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAl= locLinearScan.cpp, > line 1196. > Stack dump: > 0. =A0 =A0 =A0Program arguments: /usr/bin/clang++ -cc1 -triple > i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name APFloat.cpp > -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases > -target-cpu i486 -resource-dir /usr/lib/clang/2.8 -D LLVM_ON_UNIX -D > LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -D NDEBU= G > -D LLVM_HOSTTRIPLE=3D"i386-undermydesk-freebsd9.0" -I > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/inclu= de > -I /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I= . > -I > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/i= nclude > -I /usr/obj/usr/src/tmp/legacy/usr/include -O2 -ferror-limit 19 > -fmessage-length 205 -fgnu-runtime -fdiagnostics-show-option > -fcolor-diagnostics -o /tmp/cc-lvFfGd.s -x c++ > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFlo= at.cpp > 1. parser at end of file > 2. =A0 =A0 =A0Code generation > 3. =A0 =A0 =A0Running pass 'Linear Scan Register Allocator' on function > '@_ZN4llvm7APFloat28convertFromHexadecimalStringENS_9StringRefENS0_12roun= dingModeE' > clang++: error: clang frontend command failed due to signal 6 (use -v to = see > invocation) > *** Error code 250 Same error here with yesterday's -CURRENT, but not at the same time (the running system was compiled using gcc) : # uname -a FreeBSD z.gid0.org 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Sep 24 22:07:43 CEST 2010 root@z.gid0.org:/usr/obj/usr/src/sys/XPC i386 # clang -v FreeBSD clang version 2.8 (branches/release_28 114020) 20100917 Target: i386-undermydesk-freebsd9.0 Thread model: posix # grep -vE '^#|^$' /etc/make.conf KERNCONF=3DXPC CPUTYPE=3Dathlon-xp CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer NO_CPU_CFLAGS=3Dyes COPTFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer NO_CPU_COPTFLAGS=3Dyes WITHOUT_PROFILE=3Dyes SUP_UPDATE=3Dyes SUPFILE=3D/usr/share/examples/cvsup/standard-supfile SUPHOST=3Dcvsup3.fr.freebsd.org .if !defined(CC) || ${CC} =3D=3D "cc" CC=3Dclang .endif .if !defined(CXX) || ${CXX} =3D=3D "c++" CXX=3Dclang++ .endif NO_WERROR=3D WERROR=3D # make buildworld [...] =3D=3D=3D> gnu/lib/libgcc (obj,depend,all,install) make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc tm.h TARGET_CPU_DEFAULT=3D"" HEADERS=3D"options.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/freebsd.h defaults.h" DEFINES=3D"" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc tconfig.h TARGET_CPU_DEFAULT=3D"" HEADERS=3D"auto-host.h ansidecl.h" DEFINES=3D"USED_FOR_TARGET" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc options.h LC_ALL=3DC awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /usr/src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.opt > optionlist LC_ALL=3DC awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind= .h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-defau= lt.h clang -c -O2 -pipe -march=3Dnative -fomit-frame-pointer -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 -DElfW=3D__ElfN -o unwind-dw2.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c Assertion failed: (!spillIs.empty() && "No spill intervals?"), function assignRegOrStackSlotAtInterval, file /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAllo= cLinearScan.cpp, line 1287. Stack dump: 0. Program arguments: /usr/obj/usr/src/tmp/usr/bin/clang -cc1 -triple i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name unwind-dw2.c -pic-level 2 -mconstructor-aliases -target-cpu athlon-mp -resource-dir /usr/obj/usr/src/tmp/usr/lib/clang/2.8 -D IN_GCC -D IN_LIBGCC2 -D __GCC_FLOAT_NOT_NEEDED -D HAVE_GTHR_DEFAULT -D HIDE_EXPORTS -D __GLIBC__=3D3 -D ElfW=3D__ElfN -I /usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I /usr/src/gnu/lib/libgcc/../../../contrib/gcc -I . -I /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -O2 -std=3Dgnu99 -ferror-limit 19 -fmessage-length 118 -fvisibility hidden -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-UeLPOI.s -x c /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c 1. parser at end of file 2. Code generation 3. Running pass 'Linear Scan Register Allocator' on function '@_Unwind_GetGR' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) *** Error code 250 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 08:21:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 742C91065672 for ; Mon, 27 Sep 2010 08:21:58 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01ABA8FC17 for ; Mon, 27 Sep 2010 08:21:57 +0000 (UTC) Received: by fxm9 with SMTP id 9so3374239fxm.13 for ; Mon, 27 Sep 2010 01:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=zeJTlDbj7/2h7liMQduBVfX/kQVQRt9g3xWeNzE0cwA=; b=LjMDUNL5mogA/DdRc7dfV0vA0BNcIEEKvfu4fGM5gM4nBB7I+5YAVv8AEhObvqZqpy yQ2XRD509JwryWKbJrixGLD5+eeVSFE8utvODn+/SViTel9kFNWUmL+xIlEs9VHRBZQY f9eQ79eHTrAoauKLb744jn+gCkePnnMBW22WI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=PKrO8G1osSLLZNUnPug0y9OuD48GcxRr9UYfG+WRgN5+FGxbzPt5eiAuZkO9tokvye GprK7s8niLso7k4EiPclAYsM229tRv012XJUYoEHe9h9Njd1pzS8jsXuBxY0owrUhQl7 naobxeXU8wtEoWopbXzb0zANu/v8ejhH0fp04= Received: by 10.223.104.17 with SMTP id m17mr7218314fao.22.1285575716470; Mon, 27 Sep 2010 01:21:56 -0700 (PDT) Received: from ernst.jennejohn.org (p578E3B24.dip.t-dialin.net [87.142.59.36]) by mx.google.com with ESMTPS id t6sm2244089faa.3.2010.09.27.01.21.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 01:21:55 -0700 (PDT) Date: Mon, 27 Sep 2010 10:21:53 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20100927102153.6ea0ff58@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Michael R. Rusch" Subject: Re: ATI Radeon HD 3200 / HP Laptop (Using) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 08:21:58 -0000 On Sun, 26 Sep 2010 23:40:22 -0500 "Michael R. Rusch" wrote: > I see that the Radeon HD 3200 needs r600_dri.so > This is installed by /usr/ports/graphics/dri, which has been around since the beginning of this year. See the 20100207 entry about Mesa3D in /usr/ports/UPDATING. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 08:52:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A319106564A for ; Mon, 27 Sep 2010 08:52:22 +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 335B28FC21 for ; Mon, 27 Sep 2010 08:52:22 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CC56E46B1A; Mon, 27 Sep 2010 04:52:21 -0400 (EDT) Date: Mon, 27 Sep 2010 09:52:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Artemiev Igor In-Reply-To: <20100926235313.GA4848@two.kliksys.ru> Message-ID: References: <20100926235313.GA4848@two.kliksys.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: netisr software flowid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 08:52:22 -0000 On Mon, 27 Sep 2010, Artemiev Igor wrote: > What is the status for software flowid calculation? I found the old netisr2 > patch[1] from Robert Watson and took from there code for setting flowid in > tcp_input with some changes[2]. It work for me very well (8.1-stable) - now > the server can handle not transit traffic without drops up to 118Kpps 60MB/s > incoming and up to 107Kpps 50MB/s outgoing, netisr dispatch packets via > three threads by round-robin: Hi Artemiev: I have a large outstanding patch set in Perforce that goes quite a long way further, implementing the RSS model found in many network cards and aligning OS hash tables for connection lookup with RSS. Where the RSS hash is made available by the driver, the patches are also able to implement link-layer dispatch. They largely eliminate the possibility of cache line contention in the TCP/IP input path (as long as the driver also avoids cache line contention) on multi-queue cards. One reason I haven't merged the earlier patch is that many high-performance 10gbps (and even 1gbps) cards now support multiple input queues in hardware, meaning that they have already done the work distribution by the time the packets get to the OS. This makes the work distribution choice quite a bit harder: has a packet already been adequately balanced, or is further rebalancing required -- and of so, an equal distribution as selected in that patch might not generate well-balanced CPU load. Using just the RSS hash to distribute work, and single-queue input, I am able to get doubled end-host TCP performance with highly concurrent connections at 10gbps, which is a useful result. I have high on my todo list to get the patch you referenced into the mix as well and see how much the software distrbiution hurts/helps... Since you've done some measurement, what was the throughput on that system without the patch applied, and how many cores? Robert > > 12 root -44 - 0K 336K CPU2 2 18:43 56.15% {swi1: netisr 2} > 12 root -44 - 0K 336K RUN 3 18:41 54.49% {swi1: netisr 3} > 12 root -44 - 0K 336K CPU0 0 18:39 50.39% {swi1: netisr 0} > 12 root -68 - 0K 336K WAIT 1 8:01 18.07% {irq256: bge0} > > So, what the reason to exclude this code from final version? > > [1] http://www.watson.org/~robert/freebsd/netperf/20090523-netisr2.diff > [2] http://gate.kliksys.ru/~ai/software_flowid.diff > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 09:53:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036B01065670 for ; Mon, 27 Sep 2010 09:53:10 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id AD3C88FC1A for ; Mon, 27 Sep 2010 09:53:09 +0000 (UTC) Received: by qyk7 with SMTP id 7so4616923qyk.13 for ; Mon, 27 Sep 2010 02:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nlBtRkuq9lyJeNR7jemrsTUtzh9WqA8R86/TWle76Hk=; b=F00lrjjWPIxyOQzdpKUlCuf1UdCv78KlANgmwS/CTX6J5mq9BKPxMbETQK9GuKTv1q VlTxoS4nX6//Eys0Pv3Juh0C2eKdrU2JgNxyoBHNFDZ/FVlVe0oeVcvrkI+64Twgu1ey F3Lg7oiq2JpfzAc2+heAgM5keOdlENVN+nly0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Na9cMOTjfA+ymJKrMelgOQsiV2OG81GDztxWL/+7soHmlBr2m8uSf8s5BmQt1qe1cl FzhkxFggZkneYvKQc/xlSj0Yt+KgsjGCHX4s4bhinLHwD0y/PLF0qNwWUPdY/rmYBSTR 9Fb2Dd0oWyp5tunLZqquW/339RqD5zCM5BaZM= MIME-Version: 1.0 Received: by 10.229.191.147 with SMTP id dm19mr5443198qcb.33.1285579715678; Mon, 27 Sep 2010 02:28:35 -0700 (PDT) Received: by 10.229.227.131 with HTTP; Mon, 27 Sep 2010 02:28:35 -0700 (PDT) In-Reply-To: <20100927102153.6ea0ff58@ernst.jennejohn.org> References: <20100927102153.6ea0ff58@ernst.jennejohn.org> Date: Mon, 27 Sep 2010 04:28:35 -0500 Message-ID: From: "Sam Fourman Jr." To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, "Michael R. Rusch" Subject: Re: ATI Radeon HD 3200 / HP Laptop (Using) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 09:53:10 -0000 On Mon, Sep 27, 2010 at 3:21 AM, Gary Jennejohn wrote: > On Sun, 26 Sep 2010 23:40:22 -0500 > "Michael R. Rusch" wrote: > >> I see that the Radeon HD 3200 needs r600_dri.so >> > > This is installed by /usr/ports/graphics/dri, which has been around since > the beginning of this year. > > See the 20100207 entry about Mesa3D in /usr/ports/UPDATING. >From /usr/ports/UPDATING 20100207: AFFECTS: users of Mesa3D libraries and x11-drivers/xf86-video-nouveau AUTHOR: nork@FreeBSD.org If you want to use Mesa3D 7.6.1 and libdrm 2.4.17 rather than 7.4.4 and 2.4.12, you must define WITHOUT_NOUVEAU global macro, at least, enabled on graphics/libGL*, graphics/libglut, graphics/dri, graphics/mesa-demos, and graphics/libdrm. And please give up using x11-drivers/xf86-video-nouveau. At this time, I cannot enable latest Mesa3D and libdrm, because they break xf86-video-nouveau. But old (current?) Mesa3D and libdrm do not break any drivers. AMD Radeon HD 2xxx/3xxx/4xxx users: If you use AMD Radeon HD [234]xxx series, please define WITHOUT_NOUVEAU global macro. You can then use OpenGL Hardware Accelerator feature on these series. how would we define define WITHOUT_NOUVEAU on PC-BSD 8.1 it is pre-compiled? what are our options for 3d accelerated radeonHD 3200 Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 10:38:54 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63E4F106567A; Mon, 27 Sep 2010 10:38:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 20A868FC13; Mon, 27 Sep 2010 10:38:54 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:3940:c45b:c1c1:f335] (unknown [IPv6:2001:7b8:3a7:0:3940:c45b:c1c1:f335]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ED0CC5C43; Mon, 27 Sep 2010 12:38:52 +0200 (CEST) Message-ID: <4CA0743F.8050408@FreeBSD.org> Date: Mon, 27 Sep 2010 12:38:55 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.10pre) Gecko/20100910 Lanikai/3.1.4pre MIME-Version: 1.0 To: Olivier Smedts References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rene Ladan , Roman Divacky , Bartosz Stec , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 10:38:54 -0000 On 2010-09-27 09:32, Olivier Smedts wrote: > 2010/9/23 Bartosz Stec: ... >> Assertion failed: (false&& "Ran out of registers during register >> allocation!"), function assignRegOrStackSlotAtInterval, file >> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAllocLinearScan.cpp, >> line 1196. ... > Same error here with yesterday's -CURRENT, but not at the same time > (the running system was compiled using gcc) : As with Bartosz, could you please remove the CPU-specific flags from make.conf, and try again? I guess there is something borked in LLVM's Athlon optimization, so it is probably better to not try to tickly those bugs for now. > # grep -vE '^#|^$' /etc/make.conf > KERNCONF=XPC > CPUTYPE=athlon-xp > CFLAGS=-O2 -pipe -march=native -fomit-frame-pointer Using CPUTYPE= and -march= seems a bit redundant. :) > clang -c -O2 -pipe -march=native -fomit-frame-pointer -DIN_GCC > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. > -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=gnu99 > -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 > -DElfW=__ElfN -o unwind-dw2.o > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > Assertion failed: (!spillIs.empty()&& "No spill intervals?"), > function assignRegOrStackSlotAtInterval, file > /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAllocLinearScan.cpp, > line 1287. I haven't yet seen this one before. If I can reproduce it, I will report it upstream, and see if they can come up with a fix. From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 12:20:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FCA106566B; Mon, 27 Sep 2010 12:20:30 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4F59D8FC08; Mon, 27 Sep 2010 12:20:30 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=M8qpYxtMbuYA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=QBj5VyZNsCFbVmv3EhQA:9 a=50t1jiUm4qqUZZmtUkX-bNwlnS4A:4 a=wPNLvfGTeEIA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 26944323; Mon, 27 Sep 2010 14:20:28 +0200 To: freebsd-current@freebsd.org From: Hans Petter Selasky X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' Date: Mon, 27 Sep 2010 14:21:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009271421.42082.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: [USB] Keyboard, mouse and ergonomy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 12:20:31 -0000 Hi, I was thinking about adding a sysctl to ukbd and ums that shows how many keypresses have been done and how many pixels you have moved the mouse during a day. These number will mostly be useful for making ergonomic arguments that a certain way of working is better than another one. Anyone have any comments or input on this? Are there any security concerns about this? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 12:24:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB6A510656C9; Mon, 27 Sep 2010 12:24:57 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 263478FC13; Mon, 27 Sep 2010 12:24:56 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=M8qpYxtMbuYA:10 a=kj9zAlcOel0A:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=QBj5VyZNsCFbVmv3EhQA:9 a=50t1jiUm4qqUZZmtUkX-bNwlnS4A:4 a=CjuIK1q_8ugA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 26362834; Mon, 27 Sep 2010 14:14:52 +0200 Received-SPF: softfail receiver=mailfe06.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 27 Sep 2010 14:16:05 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201009271416.06030.hselasky@freebsd.org> Cc: freebsd-usb@freebsd.org Subject: [USB] Keyboard, mouse and ergonomy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 12:24:57 -0000 Hi, I was thinking about adding a sysctl to ukbd and ums that shows how many keypresses have been done and how many pixels you have moved the mouse during a day. These number will mostly be useful for making ergonomic arguments that a certain way of working is better than another one. Anyone have any comments or input on this? Are there any security concerns about this? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 12:30:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 502AE106564A; Mon, 27 Sep 2010 12:30:21 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EADE58FC18; Mon, 27 Sep 2010 12:30:20 +0000 (UTC) Received: by iwn34 with SMTP id 34so5998259iwn.13 for ; Mon, 27 Sep 2010 05:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.155.212 with SMTP id t20mr9193347ibw.37.1285590620144; Mon, 27 Sep 2010 05:30:20 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 27 Sep 2010 05:30:18 -0700 (PDT) In-Reply-To: <4CA0743F.8050408@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> <4CA0743F.8050408@FreeBSD.org> Date: Mon, 27 Sep 2010 14:30:18 +0200 Message-ID: From: Olivier Smedts To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rene Ladan , Roman Divacky , Bartosz Stec , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 12:30:21 -0000 2010/9/27 Dimitry Andric : > On 2010-09-27 09:32, Olivier Smedts wrote: >> >> 2010/9/23 Bartosz Stec: > > ... >>> >>> Assertion failed: (false&& =A0"Ran out of registers during register >>> allocation!"), function assignRegOrStackSlotAtInterval, file >>> >>> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/Reg= AllocLinearScan.cpp, >>> line 1196. > > ... >> >> Same error here with yesterday's -CURRENT, but not at the same time >> (the running system was compiled using gcc) : > > As with Bartosz, could you please remove the CPU-specific flags from > make.conf, and try again? Ok, I'll post the results later (it was the same with -DNDEBUG). > I guess there is something borked in LLVM's Athlon optimization, so it > is probably better to not try to tickly those bugs for now. > > > >> # grep -vE '^#|^$' /etc/make.conf >> KERNCONF=3DXPC >> CPUTYPE=3Dathlon-xp >> CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer > > Using CPUTYPE=3D and -march=3D seems a bit redundant. :) Not with NO_CPU_CFLAGS=3Dyes and NO_CPU_COPTFLAGS=3Dyes (if you want to use -march=3Dnative, that's the best thing to do). > >> clang -c -O2 -pipe -march=3Dnative -fomit-frame-pointer -DIN_GCC >> -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED =A0-DHAVE_GTHR_DEFAULT >> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include >> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config >> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. >> -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 >> -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 >> -DElfW=3D__ElfN -o unwind-dw2.o >> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c >> Assertion failed: (!spillIs.empty()&& =A0"No spill intervals?"), >> function assignRegOrStackSlotAtInterval, file >> >> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegA= llocLinearScan.cpp, >> line 1287. > > I haven't yet seen this one before. =A0If I can reproduce it, I will > report it upstream, and see if they can come up with a fix. > Thanks ! --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 13:34:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4FAD106564A; Mon, 27 Sep 2010 13:34:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECD48FC12; Mon, 27 Sep 2010 13:34:35 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3BBAB.dip.t-dialin.net [87.179.187.171]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 5F65384400C; Mon, 27 Sep 2010 15:34:30 +0200 (CEST) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 0A9BB188A; Mon, 27 Sep 2010 15:34:23 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o8RDYJxG078614; Mon, 27 Sep 2010 15:34:19 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 27 Sep 2010 15:34:19 +0200 Message-ID: <20100927153419.13263v44ijw12m4g@webmail.leidinger.net> Date: Mon, 27 Sep 2010 15:34:19 +0200 From: Alexander Leidinger To: Hans Petter Selasky References: <201009271421.42082.hselasky@c2i.net> In-Reply-To: <201009271421.42082.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 5F65384400C.A861B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.351, required 6, autolearn=disabled, RDNS_NONE 1.27, TW_KB 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1286199272.86372@NeVIGK3YKSmy73w8K/FcDg X-EBL-Spam-Status: No Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [USB] Keyboard, mouse and ergonomy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 13:34:36 -0000 Quoting Hans Petter Selasky (from Mon, 27 Sep 2010 14:21:42 +0200): > Hi, > > I was thinking about adding a sysctl to ukbd and ums that shows how many > keypresses have been done and how many pixels you have moved the mouse during > a day. These number will mostly be useful for making ergonomic arguments that > a certain way of working is better than another one. > > Anyone have any comments or input on this? Are there any security concerns > about this? Be careful with ergonomic arguments. For example the screen corners are easy (and fast) mouse targets (if they are used for something in the software), and would give a false impression if you count mouse-device movement instead of mouse-pointer movement on the screen (which you can not measure in ums). The most easy ergonomic point for a mouse is the current position (pop-up menus), and this involves not much movement... Regarding key-presses there's also the problem of having the keys directly under your fingers, or having to move back and forth with the hands (also depends upon the keyboard layout and type of work you do). Regarding metrics I suggest to: - add a click-count - not hardcode the counter-reset (let a sysctl handle the counter reset upon request) - differentiate between normal key presses and shift-ed/control-ed/... ones (I do not think that caps-lock should count as shift-ed) - I do not know if it makes sense to have a hold-time (for shift/control/...), if this is for real ergonomic research, this could be helpful Regarding the security: - don't make this real-time stats, add some artificial delay (you could interpolate what is typed just by watching the stats), I suggest to make the delay at least several seconds long (to cover people with disabilities and maybe people which search each character with one finger), for real ergonomic research this is counter-productive (but you stated that you want to measure on a per-day basis, to this should not matter in your case) - make it depending on a compile time knob (disabled by default) and issue a warning on device attach if compiled in Bye, Alexander. -- An honest tale speeds best being plainly told. -- William Shakespeare, "Henry VI" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 13:50:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7C07D106566C; Mon, 27 Sep 2010 13:50:35 +0000 (UTC) Date: Mon, 27 Sep 2010 13:50:35 +0000 From: Alexander Best To: Hans Petter Selasky Message-ID: <20100927135035.GA42926@freebsd.org> References: <201009271421.42082.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009271421.42082.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [USB] Keyboard, mouse and ergonomy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 13:50:35 -0000 On Mon Sep 27 10, Hans Petter Selasky wrote: > Hi, > > I was thinking about adding a sysctl to ukbd and ums that shows how many > keypresses have been done and how many pixels you have moved the mouse during > a day. These number will mostly be useful for making ergonomic arguments that > a certain way of working is better than another one. > > Anyone have any comments or input on this? Are there any security concerns > about this? i like the idea. :) would be nice if this could be turned on/off for ums and ukbd seperately. how about the kernel options: USB_STATS_UMS USB_STATS_UKBD cheers. alex > > --HPS -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 14:56:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BBA81065670; Mon, 27 Sep 2010 14:56:51 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF2E8FC15; Mon, 27 Sep 2010 14:56:51 +0000 (UTC) Received: by iwn34 with SMTP id 34so6096269iwn.13 for ; Mon, 27 Sep 2010 07:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.11.193 with SMTP id u1mr7295967ibu.113.1285599410337; Mon, 27 Sep 2010 07:56:50 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 27 Sep 2010 07:56:49 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> <4CA0743F.8050408@FreeBSD.org> Date: Mon, 27 Sep 2010 16:56:49 +0200 Message-ID: From: Olivier Smedts To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rene Ladan , Roman Divacky , Bartosz Stec , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 14:56:51 -0000 2010/9/27 Olivier Smedts : > 2010/9/27 Dimitry Andric : >> On 2010-09-27 09:32, Olivier Smedts wrote: >>> >>> 2010/9/23 Bartosz Stec: >> >> ... >>>> >>>> Assertion failed: (false&& =A0"Ran out of registers during register >>>> allocation!"), function assignRegOrStackSlotAtInterval, file >>>> >>>> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/Re= gAllocLinearScan.cpp, >>>> line 1196. >> >> ... >>> >>> Same error here with yesterday's -CURRENT, but not at the same time >>> (the running system was compiled using gcc) : >> >> As with Bartosz, could you please remove the CPU-specific flags from >> make.conf, and try again? > > Ok, I'll post the results later (it was the same with -DNDEBUG). Was not OK with : CPUTYPE=3Dathlon-xp CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer NO_CPU_CFLAGS=3Dyes COPTFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer NO_CPU_COPTFLAGS=3Dyes Is OK with : CPUTYPE=3Dathlon-xp CFLAGS=3D-O2 -pipe -fomit-frame-pointer NO_CPU_CFLAGS=3Dyes COPTFLAGS=3D-O2 -pipe -fomit-frame-pointer NO_CPU_COPTFLAGS=3Dyes I'll try with other -march (i686 and athlon) and post results. >> I guess there is something borked in LLVM's Athlon optimization, so it >> is probably better to not try to tickly those bugs for now. >> >> >> >>> # grep -vE '^#|^$' /etc/make.conf >>> KERNCONF=3DXPC >>> CPUTYPE=3Dathlon-xp >>> CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer >> >> Using CPUTYPE=3D and -march=3D seems a bit redundant. :) > > Not with NO_CPU_CFLAGS=3Dyes and NO_CPU_COPTFLAGS=3Dyes (if you want to > use -march=3Dnative, that's the best thing to do). > >> >>> clang -c -O2 -pipe -march=3Dnative -fomit-frame-pointer -DIN_GCC >>> -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED =A0-DHAVE_GTHR_DEFAULT >>> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include >>> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config >>> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. >>> -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 >>> -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 >>> -DElfW=3D__ElfN -o unwind-dw2.o >>> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c >>> Assertion failed: (!spillIs.empty()&& =A0"No spill intervals?"), >>> function assignRegOrStackSlotAtInterval, file >>> >>> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/Reg= AllocLinearScan.cpp, >>> line 1287. >> >> I haven't yet seen this one before. =A0If I can reproduce it, I will >> report it upstream, and see if they can come up with a fix. Anything I can provide to help with that ? > > Thanks ! > > -- > Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 = X > www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ > > =A0 "Il y a seulement 10 sortes de gens dans le monde : > =A0 ceux qui comprennent le binaire, > =A0 et ceux qui ne le comprennent pas." > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 15:33:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE7D9106564A for ; Mon, 27 Sep 2010 15:33:52 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 88B798FC0A for ; Mon, 27 Sep 2010 15:33:52 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P0FiB-000H76-9F for freebsd-current@freebsd.org; Mon, 27 Sep 2010 19:33:51 +0400 Date: Mon, 27 Sep 2010 19:35:55 +0400 From: Artemiev Igor To: freebsd-current@freebsd.org Message-ID: <20100927153555.GA9200@two.kliksys.ru> References: <20100926235313.GA4848@two.kliksys.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Subject: Re: netisr software flowid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 15:33:52 -0000 On Mon, Sep 27, 2010 at 09:52:21AM +0100, Robert Watson wrote: > One reason I haven't merged the earlier patch is that many high-performance > 10gbps (and even 1gbps) cards now support multiple input queues in hardware, > meaning that they have already done the work distribution by the time the > packets get to the OS. This makes the work distribution choice quite a bit > harder: has a packet already been adequately balanced, or is further > rebalancing required -- and of so, an equal distribution as selected in that > patch might not generate well-balanced CPU load. > > Using just the RSS hash to distribute work, and single-queue input, I am able > to get doubled end-host TCP performance with highly concurrent connections at > 10gbps, which is a useful result. I have high on my todo list to get the > patch you referenced into the mix as well and see how much the software > distrbiution hurts/helps... Thanks for explanation. > Since you've done some measurement, what was the throughput on that system > without the patch applied, and how many cores? The server has four cores. Topology: 0, 1, 2, 3 0, 1, 2, 3 Without patch i have only one netisr thread utilization with 100% cpu load and ~90% packets drop at max 80-90Kpps. The throughput oscillated from 2MB/s to 30MB/s. Cores 0,2,3 - netisr with cpu binding Core 1 - irq256 (bge0) bind via cpuset(1) P.S.: bge(4) patched for agressive interrupt moderation. Without this i have 11K+ int/sec and ~99% cpu usage only in the interrupt handling. From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 15:37:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A5AE106566B for ; Mon, 27 Sep 2010 15:37:07 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3519B8FC08 for ; Mon, 27 Sep 2010 15:37:06 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id o8RFQ1AW094341 for ; Mon, 27 Sep 2010 08:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1285601161; bh=Mw9Bvg9uiqTv8TXv7DOK2tqpXPRKFb1Gp5OtVxgRDug=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=G4YE5SK67fE9UuCUWXJoQiWuD8gRjyUpIRqVGvMY0ZDUBriRch138f5f+2HEbcik2 w/ehGztjZOm3Qc1Pk8yEOPoy+5+6bHIIbJ+rveIPKY643eBrjDHlTbABlZ95bXz73H iyUu0vD52NOvuLU8R3/7pzjcCkWu0dswvAABoIx0= From: Sean Bruno To: "current@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Sep 2010 08:26:01 -0700 Message-ID: <1285601161.7245.7.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: Subject: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 15:37:07 -0000 Does this look like an appropriate modification to libmemstat? Sean ==== //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ==== @@ -28,12 +28,13 @@ #ifndef _MEMSTAT_H_ #define _MEMSTAT_H_ +#include /* * Number of CPU slots in library-internal data structures. This should be * at least the value of MAXCPU from param.h. */ -#define MEMSTAT_MAXCPU 64 +#define MEMSTAT_MAXCPU MAXCPU /* defined in sys/${ARCH}/include/param.h */ /* * Amount of caller data to maintain for each caller data slot. Applications From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 15:49:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 222B810657F3 for ; Mon, 27 Sep 2010 15:49:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E65C08FC16 for ; Mon, 27 Sep 2010 15:49:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9034146B96; Mon, 27 Sep 2010 11:49:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0AEF48A04F; Mon, 27 Sep 2010 11:49:45 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 27 Sep 2010 11:20:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100925195334.GA58609@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20100925195334.GA58609@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009271120.36337.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 27 Sep 2010 11:49:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Anton Shterenlikht Subject: Re: amd64 panic: lock (sleep mutex) ral0 not locked @ /usr/src/sys/dev/ral/rt2560.c:2012 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 15:49:47 -0000 On Saturday, September 25, 2010 3:53:34 pm Anton Shterenlikht wrote: > On amd64 r213168 I've a ral(4) CardBus > wireless device of obscure origin. > It is identified as > > db> bt > Tracing pid 0 tid 100068 td 0xffffff0001b59440 > kbd_enter() at kbd_enter+0x3d > panic() at panic+0x17b > witness_unlock() at witness_unlock+0x297 > _mtx_unlock_flags() at _mtx_unlock_flags+0x7e > rt2560_ioctl() at rt2560_ioctl+0xbf > taskqueue_run() at taskqueue_run+0x63 > taskqueue_thread_loop() at taskqueue_thread_loop+0x54 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip 0, rsp=0xffffff80b2d41cf0, rbp = 0 --- This will likely fix your panic, but I think the card is likely to still not work: Index: rt2560.c =================================================================== --- rt2560.c (revision 212900) +++ rt2560.c (working copy) @@ -2667,8 +2667,7 @@ RAL_WRITE(sc, RT2560_CSR1, RT2560_HOST_READY); if (rt2560_bbp_init(sc) != 0) { - rt2560_stop(sc); - RAL_UNLOCK(sc); + rt2560_stop_locked(sc); return; } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 15:53:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6BD21065672 for ; Mon, 27 Sep 2010 15:53:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-17.mx.aerioconnect.net [216.240.47.77]) by mx1.freebsd.org (Postfix) with ESMTP id C9E158FC1A for ; Mon, 27 Sep 2010 15:53:06 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8RFr5Kc024993; Mon, 27 Sep 2010 08:53:05 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id D86BF2D6013; Mon, 27 Sep 2010 08:53:03 -0700 (PDT) Message-ID: <4CA0BE08.50408@freebsd.org> Date: Mon, 27 Sep 2010 08:53:44 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sbruno@freebsd.org References: <1285601161.7245.7.camel@home-yahoo> In-Reply-To: <1285601161.7245.7.camel@home-yahoo> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Sean Bruno , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 15:53:07 -0000 On 9/27/10 8:26 AM, Sean Bruno wrote: > Does this look like an appropriate modification to libmemstat? > > Sean > > > ==== //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ==== > @@ -28,12 +28,13 @@ > > #ifndef _MEMSTAT_H_ > #define _MEMSTAT_H_ > +#include > > /* > * Number of CPU slots in library-internal data structures. This > should be > * at least the value of MAXCPU from param.h. > */ > -#define MEMSTAT_MAXCPU 64 > +#define MEMSTAT_MAXCPU MAXCPU /* defined in > sys/${ARCH}/include/param.h */ > wouldn't it be better to do a sysctlbyname() and use the real value for the system? > /* > * Amount of caller data to maintain for each caller data slot. > Applications > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 16:00:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 116451065670 for ; Mon, 27 Sep 2010 16:00:50 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id C804B8FC13 for ; Mon, 27 Sep 2010 16:00:49 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o8RFfwCh010073; Mon, 27 Sep 2010 09:41:58 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <1285601161.7245.7.camel@home-yahoo> Date: Mon, 27 Sep 2010 09:41:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1285601161.7245.7.camel@home-yahoo> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 16:00:50 -0000 There's no reason not to include . I'm a little reluctant = to have it depend on the static MAXCPU definition, though. What happens = when you mix-and match userland and kernel and they no longer agree on = the definition of MAXCPU? I suggest creating a sysctl that exports the = kernel's definition of MAXCPU, and have libmemstat look for that first, = and fall back to using the static MAXCPU definition if the sysctl = fails/doesn't exit. Scott On Sep 27, 2010, at 9:26 AM, Sean Bruno wrote: > Does this look like an appropriate modification to libmemstat? >=20 > Sean >=20 >=20 > =3D=3D=3D=3D //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h =3D=3D=3D=3D > @@ -28,12 +28,13 @@ >=20 > #ifndef _MEMSTAT_H_ > #define _MEMSTAT_H_ > +#include >=20 > /* > * Number of CPU slots in library-internal data structures. This > should be > * at least the value of MAXCPU from param.h. > */ > -#define MEMSTAT_MAXCPU 64 > +#define MEMSTAT_MAXCPU MAXCPU /* defined in > sys/${ARCH}/include/param.h */ >=20 > /* > * Amount of caller data to maintain for each caller data slot. > Applications >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 16:04:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516F9106566B; Mon, 27 Sep 2010 16:04:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id ECD178FC14; Mon, 27 Sep 2010 16:04:04 +0000 (UTC) Received: by gwb15 with SMTP id 15so1951591gwb.13 for ; Mon, 27 Sep 2010 09:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/UDfWqZrCbMykP+i7UEvA+b8kew2fgbjQkIb0nH5OSo=; b=NVxrq6xnJcYZmKYOf9alZtgAoRdKb7rymSV6oQTGnER9dqI22rTjP4gxMY300OyTUM Q3HWltkhkDN9M/qh5kp1dic74sxVC2K9oCu1aC52A0zhjlGnXCAvHxgRsJA/W6pyn29M XlhWi+3NvdZ9cXVBPSJWQGzxK05Mchwl+AdP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UbEikpULfRDIZXr1URmtGPNtkVp5aXEjqKkoSj3y8vzQKPWUjTv69NkB8nuyIa522+ GAfUGarAmOd6+umcbFdEGmOwH9lt1RTseITPHJCHBfyB3JWRCbevJOvq9lpjDEVVkSQj axZkkYExoDmqehqteZ/91mkzSUZo238M7E5Sk= MIME-Version: 1.0 Received: by 10.151.47.10 with SMTP id z10mr7684003ybj.377.1285602059965; Mon, 27 Sep 2010 08:40:59 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.151.15.4 with HTTP; Mon, 27 Sep 2010 08:40:59 -0700 (PDT) In-Reply-To: <1285601161.7245.7.camel@home-yahoo> References: <1285601161.7245.7.camel@home-yahoo> Date: Mon, 27 Sep 2010 17:40:59 +0200 X-Google-Sender-Auth: ZUaG_uZWEnaOnauqbCk6eC4hzOI Message-ID: From: Attilio Rao To: sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 16:04:05 -0000 2010/9/27 Sean Bruno : > Does this look like an appropriate modification to libmemstat? > > Sean > > > =3D=3D=3D=3D //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h =3D=3D=3D=3D > @@ -28,12 +28,13 @@ > > =C2=A0#ifndef _MEMSTAT_H_ > =C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0_MEMSTAT_H_ > +#include > > =C2=A0/* > =C2=A0* Number of CPU slots in library-internal data structures. =C2=A0Th= is > should be > =C2=A0* at least the value of MAXCPU from param.h. > =C2=A0*/ > -#define =C2=A0 =C2=A0 =C2=A0 =C2=A0MEMSTAT_MAXCPU =C2=A064 > +#define =C2=A0 =C2=A0 =C2=A0 =C2=A0MEMSTAT_MAXCPU =C2=A0MAXCPU /* define= d in > sys/${ARCH}/include/param.h */ > > =C2=A0/* > =C2=A0* Amount of caller data to maintain for each caller data slot. > Applications I would not include sys/param and would axe out the comment. Just make sure anything compiles with these modifies eventually. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 16:25:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60774106564A for ; Mon, 27 Sep 2010 16:25:55 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id DDE0B8FC1F for ; Mon, 27 Sep 2010 16:25:54 +0000 (UTC) Received: by fxm9 with SMTP id 9so3762616fxm.13 for ; Mon, 27 Sep 2010 09:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=J8TVZ4r6l/PNj66vONBWzB/1oA5KFC86nuyzNbMnkTk=; b=EToWl6rBx+tg2rT3Z0rfEvESbGndbMTIE+/9RT1Xb2YFDHs6zA7wVcQqglvFYmxAwv NIUmO/5txEGyLt1TO71JhGzdgPGXWFw3tj2AMuOZ9ZefNTBo6ZDUfOWhhTk1kS+ra3tU ACpID1LOYkfNx87WIODdi90DaoasHrETpMzk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=IdorcKA7TCGRuTcGEhjmX4RJZUbFY0W32HcgiDpvITAGjxXT+ymrZvIpfSW6TjxTcj OeLobk5IDF2BnXwMMkwDV2j2O+v2snNxcBM6lp4+JfzSH/r9qDeENMGc0iXAOYVskRXV WcsiaSRq3ynaYDo6Iia/21fas7jaacWyg0yGs= Received: by 10.223.112.199 with SMTP id x7mr7811357fap.101.1285604753704; Mon, 27 Sep 2010 09:25:53 -0700 (PDT) Received: from centel.dataix.local ([99.181.158.110]) by mx.google.com with ESMTPS id a7sm2517446faa.45.2010.09.27.09.25.52 (version=SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 09:25:52 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CA0C58E.5000300@DataIX.net> Date: Mon, 27 Sep 2010 12:25:50 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100917 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Buganini References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Parallelized scripting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 16:25:55 -0000 On 09/26/2010 21:51, Buganini wrote: > Hi, I just wrote a rough C program that may help to do parallelized > scripting, for example, parallelized rc.d scripts. > > http://github.com/buganini/brackets > > in this way it is easy to use, no need to escape argv for multiple times. > > > any comments are welcomed. Have any real test cases against the base system where this has an advantage? What purpose does this serve in our current & future environments? Would this be better suited as a port or as a part of another larger toolchain? Has this been done already and re-incarnated here? Also style(9) is in direct need here. -- jhell,v From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 16:31:32 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A28A4106564A for ; Mon, 27 Sep 2010 16:31:32 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 86D6F8FC17 for ; Mon, 27 Sep 2010 16:31:32 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o8RGULXF060469; Mon, 27 Sep 2010 09:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1285605021; bh=nPO5zE3xNRVPd8+AtUPwz3q3YkUcA9DV4LJ4pzfCNGI=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=eeV41qr9AwbLsVS4V7OHuFLOQdxWYcCjdk6/bo93BwWFp4PRa9jM+P0Su1zacncw+ bFhuHMnC7Q5laxE/Zet7PaxWxkAJ0v93GMaz+Su0GQLJRRbWXHLDSRVvEy3e1z5TgT v2U0CapQ5444OpLuWjhUPvh+CGKeT0B9B9y+el3I= From: Sean Bruno To: Attilio Rao In-Reply-To: References: <1285601161.7245.7.camel@home-yahoo> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Sep 2010 09:30:20 -0700 Message-ID: <1285605020.7245.18.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "sbruno@freebsd.org" , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 16:31:32 -0000 > > I would not include sys/param and would axe out the comment. > > Just make sure anything compiles with these modifies eventually. > > Thanks, > Attilio > > Ah, yes. The include is completely pointless. The value can be assigned without it. Sean === //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ==== @@ -33,7 +33,7 @@ * Number of CPU slots in library-internal data structures. This should be * at least the value of MAXCPU from param.h. */ -#define MEMSTAT_MAXCPU 64 +#define MEMSTAT_MAXCPU MAXCPU /* * Amount of caller data to maintain for each caller data slot. Applications From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 16:22:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B9D106566B for ; Mon, 27 Sep 2010 16:22:26 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 59AAA8FC2C for ; Mon, 27 Sep 2010 16:22:26 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id o8RGLurE015768; Mon, 27 Sep 2010 09:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1285604516; bh=p82NdZY5QhZNy2i3WV0HpndXVf32E8M5JGPYxD3Bnl0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=Qzcrdt3WE0JJ7GfiTuytxZJ9fDLK8jM+i7nMIKFSn5pNXPLzgipPonvZk+arOML5v l1w6r5DNYUonG2FD729AjXxQ+GqpkEnDyLba3i22HHfPMR2TB3EGijiCuH/IpFnskX UrepZ5Dit4rc4kajCGxgrU3b5ycOFk8/1oH9o+X4= From: Sean Bruno To: Julian Elischer In-Reply-To: <4CA0BE08.50408@freebsd.org> References: <1285601161.7245.7.camel@home-yahoo> <4CA0BE08.50408@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Sep 2010 09:21:56 -0700 Message-ID: <1285604516.7245.16.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Sep 2010 17:36:29 +0000 Cc: "sbruno@freebsd.org" , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 16:22:26 -0000 On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote: > On 9/27/10 8:26 AM, Sean Bruno wrote: > > Does this look like an appropriate modification to libmemstat? > > > > Sean > > > > > > ==== //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 > > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ==== > > @@ -28,12 +28,13 @@ > > > > #ifndef _MEMSTAT_H_ > > #define _MEMSTAT_H_ > > +#include > > > > /* > > * Number of CPU slots in library-internal data structures. This > > should be > > * at least the value of MAXCPU from param.h. > > */ > > -#define MEMSTAT_MAXCPU 64 > > +#define MEMSTAT_MAXCPU MAXCPU /* defined in > > sys/${ARCH}/include/param.h */ > > > > > wouldn't it be better to do a sysctlbyname() and use the real value > for the system? > That was my initial thought (as prodded by scottl and peter). If it is made dynamic, could this be opening a race condition where the call to sysctlbyname() returns a count of CPUS that is in turn changed by the offlining of a CPU? Or am I thinking to much about this? Sean From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 17:41:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BFE3106566C; Mon, 27 Sep 2010 17:41:11 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1E08FC15; Mon, 27 Sep 2010 17:41:09 +0000 (UTC) Received: by gwb15 with SMTP id 15so1978133gwb.13 for ; Mon, 27 Sep 2010 10:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=dPP8ZJowvhZZIOOs0zoq7nOpOHSfqbXwem3sJRsJQ00=; b=u51KYm3N9w/YVLoeZ5Ent3xZ4vGBcUtEAficeEhDv67OkKZzlLWeJ8zykobepe1Uxs zC511fTt6R79XNi5mXXzSb/y1QGgZX0h1an+AE7mMpkYChwG4hrCyT98V3YS84yylEVl 1gGepjDjnjLkppeqMZ8KR4KUJjpe5fGH55JtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wnM+yXVCTWaE1peO0lmK4cIekqW4uKizT9nrD/pnc5WuCjPFdbB7+xouDo7Smrib7V +2tcgMwVErckP57vKs1zpwf5rOCen9xQ+pTOJI4uVRjCf0lwXlB0WXvPm4XnoVjjYusJ ac3X4lJwxcuYa9+UhXy4vHdExTTP+uyTSbxR8= MIME-Version: 1.0 Received: by 10.150.50.15 with SMTP id x15mr9624200ybx.35.1285609269332; Mon, 27 Sep 2010 10:41:09 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.151.15.4 with HTTP; Mon, 27 Sep 2010 10:41:09 -0700 (PDT) In-Reply-To: <1285604516.7245.16.camel@home-yahoo> References: <1285601161.7245.7.camel@home-yahoo> <4CA0BE08.50408@freebsd.org> <1285604516.7245.16.camel@home-yahoo> Date: Mon, 27 Sep 2010 19:41:09 +0200 X-Google-Sender-Auth: wR2rb5EexVQKygpd7ll0TzBKrqc Message-ID: From: Attilio Rao To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sbruno@freebsd.org" , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 17:41:11 -0000 2010/9/27 Sean Bruno : > On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote: >> On 9/27/10 8:26 AM, Sean Bruno wrote: >> > Does this look like an appropriate modification to libmemstat? >> > >> > Sean >> > >> > >> > =3D=3D=3D=3D //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 >> > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h =3D=3D=3D=3D >> > @@ -28,12 +28,13 @@ >> > >> > =C2=A0 #ifndef _MEMSTAT_H_ >> > =C2=A0 #define =C2=A0 =C2=A0 =C2=A0 =C2=A0_MEMSTAT_H_ >> > +#include >> > >> > =C2=A0 /* >> > =C2=A0 =C2=A0* Number of CPU slots in library-internal data structures= . =C2=A0This >> > should be >> > =C2=A0 =C2=A0* at least the value of MAXCPU from param.h. >> > =C2=A0 =C2=A0*/ >> > -#define =C2=A0 =C2=A0 =C2=A0 =C2=A0MEMSTAT_MAXCPU =C2=A064 >> > +#define =C2=A0 =C2=A0 =C2=A0 =C2=A0MEMSTAT_MAXCPU =C2=A0MAXCPU /* def= ined in >> > sys/${ARCH}/include/param.h */ >> > >> >> >> wouldn't it be better to do a sysctlbyname() and use the real value >> for the system? >> > > That was my initial thought (as prodded by scottl and peter). > > If it is made dynamic, could this be opening a race condition where the > call to sysctlbyname() returns a count of CPUS that is in turn changed > by the offlining of a CPU? =C2=A0Or am I thinking to much about this? We still can't support CPU hotplugging so the easy answer is 'don't bother about variadic CPUs number'. I don't really know what libmemstat is willing to do with that macro (and I don't have time to look at it now) maybe you could shade a light about what's its usage? Does it really needs to know MAXCPUS or just wants a large enough value to fill anything? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 17:54:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049311065743; Mon, 27 Sep 2010 17:54:21 +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 2251A8FC0A; Mon, 27 Sep 2010 17:54:18 +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 UAA14586; Mon, 27 Sep 2010 20:54:17 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CA0DA49.2090006@freebsd.org> Date: Mon, 27 Sep 2010 20:54:17 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox Subject: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 17:54:21 -0000 It seems that minidump on amd64 is always dumping at least about 1GB of data regardless of actual memory size and usage and thus can be even larger than regular dump. Specifically, I suspect the following code: for (va = VM_MIN_KERNEL_ADDRESS; va < MAX(KERNBASE + NKPT * NBPDR, kernel_vm_end); va += NBPDR) { i = (va >> PDPSHIFT) & ((1ul << NPDPEPGSHIFT) - 1); /* * We always write a page, even if it is zero. Each * page written corresponds to 2MB of space */ ptesize += PAGE_SIZE; It seems that difference between KERNBASE and VM_MIN_KERNEL_ADDRESS is already ~500G. Which means 500G divided by 2M equals 250K iterations/pages. Which is 1GB of data. Looks like this came from amd64 KVA expansion. And it seems a little bit wasteful? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 18:39:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F348B106566B for ; Mon, 27 Sep 2010 18:39:14 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B82E38FC0C for ; Mon, 27 Sep 2010 18:39:14 +0000 (UTC) Received: by iwn34 with SMTP id 34so6213095iwn.13 for ; Mon, 27 Sep 2010 11:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=EfBZ0ZPEhOgulxrqjLBo4yUBy3O0r2YZSghnWI8BLZQ=; b=Wj+Tlu87DBb/yxshPa08QCAFh0mlhSEkGZQf42Aynlktn08QPHnro37Qj1ZqYiXEo9 cfYoOcxGVoBetJK2jy7Eym8ikpY38/26EorqH6nveGnVCXNS74YZznSi4K48yeSyAYK0 ZXSFhDDwwq3Mr6kLPOi8CXbQj+DF5ZrCZbS/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YaONYC0Zo5RbYiapMBorYLCTew7DnP3qXUygnvGeF1O454ugELqE4AuX2HBN+boo8r y1fzGvVtJzUAHH/TdjsCpPSA5ucfqJk6ReKiXhdTRfuVp7qLEYi9zaiXRp7OyM46ZW7A 3BE0Ytz+coiHBdeLDvYenuZc+/IJACYYjBX4M= MIME-Version: 1.0 Received: by 10.231.35.202 with SMTP id q10mr9328734ibd.138.1285611424583; Mon, 27 Sep 2010 11:17:04 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.187.71 with HTTP; Mon, 27 Sep 2010 11:17:04 -0700 (PDT) In-Reply-To: <1285604516.7245.16.camel@home-yahoo> References: <1285601161.7245.7.camel@home-yahoo> <4CA0BE08.50408@freebsd.org> <1285604516.7245.16.camel@home-yahoo> Date: Mon, 27 Sep 2010 11:17:04 -0700 X-Google-Sender-Auth: bUJvbiFjyPu_ji2d6UeA9NdFtsA Message-ID: From: mdf@FreeBSD.org To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 18:39:15 -0000 On Mon, Sep 27, 2010 at 9:21 AM, Sean Bruno wrote: > On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote: >> On 9/27/10 8:26 AM, Sean Bruno wrote: >> > Does this look like an appropriate modification to libmemstat? >> > >> > Sean >> > >> > >> > =3D=3D=3D=3D //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 >> > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h =3D=3D=3D=3D >> > @@ -28,12 +28,13 @@ >> > >> > =A0 #ifndef _MEMSTAT_H_ >> > =A0 #define =A0 =A0 =A0 =A0_MEMSTAT_H_ >> > +#include >> > >> > =A0 /* >> > =A0 =A0* Number of CPU slots in library-internal data structures. =A0T= his >> > should be >> > =A0 =A0* at least the value of MAXCPU from param.h. >> > =A0 =A0*/ >> > -#define =A0 =A0 =A0 =A0MEMSTAT_MAXCPU =A064 >> > +#define =A0 =A0 =A0 =A0MEMSTAT_MAXCPU =A0MAXCPU /* defined in >> > sys/${ARCH}/include/param.h */ >> > >> >> >> wouldn't it be better to do a sysctlbyname() and use the real value >> for the system? >> > > That was my initial thought (as prodded by scottl and peter). > > If it is made dynamic, could this be opening a race condition where the > call to sysctlbyname() returns a count of CPUS that is in turn changed > by the offlining of a CPU? =A0Or am I thinking to much about this? The maximum number of CPUs supported by a running instance will not change. Only, potentially, the current number of CPUs. So a sysctl to fetch the kernel's compiled-in MAXCPU is safe. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 19:14:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C09FE106566B for ; Mon, 27 Sep 2010 19:14:24 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9E28FC13 for ; Mon, 27 Sep 2010 19:14:24 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id B69C613DF42; Mon, 27 Sep 2010 22:58:09 +0400 (MSD) Date: Mon, 27 Sep 2010 22:58:07 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1876849853.20100927225807@serebryakov.spb.ru> To: Buganini In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Parallelized scripting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 19:14:24 -0000 Hello, Buganini. You wrote 27 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2010 =D0=B3.,= 05:51:11: > Hi, I just wrote a rough C program that may help to do parallelized > scripting, for example, parallelized rc.d scripts. > http://github.com/buganini/brackets > in this way it is easy to use, no need to escape argv for multiple times. > any comments are welcomed. Idea is interesting, but code... My, oh my, why do you use fixed-length arrays of arrays of pointers, on stack in 2010?! 4096 looks like very big number, but it is still finite, and could be exploitable. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 20:54:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE8C1065670; Mon, 27 Sep 2010 20:54:16 +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 ED8198FC0A; Mon, 27 Sep 2010 20:54:15 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7BC5046B60; Mon, 27 Sep 2010 16:54:15 -0400 (EDT) Date: Mon, 27 Sep 2010 21:54:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: Message-ID: References: <1285601161.7245.7.camel@home-yahoo> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: sbruno@freebsd.org, "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 20:54:16 -0000 On Mon, 27 Sep 2010, Scott Long wrote: > There's no reason not to include . I'm a little reluctant to > have it depend on the static MAXCPU definition, though. What happens when > you mix-and match userland and kernel and they no longer agree on the > definition of MAXCPU? I suggest creating a sysctl that exports the kernel's > definition of MAXCPU, and have libmemstat look for that first, and fall back > to using the static MAXCPU definition if the sysctl fails/doesn't exit. I suppose, in a very worst case scenario, we can read the source code for libmemstat and see what it does. Robert > > Scott > > > > On Sep 27, 2010, at 9:26 AM, Sean Bruno wrote: > >> Does this look like an appropriate modification to libmemstat? >> >> Sean >> >> >> ==== //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 >> - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ==== >> @@ -28,12 +28,13 @@ >> >> #ifndef _MEMSTAT_H_ >> #define _MEMSTAT_H_ >> +#include >> >> /* >> * Number of CPU slots in library-internal data structures. This >> should be >> * at least the value of MAXCPU from param.h. >> */ >> -#define MEMSTAT_MAXCPU 64 >> +#define MEMSTAT_MAXCPU MAXCPU /* defined in >> sys/${ARCH}/include/param.h */ >> >> /* >> * Amount of caller data to maintain for each caller data slot. >> Applications >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 21:21:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A4C106566C; Mon, 27 Sep 2010 21:21:31 +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 C00188FC14; Mon, 27 Sep 2010 21:21:31 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6A95846B06; Mon, 27 Sep 2010 17:21:31 -0400 (EDT) Date: Mon, 27 Sep 2010 22:21:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sean Bruno In-Reply-To: <1285604516.7245.16.camel@home-yahoo> Message-ID: References: <1285601161.7245.7.camel@home-yahoo> <4CA0BE08.50408@freebsd.org> <1285604516.7245.16.camel@home-yahoo> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "sbruno@freebsd.org" , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 21:21:32 -0000 On Mon, 27 Sep 2010, Sean Bruno wrote: >> wouldn't it be better to do a sysctlbyname() and use the real value for the >> system? libmemstat contains some useful sample code showing how this might be done. > That was my initial thought (as prodded by scottl and peter). > > If it is made dynamic, could this be opening a race condition where the call > to sysctlbyname() returns a count of CPUS that is in turn changed by the > offlining of a CPU? Or am I thinking to much about this? Yes, you are. MAXCPU is a compile-time constant for kernel builds, so (at least a the world is today), that can't happen. I think there's a reasonable argument that MEMSTAT_MAXCPU should be phased out and all internal structures in libmemstat should be dynamically sized. However, core counts aren't growing that fast, and it's quite a bit of work, and probably not worth it just yet. I'm somewhat averse to using MAXCPU in libmemstat, however, because MAXCPU is actually not a constant in the general case: FreeBSD/i386, for example, regularly uses two different values: 1 for !SMP kernels, and 32 for SMP kernels. That's why libmemstat encodes its own value, for better or worse. A reasonable alternative would be to replace 32 with MAXCPU * 2, or if we're feeling particularly optimistic, MAXCPU * 4. Or just another big number, like 256. Robert From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 21:09:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4410106566C; Mon, 27 Sep 2010 21:09:22 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9338FC16; Mon, 27 Sep 2010 21:09:22 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o8RL8pOn081696; Mon, 27 Sep 2010 14:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1285621731; bh=SvRfQxBqrdO0/mkyAoiPp+Cfu4fzgQfD0UBgW97Wc9k=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=jl6Q/W9E7tcu2Z/sVhug+dARTmQDg5ycsyZT4P+D1mbRRKhSNTTs0gbxGix6OHRIB m7srJkeQ6B/CnION2X1IeYy8dBQK/He9ayDd+nwPxvc/VLdjtC8RBJCbOqX4TDd2KA 7XKT0oipFXOqDWOLifk27CbdT+iZQci1N2W8qRbw= From: Sean Bruno To: Attilio Rao In-Reply-To: References: <1285601161.7245.7.camel@home-yahoo> <4CA0BE08.50408@freebsd.org> <1285604516.7245.16.camel@home-yahoo> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Sep 2010 14:08:51 -0700 Message-ID: <1285621731.7245.167.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Sep 2010 21:25:49 +0000 Cc: "sbruno@freebsd.org" , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 21:09:22 -0000 On Mon, 2010-09-27 at 12:41 -0500, Attilio Rao wrote: > 2010/9/27 Sean Bruno : > > On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote: > >> On 9/27/10 8:26 AM, Sean Bruno wrote: > >> > Does this look like an appropriate modification to libmemstat? > >> > > >> > Sean > >> > > >> > > >> > ==== //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 > >> > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ==== > >> > @@ -28,12 +28,13 @@ > >> > > >> > #ifndef _MEMSTAT_H_ > >> > #define _MEMSTAT_H_ > >> > +#include > >> > > >> > /* > >> > * Number of CPU slots in library-internal data structures. This > >> > should be > >> > * at least the value of MAXCPU from param.h. > >> > */ > >> > -#define MEMSTAT_MAXCPU 64 > >> > +#define MEMSTAT_MAXCPU MAXCPU /* defined in > >> > sys/${ARCH}/include/param.h */ > >> > > >> > >> > >> wouldn't it be better to do a sysctlbyname() and use the real value > >> for the system? > >> > > > > That was my initial thought (as prodded by scottl and peter). > > > > If it is made dynamic, could this be opening a race condition where the > > call to sysctlbyname() returns a count of CPUS that is in turn changed > > by the offlining of a CPU? Or am I thinking to much about this? > > We still can't support CPU hotplugging so the easy answer is 'don't > bother about variadic CPUs number'. > I don't really know what libmemstat is willing to do with that macro > (and I don't have time to look at it now) maybe you could shade a > light about what's its usage? Does it really needs to know MAXCPUS or > just wants a large enough value to fill anything? > > Thanks, > Attilio > > Give or take, MEMSTAT_MAXCPU is used to allocate an array of per cpu stats (see lib/libmemstat/memstat_internal.h::struct memory_type). If the number of probed CPUs is more that this value, the library returns an error. Sean From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 21:39:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E7181065673; Mon, 27 Sep 2010 21:39:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2B58FC08; Mon, 27 Sep 2010 21:39:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E249546B0D; Mon, 27 Sep 2010 17:39:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E39A58A03C; Mon, 27 Sep 2010 17:39:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 27 Sep 2010 17:38:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009271738.19497.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 27 Sep 2010 17:39:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "sbruno@freebsd.org" , Robert Watson , Sean Bruno , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 21:39:26 -0000 On Monday, September 27, 2010 5:21:31 pm Robert Watson wrote: > > On Mon, 27 Sep 2010, Sean Bruno wrote: > > >> wouldn't it be better to do a sysctlbyname() and use the real value for the > >> system? > > libmemstat contains some useful sample code showing how this might be done. > > > That was my initial thought (as prodded by scottl and peter). > > > > If it is made dynamic, could this be opening a race condition where the call > > to sysctlbyname() returns a count of CPUS that is in turn changed by the > > offlining of a CPU? Or am I thinking to much about this? > > Yes, you are. MAXCPU is a compile-time constant for kernel builds, so (at > least a the world is today), that can't happen. > > I think there's a reasonable argument that MEMSTAT_MAXCPU should be phased out > and all internal structures in libmemstat should be dynamically sized. > However, core counts aren't growing that fast, and it's quite a bit of work, > and probably not worth it just yet. > > I'm somewhat averse to using MAXCPU in libmemstat, however, because MAXCPU is > actually not a constant in the general case: FreeBSD/i386, for example, > regularly uses two different values: 1 for !SMP kernels, and 32 for SMP > kernels. That's why libmemstat encodes its own value, for better or worse. > > A reasonable alternative would be to replace 32 with MAXCPU * 2, or if we're > feeling particularly optimistic, MAXCPU * 4. Or just another big number, like > 256. A prerequisite for this idea though is that MAXCPU needs to be fixed to export the SMP value to userland rather than the UP value. For example, this code in amd64/include/param.h: #if defined(SMP) || defined(KLD_MODULE) #define MAXCPU 32 #else #define MAXCPU 1 #endif would need to change so that !_KERNEL is in the conditional. I do think we should avoid using MAXCPU in userland as much as possible and use the existing sysctl for mp_maxid instead to dynamically allocate arrays. Also, I think we should either fix MAXCPU to export the SMP value to userland, or hide it from userland completely. Exporting the UP value is Just Wrong (tm). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 21:39:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E7181065673; Mon, 27 Sep 2010 21:39:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2B58FC08; Mon, 27 Sep 2010 21:39:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E249546B0D; Mon, 27 Sep 2010 17:39:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E39A58A03C; Mon, 27 Sep 2010 17:39:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 27 Sep 2010 17:38:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009271738.19497.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 27 Sep 2010 17:39:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "sbruno@freebsd.org" , Robert Watson , Sean Bruno , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 21:39:26 -0000 On Monday, September 27, 2010 5:21:31 pm Robert Watson wrote: > > On Mon, 27 Sep 2010, Sean Bruno wrote: > > >> wouldn't it be better to do a sysctlbyname() and use the real value for the > >> system? > > libmemstat contains some useful sample code showing how this might be done. > > > That was my initial thought (as prodded by scottl and peter). > > > > If it is made dynamic, could this be opening a race condition where the call > > to sysctlbyname() returns a count of CPUS that is in turn changed by the > > offlining of a CPU? Or am I thinking to much about this? > > Yes, you are. MAXCPU is a compile-time constant for kernel builds, so (at > least a the world is today), that can't happen. > > I think there's a reasonable argument that MEMSTAT_MAXCPU should be phased out > and all internal structures in libmemstat should be dynamically sized. > However, core counts aren't growing that fast, and it's quite a bit of work, > and probably not worth it just yet. > > I'm somewhat averse to using MAXCPU in libmemstat, however, because MAXCPU is > actually not a constant in the general case: FreeBSD/i386, for example, > regularly uses two different values: 1 for !SMP kernels, and 32 for SMP > kernels. That's why libmemstat encodes its own value, for better or worse. > > A reasonable alternative would be to replace 32 with MAXCPU * 2, or if we're > feeling particularly optimistic, MAXCPU * 4. Or just another big number, like > 256. A prerequisite for this idea though is that MAXCPU needs to be fixed to export the SMP value to userland rather than the UP value. For example, this code in amd64/include/param.h: #if defined(SMP) || defined(KLD_MODULE) #define MAXCPU 32 #else #define MAXCPU 1 #endif would need to change so that !_KERNEL is in the conditional. I do think we should avoid using MAXCPU in userland as much as possible and use the existing sysctl for mp_maxid instead to dynamically allocate arrays. Also, I think we should either fix MAXCPU to export the SMP value to userland, or hide it from userland completely. Exporting the UP value is Just Wrong (tm). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 21:42:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B64310656AB; Mon, 27 Sep 2010 21:42:27 +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 01CD18FC20; Mon, 27 Sep 2010 21:42:27 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id AB32346B0D; Mon, 27 Sep 2010 17:42:26 -0400 (EDT) Date: Mon, 27 Sep 2010 22:42:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <201009271738.19497.jhb@freebsd.org> Message-ID: References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <201009271738.19497.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "sbruno@freebsd.org" , freebsd-current@freebsd.org, Sean Bruno , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 21:42:27 -0000 On Mon, 27 Sep 2010, John Baldwin wrote: > Also, I think we should either fix MAXCPU to export the SMP value to > userland, or hide it from userland completely. Exporting the UP value is > Just Wrong (tm). Well, it's useful in the sense that it tells you what the maximum number of CPUs a kernel can support is, which is helpful, especially if you're futzing with MAXCPU as a kernel option :-). But, more generally, many things that use MAXCPU should probably use either mp_maxid or DPCPU. Not everything, but most things. Robert From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 21:42:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B64310656AB; Mon, 27 Sep 2010 21:42:27 +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 01CD18FC20; Mon, 27 Sep 2010 21:42:27 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id AB32346B0D; Mon, 27 Sep 2010 17:42:26 -0400 (EDT) Date: Mon, 27 Sep 2010 22:42:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <201009271738.19497.jhb@freebsd.org> Message-ID: References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <201009271738.19497.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "sbruno@freebsd.org" , freebsd-current@freebsd.org, Sean Bruno , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 21:42:27 -0000 On Mon, 27 Sep 2010, John Baldwin wrote: > Also, I think we should either fix MAXCPU to export the SMP value to > userland, or hide it from userland completely. Exporting the UP value is > Just Wrong (tm). Well, it's useful in the sense that it tells you what the maximum number of CPUs a kernel can support is, which is helpful, especially if you're futzing with MAXCPU as a kernel option :-). But, more generally, many things that use MAXCPU should probably use either mp_maxid or DPCPU. Not everything, but most things. Robert From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 23:56:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A207B106564A; Mon, 27 Sep 2010 23:56:11 +0000 (UTC) (envelope-from jdneal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1F68FC08; Mon, 27 Sep 2010 23:56:10 +0000 (UTC) Received: by iwn34 with SMTP id 34so6581632iwn.13 for ; Mon, 27 Sep 2010 16:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mokEJ7QIdrokolAymhMWsFXz+8eBW5A46t5OqobPrSQ=; b=Ai8sxEpLRH5T+LO3dCKGAOPp8b+T+vZAExYwtOONYH/ZxKQK/byW3t84yoQibPiCsi wtQrNE4YWs48ynx99E4TMUoHkcYiktp8+WHj9o0nXtTfG31Qd4dUc21UX8iYY6ysdTXH ohRAaNOoHtLfuoYmBb8JKkKkxpXzUVlSANylk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=C4n/axR3y5Ki6DECUhJYjT4LCbnJmeLeHhq+TQRQWEPQOyKMXaMVC5eXT4qoXnBf5B yheG214ROmK4fjBmvrEGChHZ+0DiSh6PQI4p19eresJgFhY1pn48jVEDdjK2Bp8RFGU/ WodXkQzZEGi3L/tJ7BrWF5JEaIhPublGjykOo= MIME-Version: 1.0 Received: by 10.231.16.75 with SMTP id n11mr8101495iba.49.1285630354653; Mon, 27 Sep 2010 16:32:34 -0700 (PDT) Received: by 10.231.166.21 with HTTP; Mon, 27 Sep 2010 16:32:34 -0700 (PDT) In-Reply-To: References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <201009271738.19497.jhb@freebsd.org> Date: Mon, 27 Sep 2010 16:32:34 -0700 Message-ID: From: Joshua Neal To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sbruno@freebsd.org" , freebsd-current@freebsd.org, Sean Bruno , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 23:56:11 -0000 I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already asking the kernel for the max number and throwing an error if it doesn't agree: if (sysctlbyname("kern.smp.maxcpus", &maxcpus, &size, NULL, 0) < 0) = { [...] if (maxcpus > MEMSTAT_MAXCPU) { list->mtl_error =3D MEMSTAT_ERROR_TOOMANYCPUS; return (-1); } I was thinking a more future-proof fix would be to get rid of the static allocations and allocate the library's internal structures based on the value of kern.smp.maxcpus. - Joshua On Mon, Sep 27, 2010 at 2:42 PM, Robert Watson wrote: > > On Mon, 27 Sep 2010, John Baldwin wrote: > >> Also, I think we should either fix MAXCPU to export the SMP value to >> userland, or hide it from userland completely. =A0Exporting the UP value= is >> Just Wrong (tm). > > Well, it's useful in the sense that it tells you what the maximum number = of > CPUs a kernel can support is, which is helpful, especially if you're futz= ing > with MAXCPU as a kernel option :-). > > But, more generally, many things that use MAXCPU should probably use eith= er > mp_maxid or DPCPU. =A0Not everything, but most things. > > Robert > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 23:56:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A207B106564A; Mon, 27 Sep 2010 23:56:11 +0000 (UTC) (envelope-from jdneal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1F68FC08; Mon, 27 Sep 2010 23:56:10 +0000 (UTC) Received: by iwn34 with SMTP id 34so6581632iwn.13 for ; Mon, 27 Sep 2010 16:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mokEJ7QIdrokolAymhMWsFXz+8eBW5A46t5OqobPrSQ=; b=Ai8sxEpLRH5T+LO3dCKGAOPp8b+T+vZAExYwtOONYH/ZxKQK/byW3t84yoQibPiCsi wtQrNE4YWs48ynx99E4TMUoHkcYiktp8+WHj9o0nXtTfG31Qd4dUc21UX8iYY6ysdTXH ohRAaNOoHtLfuoYmBb8JKkKkxpXzUVlSANylk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=C4n/axR3y5Ki6DECUhJYjT4LCbnJmeLeHhq+TQRQWEPQOyKMXaMVC5eXT4qoXnBf5B yheG214ROmK4fjBmvrEGChHZ+0DiSh6PQI4p19eresJgFhY1pn48jVEDdjK2Bp8RFGU/ WodXkQzZEGi3L/tJ7BrWF5JEaIhPublGjykOo= MIME-Version: 1.0 Received: by 10.231.16.75 with SMTP id n11mr8101495iba.49.1285630354653; Mon, 27 Sep 2010 16:32:34 -0700 (PDT) Received: by 10.231.166.21 with HTTP; Mon, 27 Sep 2010 16:32:34 -0700 (PDT) In-Reply-To: References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <201009271738.19497.jhb@freebsd.org> Date: Mon, 27 Sep 2010 16:32:34 -0700 Message-ID: From: Joshua Neal To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sbruno@freebsd.org" , freebsd-current@freebsd.org, Sean Bruno , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 23:56:11 -0000 I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already asking the kernel for the max number and throwing an error if it doesn't agree: if (sysctlbyname("kern.smp.maxcpus", &maxcpus, &size, NULL, 0) < 0) = { [...] if (maxcpus > MEMSTAT_MAXCPU) { list->mtl_error =3D MEMSTAT_ERROR_TOOMANYCPUS; return (-1); } I was thinking a more future-proof fix would be to get rid of the static allocations and allocate the library's internal structures based on the value of kern.smp.maxcpus. - Joshua On Mon, Sep 27, 2010 at 2:42 PM, Robert Watson wrote: > > On Mon, 27 Sep 2010, John Baldwin wrote: > >> Also, I think we should either fix MAXCPU to export the SMP value to >> userland, or hide it from userland completely. =A0Exporting the UP value= is >> Just Wrong (tm). > > Well, it's useful in the sense that it tells you what the maximum number = of > CPUs a kernel can support is, which is helpful, especially if you're futz= ing > with MAXCPU as a kernel option :-). > > But, more generally, many things that use MAXCPU should probably use eith= er > mp_maxid or DPCPU. =A0Not everything, but most things. > > Robert > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 07:27:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EFEC106566B for ; Tue, 28 Sep 2010 07:27:58 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 9693A8FC1A for ; Tue, 28 Sep 2010 07:27:57 +0000 (UTC) Received: from [78.35.64.56] (helo=r500.local) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1P0UbR-0007uO-37 for freebsd-current@freebsd.org; Tue, 28 Sep 2010 09:27:56 +0200 Date: Tue, 28 Sep 2010 09:27:48 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20100928092748.58b70eb5@r500.local> In-Reply-To: <20100918155100.5b74cdb2@r500.local> References: <20100918155100.5b74cdb2@r500.local> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/g5+qD93HV8TdBnCey=bOlMD"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: Re: geli boot issues with recent kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 07:27:58 -0000 --Sig_/g5+qD93HV8TdBnCey=bOlMD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > My kernel and / are on ada0s1a (UFS) while the rest of the system > is on a ZFS pool on ada0s1d.eli, attached on boot. >=20 > Since a few days ago, booting no longer works reliably for me. > Every now and then the system hangs at the time when I'd normaly > provide the passphrase. >=20 > The last times this happened I was in a hurry, so I'm not entirely > sure if the prompt for the passphrase is even shown (on my system > it's always buried in USB messages anyway). The geli passphrase prompt isn't shown at all: http://www.fabiankeil.de/tmp/freebsd-9.0-geli-boot-problem-800x561.jpg Verbose dmesg for a successful boot: http://www.fabiankeil.de/tmp/freebsd-dmesg-2010-09-27.txt > Sometimes keyboard input is ignored completely, sometimes I can > still use shift lock or scroll through the kernel messages. I now seem to always be able to scroll through the kernel messages so maybe I misremembered. > When this happened the first time, rebooting the system solved > the problem. By "rebooting" I mean shutting down the system by > keeping the power button pressed and then powering the system > on again. When the system hangs, it doesn't seem to react to > the ACPI event that is generated by pressing the power button > shortly. It seems to react to the ACPI event if I press the power button more than once, the first time shortly enough so the system doesn't power down. Attached USB devices are also noticed, the same goes for attaching or detaching the power cord. > Today I rebooted the system three times in a row without getting > it to work so I finally unloaded geom_eli from the loader prompt, > booted to single-user mode and attached the geli provider from > there. Actually I unloaded all modules and this detail seems to matter. > When I booted a few hours later with the same kernel it > worked right away. >=20 > I think I experienced the problem the first time with > a kernel from last Wednesday, currently I'm using: > FreeBSD 9.0-CURRENT Fri Sep 17 18:25:39 CEST 2010 amd64 >=20 > It definitively didn't happen with a kernel from last Saturday, > but then again I seldomly boot the system more than once a day > and the problem doesn't always show. >=20 > I enabled boot_verbose=3D"-v" and kern.geom.eli.visible_passphrase=3D1 > and thus expect to be able to provide a more detailed problem > description the next time this happens. I'm still experiencing the problem with yesterday's CURRENT. By default I load the following modules through loader.conf: zlib_load=3D"YES" crypto_load=3D"YES" =20 geom_eli_load=3D"YES" =20 opensolaris_load=3D"YES" =20 zfs_load=3D"YES" =20 acpi_video_load=3D"YES" =20 acpi_ibm_load=3D"YES" =20 snd_hda_load=3D"YES" =20 snd_uaudio_load=3D"YES" =20 if_iwn_load=3D"YES" =20 iwnfw_load=3D"YES" I noticed that if the system (ThinkPad R500) is running from battery (with those modules enabled) the hangs are almost guaranteed to happen, with external power the hangs are a lot less likely, but can happen as well. If I remove either snd_hda or snd_uaudio it get a lot less likely that the problem occurs, even when running from battery. Fabian --Sig_/g5+qD93HV8TdBnCey=bOlMD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyhmPkACgkQBYqIVf93VJ1LAwCdFwi4i02FKizCjzCsSbraRDc6 xe0AoKE19D6i9cZWUoLBPFWwAiiaLu4q =oogx -----END PGP SIGNATURE----- --Sig_/g5+qD93HV8TdBnCey=bOlMD-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 07:31:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92830106566C for ; Tue, 28 Sep 2010 07:31:47 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3308A8FC14 for ; Tue, 28 Sep 2010 07:31:47 +0000 (UTC) Received: by qwd6 with SMTP id 6so3949899qwd.13 for ; Tue, 28 Sep 2010 00:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/rcJXdl89jnDWSzhUE2I2cw8B7cvtICV9FWbTKDMfYU=; b=RcFe0kKNAuDi2b20akj+YwG79Nb8pddb99cfvFo0CA161ZBFbpO1bNLNiQBkRO8ydu hLESSGnYcPnnsUiRWOU0A6tKXIuwr1ma4GsqhsApO6xqEyEYizZKsPXjsUCtsvQS4m9X btmgD4+RrUTDtdrAXmXbDf2qLmdmN7xviIvrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bhb9EfX+TFUi6cm0Pl0GGQLX+D36h5LFHGhC0CBKHZWWOpsL7WPV2GdVTMfoh1TaX4 QBy5HrI8rbVLL87puSSPc08aJbM/shU0jTfbCRtw075quq+aQ44+dQrnJCKOIuJfeSUm TX2odU3BcLiFRwG0zuMqWvsIkUNPmU9AT5zCI= MIME-Version: 1.0 Received: by 10.224.45.22 with SMTP id c22mr6480214qaf.103.1285659106494; Tue, 28 Sep 2010 00:31:46 -0700 (PDT) Received: by 10.229.50.8 with HTTP; Tue, 28 Sep 2010 00:31:45 -0700 (PDT) In-Reply-To: References: <201001282224.o0SMOsU8070773@svn.freebsd.org> Date: Tue, 28 Sep 2010 11:31:45 +0400 Message-ID: From: pluknet To: Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: svn commit: r203134 - in head: share/man/man4 sys/conf sys/contrib/dev/run sys/dev/usb sys/dev/usb/wlan sys/modules sys/modules/runfw sys/modules/usb sys/modules/usb/run X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 07:31:47 -0000 On 29 January 2010 09:16, pluknet wrote: > On 29 January 2010 01:24, Andrew Thompson wrote: >> Author: thompsa >> Date: Thu Jan 28 22:24:54 2010 >> New Revision: 203134 >> URL: http://svn.freebsd.org/changeset/base/203134 >> >> Log: >> =A0Add run(4), a driver for Ralink RT2700U/RT2800U/RT3000U USB 802.11agn= devices. >> >> =A0This driver was written for OpenBSD by Damien Bergamini and ported ov= er by >> =A0Akinori Furukoshi. >> > [...] > >> Added: head/share/man/man4/run.4 > [...] >> +The >> +.Nm >> +driver offloads both encryption and decryption of data frames to the >> +hardware for the WEP40, WEP104, TKIP(+MIC) and CCMP ciphers. >> +.Pp >> +The >> +.Nm >> +driver can be configured at runtime with >> +.Xr ifconfig 8 >> +or on boot with >> +.Xr hostname.if 5 . > > hostname.if(5) is something that only exists in OpenBSD. > I think the following would be better: > For more information on configuring this device, see > .Xr ifconfig 8 . > Hi, This is still relevant. hostname.if(5) is in OBSD. Will someone fix this? --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 07:48:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 768F4106566C; Tue, 28 Sep 2010 07:48:28 +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 47E868FC0C; Tue, 28 Sep 2010 07:48:28 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B961D46B17; Tue, 28 Sep 2010 03:48:27 -0400 (EDT) Date: Tue, 28 Sep 2010 08:48:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Joshua Neal In-Reply-To: Message-ID: References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <201009271738.19497.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1982540403-1285660107=:69239" Cc: "sbruno@freebsd.org" , freebsd-current@freebsd.org Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 07:48:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1982540403-1285660107=:69239 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 27 Sep 2010, Joshua Neal wrote: > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > asking the kernel for the max number and throwing an error if it doesn't > agree: Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit in libmemstat. The bug could be in not having a comment by the definition of MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > I was thinking a more future-proof fix would be to get rid of the static > allocations and allocate the library's internal structures based on the > value of kern.smp.maxcpus. Agreed. I'm fairly preoccupied currently, but would be happy to accept patches :-). Robert > > - Joshua > > On Mon, Sep 27, 2010 at 2:42 PM, Robert Watson wrote: >> >> On Mon, 27 Sep 2010, John Baldwin wrote: >> >>> Also, I think we should either fix MAXCPU to export the SMP value to >>> userland, or hide it from userland completely.  Exporting the UP value is >>> Just Wrong (tm). >> >> Well, it's useful in the sense that it tells you what the maximum number of >> CPUs a kernel can support is, which is helpful, especially if you're futzing >> with MAXCPU as a kernel option :-). >> >> But, more generally, many things that use MAXCPU should probably use either >> mp_maxid or DPCPU.  Not everything, but most things. >> >> Robert >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > --621616949-1982540403-1285660107=:69239-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 07:49:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3DF0106566B; Tue, 28 Sep 2010 07:49:05 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 75F758FC1A; Tue, 28 Sep 2010 07:49:05 +0000 (UTC) Received: by iwn34 with SMTP id 34so7092987iwn.13 for ; Tue, 28 Sep 2010 00:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.146.141 with SMTP id h13mr10300040ibv.1.1285660144725; Tue, 28 Sep 2010 00:49:04 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Tue, 28 Sep 2010 00:49:03 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> <4CA0743F.8050408@FreeBSD.org> Date: Tue, 28 Sep 2010 09:49:03 +0200 Message-ID: From: Olivier Smedts To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rene Ladan , Roman Divacky , Bartosz Stec , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 07:49:05 -0000 2010/9/27 Olivier Smedts : > 2010/9/27 Olivier Smedts : >> 2010/9/27 Dimitry Andric : >>> On 2010-09-27 09:32, Olivier Smedts wrote: >>>> >>>> 2010/9/23 Bartosz Stec: >>> >>> ... >>>>> >>>>> Assertion failed: (false&& =A0"Ran out of registers during register >>>>> allocation!"), function assignRegOrStackSlotAtInterval, file >>>>> >>>>> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/R= egAllocLinearScan.cpp, >>>>> line 1196. >>> >>> ... >>>> >>>> Same error here with yesterday's -CURRENT, but not at the same time >>>> (the running system was compiled using gcc) : >>> >>> As with Bartosz, could you please remove the CPU-specific flags from >>> make.conf, and try again? >> >> Ok, I'll post the results later (it was the same with -DNDEBUG). > > Was not OK with : > CPUTYPE=3Dathlon-xp > CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer > NO_CPU_CFLAGS=3Dyes > COPTFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer > NO_CPU_COPTFLAGS=3Dyes > > Is OK with : > CPUTYPE=3Dathlon-xp > CFLAGS=3D-O2 -pipe -fomit-frame-pointer > NO_CPU_CFLAGS=3Dyes > COPTFLAGS=3D-O2 -pipe -fomit-frame-pointer > NO_CPU_COPTFLAGS=3Dyes > > I'll try with other -march (i686 and athlon) and post results. So, with "-march=3Dathlon", buildworld is ok. With "-march=3Dathlon -msse" or "-march=3Dathlon-xp" or "-march=3Dnative", buildworld fails here : clang -c -O2 -pipe -march=3Dathlon -msse -fomit-frame-pointer -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 -DElfW=3D__ElfN -o unwind-dw2.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c Assertion failed: (!spillIs.empty() && "No spill intervals?"), function assignRegOrStackSlotAtInterval, file /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAllo= cLinearScan.cpp, line 1287. Stack dump: 0. Program arguments: /usr/obj/usr/src/tmp/usr/bin/clang -cc1 -triple i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name unwind-dw2.c -pic-level 2 -mconstructor-aliases -target-cpu athlon -target-feature +sse -resource-dir /usr/obj/usr/src/tmp/usr/lib/clang/2.8 -D IN_GCC -D IN_LIBGCC2 -D __GCC_FLOAT_NOT_NEEDED -D HAVE_GTHR_DEFAULT -D HIDE_EXPORTS -D __GLIBC__=3D3 -D ElfW=3D__ElfN -I /usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I /usr/src/gnu/lib/libgcc/../../../contrib/gcc -I . -I /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -O2 -std=3Dgnu99 -ferror-limit 19 -fmessage-length 118 -fvisibility hidden -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-CfyzYr.s -x c /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c 1. parser at end of file 2. Code generation 3. Running pass 'Linear Scan Register Allocator' on function '@_Unwind_GetGR' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) *** Error code 250 Stop in /usr/src/gnu/lib/libgcc. But if I # cd /usr/src/gnu/lib/libgcc # make then unwind-dw2.c compiles fine. So the problem seems to be with clang (/usr/obj/usr/src/tmp/usr/bin/clang) when compiled with SSE on Athlon. Can't try with AMD k8 or Intel CPUs, my core2 follows -STABLE. > >>> I guess there is something borked in LLVM's Athlon optimization, so it >>> is probably better to not try to tickly those bugs for now. >>> >>> >>>> # grep -vE '^#|^$' /etc/make.conf >>>> KERNCONF=3DXPC >>>> CPUTYPE=3Dathlon-xp >>>> CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer >>> >>> Using CPUTYPE=3D and -march=3D seems a bit redundant. :) >> >> Not with NO_CPU_CFLAGS=3Dyes and NO_CPU_COPTFLAGS=3Dyes (if you want to >> use -march=3Dnative, that's the best thing to do). >> >>> >>>> clang -c -O2 -pipe -march=3Dnative -fomit-frame-pointer -DIN_GCC >>>> -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED =A0-DHAVE_GTHR_DEFAULT >>>> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include >>>> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config >>>> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. >>>> -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 >>>> -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D= 3 >>>> -DElfW=3D__ElfN -o unwind-dw2.o >>>> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c >>>> Assertion failed: (!spillIs.empty()&& =A0"No spill intervals?"), >>>> function assignRegOrStackSlotAtInterval, file >>>> >>>> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/Re= gAllocLinearScan.cpp, >>>> line 1287. >>> >>> I haven't yet seen this one before. =A0If I can reproduce it, I will >>> report it upstream, and see if they can come up with a fix. > > Anything I can provide to help with that ? > >> >> Thanks ! >> >> -- >> Olivier Smedts > > -- > Olivier Smedts --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 08:25:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AE88106564A for ; Tue, 28 Sep 2010 08:25:47 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51805.mail.re2.yahoo.com (web51805.mail.re2.yahoo.com [206.190.38.236]) by mx1.freebsd.org (Postfix) with SMTP id C38ED8FC14 for ; Tue, 28 Sep 2010 08:25:46 +0000 (UTC) Received: (qmail 25143 invoked by uid 60001); 28 Sep 2010 08:25:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1285662346; bh=nTVg52q9bnZsNpgeJc8XoYzgRuQm4HGiDY6u6FCwmsg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xqv9y+6wzm1k28O9JAu1uBAb235JnimWUEbb9u1JZZ18Gytrm8AehaO9nrX1fvaXmG1pY1D4VhueJgbjzU13RXbSIEZMtULdkZFqVDRyf8iBfBp2/lliau628IeXMjYkqdWNA6Vy18JMHueApgn094oF5eAF+f91vD5cSUl2CoM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ceGQlFZtOCts6LHq2IgBihImal4PJD271TBDyRDAfkTbibvB+i58jJVoWeyWtaYdRN6CGaaOMC/SQDM62zBp6LQAtsl//ax+1anAt/dnTpyeMLmPKe7cU4+Z184vcw+hhVhL2k07JEuTRaVjGFnnkTwJstCBWI8KLa3y7FTLXDg=; Message-ID: <56027.22059.qm@web51805.mail.re2.yahoo.com> X-YMail-OSG: HhPlu48VM1nj3ayBsDLz.5n2zp3d4jZsL7iDEdwVsptHveI y2R04SwkQy0UptkWbpcnHwuzYjuys0bhZJ_6SeyglgC8F_dF89bV1jjiFgNO eDQQAq77KG49TDtCDRS8LhKNo3m7HbfepTM8.1LV4AMa8hpFpxEY7eCu1.vI vlf4eaa2BSj8cF1B_pKWe6KvNz46r3IbOENyU3w_iQrE5XpKIgihcaPFZLTY 7Y0GIk8wMC8wxsUT4zC7yp7C4kfE2_Wn3BVJQwlDPXkeoY04HZ77fQLkF5Cb eIw9DIGBnY.GeDyi8NAfd2d.twDue7RzSfhFCQ3JMYJRG6kMvKZR1XAPJqiQ zPS0P Received: from [173.183.132.20] by web51805.mail.re2.yahoo.com via HTTP; Tue, 28 Sep 2010 01:25:45 PDT X-Mailer: YahooMailRC/497 YahooMailWebService/0.8.105.279950 References: <20100928074914.A1ABF1065790@hub.freebsd.org> Date: Tue, 28 Sep 2010 01:25:45 -0700 (PDT) From: PseudoCylon To: pluknet , Andrew Thompson In-Reply-To: <20100928074914.A1ABF1065790@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Current Subject: Re: svn commit: r203134 - in head: share/man/man4 sys/conf sys/contrib/dev/run sys/dev/usb sys/dev/usb/wlan sys/modules sys/modules/runfw sys/modules/usb sys/modules/usb/run X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 08:25:47 -0000 > > > > hostname.if(5) is something that only exists in OpenBSD. > > I think the following would be better: > > For more information on configuring this device, see > > .Xr ifconfig 8 . > > > > Hi, > > This is still relevant. hostname.if(5) is in OBSD. > Will someone fix this? > > -- > wbr, > pluknet > > Yes, I'm working on it, and about to submit with runfw.4. If you have them a quick peak, it will be appreciated. http://gitorious.org/run/man/trees/master/man/man4 AK From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 13:41:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E9610656A7; Tue, 28 Sep 2010 13:41:55 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 785488FC12; Tue, 28 Sep 2010 13:41:55 +0000 (UTC) Received: by iwn34 with SMTP id 34so7522436iwn.13 for ; Tue, 28 Sep 2010 06:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.167.80 with SMTP id p16mr10958024iby.119.1285681314854; Tue, 28 Sep 2010 06:41:54 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Tue, 28 Sep 2010 06:41:54 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <4C9A32B8.60204@kkip.pl> <4C9A6A38.4080307@freebsd.org> <4C9A7203.8010701@kkip.pl> <20100923065134.GA31455@freebsd.org> <4C9B3207.2070302@kkip.pl> Date: Tue, 28 Sep 2010 15:41:54 +0200 Message-ID: From: Olivier Smedts To: Bartosz Stec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rene Ladan , Roman Divacky , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 13:41:55 -0000 2010/9/27 Olivier Smedts : > 2010/9/23 Bartosz Stec : >> =A0On 2010-09-23 08:51, Roman Divacky wrote: >>> >>> if you want to post any build-time numbers for clang please >>> >>> =A0 =A0 =A0 =A0 =A0 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS #-DN= DEBUG >>> >>> uncomment the -DNDEBUG on this line in lib/clang/clang.build.mk >>> and rebuild it otherwise you are using Release+Asserts build of >>> clang which is some 30% slower than the normal one... >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >> >> When i try to rebuild world again (machine has world and kernel builded = with >> clang) I cought following problem at the very beginning: >> >> -------------------------------------------------------------- >>>>> World build started on Thu Sep 23 12:46:55 CEST 2010 >> -------------------------------------------------------------- >> >> -------------------------------------------------------------- >>>>> Rebuilding the temporary build tree >> -------------------------------------------------------------- >> rm -rf /usr/obj/usr/src/tmp >> mkdir -p /usr/obj/usr/src/tmp/lib >> mkdir -p /usr/obj/usr/src/tmp/usr >> mkdir -p /usr/obj/usr/src/tmp/legacy/usr >> mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist =A0-p >> /usr/obj/usr/src/tmp/legacy/usr >/dev/null >> mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist =A0-p /usr/obj/usr/src/tmp= /usr >>>/dev/null >> mtree -deU -f /usr/src/etc/mtree/BSD.include.dist =A0-p >> /usr/obj/usr/src/tmp/usr/include >/dev/null >> ln -sf /usr/src/sys /usr/obj/usr/src/tmp >> >> -------------------------------------------------------------- >>>>> stage 1.1: legacy release compatibility shims >> -------------------------------------------------------------- >> cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp =A0INSTALL=3D"sh >> /usr/src/tools/install.sh" >> =A0PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/lega= cy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/= bin >> =A0WORLDTMP=3D/usr/obj/usr/src/tmp =A0VERSION=3D"FreeBSD 9.0-CURRENT i38= 6 900021" >> =A0MAKEFLAGS=3D"-m /usr/src/tools/build/mk =A0-m /usr/src/share/mk" make= -f >> Makefile.inc1 =A0DESTDIR=3D =A0BOOTSTRAPPING=3D900021 =A0SSP_CFLAGS=3D = =A0-DWITHOUT_HTML >> -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN =A0-DNO_PIC -DWITHOUT_PROFILE >> -DNO_SHARED =A0-DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF legacy >> =3D=3D=3D> tools/build (obj,includes,depend,all,install) >> /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/buil= d >> cd /usr/src/tools/build; make buildincludes; make installincludes >> rm -f .depend >> CC=3D'clang' mkdep -f .depend -a =A0 =A0-I/usr/obj/usr/src/tmp/legacy/us= r/include >> /usr/src/tools/build/dummy.c >> clang -O2 -pipe -std=3Dgnu99 =A0 -I/usr/obj/usr/src/tmp/legacy/usr/inclu= de -c >> /usr/src/tools/build/dummy.c >> building static egacy library >> ranlib libegacy.a >> sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 =A0 libegacy.a >> /usr/obj/usr/src/tmp/legacy/usr/lib >> >> -------------------------------------------------------------- >>>>> stage 1.2: bootstrap tools >> -------------------------------------------------------------- >> cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp =A0INSTALL=3D"sh >> /usr/src/tools/install.sh" >> =A0PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/lega= cy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/= bin >> =A0WORLDTMP=3D/usr/obj/usr/src/tmp =A0VERSION=3D"FreeBSD 9.0-CURRENT i38= 6 900021" >> =A0MAKEFLAGS=3D"-m /usr/src/tools/build/mk =A0-m /usr/src/share/mk" make= -f >> Makefile.inc1 =A0DESTDIR=3D =A0BOOTSTRAPPING=3D900021 =A0SSP_CFLAGS=3D = =A0-DWITHOUT_HTML >> -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN =A0-DNO_PIC -DWITHOUT_PROFILE >> -DNO_SHARED =A0-DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF bootstrap-tools >> =3D=3D=3D> lib/clang/libllvmsupport (obj,depend,all,install) >> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for >> /usr/src/lib/clang/libllvmsupport >> rm -f .depend >> CC=3D'clang' mkdep -f .depend -a >> =A0-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/in= clude >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I= . >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clan= g/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" >> -I/usr/obj/usr/src/tmp/legacy/usr/include >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regc= omp.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/rege= rror.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/rege= xec.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regf= ree.c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regs= trlcpy.c >> CC=3D'clang' mkdep -f .depend -a >> =A0-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/in= clude >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I= . >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clan= g/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" >> -I/usr/obj/usr/src/tmp/legacy/usr/include >> =A0/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/A= PFloat.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APIn= t.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSI= nt.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allo= cator.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Comm= andLine.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Cons= tantRange.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Cras= hRecoveryContext.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGD= eltaAlgorithm.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debu= g.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Delt= aAlgorithm.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwar= f.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Erro= rHandling.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Fold= ingSet.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Form= attedStream.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Grap= hWriter.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Mana= gedStatic.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Memo= ryBuffer.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Plug= inLoader.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Pret= tyStackTrace.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Rege= x.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Smal= lPtrSet.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Smal= lVector.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Sour= ceMgr.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stat= istic.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngExtras.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngMap.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngPool.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Stri= ngRef.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Targ= etRegistry.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Time= r.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Trip= le.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Twin= e.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/circ= ular_raw_ostream.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_= os_ostream.cpp >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_= ostream.cpp >> clang++ -O2 -pipe >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/in= clude >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I= . >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clan= g/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_HOSTTRIPLE=3D\"i386-undermydesk-freebsd9.0\" -fno-exceptions >> -I/usr/obj/usr/src/tmp/legacy/usr/include -c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFl= oat.cpp >> Assertion failed: (false && "Ran out of registers during register >> allocation!"), function assignRegOrStackSlotAtInterval, file >> /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegA= llocLinearScan.cpp, >> line 1196. >> Stack dump: >> 0. =A0 =A0 =A0Program arguments: /usr/bin/clang++ -cc1 -triple >> i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name APFloat.cpp >> -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases >> -target-cpu i486 -resource-dir /usr/lib/clang/2.8 -D LLVM_ON_UNIX -D >> LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -D NDEB= UG >> -D LLVM_HOSTTRIPLE=3D"i386-undermydesk-freebsd9.0" -I >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude >> -I /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -= I . >> -I >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include >> -I /usr/obj/usr/src/tmp/legacy/usr/include -O2 -ferror-limit 19 >> -fmessage-length 205 -fgnu-runtime -fdiagnostics-show-option >> -fcolor-diagnostics -o /tmp/cc-lvFfGd.s -x c++ >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFl= oat.cpp >> 1. parser at end of file >> 2. =A0 =A0 =A0Code generation >> 3. =A0 =A0 =A0Running pass 'Linear Scan Register Allocator' on function >> '@_ZN4llvm7APFloat28convertFromHexadecimalStringENS_9StringRefENS0_12rou= ndingModeE' >> clang++: error: clang frontend command failed due to signal 6 (use -v to= see >> invocation) >> *** Error code 250 > > Same error here with yesterday's -CURRENT, but not at the same time > (the running system was compiled using gcc) : > > # uname -a > FreeBSD z.gid0.org 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Sep 24 > 22:07:43 CEST 2010 =A0 =A0 root@z.gid0.org:/usr/obj/usr/src/sys/XPC =A0i3= 86 > # clang -v > FreeBSD clang version 2.8 (branches/release_28 114020) 20100917 > Target: i386-undermydesk-freebsd9.0 > Thread model: posix > # grep -vE '^#|^$' /etc/make.conf > KERNCONF=3DXPC > CPUTYPE=3Dathlon-xp > CFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer > NO_CPU_CFLAGS=3Dyes > COPTFLAGS=3D-O2 -pipe -march=3Dnative -fomit-frame-pointer > NO_CPU_COPTFLAGS=3Dyes > WITHOUT_PROFILE=3Dyes > SUP_UPDATE=3Dyes > SUPFILE=3D/usr/share/examples/cvsup/standard-supfile > SUPHOST=3Dcvsup3.fr.freebsd.org > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > NO_WERROR=3D > WERROR=3D > # make buildworld > [...] > =3D=3D=3D> gnu/lib/libgcc (obj,depend,all,install) > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc tm.h > TARGET_CPU_DEFAULT=3D"" =A0HEADERS=3D"options.h i386/i386.h i386/unix.h > i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h > freebsd-spec.h freebsd.h i386/freebsd.h defaults.h" =A0DEFINES=3D"" > /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h > echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc tconfig.h > TARGET_CPU_DEFAULT=3D"" =A0HEADERS=3D"auto-host.h ansidecl.h" > DEFINES=3D"USED_FOR_TARGET" =A0/bin/sh > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc options.h > LC_ALL=3DC awk -f > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/c.opt > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/common.opt > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.opt > > optionlist > LC_ALL=3DC awk -f > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk =A0-f > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk =A0< > optionlist > options.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h > ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwi= nd.h > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h > ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-def= ault.h > clang -c -O2 -pipe -march=3Dnative -fomit-frame-pointer -DIN_GCC > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED =A0-DHAVE_GTHR_DEFAULT > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. > -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 > -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 > -DElfW=3D__ElfN -o unwind-dw2.o > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > Assertion failed: (!spillIs.empty() && "No spill intervals?"), > function assignRegOrStackSlotAtInterval, file > /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAl= locLinearScan.cpp, > line 1287. > Stack dump: > 0. =A0 =A0 =A0Program arguments: /usr/obj/usr/src/tmp/usr/bin/clang -cc1 > -triple i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name > unwind-dw2.c -pic-level 2 -mconstructor-aliases -target-cpu athlon-mp > -resource-dir /usr/obj/usr/src/tmp/usr/lib/clang/2.8 -D IN_GCC -D > IN_LIBGCC2 -D __GCC_FLOAT_NOT_NEEDED -D HAVE_GTHR_DEFAULT -D > HIDE_EXPORTS -D __GLIBC__=3D3 -D ElfW=3D__ElfN -I > /usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I > /usr/src/gnu/lib/libgcc/../../../contrib/gcc -I . -I > /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -O2 -std=3Dgnu99 > -ferror-limit 19 -fmessage-length 118 -fvisibility hidden -fexceptions > -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o > /tmp/cc-UeLPOI.s -x c > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > 1. =A0 =A0 =A0 parser at end of file > 2. =A0 =A0 =A0Code generation > 3. =A0 =A0 =A0Running pass 'Linear Scan Register Allocator' on function > '@_Unwind_GetGR' > clang: error: clang frontend command failed due to signal 6 (use -v to > see invocation) > *** Error code 250 > > Stop in /usr/src/gnu/lib/libgcc. > *** Error code 1 I solved this problem at my level by adding "CFLAGS+=3D-mno-sse" to src/lib/clang/clang.lib.mk Now I can "make buildworld buildkernel" with "-march=3Dnative" (on an Athlon XP). Without that, the clang compiled with SSE failed to compile libgcc. Note : this does not add "-mno-sse" to all CFLAGS but only to the CFLAGS used to compile clang/llvm libs. Maybe I could find one or more specific libs which require "-mno-sse" in this case, but there are 50 in src/lib/clang/, and this computer is really slow to buildworld. Any clues on this ? > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > -- > Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 = X > www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ > > =A0 "Il y a seulement 10 sortes de gens dans le monde : > =A0 ceux qui comprennent le binaire, > =A0 et ceux qui ne le comprennent pas." > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 16:55:55 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387901065670; Tue, 28 Sep 2010 16:55:55 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 1830E8FC12; Tue, 28 Sep 2010 16:55:54 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id o8SGjBxZ065956; Tue, 28 Sep 2010 09:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1285692311; bh=cAg42VJu+1XzzToKF0HGsaT7pBxxLBzUhu0LnsMXpg8=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=mPIFSVVhUYyfV3CitXmct1HwmiUSOne9P8r1W9ghToRTJGhRbg1NbvhgGqJ9ULjeo g2IDQYisKmI2C8YkvBzKtNPiNbUQ0ADdI5OjIz9YMBpN4juz2NSFOWLa7uG5slSi1W jAB0Of3nGRNnK1mLvI9TREFwKi0gQzKeU/F0+Z2U= From: Sean Bruno To: Robert Watson In-Reply-To: References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <201009271738.19497.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 28 Sep 2010 09:45:11 -0700 Message-ID: <1285692311.2454.11.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Sep 2010 17:12:29 +0000 Cc: "sbruno@freebsd.org" , "freebsd-current@FreeBSD.org" , Joshua Neal , John Baldwin Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 16:55:55 -0000 On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote: > On Mon, 27 Sep 2010, Joshua Neal wrote: > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > > asking the kernel for the max number and throwing an error if it doesn't > > agree: > > Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit > in libmemstat. The bug could be in not having a comment by the definition of > MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > > > I was thinking a more future-proof fix would be to get rid of the static > > allocations and allocate the library's internal structures based on the > > value of kern.smp.maxcpus. > > Agreed. I'm fairly preoccupied currently, but would be happy to accept > patches :-). > > Robert Working on a dynamic version today. I'll spam it over to you for review later. I'm moving the percpu struct definitions outside of struct memory_type, allocating quantity kern.smp.maxcpus, removing the boundary checks based on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. Sean From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 17:39:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC481065679 for ; Tue, 28 Sep 2010 17:39:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id DA0E58FC15 for ; Tue, 28 Sep 2010 17:39:44 +0000 (UTC) Received: by gwb15 with SMTP id 15so2482065gwb.13 for ; Tue, 28 Sep 2010 10:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qmCwzUz5VAUR1sJJQ97Ri01gFuQw2DPjHlEMtM5xj70=; b=fT/COwpUYT42UsH+aQ+1QQTSNbz/62TVRPsWmOFIP2kkw64Z5TFDMWp453ptXntxhb V6hrZdHJtZ5UTDI+9I/IRloN3w9BEk60RZuMJB+vq0hmhwnWzoWCqJ+UsvLsN6OCvLzm vYOcA1GAs2H+IHjeD0OhmD4ydBCZJAmgw6EbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=mQGkv7qlsnkKUHgGKa/FN0szwZYcwo0KbQt+2/vvWQ6SYGkEWHMwHuhQJYDzmfoQIM Bmkam+H2pw1rg7G/OkLyrXxbIpef43b8jMu2oX9NzddfulZBz5InqOVkVU58//tvuYpm Ed0YZuhTvTplRvwfIG9ukni3snGLWn2+6fIdw= MIME-Version: 1.0 Received: by 10.150.52.11 with SMTP id z11mr508444ybz.149.1285695583833; Tue, 28 Sep 2010 10:39:43 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.150.158.20 with HTTP; Tue, 28 Sep 2010 10:39:43 -0700 (PDT) Date: Tue, 28 Sep 2010 19:39:43 +0200 X-Google-Sender-Auth: 50houPhnTXGyhYeLaLPt8apOQf4 Message-ID: From: Attilio Rao To: freebsd-net@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 Cc: Ryan Stone , Ed Maste Subject: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 17:39:45 -0000 In the last weeks I worked for porting the netdump infrastructure to FreeBSD-CURRENT on the behalf of Sandvine Incorporated. Netdump is a framework that aims for handling kernel coredumps over the TCP/IP suite in order to dump to a separate machine than the running one. That may be used on an interesting number of cases involving disk-less workstations, disk driver debugging or embedded devices. GENERAL FRAMEWORK ARCHITECTURE Netdump is composed, right now, by an userland "server" and a kernel "client". The former is run on the target machine (where the dump will phisically happen) and it is responsible for receiving the packets containing coredumps frame and for correctly writing them on-disk. The latter is part of the kernel installed on the source machine (where the dump is initiated) and is responsible for building correctly UDP packets containing the coredump frames, pushing through the network interface and routing them appropriately. While the server may appear as, pretty much, a simple userland deamon dealing with UDP packets, the client imposes interesting problems as long as its activity is linked to handling kernel core dumping. More precisely, as long as the client is part of the dumping mechanism and the kernel may be in general panic conditions, netdump must ensure "robustness" of operations. That is partially achieved by reworking (and someway replicating) locally some UDP, ARP and IP operations, hardsetting some values (like the default gateway, the destination and the client address) and reducing further interactions with the kernel just to the network interface acitivities. More specifically, it implements a very basic UDP / IPv4 / ARP stack separate from the standard stack (since that may not be in a consistent state). It can dump to a server on the same LAN or via a router (correctly specifying the connection gateway). In order to receive packet on critical conditions, netdump polls the interface. Every network driver can implement hooks to be used by netdump independently by DEVICE_POLLING option, even if it is probabilly a good idea to share some code among them. The reference set of hooks is contained into "struct netdump_methods". And if_lem/if_em driver modifies may be set as reference for netdump hooks implementation. In order to work into an "up and running" system (meant as with all the devices in place) the netdump handler hooks as a pre-sync handler (differently from other dumping routines). It however suffers some problems typical of other dumping mechanism. For example, on DDB entering unlocked version of polling handler is used, in order to reduce the risk of deadlocks during inspections*. That reflects, among the netdump methods, the existence of 2 versions of polling hooks, where the "unlocked" is meant as reducing locking as much as possible. PATCH AND FURTHER WORK The patch is not totally complete and it is not intended to be committed in SVN yet. What I'm looking for now is more testing and review (in particular in terms of architecture) coverage by community. The server should be in realtively "committable" state, though, but I encourage its stress-testing. A manpage is provided along that should be very easy to understand how to use it. Things that can be further improved, as it is now, in the client, are: - Deciding if hardcoding of the kernel parameter is done properly. I personally don't like the sysctl usage and I would prefer an userland small utility used to testing and maybe add some tunables for enabling netdump early in the boot. You may have several opinions on this though. - VIMAGE and IPv6 support. - More drivers support. Right now only if_em (and if_lem) are converted to use netdump and can be used as a draft for other device drivers. if_ixgb should came along in the final, committing, version too. In general I think that all drivers supporting device polling could easilly support also netdump - Ideally dumpsys() in FreeBSD is too much disk-activity oriented. It should be made, instead, more neutral and more flexible to cope better with different interfaces. It is a quite a bit of work, however, and beyond the scope of netdump introduction (even if it could be beneficial for it) Netdump has been developed on a FreeBSD project branch located here: svn://svn.freebsd.org/base/projects/sv/ which could also forsee further informations about every single change. However, for your convenience, also a patch has been made public which is located here (against FreeBSD-CURRENT@213246): http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_0.diff In order to enable the client it is enough to add at your kernel config: options NETDUMP_CLIENT NETDUMP_CLIENT_DEBUG can be specified too in order to have further debuggin traces but I'd encourage to use them just for developing Netdump itself. TYPICAL USAGE This is a set of the available sysctls for netdump: # sysctl -d net.dump net.dump: netdump net.dump.enable: enable network dump net.dump.retries: times to retransmit lost packets net.dump.polls: times to poll NIC per retry net.dump.nic: NIC to dump on net.dump.gateway: dump default gateway net.dump.client: dump client And when compiled with the NETDUMP_CLIENT_DEBUG option: net.dump.serve# sysctl -d debug.netdump debug.netdump: Netdump debugging debug.netdump.crash: force crashingr: dump server A tipycal setup for netdump can be the following: Run the server on the receiving interface: # ifconfig em2 em2: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:28:b2:7a inet 10.135.14.118 netmask 0xfffffffc broadcast 10.135.14.119 media: Ethernet autoselect (1000baseT ) status: active # netdumpsrv -a 10.135.14.118 Listening on IP 10.135.14.118 Default: dumping on /var/crash/ While on the client: # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 10.128.0.0/10 10.135.12.113 UGS 18 149 em2 10.135.12.112/30 link#3 U 0 0 em2 127.0.0.1 link#5 UH 0 118 lo0 ... # ifconfig em2 em2: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:28:9f:b2 inet6 fe80::230:48ff:fe28:9fb2%em2 prefixlen 64 scopeid 0x3 inet 10.135.12.114 netmask 0xfffffffc broadcast 10.135.12.115 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active # sysctl net.dump.server=10.135.14.118 net.dump.server: 0.0.0.0 -> 10.135.14.118 # sysctl net.dump.client=10.135.12.114 net.dump.client: 0.0.0.0 -> 10.135.12.114 # sysctl net.dump.gateway=10.135.12.113 net.dump.gateway: 0.0.0.0 -> 10.135.12.113 # sysctl net.dump.nic=em2 net.dump.nic: none -> em2 # sysctl net.dump.enable=1 net.dump.enable: 0 -> 1 and at next dumping operation on client, it must netdump. Thanks, Attilio [* The dumping infrastructure in FreeBSD has several weaknesses that needs to be discussed and treacted separately] -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 18:19:32 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C5C7106566B; Tue, 28 Sep 2010 18:19:32 +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 6D3418FC18; Tue, 28 Sep 2010 18:19:32 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 33E4F46B8A; Tue, 28 Sep 2010 14:19:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <1285692311.2454.11.camel@home-yahoo> Date: Tue, 28 Sep 2010 19:19:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10297FDD-3949-4ED1-88C8-D5C16E0F2069@FreeBSD.org> References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <201009271738.19497.jhb@freebsd.org> <1285692311.2454.11.camel@home-yahoo> To: Sean Bruno X-Mailer: Apple Mail (2.1081) Cc: "sbruno@freebsd.org" , "freebsd-current@FreeBSD.org" , Joshua Neal , John Baldwin Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 18:19:32 -0000 On 28 Sep 2010, at 17:45, Sean Bruno wrote: > Working on a dynamic version today. I'll spam it over to you for = review > later. =20 >=20 > I'm moving the percpu struct definitions outside of struct = memory_type, > allocating quantity kern.smp.maxcpus, removing the boundary checks = based > on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. Sounds like the right answer. Make sure to also keep the adapt the use = of maxcpus from crashdumps so that we can also size the data structure = when analyzing cores (or /dev/kmem or firewire). Robert= From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 18:29:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C00911065672; Tue, 28 Sep 2010 18:29:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8F93A8FC0A; Tue, 28 Sep 2010 18:29:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4376C46B65; Tue, 28 Sep 2010 14:29:38 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 729E28A03C; Tue, 28 Sep 2010 14:29:37 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Tue, 28 Sep 2010 14:29:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1285601161.7245.7.camel@home-yahoo> <1285692311.2454.11.camel@home-yahoo> In-Reply-To: <1285692311.2454.11.camel@home-yahoo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201009281429.30747.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 28 Sep 2010 14:29:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "sbruno@freebsd.org" , "freebsd-current@FreeBSD.org" , Robert Watson , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 18:29:38 -0000 On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote: > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote: > > On Mon, 27 Sep 2010, Joshua Neal wrote: > > > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > > > asking the kernel for the max number and throwing an error if it doesn't > > > agree: > > > > Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit > > in libmemstat. The bug could be in not having a comment by the definition of > > MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > > > > > I was thinking a more future-proof fix would be to get rid of the static > > > allocations and allocate the library's internal structures based on the > > > value of kern.smp.maxcpus. > > > > Agreed. I'm fairly preoccupied currently, but would be happy to accept > > patches :-). > > > > Robert > > Working on a dynamic version today. I'll spam it over to you for review > later. > > I'm moving the percpu struct definitions outside of struct memory_type, > allocating quantity kern.smp.maxcpus, removing the boundary checks based > on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 18:41:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854C9106564A; Tue, 28 Sep 2010 18:41:16 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 667308FC08; Tue, 28 Sep 2010 18:41:16 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id o8SIeitJ014147; Tue, 28 Sep 2010 11:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1285699244; bh=HCL7O7ycLSkCJKQKzS7oE4Ns41ewekPJjq3r8xk+xzE=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=ES1dweAI0I/I9WXhk97qn99tsSBrim1ZJ8vDDalF1LW8NV9LnXHMlXZp+nszCMvg0 bvSXX3V3T3A6T+7Ahpb1mTkNmBHcbJ7jjajEc8ngPJL7Aoq8/Kgq0VmHMT01Jx0mD1 vpgPQCvvD4HDTbv2zGDs0zHf5RUxyBqU1MeA/39Y= From: Sean Bruno To: John Baldwin In-Reply-To: <201009281429.30747.jhb@freebsd.org> References: <1285601161.7245.7.camel@home-yahoo> <1285692311.2454.11.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 28 Sep 2010 11:40:44 -0700 Message-ID: <1285699244.2454.63.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "sbruno@freebsd.org" , "freebsd-current@FreeBSD.org" , Robert Watson , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 18:41:16 -0000 On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote: > On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote: > > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote: > > > On Mon, 27 Sep 2010, Joshua Neal wrote: > > > > > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > > > > asking the kernel for the max number and throwing an error if it doesn't > > > > agree: > > > > > > Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit > > > in libmemstat. The bug could be in not having a comment by the definition of > > > MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > > > > > > > I was thinking a more future-proof fix would be to get rid of the static > > > > allocations and allocate the library's internal structures based on the > > > > value of kern.smp.maxcpus. > > > > > > Agreed. I'm fairly preoccupied currently, but would be happy to accept > > > patches :-). > > > > > > Robert > > > > Working on a dynamic version today. I'll spam it over to you for review > > later. > > > > I'm moving the percpu struct definitions outside of struct memory_type, > > allocating quantity kern.smp.maxcpus, removing the boundary checks based > > on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. > > If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some history here so I can understand why one is "better" than the other? Sean From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 19:07:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E41106566C; Tue, 28 Sep 2010 19:07:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 58EF78FC0C; Tue, 28 Sep 2010 19:07:53 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0623146B9B; Tue, 28 Sep 2010 15:07:53 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 308638A04F; Tue, 28 Sep 2010 15:07:52 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Date: Tue, 28 Sep 2010 15:06:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1285601161.7245.7.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> <1285699244.2454.63.camel@home-yahoo> In-Reply-To: <1285699244.2454.63.camel@home-yahoo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201009281506.35960.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 28 Sep 2010 15:07:52 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "freebsd-current@FreeBSD.org" , Robert Watson , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 19:07:53 -0000 On Tuesday, September 28, 2010 2:40:44 pm Sean Bruno wrote: > On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote: > > On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote: > > > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote: > > > > On Mon, 27 Sep 2010, Joshua Neal wrote: > > > > > > > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > > > > > asking the kernel for the max number and throwing an error if it doesn't > > > > > agree: > > > > > > > > Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit > > > > in libmemstat. The bug could be in not having a comment by the definition of > > > > MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > > > > > > > > > I was thinking a more future-proof fix would be to get rid of the static > > > > > allocations and allocate the library's internal structures based on the > > > > > value of kern.smp.maxcpus. > > > > > > > > Agreed. I'm fairly preoccupied currently, but would be happy to accept > > > > patches :-). > > > > > > > > Robert > > > > > > Working on a dynamic version today. I'll spam it over to you for review > > > later. > > > > > > I'm moving the percpu struct definitions outside of struct memory_type, > > > allocating quantity kern.smp.maxcpus, removing the boundary checks based > > > on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. > > > > If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. > > > > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some > history here so I can understand why one is "better" than the other? mp_maxid is the variable in the kernel of the maximum possible CPU ID in the running kernel. It is what all kernel code uses for dynamically sized per-CPU arrays such as UMA. It can be smaller than MAXCPU if the platform does not support hotplug CPUs (true for all of our current platforms). maxcpus was only added to export the value of MAXCPU so that user code that uses libkvm to read kernel memory directly can work with datastructures that use statically sized arrays (foo[MAXCPU]) rather than dynamically sized arrays. Aside from that one specific use case, maxcpus should not be used. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 19:58:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6F3E106566B for ; Tue, 28 Sep 2010 19:58:43 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id F1A3E8FC1A for ; Tue, 28 Sep 2010 19:58:42 +0000 (UTC) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id o8SJu1kr042376 for ; Wed, 29 Sep 2010 04:56:02 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201009281956.o8SJu1kr042376@sana.init-main.com> To: freebsd-current@freebsd.org Date: Wed, 29 Sep 2010 04:56:01 +0900 From: Takanori Watanabe Subject: UFS related panic at night. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 19:58:43 -0000 I happend to encountered panic related to UFS. It is occured by find(1) from daily script by NULL pointing sx(9) lock from UFS dirhash. Mounted filesystem is like this. %mount /dev/ada0s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ada0s2e on /usr (ufs, NFS exported, local, soft-updates) /dev/ada0s2d on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) And stack backtrace is at http://www.init-main.com/DVC00052.JPG (screen shot.) From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 20:01:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BACE81065693; Tue, 28 Sep 2010 20:01:35 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5D78FC08; Tue, 28 Sep 2010 20:01:35 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o8SJnSjG095765; Tue, 28 Sep 2010 12:49:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=LKF49Ljv45PEGT2+dQsVX9SahDoisldbxJtr6Fobq/7f+ZhaQcAadT8FzufhumYS From: Sean Bruno To: John Baldwin In-Reply-To: <201009281506.35960.jhb@freebsd.org> References: <1285601161.7245.7.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> <1285699244.2454.63.camel@home-yahoo> <201009281506.35960.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 28 Sep 2010 12:49:28 -0700 Message-ID: <1285703368.2454.64.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Sep 2010 20:11:40 +0000 Cc: "sbruno@freebsd.org" , "freebsd-current@FreeBSD.org" , Robert Watson , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 20:01:35 -0000 On Tue, 2010-09-28 at 14:06 -0500, John Baldwin wrote: > On Tuesday, September 28, 2010 2:40:44 pm Sean Bruno wrote: > > On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote: > > > On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote: > > > > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote: > > > > > On Mon, 27 Sep 2010, Joshua Neal wrote: > > > > > > > > > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > > > > > > asking the kernel for the max number and throwing an error if it doesn't > > > > > > agree: > > > > > > > > > > Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit > > > > > in libmemstat. The bug could be in not having a comment by the definition of > > > > > MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > > > > > > > > > > > I was thinking a more future-proof fix would be to get rid of the static > > > > > > allocations and allocate the library's internal structures based on the > > > > > > value of kern.smp.maxcpus. > > > > > > > > > > Agreed. I'm fairly preoccupied currently, but would be happy to accept > > > > > patches :-). > > > > > > > > > > Robert > > > > > > > > Working on a dynamic version today. I'll spam it over to you for review > > > > later. > > > > > > > > I'm moving the percpu struct definitions outside of struct memory_type, > > > > allocating quantity kern.smp.maxcpus, removing the boundary checks based > > > > on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. > > > > > > If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. > > > > > > > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some > > history here so I can understand why one is "better" than the other? > > mp_maxid is the variable in the kernel of the maximum possible CPU ID in the > running kernel. It is what all kernel code uses for dynamically sized per-CPU > arrays such as UMA. It can be smaller than MAXCPU if the platform does not > support hotplug CPUs (true for all of our current platforms). > > maxcpus was only added to export the value of MAXCPU so that user code that > uses libkvm to read kernel memory directly can work with datastructures that > use statically sized arrays (foo[MAXCPU]) rather than dynamically sized > arrays. Aside from that one specific use case, maxcpus should not be used. > ah, I see now. sys/kern/subr_smp.c::mp_maxid is exported via the systcl kern.smp.maxid thank you for clarifying. Sean From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 20:57:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F10106567A for ; Tue, 28 Sep 2010 20:57:06 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id EB3C18FC0A for ; Tue, 28 Sep 2010 20:57:05 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8SKus7E013562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2010 06:56:55 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o8SKufuT047505; Wed, 29 Sep 2010 06:56:41 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o8SKudBP047504; Wed, 29 Sep 2010 06:56:39 +1000 (EST) (envelope-from peter) Date: Wed, 29 Sep 2010 06:56:39 +1000 From: Peter Jeremy To: Hans Petter Selasky Message-ID: <20100928205639.GA47266@server.vk2pj.dyndns.org> References: <201009271421.42082.hselasky@c2i.net> <20100927153419.13263v44ijw12m4g@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20100927153419.13263v44ijw12m4g@webmail.leidinger.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [USB] Keyboard, mouse and ergonomy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 20:57:06 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Sep-27 15:34:19 +0200, Alexander Leidinger wrote: >Quoting Hans Petter Selasky (from Mon, 27 Sep 2010 =20 >14:21:42 +0200): >> I was thinking about adding a sysctl to ukbd and ums that shows how many >> keypresses have been done and how many pixels you have moved the mouse d= uring >> a day. I agree with Alexander's comments on the usefulness or otherwise of just counting keypresses and mouse pixels. Mouse clicks or number of mouse movements is probably more useful for ergonomics than pixels moved. >Regarding the security: > - don't make this real-time stats, add some artificial delay Delaying the reporting of actual keystroke numbers by several seconds is rather painful. If you want to go this path, either just update the visible count every N seconds (have a callout that triggers every N seconds) or M events (where N or M are configurable and maybe small random numbers). > - make it depending on a compile time knob (disabled > by default) and issue a warning on device attach if > compiled in My personal view is that this is being excessively paranoid. Note that FreeBSD already reports the total number characters read/written via TTY devices. I don't think it's necessary to go as far as compiled-out by default with warnings if enabled - a runtime knob is adequate. Having the sysctl disabled by default and only enabled by root (maybe only readable by root) should be adequate since there are plenty of other mechanisms for root to obtain actual keypress and mouse movement data. --=20 Peter Jeremy --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkyiVocACgkQ/opHv/APuIeyewCeIX9xLWcMI5Z0FOME24zBZEDR jWMAmwWyr6qrluWHnMFg8HxPgWitPbaq =FcUP -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 21:14:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDF8B106566B for ; Tue, 28 Sep 2010 21:14:03 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 536418FC14 for ; Tue, 28 Sep 2010 21:14:02 +0000 (UTC) Received: by wwb17 with SMTP id 17so146668wwb.31 for ; Tue, 28 Sep 2010 14:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=vpudEbN478f0sSislrslp/TFTyRUHtm088WWIVsDQM8=; b=G9ZF3LGdneNGoo9mG7s4VAteOrFSKQFQuUeO3z/drnjz3wq6mcuZLIIzuVda7GrLe9 gqUlxc6SAIWG4cqM2HmhJBpqCcUDAZyzo1V7v95rU4WblDVXkFYJv+b2A/1+lZuyQNDK zBZMp1kfXehbGp3E+GbpXsd5Nh3zG/QgvcgLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=d1vd3ofTYoNP/mWHiz5Jb3cdB2QQsvnaVxkYqsdvFSRevfQHyDYrl/bg/6HmNhqo8n myQGI3MNWet6Ah9GLgaoLywrWv7KQTzPHDI3H099ZLKvoAhWbU6s+K2ECtCFDAlBCqsn tC6l5HZKRdVv2wdUoOcYER/bwlbXb1YM+ZoQo= MIME-Version: 1.0 Received: by 10.227.152.18 with SMTP id e18mr564241wbw.1.1285706570044; Tue, 28 Sep 2010 13:42:50 -0700 (PDT) Sender: giovanni.trematerra@gmail.com Received: by 10.227.144.203 with HTTP; Tue, 28 Sep 2010 13:42:49 -0700 (PDT) Date: Tue, 28 Sep 2010 22:42:49 +0200 X-Google-Sender-Auth: Xy4xbKPUWlBETLO-ml_WSc1JQW4 Message-ID: From: Giovanni Trematerra To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: kernel micro-benchmarking framework X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 21:14:03 -0000 Hi all, based on a work of rwatson@ about micro-benchmarking, I managed to have a kernel module that exposes some sysctls. Reading sysctl associated to test start the benchmark and print the results. The code is split up in this way: test.h, test.c where the infrastructure work lives. test_sync_timing.c test_mem_timing.c where the actual micro-benchmarks live: I wrote some macros to simplify adding more benchmarks. (test.h) The idea is to have a struct for every benchmark/test struct timing_proc { void (*setup)(void *); /* called before starting timing */ void (*test)(void *); /* what we want microbenchmark */ void (*tear_down)(void *); /* called after the end of timing */ void *args; /* pointer passed to the above funcs */ }; and let an agnostic code deals with it. Every test can specify a setup and tear_down function for allocate/deallocate resources and a test function to benchmark things. The great difference with Robert's code is that the test function cannot be inline as it's a pointer to function. I don't know if that could influence the results. The test function is called with interrupt disabled. We could further extent this framework to add regression test support. You could get the code here: http://www.trematerra.net/patches/timing.tbz Feedback and reviews are welcome. Thanks -- Gianni From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 22:00:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F67B106564A; Tue, 28 Sep 2010 22:00:27 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8CBB38FC08; Tue, 28 Sep 2010 22:00:26 +0000 (UTC) Received: by wwb17 with SMTP id 17so206939wwb.31 for ; Tue, 28 Sep 2010 15:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=E6aK6drnxIYdsyqyb/Swg7CkW9aRvBNATqZ5mXEHcEw=; b=rKgV4VZaW8KOZBSsMW7WUU1Baw4xNZwgBLVfG9iZI8XYAe+zyxJki8pDKfx9smZB05 3MlXkfFDXeZHAWEEIZ71HNLTs2SE4p0oSHICUqsTac3BJw+mGvf/PoJX/wUohy6QXgya lBsds3+HWcvanxgGjODD7TDMtzgxDkM6BDjgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=bmS4j83s6QrKfF7YnCKFq5s8QGxy1P2qcispF/FrfrVetkGoHBuRXz76XlkHP7Mldj jpoW6D/Pvg/5urj62Z6PHxMG4mGL/NIXP9mrbcHJhmT8HBPUe6FEcm3BtwlP9Yt8pw+T ukpgVVSmj1mvPxS0EcoAoJs883dmfcEZ8kqQg= Received: by 10.227.32.147 with SMTP id c19mr561383wbd.43.1285708095170; Tue, 28 Sep 2010 14:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Tue, 28 Sep 2010 14:07:54 -0700 (PDT) In-Reply-To: <4C99A53E.7060707@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> From: Renato Botelho Date: Tue, 28 Sep 2010 18:07:54 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: perl@freebsd.org, freebsd-current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 22:00:27 -0000 On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric wrote: > Hi, > > As of r212979, you should now be able to build world and kernel on i386 > and amd64 with clang, without any additional patches! > > To do so, make sure you have updated your installed world to at least > r212904 (which has the most recently imported clang/llvm snapshot), and > put the following in /etc/src.conf: > > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > # Don't die on warnings > NO_WERROR=3D > WERROR=3D > > Both world and kernel can also be installed, and should run properly, > but please make sure you have a way to revert if anything unexpected > happens. :) =A0Alternatively, just install into a chroot to try it out > from there. > > Some additional information can be found on this wiki page: > > http://wiki.freebsd.org/BuildingFreeBSDWithClang > > Thanks to all the people that made this possible, especially Roman > Divacky, Ed Schouten, Rui Paulo, and of course the clang/llvm > developers. I built my desktop world + kernel with clang, rev. 213247 amd64, it booted perfectly, the only problem i got was something went wrong with a perl module File::Temp. To be sure it's related i'm rebuilding the src (same rev.) with gcc and will take a look if it will back to work. I'll send an email after testing. Just to show, the problem i got with perl was using this code: #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) =3D File::Temp::tempfile(); print "$filename\n"; unlink $filename; with this results: Error in tempfile() using /tmp/XXXXXXXXXX: Tried to get a new temp name different to the previous value 50 times. Something wrong with template?? (/tmp/XXXXXXXXXX) at testes/tmp.pl line 5 Regards --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 22:24:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561731065673; Tue, 28 Sep 2010 22:24:36 +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 2ACC18FC14; Tue, 28 Sep 2010 22:24:36 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 015D646B58; Tue, 28 Sep 2010 18:24:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <1285699244.2454.63.camel@home-yahoo> Date: Tue, 28 Sep 2010 23:24:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1285601161.7245.7.camel@home-yahoo> <1285692311.2454.11.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> <1285699244.2454.63.camel@home-yahoo> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1081) Cc: "freebsd-current@FreeBSD.org" , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 22:24:36 -0000 On 28 Sep 2010, at 19:40, Sean Bruno wrote: >> If you go fully dynamic you should use mp_maxid + 1 rather than = maxcpus. >=20 > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject = some > history here so I can understand why one is "better" than the other? So, unlike maxcpus, mp_maxid is in theory susceptible to races in a = brave new world in which we support hotplug CPUs -- a brave new world = we're not yet ready for, however. If you do use mp_maxid, be aware you = need to add one to get the size of the array -- maxcpus is the number of = CPUs that can be used, whereas mp_maxid is the highest CPU ID (counting = from 0) that is used. Robert= From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 00:02:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FD701065674; Wed, 29 Sep 2010 00:02:52 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 10BCE8FC1A; Wed, 29 Sep 2010 00:02:50 +0000 (UTC) Received: by wyb33 with SMTP id 33so83502wyb.13 for ; Tue, 28 Sep 2010 17:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=dQu3mOSrOqMP+G+YcfZDLPEWQASVH5latsgR4nBvAiY=; b=Ym/z3pVV4o33LpAbHTFRj9jBsbiSeEN7w+3VtlxWCaMPogvZTqe0yz8njlhe5cUlwY qhPnAzICFn9klx3dJW1ba3CyKwWJa8ElmGfqLR6id3Yoct4sXzHQI0oPrFwidPZBcO2O mmHuxGdDKeptK6hswHTFFyuNlG82fPwM5ai3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=q3DB5DeLhHadwvypg2q2UHqf9dB8RDtbX2Vg+nttYwlYX11xtr3807vaQJ1j5TH71l ECnih8im0jcAwBKhf7C8D175FyjkJuQgklOKhMczQBJbD0PKT1HVjpgarm0S88XK14RX Pa/pdhTh7GQCOtA2bwnd6fZAEnpHgO5UlJDVE= Received: by 10.216.23.199 with SMTP id v49mr1778474wev.43.1285718565469; Tue, 28 Sep 2010 17:02:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Tue, 28 Sep 2010 17:02:25 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> From: Renato Botelho Date: Tue, 28 Sep 2010 21:02:25 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: perl@freebsd.org, freebsd-current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 00:02:52 -0000 On Tue, Sep 28, 2010 at 6:07 PM, Renato Botelho wrote: > On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric wrote: >> Hi, >> >> As of r212979, you should now be able to build world and kernel on i386 >> and amd64 with clang, without any additional patches! >> >> To do so, make sure you have updated your installed world to at least >> r212904 (which has the most recently imported clang/llvm snapshot), and >> put the following in /etc/src.conf: >> >> .if !defined(CC) || ${CC} =3D=3D "cc" >> CC=3Dclang >> .endif >> .if !defined(CXX) || ${CXX} =3D=3D "c++" >> CXX=3Dclang++ >> .endif >> # Don't die on warnings >> NO_WERROR=3D >> WERROR=3D >> >> Both world and kernel can also be installed, and should run properly, >> but please make sure you have a way to revert if anything unexpected >> happens. :) =A0Alternatively, just install into a chroot to try it out >> from there. >> >> Some additional information can be found on this wiki page: >> >> http://wiki.freebsd.org/BuildingFreeBSDWithClang >> >> Thanks to all the people that made this possible, especially Roman >> Divacky, Ed Schouten, Rui Paulo, and of course the clang/llvm >> developers. > > I built my desktop world + kernel with clang, rev. 213247 amd64, it > booted perfectly, the only problem i got was something went wrong > with a perl module File::Temp. > > To be sure it's related i'm rebuilding the src (same rev.) with gcc and > will take a look if it will back to work. I'll send an email after testin= g. > > Just to show, the problem i got with perl was using this code: > > #!/usr/bin/perl > > use File::Temp; > > my ( $fh, $filename ) =3D File::Temp::tempfile(); > print "$filename\n"; > unlink $filename; > > with this results: > > Error in tempfile() using /tmp/XXXXXXXXXX: Tried to get a new temp > name different to the previous value 50 times. > Something wrong with template?? (/tmp/XXXXXXXXXX) at testes/tmp.pl line 5 After rebuild world+kernel with gcc and reboot everything back to normal: garga@botelhor:~> perl testes/tmp.pl /tmp/MfmvMiztew garga@botelhor:~> perl testes/tmp.pl /tmp/M4xIxsTxlc I'm using perl-5.12.2_2 --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 00:33:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFA461065674; Wed, 29 Sep 2010 00:33:07 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA7F8FC17; Wed, 29 Sep 2010 00:33:06 +0000 (UTC) Received: by wwb17 with SMTP id 17so353554wwb.31 for ; Tue, 28 Sep 2010 17:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=V1rNRY4Xq3WOGnKZxz/iWVYmGVq6Q5BpyrwPsTCKw0k=; b=R+aI71U0OMo/oV6gDNwJiYxJwx5SoA8MN2O+TvhAxIy+G6JFIQX3KbUOGqhoOGmvK6 zorTlmscE/BznFCi59ogOYngq++KLtG1a9uUhO2YsWmwlleQ0yDBipauojduXyjGF03C qTEZ1kJQugqFUFP2SY3BNlkwyOePXXubdK8Kc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=RJRLez0C/OoKo55t8qmPENAc9jUW/rrPF87hdXq5fCXgDncgJz0+0VhPknx8yPbDL+ 0bg1N3FSoQBzh87OZPPSV5NWWjEVa2cbINpYqTXwFzRgoL2IYaJABLMF7uf/V5CR6v02 /uW02oYUY01wAknw/VuRtDLRI2WKfMkgGAzXM= Received: by 10.216.165.16 with SMTP id d16mr721428wel.0.1285720385652; Tue, 28 Sep 2010 17:33:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Tue, 28 Sep 2010 17:32:45 -0700 (PDT) In-Reply-To: <20100929002843.GA5001@oriental.arm.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> From: Renato Botelho Date: Tue, 28 Sep 2010 21:32:45 -0300 Message-ID: To: dlt@mebtel.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 00:33:07 -0000 On Tue, Sep 28, 2010 at 9:28 PM, Derek Tattersall wrote: > * Renato Botelho [100928 20:20]: >> On Tue, Sep 28, 2010 at 6:07 PM, Renato Botelho wrot= e: >> > On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric wrot= e: >> >> Hi, >> >> >> >> As of r212979, you should now be able to build world and kernel on i3= 86 >> >> and amd64 with clang, without any additional patches! >> >> >> >> To do so, make sure you have updated your installed world to at least >> >> r212904 (which has the most recently imported clang/llvm snapshot), a= nd >> >> put the following in /etc/src.conf: >> >> >> >> .if !defined(CC) || ${CC} =3D=3D "cc" >> >> CC=3Dclang >> >> .endif >> >> .if !defined(CXX) || ${CXX} =3D=3D "c++" >> >> CXX=3Dclang++ >> >> .endif >> >> # Don't die on warnings >> >> NO_WERROR=3D >> >> WERROR=3D >> >> >> >> Both world and kernel can also be installed, and should run properly, >> >> but please make sure you have a way to revert if anything unexpected >> >> happens. :) ?Alternatively, just install into a chroot to try it out >> >> from there. >> >> >> >> Some additional information can be found on this wiki page: >> >> >> >> http://wiki.freebsd.org/BuildingFreeBSDWithClang >> >> >> >> Thanks to all the people that made this possible, especially Roman >> >> Divacky, Ed Schouten, Rui Paulo, and of course the clang/llvm >> >> developers. >> > >> > I built my desktop world + kernel with clang, rev. 213247 amd64, it >> > booted perfectly, the only problem i got was something went wrong >> > with a perl module File::Temp. >> > >> > To be sure it's related i'm rebuilding the src (same rev.) with gcc an= d >> > will take a look if it will back to work. I'll send an email after tes= ting. >> > >> > Just to show, the problem i got with perl was using this code: >> > >> > #!/usr/bin/perl >> > >> > use File::Temp; >> > >> > my ( $fh, $filename ) =3D File::Temp::tempfile(); >> > print "$filename\n"; >> > unlink $filename; >> > >> > with this results: >> > >> > Error in tempfile() using /tmp/XXXXXXXXXX: Tried to get a new temp >> > name different to the previous value 50 times. >> > Something wrong with template?? (/tmp/XXXXXXXXXX) at testes/tmp.pl lin= e 5 >> >> After rebuild world+kernel with gcc and reboot everything >> back to normal: >> >> garga@botelhor:~> perl testes/tmp.pl >> /tmp/MfmvMiztew >> garga@botelhor:~> perl testes/tmp.pl >> /tmp/M4xIxsTxlc >> >> I'm using perl-5.12.2_2 >> >> -- >> Renato Botelho >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > A test shell script using mktemp (1) works fine on current built with > clang today. =A0The clang case produces a filename with all "A"'s rather > than the random letters expected. I didn't test mktemp, but my perl test code generate files with all 'A' just after i reboot the machine with clang, after few minutes it stop working and give the error I reported. Please let me know if there is any kind of information I can send to help fixing this. --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 00:41:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F25A106564A; Wed, 29 Sep 2010 00:41:15 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail960c35.nsolutionszone.com (mail960c35.nsolutionszone.com [209.235.152.150]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9068FC08; Wed, 29 Sep 2010 00:41:14 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail960c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o8T0SiYE026339; Wed, 29 Sep 2010 00:28:45 GMT Date: Tue, 28 Sep 2010 20:28:43 -0400 From: Derek Tattersall To: Renato Botelho Message-ID: <20100929002843.GA5001@oriental.arm.org> References: <4C99A53E.7060707@FreeBSD.org> 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) X-CSC: 0 X-CHA: v=1.1 cv=iIcw97Q+eQ1D81EQALF4mu53sRtfq8vPcYUIyeuB6hU= c=1 sm=1 a=BUHArxkelXkA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=9QuQ-5rec9QtRV4NTe4A:9 a=G1ZOs2pcQWJnwTWVD-EA:7 a=AcyVgBPn52d8dNr3FGGaKD0DCmkA:4 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 00:41:15 -0000 * Renato Botelho [100928 20:20]: > On Tue, Sep 28, 2010 at 6:07 PM, Renato Botelho wrote: > > On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric wrote: > >> Hi, > >> > >> As of r212979, you should now be able to build world and kernel on i386 > >> and amd64 with clang, without any additional patches! > >> > >> To do so, make sure you have updated your installed world to at least > >> r212904 (which has the most recently imported clang/llvm snapshot), and > >> put the following in /etc/src.conf: > >> > >> .if !defined(CC) || ${CC} == "cc" > >> CC=clang > >> .endif > >> .if !defined(CXX) || ${CXX} == "c++" > >> CXX=clang++ > >> .endif > >> # Don't die on warnings > >> NO_WERROR= > >> WERROR= > >> > >> Both world and kernel can also be installed, and should run properly, > >> but please make sure you have a way to revert if anything unexpected > >> happens. :) ?Alternatively, just install into a chroot to try it out > >> from there. > >> > >> Some additional information can be found on this wiki page: > >> > >> http://wiki.freebsd.org/BuildingFreeBSDWithClang > >> > >> Thanks to all the people that made this possible, especially Roman > >> Divacky, Ed Schouten, Rui Paulo, and of course the clang/llvm > >> developers. > > > > I built my desktop world + kernel with clang, rev. 213247 amd64, it > > booted perfectly, the only problem i got was something went wrong > > with a perl module File::Temp. > > > > To be sure it's related i'm rebuilding the src (same rev.) with gcc and > > will take a look if it will back to work. I'll send an email after testing. > > > > Just to show, the problem i got with perl was using this code: > > > > #!/usr/bin/perl > > > > use File::Temp; > > > > my ( $fh, $filename ) = File::Temp::tempfile(); > > print "$filename\n"; > > unlink $filename; > > > > with this results: > > > > Error in tempfile() using /tmp/XXXXXXXXXX: Tried to get a new temp > > name different to the previous value 50 times. > > Something wrong with template?? (/tmp/XXXXXXXXXX) at testes/tmp.pl line 5 > > After rebuild world+kernel with gcc and reboot everything > back to normal: > > garga@botelhor:~> perl testes/tmp.pl > /tmp/MfmvMiztew > garga@botelhor:~> perl testes/tmp.pl > /tmp/M4xIxsTxlc > > I'm using perl-5.12.2_2 > > -- > Renato Botelho > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" A test shell script using mktemp (1) works fine on current built with clang today. The clang case produces a filename with all "A"'s rather than the random letters expected. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 01:22:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5BC81065792 for ; Wed, 29 Sep 2010 01:22:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8DF8FC15 for ; Wed, 29 Sep 2010 01:22:10 +0000 (UTC) Received: by iwn34 with SMTP id 34so452505iwn.13 for ; Tue, 28 Sep 2010 18:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=G6F2MB6pof8Pgwyfd8BeV4BeWTiibUOJBRkZnA7kpgI=; b=mXHYCyrul9XqT19Raq3OvZr1nEbNFEM+np3mbbInkuvRjMPYaJzQMWBZxNGbC9TQ/2 XWOkLk0ZrNrwdPhJGl04mq/I9O1gNwo/Q5xXs3bW2rMWFJDHAHeknS/rdB2L9kII/ict n4d4mqsiJkT+TEqrORvdtRgde2+Vi9oWGZ9Ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=V8Z6MEbF/0/7Kx0p6tykEcuLGPZvwLmrKE73DyqmWV/DD3xFqhkbYfRz+YTdbnxpF6 UCAKP0aQ3KR/J2zg4PViZ9YJXoibxj8Mp0kGo+nIO8sSx67Jo6LqY0x0njSUoCNK1UCk ZKrlkY3pDWlNgs+N8jQ0bxZiN09Mz6975QIko= MIME-Version: 1.0 Received: by 10.231.183.134 with SMTP id cg6mr828152ibb.197.1285723329198; Tue, 28 Sep 2010 18:22:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.156.206 with HTTP; Tue, 28 Sep 2010 18:22:09 -0700 (PDT) In-Reply-To: <201009271421.42082.hselasky@c2i.net> References: <201009271421.42082.hselasky@c2i.net> Date: Wed, 29 Sep 2010 09:22:09 +0800 X-Google-Sender-Auth: c1dn3H6uFX70XAasAQOLcDy3to0 Message-ID: From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [USB] Keyboard, mouse and ergonomy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 01:22:13 -0000 On 27 September 2010 20:21, Hans Petter Selasky wrote: > Hi, > > I was thinking about adding a sysctl to ukbd and ums that shows how many > keypresses have been done and how many pixels you have moved the mouse during > a day. These number will mostly be useful for making ergonomic arguments that > a certain way of working is better than another one. > > Anyone have any comments or input on this? Are there any security concerns > about this? Grab a book or five on ergonomics, UI design and Human/Computer Interaction. Read some of the papers that you can find on what went into say, apple's (earlier) UI design. It's all rather interesting and enlightening. :) As other have said, minimising keypresses/mouse movements isn't 1:1 correlated with "better ergonomic design." Adrian From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 06:43:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 655D61065670 for ; Wed, 29 Sep 2010 06:43:26 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 252118FC13 for ; Wed, 29 Sep 2010 06:43:26 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 000295C43; Wed, 29 Sep 2010 08:43:24 +0200 (CEST) Message-ID: <4CA2E00D.3080102@FreeBSD.org> Date: Wed, 29 Sep 2010 08:43:25 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: dlt@mebtel.net References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> In-Reply-To: <20100929002843.GA5001@oriental.arm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Renato Botelho , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 06:43:26 -0000 On 2010-09-29 02:28, Derek Tattersall wrote: > A test shell script using mktemp (1) works fine on current built with > clang today. The clang case produces a filename with all "A"'s rather > than the random letters expected. I cannot reproduce this on a system compiled entirely with clang: $ mktemp foo.XXXXXX foo.MyUM5k $ mktemp foo.XXXXXX foo.YidMeT $ mktemp foo.XXXXXX foo.L27Cfz $ mktemp foo.XXXXXX foo.k3haLx ... and so on. Can you post that test script, please? From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 06:56:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADC64106566B for ; Wed, 29 Sep 2010 06:56:39 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7531B8FC19 for ; Wed, 29 Sep 2010 06:56:39 +0000 (UTC) Received: by iwn34 with SMTP id 34so813660iwn.13 for ; Tue, 28 Sep 2010 23:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:cc:content-type; bh=qfWpy2AtTqvLY9YeeKZ33MMvywR/lfcBMlyLKFWSKpU=; b=Uk91vp8UBl7Zb1vd58/eMQphxho05frVBDxNdgpX5Nb9mvKi7CqC/+nssKcEhVtmTu SGwDbNenUbr/JZPa/smTuK4VGnb9doYBfj0dpXpxD8RA/wd1X+ee+2twrUYT6gTwcifY rP/ZMhjK8def0bRQPn5q3tvf3iZbZqOsJBddg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; b=cNDc0xt2IEzFToJqDsaeK07gljkqQXVr8Pe6WgJaITexpYobKFh5tQiGyZ9Ntd2bAH er23i9zmII9TjYNNXdtRYP7BHD+qLp/9+HcEBZbAi5jFxQ+8QAPuSbsnVCncE20NXj7y glrPVH0uB/oOi8W6oeLd4895CYsC19djUIBz4= MIME-Version: 1.0 Received: by 10.231.157.205 with SMTP id c13mr1273492ibx.71.1285743396948; Tue, 28 Sep 2010 23:56:36 -0700 (PDT) Received: by 10.231.31.195 with HTTP; Tue, 28 Sep 2010 23:56:36 -0700 (PDT) In-Reply-To: <4CA2E00D.3080102@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> Date: Wed, 29 Sep 2010 14:56:36 +0800 Message-ID: From: Buganini Content-Type: text/plain; charset=UTF-8 Cc: current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 06:56:39 -0000 mktemp foo.XXXXXX works here but perl's File::Temp is not working when I tried to build editors/openoffice.org-3-devel, I got: Error in tempdir() using /tmp/XXXXXXXXXX: Tried to get a new temp name different to the previous value 50 times. Something wrong with template?? (/tmp/XXXXXXXXXX) at /usr/ports/editors/openoffice.org-3-devel/work/DEV300_m88/solenv/bin/build.pl line 2282 and it seems that openoffice crashes after I make world with clang. (not verified yet) Buganini From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 07:20:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06D0F1065674 for ; Wed, 29 Sep 2010 07:20:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDBA88FC21 for ; Wed, 29 Sep 2010 07:20:01 +0000 (UTC) Received: by mail-iw0-f182.google.com with SMTP id 34so838365iwn.13 for ; Wed, 29 Sep 2010 00:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8sgGqbQTnLa3faqt0Sl1xHSEvhil8qTI9QhatpOTm44=; b=skvZGkVhlCaFTOt5SaVLw6Sw7iIbd0cBvGUh9mjWsiZoXaFOvKyLn4I82LJPUeXRSA on09+YKAJ2DqwLcCdOz2DRVdexqUxn7rYZcksMH4c6+uHHIVj0YdNDh/e0Lh3x0QTqud XyW13s9SjD18SxnFN3WmPzTKano9X89wfnxTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Xa6XsCSkv20KGb8qztTfoBfSGTxOePjo6wXEPk9VmxvpJ8RNwkHOobHKw9Sdm2Voqb nBEWc8Lui+WxxYpUdu6BaDLqcqSMRSg3JSF1ugRCj22mC37fFFYc2P8+jNafHIeJtJDI 3z8qQRXXr3lcgsBwma/I0jaQDlr47+dEjP9+A= MIME-Version: 1.0 Received: by 10.231.11.3 with SMTP id r3mr1305477ibr.53.1285743483136; Tue, 28 Sep 2010 23:58:03 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Tue, 28 Sep 2010 23:58:02 -0700 (PDT) In-Reply-To: <4CA2E00D.3080102@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> Date: Tue, 28 Sep 2010 23:58:02 -0700 X-Google-Sender-Auth: k8jV7aFre57jeJ_FGvMDWMfifQI Message-ID: From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Renato Botelho , dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 07:20:02 -0000 On Tue, Sep 28, 2010 at 11:43 PM, Dimitry Andric wrote: > On 2010-09-29 02:28, Derek Tattersall wrote: >> >> A test shell script using mktemp (1) works fine on current built with >> clang today. =A0The clang case produces a filename with all "A"'s rather >> than the random letters expected. > > I cannot reproduce this on a system compiled entirely with clang: > > $ mktemp foo.XXXXXX > foo.MyUM5k > $ mktemp foo.XXXXXX > foo.YidMeT > $ mktemp foo.XXXXXX > foo.L27Cfz > $ mktemp foo.XXXXXX > foo.k3haLx > > ... and so on. =A0Can you post that test script, please? Please note your CPUTYPE and CFLAGS (for both those that had a problem and those that didn't) there might be some evidence in there that would help to resolve this issue with clang. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 08:28:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86F87106566B; Wed, 29 Sep 2010 08:28:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 220AC8FC08; Wed, 29 Sep 2010 08:28:44 +0000 (UTC) Received: by qwd6 with SMTP id 6so434422qwd.13 for ; Wed, 29 Sep 2010 01:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=r0mq1Ep7QBUjnbRTStJF8pxeksUC1tELp2UOBIhCu80=; b=wkzEfEeotMzuXC3Y4dyts3eTk3w2hgxrZ+1f7D/6S+WOlj+lE4lCygowpxCHaJR3yO lt9FGqd6ke116276CKfMMIm4cU944QzRDqFNcAKEYdgwRbeV4JO2Ll0WXJWOX4/AddcI jDMpjQTbUTUKlafiqa60hdYHOlbnkvAKswow4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xXOAxu0dRSZw7zinGg5cPY6yQOApCxmYIhg2SQfnA5Jk0DSiGGyc1TZRD4e78hBrPR HiRsvgEnC6K7d6x4jDadQ0/RWhbYfc/CXd7UB1i1d9bHWV3HkE6stdAOsjm2935WEVaY GeMkz+vO4IGUOrT7pTeTgRr+JcPeLnz+rVEvM= MIME-Version: 1.0 Received: by 10.229.224.137 with SMTP id io9mr941125qcb.206.1285748924152; Wed, 29 Sep 2010 01:28:44 -0700 (PDT) Received: by 10.229.50.8 with HTTP; Wed, 29 Sep 2010 01:28:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Sep 2010 12:28:44 +0400 Message-ID: From: Sergey Kandaurov To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ryan Stone , FreeBSD Current , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 08:28:45 -0000 [just don't know what namely need to test, so] All made according to your instructions. The only way I could trigger netdump was to run its ddb command by hand. Neither debug.kdb.enter nor debug.kdb.panic don't do it. Some numbers and output (bit verbose but again don't know what need to show here) Entered through debug.kdb.panic, thus Panicstring. db> netdump ----------------------------------- netdump in progress. searching for server.. dumping to xx.xxx.xx.xx (00:1a:64:d3:4f:20) ----------------------------------- Physical memory: 2026 MB Dumping 1154 MB: 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Dump complete netdump finished. cancelling normal dump # ls -hl /home/fooserv/crash/ total 1182930 -rw-r--r-- 1 root wheel 404B Sep 29 12:05 info.fooserv.0 -rw-r--r-- 1 root wheel 1.1G Sep 29 12:05 vmcore.fooserv.0 Dump from fooserv [xx.xxx.xx.xx] Architecture: amd64 Architecture version: 2 Dump length: 1210687488B (1154 MB) blocksize: 8192 Dumptime: Wed Sep 29 11:55:30 2010 Hostname: fooserv Versionstring: FreeBSD 9.0-CURRENT #51: Wed Sep 29 07:18:24 UTC 2010 root@fooserv:/usr/obj/usr/src/sys/GENERIC Panicstring: kdb_sysctl_panic Header parity check: Pass Dump complete I tried to netdump a bit later again, but it couldn't find server, which runs though, and client traffic was seen on server-side (w/o reply). db> netdump ----------------------------------- netdump in progress. searching for server.. . . . . . . . . . . . Failed to contact netdump server As for netdumpserv, it misses #include before __FBSDID(); I happily tested it on 7.3-amd64. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 08:50:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F533106566C; Wed, 29 Sep 2010 08:50:19 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 11CC18FC08; Wed, 29 Sep 2010 08:50:18 +0000 (UTC) Received: by iwn34 with SMTP id 34so943753iwn.13 for ; Wed, 29 Sep 2010 01:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cHe/GUoLZR9jOfPu1Fsvx5KGs0EY6hwkh3NNeExsSu8=; b=UyAUIw29VoNK/KoaIgeJ+EY+vFmmjA0DbmgpEbMbhiWZBvcoS2cBthWxU8MlWmsAab hr/Y7PGdGEoj2brgGS5nlo/bSjKEuQTowPcUd9ffQwIm6u46jWV23J/M6qKfWsbDDwY8 HRXbGC45BGsYwWJfYWV4zpI6xJypBEqQSy8x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=t/na1nEvmqUqGeC5tfroZG5Q2O+W1DksJgq3EB255K3lQrbvncbMJpm7uHMQ9ORfRL Ba5AgonjCQD1h9v8vgqWxA4jV4Cap+Etdj39F9EYKlTJqN4i58DqPdvKFpMk+3w7Dvmq OYE2EPAxWKXmYWzhFPz80YID2evq9au6L8tCs= MIME-Version: 1.0 Received: by 10.231.146.134 with SMTP id h6mr1349291ibv.170.1285748758985; Wed, 29 Sep 2010 01:25:58 -0700 (PDT) Received: by 10.231.158.145 with HTTP; Wed, 29 Sep 2010 01:25:58 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> Date: Wed, 29 Sep 2010 10:25:58 +0200 Message-ID: From: Daniel Nebdal To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Renato Botelho , dlt@mebtel.net, Dimitry Andric Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 08:50:19 -0000 On Wed, Sep 29, 2010 at 8:58 AM, Garrett Cooper wrote= : > On Tue, Sep 28, 2010 at 11:43 PM, Dimitry Andric wrote: >> On 2010-09-29 02:28, Derek Tattersall wrote: >>> >>> A test shell script using mktemp (1) works fine on current built with >>> clang today. =A0The clang case produces a filename with all "A"'s rathe= r >>> than the random letters expected. >> >> I cannot reproduce this on a system compiled entirely with clang: >> >> $ mktemp foo.XXXXXX >> foo.MyUM5k >> $ mktemp foo.XXXXXX >> foo.YidMeT >> $ mktemp foo.XXXXXX >> foo.L27Cfz >> $ mktemp foo.XXXXXX >> foo.k3haLx >> >> ... and so on. =A0Can you post that test script, please? > > Please note your CPUTYPE and CFLAGS (for both those that had a problem > and those that didn't) there might be some evidence in there that > would help to resolve this issue with clang. > Thanks, > -Garrett Works for me with random names; tested with the File::Temp script posted earlier. Amd64 on a Core2-family Xeon. In a make buildenv - environment I have CPUTYPE=3D'', and no CFLAGS set. As for version, err. I csup-ed the code on Sep 24, and VERSION is 'FreeBSD 9.0-CURRENT amd64 900021' . How do you find the r-number anyway? I can grab today's version and see if it still works for me. If it matters, the process was buildworld with gcc, installworld, buildworld with clang, installworld. -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 10:31:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 009F71065670 for ; Wed, 29 Sep 2010 10:31:49 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7792A8FC1F for ; Wed, 29 Sep 2010 10:31:48 +0000 (UTC) Received: by wyb32 with SMTP id 32so66485wyb.13 for ; Wed, 29 Sep 2010 03:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=SXLWbI7kHqofsuMMELh8O+hoAGDf5d6L0agUoy4QuJ0=; b=nd1GvM6HTjytTbIbHaivwXBBXC8EX6dgVnMD38BSLMNkGiImGUt9eiEo/UBI/A8SWj cvecSWsMd5+hDKOb53/tx3W5J5rl19jBlAh/qN6WVbNWIny48/z7ieOU+hY00AC35jXi Bq2omaBqlvEO3pk/UKF73dxLL1aO6v5xo9epE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; b=UdXO10/kamnU2VsFHzSNa1LEp5Q4QJ/yvN0c4kTTNa+3YGK4YWXAAZIfGT9n3sWsOz EZfDewhkfoYF4z4DFF1cdL/lHJ25sKnIb+QRMXKgkFs9fbvifyGq9y3+Kii/I4nqZWWV pJILGBYduWkUv6GX3xwrfxg00CVrCaZHptw/8= Received: by 10.227.137.81 with SMTP id v17mr1300127wbt.10.1285754880786; Wed, 29 Sep 2010 03:08:00 -0700 (PDT) Received: from dragon.dg (41-132-25-181.dsl.mweb.co.za [41.132.25.181]) by mx.google.com with ESMTPS id h29sm398434wbc.9.2010.09.29.03.07.58 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 03:07:59 -0700 (PDT) From: David Naylor Organization: Private To: mav@freebsd.org, "freebsd-current@freebsd.org" Date: Wed, 29 Sep 2010 12:07:49 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4545071.yrN6f6FqUE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009291207.53146.naylor.b.david@gmail.com> Cc: Subject: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 10:31:49 -0000 --nextPart4545071.yrN6f6FqUE Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails with ``pan= ic:=20 No usable event timer found!''. This occurs on two (all my) machines. Thi= s=20 has been a persistent problem since the introduction of the event timer cod= e. =20 Safe-mode does work with an i386 kernel on the machines. =20 Regards, David --nextPart4545071.yrN6f6FqUE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkyjD/kACgkQUaaFgP9pFrKwuQCfUdvVjhC99+FOZI9r7J1NmW8l +MQAoIZ1vJcxoU/CkOxDFfaRJ3BM4RO6 =+R4n -----END PGP SIGNATURE----- --nextPart4545071.yrN6f6FqUE-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 10:34:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 602471065672 for ; Wed, 29 Sep 2010 10:34:12 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3498FC20 for ; Wed, 29 Sep 2010 10:34:11 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1P0tzG-0002XU-MQ; Wed, 29 Sep 2010 11:34:10 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1P0tzG-00075b-H0; Wed, 29 Sep 2010 11:34:10 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o8TAYAsq068517; Wed, 29 Sep 2010 11:34:10 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: from localhost (mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) with ESMTP id o8TAY9xm068513; Wed, 29 Sep 2010 11:34:09 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Date: Wed, 29 Sep 2010 11:34:09 +0100 (BST) From: Anton Shterenlikht To: John Baldwin In-Reply-To: <201009271120.36337.jhb@freebsd.org> Message-ID: References: <20100925195334.GA58609@mech-cluster241.men.bris.ac.uk> <201009271120.36337.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: amd64 panic: lock (sleep mutex) ral0 not locked @ /usr/src/sys/dev/ral/rt2560.c:2012 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 10:34:12 -0000 On Mon, 27 Sep 2010, John Baldwin wrote: > On Saturday, September 25, 2010 3:53:34 pm Anton Shterenlikht wrote: >> On amd64 r213168 I've a ral(4) CardBus >> wireless device of obscure origin. >> It is identified as >> >> db> bt >> Tracing pid 0 tid 100068 td 0xffffff0001b59440 >> kbd_enter() at kbd_enter+0x3d >> panic() at panic+0x17b >> witness_unlock() at witness_unlock+0x297 >> _mtx_unlock_flags() at _mtx_unlock_flags+0x7e >> rt2560_ioctl() at rt2560_ioctl+0xbf >> taskqueue_run() at taskqueue_run+0x63 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x54 >> fork_exit() at fork_exit+0x12a >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip 0, rsp=0xffffff80b2d41cf0, rbp = 0 --- > > This will likely fix your panic, but I think the card is likely to still not > work: > > Index: rt2560.c > =================================================================== > --- rt2560.c (revision 212900) > +++ rt2560.c (working copy) > @@ -2667,8 +2667,7 @@ > RAL_WRITE(sc, RT2560_CSR1, RT2560_HOST_READY); > > if (rt2560_bbp_init(sc) != 0) { > - rt2560_stop(sc); > - RAL_UNLOCK(sc); > + rt2560_stop_locked(sc); > return; > } > John, You are right, the panic has got away, but the card doesn't seem to work. After issuing "ifconfig wlan0 up scan" I just get lots of ral0: could not read from BBP ral0: timeout waiting for BBP messages on the console. Shall I give up on this particular device? many thanks anton From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 10:41:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0C2E106564A for ; Wed, 29 Sep 2010 10:41:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 490F08FC24 for ; Wed, 29 Sep 2010 10:41:14 +0000 (UTC) Received: by bwz15 with SMTP id 15so538101bwz.13 for ; Wed, 29 Sep 2010 03:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=4fexJy8d3gtW1AYTs8snsLCslHiDYJILiGWRO3voDf0=; b=lSLf6V1pgdafFTusvpAhEFxj1KiXCDMVfVkKFtjC79YYLk/73V5ps6BFVShe0qkRcj pXe2M70EsJNeY58Mtk131q9nYdWlIGXLVX/ab92nY8rBH+lNtZbwg6semmVmsp1uywQ4 Iio6FLysAmK4vvtU8+xUci8JkNNzVX6nkB9zI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=kNvmCxRTzrV8O6gS/tGkEut69AID9tASjux4mTpgTsGHKS4g9r8nS5LwU6lhnmzcZz LuzD42vZzAdBHJ3K8rtVcVi8ftjwghqVduzwOdv2G8/E7jW9wZf2J34LYXJRRWfpwePg bc6DwXcplOOujTAIhc5zBBAZqoXveMvUe6NkA= Received: by 10.204.54.196 with SMTP id r4mr52790bkg.5.1285756873620; Wed, 29 Sep 2010 03:41:13 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d27sm6541736bku.22.2010.09.29.03.41.11 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 03:41:12 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA317BA.8070903@FreeBSD.org> Date: Wed, 29 Sep 2010 13:40:58 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Naylor References: <201009291207.53146.naylor.b.david@gmail.com> In-Reply-To: <201009291207.53146.naylor.b.david@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 10:41:15 -0000 Hi. David Naylor wrote: > Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails with ``panic: > No usable event timer found!''. This occurs on two (all my) machines. This > has been a persistent problem since the introduction of the event timer code. I've reproduced the problem. The reason is that all (or at least most) of devices (both PCI and ISA), including only available in that mode i8254 and RTC timers, failed to allocate their interrupts. While reported message is indeed related to event timer code, problem IMHO doesn't. While without this panic system could boot without any alive timer, I have doubts that it would be functional without timers, USB, network and disk controllers. Problems seems to be the same if I am trying to boot without ACPI. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:24:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035BF1065673; Wed, 29 Sep 2010 11:24:05 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 66DDB8FC19; Wed, 29 Sep 2010 11:24:04 +0000 (UTC) Received: by wyb32 with SMTP id 32so114682wyb.13 for ; Wed, 29 Sep 2010 04:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=I9QKiGuy4G7gBGksKw6zWtNZUulBIRCEqtQCvE98y90=; b=p5NtTIIi09+dIX6DMuD8so3JjffilTe4N/VxKxHEwoAZwgCGbQlr46xFCQGuf5k6Y2 qT7cE7YiiNxHURH4TqnlCUaTbnRYG9Yiku4gHPLxKeMdxGjt2HQ7itl6zofqlpxkY2x9 zryy4otiw3jRcPm7mfM8CVj/55Jhm5oJlHKiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=efCUhGdl4RKia8mj4OxT+TRnzKoymWaKRtzyfI7kqzTby8SLU9Pt7sfxC0UXeT6Wy+ k5sfshHyfTcX20jiCCaoTDQQx3CgOOcFGLuYRGw8h6jgFTdGaPGv4qJo07mP4HO16p68 MnkuKcUTlZ4N0K0pd2c7sBngPyikhsP2COydU= Received: by 10.227.142.132 with SMTP id q4mr1323091wbu.90.1285759443227; Wed, 29 Sep 2010 04:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 04:23:41 -0700 (PDT) In-Reply-To: <4CA2E00D.3080102@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 08:23:41 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:24:05 -0000 On Wed, Sep 29, 2010 at 3:43 AM, Dimitry Andric wrote: > On 2010-09-29 02:28, Derek Tattersall wrote: >> >> A test shell script using mktemp (1) works fine on current built with >> clang today. =A0The clang case produces a filename with all "A"'s rather >> than the random letters expected. > > I cannot reproduce this on a system compiled entirely with clang: > > $ mktemp foo.XXXXXX > foo.MyUM5k > $ mktemp foo.XXXXXX > foo.YidMeT > $ mktemp foo.XXXXXX > foo.L27Cfz > $ mktemp foo.XXXXXX > foo.k3haLx > > ... and so on. =A0Can you post that test script, please? > I'm using perl 5.12.2_2 and this is the code to reproduce the problem. I didn't tested with other perl versions because it's a hard task to move to another perl. #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) =3D File::Temp::tempfile(); print "$filename\n"; --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:25:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1902106564A; Wed, 29 Sep 2010 11:25:39 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 51F618FC19; Wed, 29 Sep 2010 11:25:38 +0000 (UTC) Received: by wwd20 with SMTP id 20so54949wwd.1 for ; Wed, 29 Sep 2010 04:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=lJB+aL7AZiLCByNnwc3D7hrrIMYpNDrQP4aGNM9xrT4=; b=uXP7bMp920BW5EXfZjgPm8I6uUr1pD8PYjdWhu0nqdmhzQ0nQCq3bpjtY0wODLbhp8 BsfEJcUY1nMFaIKged8lZV3gCxzxRofc67txo/1dp+d+JDpDk0b0AiNbBUs37ku9Zqnj 2o8yHc8LtsCiByl2vo9B08BcuBuNk9hbhNUIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=lPbQo8aQlKkKPtomKbix0jGeSZibdkc/HucXgl7X5YdZ3JoI8u1un5a2l6+x++tEJ7 QeH4ZepPojXsTB+d3+Fz4OQmdR9YCtWj3/bjkuZHQosXajKyKuqOtgVBQcUMN0yEMTP9 gM7m2crQSzgktj5wYasDP7qboSBTgZU3egu4k= Received: by 10.216.175.83 with SMTP id y61mr1288154wel.30.1285759537870; Wed, 29 Sep 2010 04:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 04:25:17 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 08:25:17 -0300 Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dlt@mebtel.net, Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:25:40 -0000 On Wed, Sep 29, 2010 at 3:58 AM, Garrett Cooper wrote= : > On Tue, Sep 28, 2010 at 11:43 PM, Dimitry Andric wrote: >> On 2010-09-29 02:28, Derek Tattersall wrote: >>> >>> A test shell script using mktemp (1) works fine on current built with >>> clang today. =A0The clang case produces a filename with all "A"'s rathe= r >>> than the random letters expected. >> >> I cannot reproduce this on a system compiled entirely with clang: >> >> $ mktemp foo.XXXXXX >> foo.MyUM5k >> $ mktemp foo.XXXXXX >> foo.YidMeT >> $ mktemp foo.XXXXXX >> foo.L27Cfz >> $ mktemp foo.XXXXXX >> foo.k3haLx >> >> ... and so on. =A0Can you post that test script, please? > > Please note your CPUTYPE and CFLAGS (for both those that had a problem > and those that didn't) there might be some evidence in there that > would help to resolve this issue with clang. I just have this on my src.conf: .if !defined(CC) || ${CC} =3D=3D "cc" CC=3Dclang .endif .if !defined(CXX) || ${CXX} =3D=3D "c++" CXX=3Dclang++ .endif # Don't die on warnings NO_WERROR=3D WERROR=3D --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:26:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4EBB10656AE for ; Wed, 29 Sep 2010 11:26:17 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4988E8FC14 for ; Wed, 29 Sep 2010 11:26:17 +0000 (UTC) Received: by wyb32 with SMTP id 32so116804wyb.13 for ; Wed, 29 Sep 2010 04:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=y3MLYorxtsI9C/odkb7dwc+O2agN1n9D+MTOj0LyL9c=; b=JAcx7bGSCJHqlJYvHycAfdrFbP8dJWmGc2SeUTD7x7B5ZdnC4G9UqvDNr3XNRkyBaG pjDgO34uAmTLP/y4Q2EaSdyQi9/Hz8rpo8dm5AxP7D07udtzqW+/UBtG+cpTORV2QBFN S55XbyKz6v5bybNg7ZjF6gLxBdk3/tAdzhN3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uQJEt9X1gqG/ZN/Lxqt+1WOLV/oYxnuxaebjl9rKXtBAR88LyyijWeuQ8ZAswLkal7 Begf09W+0ra+m86A6N4uBBEx3NizfJE50EmPi/wS8rhGpJ2EQufVI8ljSpw7RWyPILOf sZQcvYK9hVHUnvFEmwNpX1dG5Ad+jnx/bOWSU= Received: by 10.216.17.135 with SMTP id j7mr1224990wej.97.1285759576323; Wed, 29 Sep 2010 04:26:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 04:25:55 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 08:25:55 -0300 Message-ID: To: Buganini Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:26:17 -0000 On Wed, Sep 29, 2010 at 3:56 AM, Buganini wrote: > mktemp foo.XXXXXX works here > but perl's File::Temp is not working > > when I tried to build editors/openoffice.org-3-devel, I got: > Error in tempdir() using /tmp/XXXXXXXXXX: Tried to get a new temp name > different to the previous value 50 times. > Something wrong with template?? (/tmp/XXXXXXXXXX) at > /usr/ports/editors/openoffice.org-3-devel/work/DEV300_m88/solenv/bin/build.pl > line 2282 Exactly thge same way I discovered the problem here. -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:34:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4DAE106566B for ; Wed, 29 Sep 2010 11:34:38 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82E238FC0A for ; Wed, 29 Sep 2010 11:34:38 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 838675C43; Wed, 29 Sep 2010 13:34:37 +0200 (CEST) Message-ID: <4CA3244D.7030907@FreeBSD.org> Date: Wed, 29 Sep 2010 13:34:37 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: Renato Botelho References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:34:38 -0000 On 2010-09-29 13:23, Renato Botelho wrote: > #!/usr/bin/perl > > use File::Temp; > > my ( $fh, $filename ) = File::Temp::tempfile(); > print "$filename\n"; For me it works perfectly, though I am using perl 5.10: $ cat foo.pl #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print "$filename\n"; $ perl -v This is perl, v5.10.1 (*) built for i386-freebsd-64int Copyright 1987-2009, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. $ perl foo.pl /tmp/tv25CPnWhF $ perl foo.pl /tmp/L2UJQ5_JJs $ perl foo.pl /tmp/6ynQYvWIc1 $ perl foo.pl /tmp/Tdpf7PKBMg $ perl foo.pl /tmp/76ir2i1ici $ perl foo.pl /tmp/LhfD0eZgd8 I'll try building perl 5.12 and try it again. Btw, I assume you did *not* rebuild perl with clang, so your perl is still compiled with gcc? From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:37:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A172F1065675; Wed, 29 Sep 2010 11:37:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B5A3F8FC16; Wed, 29 Sep 2010 11:37:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA25590; Wed, 29 Sep 2010 14:37:16 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P0uyJ-0003Tw-PL; Wed, 29 Sep 2010 14:37:15 +0300 Message-ID: <4CA324EB.4040500@icyb.net.ua> Date: Wed, 29 Sep 2010 14:37:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexander Motin References: <201009291207.53146.naylor.b.david@gmail.com> <4CA317BA.8070903@FreeBSD.org> In-Reply-To: <4CA317BA.8070903@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , David Naylor Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:37:18 -0000 on 29/09/2010 13:40 Alexander Motin said the following: > Hi. > > David Naylor wrote: >> Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails with ``panic: >> No usable event timer found!''. This occurs on two (all my) machines. This >> has been a persistent problem since the introduction of the event timer code. > > I've reproduced the problem. > > The reason is that all (or at least most) of devices (both PCI and ISA), > including only available in that mode i8254 and RTC timers, failed to > allocate their interrupts. While reported message is indeed related to > event timer code, problem IMHO doesn't. While without this panic system > could boot without any alive timer, I have doubts that it would be > functional without timers, USB, network and disk controllers. > > Problems seems to be the same if I am trying to boot without ACPI. > It's interesting to see what the "Safe Mode" really is: dup bootsafekey @ = if s" arch-i386" environment? if drop s" acpi_load" unsetenv s" 1" s" hint.acpi.0.disabled" setenv s" 1" s" loader.acpi_disabled_by_user" setenv s" 1" s" hint.apic.0.disabled" setenv then s" 0" s" hw.ata.ata_dma" setenv s" 0" s" hw.ata.atapi_dma" setenv s" 0" s" hw.ata.wc" setenv s" 0" s" hw.eisa_slots" setenv s" 1" s" hint.kbdmux.0.disabled" setenv 0 boot Not sure if disabling ACPI on modern hardware is a good idea. Even more unsure about disabling APIC. Makes me wonder what this could be useful for. Perhaps, these are just leftovers from times were ACPI, APIC (and ATA DMA) were all new and unproven things. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:46:33 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE593106564A; Wed, 29 Sep 2010 11:46:33 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail960c35.nsolutionszone.com (mail960c35.nsolutionszone.com [209.235.152.150]) by mx1.freebsd.org (Postfix) with ESMTP id 518B38FC12; Wed, 29 Sep 2010 11:46:32 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail960c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o8TBkUTm006528; Wed, 29 Sep 2010 11:46:31 GMT Date: Wed, 29 Sep 2010 07:46:30 -0400 From: Derek Tattersall To: Dimitry Andric Message-ID: <20100929114630.GA8359@oriental.arm.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA2E00D.3080102@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-CSC: 0 X-CHA: v=1.1 cv=iIcw97Q+eQ1D81EQALF4mu53sRtfq8vPcYUIyeuB6hU= c=1 sm=1 a=BUHArxkelXkA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=6I5d2MoRAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=pwuoVvFHv6lFRFWPNGQA:9 a=Tpzg-W3jdkbQFCUjGYEGMpvizb0A:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Renato Botelho , current@FreeBSD.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:46:33 -0000 * Dimitry Andric [100929 06:16]: > On 2010-09-29 02:28, Derek Tattersall wrote: > > A test shell script using mktemp (1) works fine on current built with > > clang today. The clang case produces a filename with all "A"'s rather > > than the random letters expected. > > I cannot reproduce this on a system compiled entirely with clang: > > $ mktemp foo.XXXXXX > foo.MyUM5k > $ mktemp foo.XXXXXX > foo.YidMeT > $ mktemp foo.XXXXXX > foo.L27Cfz > $ mktemp foo.XXXXXX > foo.k3haLx > > ... and so on. Can you post that test script, please? I think was ambiguous in description of the test I ran. The mktemp shell script test only had a call to /usr/bin/mktemp. The other case I ran, was Renato's perl script, and it produced the same results as he produced. I haven't had time yet to study the File::Temp code installed by perl 5.12.2. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:49:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0F69106566B; Wed, 29 Sep 2010 11:49:50 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC1D8FC1B; Wed, 29 Sep 2010 11:49:50 +0000 (UTC) Received: by wwb17 with SMTP id 17so862319wwb.31 for ; Wed, 29 Sep 2010 04:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=SAFw8+mhFJ2YGnJp9jptf6rigBUZBJgPuEml3l2Z5hY=; b=qBNBthodccD9euTs1qN1rdN1CRSQ7aid4bfEDYvztETDR9gjwj35WpN01YoU7caCvG pV5/HbuBwD+4Lum4RCwatJeeyif44lAOrG9+VhTjZw30+c6pid9l74J/9aMC6W5jKHQV J+2nLsOdSwmPxRO0YQXTkct1GCQNopQl++pgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=RdWPsMhq1K9E5Flkca5IiP7Dk7Y8OFAekiQwdmUFT+9CgHdypI23UuVAmv5W9c75q0 qyYTAMAurX7rmoR2Uw96H/P+XrZxNX0Sw+Nl2S7DNGWOXn3klrf9aNtL+bVa/q3v2OdG ClY1YloQXzA7x3Nc0JiBBOrfdi1mOWSraK86U= Received: by 10.227.144.2 with SMTP id x2mr1387992wbu.76.1285760989271; Wed, 29 Sep 2010 04:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 04:49:29 -0700 (PDT) In-Reply-To: <4CA3244D.7030907@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 08:49:29 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:49:51 -0000 On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric wrote: > On 2010-09-29 13:23, Renato Botelho wrote: >> >> #!/usr/bin/perl >> >> use File::Temp; >> >> my ( $fh, $filename ) =3D File::Temp::tempfile(); >> print "$filename\n"; > > For me it works perfectly, though I am using perl 5.10: > > $ cat foo.pl > #!/usr/bin/perl > > use File::Temp; > > my ( $fh, $filename ) =3D File::Temp::tempfile(); > print "$filename\n"; > $ perl -v > > This is perl, v5.10.1 (*) built for i386-freebsd-64int > > Copyright 1987-2009, Larry Wall > > Perl may be copied only under the terms of either the Artistic License or > the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". =A0If you have access to = the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > $ perl foo.pl > /tmp/tv25CPnWhF > $ perl foo.pl > /tmp/L2UJQ5_JJs > $ perl foo.pl > /tmp/6ynQYvWIc1 > $ perl foo.pl > /tmp/Tdpf7PKBMg > $ perl foo.pl > /tmp/76ir2i1ici > $ perl foo.pl > /tmp/LhfD0eZgd8 > > I'll try building perl 5.12 and try it again. > > Btw, I assume you did *not* rebuild perl with clang, so your perl is > still compiled with gcc? Correct, i didn't build any port with clang. --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:50:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5BC9106567A; Wed, 29 Sep 2010 11:50:17 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE508FC1A; Wed, 29 Sep 2010 11:50:17 +0000 (UTC) Received: by iwn34 with SMTP id 34so1160069iwn.13 for ; Wed, 29 Sep 2010 04:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+LXiuJ72biJcQXCNe5K6INXXFeklACRhJuDAM0ZzD/k=; b=LxqD7RqBHZPi/zuibcRf97iQB93eJEvBvN5H+s3IknZhshp4oY3HiW0NeZIjhYM6bI bqci5Mt2nVVb3TGXOVP8no7/bHr4+JcIhCMU8gj1Zp6hP6zxuyQJRc6oJcZ4tosb1NYt s41I/BF7HHY7OsIUHlO2FqfFOMq5u5bfuiZ7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g74u2GUGOwfMivfVKRDfoSu2odHZGYkFHNuStJoMqSy3NNEhHSv0as2y7pgbyRdBEu cgqkgerHLMevESibwqTjOlVPhbMf4U6TprojbGz0+6XNU1DAkLVCRXRJ8ePHaa9xHnyP t7lC9ju9u8ud5B1OqvzQ+ZkPAtEiybxo4d0/8= MIME-Version: 1.0 Received: by 10.231.174.84 with SMTP id s20mr1655775ibz.94.1285761016497; Wed, 29 Sep 2010 04:50:16 -0700 (PDT) Received: by 10.231.31.195 with HTTP; Wed, 29 Sep 2010 04:50:15 -0700 (PDT) In-Reply-To: <20100929114630.GA8359@oriental.arm.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <20100929114630.GA8359@oriental.arm.org> Date: Wed, 29 Sep 2010 19:50:15 +0800 Message-ID: From: Buganini To: dlt@mebtel.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Renato Botelho , Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:50:17 -0000 I'm using perl 5.10, on amd64 only enable clang in src.conf no CPU nor CFLAGS settings in src.conf/make.conf so it seems that the problem is perl-version independent? perhaps amd64? On Wed, Sep 29, 2010 at 7:46 PM, Derek Tattersall wrote: > * Dimitry Andric [100929 06:16]: >> On 2010-09-29 02:28, Derek Tattersall wrote: >> > A test shell script using mktemp (1) works fine on current built with >> > clang today. =C2=A0The clang case produces a filename with all "A"'s r= ather >> > than the random letters expected. >> >> I cannot reproduce this on a system compiled entirely with clang: >> >> $ mktemp foo.XXXXXX >> foo.MyUM5k >> $ mktemp foo.XXXXXX >> foo.YidMeT >> $ mktemp foo.XXXXXX >> foo.L27Cfz >> $ mktemp foo.XXXXXX >> foo.k3haLx >> >> ... and so on. =C2=A0Can you post that test script, please? > I think was ambiguous in description of the test I ran. =C2=A0The mktemp > shell script test only had a call to /usr/bin/mktemp. =C2=A0The other cas= e I > ran, was Renato's perl script, and it produced the same results as he > produced. =C2=A0I haven't had time yet to study the File::Temp code insta= lled > by perl 5.12.2. > -- > Best regards, > Derek Tattersall > dlt@mebtel.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dlt666@yahoo.com =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dtatters@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 11:52:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0179010656B3; Wed, 29 Sep 2010 11:52:43 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 631908FC0A; Wed, 29 Sep 2010 11:52:42 +0000 (UTC) Received: by wyb32 with SMTP id 32so145749wyb.13 for ; Wed, 29 Sep 2010 04:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=T06YPDfgFJus2BE0eBAEv7WuprlqSKpCq37mpEZcUT0=; b=hf+F/Lxh+Xm8S4jA6/vUFtdPR1JmKdDKDTsAR/1FF9wF2QY3Q17dXZPYTDztCzXLli nWkc+noPyqEeGlEzDMGzKnsH6nlprMItfQ5zOgsgRy7TwLd6uSO0+Jf70nTVqURNshRi 9jc4pWoTwXUbguz5gIkHcyQueyyYVdjIYlxCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=u2ErOS0LbRJBYnepxxrP1d8K48zpzNkvgrJyjgTA6fppqv4Q4OWKmwFZLmUunC3+0r UL5lyMuqURFjNppJO59qugV6vle5RN0Fv6zDBT1iSz59Ypg5H+zMEjuuJqt6p8mAgEf0 AiYYVPtPbTIU+u65X+3y3A2PPKpRdvJzRd/V4= Received: by 10.216.1.18 with SMTP id 18mr2417038wec.24.1285761161514; Wed, 29 Sep 2010 04:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 04:52:21 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <20100929114630.GA8359@oriental.arm.org> From: Renato Botelho Date: Wed, 29 Sep 2010 08:52:21 -0300 Message-ID: To: Buganini Content-Type: text/plain; charset=ISO-8859-1 Cc: dlt@mebtel.net, Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 11:52:43 -0000 On Wed, Sep 29, 2010 at 8:50 AM, Buganini wrote: > I'm using perl 5.10, on amd64 > only enable clang in src.conf > no CPU nor CFLAGS settings in src.conf/make.conf > > so it seems that the problem is perl-version independent? > perhaps amd64? I didn't test on i386 but it seems to be a problem using world built with clang + perl 5.12. I booted here with kernel built woth clang and keeping world built with gcc and no problems happened. The problem is in some lib. -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 12:13:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF9D106566B; Wed, 29 Sep 2010 12:13:27 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail940c35.nsolutionszone.com (mail940c35.nsolutionszone.com [209.235.152.130]) by mx1.freebsd.org (Postfix) with ESMTP id BC6EF8FC12; Wed, 29 Sep 2010 12:13:26 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail940c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o8TCDNiF021821; Wed, 29 Sep 2010 12:13:24 GMT Date: Wed, 29 Sep 2010 08:13:22 -0400 From: Derek Tattersall To: Garrett Cooper Message-ID: <20100929121322.GB8359@oriental.arm.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> 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) X-CSC: 0 X-CHA: v=1.1 cv=nRMQXXDkJm4awCcx+M7+jmO1Ng3APGd8nKmIJUVj4hw= c=1 sm=1 a=BUHArxkelXkA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=6I5d2MoRAAAA:8 a=hecR6wcIAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=nm8IygaIGxlApHkrXKEA:9 a=FOppOAumkde73fvFNz8A:7 a=QoocVYyCZqIEXIjGsS2t3S4XiboA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Renato Botelho , Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 12:13:27 -0000 * Garrett Cooper [100929 06:16]: > On Tue, Sep 28, 2010 at 11:43 PM, Dimitry Andric wrote: > > On 2010-09-29 02:28, Derek Tattersall wrote: > >> > >> A test shell script using mktemp (1) works fine on current built with > >> clang today. ?The clang case produces a filename with all "A"'s rather > >> than the random letters expected. > > > > I cannot reproduce this on a system compiled entirely with clang: > > > > $ mktemp foo.XXXXXX > > foo.MyUM5k > > $ mktemp foo.XXXXXX > > foo.YidMeT > > $ mktemp foo.XXXXXX > > foo.L27Cfz > > $ mktemp foo.XXXXXX > > foo.k3haLx > > > > ... and so on. ?Can you post that test script, please? > > Please note your CPUTYPE and CFLAGS (for both those that had a problem > and those that didn't) there might be some evidence in there that > would help to resolve this issue with clang. > Thanks, > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" The CPUTYPE and CFLAGS are set as by a GENERIC build. The kernel configuration file is vanilla GENERIC with scsi and PCI ethernet drivers built as modules only. The uname is: FreeBSD oriental.arm.org 9.0-CURRENT FreeBSD 9.0-CURRENT #23: Tue Sep 28 11:06:43 EDT 2010 \ root@oriental.arm.org:/usr/obj/usr/src/sys/ORIENTAL amd64 -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 12:40:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1573106566C; Wed, 29 Sep 2010 12:40:40 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECBA8FC0A; Wed, 29 Sep 2010 12:40:39 +0000 (UTC) Received: by wwb17 with SMTP id 17so923467wwb.31 for ; Wed, 29 Sep 2010 05:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=RLcVWBCMdYIen1TYTj3/8AlaAcsEUWBgE13okMR1Zn8=; b=XTL41m+pi+M63qKRIpZbVoKBCTprz29eaIsp2I0+RpyyOD9ay5NLWXxL5zhrDPHeN0 FR2mtobAgT2BgzGoKceHGnpcxGQw/1QiYGmmXYNeqjtBxIjrBZYpfcH2N2Ctes7uhB6c BYtMsLVRLntwEyux46xbksDrPPznI5VhdhAZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ebCeJrh+zlLQSheDwVXlZwAaY8zorcZDl5JZFcogW7XScUD7bUeYbkeBw/vNF1qP7y nuxYpkAL5IHAS3EXlLofHsn525D7toBlYQUcl1CiAKDH5ur+MEAaNGXbppjSayxCESSa kb35oca9LYMgZFU7wmUXfcj4vXs+8rWh0/T+U= Received: by 10.216.236.226 with SMTP id w76mr1394936weq.7.1285764039151; Wed, 29 Sep 2010 05:40:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 05:40:18 -0700 (PDT) In-Reply-To: <4CA3244D.7030907@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 09:40:18 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 12:40:41 -0000 On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric wrote: > On 2010-09-29 13:23, Renato Botelho wrote: >> >> #!/usr/bin/perl >> >> use File::Temp; >> >> my ( $fh, $filename ) =3D File::Temp::tempfile(); >> print "$filename\n"; > > For me it works perfectly, though I am using perl 5.10: > > $ cat foo.pl > #!/usr/bin/perl > > use File::Temp; > > my ( $fh, $filename ) =3D File::Temp::tempfile(); > print "$filename\n"; > $ perl -v > > This is perl, v5.10.1 (*) built for i386-freebsd-64int > > Copyright 1987-2009, Larry Wall > > Perl may be copied only under the terms of either the Artistic License or > the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". =A0If you have access to = the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > $ perl foo.pl > /tmp/tv25CPnWhF > $ perl foo.pl > /tmp/L2UJQ5_JJs > $ perl foo.pl > /tmp/6ynQYvWIc1 > $ perl foo.pl > /tmp/Tdpf7PKBMg > $ perl foo.pl > /tmp/76ir2i1ici > $ perl foo.pl > /tmp/LhfD0eZgd8 > > I'll try building perl 5.12 and try it again. > > Btw, I assume you did *not* rebuild perl with clang, so your perl is > still compiled with gcc? > Well, I find out where the problem is, now I have my entire system built with gcc. After install libc.so.7 built with clang the problem starts, installing same lib built with gcc the problem stops. How can I debug it to give you more information? --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:17:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B65F1065673; Wed, 29 Sep 2010 13:17:27 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D94858FC14; Wed, 29 Sep 2010 13:17:25 +0000 (UTC) Received: by wwb17 with SMTP id 17so971487wwb.31 for ; Wed, 29 Sep 2010 06:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=zVkPUPI/boG5AhjCXOHfJSX72RmhyoAQ9xFI/OAvCVk=; b=WciGxreZ5g/L8h6v+aTQQjno6vvNpCg8DLZ8+7dfRQauZbiz9XAT0pQ++89yh4ugf5 fa3dN73QD3qfNvQMGY52y2v+OXd0GTrrIBc9f2ly7auNHk3gg+y1dHZM6G6BF8Q6JwuN iRXEGBaG2X9NqeoGw1GTstdb/SMF8igGU+hyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=CwKVZ9LDMGSSfTJ0vjhQ6XU5Uqa1NrkiWGGhyefQ30WFrG+fSMbp1GHC0JR1t+TVSZ wy0/KZpyN/jS5WGuV8pauX4yc/5n5GOA5vUDglUMnhZkXEBoLl5A/EWeuZOirvO9d3zc wcWER79DTI1KRpWkVyS5EZhhyE+r4YUkUjAPw= Received: by 10.216.145.199 with SMTP id p49mr2504785wej.18.1285765955380; Wed, 29 Sep 2010 06:12:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 06:12:13 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 10:12:13 -0300 Message-ID: To: Dimitry Andric Content-Type: multipart/mixed; boundary=0016e6d5094b091776049165b74a X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:17:27 -0000 --0016e6d5094b091776049165b74a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 29, 2010 at 9:40 AM, Renato Botelho wrote: > On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric wrote: >> On 2010-09-29 13:23, Renato Botelho wrote: >>> >>> #!/usr/bin/perl >>> >>> use File::Temp; >>> >>> my ( $fh, $filename ) =3D File::Temp::tempfile(); >>> print "$filename\n"; >> >> For me it works perfectly, though I am using perl 5.10: >> >> $ cat foo.pl >> #!/usr/bin/perl >> >> use File::Temp; >> >> my ( $fh, $filename ) =3D File::Temp::tempfile(); >> print "$filename\n"; >> $ perl -v >> >> This is perl, v5.10.1 (*) built for i386-freebsd-64int >> >> Copyright 1987-2009, Larry Wall >> >> Perl may be copied only under the terms of either the Artistic License o= r >> the >> GNU General Public License, which may be found in the Perl 5 source kit. >> >> Complete documentation for Perl, including FAQ lists, should be found on >> this system using "man perl" or "perldoc perl". =A0If you have access to= the >> Internet, point your browser at http://www.perl.org/, the Perl Home Page= . >> >> $ perl foo.pl >> /tmp/tv25CPnWhF >> $ perl foo.pl >> /tmp/L2UJQ5_JJs >> $ perl foo.pl >> /tmp/6ynQYvWIc1 >> $ perl foo.pl >> /tmp/Tdpf7PKBMg >> $ perl foo.pl >> /tmp/76ir2i1ici >> $ perl foo.pl >> /tmp/LhfD0eZgd8 >> >> I'll try building perl 5.12 and try it again. >> >> Btw, I assume you did *not* rebuild perl with clang, so your perl is >> still compiled with gcc? >> > > Well, I find out where the problem is, now I have my entire > system built with gcc. After install libc.so.7 built with clang > the problem starts, installing same lib built with gcc the > problem stops. > > How can I debug it to give you more information? Re-sending to the list, here is a ktrace using built-with-clang libc.so.7, when the error occours. --=20 Renato Botelho --0016e6d5094b091776049165b74a-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:26:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D44C1065672; Wed, 29 Sep 2010 13:26:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7F28FC35; Wed, 29 Sep 2010 13:26:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CE43746B9B; Wed, 29 Sep 2010 09:26:01 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B26018A04E; Wed, 29 Sep 2010 09:26:00 -0400 (EDT) From: John Baldwin To: "Robert N. M. Watson" Date: Wed, 29 Sep 2010 07:49:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1285601161.7245.7.camel@home-yahoo> <1285699244.2454.63.camel@home-yahoo> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009290749.22669.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 29 Sep 2010 09:26:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: sbruno@freebsd.org, "freebsd-current@FreeBSD.org" , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:26:02 -0000 On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote: > > On 28 Sep 2010, at 19:40, Sean Bruno wrote: > > >> If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. > > > > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some > > history here so I can understand why one is "better" than the other? > > So, unlike maxcpus, mp_maxid is in theory susceptible to races in a brave new world in which we support hotplug CPUs -- a brave new world we're not yet ready for, however. If you do use mp_maxid, be aware you need to add one to get the size of the array -- maxcpus is the number of CPUs that can be used, whereas mp_maxid is the highest CPU ID (counting from 0) that is used. Hmm, I'm not sure that is true. My feeling on mp_maxid is that it is the largest supported CPUID. Platforms that support hotplug would need to set mp_maxid such that it has room for hotpluggable CPUs. You don't want to go reallocate the UMA datastructures for every zone when a CPU is hotplugged for example. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:26:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2788E10656AA for ; Wed, 29 Sep 2010 13:26:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E79538FC3B for ; Wed, 29 Sep 2010 13:26:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9410246BA4; Wed, 29 Sep 2010 09:26:02 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DD87B8A04F; Wed, 29 Sep 2010 09:26:01 -0400 (EDT) From: John Baldwin To: Anton Shterenlikht Date: Wed, 29 Sep 2010 07:56:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100925195334.GA58609@mech-cluster241.men.bris.ac.uk> <201009271120.36337.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009290756.51326.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 29 Sep 2010 09:26:01 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: amd64 panic: lock (sleep mutex) ral0 not locked @ /usr/src/sys/dev/ral/rt2560.c:2012 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:26:03 -0000 On Wednesday, September 29, 2010 6:34:09 am Anton Shterenlikht wrote: > > On Mon, 27 Sep 2010, John Baldwin wrote: > > > On Saturday, September 25, 2010 3:53:34 pm Anton Shterenlikht wrote: > >> On amd64 r213168 I've a ral(4) CardBus > >> wireless device of obscure origin. > >> It is identified as > >> > >> db> bt > >> Tracing pid 0 tid 100068 td 0xffffff0001b59440 > >> kbd_enter() at kbd_enter+0x3d > >> panic() at panic+0x17b > >> witness_unlock() at witness_unlock+0x297 > >> _mtx_unlock_flags() at _mtx_unlock_flags+0x7e > >> rt2560_ioctl() at rt2560_ioctl+0xbf > >> taskqueue_run() at taskqueue_run+0x63 > >> taskqueue_thread_loop() at taskqueue_thread_loop+0x54 > >> fork_exit() at fork_exit+0x12a > >> fork_trampoline() at fork_trampoline+0xe > >> --- trap 0, rip 0, rsp=0xffffff80b2d41cf0, rbp = 0 --- > > > > This will likely fix your panic, but I think the card is likely to still not > > work: > > > > Index: rt2560.c > > =================================================================== > > --- rt2560.c (revision 212900) > > +++ rt2560.c (working copy) > > @@ -2667,8 +2667,7 @@ > > RAL_WRITE(sc, RT2560_CSR1, RT2560_HOST_READY); > > > > if (rt2560_bbp_init(sc) != 0) { > > - rt2560_stop(sc); > > - RAL_UNLOCK(sc); > > + rt2560_stop_locked(sc); > > return; > > } > > > > John, > > You are right, the panic has got away, but > the card doesn't seem to work. After > issuing "ifconfig wlan0 up scan" I just > get lots of > > ral0: could not read from BBP > ral0: timeout waiting for BBP > > messages on the console. > > Shall I give up on this particular device? Unfortunately I can't help with this part. :( I suspect the card is broken however. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:26:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E10B91065693; Wed, 29 Sep 2010 13:26:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE3188FC43; Wed, 29 Sep 2010 13:26:03 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 598C046C08; Wed, 29 Sep 2010 09:26:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A42B98A050; Wed, 29 Sep 2010 09:26:02 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 29 Sep 2010 09:14:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009291207.53146.naylor.b.david@gmail.com> <4CA317BA.8070903@FreeBSD.org> <4CA324EB.4040500@icyb.net.ua> In-Reply-To: <4CA324EB.4040500@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009290914.08513.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 29 Sep 2010 09:26:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Motin , David Naylor , Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:26:04 -0000 On Wednesday, September 29, 2010 7:37:15 am Andriy Gapon wrote: > on 29/09/2010 13:40 Alexander Motin said the following: > > Hi. > > > > David Naylor wrote: > >> Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails with ``panic: > >> No usable event timer found!''. This occurs on two (all my) machines. This > >> has been a persistent problem since the introduction of the event timer code. > > > > I've reproduced the problem. > > > > The reason is that all (or at least most) of devices (both PCI and ISA), > > including only available in that mode i8254 and RTC timers, failed to > > allocate their interrupts. While reported message is indeed related to > > event timer code, problem IMHO doesn't. While without this panic system > > could boot without any alive timer, I have doubts that it would be > > functional without timers, USB, network and disk controllers. > > > > Problems seems to be the same if I am trying to boot without ACPI. Probably the kernel doesn't have 'device atpic' so disabling APIC probably breaks all interrupts. A newer system might only describe APICs via the ACPI MADT table and not provide an MP Table. In that case disabling ACPI would effectively disable APIC leading to the same result. > It's interesting to see what the "Safe Mode" really is: > dup bootsafekey @ = if > s" arch-i386" environment? if > drop > s" acpi_load" unsetenv > s" 1" s" hint.acpi.0.disabled" setenv > s" 1" s" loader.acpi_disabled_by_user" setenv > s" 1" s" hint.apic.0.disabled" setenv > then > s" 0" s" hw.ata.ata_dma" setenv > s" 0" s" hw.ata.atapi_dma" setenv > s" 0" s" hw.ata.wc" setenv > s" 0" s" hw.eisa_slots" setenv > s" 1" s" hint.kbdmux.0.disabled" setenv > 0 boot > > > Not sure if disabling ACPI on modern hardware is a good idea. > Even more unsure about disabling APIC. > > Makes me wonder what this could be useful for. > Perhaps, these are just leftovers from times were ACPI, APIC (and ATA DMA) were > all new and unproven things. Yes, on modern machines I think disabling ACPI and APIC is less safe actually. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:31:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 503B81065674; Wed, 29 Sep 2010 13:31:42 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 88B0C8FC08; Wed, 29 Sep 2010 13:31:41 +0000 (UTC) Received: by wwb17 with SMTP id 17so991502wwb.31 for ; Wed, 29 Sep 2010 06:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=wQvL5bIk8aj6je/0KUEjRWFat1Y2PPhUeg3LA4xA8k4=; b=amkosiI5TrLKFtPA6lN1g5fsPkzoCzisuyn3siyB5Qh5rflo8eWt3IXTErhMgXDDPh WvLD3jq06ZuQ+BRtQW9pbZgkKn7uW/dNew2PDB6msTWQP/1qx494AW8Rd7XYIZAqOY8v jTUeUClzXgUEd9Khyer0qq37pj0BxHNQpiUsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=uWRs6ij1Ve58/ngufX9eYbeFF53/JLrMeh3ZL12+DA37QWQGh0GsL3bdMIXw/poxpp oGiLeBCrw9RFwyn2jqUluSqyVLcsBitN19jpS1gtM0+BQk6oZqVk3bh3RV8LcNia/GwB 2JiBtCVO4bQhSp4TRKuglKjJUt0StHb5+9VVU= Received: by 10.227.138.147 with SMTP id a19mr1504838wbu.93.1285767100469; Wed, 29 Sep 2010 06:31:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 06:31:19 -0700 (PDT) In-Reply-To: References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 10:31:19 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:31:42 -0000 On Wed, Sep 29, 2010 at 10:12 AM, Renato Botelho wrote: > On Wed, Sep 29, 2010 at 9:40 AM, Renato Botelho wrote= : >> On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric wrote: >>> On 2010-09-29 13:23, Renato Botelho wrote: >>>> >>>> #!/usr/bin/perl >>>> >>>> use File::Temp; >>>> >>>> my ( $fh, $filename ) =3D File::Temp::tempfile(); >>>> print "$filename\n"; >>> >>> For me it works perfectly, though I am using perl 5.10: >>> >>> $ cat foo.pl >>> #!/usr/bin/perl >>> >>> use File::Temp; >>> >>> my ( $fh, $filename ) =3D File::Temp::tempfile(); >>> print "$filename\n"; >>> $ perl -v >>> >>> This is perl, v5.10.1 (*) built for i386-freebsd-64int >>> >>> Copyright 1987-2009, Larry Wall >>> >>> Perl may be copied only under the terms of either the Artistic License = or >>> the >>> GNU General Public License, which may be found in the Perl 5 source kit= . >>> >>> Complete documentation for Perl, including FAQ lists, should be found o= n >>> this system using "man perl" or "perldoc perl". =A0If you have access t= o the >>> Internet, point your browser at http://www.perl.org/, the Perl Home Pag= e. >>> >>> $ perl foo.pl >>> /tmp/tv25CPnWhF >>> $ perl foo.pl >>> /tmp/L2UJQ5_JJs >>> $ perl foo.pl >>> /tmp/6ynQYvWIc1 >>> $ perl foo.pl >>> /tmp/Tdpf7PKBMg >>> $ perl foo.pl >>> /tmp/76ir2i1ici >>> $ perl foo.pl >>> /tmp/LhfD0eZgd8 >>> >>> I'll try building perl 5.12 and try it again. >>> >>> Btw, I assume you did *not* rebuild perl with clang, so your perl is >>> still compiled with gcc? >>> >> >> Well, I find out where the problem is, now I have my entire >> system built with gcc. After install libc.so.7 built with clang >> the problem starts, installing same lib built with gcc the >> problem stops. >> >> How can I debug it to give you more information? > > Re-sending to the list, here is a ktrace using built-with-clang > libc.so.7, when the error occours. Seems the list didn't like my attachment, so here is place to get it - http://people.freebsd.org/~garga/ktrace-error.txt.gz --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:32:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2A7210656A3; Wed, 29 Sep 2010 13:32:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 272EC8FC2B; Wed, 29 Sep 2010 13:32:12 +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 QAA27580; Wed, 29 Sep 2010 16:32:10 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CA33FDA.4020001@icyb.net.ua> Date: Wed, 29 Sep 2010 16:32:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Attilio Rao References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ryan Stone , FreeBSD Current , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:32:14 -0000 on 28/09/2010 20:39 Attilio Rao said the following: > In order to work into an "up and running" system (meant as with all > the devices in place) the netdump handler hooks as a pre-sync handler > (differently from other dumping routines). It however suffers some I actually like this idea. I think that regular dump should also be done at that time. Shouldn't we try to dump memory as early as possible, so that as little of it as possible is modified? (Not that I like sync-on-panic option at all) > problems typical of other dumping mechanism. For example, on DDB > entering unlocked version of polling handler is used, in order to > reduce the risk of deadlocks during inspections*. That reflects, among > the netdump methods, the existence of 2 versions of polling hooks, > where the "unlocked" is meant as reducing locking as much as possible. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:48:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2569A1065697; Wed, 29 Sep 2010 13:48:12 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF018FC15; Wed, 29 Sep 2010 13:48:11 +0000 (UTC) Received: by wwb17 with SMTP id 17so1015301wwb.31 for ; Wed, 29 Sep 2010 06:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=+LUREmvxuw2qfOI2Evx+Q35YeOgUAGZr7Uv9AKuBok4=; b=pTnST+EIqTyyR1aG+Urw/QbEksZa8EiKy5/iEzJbimlDd+BN5wzXr58XDixk9PVwXc Y21TdJKfQTtMyfMp0YyUQocUOdvdLpKEVDfsY4zze8s22/MztX1T+oqms8X6PpUM243G gMfhLgip8zOQ6YW61A5mfFAJSNLudCuqAbVQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=phw20MhGuuG3Vuby+guH5Ts/WeorfrhXmWsOE3UOscolTxKsEV6rLuMy/y5RsEjaY+ 3DeavIkpBxC1vHRv4IBGihFFHEdvaB3ZQRsWf7DgRldskt/8Iqi565NRQNBmrVdzUOJr lJcyA0nxAEyjr7RCmUq7qkueFXV+2+yhn9B04= Received: by 10.216.20.18 with SMTP id o18mr1469223weo.31.1285768090249; Wed, 29 Sep 2010 06:48:10 -0700 (PDT) Received: from dragon.dg (41-132-25-181.dsl.mweb.co.za [41.132.25.181]) by mx.google.com with ESMTPS id w1sm5408149weq.25.2010.09.29.06.48.06 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 06:48:09 -0700 (PDT) From: David Naylor Organization: Private To: John Baldwin Date: Wed, 29 Sep 2010 15:47:59 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.4.5; amd64; ; ) References: <201009291207.53146.naylor.b.david@gmail.com> <4CA324EB.4040500@icyb.net.ua> <201009290914.08513.jhb@freebsd.org> In-Reply-To: <201009290914.08513.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1479662.XOgHVrXr09"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009291548.03752.naylor.b.david@gmail.com> Cc: Alexander Motin , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:48:12 -0000 --nextPart1479662.XOgHVrXr09 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday 29 September 2010 15:14:08 John Baldwin wrote: > On Wednesday, September 29, 2010 7:37:15 am Andriy Gapon wrote: > > on 29/09/2010 13:40 Alexander Motin said the following: > > > Hi. > > >=20 > > > David Naylor wrote: > > >> Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails with > > >> ``panic: No usable event timer found!''. This occurs on two (all my) > > >> machines. This has been a persistent problem since the introduction > > >> of the event timer code. > > >=20 > > > I've reproduced the problem. > > >=20 > > > The reason is that all (or at least most) of devices (both PCI and > > > ISA), including only available in that mode i8254 and RTC timers, > > > failed to allocate their interrupts. While reported message is indeed > > > related to event timer code, problem IMHO doesn't. While without this > > > panic system could boot without any alive timer, I have doubts that it > > > would be functional without timers, USB, network and disk controllers. > > >=20 > > > Problems seems to be the same if I am trying to boot without ACPI. >=20 > Probably the kernel doesn't have 'device atpic' so disabling APIC probably > breaks all interrupts. A newer system might only describe APICs via the > ACPI MADT table and not provide an MP Table. In that case disabling ACPI > would effectively disable APIC leading to the same result. Is APIC and ACPI disabled in safe-mode on amd64? =20 This is using GENERIC, perhaps atpic should be added to the config file, or= made=20 mandatory for amd64 systems? =20 > > It's interesting to see what the "Safe Mode" really is: > > dup bootsafekey @ =3D if > >=20 > > s" arch-i386" environment? if > > =20 > > drop > > s" acpi_load" unsetenv > > s" 1" s" hint.acpi.0.disabled" setenv > > s" 1" s" loader.acpi_disabled_by_user" setenv > > s" 1" s" hint.apic.0.disabled" setenv > > =20 > > then > > s" 0" s" hw.ata.ata_dma" setenv > > s" 0" s" hw.ata.atapi_dma" setenv > > s" 0" s" hw.ata.wc" setenv > > s" 0" s" hw.eisa_slots" setenv > > s" 1" s" hint.kbdmux.0.disabled" setenv > > 0 boot > >=20 > > Not sure if disabling ACPI on modern hardware is a good idea. > > Even more unsure about disabling APIC. > >=20 > > Makes me wonder what this could be useful for. > > Perhaps, these are just leftovers from times were ACPI, APIC (and ATA > > DMA) were all new and unproven things. >=20 > Yes, on modern machines I think disabling ACPI and APIC is less safe > actually. --nextPart1479662.XOgHVrXr09 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkyjQ5MACgkQUaaFgP9pFrKR4ACgiAEqZNi3BuJUp53ynSzVGulc 07QAn3I4Yl3Cm7VUSEz0UyVoCjGzFsG6 =0tah -----END PGP SIGNATURE----- --nextPart1479662.XOgHVrXr09-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 13:54:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF0E1065674; Wed, 29 Sep 2010 13:54:24 +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 E99588FC12; Wed, 29 Sep 2010 13:54:23 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 862F346B90; Wed, 29 Sep 2010 09:54:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201009290749.22669.jhb@freebsd.org> Date: Wed, 29 Sep 2010 14:54:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07839A8A-5CC5-47C5-B098-89FE81CA2F3E@freebsd.org> References: <1285601161.7245.7.camel@home-yahoo> <1285699244.2454.63.camel@home-yahoo> <201009290749.22669.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1081) Cc: sbruno@freebsd.org, "freebsd-current@FreeBSD.org" , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:54:24 -0000 On 29 Sep 2010, at 12:49, John Baldwin wrote: > On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote: >>=20 >> On 28 Sep 2010, at 19:40, Sean Bruno wrote: >>=20 >>>> If you go fully dynamic you should use mp_maxid + 1 rather than = maxcpus. >>>=20 >>> I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject = some >>> history here so I can understand why one is "better" than the other? >>=20 >> So, unlike maxcpus, mp_maxid is in theory susceptible to races in a = brave new world in which we support hotplug CPUs -- a brave new world = we're=20 > not yet ready for, however. If you do use mp_maxid, be aware you need = to add one to get the size of the array -- maxcpus is the number of CPUs = that=20 > can be used, whereas mp_maxid is the highest CPU ID (counting from 0) = that is used. >=20 > Hmm, I'm not sure that is true. My feeling on mp_maxid is that it is = the > largest supported CPUID. Platforms that support hotplug would need to = set > mp_maxid such that it has room for hotpluggable CPUs. You don't want = to > go reallocate the UMA datastructures for every zone when a CPU is = hotplugged > for example. Yes, we'll have to break one (or even both) of two current assumptions = with the move to hotplug: contiguous in-use CPU IDs and mp_maxid = representing the greatest possible CPU ID as a constant value. The = former is guaranteed, but I wonder about the latter. On face value, you = might say "oh, we know how many sockets there are", but if course, we = don't know how many threads will arrive when a package is inserted. For = many subsystems, DPCPU will present a more than adequate answer for = avoiding resizing, although not for low-level systems (perhaps such as = UMA?). Likewise, on virtual machine platforms where hotplug actually = might reflect a longer-term scheduling choice by the admin/hypervisor = (i.e., resource partitioning), it may be harder to reason about what the = future holds. Robert= From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 14:07:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E36B5106564A; Wed, 29 Sep 2010 14:07:01 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 95E378FC0C; Wed, 29 Sep 2010 14:07:01 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 323579CB084; Wed, 29 Sep 2010 16:06:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0QtN0ZksjTv; Wed, 29 Sep 2010 16:06:58 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 769009CB12F; Wed, 29 Sep 2010 16:06:58 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o8TE6v0U050944; Wed, 29 Sep 2010 16:06:57 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 29 Sep 2010 16:06:57 +0200 From: Roman Divacky To: Renato Botelho Message-ID: <20100929140657.GA50873@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: dlt@mebtel.net, Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:07:02 -0000 On Wed, Sep 29, 2010 at 09:40:18AM -0300, Renato Botelho wrote: > On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric wrote: > > On 2010-09-29 13:23, Renato Botelho wrote: > >> > >> #!/usr/bin/perl > >> > >> use File::Temp; > >> > >> my ( $fh, $filename ) = File::Temp::tempfile(); > >> print "$filename\n"; > > > > For me it works perfectly, though I am using perl 5.10: > > > > $ cat foo.pl > > #!/usr/bin/perl > > > > use File::Temp; > > > > my ( $fh, $filename ) = File::Temp::tempfile(); > > print "$filename\n"; > > $ perl -v > > > > This is perl, v5.10.1 (*) built for i386-freebsd-64int > > > > Copyright 1987-2009, Larry Wall > > > > Perl may be copied only under the terms of either the Artistic License or > > the > > GNU General Public License, which may be found in the Perl 5 source kit. > > > > Complete documentation for Perl, including FAQ lists, should be found on > > this system using "man perl" or "perldoc perl". ?If you have access to the > > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > > $ perl foo.pl > > /tmp/tv25CPnWhF > > $ perl foo.pl > > /tmp/L2UJQ5_JJs > > $ perl foo.pl > > /tmp/6ynQYvWIc1 > > $ perl foo.pl > > /tmp/Tdpf7PKBMg > > $ perl foo.pl > > /tmp/76ir2i1ici > > $ perl foo.pl > > /tmp/LhfD0eZgd8 > > > > I'll try building perl 5.12 and try it again. > > > > Btw, I assume you did *not* rebuild perl with clang, so your perl is > > still compiled with gcc? > > > > Well, I find out where the problem is, now I have my entire > system built with gcc. After install libc.so.7 built with clang > the problem starts, installing same lib built with gcc the > problem stops. > > How can I debug it to give you more information? renato, can you check if libc compiled with clang -O0 still exhibits the bug? thank you, roman From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 14:14:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 414661065696; Wed, 29 Sep 2010 14:14:10 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CE36F8FC1E; Wed, 29 Sep 2010 14:14:09 +0000 (UTC) Received: by iwn34 with SMTP id 34so1341246iwn.13 for ; Wed, 29 Sep 2010 07:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Yn1wzphc1axe8WeHUjPIO810w2Gw76qRbq1PlwYUmcg=; b=rFpwN5eHMt5zulL0+cz5qiO5u3b2p+FgpX6eQFgsHm6I0NCwgc+Y0re8ZmgM9GIl8z +jcvgA0lfFt9S2K11U+2ZIwTOsoAaQKldKX3vPPn9YSg7B166cy4/RMuohFGV9rDribs C4PmvWGK9xrp7K7n/CWHHVGC2dx8rcp225NPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uAyNMiV9EpXfuEixuqEQXOYt4rRZ5wqbQtP66oewg528NP2jUcUmnboX5z3/n+sZGx Z+jLBNC0dOvdwZxDeGZHk0Q0JD/GyFYbYaAa1R3nKY/NcKFreOYECW08vihTYJgZBmZU J/NE+sfqu88fwtYFv21c/XzxMHZs70BaHwdzw= MIME-Version: 1.0 Received: by 10.231.166.139 with SMTP id m11mr1837744iby.136.1285769649039; Wed, 29 Sep 2010 07:14:09 -0700 (PDT) Received: by 10.231.167.140 with HTTP; Wed, 29 Sep 2010 07:14:08 -0700 (PDT) In-Reply-To: <07839A8A-5CC5-47C5-B098-89FE81CA2F3E@freebsd.org> References: <1285601161.7245.7.camel@home-yahoo> <1285699244.2454.63.camel@home-yahoo> <201009290749.22669.jhb@freebsd.org> <07839A8A-5CC5-47C5-B098-89FE81CA2F3E@freebsd.org> Date: Wed, 29 Sep 2010 14:14:08 +0000 Message-ID: From: Matthew Fleming To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sbruno@freebsd.org, "Robert N. M. Watson" , Joshua Neal Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:14:10 -0000 On Wed, Sep 29, 2010 at 1:54 PM, Robert N. M. Watson wrote: > > On 29 Sep 2010, at 12:49, John Baldwin wrote: > >> On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote: >>> >>> On 28 Sep 2010, at 19:40, Sean Bruno wrote: >>> >>>>> If you go fully dynamic you should use mp_maxid + 1 rather than maxcp= us. >>>> >>>> I assume that mp_maxid is the new kern.smp.maxcpus? =A0Can you inject = some >>>> history here so I can understand why one is "better" than the other? >>> >>> So, unlike maxcpus, mp_maxid is in theory susceptible to races in a bra= ve new world in which we support hotplug CPUs -- a brave new world we're >> not yet ready for, however. If you do use mp_maxid, be aware you need to= add one to get the size of the array -- maxcpus is the number of CPUs that >> can be used, whereas mp_maxid is the highest CPU ID (counting from 0) th= at is used. >> >> Hmm, I'm not sure that is true. =A0My feeling on mp_maxid is that it is = the >> largest supported CPUID. =A0Platforms that support hotplug would need to= set >> mp_maxid such that it has room for hotpluggable CPUs. =A0You don't want = to >> go reallocate the UMA datastructures for every zone when a CPU is hotplu= gged >> for example. > > Yes, we'll have to break one (or even both) of two current assumptions wi= th the move to hotplug: contiguous in-use CPU IDs and mp_maxid representing= the greatest possible CPU ID as a constant value. The former is guaranteed= , but I wonder about the latter. On face value, you might say "oh, we know = how many sockets there are", but if course, we don't know how many threads = will arrive when a package is inserted. =A0For many subsystems, DPCPU will = present a more than adequate answer for avoiding resizing, although not for= low-level systems (perhaps such as UMA?). Likewise, on virtual machine pla= tforms where hotplug actually might reflect a longer-term scheduling choice= by the admin/hypervisor (i.e., resource partitioning), it may be harder to= reason about what the future holds. > As a historical note, when AIX added hotplug CPU support, we kept the MAXCPU define as the largest number of CPUs supported by the OS image. At the time it was 256; as it shifted to 1024 there was a large cleanup effort to eliminate as many statically sized arrays as possible. AIX also has an mp_maxid equivalent which changed when new higher core numbers were used. For various reasons, new CPUs were added only while a single CPU was running, so any loop that looked like (for i =3D 0; i <=3D mp_maxid; i++) could get interrupted by an IPI (the handler spun until the core was added by the coordinating CPU) and find that it had a stale mp_maxid value. This was not a bug in 99% of the uses of the code, since whatever it was doing with each CPU was either not atomic (e.g. summing per-cpu counters) or was some kind of initializing work which was also done by the new CPU before it was fully awake. I don't necessarily recommend this as an architected plan for adding CPUs, but I wanted to offer the historical note that it could work. Also, CPU id's may not be contiguous with hotplug. Even if they are contiguous on boot, there is no reason to assume CPUs are offlined from highest ID down. For reasons of cache sharing, the best performance may be obtained by picking a specific CPU to offline. It also may be that it makes more sense to reserve CPU ids so that e.g. CPUs N*T through N*(2T-1) are all HMT threads on the same core, (for T-way HMT). In this case CPU IDs become sparse if HMT is completely disabled, and the best performance for the box overall is probably obtained by offlining T3 and T2 for each core while keeping T0 and T1 active. But discontiguous IDs shouldn't be a problem as all the code I've seen checks CPU_ABSENT(i) in the loop. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 14:19:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDFE3106564A; Wed, 29 Sep 2010 14:19:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C19988FC13; Wed, 29 Sep 2010 14:19:11 +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 RAA28487; Wed, 29 Sep 2010 17:19:08 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CA34ADC.40309@icyb.net.ua> Date: Wed, 29 Sep 2010 17:19:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Naylor References: <201009291207.53146.naylor.b.david@gmail.com> <4CA324EB.4040500@icyb.net.ua> <201009290914.08513.jhb@freebsd.org> <201009291548.03752.naylor.b.david@gmail.com> In-Reply-To: <201009291548.03752.naylor.b.david@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:19:13 -0000 on 29/09/2010 16:47 David Naylor said the following: > On Wednesday 29 September 2010 15:14:08 John Baldwin wrote: >> On Wednesday, September 29, 2010 7:37:15 am Andriy Gapon wrote: >>> on 29/09/2010 13:40 Alexander Motin said the following: >>>> Hi. >>>> >>>> David Naylor wrote: >>>>> Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails with >>>>> ``panic: No usable event timer found!''. This occurs on two (all my) >>>>> machines. This has been a persistent problem since the introduction >>>>> of the event timer code. >>>> >>>> I've reproduced the problem. >>>> >>>> The reason is that all (or at least most) of devices (both PCI and >>>> ISA), including only available in that mode i8254 and RTC timers, >>>> failed to allocate their interrupts. While reported message is indeed >>>> related to event timer code, problem IMHO doesn't. While without this >>>> panic system could boot without any alive timer, I have doubts that it >>>> would be functional without timers, USB, network and disk controllers. >>>> >>>> Problems seems to be the same if I am trying to boot without ACPI. >> >> Probably the kernel doesn't have 'device atpic' so disabling APIC probably >> breaks all interrupts. A newer system might only describe APICs via the >> ACPI MADT table and not provide an MP Table. In that case disabling ACPI >> would effectively disable APIC leading to the same result. > > Is APIC and ACPI disabled in safe-mode on amd64? Did you notice the code snippet below? Specifically hint.acpi.0.disabled and hint.apic.0.disabled. Don't let "arch-i386" confuse you, it means "x86" in that context. > This is using GENERIC, perhaps atpic should be added to the config file, or made > mandatory for amd64 systems? I don't think so. Especially given that hardware might not support !APIC case at all, even if you have atpic in your kernel. Alternatively, perhaps just don't use this "Safe Mode"? What do you try to actually achieve? >>> It's interesting to see what the "Safe Mode" really is: >>> dup bootsafekey @ = if >>> >>> s" arch-i386" environment? if >>> >>> drop >>> s" acpi_load" unsetenv >>> s" 1" s" hint.acpi.0.disabled" setenv >>> s" 1" s" loader.acpi_disabled_by_user" setenv >>> s" 1" s" hint.apic.0.disabled" setenv >>> >>> then >>> s" 0" s" hw.ata.ata_dma" setenv >>> s" 0" s" hw.ata.atapi_dma" setenv >>> s" 0" s" hw.ata.wc" setenv >>> s" 0" s" hw.eisa_slots" setenv >>> s" 1" s" hint.kbdmux.0.disabled" setenv >>> 0 boot >>> >>> Not sure if disabling ACPI on modern hardware is a good idea. >>> Even more unsure about disabling APIC. >>> >>> Makes me wonder what this could be useful for. >>> Perhaps, these are just leftovers from times were ACPI, APIC (and ATA >>> DMA) were all new and unproven things. >> >> Yes, on modern machines I think disabling ACPI and APIC is less safe >> actually. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 14:32:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D401B106566B; Wed, 29 Sep 2010 14:32:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 964FA8FC16; Wed, 29 Sep 2010 14:32:54 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DB9885C43; Wed, 29 Sep 2010 16:32:53 +0200 (CEST) Message-ID: <4CA34E16.3030003@FreeBSD.org> Date: Wed, 29 Sep 2010 16:32:54 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Kirk McKusick Subject: Soft update panic while running perl 5.12 tests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:32:55 -0000 Hi, I just encountered the following soft update panic while running perl 5.12's tests: panic: indir_trunc: Index out of range -148 parent -2061 lbn -305164 cpuid = 3 KDB: enter: panic [ thread pid 19 tid 100047 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 19 tid 100047 td 0xc72e9b40 kdb_enter(c0cd6a90,c0cd6a90,c0cfe8ab,e6be2b58,3,...) at kdb_enter+0x3a panic(c0cfe8ab,ffffff6c,fffff7f3,ffffffff,fffb57f4,...) at panic+0x136 indir_trunc(fffff7f3,ffffffff,c85507c0,c834d200,c733de00,...) at indir_trunc+0x4be handle_workitem_indirblk(4,c0cd520e,df,c834d200,c834d200,...) at handle_workitem_indirblk+0x64 handle_workitem_freeblocks(0,e6be2c74,2,5dc,1e0,...) at handle_workitem_freeblocks+0x95 process_worklist_item(c0fb2f98,0,c0cfdf8d,54a,c72e9b40,...) at process_worklist_item+0x21c softdep_process_worklist(c732aca8,0,c0cfdf8d,4cd,64,...) at softdep_process_worklist+0x8c softdep_flush(0,e6be2d28,c0cd1c8a,349,c72ed550,...) at softdep_flush+0x2a0 fork_exit(c0afb670,0,e6be2d28) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6be2d60, ebp = 0 --- It is consistently reproducible. This is on a -current system, at r213139, on i386. Settings for the affected filesystem: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) dimtest1 The panic is apparently caused by perl's "op/lfs.t" test, which tests perlio with big files. You can test it by building the perl 5.12 port, and then running: cd /usr/ports/lang/perl5.12/work/perl-5.12.2/t ../miniperl op/lfs.t Alternatively, just run "make test" in /usr/ports/lang/perl5.12. From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 15:09:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4611C1065670; Wed, 29 Sep 2010 15:09:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 078688FC1C; Wed, 29 Sep 2010 15:09:23 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 034C35C43; Wed, 29 Sep 2010 17:09:21 +0200 (CEST) Message-ID: <4CA356A3.4090204@FreeBSD.org> Date: Wed, 29 Sep 2010 17:09:23 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: FreeBSD-Current References: <4CA34E16.3030003@FreeBSD.org> In-Reply-To: <4CA34E16.3030003@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Kirk McKusick Subject: Re: Soft update panic while running perl 5.12 tests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 15:09:23 -0000 On 2010-09-29 16:32, Dimitry Andric wrote: > It is consistently reproducible. This is on a -current system, at > r213139, on i386. Settings for the affected filesystem: N.B: it only panics when using SU+J, not when using plain soft updates. From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 15:48:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB0EE106566B; Wed, 29 Sep 2010 15:48:47 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9E78FC21; Wed, 29 Sep 2010 15:48:46 +0000 (UTC) Received: by ewy22 with SMTP id 22so342303ewy.13 for ; Wed, 29 Sep 2010 08:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=sykCGh6d2rDeTpBvH/OSaAf8aSuoUXazj26MhiDJIHY=; b=w7SURGMoza53kSbb3VSa+FEUDmTPKJEa/o7QsuIALUV2/UznIRkyR6b9Sk2uwGZfCj FGKlKPNZNBpmDZbhF9f2DBuloEhNEB4N2D3HLdSCoCjGpcdwSK2j1zIWhV3Jcu8f70Dj G9aokKJTNpsK6IGB+U0AvZgby7rDgFFp2oqWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Am+L5qwkJfxxyTwX+4yUtksg2CZSFAHM/Woy04wMs2bEgXszlgiekrTWZsltCApavh dyEU8OT6Q9CwskKK81ISbvm4lm2r2AULJaM6PkWSx8PnK5pcwV8lpes8N3dZcxN+67tE lcO2Q4Eg2gfxHgTsR+jgHXzRzYOMzHAf7+LoE= Received: by 10.216.159.195 with SMTP id s45mr1610441wek.43.1285775325708; Wed, 29 Sep 2010 08:48:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 08:48:25 -0700 (PDT) In-Reply-To: <20100929140657.GA50873@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929140657.GA50873@freebsd.org> From: Renato Botelho Date: Wed, 29 Sep 2010 12:48:25 -0300 Message-ID: To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Cc: dlt@mebtel.net, Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 15:48:47 -0000 On Wed, Sep 29, 2010 at 11:06 AM, Roman Divacky wrote: > > renato, can you check if libc compiled with clang -O0 still exhibits > the bug? I got the following error when i try to build libc with -O0 clang -O2 -pipe -O0 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/amd64/gen/ldexp.c clang: warning: argument unused during compilation: '-O2' Assertion failed: (RegMap[RegOnTop] < StackTop), function moveToTop, file /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86FloatingPoint.cpp, line 200. Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name ldexp.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clang/2.8 -D NLS -D __DBINTERFACE_PRIVATE -D INET6 -D _ACL_PRIVATE -D POSIX_MISTAKE -D BROKEN_DES -D PORTMAP -D DES_BUILTIN -D YP -D NS_CACHING -D SYMBOL_VERSIONING -I /usr/src/lib/libc/include -I /usr/src/lib/libc/../../include -I /usr/src/lib/libc/amd64 -I /usr/src/lib/libc/../../contrib/gdtoa -I /usr/obj/usr/src/lib/libc -I /usr/src/lib/libc/resolv -I /usr/src/lib/libc/../../contrib/tzcode/stdtime -I /usr/src/lib/libc/stdtime -I /usr/src/lib/libc/locale -I /usr/src/lib/libc/rpc -O0 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 105 -stack-protector 1 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-8DfzyK.s -x c /usr/src/lib/libc/amd64/gen/ldexp.c 1. parser at end of file 2. Code generation 3. Running pass 'X86 FP Stackifier' on function '@ldexp' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) *** Error code 250 Removing -O0 from CFLAGS it builds fine. Am I doing something wrong? I added CFLAGS+=-O0 on /etc/make.conf, and # cd /usr/src/lib/libc # make clean && make clean && make cleandir # make obj # make depend # make Thanks -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 15:57:04 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361961065806; Wed, 29 Sep 2010 15:57:03 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail940c35.nsolutionszone.com (mail940c35.nsolutionszone.com [209.235.152.130]) by mx1.freebsd.org (Postfix) with ESMTP id 86E5E8FC1B; Wed, 29 Sep 2010 15:57:02 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail940c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o8TFuxNc027525; Wed, 29 Sep 2010 15:57:00 GMT Date: Wed, 29 Sep 2010 11:56:59 -0400 From: Derek Tattersall To: Dimitry Andric Message-ID: <20100929155659.GA82433@oriental.arm.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA3244D.7030907@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-CSC: 0 X-CHA: v=1.1 cv=nRMQXXDkJm4awCcx+M7+jmO1Ng3APGd8nKmIJUVj4hw= c=1 sm=1 a=BUHArxkelXkA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=6I5d2MoRAAAA:8 a=_IEhM8lNAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=napnQit-wInXbOPhmfYA:9 a=rp46ZIqd_4T7ICMuPsgA:7 a=WAwbG0H6a0Rgpqs1CWJKjPqdQNwA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Renato Botelho , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 15:57:04 -0000 * Dimitry Andric [100929 08:55]: > On 2010-09-29 13:23, Renato Botelho wrote: > > #!/usr/bin/perl > > > > use File::Temp; > > > > my ( $fh, $filename ) = File::Temp::tempfile(); > > print "$filename\n"; > > For me it works perfectly, though I am using perl 5.10: > > $ cat foo.pl > #!/usr/bin/perl > > use File::Temp; > > my ( $fh, $filename ) = File::Temp::tempfile(); > print "$filename\n"; > $ perl -v > > This is perl, v5.10.1 (*) built for i386-freebsd-64int > > Copyright 1987-2009, Larry Wall > > Perl may be copied only under the terms of either the Artistic License or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > $ perl foo.pl > /tmp/tv25CPnWhF > $ perl foo.pl > /tmp/L2UJQ5_JJs > $ perl foo.pl > /tmp/6ynQYvWIc1 > $ perl foo.pl > /tmp/Tdpf7PKBMg > $ perl foo.pl > /tmp/76ir2i1ici > $ perl foo.pl > /tmp/LhfD0eZgd8 > > I'll try building perl 5.12 and try it again. > > Btw, I assume you did *not* rebuild perl with clang, so your perl is > still compiled with gcc? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I built a test case using perl 5.12 and demonstrated that calling int(rand()) in perl returns NAN, as does calling rand() by itself. A "C" program that calls libc's rand() does return differing integers. The perl documentation claims that perl's rand() calls "C"s rand() and srand() if necessary. I think this effectively demonstrates that the problem lies with the perl function rand() and it's interface to libc's rand() as provided by clang. On a recent stable system, perl's mktemp works fine. The only real difference is that libc on stable is built with gcc and libc on current is built with clang. The perl source for mktemp() is in /usr/local/lib/perl5/5.12.2/File/Temp.pm. The line that builds the filename from the template is line 632. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 16:10:44 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41E06106566B; Wed, 29 Sep 2010 16:10:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1DA08FC18; Wed, 29 Sep 2010 16:10:43 +0000 (UTC) Received: by qyk7 with SMTP id 7so1468345qyk.13 for ; Wed, 29 Sep 2010 09:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3496qKG/dXXyNKRIqEuf4rn7YmzRGPQhs8KSIUhGStA=; b=gON4Vl7FR6FKHkur+QGKEnO26BUPRcouUV3Q06KZ9Rvt7eFHhwYhz983JxEwY4KT/1 P83p5/aEWzuDX6+8WQc6Il8uIxc5hyGQX3La7NAnoT8998rgfjnpTzL1T9sny+t7AUjw 0zy1nC1SGn6919KWCBaFYWwM4BYfGv1tMls6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Uyvke3WWKIl13F1XuVCbOcMfLGdBQLw4mNCcN/I2kRS0O5h/uPF96T92upxnjnpepJ SzlDhb7D9FWSZV/8azxt4PWKsB3bt64xiO+DDN5juH+r2VmBK/LMLXXygEqZ3aQN7WOe zibZ47/tXvvBSdYKfnGc6w4Bf69W5n7P8ihLg= MIME-Version: 1.0 Received: by 10.224.19.147 with SMTP id a19mr1294648qab.235.1285776642662; Wed, 29 Sep 2010 09:10:42 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Wed, 29 Sep 2010 09:10:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Sep 2010 18:10:42 +0200 X-Google-Sender-Auth: ZRQ-w5G8dl0FAnwibK5pfCpw6qc Message-ID: From: Attilio Rao To: Sergey Kandaurov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Ryan Stone , FreeBSD Current , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 16:10:44 -0000 2010/9/29 Sergey Kandaurov : > [just don't know what namely need to test, so] > > All made according to your instructions. > The only way I could trigger netdump was > to run its ddb command by hand. Neither > debug.kdb.enter nor debug.kdb.panic don't do it. You probabilly need to use KDB_UNATTENDED. > Some numbers and output (bit verbose > but again don't know what need to show here) > Entered through debug.kdb.panic, thus Panicstring. > db> netdump > > ----------------------------------- > netdump in progress. searching for server.. dumping to xx.xxx.xx.xx > (00:1a:64:d3:4f:20) > ----------------------------------- > Physical memory: 2026 MB > Dumping 1154 MB: 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 > 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 > 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 > 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 > 147 131 115 99 83 67 51 35 19 3 > Dump complete > > netdump finished. > cancelling normal dump > > # ls -hl /home/fooserv/crash/ > total 1182930 > -rw-r--r-- =C2=A01 root =C2=A0wheel =C2=A0 404B Sep 29 12:05 info.fooserv= .0 > -rw-r--r-- =C2=A01 root =C2=A0wheel =C2=A0 1.1G Sep 29 12:05 vmcore.foose= rv.0 > > Dump from fooserv [xx.xxx.xx.xx] > =C2=A0Architecture: amd64 > =C2=A0Architecture version: 2 > =C2=A0Dump length: 1210687488B (1154 MB) > =C2=A0blocksize: 8192 > =C2=A0Dumptime: Wed Sep 29 11:55:30 2010 > =C2=A0Hostname: fooserv > =C2=A0Versionstring: FreeBSD 9.0-CURRENT #51: Wed Sep 29 07:18:24 UTC 201= 0 > =C2=A0 =C2=A0root@fooserv:/usr/obj/usr/src/sys/GENERIC > =C2=A0Panicstring: kdb_sysctl_panic > =C2=A0Header parity check: Pass > Dump complete > > I tried to netdump a bit later again, but it couldn't find server, which > runs though, and client traffic was seen on server-side (w/o reply). > db> netdump > > ----------------------------------- > netdump in progress. searching for server.. . . . . . . . . . . . > Failed to contact netdump server Could you compile the kernel with NETDUMP_CLIENT_DEBUG and retry? (Warning: the log may be huge, so you may be needing to log with serial lin= e) I will try to reproduce locally, if anything. Thanks, Attilio > > As for netdumpserv, > it misses #include before __FBSDID(); > I happily tested it on 7.3-amd64. Yes, there are also other small style(9) nits that needs to be addressed in the netdumpserver as well. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 16:13:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00AD6106564A; Wed, 29 Sep 2010 16:13:15 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 555788FC12; Wed, 29 Sep 2010 16:13:13 +0000 (UTC) Received: by ewy22 with SMTP id 22so363523ewy.13 for ; Wed, 29 Sep 2010 09:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=teie2EVRsrl+vxOyKtlbG+wl31oR3/xYGB7pqo8QUK4=; b=PaiBcq9bD8FSKMArYgaLuwjYu0dghhFPLTIN8BKfXLkLB6LocTubWvsmnfFASFa38p 8pD8CAWBE3GhuWzn9YoDJJqOZ4l8L8BUUjQ1dVPOPeAJEOdAc8L1ceX4J/7kE3Jc6BZm UPgoIDE8JvDB1fawwFhmLrWcUKA9ihKLmp9qE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vpCwAeXDNkMeIIv705/6HvXxuYGe5TGhfJkaAxe1JqsvORmhHReH+K7uDM/4jSdXT+ osVSKCLfh2nqY+7++WxoVgRPZ1cSWrlfZPnOhn4Dqmi3YOyhMZTWd67WP7ic49mxy8FQ Gje/vbBMZbY7GiE1n40klD3+c/Q9eixJ8/SLc= MIME-Version: 1.0 Received: by 10.213.16.144 with SMTP id o16mr2786149eba.64.1285776792945; Wed, 29 Sep 2010 09:13:12 -0700 (PDT) Received: by 10.213.105.208 with HTTP; Wed, 29 Sep 2010 09:13:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Sep 2010 12:13:12 -0400 Message-ID: From: Ryan Stone To: FreeBSD Current , attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Fwd: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 16:13:15 -0000 ---------- Forwarded message ---------- Replying to the list this time... From: Ryan Stone Date: Wed, Sep 29, 2010 at 11:32 AM Subject: Re: [PATCH] Netdump for review and testing -- preliminary version To: Sergey Kandaurov > db> netdump > > ----------------------------------- > netdump in progress. searching for server.. . . . . . . . . . . . > Failed to contact netdump server This can be fixed by putting: nd_server_port = NETDUMP_PORT; At the beginning of netdump_trigger. From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 16:20:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 351821065670; Wed, 29 Sep 2010 16:20:12 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 682528FC17; Wed, 29 Sep 2010 16:20:11 +0000 (UTC) Received: by wwb17 with SMTP id 17so1238405wwb.31 for ; Wed, 29 Sep 2010 09:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=NO+f7bS/h9TGFmzH5ong41evUlZU6jqFaIM9IvgsaTY=; b=YQH4geSAC8jS6tKTQ956yllMLl5iWkxMRY4ISiS62hsmP30FzDUTKaPLn2noShPPdQ k/r3coln40+TCEBBabn6k5fuIwl/rPyeAOCkOv6CO94PeWOuUy3qsmiYIn/MmWvbCEvj RV7VQfqSv1aWhPt3BgyDmpUyUi9/RLQFTeO9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=CPK3RlvxFnh9VV8mJT/e+CJLWl4MHkYRwJ1aZ0xVymTfLfFTdrBtggKp1QXpTzU4Ev 41UQSR73ivHyMn5sSTyLIrBcdrc/MuDzMnz3gT/9FvhNIt2w1aHEWl/yx2nyZr0awbOa KNiK5mIhi+OfIrss/7QcZsD0J/3fZ0vLpkBiw= Received: by 10.227.155.3 with SMTP id q3mr1661278wbw.130.1285777210389; Wed, 29 Sep 2010 09:20:10 -0700 (PDT) Received: from dragon.dg (41-132-25-181.dsl.mweb.co.za [41.132.25.181]) by mx.google.com with ESMTPS id k7sm5522365wej.2.2010.09.29.09.20.06 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 09:20:09 -0700 (PDT) From: David Naylor Organization: Private To: Andriy Gapon Date: Wed, 29 Sep 2010 18:19:57 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.4.5; amd64; ; ) References: <201009291207.53146.naylor.b.david@gmail.com> <201009291548.03752.naylor.b.david@gmail.com> <4CA34ADC.40309@icyb.net.ua> In-Reply-To: <4CA34ADC.40309@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9056537.7SONuKrAe5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009291820.02401.naylor.b.david@gmail.com> Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 16:20:12 -0000 --nextPart9056537.7SONuKrAe5 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: > on 29/09/2010 16:47 David Naylor said the following: > > On Wednesday 29 September 2010 15:14:08 John Baldwin wrote: > >> On Wednesday, September 29, 2010 7:37:15 am Andriy Gapon wrote: > >>> on 29/09/2010 13:40 Alexander Motin said the following: > >>>> Hi. > >>>>=20 > >>>> David Naylor wrote: > >>>>> Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails wi= th > >>>>> ``panic: No usable event timer found!''. This occurs on two (all m= y) > >>>>> machines. This has been a persistent problem since the introduction > >>>>> of the event timer code. > >>>>=20 > >>>> I've reproduced the problem. > >>>>=20 > >>>> The reason is that all (or at least most) of devices (both PCI and > >>>> ISA), including only available in that mode i8254 and RTC timers, > >>>> failed to allocate their interrupts. While reported message is indeed > >>>> related to event timer code, problem IMHO doesn't. While without this > >>>> panic system could boot without any alive timer, I have doubts that = it > >>>> would be functional without timers, USB, network and disk controller= s. > >>>>=20 > >>>> Problems seems to be the same if I am trying to boot without ACPI. > >>=20 > >> Probably the kernel doesn't have 'device atpic' so disabling APIC > >> probably breaks all interrupts. A newer system might only describe > >> APICs via the ACPI MADT table and not provide an MP Table. In that > >> case disabling ACPI would effectively disable APIC leading to the same > >> result. > >=20 > > Is APIC and ACPI disabled in safe-mode on amd64? >=20 > Did you notice the code snippet below? Yes, and it managed to confuse me. =20 > Specifically hint.acpi.0.disabled and hint.apic.0.disabled. > Don't let "arch-i386" confuse you, it means "x86" in that context. >=20 > > This is using GENERIC, perhaps atpic should be added to the config file, > > or made mandatory for amd64 systems? >=20 > I don't think so. Especially given that hardware might not support !APIC > case at all, even if you have atpic in your kernel. Perhaps safe-mode is no longer a viable option and should be removed from t= he=20 boot menu, or renamed to "unsafe-mode"? =20 =20 > Alternatively, perhaps just don't use this "Safe Mode"? > What do you try to actually achieve? I was trying to boot a system and it was panicking due to stray interrupts.= =20 It turned out to be caused by HPET. I found `hint.hpet.0.clock=3D0' which = fixed=20 the problem. =20 This means HPET does not work on any of my machines. The other one's sympt= oms=20 are hda losing interrupts after a period of up-time. =20 --nextPart9056537.7SONuKrAe5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkyjZzIACgkQUaaFgP9pFrIg1ACfZw+/o3Qxa5lEAb8xUAk6NaTK w58AnAm48Je2BY2gOkrIwb8XEIAK+phn =Ogw3 -----END PGP SIGNATURE----- --nextPart9056537.7SONuKrAe5-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 16:25:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D0F0106566C; Wed, 29 Sep 2010 16:25:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id ADA368FC0C; Wed, 29 Sep 2010 16:25:30 +0000 (UTC) Received: by bwz15 with SMTP id 15so877147bwz.13 for ; Wed, 29 Sep 2010 09:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=oeQr6TJnO1M5kalSBtDJH94ws+IO1Hw4oQOAIKEJNZo=; b=yCAa2ORderHzvGGkGdYV7D5pJFl/eiv8YvWlV7gNzF9IIzoJDSzYfa9oVGVYZ0w/Zy IXfl5uXdn4dHr8g3Z+uKOd2ariTNDoEHt7+CAd4+d6F5hF6f7fMx7ChAL/AygUTdRRwo jaZn7SpoIX7oDeejJrByeX98uYEZULw88JKIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=eZFXL7HBkXZlYtrK9W+4lYEZQYKfd3x+eUYN0M1hQeUmPmgOzz/KKwQFVu3i3LwZBp nLMh1Ut9pe3RfGJap0rfuoQNgbkN3TGb5nGn9dJ7u4xoKwJHaJYZQjYGSXUwWAaRNFLp ptzbs0nDJQNDEpchJ7/ZeFPUBxdJHGYbvkoNI= Received: by 10.204.81.215 with SMTP id y23mr1475197bkk.78.1285777529602; Wed, 29 Sep 2010 09:25:29 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 24sm6841564bkr.19.2010.09.29.09.25.27 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 09:25:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA36869.7040205@FreeBSD.org> Date: Wed, 29 Sep 2010 19:25:13 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Naylor References: <201009291207.53146.naylor.b.david@gmail.com> <201009291548.03752.naylor.b.david@gmail.com> <4CA34ADC.40309@icyb.net.ua> <201009291820.02401.naylor.b.david@gmail.com> In-Reply-To: <201009291820.02401.naylor.b.david@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 16:25:31 -0000 David Naylor wrote: > On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: >> What do you try to actually achieve? > > I was trying to boot a system and it was panicking due to stray interrupts. > It turned out to be caused by HPET. I found `hint.hpet.0.clock=0' which fixed > the problem. > > This means HPET does not work on any of my machines. The other one's symptoms > are hda losing interrupts after a period of up-time. What chipset do you use? Nvidia MCP5x? Could you send me your verbose dmesg? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 16:33:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2591106566B; Wed, 29 Sep 2010 16:33:58 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F3CE38FC23; Wed, 29 Sep 2010 16:33:57 +0000 (UTC) Received: by wyb33 with SMTP id 33so38570wyb.13 for ; Wed, 29 Sep 2010 09:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=+w8qUHLjVfw2SN+9QzNBGd2IT+XfRDTLOuYuIi4Kdd8=; b=D848Js9LJCNMT12clL4dSiF5oVLkX/6XH6Y619+2PG0ah9xrGOeY9SlpZUObOYGuL4 exwW1CvsCcxeuBj+lZ0wcz8X5Q7eWjc6ZHT7CBFwgHJaqHqBwN5Hd69cPxrKODFgT8RC iDGXDg1JkjyF0e+sm7DdnelIptgrsSFJAXrWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=wSPLaoc84fRESw6dtpKyLIyfFEvT0cdyjb3tPnA5ogdXdz8rhOJHIttW+ZPEtPRqkP eZOqBUe+aZwNBz7zlMkWXs/v0TfyiZH/ja2dm8L/MguYDg485b1oqVEsEjMk1cXr/X3u i1lGmG+wh4GrSMzBGoP/0BslplBYFmp8FPNlI= Received: by 10.216.52.135 with SMTP id e7mr1615806wec.98.1285778036538; Wed, 29 Sep 2010 09:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 09:33:35 -0700 (PDT) In-Reply-To: <20100929140657.GA50873@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929140657.GA50873@freebsd.org> From: Renato Botelho Date: Wed, 29 Sep 2010 13:33:35 -0300 Message-ID: To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Cc: dlt@mebtel.net, Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 16:33:58 -0000 On Wed, Sep 29, 2010 at 11:06 AM, Roman Divacky wrote: > renato, can you check if libc compiled with clang -O0 still exhibits > the bug? Hi Roman, I needed to build ldexp.{o,po,So} manually with -O2, and built every other object using -O0, the same problem happened. -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 17:32:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19053106564A; Wed, 29 Sep 2010 17:32:02 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF198FC1E; Wed, 29 Sep 2010 17:32:01 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 9EBB39CB084; Wed, 29 Sep 2010 19:31:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlNnmS4oklBs; Wed, 29 Sep 2010 19:31:58 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8AA209CB213; Wed, 29 Sep 2010 19:31:58 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o8THVwS6073793; Wed, 29 Sep 2010 19:31:58 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 29 Sep 2010 19:31:58 +0200 From: Roman Divacky To: Derek Tattersall Message-ID: <20100929173158.GA73653@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100929155659.GA82433@oriental.arm.org> User-Agent: Mutt/1.4.2.3i Cc: Renato Botelho , Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:32:02 -0000 On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: > * Dimitry Andric [100929 08:55]: > > On 2010-09-29 13:23, Renato Botelho wrote: > > > #!/usr/bin/perl > > > > > > use File::Temp; > > > > > > my ( $fh, $filename ) = File::Temp::tempfile(); > > > print "$filename\n"; > > > > For me it works perfectly, though I am using perl 5.10: > > > > $ cat foo.pl > > #!/usr/bin/perl > > > > use File::Temp; > > > > my ( $fh, $filename ) = File::Temp::tempfile(); > > print "$filename\n"; > > $ perl -v > > > > This is perl, v5.10.1 (*) built for i386-freebsd-64int > > > > Copyright 1987-2009, Larry Wall > > > > Perl may be copied only under the terms of either the Artistic License or the > > GNU General Public License, which may be found in the Perl 5 source kit. > > > > Complete documentation for Perl, including FAQ lists, should be found on > > this system using "man perl" or "perldoc perl". If you have access to the > > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > > $ perl foo.pl > > /tmp/tv25CPnWhF > > $ perl foo.pl > > /tmp/L2UJQ5_JJs > > $ perl foo.pl > > /tmp/6ynQYvWIc1 > > $ perl foo.pl > > /tmp/Tdpf7PKBMg > > $ perl foo.pl > > /tmp/76ir2i1ici > > $ perl foo.pl > > /tmp/LhfD0eZgd8 > > > > I'll try building perl 5.12 and try it again. > > > > Btw, I assume you did *not* rebuild perl with clang, so your perl is > > still compiled with gcc? > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I built a test case using perl 5.12 and demonstrated that calling int(rand()) > in perl returns NAN, as does calling rand() by itself. A "C" program > that calls libc's rand() does return differing integers. The perl > documentation claims that perl's rand() calls "C"s rand() and srand() if > necessary. I think this effectively demonstrates that the problem lies > with the perl function rand() and it's interface to libc's rand() as > provided by clang. > > On a recent stable system, perl's mktemp works fine. The only real > difference is that libc on stable is built with gcc and libc on current > is built with clang. what does this show with clang libc? perl -e 'print int(rand(60)) . " \n" foreach (1 .. 10)' I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 17:41:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91158106564A; Wed, 29 Sep 2010 17:41:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB308FC1D; Wed, 29 Sep 2010 17:41:19 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7C4635C43; Wed, 29 Sep 2010 19:41:18 +0200 (CEST) Message-ID: <4CA37A3F.7020107@FreeBSD.org> Date: Wed, 29 Sep 2010 19:41:19 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: Renato Botelho References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929140657.GA50873@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , dlt@mebtel.net, current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:41:19 -0000 On 2010-09-29 17:48, Renato Botelho wrote: > 0. Program arguments: /usr/bin/clang -cc1 -triple > x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name ldexp.c > -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases > -munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clang/2.8 -D > NLS -D __DBINTERFACE_PRIVATE -D INET6 -D _ACL_PRIVATE -D POSIX_MISTAKE > -D BROKEN_DES -D PORTMAP -D DES_BUILTIN -D YP -D NS_CACHING -D > SYMBOL_VERSIONING -I /usr/src/lib/libc/include -I > /usr/src/lib/libc/../../include -I /usr/src/lib/libc/amd64 -I > /usr/src/lib/libc/../../contrib/gdtoa -I /usr/obj/usr/src/lib/libc -I > /usr/src/lib/libc/resolv -I > /usr/src/lib/libc/../../contrib/tzcode/stdtime -I > /usr/src/lib/libc/stdtime -I /usr/src/lib/libc/locale -I > /usr/src/lib/libc/rpc -O0 -Wsystem-headers -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19 > -fmessage-length 105 -stack-protector 1 -fgnu-runtime > -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-8DfzyK.s -x c > /usr/src/lib/libc/amd64/gen/ldexp.c > 1. parser at end of file > 2. Code generation > 3. Running pass 'X86 FP Stackifier' on function '@ldexp' ... > Removing -O0 from CFLAGS it builds fine. Am I doing something > wrong? No, but unfortunately ldexp.c is well-known problem case for clang's inline assembly support. Its handling of floating point arguments is rather fragile, and sometimes breaks, as you can see here. For now, only use the standard settings to compile it. :) From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 17:41:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21724106564A; Wed, 29 Sep 2010 17:41:42 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by mx1.freebsd.org (Postfix) with ESMTP id 592228FC1A; Wed, 29 Sep 2010 17:41:41 +0000 (UTC) Received: by wyi11 with SMTP id 11so1577477wyi.17 for ; Wed, 29 Sep 2010 10:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8bn4eWbY3x/hiGaPkabhlEZ/LO1a8/IOFPEPWai3kYY=; b=ECiN71NgPqXg+QJ6/zwHbYuMg6HUCjVAFQ+XPE/GaicP6CSIMt3UqIGNJVxq9/uI1F su+pCk8tUEGfL888Gda2RJmIglYMOTVLNeAguFb7CcPatYDJF3vC0hrQnI/GktMjTY9i 1KOXBdbrNxBPsnC+QJJfYTCSFPHohQtiKLIm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PebynS34KlzDOIdFoJhkzCX45AB3lGLRTMWVC4FPEljZLE7+ZwNCfJ4JzLnBnPCLDN dHPaU/ubJMoFZzttaNwCFwoz8ReJzurwip/iyz3B0YPvgdiLo8VCIdNZflXOB5g/a/9a 1WwnZxVopUt3jICQNKEoO6uD948FjIn5yn+nA= Received: by 10.216.1.18 with SMTP id 18mr2842617wec.24.1285782099973; Wed, 29 Sep 2010 10:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 10:41:17 -0700 (PDT) In-Reply-To: <20100929173158.GA73653@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> From: Renato Botelho Date: Wed, 29 Sep 2010 14:41:17 -0300 Message-ID: To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Derek Tattersall , Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:41:42 -0000 On Wed, Sep 29, 2010 at 2:31 PM, Roman Divacky wrote= : > On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: >> * Dimitry Andric [100929 08:55]: >> > On 2010-09-29 13:23, Renato Botelho wrote: >> > > #!/usr/bin/perl >> > > >> > > use File::Temp; >> > > >> > > my ( $fh, $filename ) =3D File::Temp::tempfile(); >> > > print "$filename\n"; >> > >> > For me it works perfectly, though I am using perl 5.10: >> > >> > $ cat foo.pl >> > #!/usr/bin/perl >> > >> > use File::Temp; >> > >> > my ( $fh, $filename ) =3D File::Temp::tempfile(); >> > print "$filename\n"; >> > $ perl -v >> > >> > This is perl, v5.10.1 (*) built for i386-freebsd-64int >> > >> > Copyright 1987-2009, Larry Wall >> > >> > Perl may be copied only under the terms of either the Artistic License= or the >> > GNU General Public License, which may be found in the Perl 5 source ki= t. >> > >> > Complete documentation for Perl, including FAQ lists, should be found = on >> > this system using "man perl" or "perldoc perl". =A0If you have access = to the >> > Internet, point your browser at http://www.perl.org/, the Perl Home Pa= ge. >> > >> > $ perl foo.pl >> > /tmp/tv25CPnWhF >> > $ perl foo.pl >> > /tmp/L2UJQ5_JJs >> > $ perl foo.pl >> > /tmp/6ynQYvWIc1 >> > $ perl foo.pl >> > /tmp/Tdpf7PKBMg >> > $ perl foo.pl >> > /tmp/76ir2i1ici >> > $ perl foo.pl >> > /tmp/LhfD0eZgd8 >> > >> > I'll try building perl 5.12 and try it again. >> > >> > Btw, I assume you did *not* rebuild perl with clang, so your perl is >> > still compiled with gcc? >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> I built a test case using perl 5.12 and demonstrated that calling int(ra= nd()) >> in perl returns NAN, as does calling rand() by itself. =A0A "C" program >> that calls libc's rand() does return differing integers. =A0The perl >> documentation claims that perl's rand() calls "C"s rand() and srand() if >> necessary. =A0I think this effectively demonstrates that the problem lie= s >> with the perl function rand() and it's interface to libc's rand() as >> provided by clang. >> >> On a recent stable system, perl's mktemp works fine. =A0The only real >> difference is that libc on stable is built with gcc and libc on current >> is built with clang. > > what does this show with clang libc? > > perl -e 'print int(rand(60)) . " \n" foreach (1 .. 10)' > > I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? > root@botelhor:/usr/src/lib/libc# perl -e 'print int(rand(60)) . " \n" foreach (1 .. 10)' nan nan nan nan nan nan nan nan nan nan --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 17:42:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E26401065673; Wed, 29 Sep 2010 17:42:20 +0000 (UTC) Date: Wed, 29 Sep 2010 17:42:20 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20100929174220.GA64424@freebsd.org> References: <4CA34E16.3030003@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA34E16.3030003@FreeBSD.org> Cc: Jeff Roberson , FreeBSD-Current , Kirk McKusick Subject: Re: Soft update panic while running perl 5.12 tests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:42:21 -0000 On Wed Sep 29 10, Dimitry Andric wrote: > Hi, > > I just encountered the following soft update panic while running perl > 5.12's tests: > > panic: indir_trunc: Index out of range -148 parent -2061 lbn -305164 > cpuid = 3 > KDB: enter: panic > [ thread pid 19 tid 100047 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> bt > Tracing pid 19 tid 100047 td 0xc72e9b40 > kdb_enter(c0cd6a90,c0cd6a90,c0cfe8ab,e6be2b58,3,...) at kdb_enter+0x3a > panic(c0cfe8ab,ffffff6c,fffff7f3,ffffffff,fffb57f4,...) at panic+0x136 > indir_trunc(fffff7f3,ffffffff,c85507c0,c834d200,c733de00,...) at > indir_trunc+0x4be > handle_workitem_indirblk(4,c0cd520e,df,c834d200,c834d200,...) at > handle_workitem_indirblk+0x64 > handle_workitem_freeblocks(0,e6be2c74,2,5dc,1e0,...) at > handle_workitem_freeblocks+0x95 > process_worklist_item(c0fb2f98,0,c0cfdf8d,54a,c72e9b40,...) at > process_worklist_item+0x21c > softdep_process_worklist(c732aca8,0,c0cfdf8d,4cd,64,...) at > softdep_process_worklist+0x8c > softdep_flush(0,e6be2d28,c0cd1c8a,349,c72ed550,...) at softdep_flush+0x2a0 > fork_exit(c0afb670,0,e6be2d28) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe6be2d60, ebp = 0 --- i encountered a similar panic while updating /usr/src over subversion. the amount of data coming in was quite a lot, since i'm tracking HEAD, but haven't updated /usr/src for almost 2 months. i decided to disable SUJ, because in addition to the panic i was experiencing random reboots in connection with chromium (+10 tabs open). i've been running plain UFS2+SU for almost 3 day now and haven't had a single panic or spontanious reboot. unfortunately i wasn't able to capture any information from the panic i mentioned beforehand, but my guess is that it was something similar that dimitry experienced. cheers. alex > > It is consistently reproducible. This is on a -current system, at > r213139, on i386. Settings for the affected filesystem: > > tunefs: POSIX.1e ACLs: (-a) disabled > tunefs: NFSv4 ACLs: (-N) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: soft update journaling: (-j) enabled > tunefs: gjournal: (-J) disabled > tunefs: maximum blocks per file in a cylinder group: (-e) 2048 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) dimtest1 > > The panic is apparently caused by perl's "op/lfs.t" test, which tests > perlio with big files. You can test it by building the perl 5.12 port, > and then running: > > cd /usr/ports/lang/perl5.12/work/perl-5.12.2/t > ../miniperl op/lfs.t > > Alternatively, just run "make test" in /usr/ports/lang/perl5.12. -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 17:44:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BF26106566C; Wed, 29 Sep 2010 17:44:37 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3438FC28; Wed, 29 Sep 2010 17:44:36 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 109799CB08A; Wed, 29 Sep 2010 19:44:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkAUH4-T4cQk; Wed, 29 Sep 2010 19:44:35 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 2DF099CB213; Wed, 29 Sep 2010 19:44:35 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o8THiYCD075226; Wed, 29 Sep 2010 19:44:34 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 29 Sep 2010 19:44:34 +0200 From: Roman Divacky To: Renato Botelho Message-ID: <20100929174434.GA75072@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Derek Tattersall , Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:44:37 -0000 On Wed, Sep 29, 2010 at 02:41:17PM -0300, Renato Botelho wrote: > On Wed, Sep 29, 2010 at 2:31 PM, Roman Divacky wrote: > > On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: > >> * Dimitry Andric [100929 08:55]: > >> > On 2010-09-29 13:23, Renato Botelho wrote: > >> > > #!/usr/bin/perl > >> > > > >> > > use File::Temp; > >> > > > >> > > my ( $fh, $filename ) = File::Temp::tempfile(); > >> > > print "$filename\n"; > >> > > >> > For me it works perfectly, though I am using perl 5.10: > >> > > >> > $ cat foo.pl > >> > #!/usr/bin/perl > >> > > >> > use File::Temp; > >> > > >> > my ( $fh, $filename ) = File::Temp::tempfile(); > >> > print "$filename\n"; > >> > $ perl -v > >> > > >> > This is perl, v5.10.1 (*) built for i386-freebsd-64int > >> > > >> > Copyright 1987-2009, Larry Wall > >> > > >> > Perl may be copied only under the terms of either the Artistic License or the > >> > GNU General Public License, which may be found in the Perl 5 source kit. > >> > > >> > Complete documentation for Perl, including FAQ lists, should be found on > >> > this system using "man perl" or "perldoc perl". ?If you have access to the > >> > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > >> > > >> > $ perl foo.pl > >> > /tmp/tv25CPnWhF > >> > $ perl foo.pl > >> > /tmp/L2UJQ5_JJs > >> > $ perl foo.pl > >> > /tmp/6ynQYvWIc1 > >> > $ perl foo.pl > >> > /tmp/Tdpf7PKBMg > >> > $ perl foo.pl > >> > /tmp/76ir2i1ici > >> > $ perl foo.pl > >> > /tmp/LhfD0eZgd8 > >> > > >> > I'll try building perl 5.12 and try it again. > >> > > >> > Btw, I assume you did *not* rebuild perl with clang, so your perl is > >> > still compiled with gcc? > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >> I built a test case using perl 5.12 and demonstrated that calling int(rand()) > >> in perl returns NAN, as does calling rand() by itself. ?A "C" program > >> that calls libc's rand() does return differing integers. ?The perl > >> documentation claims that perl's rand() calls "C"s rand() and srand() if > >> necessary. ?I think this effectively demonstrates that the problem lies > >> with the perl function rand() and it's interface to libc's rand() as > >> provided by clang. > >> > >> On a recent stable system, perl's mktemp works fine. ?The only real > >> difference is that libc on stable is built with gcc and libc on current > >> is built with clang. > > > > what does this show with clang libc? > > > > perl -e 'print int(rand(60)) . " \n" foreach (1 .. 10)' > > > > I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? > > > > root@botelhor:/usr/src/lib/libc# perl -e 'print int(rand(60)) . " \n" > foreach (1 .. 10)' > nan > nan > nan > nan > nan > nan > nan > nan > nan > nan heh, now I noticed that Derek already wrote that ;) is anyone able to find where in perl sources the rand function is defined? I failed that :( From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 18:03:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66618106566C; Wed, 29 Sep 2010 18:03:00 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9F68FC19; Wed, 29 Sep 2010 18:02:59 +0000 (UTC) Received: by wyb32 with SMTP id 32so17638wyb.13 for ; Wed, 29 Sep 2010 11:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=n96f/xduvhU4MkR1CYWmxXRFvv9kInK4KG5M3diZlHA=; b=g8ZVhcKihxrQtt3K5SLRXEM222oDg/ReUytrAJlD5IJyGbYwy0mBSmFW/2Awa1Xz27 myoxr2QtvXtxICaRBgeDeVjZ8OvV6k4F1Pd/dapqF7rkoo+spF9OMuCs/7b+AbXiW555 Z0n+tPvX2bp6d1DNcJAzROyuBCoXC0HfGuCy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=oFHcx6+fo98Dt144ObjOtL+/uAJlM2phcsGXG6PzXGNZVqrjcoRRvlwFRswAoLYMU+ jMTeePkivCNcwx3mBdtAuuBVML+hO1llX9QvPORFd1Eurwu3rh6bpt9iQ202d9QhBOhe FwqSiNPlucu/TPFAbzlBhYUvtxRVtQ56KgMVE= Received: by 10.216.162.78 with SMTP id x56mr1753904wek.80.1285783378525; Wed, 29 Sep 2010 11:02:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 11:02:38 -0700 (PDT) In-Reply-To: <20100929174434.GA75072@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> <20100929174434.GA75072@freebsd.org> From: Renato Botelho Date: Wed, 29 Sep 2010 15:02:38 -0300 Message-ID: To: perl@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , skv@freebsd.org Subject: Fwd: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:03:00 -0000 Could you guys give us some help on this? ---------- Forwarded message ---------- From: Roman Divacky Date: Wed, Sep 29, 2010 at 2:44 PM Subject: Re: Clang now builds world and kernel, on i386 and amd64 To: Renato Botelho Cc: Derek Tattersall , Dimitry Andric , current@freebsd.org On Wed, Sep 29, 2010 at 02:41:17PM -0300, Renato Botelho wrote: > On Wed, Sep 29, 2010 at 2:31 PM, Roman Divacky wrote: > > On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: > >> * Dimitry Andric [100929 08:55]: > >> > On 2010-09-29 13:23, Renato Botelho wrote: > >> > > #!/usr/bin/perl > >> > > > >> > > use File::Temp; > >> > > > >> > > my ( $fh, $filename ) = File::Temp::tempfile(); > >> > > print "$filename\n"; > >> > > >> > For me it works perfectly, though I am using perl 5.10: > >> > > >> > $ cat foo.pl > >> > #!/usr/bin/perl > >> > > >> > use File::Temp; > >> > > >> > my ( $fh, $filename ) = File::Temp::tempfile(); > >> > print "$filename\n"; > >> > $ perl -v > >> > > >> > This is perl, v5.10.1 (*) built for i386-freebsd-64int > >> > > >> > Copyright 1987-2009, Larry Wall > >> > > >> > Perl may be copied only under the terms of either the Artistic License or the > >> > GNU General Public License, which may be found in the Perl 5 source kit. > >> > > >> > Complete documentation for Perl, including FAQ lists, should be found on > >> > this system using "man perl" or "perldoc perl". ?If you have access to the > >> > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > >> > > >> > $ perl foo.pl > >> > /tmp/tv25CPnWhF > >> > $ perl foo.pl > >> > /tmp/L2UJQ5_JJs > >> > $ perl foo.pl > >> > /tmp/6ynQYvWIc1 > >> > $ perl foo.pl > >> > /tmp/Tdpf7PKBMg > >> > $ perl foo.pl > >> > /tmp/76ir2i1ici > >> > $ perl foo.pl > >> > /tmp/LhfD0eZgd8 > >> > > >> > I'll try building perl 5.12 and try it again. > >> > > >> > Btw, I assume you did *not* rebuild perl with clang, so your perl is > >> > still compiled with gcc? > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >> I built a test case using perl 5.12 and demonstrated that calling int(rand()) > >> in perl returns NAN, as does calling rand() by itself. ?A "C" program > >> that calls libc's rand() does return differing integers. ?The perl > >> documentation claims that perl's rand() calls "C"s rand() and srand() if > >> necessary. ?I think this effectively demonstrates that the problem lies > >> with the perl function rand() and it's interface to libc's rand() as > >> provided by clang. > >> > >> On a recent stable system, perl's mktemp works fine. ?The only real > >> difference is that libc on stable is built with gcc and libc on current > >> is built with clang. > > > > what does this show with clang libc? > > > > perl -e 'print int(rand(60)) . " \n" foreach (1 .. 10)' > > > > I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? > > > > root@botelhor:/usr/src/lib/libc# perl -e 'print int(rand(60)) . " \n" > foreach (1 .. 10)' > nan > nan > nan > nan > nan > nan > nan > nan > nan > nan heh, now I noticed that Derek already wrote that ;) is anyone able to find where in perl sources the rand function is defined? I failed that :( -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 18:22:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0324106566C; Wed, 29 Sep 2010 18:22:32 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E84328FC15; Wed, 29 Sep 2010 18:22:31 +0000 (UTC) Received: by wwb17 with SMTP id 17so1416547wwb.31 for ; Wed, 29 Sep 2010 11:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=atEdl6820wTMgTXlz2WqxakB8Rib/i90QKKHlh1RcNE=; b=RKpGiLJiNAPJt+rdPj10FrW/KKbSqwGEK4XId9jKqBLZFbXD/D2em2owJxNcLxA4gD X89YNwj48qpcxkEgIg0kjcFVfeqAq4Tg+Nqi0NohzMAuhKU4uocCtlT+UfgAYhn9vQiW oNC3Ru8XMOX/va92fmqqDMEr3f9urbgNv+qCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=OiZE+/5AGT7Ibt9YsnaUBT2odFXR3KH+yOMX/1QkjS2neJb7wxv31x8YaR0yENoRZu /gSQv88aBXfK/mIA2Vrg0AHF9WQyrcO6QBoqRxxv4yeqLLGtvz5tkR2+NYn1KgFEQvMn P7yoQZfYQ72bqimHODhU+xGCk0VYVMhMPM3q8= Received: by 10.216.35.75 with SMTP id t53mr2846899wea.95.1285784547908; Wed, 29 Sep 2010 11:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 11:22:07 -0700 (PDT) In-Reply-To: <20100929174434.GA75072@freebsd.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> <20100929174434.GA75072@freebsd.org> From: Renato Botelho Date: Wed, 29 Sep 2010 15:22:07 -0300 Message-ID: To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Cc: Derek Tattersall , Dimitry Andric , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:22:32 -0000 On Wed, Sep 29, 2010 at 2:44 PM, Roman Divacky wrote: > heh, now I noticed that Derek already wrote that ;) is anyone able > to find where in perl sources the rand function is defined? I failed > that :( It's using drand48() instead of rand() root@botelhor:/usr/ports/lang/perl5.12# make configure |& grep -i rand drand48_r() NOT found. random_r() NOT found. srand48_r() NOT found. srandom_r() NOT found. Looking for a random number function... Good, found drand48(). Use which function to generate random numbers? [drand48] Checking how to generate random libraries on your machine... Test results here: GCC libc: garga@botelhor:~/testes> ./test random value 0.396465 clang libc: garga@botelhor:~/testes> ./test random value -inf Source of test.c: #include #include #include int main() { printf("random value %f\n", drand48()); exit(0); } -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 18:37:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F28D31065673; Wed, 29 Sep 2010 18:37:19 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE9FD8FC1A; Wed, 29 Sep 2010 18:36:59 +0000 (UTC) Received: by wyb32 with SMTP id 32so19966wyb.13 for ; Wed, 29 Sep 2010 11:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=wASeikb1bOj+vAbzBCSahmYTxTmBzcPaWx8+4K8xAz0=; b=kCGf+ztsGFEMwPBBcpeYwFaoBkjKVn7nclYYZJFw9L3cZo+qRAQl9rRNtMcKqO+YsI OrG/l6pKAigdKyfESPRJ0bFJs5FJGQEbTh31xsptjGkpUDCgTFw3HhmjfJydVlMrI42w LOKXiO39ZugQF0WWkg1RKlZjmLK9drhKyW+U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LPqt3lA3ppr6NVzrIKp6kC1mpxqskoCSJTTbPAKmMZOnBULZIREjxyCrpVS5XKUPhG Y6YHk7+mhTfHzYd2w4GbOfX6ksvnvbDDiE9ZsgBoCtMM5U3XPBsI99zxIYY4FbNuwFY/ aRJgQqMMryh0Gx2bD10UUXpc7AWlleJ4yELD0= Received: by 10.216.35.75 with SMTP id t53mr2863047wea.95.1285785351873; Wed, 29 Sep 2010 11:35:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 11:35:31 -0700 (PDT) In-Reply-To: <4CA34E16.3030003@FreeBSD.org> References: <4CA34E16.3030003@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 15:35:31 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Current , Kirk McKusick Subject: Re: Soft update panic while running perl 5.12 tests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:37:20 -0000 On Wed, Sep 29, 2010 at 11:32 AM, Dimitry Andric wrote: > Hi, > > I just encountered the following soft update panic while running perl > 5.12's tests: > > panic: indir_trunc: Index out of range -148 parent -2061 lbn -305164 > cpuid =3D 3 > KDB: enter: panic > [ thread pid 19 tid 100047 ] > Stopped at =A0 =A0 =A0kdb_enter+0x3a: movl =A0 =A0$0,kdb_why > db> bt > Tracing pid 19 tid 100047 td 0xc72e9b40 > kdb_enter(c0cd6a90,c0cd6a90,c0cfe8ab,e6be2b58,3,...) at kdb_enter+0x3a > panic(c0cfe8ab,ffffff6c,fffff7f3,ffffffff,fffb57f4,...) at panic+0x136 > indir_trunc(fffff7f3,ffffffff,c85507c0,c834d200,c733de00,...) at > indir_trunc+0x4be > handle_workitem_indirblk(4,c0cd520e,df,c834d200,c834d200,...) at > handle_workitem_indirblk+0x64 > handle_workitem_freeblocks(0,e6be2c74,2,5dc,1e0,...) at > handle_workitem_freeblocks+0x95 > process_worklist_item(c0fb2f98,0,c0cfdf8d,54a,c72e9b40,...) at > process_worklist_item+0x21c > softdep_process_worklist(c732aca8,0,c0cfdf8d,4cd,64,...) at > softdep_process_worklist+0x8c > softdep_flush(0,e6be2d28,c0cd1c8a,349,c72ed550,...) at softdep_flush+0x2a= 0 > fork_exit(c0afb670,0,e6be2d28) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xe6be2d60, ebp =3D 0 --- > > It is consistently reproducible. =A0This is on a -current system, at > r213139, on i386. =A0Settings for the affected filesystem: > > tunefs: POSIX.1e ACLs: (-a) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0disabled > tunefs: NFSv4 ACLs: (-N) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 disabled > tunefs: MAC multilabel: (-l) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 disabled > tunefs: soft updates: (-n) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 enabled > tunefs: soft update journaling: (-j) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 enabled > tunefs: gjournal: (-J) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 disabled > tunefs: maximum blocks per file in a cylinder group: (-e) =A02048 > tunefs: average file size: (-f) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A016384 > tunefs: average number of files in a directory: (-s) =A0 =A0 =A0 64 > tunefs: minimum percentage of free space: (-m) =A0 =A0 =A0 =A0 =A0 =A0 8% > tunefs: optimization preference: (-o) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0time > tunefs: volume label: (-L) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 dimtest1 > > The panic is apparently caused by perl's "op/lfs.t" test, which tests > perlio with big files. =A0You can test it by building the perl 5.12 port, > and then running: > > cd /usr/ports/lang/perl5.12/work/perl-5.12.2/t > ../miniperl op/lfs.t > > Alternatively, just run "make test" in /usr/ports/lang/perl5.12. Since i'm running -current with SUJ here, and built perl 5.12 recently without problems, maybe this can help you (I have that patch applied locally since it was not committed yet). http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019409.html --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 18:43:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 725101065673; Wed, 29 Sep 2010 18:43:08 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 882658FC16; Wed, 29 Sep 2010 18:43:07 +0000 (UTC) Received: by wwb17 with SMTP id 17so1446311wwb.31 for ; Wed, 29 Sep 2010 11:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=wASeikb1bOj+vAbzBCSahmYTxTmBzcPaWx8+4K8xAz0=; b=kCGf+ztsGFEMwPBBcpeYwFaoBkjKVn7nclYYZJFw9L3cZo+qRAQl9rRNtMcKqO+YsI OrG/l6pKAigdKyfESPRJ0bFJs5FJGQEbTh31xsptjGkpUDCgTFw3HhmjfJydVlMrI42w LOKXiO39ZugQF0WWkg1RKlZjmLK9drhKyW+U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LPqt3lA3ppr6NVzrIKp6kC1mpxqskoCSJTTbPAKmMZOnBULZIREjxyCrpVS5XKUPhG Y6YHk7+mhTfHzYd2w4GbOfX6ksvnvbDDiE9ZsgBoCtMM5U3XPBsI99zxIYY4FbNuwFY/ aRJgQqMMryh0Gx2bD10UUXpc7AWlleJ4yELD0= Received: by 10.216.35.75 with SMTP id t53mr2863047wea.95.1285785351873; Wed, 29 Sep 2010 11:35:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 11:35:31 -0700 (PDT) In-Reply-To: <4CA34E16.3030003@FreeBSD.org> References: <4CA34E16.3030003@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 15:35:31 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Current , Kirk McKusick Subject: Re: Soft update panic while running perl 5.12 tests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:43:08 -0000 On Wed, Sep 29, 2010 at 11:32 AM, Dimitry Andric wrote: > Hi, > > I just encountered the following soft update panic while running perl > 5.12's tests: > > panic: indir_trunc: Index out of range -148 parent -2061 lbn -305164 > cpuid =3D 3 > KDB: enter: panic > [ thread pid 19 tid 100047 ] > Stopped at =A0 =A0 =A0kdb_enter+0x3a: movl =A0 =A0$0,kdb_why > db> bt > Tracing pid 19 tid 100047 td 0xc72e9b40 > kdb_enter(c0cd6a90,c0cd6a90,c0cfe8ab,e6be2b58,3,...) at kdb_enter+0x3a > panic(c0cfe8ab,ffffff6c,fffff7f3,ffffffff,fffb57f4,...) at panic+0x136 > indir_trunc(fffff7f3,ffffffff,c85507c0,c834d200,c733de00,...) at > indir_trunc+0x4be > handle_workitem_indirblk(4,c0cd520e,df,c834d200,c834d200,...) at > handle_workitem_indirblk+0x64 > handle_workitem_freeblocks(0,e6be2c74,2,5dc,1e0,...) at > handle_workitem_freeblocks+0x95 > process_worklist_item(c0fb2f98,0,c0cfdf8d,54a,c72e9b40,...) at > process_worklist_item+0x21c > softdep_process_worklist(c732aca8,0,c0cfdf8d,4cd,64,...) at > softdep_process_worklist+0x8c > softdep_flush(0,e6be2d28,c0cd1c8a,349,c72ed550,...) at softdep_flush+0x2a= 0 > fork_exit(c0afb670,0,e6be2d28) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xe6be2d60, ebp =3D 0 --- > > It is consistently reproducible. =A0This is on a -current system, at > r213139, on i386. =A0Settings for the affected filesystem: > > tunefs: POSIX.1e ACLs: (-a) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0disabled > tunefs: NFSv4 ACLs: (-N) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 disabled > tunefs: MAC multilabel: (-l) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 disabled > tunefs: soft updates: (-n) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 enabled > tunefs: soft update journaling: (-j) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 enabled > tunefs: gjournal: (-J) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 disabled > tunefs: maximum blocks per file in a cylinder group: (-e) =A02048 > tunefs: average file size: (-f) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A016384 > tunefs: average number of files in a directory: (-s) =A0 =A0 =A0 64 > tunefs: minimum percentage of free space: (-m) =A0 =A0 =A0 =A0 =A0 =A0 8% > tunefs: optimization preference: (-o) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0time > tunefs: volume label: (-L) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 dimtest1 > > The panic is apparently caused by perl's "op/lfs.t" test, which tests > perlio with big files. =A0You can test it by building the perl 5.12 port, > and then running: > > cd /usr/ports/lang/perl5.12/work/perl-5.12.2/t > ../miniperl op/lfs.t > > Alternatively, just run "make test" in /usr/ports/lang/perl5.12. Since i'm running -current with SUJ here, and built perl 5.12 recently without problems, maybe this can help you (I have that patch applied locally since it was not committed yet). http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019409.html --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 18:44:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FED110656B4; Wed, 29 Sep 2010 18:44:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6C28FC14; Wed, 29 Sep 2010 18:44:19 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1CFAC5C43; Wed, 29 Sep 2010 20:44:18 +0200 (CEST) Message-ID: <4CA38903.2080609@FreeBSD.org> Date: Wed, 29 Sep 2010 20:44:19 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: Renato Botelho References: <4CA34E16.3030003@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Kirk McKusick Subject: Re: Soft update panic while running perl 5.12 tests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:44:19 -0000 On 2010-09-29 20:35, Renato Botelho wrote: >> Alternatively, just run "make test" in /usr/ports/lang/perl5.12. > > Since i'm running -current with SUJ here, and built perl 5.12 > recently without problems, maybe this can help you (I have > that patch applied locally since it was not committed yet). > > http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019409.html This looks like a different panic, at least from the stack trace. Also, if you build and install perl ports, it does not run the perl tests by default. You have to run 'make test' separately for it. From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 19:16:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D51106564A; Wed, 29 Sep 2010 19:16:45 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 664A78FC0A; Wed, 29 Sep 2010 19:16:44 +0000 (UTC) Received: by wwb17 with SMTP id 17so1498570wwb.31 for ; Wed, 29 Sep 2010 12:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=DvjRWy33bV2mfcAdT9wGfDci37IN6q9zj9qyERGb2C4=; b=BQkVtHChz8oGs5bZzWHrSFJYe5ApynAGMIIzjQVQxuMoe3dP3RS0crPZ/OQ+dJIkgB GMRccNsUc0tUk+crEFvVbILXFgrd81yF8iZHvntGe/j1X+Sehtrx0VEDm11oMefRwmkw lfIzq86csjty8YYEjJjBVMMaE8SLgygtUhGaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=tEEJ7fic0TyitVSDiwtuFB2vqpGbUovERK+I08L7o/1PKjHlhrWK6/s4wRY8lDPonZ d+VwVBYoCow+OF9Pe129zIxbwjrW8mWVc4u2vXKWpJUv5zJJMqWI6U7Ex9Q1E2idBOrI K7dFKLGQAav3TZLeLi5zlfv1fX/GTEenhOdQk= Received: by 10.216.1.18 with SMTP id 18mr2923491wec.24.1285786114237; Wed, 29 Sep 2010 11:48:34 -0700 (PDT) Received: from dragon.dg (41-132-25-181.dsl.mweb.co.za [41.132.25.181]) by mx.google.com with ESMTPS id n40sm5628882weq.5.2010.09.29.11.48.16 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 11:48:32 -0700 (PDT) From: David Naylor Organization: Private To: Alexander Motin Date: Wed, 29 Sep 2010 20:48:04 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.4.5; amd64; ; ) References: <201009291207.53146.naylor.b.david@gmail.com> <201009291820.02401.naylor.b.david@gmail.com> <4CA36869.7040205@FreeBSD.org> In-Reply-To: <4CA36869.7040205@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2985025.74bEjDE2hS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009292048.11194.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 19:16:46 -0000 --nextPart2985025.74bEjDE2hS Content-Type: multipart/mixed; boundary="Boundary-01=_kn4oMVrgZQv8UUb" Content-Transfer-Encoding: 7bit --Boundary-01=_kn4oMVrgZQv8UUb Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 29 September 2010 18:25:13 Alexander Motin wrote: > David Naylor wrote: > > On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: > >> What do you try to actually achieve? > >=20 > > I was trying to boot a system and it was panicking due to stray > > interrupts. It turned out to be caused by HPET. I found > > `hint.hpet.0.clock=3D0' which fixed the problem. > >=20 > > This means HPET does not work on any of my machines. The other one's > > symptoms are hda losing interrupts after a period of up-time. >=20 > What chipset do you use? Nvidia MCP5x? Could you send me your verbose > dmesg? Yes, the one is a MCP51, the other is a ICH8M. =20 The desktop is a Gigabyte N650SLI-DS4L. Its symptom is hda losing interrup= ts=20 after a period of time. =20 The laptop is a Acer 2920. Its symptom for a GENERIC is a panic saying str= ay=20 interrupt (irq7), with a custom kernel booting stalls. =20 The dmesg's are using a custom kernel with ``hint.hpet.0.clock=3D0'' set. = The=20 Acer also has apic and atrtc timers disabled (as per the advice to get C3=20 working). =20 See attached are the dmesg's. =20 --Boundary-01=_kn4oMVrgZQv8UUb Content-Type: text/plain; charset="ISO-8859-1"; name="acer.dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acer.dmesg" Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Tue Sep 28 18:27:36 SAST 2010 root@dragon.dg:/tmp/home/freebsd9/src/sys/ACER2920 amd64 Table 'FACP' at 0xbf6dbc3a Table 'HPET' at 0xbf6dbd2e Table 'MCFG' at 0xbf6dbd66 Table 'TCPA' at 0xbf6dbda2 Table 'TMOR' at 0xbf6dbdd4 Table 'SLIC' at 0xbf6dbdfa Table 'APIC' at 0xbf6dbf70 Table 'BOOT' at 0xbf6dbfd8 Table 'SSDT' at 0xbf6d31d4 Table 'SSDT' at 0xbf6d3009 Table 'SSDT' at 0xbf6d23c4 Table 'SSDT' at 0xbf6d231e Table 'SSDT' at 0xbf6d1e38 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff809c9000. Calibrating TSC clock ... TSC clock: 2194544968 Hz CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 3221225472 (3072 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x00000000009f7000 - 0x00000000b9ca4fff, 3106594816 bytes (758446 pages) avail memory = 3084644352 (2941 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000010000 x86bios: EBDA 0x09f000-0x09ffff at 0xffffff000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xffffff00000a0000 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf7ca0 00024 (v02 PTLTD ) ACPI: XSDT 0xbf6d1dac 0008C (v01 ACRSYS ACRPRDCT 06040000 INNA 00000000) ACPI: FACP 0xbf6dbc3a 000F4 (v03 INTEL CRESTLNE 06040000 ALAN 00000001) ACPI: DSDT 0xbf6d34b1 08715 (v02 INTEL CRESTLNE 06040000 MSFT 03000000) ACPI: FACS 0xbf6defc0 00040 ACPI: HPET 0xbf6dbd2e 00038 (v01 INTEL CRESTLNE 06040000 LOHR 0000005A) ACPI: MCFG 0xbf6dbd66 0003C (v01 INTEL CRESTLNE 06040000 LOHR 0000005A) ACPI: TCPA 0xbf6dbda2 00032 (v01 Intel CRESTLN 06040000 00005A52) ACPI: TMOR 0xbf6dbdd4 00026 (v01 PTLTD 06040000 PTL 00000003) ACPI: SLIC 0xbf6dbdfa 00176 (v01 ACRSYS ACRPRDCT 06040000 ANNI 00000001) ACPI: APIC 0xbf6dbf70 00068 (v01 PTLTD ? APIC 06040000 LTP 00000000) ACPI: BOOT 0xbf6dbfd8 00028 (v01 PTLTD $SBFTBL$ 06040000 LTP 00000001) ACPI: SSDT 0xbf6d31d4 002DD (v01 SataRe SataAhci 00001000 INTL 20050624) ACPI: SSDT 0xbf6d3009 001CB (v01 BrtRef DD01BRT 00001000 INTL 20050624) ACPI: SSDT 0xbf6d23c4 0025F (v01 PmRef Cpu0Tst 00003000 INTL 20050624) ACPI: SSDT 0xbf6d231e 000A6 (v01 PmRef Cpu1Tst 00003000 INTL 20050624) ACPI: SSDT 0xbf6d1e38 004E6 (v01 PmRef CpuPm 00003000 INTL 20050624) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x000000f0 pmc: 0x00010400 cmci: 0x00000000 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=7 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> null: random: kbd: new array size 4 kbd1 at kbdmux0 mem: VESA: INT 0x10 vector 0xc000:0x0014 VESA: information block 0000 56 45 53 41 00 03 00 01 00 02 01 00 00 00 40 00 0010 00 02 77 00 00 01 3d 01 00 02 4f 01 00 02 7d 01 0020 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 60 01 61 01 62 01 63 01 64 01 65 01 66 01 67 01 0050 68 01 69 01 6a 01 6b 01 6c 01 6d 01 6e 01 6f 01 0060 70 01 71 01 3c 01 4d 01 5c 01 3a 01 4b 01 5a 01 0070 07 01 1a 01 1b 01 05 01 17 01 18 01 12 01 14 01 0080 15 01 01 01 03 01 11 01 ff ff 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 49 6e 74 65 6c 28 72 29 47 4d 39 36 35 2f 50 4d 0110 39 36 35 2f 47 4c 39 36 30 20 47 72 61 70 68 69 0120 63 73 20 43 68 69 70 20 41 63 63 65 6c 65 72 61 0130 74 65 64 20 56 47 41 20 42 49 4f 53 00 49 6e 74 0140 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f 6e 00 49 0150 6e 74 65 6c 28 72 29 47 4d 39 36 35 2f 50 4d 39 0160 36 35 2f 47 4c 39 36 30 20 47 72 61 70 68 69 63 0170 73 20 43 6f 6e 74 72 6f 6c 6c 65 72 00 48 61 72 0180 64 77 61 72 65 20 56 65 72 73 69 6f 6e 20 30 2e 0190 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 12 mode(s) found VESA: v3.0, 7616k memory, flags:0x1, mode table:0xffffff8000052040 (2000040) VESA: Intel(r)GM965/PM965/GL960 Graphics Chip Accelerated VGA BIOS VESA: Intel Corporation Intel(r)GM965/PM965/GL960 Graphics Controller Hardware Version 0.0 io: CPU0: local APIC error 0x80 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: Power Button (fixed) hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) Timecounter "HPET" frequency 14318180 Hz quality 900 ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 0/3 0/3 1/2 -> 8 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 ACPI: SSDT 0xbf6d2cc7 0027A (v01 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0027A (v01 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: SSDT 0xbf6d2623 0061F (v01 PmRef Cpu0Cst 00003001 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0061F (v01 PmRef Cpu0Cst 00003001 INTL 20050624) cpu1: on acpi0 ACPI: SSDT 0xbf6d2f41 000C8 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 000C8 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: SSDT 0xbf6d2c42 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 11 Validation 0 10 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 11 Validation 0 10 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 10 11 Validation 0 11 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 11 Validation 0 10 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 10 11 Validation 0 11 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 11 Validation 0 10 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 10 11 Validation 0 11 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 10 11 Validation 0 11 N 0 10 11 After Disable 0 255 N 0 10 11 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2a00, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2a02, revid=0x03 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xfc000000, size 20, enabled map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0x1800, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2a03, revid=0x03 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfc100000, size 20, enabled found-> vendor=0x8086, dev=0x2834, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2835, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfc404800, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 20 found-> vendor=0x8086, dev=0x284b, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfc200000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x283f, revid=0x03 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2841, revid=0x03 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2843, revid=0x03 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2830, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2831, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2832, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2836, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfc404c00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xf3 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x03 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2850, revid=0x03 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0x1810, size 4, enabled found-> vendor=0x8086, dev=0x2829, revid=0x03 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 4 messages map[10]: type I/O Port, range 32, base 0x1c00, size 3, enabled map[14]: type I/O Port, range 32, base 0x18d4, size 2, enabled map[18]: type I/O Port, range 32, base 0x18d8, size 3, enabled map[1c]: type I/O Port, range 32, base 0x18d0, size 2, enabled map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled map[24]: type Memory, range 32, base 0xfc404000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x283e, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0, size 8, enabled map[20]: type I/O Port, range 32, base 0x1c20, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x1800-0x1807 mem 0xfc000000-0xfc0fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory drm0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 vgapci0: using IRQ 256 for MSI info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: mem 0xfc100000-0xfc1fffff at device 2.1 on pci0 uhci0: port 0x1820-0x183f irq 20 at device 26.0 on pci0 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 50 usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 21 at device 26.1 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 51 usbus1: on uhci1 ehci0: mem 0xfc404800-0xfc404bff irq 20 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 hdac0: mem 0xfc200000-0xfc203fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 52 hdac0: using IRQ 257 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 3 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xf6000000-0xf7ffffff pcib1: prefetched decode 0xf0000000-0xf1ffffff pci2: on pcib1 pci2: domain=0, physical bus=2 found-> vendor=0x14e4, dev=0x1693, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf6000000, size 16, enabled pcib1: requested memory range 0xf6000000-0xf600ffff: good pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 bge0: mem 0xf6000000-0xf600ffff irq 16 at device 0.0 on pci2 bge0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 258 to local APIC 0 vector 53 bge0: using IRQ 258 for MSI bge0: CHIP ID 0x0000b002; ASIC REV 0x0b; CHIP REV 0xb0; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x0050ef, model 0x000e, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: XX:XX:XX:XX:XX:XX pcib2: irq 17 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 4 pcib2: subordinate bus 5 pcib2: I/O decode 0x3000-0x3fff pcib2: memory decode 0xf8000000-0xf9ffffff pcib2: prefetched decode 0xf2000000-0xf3ffffff pci4: on pcib2 pci4: domain=0, physical bus=4 found-> vendor=0x8086, dev=0x4229, revid=0x61 domain=0, bus=4, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf8000000, size 13, enabled pcib2: requested memory range 0xf8000000-0xf8001fff: good pcib2: matched entry for 4.0.INTA pcib2: slot 0 INTA hardwired to IRQ 17 pci4: at device 0.0 (no driver attached) pci0:4:0:0: Transition from D0 to D3 pcib3: irq 18 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 6 pcib3: subordinate bus 7 pcib3: I/O decode 0x4000-0x4fff pcib3: memory decode 0xfa000000-0xfbffffff pcib3: prefetched decode 0xf4000000-0xf5ffffff pci6: on pcib3 pci6: domain=0, physical bus=6 uhci2: port 0x1860-0x187f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 usbus3: on uhci2 uhci3: port 0x1880-0x189f irq 17 at device 29.1 on pci0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 55 usbus4: on uhci3 uhci4: port 0x18a0-0x18bf irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 56 usbus5: on uhci4 ehci1: mem 0xfc404c00-0xfc404fff irq 23 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6: on ehci1 pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 15 pcib4: subordinate bus 15 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. ACPI Warning: For \\_SB_.PCI0.PCIB._PRT: Return Package has no elements (empty) (20100915/nspredef-572) pci15: on pcib4 pci15: domain=0, physical bus=15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 57 ahci0: port 0x1c00-0x1c07,0x18d4-0x18d7,0x18d8-0x18df,0x18d0-0x18d3,0x18e0-0x18ff mem 0xfc404000-0xfc4047ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (4 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 60 ahci0: using IRQ 259 for MSI ahci0: AHCI v1.10 with 3 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC 3ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: at channel 1 on ahci0 ahcich1: Caps: ahcich2: at channel 2 on ahci0 ahcich2: Caps: pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 59 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 61 Event timer "i8254" frequency 1193182 Hz quality 100 battery0: on acpi0 acpi_acad0: on acpi0 acpi0: wakeup code va 0xffffff80dc548000 pa 0x4000 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcf000-0xcffff,0xe0000-0xe17ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Setting TjMax=100 est0: on cpu0 coretemp1: on cpu1 coretemp1: Setting TjMax=100 est1: on cpu1 Device configuration finished. linprocfs registered procfs registered Timecounter "TSC" frequency 2194544968 Hz quality -100 Timecounters tick every 10.000 msec vlan: initialized, using hash tables with chaining Linux ELF exec handler installed lo0: bpf attached ata0: Identifying devices: 00010000 ata0: New devices: 00010000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 battery0: battery initialization start acpi_acad0: acline initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC268 hdac0: HDA Codec ID: 0x10ec0268 hdac0: Vendor: 0x10ec hdac0: Device: 0x0268 hdac0: Revision: 0x00 hdac0: Stepping: 0x03 hdac0: PCI Subvendor: 0x01351025 hdac0: Found audio FG nid=1 startnode=2 endnode=37 total=35 hdac0: Probing codec #1... hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) hdac0: HDA Codec ID: 0x11c11040 hdac0: Vendor: 0x11c1 hdac0: Device: 0x1040 hdac0: Revision: 0x02 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0x01351025 hdac0: Found modem FG nid=1 startnode=2 endnode=127 total=125 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 18 0x99a3092e as 2 seq 14 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 19 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 20 0x0221401f as 1 seq 15 Headphones Jack jack 1 loc 2 color Green misc 0 hdac0: nid 21 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 24 0x02a19820 as 2 seq 0 Mic Jack jack 1 loc 2 color Pink misc 8 hdac0: nid 25 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patched pins configuration: hdac0: nid 18 0x99a3092e as 2 seq 14 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 19 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 20 0x0221401f as 1 seq 15 Headphones Jack jack 1 loc 2 color Green misc 0 hdac0: nid 21 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 24 0x02a19820 as 2 seq 0 Mic Jack jack 1 loc 2 color Pink misc 8 hdac0: nid 25 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: 2 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=21 seq=0 hdac0: Pin nid=20 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=24 seq=0 hdac0: Pin nid=18 seq=14 hdac0: Tracing association 0 (1) hdac0: Pin 21 traced to DAC 2 hdac0: Pin 20 traced to DAC 2 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 24 traced to ADC 7 hdac0: Unable to trace pin 18 to ADC 7, undo traces hdac0: Pin 24 traced to ADC 8 hdac0: Pin 18 traced to ADC 8 hdac0: Association 1 (2) trace succeeded hdac0: Tracing input monitor hdac0: Tracing other input monitors hdac0: Tracing nid 18 to out hdac0: Tracing nid 24 to out hdac0: Tracing beeper hdac0: nid 29 traced to out hdac0: GPIO init: data=0x00000000 mask=0x00000000 dir=0x00000000 hdac0: GPIO commit: data=0x00000001 mask=0x00000001 dir=0x00000001 hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=20 [UNSOL] hdac0: Pin sense: nid=20 res=0x00000000 hdac0: FG config/quirks: gpio0 forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 3 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 4 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 5 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 6 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000211 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x001e05e0 hdac0: 16 20 24 32 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100111 hdac0: STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=36 [audio selector] [DISABLED] hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x00100111 hdac0: STEREO hdac0: Association: 1 (0x00004001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=35 [audio selector] hdac0: hdac0: nid: 9 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 11 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 12 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 13 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010a hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=2 [audio output] hdac0: hdac0: nid: 15 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00008000) hdac0: OSS: pcm, speaker hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=29 [beep widget] hdac0: hdac0: nid: 16 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm, speaker hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 3 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] [DISABLED] hdac0: + <- nid=29 [beep widget] hdac0: + <- nid=2 [audio output] hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 18 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Association: 1 (0x00004000) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x99a3092e hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x0221401f hdac0: Pin control: 0x000000c0 HP OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=15 [audio mixer] hdac0: hdac0: nid: 21 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x99130110 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio mixer] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040010c hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00003734 hdac0: PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x02a19820 hdac0: Pin control: 0x00000025 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x004f0200 hdac0: mute=0 step=2 size=79 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=2 [audio output] hdac0: hdac0: nid: 25 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040008b hdac0: UNSOL STEREO hdac0: Pin cap: 0x00003724 hdac0: PDC IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Input amp: 0x004f0200 hdac0: mute=0 step=2 size=79 offset=0 hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Pin cap: 0x00003734 hdac0: PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x004f0200 hdac0: mute=0 step=2 size=79 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=2 [audio output] hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 29 hdac0: Name: beep widget hdac0: Widget cap: 0x00700000 hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400380 hdac0: DIGITAL UNSOL hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 35 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: mic, monitor hdac0: Output amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 7 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] (selected) hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (Fixed)] hdac0: + <- nid=18 [pin: Mic (Fixed)] hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 7 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] (selected) hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=20 [pin: Headphones (Green Jack)] hdac0: + <- nid=21 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=19 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: Processing modem FG cad=1 nid=1... hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x00060160 pcm0: 16 20 bits, 44 48 96 KHz pcm0: ADC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=21 [pin: Speaker (Fixed)] pcm0: | pcm0: + <- nid=16 [audio mixer] [src: pcm, speaker] pcm0: | pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: pcm0: nid=20 [pin: Headphones (Green Jack)] pcm0: | pcm0: + <- nid=15 [audio mixer] [src: pcm, speaker] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio selector] [src: mic, monitor] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=18 [pin: Mic (Fixed)] [src: monitor] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 4 (nid 15 in 0): mute pcm0: +- ctl 5 (nid 15 in 1): mute pcm0: +- ctl 7 (nid 16 in 1): mute pcm0: +- ctl 8 (nid 16 in 2): mute pcm0: +- ctl 9 (nid 20 in ): mute pcm0: +- ctl 10 (nid 21 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 4 (nid 15 in 0): mute pcm0: +- ctl 8 (nid 16 in 2): mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 13 (nid 24 out): 0/40dB (3 steps) pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 5 (nid 15 in 1): mute pcm0: +- ctl 7 (nid 16 in 1): mute pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 17 (nid 35 out): -16/30dB (32 steps) + mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 5 (nid 15 in 1): mute pcm0: +- ctl 7 (nid 16 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 4730000, 10000; 0xffffff80dc556000 -> 4730000 pcm0: sndbuf_setmap 4930000, 10000; 0xffffff80dc566000 -> 4930000 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ahcich0: AHCI reset... ahcich0: SATA connect time=0ms status=00000113 ahcich0: ready wait time=57ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 ahcich1: AHCI reset... acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ahcich1: SATA offline status=00000004 ahcich1: AHCI reset done: phy reset found no device ahcich2: AHCI reset... ahcich2: SATA offline status=00000004 ahcich2: AHCI reset done: phy reset found no device battery0: battery initialization done, tried 1 times uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered ugen2.2: at usbus2 umass0: on usbus2 unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): SCSI status error (probe0:ata0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST csi:12,1,0,0 asc:24,0 (Invalid field in CDB): Command byte 1 is invalid (probe0:ata0:0:0:0): Error 22, Unretryable error (probe0:ata0:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata0:0:0:0): SCSI status error (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: NOT READY csi:0,0,bb,0 asc:3a,0 (Medium not present) (probe0:ata0:0:0:0): Error 6, Unretryable error umass0:4:0:-1: Attached to scbus4 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 1.x device ada0: Serial Number 080109BB0F00WDHENE2C ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 SATA 1.x device pass0: Serial Number 080109BB0F00WDHENE2C pass0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ata0 bus 0 scbus3 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 3.300MB/s transfers GEOM: new disk ada0 GEOM: new disk cd0 (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 SMP: AP CPU #1 Launched! (cd0:ata0:0:0:0): CAM status: SCSI Status Error cpu1 AP: (cd0:ata0:0:0:0): SCSI status: Check Condition ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff (cd0:ata0:0:0:0): SCSI sense: NOT READY csi:0,0,bb,0 asc:3a,0 (Medium not present) lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff (cd0: timer: 0x000100ef therm: 0x00010200 err: 0x000000f0 pmc: 0x00010400ata0:0: cmci: 0x000000000: 0): CPU1: local APIC error 0x80Error 6, Unretryable error ioapic0: routing intpin 1 ( cd0 at ata0 bus 0 scbus3 target 0 lun 0ISA IRQ 1 cd0: ) to lapic 1 vector 48 Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 1 vector 50 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 52 msi: Assigning MSI IRQ 258 to local APIC 1 vector 53 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:umass-sim0:0:0:0): SCSI status error (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:0): Error 6, Unretryable error pass2 at umass-sim0 bus 0 scbus4 target 0 lun 0 pass2: Removable Direct Access SCSI-0 device pass2: Serial Number 20060413092100000 pass2: 40.000MB/s transfers (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 20060413092100000 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY csi:0,0,bb,0 asc:3a,0 (Medium not present) (cd0:ata0:0:0:0): Error 6, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY csi:0,0,bb,0 asc:3a,0 (Medium not present) (cd0:ata0:0:0:0): Error 6, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY csi:0,0,bb,0 asc:3a,0 (Medium not present) (cd0:ata0:0:0:0): Error 6, Unretryable error GEOM: new disk da0 (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error Opened disk da0 -> 6 (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error Opened disk da0 -> 6 (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error Opened disk da0 -> 6 Root mount waiting for: usbus2 ugen2.3: at usbus2 Trying to mount root from ufs:/dev/ufs/root ct_to_ts([2010-09-29 18:28:32]) = 1285784912.000000000 start_init: trying /sbin/init WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. bge0: Disabling fastboot bge0: Disabling fastboot --Boundary-01=_kn4oMVrgZQv8UUb Content-Type: text/plain; charset="ISO-8859-1"; name="gigabyte.dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gigabyte.dmesg" cmdreg=0x0006, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03a8, revid=0xa2 domain=0, bus=0, slot=0, func=5 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b5, revid=0xa1 domain=0, bus=0, slot=0, func=6 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b4, revid=0xa1 domain=0, bus=0, slot=0, func=7 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03ad, revid=0xa1 domain=0, bus=0, slot=1, func=0 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03ae, revid=0xa1 domain=0, bus=0, slot=1, func=1 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03af, revid=0xa1 domain=0, bus=0, slot=1, func=2 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b0, revid=0xa1 domain=0, bus=0, slot=1, func=3 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b1, revid=0xa1 domain=0, bus=0, slot=1, func=4 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b2, revid=0xa1 domain=0, bus=0, slot=1, func=5 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b3, revid=0xa1 domain=0, bus=0, slot=1, func=6 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b6, revid=0xa1 domain=0, bus=0, slot=2, func=0 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03bc, revid=0xa1 domain=0, bus=0, slot=2, func=1 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03ba, revid=0xa1 domain=0, bus=0, slot=2, func=2 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x03b7, revid=0xa1 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x0270, revid=0xa2 domain=0, bus=0, slot=9, func=0 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0260, revid=0xa3 domain=0, bus=0, slot=10, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0264, revid=0xa3 domain=0, bus=0, slot=10, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x1c00, size 6, enabled map[24]: type I/O Port, range 32, base 0x1c80, size 6, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.APCS:0) pci_link35: Picked IRQ 20 with weight 0 pcib0: slot 10 INTA routed to irq 20 via \\_SB_.PCI0.APCS found-> vendor=0x10de, dev=0x0272, revid=0xa3 domain=0, bus=0, slot=10, func=2 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0400, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x026d, revid=0xa3 domain=0, bus=0, slot=11, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xe7006000, size 12, enabled pcib0: matched entry for 0.11.INTA (src \\_SB_.PCI0.APCF:0) pci_link28: Picked IRQ 21 with weight 0 pcib0: slot 11 INTA routed to irq 21 via \\_SB_.PCI0.APCF found-> vendor=0x10de, dev=0x026e, revid=0xa3 domain=0, bus=0, slot=11, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xe7007000, size 8, enabled pcib0: matched entry for 0.11.INTB (src \\_SB_.PCI0.APCL:0) pci_link36: Picked IRQ 22 with weight 0 pcib0: slot 11 INTB routed to irq 22 via \\_SB_.PCI0.APCL found-> vendor=0x10de, dev=0x0265, revid=0xa1 domain=0, bus=0, slot=13, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xf000, size 4, enabled found-> vendor=0x10de, dev=0x0266, revid=0xa1 domain=0, bus=0, slot=14, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9f0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbf0, size 2, enabled map[18]: type I/O Port, range 32, base 0x970, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb70, size 2, enabled map[20]: type I/O Port, range 32, base 0xe500, size 4, enabled map[24]: type Memory, range 32, base 0xe7004000, size 12, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.APSI:0) pci_link39: Picked IRQ 23 with weight 0 pcib0: slot 14 INTA routed to irq 23 via \\_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x0267, revid=0xa1 domain=0, bus=0, slot=15, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9e0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbe0, size 2, enabled map[18]: type I/O Port, range 32, base 0x960, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb60, size 2, enabled map[20]: type I/O Port, range 32, base 0xea00, size 4, enabled map[24]: type Memory, range 32, base 0xe7005000, size 12, enabled pcib0: matched entry for 0.15.INTA (src \\_SB_.PCI0.APSJ:0) pci_link40: Picked IRQ 20 with weight 1 pcib0: slot 15 INTA routed to irq 20 via \\_SB_.PCI0.APSJ found-> vendor=0x10de, dev=0x026f, revid=0xa2 domain=0, bus=0, slot=16, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x026c, revid=0xa2 domain=0, bus=0, slot=16, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks map[10]: type Memory, range 32, base 0xe7000000, size 14, enabled pcib0: matched entry for 0.16.INTB (src \\_SB_.PCI0.AAZA:0) pci_link33: Picked IRQ 21 with weight 1 pcib0: slot 16 INTB routed to irq 21 via \\_SB_.PCI0.AAZA found-> vendor=0x10de, dev=0x0269, revid=0xa3 domain=0, bus=0, slot=20, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xe7008000, size 12, enabled map[14]: type I/O Port, range 32, base 0xec00, size 3, enabled pcib0: matched entry for 0.20.INTA (src \\_SB_.PCI0.APCH:0) pci_link30: Picked IRQ 22 with weight 1 pcib0: slot 20 INTA routed to irq 22 via \\_SB_.PCI0.APCH pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pcib1: at device 3.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xe2000000-0xe4ffffff pcib1: prefetched decode 0xd0000000-0xdfffffff pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.XVRA - AE_NOT_FOUND pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x0391, revid=0xa1 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe2000000, size 24, enabled pcib1: requested memory range 0xe2000000-0xe2ffffff: good map[14]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib1: requested memory range 0xd0000000-0xdfffffff: good map[1c]: type Memory, range 64, base 0xe3000000, size 24, enabled pcib1: requested memory range 0xe3000000-0xe3ffffff: good map[24]: type I/O Port, range 32, base 0xc000, size 7, enabled pcib1: requested I/O range 0xc000-0xc07f: in range pcib0: matched entry for 0.3.INTA (src \\_SB_.PCI0.APC5:0) pci_link24: Picked IRQ 16 with weight 0 pcib0: slot 3 INTA routed to irq 16 via \\_SB_.PCI0.APC5 pcib1: slot 0 INTA is routed to irq 16 vgapci0: port 0xc000-0xc07f mem 0xe2000000-0xe2ffffff,0xd0000000-0xdfffffff,0xe3000000-0xe3ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 49 pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) ohci0: mem 0xe7006000-0xe7006fff irq 21 at device 11.0 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 usbus0: on ohci0 ehci0: mem 0xe7007000-0xe70070ff irq 22 at device 11.1 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 51 ehci0: Doorbell workaround enabled usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 13.0 on pci0 ata0: on atapci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=10 stat1=00 devices=0x30000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 52 ata1: on atapci0 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 53 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe500-0xe50f mem 0xe7004000-0xe7004fff irq 23 at device 14.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 ata2: on atapci1 ata2: SATA connect time=0ms status=00000113 ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: on atapci1 ata3: SATA connect timeout status=00000000 atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xea00-0xea0f mem 0xe7005000-0xe7005fff irq 20 at device 15.0 on pci0 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 55 ata4: on atapci2 ata4: SATA connect time=0ms status=00000113 ata4: reset tp1 mask=01 ostat0=50 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata5: on atapci2 ata5: SATA connect timeout status=00000000 pcib2: at device 16.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xe5000000-0xe6ffffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1113, dev=0x1216, revid=0x11 domain=0, bus=2, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd000, size 8, enabled pcib2: requested I/O range 0xd000-0xd0ff: in range map[14]: type Memory, range 32, base 0xe6000000, size 10, enabled pcib2: requested memory range 0xe6000000-0xe60003ff: good pcib2: matched entry for 2.7.INTA (src \\_SB_.PCI0.APC2:0) pci_link21: Picked IRQ 17 with weight 0 pcib2: slot 7 INTA routed to irq 17 via \\_SB_.PCI0.APC2 dc0: port 0xd000-0xd0ff mem 0xe6000000-0xe60003ff irq 17 at device 7.0 on pci2 miibus0: on dc0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x000749, model 0x0001, rev. 1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: XX:XX:XX:XX:XX:XX ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 56 hdac0: mem 0xe7000000-0xe7003fff irq 21 at device 16.1 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 nfe0: port 0xec00-0xec07 mem 0xe7008000-0xe7008fff irq 22 at device 20.0 on pci0 miibus1: on nfe0 rgephy0: PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: XX:XX:XX:XX:XX:XX attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfeff0000-0xfeff03ff irq 0,8 on acpi0 hpet0: vendor 0x10de, rev 0x1, 25000000Hz, 3 timers, legacy route hpet0: t0: irqs 0x00ff3efa (31), periodic hpet0: t1: irqs 0x00ff3efa (31) hpet0: t2: irqs 0x00ff3efa (31) Timecounter "HPET" frequency 25000000 Hz quality 900 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 58 Event timer "HPET" frequency 25000000 Hz quality 450 Event timer "HPET1" frequency 25000000 Hz quality 440 Event timer "HPET2" frequency 25000000 Hz quality 440 atrtc0: port 0x70-0x73 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 59 Event timer "RTC" frequency 32768 Hz quality 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 60 uart0: fast interrupt psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 61 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 62 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 acpi0: wakeup code va 0xffffff81b193c000 pa 0x4000 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0: at flags 0x180 on isa0 sc0: VGA <16 virtual consoles, flags=0x380> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices acpi_perf0: on cpu0 coretemp0: on cpu0 coretemp0: Setting TjMax=100 coretemp1: on cpu1 coretemp1: Setting TjMax=100 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est1 attach returned 6 coretemp2: on cpu2 coretemp2: Setting TjMax=100 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est2 attach returned 6 coretemp3: on cpu3 coretemp3: Setting TjMax=100 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est3 attach returned 6 Device configuration finished. linprocfs registered procfs registered Timecounter "TSC" frequency 2400026211 Hz quality -100 lapic: Divisor 2, Frequency 133334840 Hz Timecounters tick every 10.000 msec vlan: initialized, using hash tables with chaining Linux ELF exec handler installed lo0: bpf attached ata0: Identifying devices: 00030000 ata0: New devices: 00030000 GEOM_SCHED: Loading: mp = 0xffffffff809e8e60, g_sched_class = 0xffffffff809e8e60. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: setting UDMA100 ad4: 305244MB at ata2-master UDMA100 SATA 1.5Gb/s ad4: 625140335 sectors [620178C/16H/63S] 16 sectors/interrupt 1 depth queue ata3: Identifying devices: 00000000 ata3: New devices: 00000000 ata4: Identifying devices: 00000001 ata4: New devices: 00000001 GEOM: new disk ad4 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: setting UDMA100 ad8: 476940MB at ata4-master UDMA100 SATA 1.5Gb/s ad8: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue ata5: Identifying devices: 00000000 ata5: New devices: 00000000 hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC888 hdac0: HDA Codec ID: 0x10ec0888 hdac0: Vendor: 0x10ec hdac0: Device: 0x0888 hdac0: Revision: 0x00 hdac0: Stepping: 0x01 hdac0: PCI Subvendor: 0xa0021458 hdac0: Found audio FG nid=1 startnode=2 endnode=39 total=37 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000003 NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 20 0x01014410 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 4 hdac0: nid 21 0x01011412 as 1 seq 2 Line-out Jack jack 1 loc 1 color Black misc 4 hdac0: nid 22 0x01016411 as 1 seq 1 Line-out Jack jack 1 loc 1 color Orange misc 4 hdac0: nid 23 0x01012414 as 1 seq 4 Line-out Jack jack 1 loc 1 color Grey misc 4 hdac0: nid 24 0x01a19c40 as 4 seq 0 Mic Jack jack 1 loc 1 color Pink misc 12 hdac0: nid 25 0x02a19c50 as 5 seq 0 Mic Jack jack 1 loc 2 color Pink misc 12 hdac0: nid 26 0x01813441 as 4 seq 1 Line-in Jack jack 1 loc 1 color Blue misc 4 hdac0: nid 27 0x02214c20 as 2 seq 0 Headphones Jack jack 1 loc 2 color Green misc 12 hdac0: nid 28 0x9933014f as 4 seq 15 CD Fixed jack 3 loc 25 color Unknown misc 1 hdac0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdac0: nid 30 0x99430130 as 3 seq 0 SPDIF-out Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 31 0x99c30160 as 6 seq 0 SPDIF-in Fixed jack 3 loc 25 color Unknown misc 1 hdac0: Patched pins configuration: hdac0: nid 20 0x01014410 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 4 hdac0: nid 21 0x01011412 as 1 seq 2 Line-out Jack jack 1 loc 1 color Black misc 4 hdac0: nid 22 0x01016411 as 1 seq 1 Line-out Jack jack 1 loc 1 color Orange misc 4 hdac0: nid 23 0x01012414 as 1 seq 4 Line-out Jack jack 1 loc 1 color Grey misc 4 hdac0: nid 24 0x01a19c40 as 4 seq 0 Mic Jack jack 1 loc 1 color Pink misc 12 hdac0: nid 25 0x02a19c50 as 5 seq 0 Mic Jack jack 1 loc 2 color Pink misc 12 hdac0: nid 26 0x01813441 as 4 seq 1 Line-in Jack jack 1 loc 1 color Blue misc 4 hdac0: nid 27 0x02214c20 as 2 seq 0 Headphones Jack jack 1 loc 2 color Green misc 12 hdac0: nid 28 0x9933014f as 4 seq 15 CD Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 30 0x99430130 as 3 seq 0 SPDIF-out Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 31 0x99c30160 as 6 seq 0 SPDIF-in Fixed jack 3 loc 25 color Unknown misc 1 hdac0: 6 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Pin nid=22 seq=1 hdac0: Pin nid=21 seq=2 hdac0: Pin nid=23 seq=4 hdac0: Association 1 (2) out: hdac0: Pin nid=27 seq=0 hdac0: Association 2 (3) out: hdac0: Pin nid=30 seq=0 hdac0: Association 3 (4) in: hdac0: Pin nid=24 seq=0 hdac0: Pin nid=26 seq=1 hdac0: Pin nid=28 seq=15 hdac0: Association 4 (5) in: hdac0: Pin nid=25 seq=0 hdac0: Association 5 (6) in: hdac0: Pin nid=31 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Pin 22 traced to DAC 3 hdac0: Pin 21 traced to DAC 4 hdac0: Pin 23 traced to DAC 5 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 27 traced to DAC 37 hdac0: Association 1 (2) trace succeeded hdac0: Tracing association 2 (3) hdac0: Pin 30 traced to DAC 6 hdac0: Association 2 (3) trace succeeded hdac0: Tracing association 3 (4) hdac0: Pin 24 traced to ADC 8 hdac0: Pin 26 traced to ADC 8 hdac0: Pin 28 traced to ADC 8 hdac0: Association 3 (4) trace succeeded hdac0: Tracing association 4 (5) hdac0: Pin 25 traced to ADC 9 hdac0: Association 4 (5) trace succeeded hdac0: Tracing association 5 (6) hdac0: Pin 31 traced to ADC 10 hdac0: Association 5 (6) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 11 to out hdac0: nid 11 is input monitor hdac0: Tracing nid 34 to out hdac0: Tracing nid 35 to out hdac0: Tracing other input monitors hdac0: Tracing nid 24 to out hdac0: Tracing nid 25 to out hdac0: Tracing nid 26 to out hdac0: Tracing nid 28 to out hdac0: Tracing nid 31 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x00000011 hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: hdac0: nid: 3 hdac0: Name: audio output hdac0: Widget cap: 0x00000011 hdac0: STEREO hdac0: Association: 0 (0x00000002) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: hdac0: nid: 4 hdac0: Name: audio output hdac0: Widget cap: 0x00000011 hdac0: STEREO hdac0: Association: 0 (0x00000004) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: hdac0: nid: 5 hdac0: Name: audio output hdac0: Widget cap: 0x00000011 hdac0: STEREO hdac0: Association: 0 (0x00000010) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: hdac0: nid: 6 hdac0: Name: audio output hdac0: Widget cap: 0x00000211 hdac0: DIGITAL STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x001e05e0 hdac0: 16 20 24 32 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 3 (0x00008003) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 1 hdac0: | hdac0: + <- nid=35 [audio mixer] hdac0: hdac0: nid: 9 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 4 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 1 hdac0: | hdac0: + <- nid=34 [audio mixer] hdac0: hdac0: nid: 10 hdac0: Name: audio input hdac0: Widget cap: 0x00100391 hdac0: DIGITAL UNSOL STEREO hdac0: Association: 5 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x001e0560 hdac0: 16 20 24 32 bits, 44 48 96 192 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=31 [pin: SPDIF-in (Fixed)] hdac0: hdac0: nid: 11 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 3 (0x00008003) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 10 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + <- nid=28 [pin: CD (Fixed)] hdac0: + <- nid=29 [beep widget] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Line-out (Black Jack)] hdac0: + [DISABLED] <- nid=22 [pin: Line-out (Orange Jack)] hdac0: + [DISABLED] <- nid=23 [pin: Line-out (Grey Jack)] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm, mix hdac0: Output amp: 0x00051f1f hdac0: mute=0 step=31 size=5 offset=31 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 13 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000002) hdac0: OSS: pcm, mix hdac0: Output amp: 0x00051f1f hdac0: mute=0 step=31 size=5 offset=31 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=3 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 14 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000004) hdac0: OSS: pcm, mix hdac0: Output amp: 0x00051f1f hdac0: mute=0 step=31 size=5 offset=31 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=4 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 15 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000010) hdac0: OSS: pcm, mix hdac0: Output amp: 0x00051f1f hdac0: mute=0 step=31 size=5 offset=31 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=5 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Line-out (Green Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000003e hdac0: TRQD PDC HP OUT IN hdac0: Pin config: 0x01014410 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: + [DISABLED] <- nid=15 [audio mixer] hdac0: + [DISABLED] <- nid=38 [audio mixer] hdac0: hdac0: nid: 21 hdac0: Name: pin: Line-out (Black Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000004) hdac0: Pin cap: 0x0000003e hdac0: TRQD PDC HP OUT IN hdac0: Pin config: 0x01011412 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] hdac0: + [DISABLED] <- nid=13 [audio mixer] hdac0: + <- nid=14 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=15 [audio mixer] hdac0: + [DISABLED] <- nid=38 [audio mixer] hdac0: hdac0: nid: 22 hdac0: Name: pin: Line-out (Orange Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000002) hdac0: Pin cap: 0x00000036 hdac0: TRQD PDC OUT IN hdac0: Pin config: 0x01016411 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] hdac0: + <- nid=13 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: + [DISABLED] <- nid=15 [audio mixer] hdac0: + [DISABLED] <- nid=38 [audio mixer] hdac0: hdac0: nid: 23 hdac0: Name: pin: Line-out (Grey Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000010) hdac0: Pin cap: 0x00000036 hdac0: TRQD PDC OUT IN hdac0: Pin config: 0x01012414 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] hdac0: + [DISABLED] <- nid=13 [audio mixer] hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: + <- nid=15 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=38 [audio mixer] hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x0000373e hdac0: TRQD PDC HP OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x01a19c40 hdac0: Pin control: 0x00000025 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: + [DISABLED] <- nid=15 [audio mixer] hdac0: + [DISABLED] <- nid=38 [audio mixer] hdac0: hdac0: nid: 25 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 4 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x0000373e hdac0: TRQD PDC HP OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x02a19c50 hdac0: Pin control: 0x00000025 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: + [DISABLED] <- nid=15 [audio mixer] hdac0: + [DISABLED] <- nid=38 [audio mixer] hdac0: hdac0: nid: 26 hdac0: Name: pin: Line-in (Blue Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 3 (0x00000002) hdac0: OSS: line (line) hdac0: Pin cap: 0x0000373e hdac0: TRQD PDC HP OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x01813441 hdac0: Pin control: 0x00000025 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: + [DISABLED] <- nid=15 [audio mixer] hdac0: + [DISABLED] <- nid=38 [audio mixer] hdac0: hdac0: nid: 27 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: Pin cap: 0x0000373e hdac0: TRQD PDC HP OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x02214c20 hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 5 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] hdac0: + [DISABLED] <- nid=13 [audio mixer] hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: + [DISABLED] <- nid=15 [audio mixer] hdac0: + <- nid=38 [audio mixer] (selected) hdac0: hdac0: nid: 28 hdac0: Name: pin: CD (Fixed) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Association: 3 (0x00008000) hdac0: OSS: cd (cd) hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x9933014f hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 29 hdac0: Name: beep widget hdac0: Widget cap: 0x00700000 hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: hdac0: nid: 30 hdac0: Name: pin: SPDIF-out (Fixed) hdac0: Widget cap: 0x00400300 hdac0: DIGITAL hdac0: Association: 2 (0x00000001) hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x99430130 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] hdac0: hdac0: nid: 31 hdac0: Name: pin: SPDIF-in (Fixed) hdac0: Widget cap: 0x00400200 hdac0: DIGITAL hdac0: Association: 5 (0x00000001) hdac0: OSS: dig1 (dig1) hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x99c30160 hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 34 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 4 (0x00000001) hdac0: OSS: speaker, monitor hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 11 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + <- nid=25 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: CD (Fixed)] hdac0: + <- nid=29 [beep widget] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Line-out (Black Jack)] hdac0: + [DISABLED] <- nid=22 [pin: Line-out (Orange Jack)] hdac0: + [DISABLED] <- nid=23 [pin: Line-out (Grey Jack)] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 35 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 3 (0x00008003) hdac0: OSS: speaker, line, mic, cd, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 11 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + <- nid=28 [pin: CD (Fixed)] hdac0: + <- nid=29 [beep widget] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Line-out (Black Jack)] hdac0: + [DISABLED] <- nid=22 [pin: Line-out (Orange Jack)] hdac0: + [DISABLED] <- nid=23 [pin: Line-out (Grey Jack)] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 37 hdac0: Name: audio output hdac0: Widget cap: 0x00000011 hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: hdac0: nid: 38 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: pcm, mix hdac0: Output amp: 0x00051f1f hdac0: mute=0 step=31 size=5 offset=31 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=37 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 3 4 5 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x00060160 pcm0: 16 20 bits, 44 48 96 KHz pcm0: ADC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=20 [pin: Line-out (Green Jack)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=22 [pin: Line-out (Orange Jack)] pcm0: | pcm0: + <- nid=13 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=3 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=21 [pin: Line-out (Black Jack)] pcm0: | pcm0: + <- nid=14 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=4 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=23 [pin: Line-out (Grey Jack)] pcm0: | pcm0: + <- nid=15 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=5 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio mixer] [src: speaker, line, mic, cd, mix] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=28 [pin: CD (Fixed)] [src: cd] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=28 [pin: CD (Fixed)] [src: cd] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 13 (nid 12 out): -46/0dB (32 steps) pcm0: +- ctl 14 (nid 12 in 0): mute pcm0: +- ctl 15 (nid 12 in 1): mute pcm0: +- ctl 16 (nid 13 out): -46/0dB (32 steps) pcm0: +- ctl 17 (nid 13 in 0): mute pcm0: +- ctl 18 (nid 13 in 1): mute pcm0: +- ctl 19 (nid 14 out): -46/0dB (32 steps) pcm0: +- ctl 20 (nid 14 in 0): mute pcm0: +- ctl 21 (nid 14 in 1): mute pcm0: +- ctl 22 (nid 15 out): -46/0dB (32 steps) pcm0: +- ctl 23 (nid 15 in 0): mute pcm0: +- ctl 24 (nid 15 in 1): mute pcm0: +- ctl 25 (nid 20 in ): mute pcm0: +- ctl 27 (nid 21 in ): mute pcm0: +- ctl 29 (nid 22 in ): mute pcm0: +- ctl 31 (nid 23 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 14 (nid 12 in 0): mute pcm0: +- ctl 17 (nid 13 in 0): mute pcm0: +- ctl 20 (nid 14 in 0): mute pcm0: +- ctl 23 (nid 15 in 0): mute pcm0: pcm0: CD Volume (OSS: cd) pcm0: | pcm0: +- ctl 7 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 56 (nid 35 in 4): mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 34 (nid 24 out): 0/30dB (4 steps) pcm0: +- ctl 52 (nid 35 in 0): mute pcm0: pcm0: Line-in Volume (OSS: line) pcm0: | pcm0: +- ctl 38 (nid 26 out): 0/30dB (4 steps) pcm0: +- ctl 54 (nid 35 in 2): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 8 (nid 11 in 5): -34/12dB (32 steps) + mute pcm0: +- ctl 57 (nid 35 in 5): mute pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 1 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 52 (nid 35 in 0): mute pcm0: +- ctl 54 (nid 35 in 2): mute pcm0: +- ctl 56 (nid 35 in 4): mute pcm0: +- ctl 57 (nid 35 in 5): mute pcm0: +- ctl 62 (nid 35 in 10): mute pcm0: pcm0: Input Mix Level (OSS: mix) pcm0: | pcm0: +- ctl 3 (nid 11 in 0): -34/12dB (32 steps) + mute pcm0: +- ctl 5 (nid 11 in 2): -34/12dB (32 steps) + mute pcm0: +- ctl 7 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 8 (nid 11 in 5): -34/12dB (32 steps) + mute pcm0: +- ctl 15 (nid 12 in 1): mute pcm0: +- ctl 18 (nid 13 in 1): mute pcm0: +- ctl 21 (nid 14 in 1): mute pcm0: +- ctl 24 (nid 15 in 1): mute pcm0: +- ctl 62 (nid 35 in 10): mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 15 (nid 12 in 1): mute pcm0: +- ctl 18 (nid 13 in 1): mute pcm0: +- ctl 21 (nid 14 in 1): mute pcm0: +- ctl 24 (nid 15 in 1): mute pcm0: pcm0: Enabling Soft PCM volume pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Soft PCM mixer ENABLED pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 1affb0000, 4000; 0xffffff81b194a000 -> 1affb0000 pcm0: sndbuf_setmap 46c0000, 4000; 0xffffff81b195a000 -> 46c0000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 37 pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x00060160 pcm1: 16 20 bits, 44 48 96 KHz pcm1: ADC: 9 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=27 [pin: Headphones (Green Jack)] pcm1: | pcm1: + <- nid=38 [audio mixer] [src: pcm, mix] pcm1: | pcm1: + <- nid=37 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: pcm1: nid=9 [audio input] pcm1: | pcm1: + <- nid=34 [audio mixer] [src: speaker, monitor] pcm1: | pcm1: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 39 (nid 27 in ): mute pcm1: +- ctl 63 (nid 38 out): -46/0dB (32 steps) pcm1: +- ctl 64 (nid 38 in 0): mute pcm1: +- ctl 65 (nid 38 in 1): mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 64 (nid 38 in 0): mute pcm1: pcm1: Microphone2 Volume (OSS: monitor) pcm1: | pcm1: +- ctl 36 (nid 25 out): 0/30dB (4 steps) pcm1: +- ctl 42 (nid 34 in 1): mute pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: | pcm1: +- ctl 46 (nid 34 in 5): mute pcm1: pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 2 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 42 (nid 34 in 1): mute pcm1: +- ctl 46 (nid 34 in 5): mute pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: | pcm1: +- ctl 65 (nid 38 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain) pcm1: | pcm1: +- ctl 65 (nid 38 in 1): mute pcm1: pcm1: Enabling Soft PCM volume pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "speaker": pcm1: Mixer "mix": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Mixer "monitor": pcm1: Soft PCM mixer ENABLED pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 46d0000, 4000; 0xffffff81b196a000 -> 46d0000 pcm1: sndbuf_setmap 4f10000, 4000; 0xffffff81b197a000 -> 4f10000 pcm2: at cad 0 nid 1 on hdac0 pcm2: +--------------------------------------+ pcm2: | DUMPING PCM Playback/Record Channels | pcm2: +--------------------------------------+ pcm2: pcm2: Playback: pcm2: pcm2: Stream cap: 0x00000005 pcm2: AC3 PCM pcm2: PCM cap: 0x001e05e0 pcm2: 16 20 24 32 bits, 44 48 88 96 192 KHz pcm2: DAC: 6 pcm2: pcm2: Record: pcm2: pcm2: Stream cap: 0x00000005 pcm2: AC3 PCM pcm2: PCM cap: 0x001e0560 pcm2: 16 20 24 32 bits, 44 48 96 192 KHz pcm2: ADC: 10 pcm2: pcm2: +-------------------------------+ pcm2: | DUMPING Playback/Record Paths | pcm2: +-------------------------------+ pcm2: pcm2: Playback: pcm2: pcm2: nid=30 [pin: SPDIF-out (Fixed)] pcm2: | pcm2: + <- nid=6 [audio output] [src: pcm] pcm2: pcm2: Record: pcm2: pcm2: nid=10 [audio input] pcm2: | pcm2: + <- nid=31 [pin: SPDIF-in (Fixed)] [src: dig1] pcm2: pcm2: +-------------------------+ pcm2: | DUMPING Volume Controls | pcm2: +-------------------------+ pcm2: pcm2: Forcing Soft PCM volume pcm2: Forcing master volume with PCM pcm2: Mixer "vol" -> "none": child=0x00000010 pcm2: Mixer "pcm": parent="vol" pcm2: Soft PCM mixer ENABLED pcm2: clone manager: deadline=750ms flags=0x8000001e pcm2: sndbuf_setmap 4f30000, 4000; 0xffffff81b198a000 -> 4f30000 pcm2: sndbuf_setmap 46e0000, 4000; 0xffffff81b199a000 -> 46e0000 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:0:0): SCSI status error (probe0:ata0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (probe0:ata0:0:0:0): Error 22, Unretryable error (probe0:ata0:0:0:0): Down reving Protocol Version from 2 to 0? unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 (probe1:ata0:0:1:0): SCSI status error (probe1:ata0:0:1:0): INQUIRY. CDB: 12 1 0 0 ff 0 (probe1:ata0:0:1:0): CAM status: SCSI Status Error (probe1:ata0:0:1:0): SCSI status: Check Condition (probe1:ata0:0:1:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB): Command byte 1 bit 0 is invalid (probe1:ata0:0:1:0): Error 22, Unretryable error (probe1:ata0:0:1:0): Down reving Protocol Version from 2 to 0? (probe0:ata0:0:0:0): SCSI status error (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (probe0:ata0:0:0:0): Error 6, Unretryable error (probe1:ata0:0:1:0): SCSI status error (probe1:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe1:ata0:0:1:0): CAM status: SCSI Status Error (probe1:ata0:0:1:0): SCSI status: Check Condition (probe1:ata0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (probe1:ata0:0:1:0): Retrying command (per sense data) (probe1:ata0:0:1:0): SCSI status error (probe1:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe1:ata0:0:1:0): CAM status: SCSI Status Error (probe1:ata0:0:1:0): SCSI status: Check Condition (probe1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe1:ata0:0:1:0): Error 6, Unretryable error pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 3.300MB/s transfers pass1 at ata0 bus 0 scbus0 target 1 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 3.300MB/s transfers (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 SMP: AP CPU #1 Launched! (cd0:ata0:0:0:0): CAM status: SCSI Status Error cpu1 AP: (cd0:ata0:0:0:0): SCSI status: Check Condition ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff (cd0: timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400ata0:0: cmci: 0x000000000: 0): Error 6, Unretryable errorSMP: AP CPU #2 Launched! cd0 at ata0 bus 0 scbus0 target 0 lun 0 cpu2 AP: cd0: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Removable CD-ROM SCSI-0 device lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff cd0: 3.300MB/s transfers timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x00000000 cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x00000000 ioapic0: routing intpin 1 (CPU1: local APIC error 0x80CCPPUU23:: llooccaall AAPPIICC eerrrroorr 00xx8800ISA IRQ 1 ) to lapic 1 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 14 ((cd1:ISA IRQ 14ata0:0:) to lapic 1 vector 491: 0): ioapic0: routing intpinS C1S5I st(atus errorISA IRQ 15 (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 ) to lapic 2 vector 49 (cd1:ata0:0:1:0): CAM status: SCSI Status Error ioapic0: routing intpin 16 ( (cd1:ata0:0:1:0): SCSI status: Check ConditionPCI IRQ 16 (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)) to lapic 3 vector 49 (cd1: ata0:0:1:0): Error 6, Unretryable errorioapic0: routing intpin 20 ( cd1 at ata0 bus 0 scbus0 target 1 lun 0PCI IRQ 20 cd1: ) to lapic 1 vector 50 Removable CD-ROM SCSI-0 device ioapic0: routing intpin 21 ( cd1: 3.300MB/s transfersPCI IRQ 21) to lapic 2 vector 50 cd1: Attempt to query device size failed: NOT READY, Medium not present ioapic0: routing intpin 22 ( PCI IRQ 22) to lapic 3 vector 50 GEOM: new disk ad8 GEOM: new disk cd0 GEOM: new disk cd1 uhub0: 8 ports with 8 removable, self powered (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata0:0:0:0): Error 6, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata0:0:0:0): Error 6, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata0:0:0:0): Error 6, Unretryable error (cd1:ata0:0:1:0): SCSI status error (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:1:0): CAM status: SCSI Status Error (cd1:ata0:0:1:0): SCSI status: Check Condition (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd1:ata0:0:1:0): Error 6, Unretryable error (cd1:ata0:0:1:0): SCSI status error (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:1:0): CAM status: SCSI Status Error (cd1:ata0:0:1:0): SCSI status: Check Condition (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd1:ata0:0:1:0): Error 6, Unretryable error (cd1:ata0:0:1:0): SCSI status error (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:1:0): CAM status: SCSI Status Error (cd1:ata0:0:1:0): SCSI status: Check Condition (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd1:ata0:0:1:0): Error 6, Unretryable error GEOM_MIRROR: Device mirror/gm0 launched (2/2). Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub1: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/mirror/gm0a ct_to_ts([2010-09-29 18:19:12]) = 1285784352.000000000 start_init: trying /sbin/init WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. bridge0: bpf attached bridge0: Ethernet address: XX:XX:XX:XX:XX:XX --Boundary-01=_kn4oMVrgZQv8UUb-- --nextPart2985025.74bEjDE2hS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkyjiesACgkQUaaFgP9pFrLJkwCZAXHj7PbGpllGonJGR0jvWOzw UBcAn1saVoomFA0dEsnfGM51F3PXn2OW =7eCW -----END PGP SIGNATURE----- --nextPart2985025.74bEjDE2hS-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 19:35:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED2F1065672; Wed, 29 Sep 2010 19:35:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D32248FC08; Wed, 29 Sep 2010 19:35:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 197145C43; Wed, 29 Sep 2010 21:35:06 +0200 (CEST) Message-ID: <4CA394EB.7090902@FreeBSD.org> Date: Wed, 29 Sep 2010 21:35:07 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: Renato Botelho References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> <20100929174434.GA75072@freebsd.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090609020204040609070302" Cc: Roman Divacky , Derek Tattersall , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 19:35:07 -0000 This is a multi-part message in MIME format. --------------090609020204040609070302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2010-09-29 20:22, Renato Botelho wrote: > It's using drand48() instead of rand() ... > GCC libc: > garga@botelhor:~/testes> ./test > random value 0.396465 > > clang libc: > garga@botelhor:~/testes> ./test > random value -inf Renato, Derek, could you please apply the attached patch for ldexp, rebuild your libc (with clang), and run your random test program again? --------------090609020204040609070302 Content-Type: text/plain; name="ldexp-amd64.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ldexp-amd64.diff" diff --git a/lib/libc/amd64/gen/ldexp.c b/lib/libc/amd64/gen/ldexp.c index 43107fc..ecf1ff8 100644 --- a/lib/libc/amd64/gen/ldexp.c +++ b/lib/libc/amd64/gen/ldexp.c @@ -36,6 +36,8 @@ static char sccsid[] = "@(#)ldexp.c 8.1 (Berkeley) 6/4/93"; #include __FBSDID("$FreeBSD$"); +#include + /* * ldexp(value, exp): return value * (2 ** exp). * @@ -49,12 +51,16 @@ __FBSDID("$FreeBSD$"); double ldexp (double value, int exp) { - double temp, texp, temp2; + double temp, texp; +#ifdef __clang__ + volatile +#endif + double temp2; texp = exp; #ifdef __GNUC__ __asm ("fscale " - : "=u" (temp2), "=t" (temp) - : "0" (texp), "1" (value)); + : "=t" (temp), "=u" (temp2) + : "0" (value), "1" (texp)); #else #error unknown asm #endif --------------090609020204040609070302-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 19:47:53 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210F41065670; Wed, 29 Sep 2010 19:47:53 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 57B588FC24; Wed, 29 Sep 2010 19:47:52 +0000 (UTC) Received: by wwb17 with SMTP id 17so1544118wwb.31 for ; Wed, 29 Sep 2010 12:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=N/2dIwTPJ61OqofHixceyoud8f32Tw2k2UrrtrOxUPw=; b=EYnJHLZ89uZeEaPNJCiRTgzjX0WG/IrE7aGakMYZm8WePkq+dSgv48MYzZ+CBOIKok 8oDAFIO1MAsOjjfxGScEj3ZnHMR4lMOkCbm2fww01ZcPivImnHRHmGOLXw1lVWvalKeW bn9AqoZfJG3rtwcp8At1+JmRlHwhs1TusyVBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=J4ij/8jyI+a53OEKJxkyBGDeap1su0tX6mItIYuC6TDiQLvyrzeKC6lrtHqb7pqsle I8d72xh4hSiwvPbiSLyFd/fTjRvbUgHH0JzYRTNnSr3+erjfqnSzfoQur46ClhMcRkMd mfE641ovXPvkB1Gz+4nBEPzU+JNip5/GITIl8= Received: by 10.216.159.213 with SMTP id s63mr2976848wek.78.1285789670697; Wed, 29 Sep 2010 12:47:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 12:47:30 -0700 (PDT) In-Reply-To: <4CA394EB.7090902@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> <20100929174434.GA75072@freebsd.org> <4CA394EB.7090902@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 16:47:30 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Roman Divacky , Derek Tattersall , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 19:47:53 -0000 On Wed, Sep 29, 2010 at 4:35 PM, Dimitry Andric wrote: > On 2010-09-29 20:22, Renato Botelho wrote: >> >> It's using drand48() instead of rand() > > ... >> >> GCC libc: >> garga@botelhor:~/testes> =A0./test >> random value 0.396465 >> >> clang libc: >> garga@botelhor:~/testes> =A0./test >> random value -inf > > Renato, Derek, could you please apply the attached patch for ldexp, > rebuild your libc (with clang), and run your random test program again? > Worked perfectly here \o/ Thank you --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 19:49:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E8971065698; Wed, 29 Sep 2010 19:49:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB1FC8FC1B; Wed, 29 Sep 2010 19:49:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694] (unknown [IPv6:2001:7b8:3a7:0:20e5:f9f9:5cd3:9694]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BD4E85C43; Wed, 29 Sep 2010 21:48:59 +0200 (CEST) Message-ID: <4CA3982D.4020605@FreeBSD.org> Date: Wed, 29 Sep 2010 21:49:01 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100928 Lanikai/3.1.5pre MIME-Version: 1.0 To: Renato Botelho References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> <20100929174434.GA75072@freebsd.org> <4CA394EB.7090902@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , Derek Tattersall , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 19:49:01 -0000 On 2010-09-29 21:47, Renato Botelho wrote: >> Renato, Derek, could you please apply the attached patch for ldexp, >> rebuild your libc (with clang), and run your random test program again? > > Worked perfectly here \o/ And what about perl? :) From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 20:05:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9DEF106566C; Wed, 29 Sep 2010 20:05:29 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DDF4C8FC08; Wed, 29 Sep 2010 20:05:28 +0000 (UTC) Received: by wwb17 with SMTP id 17so1570646wwb.31 for ; Wed, 29 Sep 2010 13:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=ERUEzlXCBkwIHmgWLRJTmqsAv9wQ/GOrFMdoRBZxLE8=; b=MIbOmmXkqvjfUY1tgh1ipmQ82EIyxQ8Xa/1pkqi7VenLPEte1Y/pAEeEVvDJXSvEOU vAI6JC3pDiL5xkwT287vuUUilrSBQYRIs9fpotPd64eeNtoKyU4W0J8HfxYbKfCFmIUO EZ30feZ51wKTngxee72i3JlQhZy2X5r9mqfWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=veXQhvcmjKkvm8OSFkyeLOUGotwbC8ajaRCyMtigaplxyA2Mr4EAUDPWbjJ78e7pm5 TVWn33pb55dB64YEtzE4ecYUOf2Curg4luyuOYmVnbEVweEW/m/T6OiPmfkpb9kAduv8 hUhiDvhI5UM9ViKInMVNndUx9EKBv2hRu3U2E= Received: by 10.227.136.1 with SMTP id p1mr2153878wbt.4.1285790255539; Wed, 29 Sep 2010 12:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Wed, 29 Sep 2010 12:57:15 -0700 (PDT) In-Reply-To: <4CA3982D.4020605@FreeBSD.org> References: <4C99A53E.7060707@FreeBSD.org> <20100929002843.GA5001@oriental.arm.org> <4CA2E00D.3080102@FreeBSD.org> <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> <20100929174434.GA75072@freebsd.org> <4CA394EB.7090902@FreeBSD.org> <4CA3982D.4020605@FreeBSD.org> From: Renato Botelho Date: Wed, 29 Sep 2010 16:57:15 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Roman Divacky , Derek Tattersall , current@freebsd.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 20:05:29 -0000 On Wed, Sep 29, 2010 at 4:49 PM, Dimitry Andric wrote: > On 2010-09-29 21:47, Renato Botelho wrote: >>> >>> Renato, Derek, could you please apply the attached patch for ldexp, >>> rebuild your libc (with clang), and run your random test program again? >> >> Worked perfectly here \o/ > > And what about perl? :) > Just fine :) garga@botelhor:~/testes> perl tmp.pl /tmp/_68PLsxOhY garga@botelhor:~/testes> perl tmp.pl /tmp/XUQhE_7DKY garga@botelhor:~/testes> perl tmp.pl /tmp/8VyPZdAWD7 garga@botelhor:~/testes> perl tmp.pl /tmp/3bdOmoPhL2 -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 20:41:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22CDB106566C; Wed, 29 Sep 2010 20:41:50 +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 3CD168FC08; Wed, 29 Sep 2010 20:41:48 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA04478; Wed, 29 Sep 2010 23:41:47 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P13TH-0004QK-GZ; Wed, 29 Sep 2010 23:41:47 +0300 Message-ID: <4CA3A48A.5070300@freebsd.org> Date: Wed, 29 Sep 2010 23:41:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CA0DA49.2090006@freebsd.org> In-Reply-To: <4CA0DA49.2090006@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 20:41:50 -0000 on 27/09/2010 20:54 Andriy Gapon said the following: > > It seems that minidump on amd64 is always dumping at least about 1GB of data > regardless of actual memory size and usage and thus can be even larger than > regular dump. > > Specifically, I suspect the following code: > for (va = VM_MIN_KERNEL_ADDRESS; va < MAX(KERNBASE + NKPT * NBPDR, > kernel_vm_end); va += NBPDR) { > i = (va >> PDPSHIFT) & ((1ul << NPDPEPGSHIFT) - 1); > /* > * We always write a page, even if it is zero. Each > * page written corresponds to 2MB of space > */ > ptesize += PAGE_SIZE; > > It seems that difference between KERNBASE and VM_MIN_KERNEL_ADDRESS is already > ~500G. Which means 500G divided by 2M equals 250K iterations/pages. Which is 1GB > of data. > > Looks like this came from amd64 KVA expansion. > And it seems a little bit wasteful? So perhaps we need to add another level of indirection? I.e. first dump contiguous array of "pseudo-pde" entries that would point to chunks of "pseudo-pte" entries, so that "pseudo-pte" entries could be sparse. This is instead of dumping 1GB of contiguous "pseudo-ptes" as we do now. A bit of work, though. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 21:12:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6CA9310656A4; Wed, 29 Sep 2010 21:12:53 +0000 (UTC) Date: Wed, 29 Sep 2010 21:12:53 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100929211253.GA1250@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 21:12:53 -0000 hi there, i wanted to ask if it would be possible to asjust glabel so that e.g. inserting a new media into a dvd-drive gets recognised and glabel displays the lablel right away. right now i use this shell alias to work around this issue: mdvd='sh -c ": 3>/dev/dvd" ; mount /media/dvd/ && cd /media/dvd/' cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 21:45:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C362C106564A; Wed, 29 Sep 2010 21:45:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C1F6D8FC13; Wed, 29 Sep 2010 21:45:58 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA05515; Thu, 30 Sep 2010 00:45:56 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P14TM-0004Vc-IU; Thu, 30 Sep 2010 00:45:56 +0300 Message-ID: <4CA3B393.8060206@icyb.net.ua> Date: Thu, 30 Sep 2010 00:45:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexander Best References: <20100929211253.GA1250@freebsd.org> In-Reply-To: <20100929211253.GA1250@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 21:45:59 -0000 on 30/09/2010 00:12 Alexander Best said the following: > hi there, > > i wanted to ask if it would be possible to asjust glabel so that e.g. inserting > a new media into a dvd-drive gets recognised and glabel displays the lablel > right away. Yes, of course, as soon as we have in kernel a programmatic way to know that media as changed. We don't have one right now... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 22:28:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83CF51065673 for ; Wed, 29 Sep 2010 22:28:19 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 511308FC1B for ; Wed, 29 Sep 2010 22:28:19 +0000 (UTC) Received: from [172.16.135.104] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o8TMSIxl053889 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 29 Sep 2010 15:28:18 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CA3BD7C.9080306@feral.com> Date: Wed, 29 Sep 2010 15:28:12 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> In-Reply-To: <4CA3B393.8060206@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 29 Sep 2010 15:28:18 -0700 (PDT) Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 22:28:19 -0000 On 9/29/2010 2:45 PM, Andriy Gapon wrote: > on 30/09/2010 00:12 Alexander Best said the following: >> hi there, >> >> i wanted to ask if it would be possible to asjust glabel so that e.g. inserting >> a new media into a dvd-drive gets recognised and glabel displays the lablel >> right away. > Yes, of course, as soon as we have in kernel a programmatic way to know that > media as changed. > We don't have one right now... > What announcement API would you like to add? If something like that was in place, I assure you that things would start to use it very quickly. From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 22:27:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7445D106566B; Wed, 29 Sep 2010 22:27:00 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh6.mail.rice.edu (mh6.mail.rice.edu [128.42.201.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBB68FC08; Wed, 29 Sep 2010 22:27:00 +0000 (UTC) Received: from mh6.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh6.mail.rice.edu (Postfix) with ESMTP id 6F08E28F7C0; Wed, 29 Sep 2010 17:26:59 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh6.mail.rice.edu, auth channel Received: from mh6.mail.rice.edu ([127.0.0.1]) by mh6.mail.rice.edu (mh6.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 0-VMDs98Spp3; Wed, 29 Sep 2010 17:26:59 -0500 (CDT) Received: from [10.209.194.120] (unknown [10.209.194.120]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh6.mail.rice.edu (Postfix) with ESMTPSA id 2BC5028F797; Wed, 29 Sep 2010 17:26:59 -0500 (CDT) Message-ID: <4CA3BD1E.5070807@rice.edu> Date: Wed, 29 Sep 2010 17:26:38 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Gapon References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> In-Reply-To: <4CA3A48A.5070300@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 29 Sep 2010 22:38:25 +0000 Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 22:27:00 -0000 On 9/29/2010 3:41 PM, Andriy Gapon wrote: > on 27/09/2010 20:54 Andriy Gapon said the following: >> It seems that minidump on amd64 is always dumping at least about 1GB of data >> regardless of actual memory size and usage and thus can be even larger than >> regular dump. >> >> Specifically, I suspect the following code: >> for (va = VM_MIN_KERNEL_ADDRESS; va< MAX(KERNBASE + NKPT * NBPDR, >> kernel_vm_end); va += NBPDR) { >> i = (va>> PDPSHIFT)& ((1ul<< NPDPEPGSHIFT) - 1); >> /* >> * We always write a page, even if it is zero. Each >> * page written corresponds to 2MB of space >> */ >> ptesize += PAGE_SIZE; >> >> It seems that difference between KERNBASE and VM_MIN_KERNEL_ADDRESS is already >> ~500G. Which means 500G divided by 2M equals 250K iterations/pages. Which is 1GB >> of data. >> >> Looks like this came from amd64 KVA expansion. >> And it seems a little bit wasteful? > So perhaps we need to add another level of indirection? > I.e. first dump contiguous array of "pseudo-pde" entries that would point to > chunks of "pseudo-pte" entries, so that "pseudo-pte" entries could be sparse. > This is instead of dumping 1GB of contiguous "pseudo-ptes" as we do now. > That would be the best approach. That said, for the foreseeable future, the kernel page table on amd64 will have two valid ranges, no more, no less. So, if it's much easier to modify minidump to deal with a page table that is assumed to have two contiguous parts, just do it. That assumption should remain valid for a few years. Alan From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 00:18:11 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85BD9106566B; Thu, 30 Sep 2010 00:18:11 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail940c35.nsolutionszone.com (mail940c35.nsolutionszone.com [209.235.152.130]) by mx1.freebsd.org (Postfix) with ESMTP id EA2A28FC16; Thu, 30 Sep 2010 00:18:10 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail940c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o8U0I80w010953; Thu, 30 Sep 2010 00:18:09 GMT Date: Wed, 29 Sep 2010 20:18:07 -0400 From: Derek Tattersall To: Dimitry Andric Message-ID: <20100930001807.GA13585@oriental.arm.org> References: <4CA3244D.7030907@FreeBSD.org> <20100929155659.GA82433@oriental.arm.org> <20100929173158.GA73653@freebsd.org> <20100929174434.GA75072@freebsd.org> <4CA394EB.7090902@FreeBSD.org> <4CA3982D.4020605@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA3982D.4020605@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-CSC: 0 X-CHA: v=1.1 cv=nRMQXXDkJm4awCcx+M7+jmO1Ng3APGd8nKmIJUVj4hw= c=1 sm=1 a=BUHArxkelXkA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=6I5d2MoRAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=47frlD_zMy04qv8A_w8A:9 a=RmONJNxu41WOLMb8b2UDDYS9pWoA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Renato Botelho , Roman Divacky , current@FreeBSD.org Subject: Re: Clang now builds world and kernel, on i386 and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 00:18:11 -0000 * Dimitry Andric [100929 17:05]: > On 2010-09-29 21:47, Renato Botelho wrote: > >> Renato, Derek, could you please apply the attached patch for ldexp, > >> rebuild your libc (with clang), and run your random test program again? > > > > Worked perfectly here \o/ > > And what about perl? :) Super! Thanks very much for this rapid fix. And perldoc -f works again. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 05:23:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1EB0106564A; Thu, 30 Sep 2010 05:23:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2608FC0C; Thu, 30 Sep 2010 05:23:52 +0000 (UTC) Received: by bwz15 with SMTP id 15so1487784bwz.13 for ; Wed, 29 Sep 2010 22:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=+MpEQ5KVrzY8+Vqn1ik6ZXIkhHwuGbORSKTbnznXwxw=; b=HiIKHRaJXplc6PK+3KRpQ1NMH94+O++18rlCUTBEbF+iNproYWCoRNlSoO4P4Karhy Ch3w9AX8sjevITv06JItB6NxSQ6YkFsTm/gRKDTwwGGyiXGCslapERQfJ973ude5wB4w p8fBvofsMIiOvd27xDnVkwY2Mupzkz120hOZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=Yu+ijXrZyKVFsrDNpqvsRcjj5utWv9AOlf8gfGdSnwMzCQZZsJw873eh789WxwoALa XgAISkzK29aay9DY3V3sQk6BTD4Xn1xmFS7S6afoCpxeknlBbxRaCNaQN832IaTpxj1/ Twrm3ooisL6FzYo6syHRX8+0Ukok83PpyywUo= Received: by 10.204.103.207 with SMTP id l15mr2052340bko.196.1285824231769; Wed, 29 Sep 2010 22:23:51 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id v7sm4681073bkx.4.2010.09.29.22.23.49 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 22:23:50 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA41ED6.5060208@FreeBSD.org> Date: Thu, 30 Sep 2010 08:23:34 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Naylor References: <201009291207.53146.naylor.b.david@gmail.com> <201009291820.02401.naylor.b.david@gmail.com> <4CA36869.7040205@FreeBSD.org> <201009292048.11194.naylor.b.david@gmail.com> In-Reply-To: <201009292048.11194.naylor.b.david@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------070406070505010906060903" Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 05:23:53 -0000 This is a multi-part message in MIME format. --------------070406070505010906060903 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit David Naylor wrote: > On Wednesday 29 September 2010 18:25:13 Alexander Motin wrote: >> David Naylor wrote: >>> On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: >>>> What do you try to actually achieve? >>> I was trying to boot a system and it was panicking due to stray >>> interrupts. It turned out to be caused by HPET. I found >>> `hint.hpet.0.clock=0' which fixed the problem. >>> >>> This means HPET does not work on any of my machines. The other one's >>> symptoms are hda losing interrupts after a period of up-time. >> What chipset do you use? Nvidia MCP5x? Could you send me your verbose >> dmesg? > > Yes, the one is a MCP51, the other is a ICH8M. > > The desktop is a Gigabyte N650SLI-DS4L. Its symptom is hda losing interrupts > after a period of time. There are too many reports about different lost interrupts problems on different controllers of MCP5x. I don't know the reason. Attached patch should disable using regular HPET interrupts on NVidia chipsets. I hope it will work as workaround. May be it is too aggressive, but better to be safe then sorry. I assume that legacy_route mode may still work fine there. It would be nice to test it. > The laptop is a Acer 2920. Its symptom for a GENERIC is a panic saying stray > interrupt (irq7), with a custom kernel booting stalls. This is strange, as my Acer with the same ICH8M works fine in all possible modes. Also IMHO stray interrupts are not a reason to panic. Could you show what it looks like? -- Alexander Motin --------------070406070505010906060903 Content-Type: text/plain; name="hpet.nonv.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hpet.nonv.patch" --- acpi_hpet.c.prev 2010-09-13 10:25:36.000000000 +0300 +++ acpi_hpet.c 2010-09-30 08:09:34.000000000 +0300 @@ -58,6 +58,7 @@ __FBSDID("$FreeBSD: head/sys/dev/acpica/ #define HPET_VENDID_AMD 0x4353 #define HPET_VENDID_INTEL 0x8086 +#define HPET_VENDID_NVIDIA 0x10de ACPI_SERIAL_DECL(hpet, "ACPI HPET support"); @@ -492,6 +493,12 @@ hpet_attach(device_t dev) if (vendor == HPET_VENDID_AMD) sc->allowed_irqs = 0x00000000; /* + * NVidia MCP5x chipsets have number of unexplained interrupt + * problems. For some reason, using HPET interrupts breaks HDA sound. + */ + if (vendor == HPET_VENDID_NVIDIA && rev <= 0x01) + sc->allowed_irqs = 0x00000000; + /* * Neither QEMU nor VirtualBox report supported IRQs correctly. * The only way to use HPET there is to specify IRQs manually * and/or use legacy_route. Legacy_route mode work on both. --------------070406070505010906060903-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 05:55:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84801106564A; Thu, 30 Sep 2010 05:55:56 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A52A48FC15; Thu, 30 Sep 2010 05:55:55 +0000 (UTC) Received: by wyb34 with SMTP id 34so25156wyb.13 for ; Wed, 29 Sep 2010 22:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=6e25+cpgq0F6fXo3P1//g5gwHrEt2dG+Cp4Nf8PIVnc=; b=X5/CO1RZnaRURbL60keHeKbacweB/r/Cujvqg/PlQh3TkGuWs5pKoyjSwi45ndWwZ2 Gmmj08PeHXFv2pd6GtWCYb2pR8CjI5DpxkSBAJ7Ey/jS9iFZGTcVYWzGiFVXaM5SNn7C CjO2hivwS6Ubjmx3xrP0ZaPw80D0uYq1XQCW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=gTPkCmWPgXKrOjd6raQvNaE9NA/eNXvw1iqBE2VqOWQbOq1LIJAtDoQ7bDwJKo3IFY H3MProwoSLJuS9Pkp9HypyfjFkAirqCC51kA/jViIO1MaikLNc1oC2hFJtSyANesUDzE o+Ev8N/bb+tObsWmb9akDvHsltpK31URaLL0w= Received: by 10.216.236.149 with SMTP id w21mr2445018weq.65.1285826154573; Wed, 29 Sep 2010 22:55:54 -0700 (PDT) Received: from dragon.dg (41-132-25-181.dsl.mweb.co.za [41.132.25.181]) by mx.google.com with ESMTPS id v11sm6009289weq.16.2010.09.29.22.55.51 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 22:55:53 -0700 (PDT) From: David Naylor Organization: Private To: Alexander Motin Date: Thu, 30 Sep 2010 07:55:43 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.4.5; amd64; ; ) References: <201009291207.53146.naylor.b.david@gmail.com> <201009292048.11194.naylor.b.david@gmail.com> <4CA41ED6.5060208@FreeBSD.org> In-Reply-To: <4CA41ED6.5060208@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1652381.9iCLpYTfoM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009300755.46989.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 05:55:56 -0000 --nextPart1652381.9iCLpYTfoM Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday 30 September 2010 07:23:34 Alexander Motin wrote: > David Naylor wrote: > > On Wednesday 29 September 2010 18:25:13 Alexander Motin wrote: > >> David Naylor wrote: > >>> On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: > >>>> What do you try to actually achieve? > >>>=20 > >>> I was trying to boot a system and it was panicking due to stray > >>> interrupts. It turned out to be caused by HPET. I found > >>> `hint.hpet.0.clock=3D0' which fixed the problem. > >>>=20 > >>> This means HPET does not work on any of my machines. The other one's > >>> symptoms are hda losing interrupts after a period of up-time. > >>=20 > >> What chipset do you use? Nvidia MCP5x? Could you send me your verbose > >> dmesg? > >=20 > > Yes, the one is a MCP51, the other is a ICH8M. > >=20 > > The desktop is a Gigabyte N650SLI-DS4L. Its symptom is hda losing > > interrupts after a period of time. >=20 > There are too many reports about different lost interrupts problems on > different controllers of MCP5x. I don't know the reason. Attached patch > should disable using regular HPET interrupts on NVidia chipsets. I hope > it will work as workaround. May be it is too aggressive, but better to > be safe then sorry. I assume that legacy_route mode may still work fine > there. It would be nice to test it. I assume you mean hint.hpet.0.legacy_route=3D1? I'll give that a try later= =20 today on both machines. =20 Is your patch the same as hint.hpet.0.clock=3D0? =20 > > The laptop is a Acer 2920. Its symptom for a GENERIC is a panic saying > > stray interrupt (irq7), with a custom kernel booting stalls. >=20 > This is strange, as my Acer with the same ICH8M works fine in all > possible modes. Also IMHO stray interrupts are not a reason to panic. > Could you show what it looks like? See http://markmail.org/message/smxnofrdmmkxyvnd for my previous email that= =20 includes the backtrace from that panic. When I booted in i386 safe mode th= e=20 kernel reported stray interrupts on irq7. vmstat -i shows irq7 as "stray=20 irq7". =20 Is there anything else you are looking for? --nextPart1652381.9iCLpYTfoM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkykJmIACgkQUaaFgP9pFrKPlwCfViXeQD1mrdBf1zYv75Qcos+n Q6UAn3nNFCGf6LLKm0h5Ke7ETBqoE9KG =dPhM -----END PGP SIGNATURE----- --nextPart1652381.9iCLpYTfoM-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 06:10:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DDDF1065674; Thu, 30 Sep 2010 06:10:15 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 041018FC16; Thu, 30 Sep 2010 06:10:14 +0000 (UTC) Received: by yxn35 with SMTP id 35so698131yxn.13 for ; Wed, 29 Sep 2010 23:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=y6RZmaJQNkS05TXxx2gNsJGMls20iAows2QPyDORdSo=; b=Ib2S5wdBiHhH0F1ONZbdbmi1fay+1bu7KohjnwM9J9cpuFkFw5XxosRiZ8dunFSoSc YhRtBli8A/TlnIzFJhsIl9BS+XA/ZksckD0BmfXL+qW0VsJTxERRnJmb3sN5LvpnagvK 26UzaYpGzlKR3HhT49lnGqH1NEBr7WVYiA64A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FHtl8VCPv+lACxEABelBjhj1qiPhuTK5kExTAXpInoOr9Zr2dGvnqXJczH7pV3FU08 h5ztZ5Kr8TB+hBEfLwuqZHq7ldIESkBxMxIC09Te12GHeymmEJqaKH0QH0Wdb/J6km7o 4YyT6qK3keUG32AjEZlID384LmVpGZUVdg27w= MIME-Version: 1.0 Received: by 10.224.54.13 with SMTP id o13mr2069101qag.305.1285827014006; Wed, 29 Sep 2010 23:10:14 -0700 (PDT) Received: by 10.229.50.8 with HTTP; Wed, 29 Sep 2010 23:10:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Sep 2010 10:10:13 +0400 Message-ID: From: Sergey Kandaurov To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, FreeBSD Current Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 06:10:15 -0000 > From: Ryan Stone > Date: Wed, Sep 29, 2010 at 11:32 AM > Subject: Re: [PATCH] Netdump for review and testing -- preliminary version > To: Sergey Kandaurov > > >> db> netdump >> >> ----------------------------------- >> netdump in progress. searching for server.. . . . . . . . . . . . >> Failed to contact netdump server > > This can be fixed by putting: > > nd_server_port = NETDUMP_PORT; > > At the beginning of netdump_trigger. Hi. Thank you, that helped fixing it. 2nd and further netdumps work now. Some more numbers below [hosts are on diff. switches connected with STP on same 1Gb MTU1500 LAN] packets errs bytes packets errs bytes colls [avg:] 3488 0 4109874 4002 0 704800 0 [at the end:] 3484 0 4076816 3989 0 680710 0 3510 0 4086756 4066 0 712280 0 3552 0 4136112 4107 0 714790 0 3459 0 4059238 3995 0 681966 0 3499 0 4077516 4037 0 709734 0 3423 0 4004157 3936 0 678816 0 13898 0 19118779 14018 0 2062568 0 22206 0 31680314 21451 0 2959042 0 22410 0 32086046 21710 0 2854724 0 22231 0 31747238 21489 0 2899306 0 input (bce0) output packets errs bytes packets errs bytes colls 18490 0 26180288 17757 0 2729082 0 336 0 24674 90 0 622960 0 6 0 1148 1 0 178 0 1687470 packets captured 2274879 packets received by filter 65676 packets dropped by kernel It shows 30Mbps in average with up to 224 Mbps at the end. The traffic picture is 1472 bytes UDP payload, and 4 bytes ack. It took slightly less then 5 mins to netdump 1146 MB. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 06:22:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 722EF106566C; Thu, 30 Sep 2010 06:22:47 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1682C8FC0A; Thu, 30 Sep 2010 06:22:46 +0000 (UTC) Received: by gwb15 with SMTP id 15so705715gwb.13 for ; Wed, 29 Sep 2010 23:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1iBQBnoREJsHTEOVxeNLNy77VpaRVyFL5a5XJm8hy7A=; b=bpeXERFElAo46/q03QggV5p5optCDBCPuZ/V4+k+W+vkdz+WDUiiRIvGalAFF/PEaL Pr0M6nmTQKiulV8XXfUUAlM30a4+MsVo7erpVBsJxiGngZL544D5ut7A8NVEd2KmDA+c ykCkrjs2EjPRM7Q+cKxDS6vHWU5Kd+rsUvX7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G7CULXaK3Y3WpQJ7AhoDx5Vxea4OA1tpzq0bWuOh1OrGqXSczQStxqw+8nihoah3+J rZdbOINOByE7W3g8zK2UK4sM38icnS6uDyI6bVV/hhvzBYn3fsqy8aDrlauAidvj+EfF cY3z08GzrEFBWt+nRAZxnneseJeFBY5VQoVH0= MIME-Version: 1.0 Received: by 10.229.237.129 with SMTP id ko1mr2232596qcb.4.1285827766088; Wed, 29 Sep 2010 23:22:46 -0700 (PDT) Received: by 10.229.50.8 with HTTP; Wed, 29 Sep 2010 23:22:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Sep 2010 10:22:45 +0400 Message-ID: From: Sergey Kandaurov To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, FreeBSD Current Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 06:22:47 -0000 The 1st error is caught :). Prior actions was triggering netdump, leaving db> and entering again, then trigger netdump once more. Dumping 1146 MB: 1131 1115 1099 1083 1067 1051 1035 1019 1003 987 971 955 939 923 907 891 875 859 843 827 811 795. . . . . . . . . . . ** DUMP FAILED (ERROR 60) ** Failed to dump the actual raw datas Then I was able to leave ddb back to the working system. P.S. What about to start netdumpsrv from rc.d ? It's very simple. %%% #!/bin/sh # # $FreeBSD$ # # PROVIDE: netdumpsrv # REQUIRE: NETWORKING # KEYWORD: shutdown . /etc/rc.subr name="netdumpsrv" rcvar=`set_rcvar` command="/usr/sbin/${name}" pidfile="/var/run/${name}.pid" load_rc_config $name run_rc_command "$1" %%% -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 06:46:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 767A1106566B; Thu, 30 Sep 2010 06:46:43 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 34D3B8FC08; Thu, 30 Sep 2010 06:46:43 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id DF6DB4968B; Thu, 30 Sep 2010 08:29:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id dF2g5FRSnmbh; Thu, 30 Sep 2010 08:29:48 +0200 (CEST) Received: from danger-mbp.local (59576.ba.3pp.slovanet.sk [84.16.39.226]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 9C8DA49680; Thu, 30 Sep 2010 08:29:48 +0200 (CEST) Message-ID: <4CA42E5C.5090609@FreeBSD.org> Date: Thu, 30 Sep 2010 08:29:48 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.10pre) Gecko/20100914 Lanikai/3.1.5pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: HEADSUP: Call for FreeBSD Status Reports - 3Q/2010 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 06:46:43 -0000 Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2010 is due on October 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 06:52:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CABBE1065672; Thu, 30 Sep 2010 06:52:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2723C8FC15; Thu, 30 Sep 2010 06:52:58 +0000 (UTC) Received: by bwz15 with SMTP id 15so1522865bwz.13 for ; Wed, 29 Sep 2010 23:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=f3QaxUIuFk3vemwHpjNq87f+ivw86Vr7wN7Zs46ErHI=; b=vbHdMqLV3nDK/N37ivoX7kGYMHDRNv4uoZwdUXza61tzC5ho9KfaT6TEZogd5u8gyL SOBNLoEClIhHXMj6luMH5IiHmYbXd65gVqIwaK/t8kS9bRVpzaapSIbhWjej42l3DMui rHoZIEypq0mKYO9lzeu31BbK5kJpQJgqXrQPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=aZ7PlqEIxyqDvNDfnE/LW5Mg+PW75XMAZOMsMtdw+qUUUYCV7LrbEWAv3mW07XysG7 TUqHBXLCKpXqdKCbuHo30JwOFmEn9aSSNFYSJTY/kcOqoBe8qlO4AiW+oZ/6QzEXthNT I/LgmKp4sOaQxVQngl0hBYsmN24yMi39vI+OY= Received: by 10.204.69.18 with SMTP id x18mr2323293bki.34.1285829576603; Wed, 29 Sep 2010 23:52:56 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f18sm7453786bkf.3.2010.09.29.23.52.54 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 23:52:55 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA433B7.9010306@FreeBSD.org> Date: Thu, 30 Sep 2010 09:52:39 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Naylor References: <201009291207.53146.naylor.b.david@gmail.com> <201009292048.11194.naylor.b.david@gmail.com> <4CA41ED6.5060208@FreeBSD.org> <201009300755.46989.naylor.b.david@gmail.com> In-Reply-To: <201009300755.46989.naylor.b.david@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 06:53:00 -0000 David Naylor wrote: > On Thursday 30 September 2010 07:23:34 Alexander Motin wrote: >> David Naylor wrote: >>> On Wednesday 29 September 2010 18:25:13 Alexander Motin wrote: >>>> David Naylor wrote: >>>>> On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: >>>>>> What do you try to actually achieve? >>>>> I was trying to boot a system and it was panicking due to stray >>>>> interrupts. It turned out to be caused by HPET. I found >>>>> `hint.hpet.0.clock=0' which fixed the problem. >>>>> >>>>> This means HPET does not work on any of my machines. The other one's >>>>> symptoms are hda losing interrupts after a period of up-time. >>>> What chipset do you use? Nvidia MCP5x? Could you send me your verbose >>>> dmesg? >>> Yes, the one is a MCP51, the other is a ICH8M. >>> >>> The desktop is a Gigabyte N650SLI-DS4L. Its symptom is hda losing >>> interrupts after a period of time. >> There are too many reports about different lost interrupts problems on >> different controllers of MCP5x. I don't know the reason. Attached patch >> should disable using regular HPET interrupts on NVidia chipsets. I hope >> it will work as workaround. May be it is too aggressive, but better to >> be safe then sorry. I assume that legacy_route mode may still work fine >> there. It would be nice to test it. > > I assume you mean hint.hpet.0.legacy_route=1? I'll give that a try later > today on both machines. Make sure that both attimer and atrtc disabled, as mentioned in hpet(4). > Is your patch the same as hint.hpet.0.clock=0? By default - effectively yes. But it still allows to configure legacy_route, which is, for example, default for Linux. >>> The laptop is a Acer 2920. Its symptom for a GENERIC is a panic saying >>> stray interrupt (irq7), with a custom kernel booting stalls. >> This is strange, as my Acer with the same ICH8M works fine in all >> possible modes. Also IMHO stray interrupts are not a reason to panic. >> Could you show what it looks like? > > See http://markmail.org/message/smxnofrdmmkxyvnd for my previous email that > includes the backtrace from that panic. When I booted in i386 safe mode the > kernel reported stray interrupts on irq7. vmstat -i shows irq7 as "stray > irq7". I am not sure "stray irq7" related here. Instead more suspicious looks probable irq20 interrupt sharing between HPET and uhci0 and the fact that system panicked during interrupt handler registration by uhci0. I can't be sure what IRQ was used by HPET there, as in only present dmesg it was disabled, but as soon as HPET registered early, I think it grabbed first possible - irq20. On my system HPET also uses irq20, but uhci0 lives on irq16 and so irq20 is not shared. To collect more data you may try to hint HPET driver to avoid irq20 by setting hint.hpet.0.allowed_irqs=0x00e00000 or other values. I've tried same recipy to create sharing on my system, but still found no problem. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 09:59:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88C2F106564A for ; Thu, 30 Sep 2010 09:59:10 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3EDEF8FC14 for ; Thu, 30 Sep 2010 09:59:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P1Fuu-0002mG-MZ for freebsd-current@freebsd.org; Thu, 30 Sep 2010 11:59:08 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Sep 2010 11:59:08 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Sep 2010 11:59:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 30 Sep 2010 11:59:10 +0200 Lines: 24 Message-ID: References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <4CA3BD7C.9080306@feral.com> X-Enigmail-Version: 1.0.1 Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 09:59:10 -0000 On 09/30/10 00:28, Matthew Jacob wrote: > On 9/29/2010 2:45 PM, Andriy Gapon wrote: >> on 30/09/2010 00:12 Alexander Best said the following: >>> hi there, >>> >>> i wanted to ask if it would be possible to asjust glabel so that e.g. >>> inserting >>> a new media into a dvd-drive gets recognised and glabel displays the >>> lablel >>> right away. >> Yes, of course, as soon as we have in kernel a programmatic way to >> know that >> media as changed. >> We don't have one right now... >> > > What announcement API would you like to add? > > If something like that was in place, I assure you that things would > start to use it very quickly. It doesn't have to be a heavy "announcement API". Basically, something would have to re-trigger GEOM tasting on existing devices, probably by marking them "spoiled" first. From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 11:22:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23F611065742 for ; Thu, 30 Sep 2010 11:22:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5AA8FC17 for ; Thu, 30 Sep 2010 11:22:27 +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 OAA19695; Thu, 30 Sep 2010 14:22:23 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CA472EE.7040704@icyb.net.ua> Date: Thu, 30 Sep 2010 14:22:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matthew Jacob References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> In-Reply-To: <4CA3BD7C.9080306@feral.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 11:22:29 -0000 on 30/09/2010 01:28 Matthew Jacob said the following: > On 9/29/2010 2:45 PM, Andriy Gapon wrote: >> on 30/09/2010 00:12 Alexander Best said the following: >>> hi there, >>> >>> i wanted to ask if it would be possible to asjust glabel so that e.g. inserting >>> a new media into a dvd-drive gets recognised and glabel displays the lablel >>> right away. >> Yes, of course, as soon as we have in kernel a programmatic way to know that >> media as changed. >> We don't have one right now... >> > > What announcement API would you like to add? Not sure what kind of API you mean and if anything really needs to be added. I think you already can easily trigger GEOM re-tasting. > If something like that was in place, I assure you that things would start to use > it very quickly. I am not sure about this. Because, e.g. I don't see an easy way to know that media is changed in scsi_cd driver. That is, without polling. I don't consider polling to be an easy way for a number of reasons. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 12:45:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E541106564A for ; Thu, 30 Sep 2010 12:45:59 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 26E078FC26 for ; Thu, 30 Sep 2010 12:45:58 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o8UCjvmX004852 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 30 Sep 2010 05:45:58 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CA4867F.9050105@feral.com> Date: Thu, 30 Sep 2010 05:45:51 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Thu, 30 Sep 2010 05:45:58 -0700 (PDT) Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 12:45:59 -0000 We already have a 'retaste' command for gmultipath at Panasas. >> What announcement API would you like to add? >> >> If something like that was in place, I assure you that things would >> start to use it very quickly. > > It doesn't have to be a heavy "announcement API". Basically, something > would have to re-trigger GEOM tasting on existing devices, probably by > marking them "spoiled" first. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 12:53:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA2F910656B6 for ; Thu, 30 Sep 2010 12:53:16 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8DCC18FC17 for ; Thu, 30 Sep 2010 12:53:16 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o8UCrF2M004887 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 30 Sep 2010 05:53:16 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CA48835.1020701@feral.com> Date: Thu, 30 Sep 2010 05:53:09 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> <4CA472EE.7040704@icyb.net.ua> In-Reply-To: <4CA472EE.7040704@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Thu, 30 Sep 2010 05:53:16 -0700 (PDT) Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 12:53:16 -0000 Oh? Why? > I am not sure about this. > Because, e.g. I don't see an easy way to know that media is changed in scsi_cd > driver. That is, without polling. I don't consider polling to be an easy way for > a number of reasons. > From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 15:44:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04BBF1065672; Thu, 30 Sep 2010 15:44:10 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8098FC0A; Thu, 30 Sep 2010 15:44:08 +0000 (UTC) Received: by wwb17 with SMTP id 17so2727816wwb.31 for ; Thu, 30 Sep 2010 08:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=VafLomEmZ4ZcgAuJ/8rGxRW0Ayis1D7ZPNWDQRE8+GI=; b=MWhB0+ikjDLiLBn3pi7oGEEgu+CzOitqX3e/hBGwiOrBAlMfBTIysoRFrXRNGKokdB OGQk/cQUaoLjXkLeDGgiALoNsYivcSliioppQFVzKA8bWSv/n/znq6kwYyHJm45jkPgL 1ZnBj1BbkD6O6Xg2oplHIWQHvbbH6bzC3jBTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=hFFcaShayOz3XXytn5+eYYqDF0hBTRc5eY9nQgfaXoPnZwJjSdAupn5jeZ/1vqg0jN 9Hp9jjRUJwqtp1wKog8CZBM8pm3xzHrexLIAc+yqs8oXo30/lyjXrkGTMREDqAucCxDd HW9K1WrhP+U+TYX6UsgV/IZWK7F58TDIcXrjI= Received: by 10.227.135.141 with SMTP id n13mr3409680wbt.97.1285861425319; Thu, 30 Sep 2010 08:43:45 -0700 (PDT) Received: from dragon.dg (41-132-25-181.dsl.mweb.co.za [41.132.25.181]) by mx.google.com with ESMTPS id bc3sm8485624wbb.2.2010.09.30.08.43.40 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 08:43:42 -0700 (PDT) From: David Naylor Organization: Private To: Alexander Motin Date: Thu, 30 Sep 2010 17:43:01 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.4.5; amd64; ; ) References: <201009291207.53146.naylor.b.david@gmail.com> <201009300755.46989.naylor.b.david@gmail.com> <4CA433B7.9010306@FreeBSD.org> In-Reply-To: <4CA433B7.9010306@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2414250.FMb40JKo8v"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009301743.36007.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 15:44:10 -0000 --nextPart2414250.FMb40JKo8v Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday 30 September 2010 08:52:39 Alexander Motin wrote: > David Naylor wrote: > > On Thursday 30 September 2010 07:23:34 Alexander Motin wrote: > >> David Naylor wrote: > >>> On Wednesday 29 September 2010 18:25:13 Alexander Motin wrote: > >>>> David Naylor wrote: > >>>>> On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: > >>>>>> What do you try to actually achieve? > >>>>>=20 > >>>>> I was trying to boot a system and it was panicking due to stray > >>>>> interrupts. It turned out to be caused by HPET. I found > >>>>> `hint.hpet.0.clock=3D0' which fixed the problem. > >>>>>=20 > >>>>> This means HPET does not work on any of my machines. The other one= 's > >>>>> symptoms are hda losing interrupts after a period of up-time. > >>>>=20 > >>>> What chipset do you use? Nvidia MCP5x? Could you send me your verbose > >>>> dmesg? > >>>=20 > >>> Yes, the one is a MCP51, the other is a ICH8M. > >>>=20 > >>> The desktop is a Gigabyte N650SLI-DS4L. Its symptom is hda losing > >>> interrupts after a period of time. > >>=20 > >> There are too many reports about different lost interrupts problems on > >> different controllers of MCP5x. I don't know the reason. Attached patch > >> should disable using regular HPET interrupts on NVidia chipsets. I hope > >> it will work as workaround. May be it is too aggressive, but better to > >> be safe then sorry. I assume that legacy_route mode may still work fine > >> there. It would be nice to test it. > >=20 > > I assume you mean hint.hpet.0.legacy_route=3D1? I'll give that a try l= ater > > today on both machines. >=20 > Make sure that both attimer and atrtc disabled, as mentioned in hpet(4). legacy_route worked on the desktop but not on the laptop (boot stalled). =20 Here is vmstat using default settings for the desktop: interrupt total rate irq1: atkbd0 64 0 irq12: psm0 756 3 irq14: ata0 1255 5 irq16: vgapci0 13576 54 irq17: dc0 1546 6 irq18: hpet0 456756 1834 irq20: atapci2 11557 46 irq21: hdac0 ohci0 17038 68 irq23: atapci1 11534 46 Total 514082 2064 I moved hpet to irq22 (allowed_irqs=3D"0x400000") and that also worked for = the=20 desktop. =20 > > Is your patch the same as hint.hpet.0.clock=3D0? >=20 > By default - effectively yes. But it still allows to configure > legacy_route, which is, for example, default for Linux. >=20 > >>> The laptop is a Acer 2920. Its symptom for a GENERIC is a panic sayi= ng > >>> stray interrupt (irq7), with a custom kernel booting stalls. > >>=20 > >> This is strange, as my Acer with the same ICH8M works fine in all > >> possible modes. Also IMHO stray interrupts are not a reason to panic. > >> Could you show what it looks like? > >=20 > > See http://markmail.org/message/smxnofrdmmkxyvnd for my previous email > > that includes the backtrace from that panic. When I booted in i386 safe > > mode the kernel reported stray interrupts on irq7. vmstat -i shows irq7 > > as "stray irq7". >=20 > I am not sure "stray irq7" related here. Instead more suspicious looks > probable irq20 interrupt sharing between HPET and uhci0 and the fact > that system panicked during interrupt handler registration by uhci0. I > can't be sure what IRQ was used by HPET there, as in only present dmesg > it was disabled, but as soon as HPET registered early, I think it > grabbed first possible - irq20. On my system HPET also uses irq20, but > uhci0 lives on irq16 and so irq20 is not shared. On the laptop uhci0 and ehci0 live on irq20. =20 > To collect more data you may try to hint HPET driver to avoid irq20 by > setting hint.hpet.0.allowed_irqs=3D0x00e00000 or other values. I've tried > same recipy to create sharing on my system, but still found no problem. This fixes the problem for the laptop. This also allows one-shot timing to= =20 work. Moving hpet to irq22 also worked. Here is the vmstat -i using the=20 above hint: interrupt total rate irq1: atkbd0 407 0 irq9: acpi0 1857 2 irq12: psm0 1005 1 irq14: ata0 1870 2 irq18: uhci4 2183 2 irq20: uhci0 ehci0 2421 3 irq21: hpet0 uhci1 502330 667 irq23: uhci2 ehci1 3 0 irq256: vgapci0 25023 33 irq257: hdac0 236 0 irq258: bge0 79 0 irq259: ahci0 27356 36 Total 564770 750 --nextPart2414250.FMb40JKo8v Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEUEABECAAYFAkyksCcACgkQUaaFgP9pFrJt5gCYs1WK5VPIEg5+HLyZTNIgHtC/ wACcCQjBrPbunKWXajfwEFBK7RmI1RE= =JmLK -----END PGP SIGNATURE----- --nextPart2414250.FMb40JKo8v-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 16:37:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60FCE1065674 for ; Thu, 30 Sep 2010 16:37:19 +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 D785C8FC08 for ; Thu, 30 Sep 2010 16:37:18 +0000 (UTC) Received: (qmail 20758 invoked from network); 30 Sep 2010 16:29:15 -0000 Received: from unknown (HELO [62.48.0.92]) ([62.48.0.92]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 16:29:15 -0000 Message-ID: <4CA4BCD2.4070303@freebsd.org> Date: Thu, 30 Sep 2010 18:37:38 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 16:37:20 -0000 Just for the kick of it I decided to take a closer look at the use of splay trees (inherited from Mach if I read the history correctly) in the FreeBSD VM system suspecting an interesting journey. The VM system has two major structures: 1) the VM map which is per process and manages its address space by tracking all regions that are allocated and their permissions. 2) the VM page table which is per VM map and provides the backing memory pages to the regions and interfaces with the pmap layer (virtual->physical). Both of these are very frequently accessed through memory allocations from userspace and page faults from the pmap layer. Their efficiency and SMP scalability is crucial for many operations beginning with fork/ exec, going through malloc/mmap and ending with free/exit of a process. Both the vmmap and page table make use of splay trees to manage the entries and to speed up lookups compared to long to traverse linked lists or more memory expensive hash tables. Some structures though do have an additional linked list to simplify ordered traversals. A splay tree is an interesting binary search tree with insertion, lookup and removal performed in O(log n) *amortized* time. With the *amortized* time being the crucial difference to other binary trees. On every access *including* lookup it rotates the tree to make the just found element the new root node. For all gory details see: http://en.wikipedia.org/wiki/Splay_tree This behavior has a few important implications: 1) the root node and constant rotation works like a cache with least recent looked up node at the top and less recently ones close to the top; 2) every lookup that doesn't match the root node, ie. a cache miss, causes a rotation of the tree to make the newly found node the new root; 3) during the rotate it has to re-arrange and touch possibly a large number of other nodes; 4) in worst case the tree may resemble a linked list. A splay tree makes no guarantee that it is balanced. For the kernel and the splay tree usage in the VM map and page table some more implications come up: a) the amortization effect/cost only balance if the majority of lookups are root node (cache) hits, otherwise the cost of rebalancing destroys any advantage and quickly turns into a large overhead. b) the overhead becomes even worse due to touching many nodes and causing a lot of CPU cache line dirtying. For processes with shared memory or threads across CPU's this overhead becomes almost excessive because the CPU's stomp on each others cached nodes and get their own caches invalidated. The penalty is a high-latency memory refetch not only for the root node lookup but every hop in the following rebalancing operation => thrashing. To quantify the positive and negative effects of the splay tree I instrumented the code and added counters to track the behavior of the splay tree in the vmmap and page table. The test case is an AMD64 kernel build to get a first overview. Other system usages may have different results depending on their fork and memory usage patters. The results are very interesting: The page table shows a *very* poor root node hit rate and an excessive amount of rotational node modifications representing almost the worst case for splay trees. http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,127484769&chd=t:16946915,16719791,48872230,131057,74858589,105206121&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies The vmmap shows a high root node hit rate but still a significant amount of rotational node modifications. http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,21881583&chd=t:724293,723701,20881583,19044544,3719582,4553350&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies From these observations I come to the conclusion that a splay tree is suboptimal for the normal case and quickly horrible even on small deviations from the normal case in the vmmap. For the page table it is always horrible. Not to mention the locking complications due to modifying the tree on lookups. Based on an examination of other binary trees I put forward the hypothesis that a Red-Black tree is a much better, if not the optimal, fit for the vmmap and page table. RB trees are balanced binary trees and O(log n) in all cases. The big advantage in this context is that lookups are pure reads and do not cause CPU cache invalidations on other CPU's and always only require a read lock without the worst case properties of the unbalanced splay tree. The high cache locality of the vmmap lookups can be used with the RB tree as well by simply adding a pointer to the least recently found node. To prevent write locking this can be done lazily. More profiling is required to make a non-speculative statement on this though. In addition a few of the additional linked lists that currently accompany the vmmap and page structures are no longer necessary as they easily can be done with standard RB tree accessors. Our standard userspace jemalloc also uses RB trees for its internal housekeeping. RB tree details: http://en.wikipedia.org/wiki/Red-black_tree I say hypothesis because I haven't measured the difference to an RB tree implementation yet. I've hacked up a crude and somewhat mechanical patch to convert the vmmap and page VM structures to use RB trees, the vmmap part is not stable yet. The page part seems to work fine though. This is what I've hacked together so far: http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff The diffs are still in their early stages and do not make use of any code simplifications becoming possible by using RB trees instead of the current splay trees. Comments on the VM issue and splay vs. RB tree hypothesis welcome. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:15:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41D111065670; Thu, 30 Sep 2010 17:15:09 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C98F38FC1E; Thu, 30 Sep 2010 17:15:08 +0000 (UTC) Received: by gwb15 with SMTP id 15so1080052gwb.13 for ; Thu, 30 Sep 2010 10:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K+yTQ/3ztvTBJhRhX+Zi4AldNfQ7MaAXdzqmaKbUwyI=; b=xbc/fk4guhrSTnjSEi0g1ScgSpUBVmCV4O4+Rt+hdblD5bexBXBNYmYmXKjbNvjOmt 4fb9RADbs77VVdSMQXp1zRUuFKzzc5h/6naoLTGZOuZVBAJiqutQVhJ/y4lOZT9366IM sMdVfAvsFDLPmvjjVRSHcT7Mq2/seLe5vN1iQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wwj82wQ3Ja8RctxXIKfITisUFoIHP8hdnBgNfQcT19E/NaJ2442SqqY/pYoXGljV+6 0NhhVpqUZdopiiuhpVvm+2vuf7LWEIYO6ZPUx8yGWtQM6G1wmkYG/TjhfgNvKx6ZYH6a D2QiWlHI3XqHIpTCw+ta1HvuodJyHzNBMUv4s= MIME-Version: 1.0 Received: by 10.231.183.10 with SMTP id ce10mr4097344ibb.96.1285866907574; Thu, 30 Sep 2010 10:15:07 -0700 (PDT) Received: by 10.231.167.140 with HTTP; Thu, 30 Sep 2010 10:15:07 -0700 (PDT) In-Reply-To: <4CA4BCD2.4070303@freebsd.org> References: <4CA4BCD2.4070303@freebsd.org> Date: Thu, 30 Sep 2010 10:15:07 -0700 Message-ID: From: Matthew Fleming To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:15:09 -0000 On Thu, Sep 30, 2010 at 9:37 AM, Andre Oppermann wrote: > Just for the kick of it I decided to take a closer look at the use of > splay trees (inherited from Mach if I read the history correctly) in > the FreeBSD VM system suspecting an interesting journey. > > The VM system has two major structures: > =A01) the VM map which is per process and manages its address space > =A0 =A0by tracking all regions that are allocated and their permissions. > =A02) the VM page table which is per VM map and provides the backing > =A0 =A0memory pages to the regions and interfaces with the pmap layer > =A0 =A0(virtual->physical). > > Both of these are very frequently accessed through memory allocations > from userspace and page faults from the pmap layer. =A0Their efficiency > and SMP scalability is crucial for many operations beginning with fork/ > exec, going through malloc/mmap and ending with free/exit of a process. > > Both the vmmap and page table make use of splay trees to manage the > entries and to speed up lookups compared to long to traverse linked > lists or more memory expensive hash tables. =A0Some structures though > do have an additional linked list to simplify ordered traversals. > > A splay tree is an interesting binary search tree with insertion, > lookup and removal performed in O(log n) *amortized* time. =A0With > the *amortized* time being the crucial difference to other binary trees. > On every access *including* lookup it rotates the tree to make the > just found element the new root node. =A0For all gory details see: > =A0http://en.wikipedia.org/wiki/Splay_tree > > This behavior has a few important implications: > =A01) the root node and constant rotation works like a cache with > =A0 =A0least recent looked up node at the top and less recently ones > =A0 =A0close to the top; > =A02) every lookup that doesn't match the root node, ie. a cache miss, > =A0 =A0causes a rotation of the tree to make the newly found node the new > =A0 =A0root; > =A03) during the rotate it has to re-arrange and touch possibly a large > =A0 =A0number of other nodes; > =A04) in worst case the tree may resemble a linked list. =A0A splay tree > =A0 =A0makes no guarantee that it is balanced. > > For the kernel and the splay tree usage in the VM map and page table > some more implications come up: > =A0a) the amortization effect/cost only balance if the majority of > =A0 =A0lookups are root node (cache) hits, otherwise the cost of > =A0 =A0rebalancing destroys any advantage and quickly turns into a > =A0 =A0large overhead. > =A0b) the overhead becomes even worse due to touching many nodes and > =A0 =A0causing a lot of CPU cache line dirtying. =A0For processes with > =A0 =A0shared memory or threads across CPU's this overhead becomes > =A0 =A0almost excessive because the CPU's stomp on each others cached > =A0 =A0nodes and get their own caches invalidated. =A0The penalty is a > =A0 =A0high-latency memory refetch not only for the root node lookup > =A0 =A0but every hop in the following rebalancing operation =3D> thrashin= g. > > To quantify the positive and negative effects of the splay tree I > instrumented the code and added counters to track the behavior of > the splay tree in the vmmap and page table. > > The test case is an AMD64 kernel build to get a first overview. > Other system usages may have different results depending on their > fork and memory usage patters. > > The results are very interesting: > > =A0The page table shows a *very* poor root node hit rate and an excessive > =A0amount of rotational node modifications representing almost the > =A0worst case for splay trees. > > http://chart.apis.google.com/chart?chs=3D700x300&chbh=3Da,23&chds=3D0,127= 484769&chd=3Dt:16946915,16719791,48872230,131057,74858589,105206121&cht=3Db= vg&chl=3Dinsert|remove|lookup|cachehit|rotates|rotatemodifies > > =A0The vmmap shows a high root node hit rate but still a significant > =A0amount of rotational node modifications. > > http://chart.apis.google.com/chart?chs=3D700x300&chbh=3Da,23&chds=3D0,218= 81583&chd=3Dt:724293,723701,20881583,19044544,3719582,4553350&cht=3Dbvg&chl= =3Dinsert|remove|lookup|cachehit|rotates|rotatemodifies > > From these observations I come to the conclusion that a splay tree > is suboptimal for the normal case and quickly horrible even on small > deviations from the normal case in the vmmap. =A0For the page table it > is always horrible. =A0Not to mention the locking complications due to > modifying the tree on lookups. > > Based on an examination of other binary trees I put forward the > hypothesis that a Red-Black tree is a much better, if not the optimal, > fit for the vmmap and page table. =A0RB trees are balanced binary trees > and O(log n) in all cases. =A0The big advantage in this context is that > lookups are pure reads and do not cause CPU cache invalidations on > other CPU's and always only require a read lock without the worst > case properties of the unbalanced splay tree. =A0The high cache locality > of the vmmap lookups can be used with the RB tree as well by simply > adding a pointer to the least recently found node. =A0To prevent write lo= cking > this can be done lazily. =A0More profiling is required to make > a non-speculative statement on this though. =A0In addition a few of > the additional linked lists that currently accompany the vmmap and > page structures are no longer necessary as they easily can be done > with standard RB tree accessors. =A0Our standard userspace jemalloc > also uses RB trees for its internal housekeeping. =A0RB tree details: > =A0http://en.wikipedia.org/wiki/Red-black_tree > > I say hypothesis because I haven't measured the difference to an > RB tree implementation yet. =A0I've hacked up a crude and somewhat > mechanical patch to convert the vmmap and page VM structures to > use RB trees, the vmmap part is not stable yet. =A0The page part > seems to work fine though. > > This is what I've hacked together so far: > =A0http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff > =A0http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff > > The diffs are still in their early stages and do not make use of > any code simplifications becoming possible by using RB trees instead > of the current splay trees. > > Comments on the VM issue and splay vs. RB tree hypothesis welcome. Do you have actual performance numbers from a real workload? I implemented an AA tree locally (basically a 2,3 tree that uses coloring to represent the 3 nodes) and the performance was much worse than the splay tree. I assume this is due to the overhead of keeping the tree balanced; I didn't instrument either the splay or the AA code. I suspect that the overhead of an RB tree would similarly wash out the benefits of O(log_2 n) time, but this is theory. The facts would be measuring several different workloads an looking at the system/real times for them between the two solutions. We've talked internally at $work about using a B+-tree with maybe branching factor 5-7; whatever makes sense for the size of a cache line. This seems likely to be better for performance than an RB-tree but does require a lot more changes, since separate memory is needed for the tree's nodes outside the vm_page structure. There just hasn't been time to implement it and try it out. Unfortunately I won't have the time to experiment at $work for a few months on this problem. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:24:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56E16106566B for ; Thu, 30 Sep 2010 17:24:43 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8E0EE8FC0A for ; Thu, 30 Sep 2010 17:24:41 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 849219CB0F1; Thu, 30 Sep 2010 19:24:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52YLvdPPXC+X; Thu, 30 Sep 2010 19:24:39 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5D47E9CB12E; Thu, 30 Sep 2010 19:24:39 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o8UHOdLC035141; Thu, 30 Sep 2010 19:24:39 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 30 Sep 2010 19:24:39 +0200 From: Roman Divacky To: Andre Oppermann Message-ID: <20100930172439.GA34369@freebsd.org> References: <4CA4BCD2.4070303@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA4BCD2.4070303@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:24:43 -0000 are you aware of Summer of Code 2008 project by Mayur Shardul? quoting: http://www.freebsd.org/projects/summerofcode-2008.html Project: VM Algorithm Improvement Student: Mayur Shardul Mentor: Jeff Roberson Summary: A new data structure, viz. radix tree, was implemented and used for management of the resident pages. The objective is efficient use of memory and faster performance. The biggest challenge was to service insert requests on the data structure without blocking. Because of this constraint the memory allocation failures were not acceptable, to solve the problem the required memory was allocated at the boot time. Both the data structures were used in parallel to check the correctness and we also benchmarked the data structures and found that radix trees gave much better performance over splay trees. Ready to enter CVS/SVN: We will investigate some more approaches to handle allocation failures before the new data structure goes in CVS. On Thu, Sep 30, 2010 at 06:37:38PM +0200, Andre Oppermann wrote: > Just for the kick of it I decided to take a closer look at the use of > splay trees (inherited from Mach if I read the history correctly) in > the FreeBSD VM system suspecting an interesting journey. > > The VM system has two major structures: > 1) the VM map which is per process and manages its address space > by tracking all regions that are allocated and their permissions. > 2) the VM page table which is per VM map and provides the backing > memory pages to the regions and interfaces with the pmap layer > (virtual->physical). > > Both of these are very frequently accessed through memory allocations > from userspace and page faults from the pmap layer. Their efficiency > and SMP scalability is crucial for many operations beginning with fork/ > exec, going through malloc/mmap and ending with free/exit of a process. > > Both the vmmap and page table make use of splay trees to manage the > entries and to speed up lookups compared to long to traverse linked > lists or more memory expensive hash tables. Some structures though > do have an additional linked list to simplify ordered traversals. > > A splay tree is an interesting binary search tree with insertion, > lookup and removal performed in O(log n) *amortized* time. With > the *amortized* time being the crucial difference to other binary trees. > On every access *including* lookup it rotates the tree to make the > just found element the new root node. For all gory details see: > http://en.wikipedia.org/wiki/Splay_tree > > This behavior has a few important implications: > 1) the root node and constant rotation works like a cache with > least recent looked up node at the top and less recently ones > close to the top; > 2) every lookup that doesn't match the root node, ie. a cache miss, > causes a rotation of the tree to make the newly found node the new > root; > 3) during the rotate it has to re-arrange and touch possibly a large > number of other nodes; > 4) in worst case the tree may resemble a linked list. A splay tree > makes no guarantee that it is balanced. > > For the kernel and the splay tree usage in the VM map and page table > some more implications come up: > a) the amortization effect/cost only balance if the majority of > lookups are root node (cache) hits, otherwise the cost of > rebalancing destroys any advantage and quickly turns into a > large overhead. > b) the overhead becomes even worse due to touching many nodes and > causing a lot of CPU cache line dirtying. For processes with > shared memory or threads across CPU's this overhead becomes > almost excessive because the CPU's stomp on each others cached > nodes and get their own caches invalidated. The penalty is a > high-latency memory refetch not only for the root node lookup > but every hop in the following rebalancing operation => thrashing. > > To quantify the positive and negative effects of the splay tree I > instrumented the code and added counters to track the behavior of > the splay tree in the vmmap and page table. > > The test case is an AMD64 kernel build to get a first overview. > Other system usages may have different results depending on their > fork and memory usage patters. > > The results are very interesting: > > The page table shows a *very* poor root node hit rate and an excessive > amount of rotational node modifications representing almost the > worst case for splay trees. > > http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,127484769&chd=t:16946915,16719791,48872230,131057,74858589,105206121&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies > > The vmmap shows a high root node hit rate but still a significant > amount of rotational node modifications. > > http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,21881583&chd=t:724293,723701,20881583,19044544,3719582,4553350&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies > > From these observations I come to the conclusion that a splay tree > is suboptimal for the normal case and quickly horrible even on small > deviations from the normal case in the vmmap. For the page table it > is always horrible. Not to mention the locking complications due to > modifying the tree on lookups. > > Based on an examination of other binary trees I put forward the > hypothesis that a Red-Black tree is a much better, if not the optimal, > fit for the vmmap and page table. RB trees are balanced binary trees > and O(log n) in all cases. The big advantage in this context is that > lookups are pure reads and do not cause CPU cache invalidations on > other CPU's and always only require a read lock without the worst > case properties of the unbalanced splay tree. The high cache locality > of the vmmap lookups can be used with the RB tree as well by simply > adding a pointer to the least recently found node. To prevent write > locking this can be done lazily. More profiling is required to make > a non-speculative statement on this though. In addition a few of > the additional linked lists that currently accompany the vmmap and > page structures are no longer necessary as they easily can be done > with standard RB tree accessors. Our standard userspace jemalloc > also uses RB trees for its internal housekeeping. RB tree details: > http://en.wikipedia.org/wiki/Red-black_tree > > I say hypothesis because I haven't measured the difference to an > RB tree implementation yet. I've hacked up a crude and somewhat > mechanical patch to convert the vmmap and page VM structures to > use RB trees, the vmmap part is not stable yet. The page part > seems to work fine though. > > This is what I've hacked together so far: > http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff > http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff > > The diffs are still in their early stages and do not make use of > any code simplifications becoming possible by using RB trees instead > of the current splay trees. > > Comments on the VM issue and splay vs. RB tree hypothesis welcome. > > -- > Andre > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:37:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E6C1065673 for ; Thu, 30 Sep 2010 17:37:21 +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 43BDF8FC19 for ; Thu, 30 Sep 2010 17:37:20 +0000 (UTC) Received: (qmail 21178 invoked from network); 30 Sep 2010 17:29:18 -0000 Received: from unknown (HELO [62.48.0.92]) ([62.48.0.92]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 17:29:18 -0000 Message-ID: <4CA4CAE6.2090108@freebsd.org> Date: Thu, 30 Sep 2010 19:37:42 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers References: <4CA4BCD2.4070303@freebsd.org> In-Reply-To: <4CA4BCD2.4070303@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:37:21 -0000 On 30.09.2010 18:37, Andre Oppermann wrote: > Just for the kick of it I decided to take a closer look at the use of > splay trees (inherited from Mach if I read the history correctly) in > the FreeBSD VM system suspecting an interesting journey. Correcting myself regarding the history: The splay tree for vmmap was done about 8 years ago by alc@ to replace a simple linked list and was a huge improvement. The change in vmpage from a hash to the same splay tree as in vmmap was committed by dillon@ about 7.5 years ago with some involvement of alc@. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:44:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F2DD106564A for ; Thu, 30 Sep 2010 17:44:19 +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 EAAF38FC19 for ; Thu, 30 Sep 2010 17:44:18 +0000 (UTC) Received: (qmail 21251 invoked from network); 30 Sep 2010 17:36:16 -0000 Received: from unknown (HELO [62.48.0.92]) ([62.48.0.92]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 17:36:16 -0000 Message-ID: <4CA4CC87.9060605@freebsd.org> Date: Thu, 30 Sep 2010 19:44:39 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matthew Fleming References: <4CA4BCD2.4070303@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:44:19 -0000 On 30.09.2010 19:15, Matthew Fleming wrote: > On Thu, Sep 30, 2010 at 9:37 AM, Andre Oppermann wrote: >> Just for the kick of it I decided to take a closer look at the use of >> splay trees (inherited from Mach if I read the history correctly) in >> the FreeBSD VM system suspecting an interesting journey. >> >> The VM system has two major structures: >> 1) the VM map which is per process and manages its address space >> by tracking all regions that are allocated and their permissions. >> 2) the VM page table which is per VM map and provides the backing >> memory pages to the regions and interfaces with the pmap layer >> (virtual->physical). >> >> Both of these are very frequently accessed through memory allocations >> from userspace and page faults from the pmap layer. Their efficiency >> and SMP scalability is crucial for many operations beginning with fork/ >> exec, going through malloc/mmap and ending with free/exit of a process. >> >> Both the vmmap and page table make use of splay trees to manage the >> entries and to speed up lookups compared to long to traverse linked >> lists or more memory expensive hash tables. Some structures though >> do have an additional linked list to simplify ordered traversals. >> >> A splay tree is an interesting binary search tree with insertion, >> lookup and removal performed in O(log n) *amortized* time. With >> the *amortized* time being the crucial difference to other binary trees. >> On every access *including* lookup it rotates the tree to make the >> just found element the new root node. For all gory details see: >> http://en.wikipedia.org/wiki/Splay_tree >> >> This behavior has a few important implications: >> 1) the root node and constant rotation works like a cache with >> least recent looked up node at the top and less recently ones >> close to the top; >> 2) every lookup that doesn't match the root node, ie. a cache miss, >> causes a rotation of the tree to make the newly found node the new >> root; >> 3) during the rotate it has to re-arrange and touch possibly a large >> number of other nodes; >> 4) in worst case the tree may resemble a linked list. A splay tree >> makes no guarantee that it is balanced. >> >> For the kernel and the splay tree usage in the VM map and page table >> some more implications come up: >> a) the amortization effect/cost only balance if the majority of >> lookups are root node (cache) hits, otherwise the cost of >> rebalancing destroys any advantage and quickly turns into a >> large overhead. >> b) the overhead becomes even worse due to touching many nodes and >> causing a lot of CPU cache line dirtying. For processes with >> shared memory or threads across CPU's this overhead becomes >> almost excessive because the CPU's stomp on each others cached >> nodes and get their own caches invalidated. The penalty is a >> high-latency memory refetch not only for the root node lookup >> but every hop in the following rebalancing operation => thrashing. >> >> To quantify the positive and negative effects of the splay tree I >> instrumented the code and added counters to track the behavior of >> the splay tree in the vmmap and page table. >> >> The test case is an AMD64 kernel build to get a first overview. >> Other system usages may have different results depending on their >> fork and memory usage patters. >> >> The results are very interesting: >> >> The page table shows a *very* poor root node hit rate and an excessive >> amount of rotational node modifications representing almost the >> worst case for splay trees. >> >> http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,127484769&chd=t:16946915,16719791,48872230,131057,74858589,105206121&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies >> >> The vmmap shows a high root node hit rate but still a significant >> amount of rotational node modifications. >> >> http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,21881583&chd=t:724293,723701,20881583,19044544,3719582,4553350&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies >> >> From these observations I come to the conclusion that a splay tree >> is suboptimal for the normal case and quickly horrible even on small >> deviations from the normal case in the vmmap. For the page table it >> is always horrible. Not to mention the locking complications due to >> modifying the tree on lookups. >> >> Based on an examination of other binary trees I put forward the >> hypothesis that a Red-Black tree is a much better, if not the optimal, >> fit for the vmmap and page table. RB trees are balanced binary trees >> and O(log n) in all cases. The big advantage in this context is that >> lookups are pure reads and do not cause CPU cache invalidations on >> other CPU's and always only require a read lock without the worst >> case properties of the unbalanced splay tree. The high cache locality >> of the vmmap lookups can be used with the RB tree as well by simply >> adding a pointer to the least recently found node. To prevent write locking >> this can be done lazily. More profiling is required to make >> a non-speculative statement on this though. In addition a few of >> the additional linked lists that currently accompany the vmmap and >> page structures are no longer necessary as they easily can be done >> with standard RB tree accessors. Our standard userspace jemalloc >> also uses RB trees for its internal housekeeping. RB tree details: >> http://en.wikipedia.org/wiki/Red-black_tree >> >> I say hypothesis because I haven't measured the difference to an >> RB tree implementation yet. I've hacked up a crude and somewhat >> mechanical patch to convert the vmmap and page VM structures to >> use RB trees, the vmmap part is not stable yet. The page part >> seems to work fine though. >> >> This is what I've hacked together so far: >> http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff >> http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff >> >> The diffs are still in their early stages and do not make use of >> any code simplifications becoming possible by using RB trees instead >> of the current splay trees. >> >> Comments on the VM issue and splay vs. RB tree hypothesis welcome. > > Do you have actual performance numbers from a real workload? No, not yet. I obviously would have posted those numbers as well. What do you consider a representative real workload? > I implemented an AA tree locally (basically a 2,3 tree that uses > coloring to represent the 3 nodes) and the performance was much worse > than the splay tree. I assume this is due to the overhead of keeping > the tree balanced; I didn't instrument either the splay or the AA > code. I suspect that the overhead of an RB tree would similarly wash > out the benefits of O(log_2 n) time, but this is theory. The facts > would be measuring several different workloads an looking at the > system/real times for them between the two solutions. I think there are two pronounced effects to consider: a) the algorithmic complexity b) the real world implications of said complexity and operations on today's CPU's multi-hierarchy caches and associated SMP side effects. > We've talked internally at $work about using a B+-tree with maybe > branching factor 5-7; whatever makes sense for the size of a cache > line. This seems likely to be better for performance than an RB-tree > but does require a lot more changes, since separate memory is needed > for the tree's nodes outside the vm_page structure. There just hasn't > been time to implement it and try it out. > > Unfortunately I won't have the time to experiment at $work for a few > months on this problem. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:46:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27B6910656A5 for ; Thu, 30 Sep 2010 17:46:12 +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 8AFF08FC29 for ; Thu, 30 Sep 2010 17:46:11 +0000 (UTC) Received: (qmail 21275 invoked from network); 30 Sep 2010 17:38:08 -0000 Received: from unknown (HELO [62.48.0.92]) ([62.48.0.92]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 17:38:08 -0000 Message-ID: <4CA4CCF8.1050300@freebsd.org> Date: Thu, 30 Sep 2010 19:46:32 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> In-Reply-To: <20100930172439.GA34369@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:46:12 -0000 On 30.09.2010 19:24, Roman Divacky wrote: > are you aware of Summer of Code 2008 project by Mayur Shardul? I remember that there was this project but I never saw any numbers or other outcome of it. Haven't checked p4 to look at the code though. -- Andre > quoting: http://www.freebsd.org/projects/summerofcode-2008.html > > Project: VM Algorithm Improvement > Student: Mayur Shardul > Mentor: Jeff Roberson > Summary: > A new data structure, viz. radix tree, was implemented and used for management of the resident pages. The > objective is efficient use of memory and faster performance. The biggest challenge was to service insert requests > on the data structure without blocking. Because of this constraint the memory allocation failures were not > acceptable, to solve the problem the required memory was allocated at the boot time. Both the data structures were > used in parallel to check the correctness and we also benchmarked the data structures and found that radix trees > gave much better performance over splay trees. > > Ready to enter CVS/SVN: We will investigate some more approaches to handle allocation failures before the new data > structure goes in CVS. From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:46:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 955C51065673 for ; Thu, 30 Sep 2010 17:46:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC0C8FC1F for ; Thu, 30 Sep 2010 17:46:28 +0000 (UTC) Received: by bwz15 with SMTP id 15so2087127bwz.13 for ; Thu, 30 Sep 2010 10:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Aib25OLq0z3MPdtY43gSpKb4IRHg6/dHsJ41V+674IE=; b=F9YJ3B60I5BPYCtKs3pTcKjKkqUOlLGChUAEw9eLqHOO6f98/3eEwuTpUhSSolPPAB WaJpgGjiQ1vu3fY9scmE36u4BnfLzCsKVBpXksM8Or8n+5fUi+DEIyr/RP12y/6a94Ss oFQKPzeM60MvnJ5cux8VPvnAF3dP+nROF7m/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lSCgG2C5UFpdbJKp2hP08ZMA8/pBMdH6cGvP//B8w+WFcWyxopsgXnWTHGiEJGcy2m uqCXdAGi4kkiYwzY3PybZYd4nL7UkKGnUp4vlQo+EREH2WFA+tJWpmrJvQC23Ph026nd motRTuuFwigtG6vt1RGoXUGiEB1HdOOfy1dkM= Received: by 10.204.82.136 with SMTP id b8mr3055109bkl.38.1285868787932; Thu, 30 Sep 2010 10:46:27 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 24sm118677bkr.19.2010.09.30.10.46.26 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 10:46:27 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA4CCE3.9060408@FreeBSD.org> Date: Thu, 30 Sep 2010 20:46:11 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon , FreeBSD-Current References: <4CA3BD7C.9080306@feral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:46:29 -0000 Andriy Gapon wrote: > on 30/09/2010 01:28 Matthew Jacob said the following: >> If something like that was in place, I assure you that things would start to use >> it very quickly. > > I am not sure about this. > Because, e.g. I don't see an easy way to know that media is changed in scsi_cd > driver. That is, without polling. I don't consider polling to be an easy way for > a number of reasons. SATA specification defines concept of Asynchronous Notification. It is already used by port multipliers to report about PHY events. It is also supposed to be used by CD drives to report media change. I haven't seen such devices yet, but hope they may appear sometimes. And even without AN support it would be nice to implement proper handling for SCSI "UA - media changed" errors within CAM. It still won't be perfect without using polling, but probably still something. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:49:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE9A106567A; Thu, 30 Sep 2010 17:49:02 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id BC0348FC12; Thu, 30 Sep 2010 17:49:01 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C06589CB080; Thu, 30 Sep 2010 19:49:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXt4XcWA4BN8; Thu, 30 Sep 2010 19:49:00 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 4EAA59CB11D; Thu, 30 Sep 2010 19:49:00 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o8UHn0qj037914; Thu, 30 Sep 2010 19:49:00 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 30 Sep 2010 19:49:00 +0200 From: Roman Divacky To: Andre Oppermann Message-ID: <20100930174900.GA37733@freebsd.org> References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA4CCF8.1050300@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:49:02 -0000 On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote: > On 30.09.2010 19:24, Roman Divacky wrote: > >are you aware of Summer of Code 2008 project by Mayur Shardul? > > I remember that there was this project but I never saw any numbers > or other outcome of it. Haven't checked p4 to look at the code > though. there's a little something: http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 17:52:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 627051065674 for ; Thu, 30 Sep 2010 17:52:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD088FC15 for ; Thu, 30 Sep 2010 17:52:02 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P1NIW-0001h0-Sw for freebsd-current@freebsd.org; Thu, 30 Sep 2010 19:52:00 +0200 Received: from 93-138-123-63.adsl.net.t-com.hr ([93.138.123.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Sep 2010 19:52:00 +0200 Received: from ivoras by 93-138-123-63.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Sep 2010 19:52:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 30 Sep 2010 19:51:49 +0200 Lines: 19 Message-ID: References: <4CA4BCD2.4070303@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-123-63.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100620 Thunderbird/3.0.4 In-Reply-To: <4CA4BCD2.4070303@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:52:03 -0000 On 09/30/10 18:37, Andre Oppermann wrote: > Both the vmmap and page table make use of splay trees to manage the > entries and to speed up lookups compared to long to traverse linked > lists or more memory expensive hash tables. Some structures though > do have an additional linked list to simplify ordered traversals. The property of splay tree requiring *writes* for nearly every read really is a thorn in the eye for SMP. It seems to me that even if the immediate benefits from converting to something else are not directly observable, it will still be worth doing it. It's a shame that RCU is still a patent minefield :/ http://mirror.leaseweb.com/kernel/people/npiggin/patches/lockless/2.6.16-rc5/radix-intro.pdf Slightly off-topic: a scare-mongering topic on Slashdot: http://hardware.slashdot.org/story/10/09/30/1528229/Linux-May-Need-a-Rewrite-Beyond-48-Cores From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 18:04:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E84B106566C; Thu, 30 Sep 2010 18:04:19 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 096BA8FC13; Thu, 30 Sep 2010 18:04:18 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 253199CB0D7; Thu, 30 Sep 2010 20:04:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-NdpJwU5wku; Thu, 30 Sep 2010 20:04:17 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A2F709CB146; Thu, 30 Sep 2010 20:04:17 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o8UI4HI1039574; Thu, 30 Sep 2010 20:04:17 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 30 Sep 2010 20:04:17 +0200 From: Roman Divacky To: Andre Oppermann Message-ID: <20100930180417.GA39381@freebsd.org> References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> <20100930174900.GA37733@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100930174900.GA37733@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 18:04:19 -0000 On Thu, Sep 30, 2010 at 07:49:00PM +0200, Roman Divacky wrote: > On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote: > > On 30.09.2010 19:24, Roman Divacky wrote: > > >are you aware of Summer of Code 2008 project by Mayur Shardul? > > > > I remember that there was this project but I never saw any numbers > > or other outcome of it. Haven't checked p4 to look at the code > > though. > > there's a little something: > > http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement and the actual patch + userspace implementation + benchmarking suite is here: http://code.google.com/p/google-summer-of-code-2008-freebsd/downloads/detail?name=Mayur_Shardul.tar.gz&can=2&q= it looks like a solid work with solid results to me From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 18:19:05 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B875A106564A for ; Thu, 30 Sep 2010 18:19:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E5DB18FC08 for ; Thu, 30 Sep 2010 18:19: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 VAA26906; Thu, 30 Sep 2010 21:19:02 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CA4D496.6080604@icyb.net.ua> Date: Thu, 30 Sep 2010 21:19:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Robert Watson Subject: sysctls in kern_shutdown: add twin tunables X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 18:19:05 -0000 http://people.freebsd.org/~avg/kern_shutdown-tunables.diff The above patch adds twin tunables for the following (R/W) sysctls: - debug.debugger_on_panic - debug.trace_on_panic - kern.sync_on_panic This seems useful to me, but I am not sure if I am not missing something important. E.g. security-wise. It seems that I am not paranoid enough often times. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 18:26:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 841DB1065672 for ; Thu, 30 Sep 2010 18:26:22 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56A728FC16 for ; Thu, 30 Sep 2010 18:26:21 +0000 (UTC) Received: by pxi17 with SMTP id 17so719862pxi.13 for ; Thu, 30 Sep 2010 11:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=HTVWFQJCaDYink14UwYwO6xIP1kkrXGRUiGtf0IW+38=; b=CgQR2qnAc96UOZyvIxxeCC22+9f0GjursgxBQ/+AUSdbq4PQE3Gu+812LMA5mJ26ZI zatqciQ3sCW5yFTJklExlfpxJE0qtX7HDsOCt3whsDejUzEB/p4xhHhyX199vhGF/TYb e5Qv+19iZqzHe6F39eS25/Dl9jRIDefSm9xTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=V/thMLbt2DqFfUQ1853xpb3i8q45kSDAxQPA3xEwnx9oEAcEr0hPzqiTynDyBR0mww fwNtjnJglV7s3oCMchPolQAgbn0eIK6ijE9MkmVPbFqTluP92xlgdy3UU3V4hlWoFAhc VsOaXykt0CALR1OXdXCREKqqK+V2ogOiSQWu0= MIME-Version: 1.0 Received: by 10.114.95.12 with SMTP id s12mr4700695wab.217.1285869710947; Thu, 30 Sep 2010 11:01:50 -0700 (PDT) Received: by 10.42.170.136 with HTTP; Thu, 30 Sep 2010 11:01:50 -0700 (PDT) In-Reply-To: <4CA4CAE6.2090108@freebsd.org> References: <4CA4BCD2.4070303@freebsd.org> <4CA4CAE6.2090108@freebsd.org> Date: Thu, 30 Sep 2010 13:01:50 -0500 Message-ID: From: Alan Cox To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 18:26:22 -0000 On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann wrote: > On 30.09.2010 18:37, Andre Oppermann wrote: > >> Just for the kick of it I decided to take a closer look at the use of >> splay trees (inherited from Mach if I read the history correctly) in >> the FreeBSD VM system suspecting an interesting journey. >> > > Correcting myself regarding the history: The splay tree for vmmap was > done about 8 years ago by alc@ to replace a simple linked list and was > a huge improvement. The change in vmpage from a hash to the same splay > tree as in vmmap was committed by dillon@ about 7.5 years ago with some > involvement of alc@. > ss > Yes, and there is a substantial difference in the degree of locality of access to these different structures, and thus the effectiveness of a splay tree. When I did the last round of changes to the locking on the vm map, I made some measurements of the splay tree's performance on a JVM running a moderately large bioinformatics application. The upshot was that the average number of map entries visited on an access to the vm map's splay tree was less than the expected depth of a node in a perfectly balanced tree. I teach class shortly. I'll provide more details later. Regards, Alan From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 18:49:09 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43129106564A for ; Thu, 30 Sep 2010 18:49:09 +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 1E5788FC1C for ; Thu, 30 Sep 2010 18:49:09 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2E61B46B2C; Thu, 30 Sep 2010 14:49:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4CA4D496.6080604@icyb.net.ua> Date: Thu, 30 Sep 2010 19:49:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99D3F3AD-27C1-45C4-B1FC-FFC8A63AF94D@FreeBSD.org> References: <4CA4D496.6080604@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@FreeBSD.org Subject: Re: sysctls in kern_shutdown: add twin tunables X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 18:49:09 -0000 On 30 Sep 2010, at 19:19, Andriy Gapon wrote: > http://people.freebsd.org/~avg/kern_shutdown-tunables.diff >=20 > The above patch adds twin tunables for the following (R/W) sysctls: > - debug.debugger_on_panic > - debug.trace_on_panic > - kern.sync_on_panic >=20 > This seems useful to me, but I am not sure if I am not missing = something > important. E.g. security-wise. > It seems that I am not paranoid enough often times. This change seems fine to me. Our trust model assumes that loader.conf = will be properly protected (or rather, that if you don't protect = loader.conf properly, you should expect unfortunate results). Robert= From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 18:57:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE7B0106564A; Thu, 30 Sep 2010 18:57:39 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8EAC18FC14; Thu, 30 Sep 2010 18:57:39 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 51C901A3D23; Thu, 30 Sep 2010 11:38:53 -0700 (PDT) Date: Thu, 30 Sep 2010 11:38:53 -0700 From: Alfred Perlstein To: Andre Oppermann Message-ID: <20100930183853.GX49807@elvis.mu.org> References: <4CA4BCD2.4070303@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA4BCD2.4070303@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 18:57:39 -0000 Andre, Your observations on the effectiveness of the splay tree mirror the concerns I have with it when I read about it. I have always wondered though if the splay-tree algorithm was modified to only perform rotations when a lookup required more than "N" traversals to reach a node. This would self-balance the tree and maintain cache without the expense of writes for nearly all lookups. I'm wondering if you have the time/interest in rerunning your tests, but modifying the algorithm to only rebalance the splay if a lookup requires more than let's say 3, 5, 7 or 10 traversals. what do you think? -Alfred * Andre Oppermann [100930 09:38] wrote: > Just for the kick of it I decided to take a closer look at the use of > splay trees (inherited from Mach if I read the history correctly) in > the FreeBSD VM system suspecting an interesting journey. > > The VM system has two major structures: > 1) the VM map which is per process and manages its address space > by tracking all regions that are allocated and their permissions. > 2) the VM page table which is per VM map and provides the backing > memory pages to the regions and interfaces with the pmap layer > (virtual->physical). > > Both of these are very frequently accessed through memory allocations > from userspace and page faults from the pmap layer. Their efficiency > and SMP scalability is crucial for many operations beginning with fork/ > exec, going through malloc/mmap and ending with free/exit of a process. > > Both the vmmap and page table make use of splay trees to manage the > entries and to speed up lookups compared to long to traverse linked > lists or more memory expensive hash tables. Some structures though > do have an additional linked list to simplify ordered traversals. > > A splay tree is an interesting binary search tree with insertion, > lookup and removal performed in O(log n) *amortized* time. With > the *amortized* time being the crucial difference to other binary trees. > On every access *including* lookup it rotates the tree to make the > just found element the new root node. For all gory details see: > http://en.wikipedia.org/wiki/Splay_tree > > This behavior has a few important implications: > 1) the root node and constant rotation works like a cache with > least recent looked up node at the top and less recently ones > close to the top; > 2) every lookup that doesn't match the root node, ie. a cache miss, > causes a rotation of the tree to make the newly found node the new > root; > 3) during the rotate it has to re-arrange and touch possibly a large > number of other nodes; > 4) in worst case the tree may resemble a linked list. A splay tree > makes no guarantee that it is balanced. > > For the kernel and the splay tree usage in the VM map and page table > some more implications come up: > a) the amortization effect/cost only balance if the majority of > lookups are root node (cache) hits, otherwise the cost of > rebalancing destroys any advantage and quickly turns into a > large overhead. > b) the overhead becomes even worse due to touching many nodes and > causing a lot of CPU cache line dirtying. For processes with > shared memory or threads across CPU's this overhead becomes > almost excessive because the CPU's stomp on each others cached > nodes and get their own caches invalidated. The penalty is a > high-latency memory refetch not only for the root node lookup > but every hop in the following rebalancing operation => thrashing. > > To quantify the positive and negative effects of the splay tree I > instrumented the code and added counters to track the behavior of > the splay tree in the vmmap and page table. > > The test case is an AMD64 kernel build to get a first overview. > Other system usages may have different results depending on their > fork and memory usage patters. > > The results are very interesting: > > The page table shows a *very* poor root node hit rate and an excessive > amount of rotational node modifications representing almost the > worst case for splay trees. > > http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,127484769&chd=t:16946915,16719791,48872230,131057,74858589,105206121&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies > > The vmmap shows a high root node hit rate but still a significant > amount of rotational node modifications. > > http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,21881583&chd=t:724293,723701,20881583,19044544,3719582,4553350&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies > > From these observations I come to the conclusion that a splay tree > is suboptimal for the normal case and quickly horrible even on small > deviations from the normal case in the vmmap. For the page table it > is always horrible. Not to mention the locking complications due to > modifying the tree on lookups. > > Based on an examination of other binary trees I put forward the > hypothesis that a Red-Black tree is a much better, if not the optimal, > fit for the vmmap and page table. RB trees are balanced binary trees > and O(log n) in all cases. The big advantage in this context is that > lookups are pure reads and do not cause CPU cache invalidations on > other CPU's and always only require a read lock without the worst > case properties of the unbalanced splay tree. The high cache locality > of the vmmap lookups can be used with the RB tree as well by simply > adding a pointer to the least recently found node. To prevent write > locking this can be done lazily. More profiling is required to make > a non-speculative statement on this though. In addition a few of > the additional linked lists that currently accompany the vmmap and > page structures are no longer necessary as they easily can be done > with standard RB tree accessors. Our standard userspace jemalloc > also uses RB trees for its internal housekeeping. RB tree details: > http://en.wikipedia.org/wiki/Red-black_tree > > I say hypothesis because I haven't measured the difference to an > RB tree implementation yet. I've hacked up a crude and somewhat > mechanical patch to convert the vmmap and page VM structures to > use RB trees, the vmmap part is not stable yet. The page part > seems to work fine though. > > This is what I've hacked together so far: > http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff > http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff > > The diffs are still in their early stages and do not make use of > any code simplifications becoming possible by using RB trees instead > of the current splay trees. > > Comments on the VM issue and splay vs. RB tree hypothesis welcome. > > -- > Andre > _______________________________________________ > 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" -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 20:45:53 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F239B106564A; Thu, 30 Sep 2010 20:45:53 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 15B908FC21; Thu, 30 Sep 2010 20:45:52 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA28970; Thu, 30 Sep 2010 23:45:51 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P1Q0l-0008H7-Bf; Thu, 30 Sep 2010 23:45:51 +0300 Message-ID: <4CA4F6FF.5070402@icyb.net.ua> Date: Thu, 30 Sep 2010 23:45:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexander Motin References: <4CA3BD7C.9080306@feral.com> <4CA4CCE3.9060408@FreeBSD.org> In-Reply-To: <4CA4CCE3.9060408@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 20:45:54 -0000 on 30/09/2010 20:46 Alexander Motin said the following: > Andriy Gapon wrote: >> on 30/09/2010 01:28 Matthew Jacob said the following: >>> If something like that was in place, I assure you that things would start to use >>> it very quickly. >> >> I am not sure about this. >> Because, e.g. I don't see an easy way to know that media is changed in scsi_cd >> driver. That is, without polling. I don't consider polling to be an easy way for >> a number of reasons. > > SATA specification defines concept of Asynchronous Notification. It is > already used by port multipliers to report about PHY events. It is also > supposed to be used by CD drives to report media change. I haven't seen > such devices yet, but hope they may appear sometimes. Would this require some reverse-path from SIM driver to peripheral driver to deliver a notification? Do we have one? > And even without AN support it would be nice to implement proper > handling for SCSI "UA - media changed" errors within CAM. It still won't > be perfect without using polling, but probably still something. I agree. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 20:49:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460BB1065670 for ; Thu, 30 Sep 2010 20:49:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8F9288FC08 for ; Thu, 30 Sep 2010 20:49:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA29001; Thu, 30 Sep 2010 23:49:52 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P1Q4e-0008HC-1b; Thu, 30 Sep 2010 23:49:52 +0300 Message-ID: <4CA4F7EF.9010203@icyb.net.ua> Date: Thu, 30 Sep 2010 23:49:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matthew Jacob References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> <4CA472EE.7040704@icyb.net.ua> <4CA48835.1020701@feral.com> In-Reply-To: <4CA48835.1020701@feral.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 20:49:58 -0000 on 30/09/2010 15:53 Matthew Jacob said the following: > > Oh? Why? In fact, I am not sure anymore :-) I had in mind some technical difficulties (like potential races with "normal" usage), but I think that they all are not very hard to overcome. Another question I had was how to poll, i.e. what command(s) to issue to cover different possibilities and hardware capabilities. Now all we need is someone to actually implement this :) >> I am not sure about this. >> Because, e.g. I don't see an easy way to know that media is changed in scsi_cd >> driver. That is, without polling. I don't consider polling to be an easy way >> for >> a number of reasons. >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 20:56:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C23D0106566C for ; Thu, 30 Sep 2010 20:56:53 +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 327C88FC16 for ; Thu, 30 Sep 2010 20:56:52 +0000 (UTC) Received: (qmail 22373 invoked from network); 30 Sep 2010 20:48:48 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 20:48:48 -0000 Message-ID: <4CA4F998.5000908@freebsd.org> Date: Thu, 30 Sep 2010 22:56:56 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: alc@freebsd.org References: <4CA4BCD2.4070303@freebsd.org> <4CA4CAE6.2090108@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , Alan Cox , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 20:56:53 -0000 On 30.09.2010 20:01, Alan Cox wrote: > On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann wrote: > >> On 30.09.2010 18:37, Andre Oppermann wrote: >> >>> Just for the kick of it I decided to take a closer look at the use of >>> splay trees (inherited from Mach if I read the history correctly) in >>> the FreeBSD VM system suspecting an interesting journey. >>> >> >> Correcting myself regarding the history: The splay tree for vmmap was >> done about 8 years ago by alc@ to replace a simple linked list and was >> a huge improvement. The change in vmpage from a hash to the same splay >> tree as in vmmap was committed by dillon@ about 7.5 years ago with some >> involvement of alc@. >> ss >> > > Yes, and there is a substantial difference in the degree of locality of > access to these different structures, and thus the effectiveness of a splay > tree. When I did the last round of changes to the locking on the vm map, I > made some measurements of the splay tree's performance on a JVM running a > moderately large bioinformatics application. The upshot was that the > average number of map entries visited on an access to the vm map's splay > tree was less than the expected depth of a node in a perfectly balanced > tree. This is indeed an expected property of the splay tree. For the vmmap the root node hit rate, that is the least recently accessed node, is very high. Other nodes that are frequently accessed as well should be high up too. Nonetheless the churn rate on the nodes in tree rotations is considerable. The question now is whether we can get the same positive effect but with less negative side effects. Of particular concern is the CPU cache dirtying and thrashing by the splay rotations. Especially with today's and tomorrows many core, many socket, many threads/processes machines. Another concern is worst case behavior when the root node hit rate is low. Currently this is the case in vmpage for certain. It may also become a concern in vmmap with the use of memguard (fragmenting the address space) or an adversary trying to exploit worst case behavior on a shared host by mapping only every other page. This concern is validated when accepting the measurement by the 2008 SoC student Mayur (thanks to rdivacky@ for digging up his page): http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement In the measurements of his alternative radix trie implementation the lookup time is *230 times less* than for the splay tree (as measured by with the TSC). The description of the performed benchmark is extremely sparse and it is not clear what access pattern he simulated. Probably a random lookup pattern which is of course very bad for the splay tree. Any balanced tree will be better for random lookups. Whether his measured improvement is due to using a radix trie or if it would perform equally to a normal balanced binary tree I can't say (yet). > I teach class shortly. I'll provide more details later. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:00:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4582106564A for ; Thu, 30 Sep 2010 21:00:54 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C60C8FC14 for ; Thu, 30 Sep 2010 21:00:53 +0000 (UTC) Received: by bwz15 with SMTP id 15so2305919bwz.13 for ; Thu, 30 Sep 2010 14:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=1lbCyga7ngNI5Z/puTscKhiTTk9ayUj7ClQd5Mev/Ag=; b=LW++IxChhbdyiMKijyxI/w/PC6ozzHpfRzaHFp1EL0fn622JpU8bHUeGj+iodsWoJc rok4CDu/7bbwgncX6S/ym+W6MzHjWGutoTJFeYJmvrM1FGPsOJNQa8AA39gDZkmuXr4R CokXVlYbJHcdS6Tcr3GD+0R83MDow/NFGzL3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=n1gIQkhAC+gHBTbhzQyXuz1L8YBZGgvI0n6sSvGQX7+qTi0E5dKyDq8D9p2aTUabbM Na1lMig7ypitx0TC8GV+L/LbbgUQF/hqWWeM1XLqO5JwiGzF9MBCvnovQYlnTziHRh9c mmHNJpvUUeRTge7WaiAwskDlAVe6W7zeOUskI= Received: by 10.204.70.211 with SMTP id e19mr3277653bkj.23.1285880453228; Thu, 30 Sep 2010 14:00:53 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y19sm326176bkw.18.2010.09.30.14.00.51 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 14:00:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA4FA74.8000708@FreeBSD.org> Date: Fri, 01 Oct 2010 00:00:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4CA3BD7C.9080306@feral.com> <4CA4CCE3.9060408@FreeBSD.org> <4CA4F6FF.5070402@icyb.net.ua> In-Reply-To: <4CA4F6FF.5070402@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:00:54 -0000 Andriy Gapon wrote: > on 30/09/2010 20:46 Alexander Motin said the following: >> Andriy Gapon wrote: >>> on 30/09/2010 01:28 Matthew Jacob said the following: >>>> If something like that was in place, I assure you that things would start to use >>>> it very quickly. >>> I am not sure about this. >>> Because, e.g. I don't see an easy way to know that media is changed in scsi_cd >>> driver. That is, without polling. I don't consider polling to be an easy way for >>> a number of reasons. >> SATA specification defines concept of Asynchronous Notification. It is >> already used by port multipliers to report about PHY events. It is also >> supposed to be used by CD drives to report media change. I haven't seen >> such devices yet, but hope they may appear sometimes. > > Would this require some reverse-path from SIM driver to peripheral driver to > deliver a notification? Do we have one? Yes we do. SATA PMP driver (it looks like usual peripheral driver from this point) already receives and handles AC_SCSI_AEN messages sent to it via xpt_async() mechanism. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:07:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 540AD1065670 for ; Thu, 30 Sep 2010 21:07:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D7D328FC1B for ; Thu, 30 Sep 2010 21:07:19 +0000 (UTC) Received: (qmail 7068 invoked by uid 399); 30 Sep 2010 21:07:18 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Sep 2010 21:07:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA4FC05.3020407@FreeBSD.org> Date: Thu, 30 Sep 2010 14:07:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> In-Reply-To: <4CA3BD7C.9080306@feral.com> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:07:20 -0000 On 9/29/2010 3:28 PM, Matthew Jacob wrote: > On 9/29/2010 2:45 PM, Andriy Gapon wrote: >> on 30/09/2010 00:12 Alexander Best said the following: >>> hi there, >>> >>> i wanted to ask if it would be possible to asjust glabel so that e.g. >>> inserting >>> a new media into a dvd-drive gets recognised and glabel displays the >>> lablel >>> right away. >> Yes, of course, as soon as we have in kernel a programmatic way to >> know that >> media as changed. >> We don't have one right now... >> > > What announcement API would you like to add? > > If something like that was in place, I assure you that things would > start to use it very quickly. To what extent is HAL relevant here? I was sort of ambivalent about using it in FreeBSD, but my recent experimentation with ubuntu is starting to change my mind. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:10:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74BBD106567A for ; Thu, 30 Sep 2010 21:10:38 +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 D91448FC1C for ; Thu, 30 Sep 2010 21:10:37 +0000 (UTC) Received: (qmail 22456 invoked from network); 30 Sep 2010 21:02:33 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 21:02:33 -0000 Message-ID: <4CA4FCD1.6010709@freebsd.org> Date: Thu, 30 Sep 2010 23:10:41 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alfred Perlstein References: <4CA4BCD2.4070303@freebsd.org> <20100930183853.GX49807@elvis.mu.org> In-Reply-To: <20100930183853.GX49807@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:10:38 -0000 On 30.09.2010 20:38, Alfred Perlstein wrote: > Andre, > > Your observations on the effectiveness of the splay tree > mirror the concerns I have with it when I read about it. > > I have always wondered though if the splay-tree algorithm > was modified to only perform rotations when a lookup required > more than "N" traversals to reach a node. > > This would self-balance the tree and maintain cache without > the expense of writes for nearly all lookups. This would break the underlying assumption of the splay tree. A splay tree is not a balanced tree. With this approach you can easily get stuck in a sub-optimal situation with many lookups traversing N-1 nodes and not getting the cache benefit. When N nodes are traversed for an outlier, and the rotate happens, you rotate again on the next lookup or you get stuck in another sub-optimal situation. In effect you get the worst of an splay tree while not being able to gain on the amortization effect when the root node hit rate is high. > I'm wondering if you have the time/interest in rerunning > your tests, but modifying the algorithm to only rebalance > the splay if a lookup requires more than let's say 3, 5, 7 > or 10 traversals. As the assumption of the algorithm is broken I don't think it's useful to spend time on this. I'd rather try and add a last-match pointer to the RB tree to take home the locality effect in vmmap. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:28:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C7CE1065674; Thu, 30 Sep 2010 21:28:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D0D388FC1C; Thu, 30 Sep 2010 21:28:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f59a:54a5:56c:5c84] (unknown [IPv6:2001:7b8:3a7:0:f59a:54a5:56c:5c84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1F0EE5C43; Thu, 30 Sep 2010 23:28:58 +0200 (CEST) Message-ID: <4CA5011D.8080804@FreeBSD.org> Date: Thu, 30 Sep 2010 23:29:01 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.11pre) Gecko/20100929 Lanikai/3.1.5pre MIME-Version: 1.0 To: Doug Barton References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> <4CA4FC05.3020407@FreeBSD.org> In-Reply-To: <4CA4FC05.3020407@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:28:59 -0000 On 2010-09-30 23:07, Doug Barton wrote: > To what extent is HAL relevant here? I was sort of ambivalent about > using it in FreeBSD, but my recent experimentation with ubuntu is > starting to change my mind. Please read this first: https://wiki.ubuntu.com/Halsectomy :) From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:29:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 556821065672; Thu, 30 Sep 2010 21:29:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id C97A48FC14; Thu, 30 Sep 2010 21:29:48 +0000 (UTC) Received: by qyk8 with SMTP id 8so532575qyk.13 for ; Thu, 30 Sep 2010 14:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ykVBo2fYnPZk9gfOnk750grUpUcV01U6bTRlhYxily8=; b=u91jN5poX9T0plIqlos60QlXslg/8Lw3yfIs7A/GMUUpxjTRtpnrdATAxNvVtaAGT5 zWQjDS1+K3SuiI0zTNKA9wGy4n7ijYP79KUEWlQTotEDmqs30rNZgJ3GaHfErJCdQCVr tBEhyfgsFfgbYijR6OAn/9qwErgYHuaCXs2HE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=II+KjhmWbjlamPVd+/QkveY+ek11a4YRldYoGVlqGeOl8GybwlzJMCKD2NMyKWCSJY 72bth4ROtYo7G0fW54zoBhJBXYazn+4oZZoOr35DK+dydvlb81gSGqngrO1bbOnoB9L8 3OI/5wqSesYLPjD+8KqepKGw6SwSZ941W4In0= MIME-Version: 1.0 Received: by 10.229.1.70 with SMTP id 6mr2980766qce.251.1285880730999; Thu, 30 Sep 2010 14:05:30 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Thu, 30 Sep 2010 14:05:30 -0700 (PDT) In-Reply-To: <4CA4CCF8.1050300@freebsd.org> References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> Date: Thu, 30 Sep 2010 23:05:30 +0200 X-Google-Sender-Auth: 0KiDwJlpl0WPQBzbnRI06KolDlI Message-ID: From: Attilio Rao To: Andre Oppermann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:29:49 -0000 2010/9/30 Andre Oppermann : > On 30.09.2010 19:24, Roman Divacky wrote: >> >> are you aware of Summer of Code 2008 project by Mayur Shardul? > > I remember that there was this project but I never saw any numbers > or other outcome of it. =C2=A0Haven't checked p4 to look at the code > though. The final code (Jeff took Mayur initial patches and further refined) resulted in a very variadic performance for simple tests, so I think that the last posted codes had the same performance, overall, than the splay tree. I recall, however, that there were still rooms for improvement. Ask Jeff about the last patches. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:35:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E669B1065673 for ; Thu, 30 Sep 2010 21:35:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 28E378FC22 for ; Thu, 30 Sep 2010 21:35:00 +0000 (UTC) Received: (qmail 14861 invoked by uid 399); 30 Sep 2010 21:35:00 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Sep 2010 21:35:00 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA50283.4000601@FreeBSD.org> Date: Thu, 30 Sep 2010 14:34:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dimitry Andric References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> <4CA4FC05.3020407@FreeBSD.org> <4CA5011D.8080804@FreeBSD.org> In-Reply-To: <4CA5011D.8080804@FreeBSD.org> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:35:02 -0000 On 9/30/2010 2:29 PM, Dimitry Andric wrote: > On 2010-09-30 23:07, Doug Barton wrote: >> To what extent is HAL relevant here? I was sort of ambivalent about >> using it in FreeBSD, but my recent experimentation with ubuntu is >> starting to change my mind. > > Please read this first: https://wiki.ubuntu.com/Halsectomy :) Right, especially the bits about moving the functionality into the kernel. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:38:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4016A106564A for ; Thu, 30 Sep 2010 21:38:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C1A118FC25 for ; Thu, 30 Sep 2010 21:38:45 +0000 (UTC) Received: (qmail 19355 invoked by uid 399); 30 Sep 2010 21:38:45 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Sep 2010 21:38:45 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA50363.2030500@FreeBSD.org> Date: Thu, 30 Sep 2010 14:38:43 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> <4CA4FC05.3020407@FreeBSD.org> <4CA5011D.8080804@FreeBSD.org> <4CA50283.4000601@FreeBSD.org> In-Reply-To: <4CA50283.4000601@FreeBSD.org> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:38:46 -0000 On 9/30/2010 2:34 PM, Doug Barton wrote: > On 9/30/2010 2:29 PM, Dimitry Andric wrote: >> On 2010-09-30 23:07, Doug Barton wrote: >>> To what extent is HAL relevant here? I was sort of ambivalent about >>> using it in FreeBSD, but my recent experimentation with ubuntu is >>> starting to change my mind. >> >> Please read this first: https://wiki.ubuntu.com/Halsectomy :) > > Right, especially the bits about moving the functionality into the kernel. Sorry, I'm being too terse. What I'm saying is that we have an existing "notifications" model that third party apps already know how to deal with. If we're considering developing a notifications model of our own then we are well served by looking at the work that has gone before (without violating copyright issues, yadda yadda). hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 21:44:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3081A106564A for ; Thu, 30 Sep 2010 21:44: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 949F28FC25 for ; Thu, 30 Sep 2010 21:44:14 +0000 (UTC) Received: (qmail 22636 invoked from network); 30 Sep 2010 21:36:09 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 21:36:09 -0000 Message-ID: <4CA504AD.8000102@freebsd.org> Date: Thu, 30 Sep 2010 23:44:13 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Roman Divacky References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> <20100930174900.GA37733@freebsd.org> <20100930180417.GA39381@freebsd.org> In-Reply-To: <20100930180417.GA39381@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:44:15 -0000 On 30.09.2010 20:04, Roman Divacky wrote: > On Thu, Sep 30, 2010 at 07:49:00PM +0200, Roman Divacky wrote: >> On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote: >>> On 30.09.2010 19:24, Roman Divacky wrote: >>>> are you aware of Summer of Code 2008 project by Mayur Shardul? >>> >>> I remember that there was this project but I never saw any numbers >>> or other outcome of it. Haven't checked p4 to look at the code >>> though. >> >> there's a little something: >> >> http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement > > and the actual patch + userspace implementation + benchmarking suite > is here: > > http://code.google.com/p/google-summer-of-code-2008-freebsd/downloads/detail?name=Mayur_Shardul.tar.gz&can=2&q= > > it looks like a solid work with solid results to me I just took a look (not in-depth though) at the patch and can't follow your conclusion. It is not ready to go into svn in its current state. Even though it is called a radix trie it doesn't look like one. On first impression it looks much more like an AA tree. A radix trie, which we already have in our network routing table code, is a variable length (mask) tree that does path compression. See net/radix.[ch] and http://en.wikipedia.org/wiki/Radix_tree Extrapolating in a complete guesstimating way from the lookup function I'd say it may perform only slightly better in an ideal case than a RB tree but with the added overall expense of requiring external memory to store the index and branch nodes. This is probably a nasty disadvantage. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 22:06:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19FCE106566C for ; Thu, 30 Sep 2010 22:06:56 +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 7D9D08FC19 for ; Thu, 30 Sep 2010 22:06:55 +0000 (UTC) Received: (qmail 22777 invoked from network); 30 Sep 2010 21:58:50 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2010 21:58:50 -0000 Message-ID: <4CA509FE.30303@freebsd.org> Date: Fri, 01 Oct 2010 00:06:54 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Roman Divacky References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> <20100930174900.GA37733@freebsd.org> <20100930180417.GA39381@freebsd.org> <4CA504AD.8000102@freebsd.org> In-Reply-To: <4CA504AD.8000102@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 22:06:56 -0000 On 30.09.2010 23:44, Andre Oppermann wrote: > On 30.09.2010 20:04, Roman Divacky wrote: >> On Thu, Sep 30, 2010 at 07:49:00PM +0200, Roman Divacky wrote: >>> On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote: >>>> On 30.09.2010 19:24, Roman Divacky wrote: >>>>> are you aware of Summer of Code 2008 project by Mayur Shardul? >>>> >>>> I remember that there was this project but I never saw any numbers >>>> or other outcome of it. Haven't checked p4 to look at the code >>>> though. >>> >>> there's a little something: >>> >>> http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement >> >> and the actual patch + userspace implementation + benchmarking suite >> is here: >> >> http://code.google.com/p/google-summer-of-code-2008-freebsd/downloads/detail?name=Mayur_Shardul.tar.gz&can=2&q= >> >> >> it looks like a solid work with solid results to me > > I just took a look (not in-depth though) at the patch and can't follow > your conclusion. It is not ready to go into svn in its current state. > > Even though it is called a radix trie it doesn't look like one. On first > impression it looks much more like an AA tree. A radix trie, which we > already have in our network routing table code, is a variable length > (mask) tree that does path compression. See net/radix.[ch] and > http://en.wikipedia.org/wiki/Radix_tree Thinking more about this I can't see any advantage of the radix trie becoming useful for the vmmap. The index of the vmmap is the address range and can't be expressed in a path compressable power of 2 quantity and is non-overlapping. The key for the trie, a pointer, has a fixed small size and can't be optimized away. And it is not a balanced tree. Many keys in the same region lead to long node traversals. In short: VMmap and a radix trie have an impedance mismatch and are unfit for each other imho. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 22:44:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CDDC1065673; Thu, 30 Sep 2010 22:44:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 400FE8FC1A; Thu, 30 Sep 2010 22:44:16 +0000 (UTC) Received: by iwn34 with SMTP id 34so3712033iwn.13 for ; Thu, 30 Sep 2010 15:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=TBLvS8wpxDKa2B9GxhSJZrUCLUOxnyqa4WhHqGte/tc=; b=uCLjDt+fs4lc9Q0io2N0LU3ocPPrZm3r2ogl0qkWg31sLOwBBjbKoidLipTA7gLTyO sHP0U/heIsVaELLCJGPCbu8chmS4n865v9ITMrAhPPz9/XLwUTlVYPaRTBfhrxP2dLRA YOD1q9IMVx3bHFtNZmX+lX/6oz8OR2wyq7aXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ndxQX0syjv1BJdxiyMu7abpDwIxrwTm7+Jydvu+vTvd9qt7mp8M1ybykep52KeOBF1 CY8cvhswWL2uxc8ts6IYSt/hXP+x1vRTwj6+CcVQUA6vaJ/ElPJ2E4PvSa52nZ/i4jIv sXyhjLijq/5OEWwTGKmJGqKFQ51+K/nVnMC3E= MIME-Version: 1.0 Received: by 10.231.191.74 with SMTP id dl10mr4501035ibb.157.1285885216030; Thu, 30 Sep 2010 15:20:16 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Thu, 30 Sep 2010 15:20:15 -0700 (PDT) In-Reply-To: <4CA50363.2030500@FreeBSD.org> References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> <4CA4FC05.3020407@FreeBSD.org> <4CA5011D.8080804@FreeBSD.org> <4CA50283.4000601@FreeBSD.org> <4CA50363.2030500@FreeBSD.org> Date: Thu, 30 Sep 2010 15:20:15 -0700 X-Google-Sender-Auth: QIU46d3jR-iyIf9kv9l1rCSpcdI Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 22:44:16 -0000 On Thu, Sep 30, 2010 at 2:38 PM, Doug Barton wrote: > On 9/30/2010 2:34 PM, Doug Barton wrote: >> >> On 9/30/2010 2:29 PM, Dimitry Andric wrote: >>> >>> On 2010-09-30 23:07, Doug Barton wrote: >>>> >>>> To what extent is HAL relevant here? I was sort of ambivalent about >>>> using it in FreeBSD, but my recent experimentation with ubuntu is >>>> starting to change my mind. >>> >>> Please read this first: https://wiki.ubuntu.com/Halsectomy :) >> >> Right, especially the bits about moving the functionality into the kernel. > > Sorry, I'm being too terse. What I'm saying is that we have an existing > "notifications" model that third party apps already know how to deal with. > If we're considering developing a notifications model of our own then we are > well served by looking at the work that has gone before (without violating > copyright issues, yadda yadda). The problem is that the current system proposed for Device Kit is based on file system notification. I know we can do this with kqueues to some degree, but we do some of our best work via sysctls, and using other methods of attack, so it would be nice if these were `abstracted' out into generic events with OS specific callback handlers. Anyhow, just something to toss around, but honestly apart from the disc tasting I see via hald whenever I insert a CD or DVD, I could really care less about that functionality, and it could be just as easily implemented via some other mechanism, similar to what we already have in devd, or something more kernel centric like others have suggested before with geom. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 22:50:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 002D71065675 for ; Thu, 30 Sep 2010 22:50:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 872DB8FC1D for ; Thu, 30 Sep 2010 22:50:06 +0000 (UTC) Received: by fxm9 with SMTP id 9so2230533fxm.13 for ; Thu, 30 Sep 2010 15:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=K3dfLwqdLa65PPQNghcdjtSproznHzGsNxfY/D4NpLg=; b=RTfMiZaYmu2u2X2r6ardIHGjD35ehTjqijGcByLQwDEhvn4xzM5f9uDUAmmpiNeVpV 8vSM9FMsq4CA6PFG3TYQYGxYLm4KHXZVg+owX45hzmHgqhLPBXiW4LZT/L2VHqkNtY8d VPNblmHUipJ5uLyqPqIOe8rfyHXcSHx0lKW/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dK1n7dHGAV7j5iHactXBlAwAWAlLaSBElT8UzCIl7kZwbjswzU/nQTq9a68LNKh/qq M+7JbC55BsKtTWkCryzjiOIrP40PwZ8tuG+Y+qRa9pX6VyUwCofYUg8w5tmtlXmxlbEP 28JIdcw4rToGBjkT4ciHCF8ckNr/F3/IZcCEI= MIME-Version: 1.0 Received: by 10.223.115.19 with SMTP id g19mr4638044faq.70.1285887004937; Thu, 30 Sep 2010 15:50:04 -0700 (PDT) Received: by 10.223.110.197 with HTTP; Thu, 30 Sep 2010 15:50:04 -0700 (PDT) In-Reply-To: <4CA509FE.30303@freebsd.org> References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> <20100930174900.GA37733@freebsd.org> <20100930180417.GA39381@freebsd.org> <4CA504AD.8000102@freebsd.org> <4CA509FE.30303@freebsd.org> Date: Thu, 30 Sep 2010 15:50:04 -0700 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 22:50:07 -0000 For the curious, DragonflyBSD went through this back in 2005. All the gory details are in the thread with Subject: "splay tree and red-black tree for vm_map entry lookups" [1] While things are most likely different now between the FreeBSD VM and the DragonflyBSD VM, it may be worthwhile checking out what they did, and why. They considered the FreeBSD splay-tree and compared it to red-black tree, and went with red-black. There's mention in that thread that NetBSD uses red-black trees. No idea if this is still correct. [1] http://leaf.dragonflybsd.org/mailarchive/kernel/2005-01/msg00121.html -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 03:41:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D67D106566C for ; Fri, 1 Oct 2010 03:41:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id ECFCB8FC21 for ; Fri, 1 Oct 2010 03:41:45 +0000 (UTC) Received: (qmail 31357 invoked by uid 399); 1 Oct 2010 03:41:44 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Oct 2010 03:41:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA55875.9060904@FreeBSD.org> Date: Thu, 30 Sep 2010 20:41:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Garrett Cooper References: <20100929211253.GA1250@freebsd.org> <4CA3B393.8060206@icyb.net.ua> <4CA3BD7C.9080306@feral.com> <4CA4FC05.3020407@FreeBSD.org> <4CA5011D.8080804@FreeBSD.org> <4CA50283.4000601@FreeBSD.org> <4CA50363.2030500@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 03:41:46 -0000 On 9/30/2010 3:20 PM, Garrett Cooper wrote: > The problem is that the current system proposed for Device Kit is > based on file system notification. I know we can do this with kqueues > to some degree, but we do some of our best work via sysctls, and using > other methods of attack, so it would be nice if these were > `abstracted' out into generic events with OS specific callback > handlers. I'm not a kernel developer so I'm not going to tell anyone _how_ to implement the internals of this idea. My point is that if we're going to implement something that the API should be compatible so that all of the client software that already works with HAL doesn't have to be rewritten, patched, or abandoned. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 03:57:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91A8E106564A; Fri, 1 Oct 2010 03:57:26 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 341E98FC18; Fri, 1 Oct 2010 03:57:25 +0000 (UTC) Received: by gwb15 with SMTP id 15so1271424gwb.13 for ; Thu, 30 Sep 2010 20:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=KqBKv8ZCXrX2PebYqCny7ZneiiN5J+5JOBdAWTSVT2Q=; b=ATjO7nh49Ih89bX9X6NjBkzz3Yg3D/FklYtngsWxfrHM1ttl4juNpsBKXQ2GD551N0 UvP/7Xeq1tdT0IYf8uPmbDHUm8WwXwQjwVu1vKag9U7IVCtFe6f7iyY2kr0uGbYb3/8q 25lKXJ8fOhMK0yxpUcNIqGF/tAYyNJf+8oXq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=ZfSElQoKp6WBypE3Cz4qghfRog/QujqEgfypA7oMAmLPmtzBWPGVsIZLxBPw/v5kKS IZ0TAD1pNTcOTAtRHUj/tHK8sIEhTeGC+xQ2TtDYPDowj1LxmDU45sfd4oqO6P4qF1CI 56WsAu5Wql4Z4LqGpOqkSUIJbXVaQ18vCy3nQ= Received: by 10.150.138.17 with SMTP id l17mr324369ybd.237.1285904114763; Thu, 30 Sep 2010 20:35:14 -0700 (PDT) Received: from ono-sendai.local ([75.111.34.169]) by mx.google.com with ESMTPS id q30sm339422ybk.8.2010.09.30.20.35.10 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 20:35:12 -0700 (PDT) Message-ID: <4CA556EB.902@gmail.com> Date: Thu, 30 Sep 2010 20:35:07 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org References: <4C732522.1010400@gmail.com> In-Reply-To: <4C732522.1010400@gmail.com> Content-Type: multipart/mixed; boundary="------------070203050204080303080401" Cc: Subject: Re: Sleep/Lenovo SL410 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 03:57:26 -0000 This is a multi-part message in MIME format. --------------070203050204080303080401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Success! After setting every possible suspend/resume sysctl, "sysctl hw.pci.do_power_resume=0" allowed suspend and resume. Still beeps 1-3 times before suspend, with rapid sleep light flashing until suspend complete. Kernel conf is attached. World built from last Friday's CVS, -CURRENT acpiconf -s3 works perfectly from console previously opened windows are garbled until refresh in X acpiconf -s4 causes shutdown, does not resume on power on. Swap is 2x RAM. VMstat -i rate is 540. Thank you FreeBSD! Matt --------------070203050204080303080401 Content-Type: text/plain; name="ONOSENDAI" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ONOSENDAI" # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.544 2010/04/25 22:01:32 thompsa Exp $ cpu HAMMER ident ONOSENDAI #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options GEOM_BDE # Encrypted filesystems with GBDE options GEOM_ELI # Encrypted filesystems with GELI options GEOM_JOURNAL # GJournal options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging for use in -current #options KDB # Enable kernel debugger #support. #options DDB # Support DDB. #options GDB # Support remote GDB. #options DEADLKRES # Enable the deadlock resolver #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ahci device ataahci device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives device atapicam # for acd0 -mod options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID #XXX it is not 64-bit clean, -scottl #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 Gigabit Ethernet Family #device igb # Intel PRO/1000 PCIE Server Gigabit Family #device ixgbe # Intel PRO/10GbE PCIE Ethernet Family #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device ae # Attansic/Atheros L2 FastEthernet #device age # Attansic/Atheros L1 Gigabit Ethernet #device alc # Atheros AR8131/AR8132 Ethernet #device ale # Atheros AR8121/AR8113/AR8114 Ethernet #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device et # Agere ET1310 10/100/Gigabit Ethernet #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sge # Silicon Integrated Systems SiS190/191 #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. device iwn # Intel wireless -mod device iwnfw # fw for intel wireless # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player # USB Serial devices device u3g # USB 3g Modems device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet device udav # Davicom DM9601E USB # USB Wireless device rum # Ralink Technology RT2501USB wireless NICs device uath # Atheros AR5523 wireless NICs device ural # Ralink Technology RT2500USB wireless NICs device zyd # ZyDAS zb1211/zb1211b wireless NICs # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons # sound device sound #device snd_hda # SL410 sound -mod # firewall device pf # firewall of choice device pflog device pfsync # other # crypto device crypto # crypto device # acpi option ACPI_DEBUG device acpi_ibm device smbus device smb device ichsmb device iicbus # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. #options VESA_DEBUG device dpms # DPMS suspend & resume via VESA BIOS # x86 real mode BIOS emulator, required by atkbdc/dpms/vesa options X86BIOS #other options PSM_HOOKRESUME #hook the system resume event, useful #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event device drm # DRM core module required by DRM drivers device i915drm # Intel i830 through i915 device coretemp device speaker device cpuctl options SC_PIXEL_MODE --------------070203050204080303080401-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 05:04:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3DA01068142 for ; Fri, 1 Oct 2010 05:04:13 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 523478FC19 for ; Fri, 1 Oct 2010 05:04:12 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o914nmog024966 for ; Thu, 30 Sep 2010 21:49:48 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o914nmVt024965; Thu, 30 Sep 2010 21:49:48 -0700 (PDT) Date: Thu, 30 Sep 2010 21:49:48 -0700 (PDT) From: Matthew Dillon Message-Id: <201010010449.o914nmVt024965@apollo.backplane.com> To: freebsd-current@freebsd.org References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> <20100930174900.GA37733@freebsd.org> <20100930180417.GA39381@freebsd.org> <4CA504AD.8000102@freebsd.org> <4CA509FE.30303@freebsd.org> Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 05:04:14 -0000 I don't remember the reference but I read a comprehensive comparison between various indexing methods about a year ago and the splay tree did considerably better than a RB-tree. The RB-tree actually did fairly poorly. Any binary tree-like structure makes fairly poor use of cpu caches. Splay trees work somewhat better as long as there is some locality of reference in the lookups, since the node being looked up is moved to the root. It isn't a bad trade-off. On the negative side all binary-tree-like structures tend to be difficult to MP-lock in a fine-grained manner (not that very many structures are locked at that fine a grain anyway, but it's a data point). Splay-trees are impossible to lock at a fine-grain due to the massive modifications made on any search and the movement of the root, and there are MP access issues too. -- What turned out to be the best indexing mechanism was a chained hash table whos hoppers were small linear arrays instead of single elements. So instead of pointer-chaining each element you have a small for() loop for 4-8 elements before you chain. The structure being indexed would NOT be integrated into the index directly, the index would point at the final structure from the hopper. For our purposes such linear arrays would contain a pointer and an indexing value in as small an element as possible (8-16 bytes), the idea being that you make the absolute best use of your cache line and L1 cache / memory burst. One random access (initial hash index), then linear accesses using a small indexing element, then one final random access to get to the result structure and validate that it's the one desired (at that point we'd be 99.9% sure that we have the right structure because we have already compared the index value stored in the hopper). As a plus the initial hash index also makes MP locking the base of the chains easier. I don't use arrayized chained hash tables in DFly either, but only because it's stayed fairly low on the priority list. cpu isn't really a major issue on systems these days. I/O is the bigger problem. RB-Trees are simply extremely convenient from the programming side, which is why we still use them. I was surprised that splay trees did so well vs RB-trees, I never liked the memory writes splay trees do let alone the impossibility of fine-grained locking. Originally I thought the writes would make performance worse, but they actually don't. Still, if I were to change any topologies now I would definitely go with the chained-hash / small-linear-array / chain / small-linear-array / chain mechanic. It seems to be the clear winner. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 05:53:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 934EE106564A for ; Fri, 1 Oct 2010 05:53:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52EB08FC0A for ; Fri, 1 Oct 2010 05:53:54 +0000 (UTC) Received: by iwn34 with SMTP id 34so4180310iwn.13 for ; Thu, 30 Sep 2010 22:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ijmxDKamgLMNXxHSwD+ep7q9PJ0DRVtD+g5PJfv5bmE=; b=h9uAau2vBBwR8Unnm3glcmruPUrk4ss5OSprzaKyKZ/Y+spQR5smG5DoQG2AF/UIEz rgflrWifIIbZAnSMpZ7Ip76IFr8Bn5hlPAL7uUsw12HLXnF92GgupghFVZqe4993orMQ xf5sl2QTmGClBMOC5BAcF8pAW8bd9D+njToC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gweMJpBI5hoNHqe4cT3Qg5TbY9ty2knbfrkvozyy/eTl9gM5Texxk8IYL46egCycC1 x7FXRPi8wZcNloUKYBz7+xAjjBNBlFhx8O1DoI7HqizjA0OIHIkAVxazQOy0vKB9jNPP jLzbAHmZBPfcOThq1Ik1ZAK7JeTVt/GpVVmfM= MIME-Version: 1.0 Received: by 10.231.118.28 with SMTP id t28mr3682214ibq.131.1285912433463; Thu, 30 Sep 2010 22:53:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.171.203 with HTTP; Thu, 30 Sep 2010 22:53:53 -0700 (PDT) In-Reply-To: <201010010449.o914nmVt024965@apollo.backplane.com> References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> <20100930174900.GA37733@freebsd.org> <20100930180417.GA39381@freebsd.org> <4CA504AD.8000102@freebsd.org> <4CA509FE.30303@freebsd.org> <201010010449.o914nmVt024965@apollo.backplane.com> Date: Fri, 1 Oct 2010 13:53:53 +0800 X-Google-Sender-Auth: Espu7z_Yj4aG2XQIyN0XjET1lsw Message-ID: From: Adrian Chadd To: Matthew Dillon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 05:53:54 -0000 On 1 October 2010 12:49, Matthew Dillon wrote= : > =A0 =A0What turned out to be the best indexing mechanism was a chained > =A0 =A0hash table whos hoppers were small linear arrays instead of single > =A0 =A0elements. =A0So instead of pointer-chaining each element you have = a small > =A0 =A0for() loop for 4-8 elements before you chain. =A0The structure bei= ng > =A0 =A0indexed would NOT be integrated into the index directly, the index > =A0 =A0would point at the final structure from the hopper. > > =A0 =A0For our purposes such linear arrays would contain a pointer and > =A0 =A0an indexing value in as small an element as possible (8-16 bytes), > =A0 =A0the idea being that you make the absolute best use of your cache l= ine > =A0 =A0and L1 cache / memory burst. =A0One random access (initial hash in= dex), > =A0 =A0then linear accesses using a small indexing element, then one fina= l > =A0 =A0random access to get to the result structure and validate that > =A0 =A0it's the one desired (at that point we'd be 99.9% sure that we hav= e > =A0 =A0the right structure because we have already compared the index val= ue > =A0 =A0stored in the hopper). =A0As a plus the initial hash index also ma= kes > =A0 =A0MP locking the base of the chains easier. Sounds like B+tree style stuff. Minimise the "seek" operations, as random lookup times are orders of magnitude slower than sequential access times. (Memory is hierarchial, who would've thunk. :-) Adrian From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 07:43:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A6E106566B; Fri, 1 Oct 2010 07:43:40 +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 2DD098FC14; Fri, 1 Oct 2010 07:43:38 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA06773; Fri, 01 Oct 2010 10:43:28 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P1aH9-000Ara-Tx; Fri, 01 Oct 2010 10:43:27 +0300 Message-ID: <4CA5911E.3000101@freebsd.org> Date: Fri, 01 Oct 2010 10:43:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alan Cox References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> In-Reply-To: <4CA3BD1E.5070807@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 07:43:40 -0000 on 30/09/2010 01:26 Alan Cox said the following: > On 9/29/2010 3:41 PM, Andriy Gapon wrote: >> So perhaps we need to add another level of indirection? >> I.e. first dump contiguous array of "pseudo-pde" entries that would point to >> chunks of "pseudo-pte" entries, so that "pseudo-pte" entries could be sparse. >> This is instead of dumping 1GB of contiguous "pseudo-ptes" as we do now. >> > > That would be the best approach. That said, for the foreseeable future, the > kernel page table on amd64 will have two valid ranges, no more, no less. So, if > it's much easier to modify minidump to deal with a page table that is assumed to > have two contiguous parts, just do it. That assumption should remain valid for > a few years. I tried to go for a full thing, at least how I understood it. Two hours of hacking frenzy and here is a result: http://people.freebsd.org/~avg/amd64-minidump.diff I hope that the code is not too ugly. At least my testing shows that it's not (badly) broken. The idea. We dump contiguously only pages with PDEs (which means both valid and invalid PDEs), valid pages with PTEs are dumped the same way as data physical pages (i.e. via dump_add_page, etc); no fake PTEs for 2MB pages. PDE area of the dump takes about 20MB as opposed to 1GB for PTE area (the math is obvious, but just in case). libkva is changed to treat former PTE area as PDE area and is also taught to understand PG_PS in PDE. There is now an overhead of having to first read a PTE page in V-to-P-to-offset lookup for !PG_PS case. Perhaps we could cache all PTEs in memory and have a lookup table for them, but I didn't bother with this possibly premature optimization at this time. There is an unrelated change in minidumpsys - "bitmap_frozen". I had to do it despite having a patch in my local tree to stop other CPUs on panic->dump. Code in dump path (peripheral disk driver, CAM, SIM driver, something else?) seems to do some memory allocations and change dump bitmap, which leads to a mismatch between dump size and dump bitmap; and also potentially to inconsistencies in the bitmap itself. So I decided that it's a good idea to freeze the bitmap once we decided what pages we want to dump. Some variables and structure fields with 'pte' in them should probably be renamed to have 'pde' instead. What do you think? I will appreciate reviews, testing, comments, etc. Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 08:53:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ACDA1065670 for ; Fri, 1 Oct 2010 08:53:49 +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 DA2618FC19 for ; Fri, 1 Oct 2010 08:53:48 +0000 (UTC) Received: (qmail 27992 invoked from network); 1 Oct 2010 08:45:37 -0000 Received: from unknown (HELO [62.48.0.92]) ([62.48.0.92]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Oct 2010 08:45:37 -0000 Message-ID: <4CA5A1B1.7050902@freebsd.org> Date: Fri, 01 Oct 2010 10:54:09 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CA4BCD2.4070303@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 08:53:49 -0000 On 30.09.2010 19:51, Ivan Voras wrote: > On 09/30/10 18:37, Andre Oppermann wrote: > >> Both the vmmap and page table make use of splay trees to manage the >> entries and to speed up lookups compared to long to traverse linked >> lists or more memory expensive hash tables. Some structures though >> do have an additional linked list to simplify ordered traversals. > > The property of splay tree requiring *writes* for nearly every read > really is a thorn in the eye for SMP. It seems to me that even if the > immediate benefits from converting to something else are not directly > observable, it will still be worth doing it. Fully agreed. > It's a shame that RCU is still a patent minefield :/ > > http://mirror.leaseweb.com/kernel/people/npiggin/patches/lockless/2.6.16-rc5/radix-intro.pdf I'm not convinced that RCU is the only scalable way of sharing a data structure across a possibly large number of CPU's. The term "lockless" is often used and frequently misunderstood. Having a lockess data structure *doesn't* mean that is either performant, scalable or both. It heavily depends on a number of additional factors. Many times "lockless" just replaces a simple lock/unlock cycle with a number of atomic operations on the data structure. This can easily backfire because an atomic operation just hides the computational complexity and also dirties the CPU's cache lines. Generally on cache coherent architectures almost all of the atomic operation is in HW with bus lock cycles, bus snooping and whatnot. While seemingly simple form the programmers point of view, the overhead and latency is still there. Needless to say that on more relaxed architectures (SPARC, Alpha, ...) the overhead is higher. Also important in the overall picture are the memory barrier semantics of locks. Some newer CPU's have started to provide hardware implemented lock managers and combine it with SMT features so that access to an already locked lock causes an immediate HW thread switch and on unlock a switch back. We also have rm_locks (read mostly locks) that do not require synchronization on read but have a more expensive write lock. In UMA we use a mix of global pools of elements with per-CPU caching of free elements. As always the best approach depends on the dominant access pattern of a structure. It all comes down to the amortization cost of the different locking or "lockless" strategies. It's also important to make sure that worst case behavior doesn't bring down the box. As a rule of thumb I use this: a) make sure the lock is held for only a small amount of time to avoid lock contention. b) do everything you can outside of the lock. c) if the lock is found to be heavily contended rethink the whole approach and check if other data structures can be used. d) minimize write accesses to memory in the lock protected shared data structure. e) PROFILE, DON'T SPECULATE! Measure the access pattern and measure the locking/data access strategy's cost in terms of CPU cycles consumed. f) on lookup heavy data structures avoid writing to memory and by it dirtying CPU caches. g) on modify heavy data structures avoid touching too many elements. h) on lookup and modify heavy data structure that are used across many CPU's all bets are off and a different data structure approach should be considered resulting ideally in case f). It all starts with the hypothesis that a data structure is not optimally locked. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 09:20:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B471065670 for ; Fri, 1 Oct 2010 09:20:42 +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 073F98FC16 for ; Fri, 1 Oct 2010 09:20:41 +0000 (UTC) Received: (qmail 28285 invoked from network); 1 Oct 2010 09:12:32 -0000 Received: from unknown (HELO [62.48.0.92]) ([62.48.0.92]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Oct 2010 09:12:32 -0000 Message-ID: <4CA5A7FF.5030602@freebsd.org> Date: Fri, 01 Oct 2010 11:21:03 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CA4BCD2.4070303@freebsd.org> <20100930172439.GA34369@freebsd.org> <4CA4CCF8.1050300@freebsd.org> <20100930174900.GA37733@freebsd.org> <20100930180417.GA39381@freebsd.org> <4CA504AD.8000102@freebsd.org> <4CA509FE.30303@freebsd.org> <201010010449.o914nmVt024965@apollo.backplane.com> In-Reply-To: <201010010449.o914nmVt024965@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 09:20:42 -0000 On 01.10.2010 06:49, Matthew Dillon wrote: > I don't remember the reference but I read a comprehensive comparison > between various indexing methods about a year ago and the splay tree > did considerably better than a RB-tree. The RB-tree actually did > fairly poorly. It heavily depends on the access pattern of data structure. Is it lookup, modify or insert/delete dominated? Or a mix of any of them. How heavily is the data structure shared across CPU's? Without this information it is impossible to make a qualified choice. Making general comparative statements on indexing methods without taking the access pattern and SMP/CPU cache behavior into account is going to lead to wrong approach 90% of the time. (Made that number of up ;-) > Any binary tree-like structure makes fairly poor use of cpu caches. > Splay trees work somewhat better as long as there is some locality > of reference in the lookups, since the node being looked up is moved > to the root. It isn't a bad trade-off. Again, it hugely depends on how good the locality is and how expensive the CPU cache line dirtying of the splay rotation is. You can quickly fall off an amortization *cliff* here. I agree with binary tree structures being a bit less optimal for CPU caches because the tree node is embedded with the data element. On the plus side not many other data structures are either. And as long as memory is only read it can be cached on multiple CPU's. Touching it throws it out everywhere else and causes a high latency memory access on the next read. > On the negative side all binary-tree-like structures tend to be > difficult to MP-lock in a fine-grained manner (not that very many > structures are locked at that fine a grain anyway, but it's a data > point). Splay-trees are impossible to lock at a fine-grain due to > the massive modifications made on any search and the movement > of the root, and there are MP access issues too. I doubt that fine grained locking of such data structures is beneficial in many cases. Fine grained locking implies more locks, more bus lock cycles, more memory barriers and more CPU cache dirtying. As long as a data structure's global lock is not significantly contended on and based on that a finer locking doesn't lead to parallel operation it just creates a lot of overhead for nothing. > -- > > What turned out to be the best indexing mechanism was a chained > hash table whos hoppers were small linear arrays instead of single > elements. So instead of pointer-chaining each element you have a small > for() loop for 4-8 elements before you chain. The structure being > indexed would NOT be integrated into the index directly, the index > would point at the final structure from the hopper. This makes a lot of sense if the index is sufficiently small, lets say one or two int's. When you go beyond that the advantage quickly fades away. > For our purposes such linear arrays would contain a pointer and > an indexing value in as small an element as possible (8-16 bytes), > the idea being that you make the absolute best use of your cache line > and L1 cache / memory burst. One random access (initial hash index), > then linear accesses using a small indexing element, then one final > random access to get to the result structure and validate that > it's the one desired (at that point we'd be 99.9% sure that we have > the right structure because we have already compared the index value > stored in the hopper). As a plus the initial hash index also makes > MP locking the base of the chains easier. Agreed under the premise that the access pattern fits this behavior. > I don't use arrayized chained hash tables in DFly either, but only > because it's stayed fairly low on the priority list. cpu isn't really > a major issue on systems these days. I/O is the bigger problem. > RB-Trees are simply extremely convenient from the programming side, > which is why we still use them. Agreed with the emphasis on including lock/atomic cycles and CPU cache hierarchy into I/O. > I was surprised that splay trees did so well vs RB-trees, I never liked > the memory writes splay trees do let alone the impossibility of > fine-grained locking. Originally I thought the writes would make > performance worse, but they actually don't. Still, if I were to change > any topologies now I would definitely go with the chained-hash / > small-linear-array / chain / small-linear-array / chain mechanic. It > seems to be the clear winner. Without first studying the accesses pattern and applying it to the various data structures this is a very speculative statement to make. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 10:38:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49195106566C; Fri, 1 Oct 2010 10:38:07 +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 A506B8FC14; Fri, 1 Oct 2010 10:38:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA09986; Fri, 01 Oct 2010 13:38:04 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P1d07-000B0C-TM; Fri, 01 Oct 2010 13:38:03 +0300 Message-ID: <4CA5BA0B.6010809@freebsd.org> Date: Fri, 01 Oct 2010 13:38:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> In-Reply-To: <4C84DBE6.5010809@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jung-uk Kim Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 10:38:07 -0000 on 06/09/2010 15:17 Andriy Gapon said the following: > on 29/08/2010 12:25 Andriy Gapon said the following: >> The below patch is against sources in FreeBSD tree, it should be applied >> either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending >> on the desired architecture: >> http://people.freebsd.org/~avg/intel-cpu-topo.diff > > I see that I am not getting as many testers as I expected, so I am going to commit > the patch. > > You still have a short while to either objectively object to the patch or to > voluntary test it :-) This is now committed as r213323. Many thanks to all the testers. MFC is planned in one month's time. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 05:24:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F5581065903 for ; Fri, 1 Oct 2010 05:24:45 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7538FC0C for ; Fri, 1 Oct 2010 05:24:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o91529qG067017; Fri, 1 Oct 2010 15:02:10 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 1 Oct 2010 15:02:09 +1000 (EST) From: Ian Smith To: Matt In-Reply-To: <4CA556EB.902@gmail.com> Message-ID: <20101001144505.C62022@sola.nimnet.asn.au> References: <4C732522.1010400@gmail.com> <4CA556EB.902@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 01 Oct 2010 11:02:41 +0000 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Sleep/Lenovo SL410 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 05:24:45 -0000 On Thu, 30 Sep 2010, Matt wrote: > Success! > > After setting every possible suspend/resume sysctl, > "sysctl hw.pci.do_power_resume=0" > allowed suspend and resume. Still beeps 1-3 times before suspend, with rapid > sleep light flashing until suspend complete. Interesting; $someone may document do_power_resume a bit more $someday? > Kernel conf is attached. > World built from last Friday's CVS, -CURRENT > > acpiconf -s3 works perfectly from console > previously opened windows are garbled until refresh in X Some thinkpads have responded positively in this regard to setting hw.syscons.sc_no_suspend_vtswitch=1 > acpiconf -s4 causes shutdown, does not resume on power on. Suspend To Disk is not expected to work; your laptop (like most) has no BIOS support for S4, as per your hw.acpi.s4bios: 0 cheers, Ian > Swap is 2x RAM. > > VMstat -i rate is 540. > > Thank you FreeBSD! > > Matt From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 13:31:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15AE6106566B for ; Fri, 1 Oct 2010 13:31:18 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAEE8FC0A for ; Fri, 1 Oct 2010 13:31:17 +0000 (UTC) Received: by wwb17 with SMTP id 17so3995896wwb.31 for ; Fri, 01 Oct 2010 06:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=60DDvysFm5jQ8X15gc9nJH17DuOUhFxX9JeTKYpU+10=; b=lsbavQtDY6v7q9iITF4FhziRDYOCXufWMv0++mCuEYw6z3oFmcdBeCT8Ws5JeO66mk T9ZRyhpxPxcvQuMJ1wprxrQDoww9IqqPiESovIdvy0tZE/TK3+6ZqOlR10vv2PM2O2uc UlVIzU+RZzA/LFBCJYDdmCnloiUANHQw6icLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=klnljI3sAVuSC+oxNcQUaEMzoC7tcq4bslKUmLzslECzjgNU+JqQLHb9R3bv2/8516 hT/i2j3D/nO0OaaDqqeDJRX+qNi+PvZO5zxzmqICIgqAKJJ9qPl/y/16aGZREYPqkZIe 1NgtHr+YlSzQofizkldJCePkI6HdsV2yknwK0= MIME-Version: 1.0 Received: by 10.216.180.200 with SMTP id j50mr2095636wem.36.1285938000119; Fri, 01 Oct 2010 06:00:00 -0700 (PDT) Received: by 10.216.172.210 with HTTP; Fri, 1 Oct 2010 06:00:00 -0700 (PDT) Date: Fri, 1 Oct 2010 15:00:00 +0200 Message-ID: From: Svatopluk Kraus To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: CACHE_LINE_SIZE too small, so struct vpglocks size alignment doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 13:31:18 -0000 Hallo, a size of 'struct vpglocks' is padded to CACHE_LINE_SIZE size in 'sys/vm/vm_page.h' header file. I work on a 'coldfire' port where CACHE_LINE_SIZE is 16 bytes and sizeof(struct mtx) is 20 bytes thus size alignment doesn't work. I solved it somehow, but I like to learn how to solve it in spirit of FreeBSD. There are a couple of possibilities: A1. Do nothing for small CACHE_LINE_SIZE. A2. Pad to multiple of CACHE_LINE_SIZE. B1. use #if with CACHE_LINE_SIZE B2. use #if with __coldfire__ When I use B1 solution I need to known sizeof(struct mtx) value in preprocessing time. So, is it correct to use something like 'assym.s' magic (sys/i386/i386/genassym.c) in MI code? Or has someone another suggestion? Regards, Svata From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 14:01:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11DA1106566B for ; Fri, 1 Oct 2010 14:01:22 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8EBB8FC16 for ; Fri, 1 Oct 2010 14:01:21 +0000 (UTC) Received: by iwn34 with SMTP id 34so4738330iwn.13 for ; Fri, 01 Oct 2010 07:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ozUcwsl04T7HlcBQaFF53EntBwYbraDFRjF786IGBYo=; b=g/U7w/Jd4rXdsq54qatRuDDmG4xjkttYweJ15B12mgpKEfSJjeugJMt46JEddBMfnJ CP5OI8lAazyydqHS6mwcFAX5uD6yBE54dsyVya63jjdOIY84aPUupIPWJJKrE7qfP2z7 6mtZ42bfVVgzuaPUH/deo/GUClHJBrwefRpK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=U8MMSbi+/Vb/mDqniD86gmXzzmpH/6JdOB/xZ0gIQnlLUosaR+3d9UtCSR8BntBSNI jkrAbAcTqsiuXGAi04WsAYJr8xkMWP0ixIMuy1iOfFxE6kv8ErtcR1tS87tewEo6vhP5 zhcAb4G/WriTBzQ7HXu8TC8a6jRXAv2Vy6L7U= MIME-Version: 1.0 Received: by 10.231.167.67 with SMTP id p3mr5736782iby.20.1285941680935; Fri, 01 Oct 2010 07:01:20 -0700 (PDT) Received: by 10.231.167.140 with HTTP; Fri, 1 Oct 2010 07:01:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Oct 2010 14:01:20 +0000 Message-ID: From: Matthew Fleming To: Svatopluk Kraus Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: CACHE_LINE_SIZE too small, so struct vpglocks size alignment doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 14:01:22 -0000 On Fri, Oct 1, 2010 at 1:00 PM, Svatopluk Kraus wrote: > Hallo, > > =A0a size of 'struct vpglocks' is padded to CACHE_LINE_SIZE size in > 'sys/vm/vm_page.h' > header file. I work on a 'coldfire' port where CACHE_LINE_SIZE is 16 byte= s and > sizeof(struct mtx) is 20 bytes thus size alignment doesn't work. > > =A0I solved it somehow, but I like to learn how to solve it in spirit > of FreeBSD. > There are a couple of possibilities: > > A1. Do nothing for small CACHE_LINE_SIZE. > A2. Pad to multiple of CACHE_LINE_SIZE. > > B1. use #if with CACHE_LINE_SIZE > B2. use #if with __coldfire__ > > When I use B1 solution I need to known sizeof(struct mtx) value in > preprocessing time. > So, is it correct to use something like 'assym.s' magic > (sys/i386/i386/genassym.c) > in MI code? Or has someone another suggestion? What about padding to CACHE_LINE_SIZE - (sizeof(struct vpglocks) & (CACHE_LINE_SIZE-1)) ? Some compilers will complain about 0-sized arrays, but gcc isn't one of the= m. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 14:11:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A590106566C for ; Fri, 1 Oct 2010 14:11:48 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id DBB0C8FC15 for ; Fri, 1 Oct 2010 14:11:47 +0000 (UTC) Received: from nagual.pp.ru (dev-null@localhost [127.0.0.1]) by nagual.pp.ru (8.14.4/8.14.4) with ESMTP id o91DxG5D089948 for ; Fri, 1 Oct 2010 17:59:16 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1285941556; bh=28pVqdfKP2ci/Ujk+3MEH+FaFb7WZTubqway2MQAN2E=; l=248; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=eRfSHcleaJx8erwpzOljdT2LJJNl4dow7gZskS+Kq3oCmQEhPGmu9dVYg4T+MwU6v LIwUHlkM231laKr/UllRha7BdPQRGbfC14RVcPDfu5q0bntj3ZgIZ3bs3vR/7aImdW YVjWSHfm2VBYYZtylsJ8z7NZ9hZqCIlURl4nNlvI= Received: (from ache@localhost) by nagual.pp.ru (8.14.4/8.14.4/Submit) id o91DxFLj089947 for current@freebsd.org; Fri, 1 Oct 2010 17:59:16 +0400 (MSD) (envelope-from ache) Date: Fri, 1 Oct 2010 17:59:15 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20101001135914.GA89850@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: ping6 cause kernel panic in nd6_output_lle() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 14:11:48 -0000 Pinging nonexistent IPv6 adress withing the same prefixlen 64 (i.e. nonexistent neighbor) immediately cause kernel panic in nd6_output_lle() See http://img837.imageshack.us/img837/7496/01102010f.jpg Please fix. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 18:28:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137A8106566C; Fri, 1 Oct 2010 18:28:58 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 97E668FC0A; Fri, 1 Oct 2010 18:28:57 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 553072A28D80; Fri, 1 Oct 2010 20:28:56 +0200 (CEST) Date: Fri, 1 Oct 2010 20:28:56 +0200 From: Ed Schouten To: Andre Oppermann Message-ID: <20101001182856.GF87427@hoeg.nl> References: <4CA4BCD2.4070303@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bNOIqPvWVsuhXMpy" Content-Disposition: inline In-Reply-To: <4CA4BCD2.4070303@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , freebsd-current@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 18:28:58 -0000 --bNOIqPvWVsuhXMpy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andre, * Andre Oppermann wrote: > A splay tree is an interesting binary search tree with insertion, > lookup and removal performed in O(log n) *amortized* time. With > the *amortized* time being the crucial difference to other binary trees. > On every access *including* lookup it rotates the tree to make the > just found element the new root node. For all gory details see: > http://en.wikipedia.org/wiki/Splay_tree Even though a red-black tree is quite good since it guarantees a $2 \log n$ upperbound, the problem is that it's quite computationally intensive. Maybe it would be worth looking at other types of balanced trees? For example, another type of tree which has only $O(\log n)$ amortized insertion/removal/lookup time, but could already be a lot better in practice, is a Treap. Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --bNOIqPvWVsuhXMpy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkymKGgACgkQ52SDGA2eCwVl5wCdHzG4YpvaU5cPp4uU0BB5fUM8 rd4An2KVKMItdIuTQVBkEopnKVc8/X+B =WSCh -----END PGP SIGNATURE----- --bNOIqPvWVsuhXMpy-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 18:48:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D98A106564A for ; Fri, 1 Oct 2010 18:48:25 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE7908FC24 for ; Fri, 1 Oct 2010 18:48:24 +0000 (UTC) Received: by yxn35 with SMTP id 35so1573880yxn.13 for ; Fri, 01 Oct 2010 11:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fHgyXu3lAPjKSXqtwxpCgZRI9o/2Z/UEQ5oKFH2HLmU=; b=B3b1ONqCRAx0yqY6QVU4iTJ/6dvjMmL/0+ro9YckjpKlnsI7wrK4NqMXZXhkkc8b+P olsGGsqL59xS0RpjrtNiVksvkV8tDzjLAlOSupdJWEg6jPaoPlMiMYwGL1GP63wcbbq1 z+Hn2Ghd9XF+KuGnohtFx+dwlD+dcwsaY+aiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CJ0MwvjZN1S3m0HzijLBXTQA6EqHscqoFluZuujIJhChIopOLi8moYOk8ScSCNk8Ru 3hLtazOVUeyq6thVqj7PO/BnqDtwHQMY0mt5OLez47tKrSCIkpgKdFFt0OcKpUCNTVcM ydsFaB+NoTTpwSHWkL6adRMSmwVJ2YrnNB+GQ= MIME-Version: 1.0 Received: by 10.220.157.143 with SMTP id b15mr1460433vcx.120.1285958516165; Fri, 01 Oct 2010 11:41:56 -0700 (PDT) Received: by 10.220.200.1 with HTTP; Fri, 1 Oct 2010 11:41:56 -0700 (PDT) In-Reply-To: <20101001144505.C62022@sola.nimnet.asn.au> References: <4C732522.1010400@gmail.com> <4CA556EB.902@gmail.com> <20101001144505.C62022@sola.nimnet.asn.au> Date: Fri, 1 Oct 2010 18:41:56 +0000 Message-ID: From: Paul B Mahol To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: Matt , freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Sleep/Lenovo SL410 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 18:48:25 -0000 On 10/1/10, Ian Smith wrote: > On Thu, 30 Sep 2010, Matt wrote: > > Success! > > > > After setting every possible suspend/resume sysctl, > > "sysctl hw.pci.do_power_resume=0" > > allowed suspend and resume. Still beeps 1-3 times before suspend, with > rapid > > sleep light flashing until suspend complete. > > Interesting; $someone may document do_power_resume a bit more $someday? It is already documented. > > > Kernel conf is attached. > > World built from last Friday's CVS, -CURRENT > > > > acpiconf -s3 works perfectly from console > > previously opened windows are garbled until refresh in X > > Some thinkpads have responded positively in this regard to setting > hw.syscons.sc_no_suspend_vtswitch=1 > > > acpiconf -s4 causes shutdown, does not resume on power on. > > Suspend To Disk is not expected to work; your laptop (like most) has no > BIOS support for S4, as per your hw.acpi.s4bios: 0 Suspend to disk does not work because FreeBSD does not support it. (s4bios is irrelevant here) From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 19:05:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928D7106566B for ; Fri, 1 Oct 2010 19:05:27 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A97A8FC16 for ; Fri, 1 Oct 2010 19:05:26 +0000 (UTC) Received: (qmail 32509 invoked from network); 1 Oct 2010 18:57:12 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Oct 2010 18:57:12 -0000 Message-ID: <4CA630F5.9060500@networx.ch> Date: Fri, 01 Oct 2010 21:05:25 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 01 Oct 2010 19:15:19 +0000 Cc: Subject: Very interesting paper: An Analysis of Linux Scalability to many Cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 19:05:27 -0000 Just saw the link to a very interesting paper on SMP scalability. A very good read and highly relevant for our efforts as well. In certain areas we may already fare better, in others we still have some work to do. An Analysis of Linux Scalability to many Cores ABSTRACT This paper analyzes the scalability of seven system applications (Exim, memcached, Apache, PostgreSQL, gmake, Psearchy, and MapReduce) running on Linux on a 48-core computer. Except for gmake, all applications trigger scalability bottlenecks inside a recent Linux kernel. Using mostly standard parallel programming techniques— this paper introduces one new technique, sloppy counters— these bottlenecks can be removed from the kernel or avoided by changing the applications slightly. Modifying the kernel required in total 3002 lines of code changes. A speculative conclusion from this analysis is that there is no scalability reason to give up on traditional operating system organizations just yet. http://pdos.csail.mit.edu/papers/linux:osdi10.pdf -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 21:48:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0E9E106566B for ; Fri, 1 Oct 2010 21:48:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA438FC21 for ; Fri, 1 Oct 2010 21:48:22 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o91LKcSa080856 for ; Fri, 1 Oct 2010 14:20:38 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o91LKcsg080855 for current@freebsd.org; Fri, 1 Oct 2010 14:20:38 -0700 (PDT) (envelope-from david) Date: Fri, 1 Oct 2010 14:20:38 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20101001212038.GE1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="inZzG0lmAPZRgTxV" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:48:23 -0000 --inZzG0lmAPZRgTxV Content-Type: multipart/mixed; boundary="OM63UbYQsNeyh2dn" Content-Disposition: inline --OM63UbYQsNeyh2dn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have recently acquired a new laptop (to replace the "Frankenlaptop" I've been using for the last several years). The new machine is a Dell Precision M4400, so it's pretty recent technology compared to what I'm used to. :-} I installed FreeBSD 8.1-R on slice 1, customized it a bit to work in my environment, then cloned slice 1 to slice 2, booted from slice 2, populated /usr/src via "svn co" (pointing to stable/8, and upgraded slice to stable/8 as of r213245. So far, so good. I tinkered with it a bit more, building ports the way I want them, &c.; the following day, I upgraded to r213267. That went well, so I cloned slice 2 to slice 4, used "svn switch" to flip /usr/src from slice 4 to head, booted from slice 4, and upgraded slice 4 to 9.0-CURRENT as of r213267. On the reboot following the install (the "smoke test"), I noticed that the machine got most of the way through the kernel probes, then hung (requiring a power cycle to break out of it). It did this a few more times, then the next boot worked. I thought this odd, but not necessarily demonstrating a problem with FreeBSD: I hadn't had much experienmce with this particular hardware, after all. The following day (as is my usual pattern), I upgraded slice 2 to stable/8 as of r213295 without incident. After upgrading the installed ports, I then booted from slice 4 (after several tries), then upgraded slice 4 to head as of r213295. Again, attempts to boot from slice 4 usually -- but not always -- would hang, always in the same place. Now, I had hada a somewhat-similar hang on my work desktop, which is also a Dell machine. And in that case -- though there were several differences, soime of which may well be relevant -- a BIOS upgrade resolved that issue. So I checked; the laptop had BIOS A19, and Dell had A23 available. This morning, I upgraded slice 2 to stable/8 as of r213322, booted slice 4, and upgraded it to head as of r213322. Again, it woudl hang more often than not. This afternoon, after receiving appropriate encouragement (that yes, I probably could use Dell's Linux BIOS updater from a KNOPPIX environment), I was able to successfully update the BIOS to A23. Unfortunately, booting head (slice 4) still hangs -- usually. I'm unable to detect a pattern in why it sometimes boots OK, while most of the time it hangs. So when it hangs (today), It's runing: FreeBSD localhost 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r213322: Fri Oct 1 10= :18:30 PDT 2010 root@g1-222.catwhisker.org.:/usr/obj/usr/src/sys/CANARY= i386 And looking at the stable/8 /var/log/messages, when it boots under head, it runs along: =2E.. Oct 1 13:37:41 localhost kernel: ugen6.1: at usbus6 Oct 1 13:37:41 localhost kernel: uhub6: on usbus6 Oct 1 13:37:41 localhost kernel: ugen7.1: at usbus7 Oct 1 13:37:41 localhost kernel: uhub7: on usbus7 Oct 1 13:37:41 localhost kernel: ad4: 238475MB = at ata2-master UDMA100 SATA 3Gb/s Oct 1 13:37:41 localhost kernel: acd0: DVDR at ata3-master UDMA100 SATA 1.5Gb/s Oct 1 13:37:41 localhost kernel: hdac0: HDA Codec #0: IDT 92HD71B7 Oct 1 13:37:41 localhost kernel: pcm0: at= cad 0 nid 1 on hdac0 Oct 1 13:37:41 localhost kernel: pcm1: at= cad 0 nid 1 on hdac0 Oct 1 13:37:41 localhost kernel: pcm2: a= t cad 0 nid 1 on hdac0 Oct 1 13:37:41 localhost kernel: uhub0: 2 ports with 2 removable, self pow= ered Oct 1 13:37:41 localhost kernel: uhub1: 2 ports with 2 removable, self pow= ered Oct 1 13:37:41 localhost kernel: uhub2: 2 ports with 2 removable, self pow= ered Oct 1 13:37:41 localhost kernel: uhub4: 2 ports with 2 removable, self pow= ered Oct 1 13:37:41 localhost kernel: uhub5: 2 ports with 2 removable, self pow= ered Oct 1 13:37:41 localhost kernel: uhub6: 2 ports with 2 removable, self pow= ered Oct 1 13:37:41 localhost kernel: uhub3: 6 ports with 6 removable, self pow= ered Oct 1 13:37:41 localhost kernel: uhub7: 6 ports with 6 removable, self pow= ered Oct 1 13:37:41 localhost kernel: acd0: FAILURE - INQUIRY ILLEGAL REQUEST a= sc=3D0x24 ascq=3D0x00=20 Oct 1 13:37:41 localhost kernel: (probe0:ata3:0:0:0): TEST UNIT READY. CDB= : 0 0 0 0 0 0=20 Oct 1 13:37:41 localhost kernel: (probe0:ata3:0:0:0): CAM status: SCSI Sta= tus Error Oct 1 13:37:41 localhost kernel: (probe0:ata3:0:0:0): SCSI status: Check C= ondition Oct 1 13:37:41 localhost kernel: (probe0:ata3:0:0:0): SCSI sense: NOT READ= Y asc:3a,1 (Medium not present - tray closed) Oct 1 13:37:41 localhost kernel: cd0 at ata3 bus 0 scbus1 target 0 lun 0 Oct 1 13:37:41 localhost kernel: cd0: Rem= ovable CD-ROM SCSI-0 device=20 Oct 1 13:37:41 localhost kernel: cd0: 100.000MB/s transfersSMP: AP CPU #1 = Launched! Oct 1 13:37:41 localhost kernel:=20 Oct 1 13:37:41 localhost kernel: cd0: Attempt to query device size failed:= NOT READY, Medium not present - tray closed Oct 1 13:37:41 localhost kernel: Trying to mount root from ufs:/dev/ad4s2a Oct 1 13:37:41 localhost kernel: ugen2.2: at usbus2 and stops right there when it hangs. When it does not hang, the boot continues at that point with: Oct 1 13:37:41 localhost kernel: WARNING: TMPFS is considered to be a high= ly experimental feature in FreeBSD. Oct 1 13:37:41 localhost kernel: wlan0: Ethernet address: 00:21:6a:26:34:c0 Oct 1 13:37:41 localhost kernel: iwn0: radio is disabled by hardware switch Oct 1 13:37:42 localhost kernel: em0: link state changed to DOWN Oct 1 13:37:44 localhost kernel: em0: link state changed to UP =2E... Now, I never saw this behavior with the old laptop, and I had been tracking stable/7, stable/8, and head on that on a daily basis ever since a stable/8 existed. (And I've been tracking head rather longer than that.) While I'm not about to assume that this indicates something wrong with FreeBSD, I'm a bit less inclined to believe that it might be a hardware/BIOS issue than I was yesterday. Here are some differences between what I saw with my work desktop vs. the new laptop: * Desktop would reliably hang on each alternate boot. No pattern detected for laptop, but hangs predominate (by a factor of about 4:1). * Desktop would hang on alternate boots regardless of which branch of FreeBSD I was trying to boot. Laptop only hangs on head. * BIOS upgrade resolved issue with desktop. So far, it hasn't with the laptop. How might I get sufficient appropriate additional detail that I might be able to help get this figured out, and possibly even fixed? I've attached a copy of the stable/8 dmesg.boot. I can get one form head, but this is what I have at the moment. I will, of course, be happy to test patches. Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --OM63UbYQsNeyh2dn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-STABLE #3 r213295: Thu Sep 30 04:11:06 PDT 2010 root@g1-222.catwhisker.org.:/common/S2/obj/usr/src/sys/CANARY i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.01-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x10676 Family =3D 6 Model =3D 17 St= epping =3D 6 Features=3D0xbfebfbff Features2=3D0x8e3fd AMD Features=3D0x20100000 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 3657080832 (3487 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, df351c00 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x930,0x934 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xf5000000-0xf5fff= fff,0xe0000000-0xefffffff,0xf2000000-0xf3ffffff irq 16 at device 0.0 on pci1 em0: port 0xefe0-0xefff mem 0x= f6fe0000-0xf6ffffff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:21:70:d5:28:dd uhci0: port 0x6f60-0x6f7f irq 20 at de= vice 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup =3D 0x2f00 usbus0: on uhci0 uhci1: port 0x6f80-0x6f9f irq 21 at de= vice 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup =3D 0x2f00 usbus1: on uhci1 uhci2: port 0x6fa0-0x6fbf irq 22 at de= vice 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup =3D 0x2f00 usbus2: on uhci2 ehci0: mem 0xfed1c400-0xfed1c7ff i= rq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf6fdc000-0xf6f= dffff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib2: at device 28.0 on pci0 pci11: on pcib2 pcib3: at device 28.1 on pci0 pci12: on pcib3 iwn0: mem 0xf1ffe000-0xf1ffffff irq 17 at devi= ce 0.0 on pci12 iwn0: MIMO 3T3R, MoW, address 00:21:6a:26:34:c0 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps pcib4: at device 28.2 on pci0 pci13: on pcib4 pcib5: at device 28.3 on pci0 pci14: on pcib5 uhci3: port 0x6f00-0x6f1f irq 20 at de= vice 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup =3D 0x2f00 usbus4: on uhci3 uhci4: port 0x6f20-0x6f3f irq 21 at de= vice 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup =3D 0x2f00 usbus5: on uhci4 uhci5: port 0x6f40-0x6f5f irq 22 at de= vice 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup =3D 0x2f00 usbus6: on uhci5 ehci1: mem 0xfed1c000-0xfed1c3ff i= rq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pci3: on pcib6 cbb0: irq 19 at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] cbb0: Bad Vcc requested fwohci0: <1394 Open Host Controller Interface> mem 0xf1bff800-0xf1bfffff ir= q 17 at device 1.1 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 4a:4f:c0:00:10:37:06:01 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x14a8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 4a:4f:c0:37:06:01 fwe0: Ethernet address: 4a:4f:c0:37:06:01 fwip0: on firewire0 fwip0: Firewire address: 4a:4f:c0:00:10:37:06:01 @ 0xfffe00000000, S400, ma= xrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMAS= TER mode pci3: at device 1.2 (no driver attach= ed) pci3: at device 1.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x6e70-0x6e77,0x6e78-0x6e7b,0x6e80-0x= 6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf mem 0xfed1c800-0xfed1cfff irq 19 at device= 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.20 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ichsmb0: port 0x1100-0x111f mem 0xf6= fdaf00-0xf6fdafff irq 19 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on ac= pi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xce7ff,0xce800-0xcffff pnpid ORM0= 000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: parallel port not found. est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me)=20 firewire0: bus manager 0=20 ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forward= ing enabled, default to deny, logging disabled load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ad4: 238475MB at ata2-master UDMA100 SATA 3Gb/s acd0: DVDR at ata3-master UDMA100 SATA 1.= 5Gb/s hdac0: HDA Codec #0: IDT 92HD71B7 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00=20 (probe0:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0=20 (probe0:ata3:0:0:0): CAM status: SCSI Status Error (probe0:ata3:0:0:0): SCSI status: Check Condition (probe0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray closed) cd0 at ata3 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 100.000MB/s transfersSMP: AP CPU #1 Launched! cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed Trying to mount root from ufs:/dev/ad4s2a ugen2.2: at usbus2 WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. wlan0: Ethernet address: 00:21:6a:26:34:c0 iwn0: radio is disabled by hardware switch --OM63UbYQsNeyh2dn-- --inZzG0lmAPZRgTxV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkymUKUACgkQmprOCmdXAD1ABwCfRcaCF88V/T3oAQK5kGdn3iot JQAAn2yDPjThplUscAJwJ0o/ZNjcXBpW =8zrT -----END PGP SIGNATURE----- --inZzG0lmAPZRgTxV-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 23:10:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3407B106566B for ; Fri, 1 Oct 2010 23:10:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id B9E818FC13 for ; Fri, 1 Oct 2010 23:10:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B949341C733; Sat, 2 Oct 2010 01:10:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id E4YA2084nxQ7; Sat, 2 Oct 2010 01:10:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B9E2C41C735; Sat, 2 Oct 2010 01:10:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 47E804448F3; Fri, 1 Oct 2010 23:06:59 +0000 (UTC) Date: Fri, 1 Oct 2010 23:06:58 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrey Chernov In-Reply-To: <20101001135914.GA89850@nagual.pp.ru> Message-ID: <20101001230637.J95502@maildrop.int.zabbadoz.net> References: <20101001135914.GA89850@nagual.pp.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: ping6 cause kernel panic in nd6_output_lle() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:10:08 -0000 On Fri, 1 Oct 2010, Andrey Chernov wrote: > Pinging nonexistent IPv6 adress withing the same prefixlen 64 (i.e. > nonexistent neighbor) immediately cause kernel panic in nd6_output_lle() > > See > http://img837.imageshack.us/img837/7496/01102010f.jpg want to try the patch from kern/148857? /bz -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 23:30:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 925B3106564A for ; Fri, 1 Oct 2010 23:30:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4576E8FC12 for ; Fri, 1 Oct 2010 23:30:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o91NU1hc081786 for ; Fri, 1 Oct 2010 16:30:01 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o91NU1gF081785 for current@freebsd.org; Fri, 1 Oct 2010 16:30:01 -0700 (PDT) (envelope-from david) Date: Fri, 1 Oct 2010 16:30:01 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20101001233001.GG1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5zn77Mes2TPnoMqf" Content-Disposition: inline In-Reply-To: <20101001212038.GE1535@albert.catwhisker.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:30:02 -0000 --5zn77Mes2TPnoMqf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 02:20:38PM -0700, David Wolfskill wrote: > I have recently acquired a new laptop (to replace the "Frankenlaptop" > I've been using for the last several years). > ... > While I'm not about to assume that this indicates something wrong > with FreeBSD, I'm a bit less inclined to believe that it might be a > hardware/BIOS issue than I was yesterday. >=20 > Here are some differences between what I saw with my work desktop vs. > the new laptop: >=20 > * Desktop would reliably hang on each alternate boot. No pattern > detected for laptop, but hangs predominate (by a factor of about 4:1). >=20 > * Desktop would hang on alternate boots regardless of which branch of > FreeBSD I was trying to boot. Laptop only hangs on head. >=20 > * BIOS upgrade resolved issue with desktop. So far, it hasn't with the > laptop. >=20 > How might I get sufficient appropriate additional detail that I might be > able to help get this figured out, and possibly even fixed? > ... At a colleague's suggestion, I tried disabling some of the devices in the BIOS. Under System Configuration/Miscellaneous Devices, there are several devices listed; eac is enabled by default. I found the disabling the "Module Bay" appears to avoid the hang -- reliably. That appears to be the minimally-invasive change necessary to avoid the hang. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --5zn77Mes2TPnoMqf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkymbvgACgkQmprOCmdXAD12ogCfZWoWTuu/gQmwiF8Yjjqd1GAn xvAAn3RaqsqL63/Hqr805hEUPLHLZNDR =hOXX -----END PGP SIGNATURE----- --5zn77Mes2TPnoMqf-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 01:33:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17F51065672 for ; Sat, 2 Oct 2010 01:33:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 984F48FC13 for ; Sat, 2 Oct 2010 01:33:45 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o921Xivq082433 for ; Fri, 1 Oct 2010 18:33:44 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o921XiDr082432 for current@freebsd.org; Fri, 1 Oct 2010 18:33:44 -0700 (PDT) (envelope-from david) Date: Fri, 1 Oct 2010 18:33:44 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20101002013344.GI1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cuYGGMKi0BuiS2pJ" Content-Disposition: inline In-Reply-To: <20101001233001.GG1535@albert.catwhisker.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 01:33:45 -0000 --cuYGGMKi0BuiS2pJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 04:30:01PM -0700, David Wolfskill wrote: > ... > I found the disabling the "Module Bay" appears to avoid the hang -- > reliably. >=20 > That appears to be the minimally-invasive change necessary to avoid the > hang. > .... Until I realized what was in the Modular Bay: the CD/CVD reader/burner. So I tried a variation on the theme: I left all the devices enabled, but I physically removed the device from the bay before booting -- and was unable to get it to fail. And -- just now -- I disabled the channel (via atacontrol(8)), inserted the drive, and enabled the channel: g1-222# atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present g1-222# atacontrol detach ata3 g1-222# atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present g1-222# atacontrol attach ata3 Master: acd0 SATA revision 1.x Slave: no device present g1-222# atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: acd0 SATA revision 1.x Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present g1-222#=20 This is running: FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r213322: = Fri Oct 1 10:18:30 PDT 2010 root@g1-222.catwhisker.org.:/usr/obj/usr/s= rc/sys/CANARY i386 Any ideas on what mught be causing CURRENT to hang -- sometimes -- given that it appears to involve the Modular Bay (or the specific device that is in the bay during the hang)? Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --cuYGGMKi0BuiS2pJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkymi/gACgkQmprOCmdXAD3TrgCbB/Th1w6vaEXBDcryehfFQ30J SbYAn3JMtOCcWbIe/JmQBL/Ze3agDHEc =5Y+B -----END PGP SIGNATURE----- --cuYGGMKi0BuiS2pJ-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 02:19:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B442106564A for ; Sat, 2 Oct 2010 02:19:21 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 001918FC20 for ; Sat, 2 Oct 2010 02:19:20 +0000 (UTC) Received: by wyb29 with SMTP id 29so2310243wyb.13 for ; Fri, 01 Oct 2010 19:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+Kmih2FcWAAbYnIcoVChs+MF2uFff5lhDXVKDmqWalQ=; b=QTe5TG2auDNh0IpNMVO488M+NrjXzPdfivSvapLLI92ATeq3FP4TUQLhnlgCvCZGix np9dsuT8kGgkOG7xRbulZsUE3c2LowKmt0BOP5vWq7a0H8oUruZFHZ049zvpnd9OSTGA ZDl6s7QZRHjOjc+iFJeAL3rqZhLgUWDdNYSY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JgsoR3JzG0nJXRsF9QzICKeBJELAFj8yhSyNQgbvoxGk2SkhfyWvlugn9I26uOVG87 8ubKi/l6jNNDaSpbz7KWYhOXLUB9f+anx4ou+UqcZt3/PZXb2mpaJuQ98uiajcFXnyKx pRrpfR1dVZN6Vh08LzfqRIn4Z8eil1+3ajPk4= MIME-Version: 1.0 Received: by 10.216.203.71 with SMTP id e49mr5152142weo.60.1285984573864; Fri, 01 Oct 2010 18:56:13 -0700 (PDT) Received: by 10.216.133.133 with HTTP; Fri, 1 Oct 2010 18:56:13 -0700 (PDT) In-Reply-To: <20101002013344.GI1535@albert.catwhisker.org> References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> Date: Fri, 1 Oct 2010 20:56:13 -0500 Message-ID: From: Brandon Gooch To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 02:19:21 -0000 On Fri, Oct 1, 2010 at 8:33 PM, David Wolfskill wrot= e: > On Fri, Oct 01, 2010 at 04:30:01PM -0700, David Wolfskill wrote: >> ... >> I found the disabling the "Module Bay" appears to avoid the hang -- >> reliably. >> >> That appears to be the minimally-invasive change necessary to avoid the >> hang. >> .... > > Until I realized what was in the Modular Bay: the CD/CVD reader/burner. > > So I tried a variation on the theme: =A0I left all the devices enabled, > but I physically removed the device from the bay before booting -- and > was unable to get it to fail. > > And -- just now -- I disabled the channel (via atacontrol(8)), inserted > the drive, and enabled the channel: > > g1-222# atacontrol list > ATA channel 0: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 1: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 2: > =A0 =A0Master: =A0ad4 SATA revision 2.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 3: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 4: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 5: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > g1-222# atacontrol detach ata3 > g1-222# atacontrol list > ATA channel 0: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 1: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 2: > =A0 =A0Master: =A0ad4 SATA revision 2.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 3: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 4: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 5: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > g1-222# atacontrol attach ata3 > Master: acd0 SATA revision 1.x > Slave: =A0 =A0 =A0 no device present > g1-222# atacontrol list > ATA channel 0: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 1: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 2: > =A0 =A0Master: =A0ad4 SATA revision 2.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 3: > =A0 =A0Master: acd0 SATA revision 1.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 4: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 5: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > g1-222# > > This is running: > > FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r213322= : Fri Oct =A01 10:18:30 PDT 2010 =A0 =A0 root@g1-222.catwhisker.org.:/usr/o= bj/usr/src/sys/CANARY =A0i386 > > Any ideas on what mught be causing CURRENT to hang -- sometimes > -- given that it appears to involve the Modular Bay (or the specific > device that is in the bay during the hang)? > If you haven't already, it may be worth trying 'options ATA_CAM' in your kernel config. -Brandon From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 02:22:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E839106566B for ; Sat, 2 Oct 2010 02:22:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C6F8C8FC08 for ; Sat, 2 Oct 2010 02:22:34 +0000 (UTC) Received: by iwn34 with SMTP id 34so5573248iwn.13 for ; Fri, 01 Oct 2010 19:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=I2yVSndzj0MVTc/CmLy/FF4j15/YvsEnKmDWaC1FlcM=; b=YMFECDp3gXCUbsNYOn3bBPnARoy9IQHq0ULGolKnWsW+C1Az4gEnODzoierpjgokI2 zzN78TKOiPONmLV4lOQGZcR1/18GuyRSJkBShfKfrP+npT41YlJkijo3S7j82+TC3aUP enpB45X7yKJyTMlrVLO3SPbUa2FsrKsCQ4qb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=oIUShG9+G7B9KIX4O9+e0uEUp7+uMUwvP7MNPo4MKOHl0A6a8yyaDwd44ojz1dmZig MjLofwsa5qRNAznS/c7DCfvmrMAOYJtBm0AHNKbB6F8NyWn+u15S08WMC9VwKuRwQ0bT W0Muws4yNfmL2qpTyyl/K60SV+Z4RI7eVP6qk= MIME-Version: 1.0 Received: by 10.231.191.147 with SMTP id dm19mr6653420ibb.6.1285986154000; Fri, 01 Oct 2010 19:22:34 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Fri, 1 Oct 2010 19:22:33 -0700 (PDT) In-Reply-To: <20101002013344.GI1535@albert.catwhisker.org> References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> Date: Fri, 1 Oct 2010 19:22:33 -0700 X-Google-Sender-Auth: rjP_EfFEr2X6HUd7EB8VS1TSkdA Message-ID: From: Garrett Cooper To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 02:22:35 -0000 On Fri, Oct 1, 2010 at 6:33 PM, David Wolfskill wrot= e: > On Fri, Oct 01, 2010 at 04:30:01PM -0700, David Wolfskill wrote: >> ... >> I found the disabling the "Module Bay" appears to avoid the hang -- >> reliably. >> >> That appears to be the minimally-invasive change necessary to avoid the >> hang. >> .... > > Until I realized what was in the Modular Bay: the CD/CVD reader/burner. > > So I tried a variation on the theme: =A0I left all the devices enabled, > but I physically removed the device from the bay before booting -- and > was unable to get it to fail. > > And -- just now -- I disabled the channel (via atacontrol(8)), inserted > the drive, and enabled the channel: > > g1-222# atacontrol list > ATA channel 0: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 1: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 2: > =A0 =A0Master: =A0ad4 SATA revision 2.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 3: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 4: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 5: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > g1-222# atacontrol detach ata3 > g1-222# atacontrol list > ATA channel 0: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 1: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 2: > =A0 =A0Master: =A0ad4 SATA revision 2.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 3: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 4: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 5: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > g1-222# atacontrol attach ata3 > Master: acd0 SATA revision 1.x > Slave: =A0 =A0 =A0 no device present > g1-222# atacontrol list > ATA channel 0: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 1: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 2: > =A0 =A0Master: =A0ad4 SATA revision 2.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 3: > =A0 =A0Master: acd0 SATA revision 1.x > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 4: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > ATA channel 5: > =A0 =A0Master: =A0 =A0 =A0no device present > =A0 =A0Slave: =A0 =A0 =A0 no device present > g1-222# > > This is running: > > FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r213322= : Fri Oct =A01 10:18:30 PDT 2010 =A0 =A0 root@g1-222.catwhisker.org.:/usr/o= bj/usr/src/sys/CANARY =A0i386 > > Any ideas on what mught be causing CURRENT to hang -- sometimes > -- given that it appears to involve the Modular Bay (or the specific > device that is in the bay during the hang)? Do you have boot -v output? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 03:24:28 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07009106564A for ; Sat, 2 Oct 2010 03:24:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id D2ADD8FC0C for ; Sat, 2 Oct 2010 03:24:27 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o923ORiO083317; Fri, 1 Oct 2010 20:24:27 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o923ORWa083316; Fri, 1 Oct 2010 20:24:27 -0700 (PDT) (envelope-from david) Date: Fri, 1 Oct 2010 20:24:27 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20101002032427.GJ1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Garrett Cooper , current@FreeBSD.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="29c+rP9cauTmUpOY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 03:24:28 -0000 --29c+rP9cauTmUpOY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 07:22:33PM -0700, Garrett Cooper wrote: > ... > > Any ideas on what mught be causing CURRENT to hang -- sometimes > > -- given that it appears to involve the Modular Bay (or the specific > > device that is in the bay during the hang)? >=20 > Do you have boot -v output? Yes; please see , which has: albert(8.1-S)[11] ls -lT total 196 -rw-r--r-- 1 david wheel 11497 Oct 1 20:19:06 2010 console.log -rw-r--r-- 1 david wheel 60397 Oct 1 19:26:23 2010 dmesg.boot -rw-r--r-- 1 david wheel 114752 Oct 1 20:21:50 2010 messages albert(8.1-S)[12]=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --29c+rP9cauTmUpOY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkympeoACgkQmprOCmdXAD2etACfQaQ61mML1LcRewpCTq94Ighc IVUAn2e7GV9+9F8vcGG0M3wtpzyEgGZC =VWY1 -----END PGP SIGNATURE----- --29c+rP9cauTmUpOY-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 03:37:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 346C41065672; Sat, 2 Oct 2010 03:37:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DCF948FC0A; Sat, 2 Oct 2010 03:37:50 +0000 (UTC) Received: by iwn34 with SMTP id 34so5631506iwn.13 for ; Fri, 01 Oct 2010 20:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Kfg21odWVik15WLLy68ZJdGDLQuV3FfN0VIQJ27Znk0=; b=LtApH0O44zMsZQXxyQ/Rq5ZzgRCIcCnNEWcRYIdzeoSBx0H5lKfYrHWyO7UL3yp0ZP OTimwrhLeoAAcOp3i7nlCud9t1juS7GAbNcUV/3MQ/4tVDt5q+JtSSB1MDofyLW4w3lT rejIUWrwhRc60Tv/iPuPpJH+L3HNnAQM1wtDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=KUl6CAGEQY99Na8/ag97tHEq5O+MCgvLHWuuNn6fP8yVCoJoNmbzbjQXKRv6I/vxdc fm7wRMZiCB4WVuUt0IUolzyABCfekAsuuojk2RHNIwb3IFXkVw2QQZZfeG4fOtnsjZAh c282OwA3QK9R8rqEYv2p7rFqVxw/cR7LIEBeo= MIME-Version: 1.0 Received: by 10.231.156.65 with SMTP id v1mr6660112ibw.107.1285990670167; Fri, 01 Oct 2010 20:37:50 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Fri, 1 Oct 2010 20:37:50 -0700 (PDT) In-Reply-To: <20101002032427.GJ1535@albert.catwhisker.org> References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002032427.GJ1535@albert.catwhisker.org> Date: Fri, 1 Oct 2010 20:37:50 -0700 X-Google-Sender-Auth: rIXCFjRhzScpaYoLmp_fnM49YoA Message-ID: From: Garrett Cooper To: David Wolfskill , Garrett Cooper , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 03:37:51 -0000 On Fri, Oct 1, 2010 at 8:24 PM, David Wolfskill wrot= e: > On Fri, Oct 01, 2010 at 07:22:33PM -0700, Garrett Cooper wrote: >> ... >> > Any ideas on what mught be causing CURRENT to hang -- sometimes >> > -- given that it appears to involve the Modular Bay (or the specific >> > device that is in the bay during the hang)? >> >> =A0 =A0 Do you have boot -v output? > > Yes; please see , > which has: > > albert(8.1-S)[11] ls -lT > total 196 > -rw-r--r-- =A01 david =A0wheel =A0 11497 Oct =A01 20:19:06 2010 console.l= og > -rw-r--r-- =A01 david =A0wheel =A0 60397 Oct =A01 19:26:23 2010 dmesg.boo= t > -rw-r--r-- =A01 david =A0wheel =A0114752 Oct =A01 20:21:50 2010 messages > albert(8.1-S)[12] This might sound like a stupid idea, but can you try booting with a CD/DVD in the drive? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 03:39:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D521A1065697 for ; Sat, 2 Oct 2010 03:39:00 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9011B8FC23 for ; Sat, 2 Oct 2010 03:39:00 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o923cxbp083485; Fri, 1 Oct 2010 20:38:59 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o923cxQv083484; Fri, 1 Oct 2010 20:38:59 -0700 (PDT) (envelope-from david) Date: Fri, 1 Oct 2010 20:38:59 -0700 From: David Wolfskill To: Brandon Gooch Message-ID: <20101002033859.GK1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Brandon Gooch , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="++AYaZ8Lu7KET2DY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 03:39:00 -0000 --++AYaZ8Lu7KET2DY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 08:56:13PM -0500, Brandon Gooch wrote: > ... > > Any ideas on what mught be causing CURRENT to hang -- sometimes > > -- given that it appears to involve the Modular Bay (or the specific > > device that is in the bay during the hang)? > > >=20 > If you haven't already, it may be worth trying 'options ATA_CAM' in > your kernel config. Well, I hadn't, so I tried it. And since I had read the note: # ATA_CAM: Turn ata(4) subsystem controller drivers into cam(4) # interface modules. This deprecates all ata(4) # peripheral device drivers (atadisk, ataraid, atapic= d, # atapifd, atapist, atapicam) and all user-level APIs. # cam(4) drivers and APIs will be connected instead. I had an idea that /etc/fstab would need a global edit (though I didn't know what device would be used). Attempting a single-user mode boot clarified that for me: :s/ad4/ada0/ Fortunately, I'm in the habit of keeping more than one bootable slice around, so I was able to accomplish that. And -- probably more important for this discussion -- I was unable to re-create the failing condition: the machine booted Just Fine every time I tried it, whether the CD/DVD drive was inserted or not. Now, this seems a bit more like a circumvention or diagnostic aid (to me) than an actual solution -- or am I misunderstanding? Thanks for the suggestion, though! Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --++AYaZ8Lu7KET2DY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkymqVMACgkQmprOCmdXAD0J/QCeK2DlXKXIw+sOT5uxp9nBmhJb 2L4An2Qs95l2RlNoVCSAaqEKVprANFjd =PVNC -----END PGP SIGNATURE----- --++AYaZ8Lu7KET2DY-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 03:41:57 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A2041065670; Sat, 2 Oct 2010 03:41:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0E77E8FC14; Sat, 2 Oct 2010 03:41:56 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o923fub4083500; Fri, 1 Oct 2010 20:41:56 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o923fuPr083499; Fri, 1 Oct 2010 20:41:56 -0700 (PDT) (envelope-from david) Date: Fri, 1 Oct 2010 20:41:56 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20101002034156.GL1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Garrett Cooper , current@FreeBSD.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002032427.GJ1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bUPNgY5xlcsGsZNb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 03:41:57 -0000 --bUPNgY5xlcsGsZNb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 08:37:50PM -0700, Garrett Cooper wrote: > ... > This might sound like a stupid idea, but can you try booting with > a CD/DVD in the drive? Ah -- sorry about that. :-( OK; it may be a bit before I get a successful verbose boot without ATA_CAM and with the CD/DVD drive inserted. But I will work on it and replace the files I placed with new ones. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --bUPNgY5xlcsGsZNb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkymqgMACgkQmprOCmdXAD2kSQCfRXwXdVUYkmjAjcMcfhwLGO30 QVEAn0VMd3AHVs/AaDvSA5JAy7uF9hSf =fN2I -----END PGP SIGNATURE----- --bUPNgY5xlcsGsZNb-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 03:52:29 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E8C5106564A; Sat, 2 Oct 2010 03:52:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id EB7618FC17; Sat, 2 Oct 2010 03:52:28 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o923qSAl083704; Fri, 1 Oct 2010 20:52:28 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o923qSfb083703; Fri, 1 Oct 2010 20:52:28 -0700 (PDT) (envelope-from david) Date: Fri, 1 Oct 2010 20:52:28 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20101002035228.GM1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Garrett Cooper , current@FreeBSD.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002032427.GJ1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UF02rXHtYm1UevNQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 03:52:29 -0000 --UF02rXHtYm1UevNQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 08:37:50PM -0700, Garrett Cooper wrote: > ... > > albert(8.1-S)[11] ls -lT > > total 196 > > -rw-r--r-- =A01 david =A0wheel =A0 11497 Oct =A01 20:19:06 2010 console= .log > > -rw-r--r-- =A01 david =A0wheel =A0 60397 Oct =A01 19:26:23 2010 dmesg.b= oot > > -rw-r--r-- =A01 david =A0wheel =A0114752 Oct =A01 20:21:50 2010 messages > > albert(8.1-S)[12] >=20 > This might sound like a stupid idea, but can you try booting with > a CD/DVD in the drive? Again, my apologies. And I got lucky: it booted OK on the second try. The files arfe now: albert(8.1-S)[2] ls -lT total 232 -rw-r--r-- 1 david wheel 22824 Oct 1 20:50:04 2010 console.log -rw-r--r-- 1 david wheel 60458 Oct 1 20:45:38 2010 dmesg.boot -rw-r--r-- 1 david wheel 142589 Oct 1 20:47:47 2010 messages albert(8.1-S)[3]=20 Thanks. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --UF02rXHtYm1UevNQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkymrHsACgkQmprOCmdXAD3rmQCePFTturCv0U9UUItL9R8nnhh9 2cEAn2/+s6cLMLGoI24dc5qk6bBu2dwC =/t5e -----END PGP SIGNATURE----- --UF02rXHtYm1UevNQ-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 05:18:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19E4E1065670 for ; Sat, 2 Oct 2010 05:18:40 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0AC28FC0A for ; Sat, 2 Oct 2010 05:18:39 +0000 (UTC) Received: by wyb29 with SMTP id 29so2386332wyb.13 for ; Fri, 01 Oct 2010 22:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3oyNfNafzJk9wavBmojGq0ESvZvZm9zteZ8aYwQLCj0=; b=eOC54BD5ZzsybevRIZkP3Gh14RB9PJ24UbtoO4+hLpgjHww+x2ofW7RQuUME6Yedxy pcYmh273NXLosClyZMqy4IyyJWIEl1Fybhm6yd9Obgq2onLREzfhsuTBvgJiRD0QX093 2FReNomnQEhgeCSC46utg8+mLwHLrY5XG0EL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=LC+VElBVmD60GJt4DIOhKd0fRbfGD9qoXkfryw4kIx1kcdwwdL+ytkYnlJDHRHxwK6 g0GdENJNsmuIYrUYE58AIBEei0XRNmSPNrlzuovo5dWb8aAWmvfA0gqNJy9cb9YPatc+ 5x3xbucPAgnYJbM1WhizKh1wAXjD6Tle2gVsM= MIME-Version: 1.0 Received: by 10.216.22.193 with SMTP id t43mr2865539wet.82.1285996718484; Fri, 01 Oct 2010 22:18:38 -0700 (PDT) Received: by 10.216.133.133 with HTTP; Fri, 1 Oct 2010 22:18:38 -0700 (PDT) In-Reply-To: <20101002033859.GK1535@albert.catwhisker.org> References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> Date: Sat, 2 Oct 2010 00:18:38 -0500 Message-ID: From: Brandon Gooch To: David Wolfskill , Brandon Gooch , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 05:18:40 -0000 On Fri, Oct 1, 2010 at 10:38 PM, David Wolfskill wro= te: > On Fri, Oct 01, 2010 at 08:56:13PM -0500, Brandon Gooch wrote: >> ... >> > Any ideas on what mught be causing CURRENT to hang -- sometimes >> > -- given that it appears to involve the Modular Bay (or the specific >> > device that is in the bay during the hang)? >> > >> >> If you haven't already, it may be worth trying 'options ATA_CAM' in >> your kernel config. > > Well, I hadn't, so I tried it. =A0And since I had read the note: > > # ATA_CAM: =A0 =A0 =A0 =A0 =A0 =A0 =A0Turn ata(4) subsystem controller dr= ivers into cam(4) > # =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interface modules. This dep= recates all ata(4) > # =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 peripheral device drivers (= atadisk, ataraid, atapicd, > # =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 atapifd, atapist, atapicam)= and all user-level APIs. > # =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cam(4) drivers and APIs wil= l be connected instead. > > I had an idea that /etc/fstab would need a global edit (though I > didn't know what device would be used). > > Attempting a single-user mode boot clarified that for me: > > =A0 =A0 =A0 =A0:s/ad4/ada0/ > > Fortunately, I'm in the habit of keeping more than one bootable slice > around, so I was able to accomplish that. > > And -- probably more important for this discussion -- I was unable to > re-create the failing condition: the machine booted Just Fine every > time I tried it, whether the CD/DVD drive was inserted or not. > > Now, this seems a bit more like a circumvention or diagnostic aid > (to me) than an actual solution -- or am I misunderstanding? > > Thanks for the suggestion, though! > The ATA_CAM option allows the use of the new CAM ATA infrastructure, replacing the legacy operation of the ATA devices. The following may be enlightening: http://lists.freebsd.org/pipermail/freebsd-current/2009-December/013956.htm= l I've been using it now on all of my newer machines; it's well worth the slight changes to your setups considering what you stand to gain. I definitely would not consider it a work-around, unless you absolutely require legacy operation of some device. -Brandon From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 09:48:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB7F9106566B for ; Sat, 2 Oct 2010 09:48:57 +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 1682C8FC0C for ; Sat, 2 Oct 2010 09:48:56 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26373 for ; Sat, 02 Oct 2010 12:48:55 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P1yi7-000Fds-5d for freebsd-current@FreeBSD.ORG; Sat, 02 Oct 2010 12:48:55 +0300 Message-ID: <4CA70006.2050602@freebsd.org> Date: Sat, 02 Oct 2010 12:48:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Fwd: Re: cam.3: do not discourage use of cam_open_device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 09:48:58 -0000 I would like to commit the following proposed changes in about a week. -------- Original Message -------- Reviving this thread. Sorry for top-posting. Here's a patch that removes any "artificial intelligence" from cam_get_device() and thus from cam_open_device() as well: http://people.freebsd.org/~avg/cam_get_device.diff This removes the following features: 1. ignoring 'r' and 'n' at the start of device name 2. ignoring whitespace at end of device name (why put it there in the first place) 3. parsing and ignoring slice and partition names So, only plain device names like /dev/foo0 or foo1 are supported. Perhaps we could also remove sd => da and st => sa mapping at this time too? on 23/04/2010 23:00 Andriy Gapon said the following: > on 23/04/2010 21:44 Kenneth D. Merry said the following: >> On Tue, Apr 20, 2010 at 21:01:26 +0300, Andriy Gapon wrote: >>> This is based on my understanding what Scott Long tried to explain me a while ago. >>> >>> Index: lib/libcam/cam.3 >>> =================================================================== >>> --- lib/libcam/cam.3 (revision 206902) >>> +++ lib/libcam/cam.3 (working copy) >>> @@ -190,12 +190,6 @@ >>> Once the device name and unit number >>> are determined, a lookup is performed to determine the passthrough device >>> that corresponds to the given device. >>> -.Fn cam_open_device >>> -is rather simple to use, but it is not really suitable for general use >>> -because its behavior is not necessarily deterministic. >>> -Programmers writing >>> -new applications should make the extra effort to use one of the other open >>> -routines documented below. >>> .Pp >>> .Fn cam_open_spec_device >>> opens the >>> >>> >>> It seems that this warning about ambiguity came from pre-devfs days when e.g. cd0 >>> nodes in different directories could correspond to different actual SCSI >>> peripherals. It seems that there wasn't an ambiguity if an absolute device path >>> was given. >>> >>> Nowadays, cam_open_device seems to always do a proper job of finding a correct >>> pass device. >> >> The warning had more to do with the ambiguity trying to make sense of >> device names than having different device nodes lying around. >> >> cam_get_device() (which is called by cam_open_device()) tries to do >> some things that will break on devices that start with n (unless it's a >> non-rewound tape device) or r. Right now we don't have any CAM peripheral >> drivers that start with those letters, so it works. It also won't do the >> right thing on devices with gpt partitions. Some of that can be fixed, >> though. >> >> So it's mostly deterministic, but it may not do exactly what you expect. >> >> It may be good to keep some statement in there pointing people to the other >> routines as being preferred because they're a little more deterministic. > > These are very valid concerns. > I was aware that we ditched "r" (raw) devices quite a while ago, but wasn't sure > about "n" kind as I have never dealt with tapes in my life. > Perhaps we can just remove that code now? > > Also, from my point of view, it doesn't make any sense to support > cam_open_device() calls on slices, partitions, etc. I mean, what is a > passthough device for a slice of disk? Can you send SCSI commands to a slice? > > All these comes from my (limited) practical experience with some userland > applications where people were afraid to use cam_open_device() because of the > warning in question. So they went out of the way to "manually" establish > mapping from an original device name to a corresponding passthough device. > > So, I'd like to let people know that it's totally OK to use cam_open_device() > with "normal" device names. I don't care about the extra logic ("r", "n" > prefixes; partition/slice suffixes). > > But that's only my point of view. > > And thank you for the explanation! > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 12:36:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D842106566B for ; Sat, 2 Oct 2010 12:36:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E15948FC19 for ; Sat, 2 Oct 2010 12:36:19 +0000 (UTC) Received: by qyk33 with SMTP id 33so1905119qyk.13 for ; Sat, 02 Oct 2010 05:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=n4Ress/3SvN/4e6KQxs9AoC/19/ATIKHwNc5SR/tThQ=; b=VyIiPTgktJhgTf4Aac0vawb8yJzrZyjago2ZIcXW9tblcflDciVPKxiMhRvOTqs45y yJrQl1FEXCLO4JFwWU4xT4SyIlLX8s8gp7CtL8r4AITy3MDu7uLPI/GKRldVOFoT7HKb wpOUL8IVqp/y/0SjD336OmHkdBi7vv7r8E9TQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DMy7c076+GOiNebxGYvtqFmaXhsEfpL/FfMb+sF4xxlQo9OKi5fkRbnOfTt94p5K63 AG027o6XXOUitunwI/yJinJy6mBAhNPYLrSeOTtN7tcSSa/ebjv4OuH7lInFH4y+UOoG V8WvRXOus8qx50P5S7pCaEuQelXlyQoxgjY3o= MIME-Version: 1.0 Received: by 10.224.114.33 with SMTP id c33mr4788618qaq.11.1286022979016; Sat, 02 Oct 2010 05:36:19 -0700 (PDT) Received: by 10.220.200.1 with HTTP; Sat, 2 Oct 2010 05:36:18 -0700 (PDT) Date: Sat, 2 Oct 2010 12:36:18 +0000 Message-ID: From: Paul B Mahol To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 12:36:20 -0000 Hi, I see no point to have it in usr/bin. From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 13:39:04 2010 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF64106564A for ; Sat, 2 Oct 2010 13:39:04 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 57FF08FC08 for ; Sat, 2 Oct 2010 13:39:03 +0000 (UTC) Received: from nagual.pp.ru (dev-null@localhost [127.0.0.1]) by nagual.pp.ru (8.14.4/8.14.4) with ESMTP id o92Dd2kt006883; Sat, 2 Oct 2010 17:39:02 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1286026742; bh=qq//7tl7ua/gLqAvlINueuo/E8gfmRz9+K7oH2kuECM=; l=571; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=qa06Y/RR5mdWftW2SxKiRbtLM4KPnP5qwIXjM7yQcn7U0teNcjv3NdtRhvrIuzZtK 2pH9DSh6uv3QyK6SArJ+x7F/ds178gdeqezw2z8bGQDPiYCKbOfQVIobT/cUfYkA80 cG80V5bwRZnBcTgduq4n67FYifDEH9dR25OqaDZM= Received: (from ache@localhost) by nagual.pp.ru (8.14.4/8.14.4/Submit) id o92Dd1dU006882; Sat, 2 Oct 2010 17:39:01 +0400 (MSD) (envelope-from ache) Date: Sat, 2 Oct 2010 17:39:00 +0400 From: Andrey Chernov To: "Bjoern A. Zeeb" Message-ID: <20101002133859.GA6862@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Bjoern A. Zeeb" , FreeBSD current mailing list References: <20101001135914.GA89850@nagual.pp.ru> <20101001230637.J95502@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101001230637.J95502@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD current mailing list Subject: Re: ping6 cause kernel panic in nd6_output_lle() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 13:39:04 -0000 On Fri, Oct 01, 2010 at 11:06:58PM +0000, Bjoern A. Zeeb wrote: > On Fri, 1 Oct 2010, Andrey Chernov wrote: > > > Pinging nonexistent IPv6 adress withing the same prefixlen 64 (i.e. > > nonexistent neighbor) immediately cause kernel panic in nd6_output_lle() > > > > See > > http://img837.imageshack.us/img837/7496/01102010f.jpg > > want to try the patch from kern/148857? For recent -current the patch have missing struct mbuf *m = NULL; declaration early in the nd6_llinfo_timer(). Besides that, it fix the panic, thanx! -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 14:53:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3631065674 for ; Sat, 2 Oct 2010 14:53:07 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 529928FC08 for ; Sat, 2 Oct 2010 14:53:06 +0000 (UTC) Received: by fxm9 with SMTP id 9so3319303fxm.13 for ; Sat, 02 Oct 2010 07:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sjx67wPdAoepvJQa3PuDdl4JMKaKC2qaxtTFAluHdZM=; b=eayuLU+ALLs1bs/2PrOkR59rTR7fl+F6wR0hS/5MTgbY3itmHC28U4+vb1hHNWOdWQ /QxKAZdHrjq2KnzKvh+pOT+/+db+TBQyrW1ejfamUdoBSkBGcswgHlPr45knKNOjgT9m QIed5M9tnxIjCKqezvNc7/1KvY9kJwf+gF+pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HakDEgo0xPm8dwLb33xxHrYiNJtto1KuAOubxuaaJD/84PePTHj4HBmwOQBaHqLCyu Caq3KvrljoXc0cPg6PADkOZeM4tJzsDvgcVxta3URIwYXfmN2IPEDe/nmUJcubvubFcg oC+Uwly5PIGMLVdkf19gMYmsyXvV/k2QJVTIY= MIME-Version: 1.0 Received: by 10.239.158.71 with SMTP id t7mr790828hbc.88.1286031186062; Sat, 02 Oct 2010 07:53:06 -0700 (PDT) Received: by 10.239.193.140 with HTTP; Sat, 2 Oct 2010 07:53:05 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Oct 2010 16:53:05 +0200 Message-ID: From: Davide Italiano To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 14:53:07 -0000 On Sat, Oct 2, 2010 at 2:36 PM, Paul B Mahol wrote: > Hi, > > I see no point to have it in usr/bin. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Consider that it could be used for system tasks , like print jobs. From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 15:03:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C568106564A for ; Sat, 2 Oct 2010 15:03:51 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C78558FC12 for ; Sat, 2 Oct 2010 15:03:50 +0000 (UTC) Received: by wyb29 with SMTP id 29so2673648wyb.13 for ; Sat, 02 Oct 2010 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HzQ51t3iNr2ZsIBMLx03/1nTS5UkTiaygg/3QFLXwX8=; b=DkccMHgVoKYpUNchjun7TkP8Q6EYMbXm4MMHWNM5K7a63FJRfCDmmCX2foPC1JCiuk OU2CNt1GSGaprsfX53Vr7LRdqKCKh5YNDVwRN9krtaXXSsYL2NjjNnq+qLqTX98mXcHv ULO9zDSRFOOeqahq593AThWC6hrJcFYdJ3dzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YQHkf1L1i61Gb57JyOuknkzE0xo8SWs4pKEz3p6Ddn/44KN7ifq8PJb5PD2+/yVxA5 vkPf1EtbCJYB8/QMLrYlewfCSjIDwJddwSykwvUVsVkeVwX5bbYmMXdagFPRsKSBqfBe Pl1ZhQeaTVxRh+AUqVErl08DQPj4NaNtzhbgY= MIME-Version: 1.0 Received: by 10.227.69.134 with SMTP id z6mr5562745wbi.201.1286031829854; Sat, 02 Oct 2010 08:03:49 -0700 (PDT) Received: by 10.216.133.133 with HTTP; Sat, 2 Oct 2010 08:03:49 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Oct 2010 10:03:49 -0500 Message-ID: From: Brandon Gooch To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 15:03:51 -0000 On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrote: > Hi, > > I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come the folks at my university who manage the line printers have never let me on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole "move it to games thing"... -Brandon aka "The Green Bar Bandit" From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 16:48:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85EED106566B for ; Sat, 2 Oct 2010 16:48:28 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 22C968FC13 for ; Sat, 2 Oct 2010 16:48:15 +0000 (UTC) Received: by gwb15 with SMTP id 15so1810990gwb.13 for ; Sat, 02 Oct 2010 09:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XFGyEGMRLlQ4U3RnrZt0PwnLoTEhH3d1u/WxvElf60s=; b=Sl/5x1lgqDuJvaMBZ4a9r/9dafJyPyqQYlrnLetGw3CrSoJglXbshV8fVtgJ8G4gRY dJMbrd3b08HtpODY+igTNKCgAdJNXaQ5YTz3FnC0b7p6DWUhlPLYKjUQubJydetQSCqh u806kirbmtYcbJpGkM+CIJ3xbpla443NETh/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f5aQSLqNxmpYCe9v/4Uw3qunTrX4MCir/FociTaapE3mp2kgt/Yg/6pKHj+zZXOUwn yfBnbIfAzprGs8ZQQeNBfDeMfC58O8c+nlhAKYE2Ph/7nhDKtUL7L67uL0bE13Wp5avL 6I9G3kaQ7Z50TtomhP0ZxAQB6f8IZsQM16WAc= MIME-Version: 1.0 Received: by 10.236.109.172 with SMTP id s32mr5314700yhg.66.1286038095303; Sat, 02 Oct 2010 09:48:15 -0700 (PDT) Received: by 10.220.200.1 with HTTP; Sat, 2 Oct 2010 09:48:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Oct 2010 16:48:15 +0000 Message-ID: From: Paul B Mahol To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 16:48:28 -0000 On 10/2/10, Brandon Gooch wrote: > On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrote: >> Hi, >> >> I see no point to have it in usr/bin. > > Cool! This is the first time I've heard of this program! How come the > folks at my university who manage the line printers have never let me > on to this?! > > Ahh -- wait a sec -- I'm beginning to see your point about the whole > "move it to games thing"... > > -Brandon aka "The Green Bar Bandit" > NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 16:55:24 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CB6F106566C; Sat, 2 Oct 2010 16:55:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 163FF8FC08; Sat, 2 Oct 2010 16:55:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o92GtNGl019332; Sat, 2 Oct 2010 12:55:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o92GtN2w019328; Sat, 2 Oct 2010 16:55:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 2 Oct 2010 16:55:23 GMT Message-Id: <201010021655.o92GtN2w019328@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 16:55:24 -0000 TB --- 2010-10-02 08:26:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-02 08:26:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-10-02 08:26:21 - cleaning the object tree TB --- 2010-10-02 08:31:22 - cvsupping the source tree TB --- 2010-10-02 08:31:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-10-02 08:40:37 - building world TB --- 2010-10-02 08:40:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-02 08:40:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-02 08:40:37 - TARGET=powerpc TB --- 2010-10-02 08:40:37 - TARGET_ARCH=powerpc TB --- 2010-10-02 08:40:37 - TZ=UTC TB --- 2010-10-02 08:40:37 - __MAKE_CONF=/dev/null TB --- 2010-10-02 08:40:37 - cd /src TB --- 2010-10-02 08:40:37 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 2 08:40:40 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 2 15:53:45 UTC 2010 TB --- 2010-10-02 15:53:45 - generating LINT kernel config TB --- 2010-10-02 15:53:45 - cd /src/sys/powerpc/conf TB --- 2010-10-02 15:53:45 - /usr/bin/make -B LINT TB --- 2010-10-02 15:53:45 - building LINT kernel TB --- 2010-10-02 15:53:45 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-02 15:53:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-02 15:53:45 - TARGET=powerpc TB --- 2010-10-02 15:53:45 - TARGET_ARCH=powerpc TB --- 2010-10-02 15:53:45 - TZ=UTC TB --- 2010-10-02 15:53:45 - __MAKE_CONF=/dev/null TB --- 2010-10-02 15:53:45 - cd /src TB --- 2010-10-02 15:53:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 2 15:53:46 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/powerpc/openpic.c awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/pic_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror pic_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/powerpc/pmap_dispatch.c /src/sys/powerpc/powerpc/pmap_dispatch.c: In function 'pmap_page_set_memattr': /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: 'pa' undeclared (first use in this function) /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: (Each undeclared identifier is reported only once /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: for each function it appears in.) /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: 'size' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-02 16:55:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-02 16:55:23 - ERROR: failed to build lint kernel TB --- 2010-10-02 16:55:23 - 5575.86 user 14858.96 system 30541.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 18:48:44 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79001065674; Sat, 2 Oct 2010 18:48:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 86E998FC1B; Sat, 2 Oct 2010 18:48:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o92ImhQA085418; Sat, 2 Oct 2010 14:48:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o92ImhFr085417; Sat, 2 Oct 2010 18:48:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 2 Oct 2010 18:48:43 GMT Message-Id: <201010021848.o92ImhFr085417@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 18:48:44 -0000 TB --- 2010-10-02 10:56:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-02 10:56:26 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-10-02 10:56:26 - cleaning the object tree TB --- 2010-10-02 11:00:23 - cvsupping the source tree TB --- 2010-10-02 11:00:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-10-02 11:07:09 - building world TB --- 2010-10-02 11:07:09 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-02 11:07:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-02 11:07:09 - TARGET=powerpc TB --- 2010-10-02 11:07:09 - TARGET_ARCH=powerpc64 TB --- 2010-10-02 11:07:09 - TZ=UTC TB --- 2010-10-02 11:07:09 - __MAKE_CONF=/dev/null TB --- 2010-10-02 11:07:09 - cd /src TB --- 2010-10-02 11:07:09 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 2 11:07:11 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 2 17:52:36 UTC 2010 TB --- 2010-10-02 17:52:36 - generating LINT kernel config TB --- 2010-10-02 17:52:36 - cd /src/sys/powerpc/conf TB --- 2010-10-02 17:52:36 - /usr/bin/make -B LINT TB --- 2010-10-02 17:52:36 - building LINT kernel TB --- 2010-10-02 17:52:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-02 17:52:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-02 17:52:36 - TARGET=powerpc TB --- 2010-10-02 17:52:36 - TARGET_ARCH=powerpc64 TB --- 2010-10-02 17:52:36 - TZ=UTC TB --- 2010-10-02 17:52:36 - __MAKE_CONF=/dev/null TB --- 2010-10-02 17:52:36 - cd /src TB --- 2010-10-02 17:52:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 2 17:52:37 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/powerpc/openpic.c awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/pic_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror pic_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/powerpc/pmap_dispatch.c /src/sys/powerpc/powerpc/pmap_dispatch.c: In function 'pmap_page_set_memattr': /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: 'pa' undeclared (first use in this function) /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: (Each undeclared identifier is reported only once /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: for each function it appears in.) /src/sys/powerpc/powerpc/pmap_dispatch.c:448: error: 'size' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-02 18:48:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-02 18:48:43 - ERROR: failed to build lint kernel TB --- 2010-10-02 18:48:43 - 5117.84 user 16435.31 system 28337.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full