From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 13:54: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 A4F9F106566B for ; Sun, 17 Oct 2010 13:54:25 +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 378428FC18 for ; Sun, 17 Oct 2010 13:54:24 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=VwQbUJbxAAAA:8 a=MqtWdLHOA0PUFXxu8IEA:9 a=XgprsCEb22RbgY8RhFcA:7 a=8ZslbrjzRBPLVSqX4EAYz_0RbdoA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 36249457 for freebsd-current@freebsd.org; Sun, 17 Oct 2010 15:54:23 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 17 Oct 2010 15:55:40 +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="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010171555.40751.hselasky@c2i.net> Subject: FYI: ACPI buffer overflow 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, 17 Oct 2010 13:54:25 -0000 ---------- Forwarded Message ---------- Subject: Re: MacBookPro 5,1 Date: Sunday 17 October 2010, 15:47:56 From: Hans Petter Selasky To: freebsd-acpi@freebsd.org CC: linux-acpi@vger.kernel.org Hi, CC'ing the Linux guys, hence I belive you are using the same ACPI code like in FreeBSD. It appears that when a string is present in the extended interrupt descriptor (6.4.3.6, ACPIspec30.pdf), then this is not handled correctly, meaning that the precomputed buffer space when encoding to AML, is incorrect and that data is written beyond the destination buffer! The error is catched on a MacBookPro 5,1 and is visible if you zero-pad all ACPI allocations to 4096 bytes, and verify that the freed buffer is not written beyond the allocation. Also the Extended interrupt descriptor must be the last element encoded in the AML. The quick patch is to disable these elements. I tried to figure out why this happens, but this particular handling in the code looks very obfuscated to me. src/sys/contrib/dev/acpica %svk diff === resources/rsmisc.c ================================================================== --- resources/rsmisc.c (revision 213698) +++ resources/rsmisc.c (local) @@ -311,6 +311,8 @@ case ACPI_RSC_SOURCEX: + break; /* RSC_SOURCEX is broken */ + /* * Optional ResourceSource (Index and String). This is the more * complicated case used by the Interrupt() macro @@ -537,6 +539,8 @@ case ACPI_RSC_SOURCEX: + break; /* RSC_SOURCEX is broken */ + /* * Optional ResourceSource (Index and String) */ Any comments are welcome! --HPS ----------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 17:28: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 BD7361065679 for ; Sun, 17 Oct 2010 17:28:20 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFA88FC1C for ; Sun, 17 Oct 2010 17:28:20 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P7VkR-0004i2-7Z for freebsd-current@freebsd.org; Sun, 17 Oct 2010 18:06:11 +0200 Message-ID: <4CBB1EF2.3010606@gwdg.de> Date: Sun, 17 Oct 2010 18:06:10 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.9) Gecko/20100921 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Subject: bge0 does not work anymore 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, 17 Oct 2010 17:28:20 -0000 I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays kernel the driver 'bge0' does not work anymore. With kernel from October 9th it does. The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x00a002; CHIP ID 0x0000a0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. The entry in /etc/rc.conf is 'ifconfig_bge0="DHCP". Does anyone else observe this behaviour? Is there something I can try? Thanks in advance, Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 18:19:48 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 877D1106564A; Sun, 17 Oct 2010 18:19:48 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 145AC8FC0A; Sun, 17 Oct 2010 18:19:47 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.4/8.14.4) with ESMTP id o9HI7b6g073145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Oct 2010 11:07:38 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201010171807.o9HI7b6g073145@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 17 Oct 2010 11:07:32 -0700 To: Rainer Hurling , freebsd-current@freebsd.org From: Manfred Antar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=no version=3.3.1, No X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: o9HI7b6g073145 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: marius@freebsd.org Subject: Re: bge0 does not work anymore 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, 17 Oct 2010 18:19:48 -0000 At 09:06 AM 10/17/2010, Rainer Hurling wrote: >I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays kernel the driver 'bge0' does not work anymore. With kernel from October 9th it does. > >The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x00a002; CHIP ID 0x0000a0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. > >The entry in /etc/rc.conf is 'ifconfig_bge0="DHCP". > >Does anyone else observe this behaviour? Is there something I can try? > >Thanks in advance, >Rainer Hurling Same here, the last time it worked was Oct 14. with Current source. uname -a : FreeBSD pozo.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Oct 14 14:13:47 PDT 2010 root@pozo.com:/sys/i386/compile/COMPAQ i386 i have ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0" in rc.conf ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 18:39: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 DCBFB106566C; Sun, 17 Oct 2010 18:39:16 +0000 (UTC) (envelope-from yr.retarded@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 42FC78FC12; Sun, 17 Oct 2010 18:39:15 +0000 (UTC) Received: by ewy21 with SMTP id 21so129369ewy.13 for ; Sun, 17 Oct 2010 11:39: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 :content-transfer-encoding; bh=Faius4nN4lmsSdS4QEUJAFcbXJklzQuU4SmYBev3Gsk=; b=r+yJnU63m7YMTYma450HpkmPFlNjvOf7UXLh7Bsd1Z8SJdVyo9Vr7Erkry5fS5mekr BTr/A2yeMeXJKXw5eoK89WnoivUpThjMFtFvR7HrTfXujP4k+PCijAmUKUyG6j/mH5y9 g08qnW/xBhGS/HlMsVxeiygxVGyhoUWWjNZEE= 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=YVshsf0y8xkQ2e7U1fdLcdtj+mnrOL0AZztFlBdCLjLW/hLXe2FMAxf7T8axxRBv6A az9UytqMeU0hv2KVPwyuShf1fmEKebNkoSJ98nFqEotF3aa1KcvocLV+nst1fHd8jANA 1gnDakErUahnT3gquOyODq+MMb99OC9TjTlOg= MIME-Version: 1.0 Received: by 10.216.231.227 with SMTP id l77mr4194165weq.104.1287339089124; Sun, 17 Oct 2010 11:11:29 -0700 (PDT) Received: by 10.216.50.65 with HTTP; Sun, 17 Oct 2010 11:11:29 -0700 (PDT) In-Reply-To: References: <20101015191802.GA55182@wep4035.physik.uni-wuerzburg.de> <20101015204947.N10185@maildrop.int.zabbadoz.net> Date: Sun, 17 Oct 2010 13:11:29 -0500 Message-ID: From: Chris Ruiz To: Mark Murray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current mailing list Subject: Re: Setting up IPv6 in /etc/rc.conf 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, 17 Oct 2010 18:39:16 -0000 On Sat, Oct 16, 2010 at 3:15 AM, Mark Murray wrote: > "Bjoern A. Zeeb" writes: >> On Fri, 15 Oct 2010, Mark Murray wrote: >> >> > Alexey Shuvaev writes: >> >>> gifconfig_gif0_ipv6=3D"2001:1111:2222:3333::2 2001:1111:2222:3333::1= prefixlen 128" >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0^^^^ >> >> I suppose you should prefix it with "inet6" keyword. >> >> There are 2 examples in rc.conf (search for "Sample IPv6"). >> > >> > Aaaaah! >> > >> > It didn't occur to me that I might need TWO inet6's! I'll give that a = go when >> > I play with this again tomorrow. >> >> It's just one inet6; put there what you would pass to ifconfig on the >> command line. =A0The fact that ifconfig defaults to "inet" is the >> problem leading to more confusion. > > In which case, I'm back to square one. What should work doesn't. > > I have the necessary commands in /etc/rc.local to bring up IPv6. > >> I think the samples in defaults/rc.conf will be more clear soon. > > Cool! Thanks. You have a few syntax errors in your rc.conf, try these adjustments and everything "should" work (as it works for me on a recent CURRENT.) gif_interfaces=3D"gif0" gifconfig_gif0=3D"192.168.0.2 11.22.33.44" ifconfig_gif0_ipv6=3D"inet6 2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" ipv6_defaultrouter=3D"2001:1111:2222:3333::1" -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 22:55:37 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 BD7FD106566C for ; Sun, 17 Oct 2010 22:55:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 67DBE8FC08 for ; Sun, 17 Oct 2010 22:55:37 +0000 (UTC) Received: (qmail 9202 invoked by uid 399); 17 Oct 2010 22:55:36 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Oct 2010 22:55:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CBB7EE6.3040102@FreeBSD.org> Date: Sun, 17 Oct 2010 15:55:34 -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 X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexey Dokuchaev Subject: Is nvidia-driver 256.53 expected to work on -current? 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, 17 Oct 2010 22:55:37 -0000 Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but when I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 23:19: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 3F6FC1065694 for ; Sun, 17 Oct 2010 23:19:30 +0000 (UTC) (envelope-from ralphellis1@netscape.ca) Received: from smtp-2.vancouver.ipapp.com (smtp-2.vancouver.ipapp.com [216.152.192.163]) by mx1.freebsd.org (Postfix) with ESMTP id DEA1B8FC39 for ; Sun, 17 Oct 2010 23:19:29 +0000 (UTC) Received: from [192.168.123.102] ([172.162.130.250]) by smtp-2.vancouver.ipapp.com ; Sun, 17 Oct 2010 16:19:14 -0700 Message-ID: <4CBB8459.1090507@netscape.ca> Date: Sun, 17 Oct 2010 19:18:49 -0400 From: Ralph Ellis User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.13) Gecko/20100929 SeaMonkey/2.0.8 MIME-Version: 1.0 To: Doug Barton References: <4CBB7EE6.3040102@FreeBSD.org> In-Reply-To: <4CBB7EE6.3040102@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Country: US Cc: Alexey Dokuchaev , freebsd-current@FreeBSD.org Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 17 Oct 2010 23:19:30 -0000 Doug Barton wrote: > Y'all will probably recall that I had a lot of problems with the > nvidia-driver, and video generally (esp. flash) on i386 -current. Well > I haven't had any problems recently because I haven't been using > FreeBSD. :) But I have things I need to catch up on, so here's what I > did: > > 1. Bought a new hard drive, and installed a snapshot of amd64 -current > (this was actually done a while ago). > 2. Yesterday I started configuring stuff, updated my source and ports > trees, rebuilt the world, customized the kernel, etc. > 3. With a newly up to date system I built the latest version of the > nvidia-driver port, and started using it. > > My experience with it has been exactly the same as older versions of > the port on previous versions of i386 -current. Sometimes it runs fine > for a while, but whe n I exit the window manager (openbox) the system > hangs and I never get back to the command prompt. (I'm using startx to > try and minimize the number of variables.) Sometimes it will work fine > for an hour, maybe two, then the whole thing just hangs. All the stuff > is displayed on the screen, but the mouse won't move, I can't zap X, > or even switch to the console. I have to power off. This is > particularly frustrating because I haven't even loaded flash (or for > that matter firefox) yet. > > Windows and linux (ubuntu, with the nvidia driver) work great on this > same hardware, so I'm pretty thoroughly convinced that the problem is > with freebsd/current somewhere. In addition to the -current partition > I also installed amd64 8.1-RELEASE so I'll give that a go next, but I > wanted to ask here first if anyone else was having problems on -current. > > > Doug > I am currently running the Nvidia 195 driver on amd64 9 - current from the ports tree. It works without problems. When I tried to compile the 256 driver, it would not compile and said that it was not meant to work with 9 - current. Hope this helps. Ralph Ellis ralphellis1@netscape.ca From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 23:32:00 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C8DD01065673; Sun, 17 Oct 2010 23:32:00 +0000 (UTC) Date: Sun, 17 Oct 2010 23:32:00 +0000 From: Alexander Best To: Ralph Ellis Message-ID: <20101017233200.GA69700@freebsd.org> References: <4CBB7EE6.3040102@FreeBSD.org> <4CBB8459.1090507@netscape.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CBB8459.1090507@netscape.ca> Cc: freebsd-current@FreeBSD.org, Alexey Dokuchaev , Doug Barton Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 17 Oct 2010 23:32:00 -0000 On Sun Oct 17 10, Ralph Ellis wrote: > Doug Barton wrote: > >Y'all will probably recall that I had a lot of problems with the > >nvidia-driver, and video generally (esp. flash) on i386 -current. Well > >I haven't had any problems recently because I haven't been using > >FreeBSD. :) But I have things I need to catch up on, so here's what I > >did: > > > >1. Bought a new hard drive, and installed a snapshot of amd64 -current > >(this was actually done a while ago). > >2. Yesterday I started configuring stuff, updated my source and ports > >trees, rebuilt the world, customized the kernel, etc. > >3. With a newly up to date system I built the latest version of the > >nvidia-driver port, and started using it. > > > >My experience with it has been exactly the same as older versions of > >the port on previous versions of i386 -current. Sometimes it runs fine > >for a while, but whe n I exit the window manager (openbox) the system > >hangs and I never get back to the command prompt. (I'm using startx to > >try and minimize the number of variables.) Sometimes it will work fine > >for an hour, maybe two, then the whole thing just hangs. All the stuff > >is displayed on the screen, but the mouse won't move, I can't zap X, > >or even switch to the console. I have to power off. This is > >particularly frustrating because I haven't even loaded flash (or for > >that matter firefox) yet. > > > >Windows and linux (ubuntu, with the nvidia driver) work great on this > >same hardware, so I'm pretty thoroughly convinced that the problem is > >with freebsd/current somewhere. In addition to the -current partition > >I also installed amd64 8.1-RELEASE so I'll give that a go next, but I > >wanted to ask here first if anyone else was having problems on -current. > > > > > >Doug > > > I am currently running the Nvidia 195 driver on amd64 9 - current from > the ports tree. It works without problems. > When I tried to compile the 256 driver, it would not compile and said > that it was not meant to work with 9 - current. i'm running 256.52 on HEAD (amd64) without any issues. the 260.X drivers all freze my computer when i exit X. it's quite easy to work around the isse that the nvidia drivers fail to compile on HEAD. simply change the line #if __FreeBSD_version >= 900000 in src/nv-freebsd.h to #if __FreeBSD_version >= 1000000. cheers. alex > Hope this helps. > Ralph Ellis > ralphellis1@netscape.ca > > -- a13x From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 23:49: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 63B73106566B; Sun, 17 Oct 2010 23:49:06 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F19D98FC08; Sun, 17 Oct 2010 23:49:05 +0000 (UTC) Received: by vws1 with SMTP id 1so188157vws.13 for ; Sun, 17 Oct 2010 16:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.192.4 with SMTP id do4mr937947vcb.61.1287359344883; Sun, 17 Oct 2010 16:49:04 -0700 (PDT) Received: by 10.220.188.3 with HTTP; Sun, 17 Oct 2010 16:49:04 -0700 (PDT) X-Originating-IP: [128.95.133.82] In-Reply-To: <4CBB7EE6.3040102@FreeBSD.org> References: <4CBB7EE6.3040102@FreeBSD.org> Date: Sun, 17 Oct 2010 16:49:04 -0700 Message-ID: From: Rob Farmer To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexey Dokuchaev , freebsd-current@freebsd.org Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 17 Oct 2010 23:49:06 -0000 On Sun, Oct 17, 2010 at 15:55, Doug Barton wrote: > Windows and linux (ubuntu, with the nvidia driver) work great on this same > hardware, so I'm pretty thoroughly convinced that the problem is with > freebsd/current somewhere. In addition to the -current partition I also > installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask > here first if anyone else was having problems on -current. I am running 256.53 on amd64 current (r213747). I don't use anything linux (the module isn't loaded) and built the driver with all options off except ACPI_PM. My custom kernel does not have "device agp". I use XFCE 4, don't really run anything graphically intense, and shutdown at night. I haven't had any problems, but IIRC from your past threads, the issues sort of build over time so I simply may not be aggravating the problem enough. The system is a HP Pavillion dv6405us laptop with a GeForce Go 6150. This is a pretty crappy card, even in Windows (the whole system was $500 3 years ago - it was one of those computers that supposedly was "Vista Ready" but could barely boot it), so I doubt I am gaining much over vesa though. -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Sun Oct 17 23:49: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 DC3F51065695; Sun, 17 Oct 2010 23:49:46 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 737478FC16; Sun, 17 Oct 2010 23:49:46 +0000 (UTC) Received: by vws1 with SMTP id 1so188348vws.13 for ; Sun, 17 Oct 2010 16:49:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.135 with SMTP id by7mr516274vcb.199.1287359385746; Sun, 17 Oct 2010 16:49:45 -0700 (PDT) Received: by 10.220.188.3 with HTTP; Sun, 17 Oct 2010 16:49:45 -0700 (PDT) X-Originating-IP: [128.95.133.82] In-Reply-To: <4CBB8459.1090507@netscape.ca> References: <4CBB7EE6.3040102@FreeBSD.org> <4CBB8459.1090507@netscape.ca> Date: Sun, 17 Oct 2010 16:49:45 -0700 Message-ID: From: Rob Farmer To: Ralph Ellis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexey Dokuchaev , Doug Barton , freebsd-current@freebsd.org Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 17 Oct 2010 23:49:46 -0000 On Sun, Oct 17, 2010 at 16:18, Ralph Ellis wrote: > I am currently running the Nvidia =A0195 driver on amd64 9 - current from= the > ports tree. It works without problems. > When I tried to compile the 256 driver, it would not compile and said tha= t > it was not meant to work with 9 - current. Some necessary support was removed recently, but it has be re-added. See r213739. --=20 Rob Farmer From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 00:06: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 7695A106566B for ; Mon, 18 Oct 2010 00:06:14 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id 0FDD98FC0C for ; Mon, 18 Oct 2010 00:06:13 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id o9HNcVHj003089 for ; Mon, 18 Oct 2010 10:38:31 +1100 Message-ID: <4CBB88F6.1070707@swin.edu.au> Date: Mon, 18 Oct 2010 10:38:30 +1100 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.12) Gecko/20100920 Thunderbird/3.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CBB7EE6.3040102@FreeBSD.org> <4CBB8459.1090507@netscape.ca> In-Reply-To: <4CBB8459.1090507@netscape.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 18 Oct 2010 00:06:14 -0000 On 18/10/2010 10:18, Ralph Ellis wrote: > Doug Barton wrote: >> Y'all will probably recall that I had a lot of problems with the >> nvidia-driver, and video generally (esp. flash) on i386 -current. Well >> I haven't had any problems recently because I haven't been using >> FreeBSD. :) But I have things I need to catch up on, so here's what I >> did: >> >> 1. Bought a new hard drive, and installed a snapshot of amd64 -current >> (this was actually done a while ago). >> 2. Yesterday I started configuring stuff, updated my source and ports >> trees, rebuilt the world, customized the kernel, etc. >> 3. With a newly up to date system I built the latest version of the >> nvidia-driver port, and started using it. >> >> My experience with it has been exactly the same as older versions of >> the port on previous versions of i386 -current. Sometimes it runs fine >> for a while, but whe n I exit the window manager (openbox) the system >> hangs and I never get back to the command prompt. (I'm using startx to >> try and minimize the number of variables.) Sometimes it will work fine >> for an hour, maybe two, then the whole thing just hangs. All the stuff >> is displayed on the screen, but the mouse won't move, I can't zap X, >> or even switch to the console. I have to power off. This is >> particularly frustrating because I haven't even loaded flash (or for >> that matter firefox) yet. >> >> Windows and linux (ubuntu, with the nvidia driver) work great on this >> same hardware, so I'm pretty thoroughly convinced that the problem is >> with freebsd/current somewhere. In addition to the -current partition >> I also installed amd64 8.1-RELEASE so I'll give that a go next, but I >> wanted to ask here first if anyone else was having problems on -current. >> >> >> Doug >> > I am currently running the Nvidia 195 driver on amd64 9 - current from > the ports tree. It works without problems. > When I tried to compile the 256 driver, it would not compile and said > that it was not meant to work with 9 - current. > Hope this helps. > Ralph Ellis > ralphellis1@netscape.ca > > I have not had any trouble with the new Nvidia drivers at all - but I'm running i386, so it might be an amd64 issue. No compilation issues at all, no problems running, switching to VT etc. (and yes, I had the same problems as Doug a while ago) Kernel and world are not from today, but fairly recent though: FreeBSD 9.0-CURRENT #48 r213491M: Thu Oct 7 See: (--) PCI:*(0:1:0:0) 10de:06e4:1458:349c nVidia Corporation G98 [GeForce 8400 GS] rev 161, Mem @ 0xf2000000/16777216, 0xe0000000/268435456, 0xf0000000/33554432, I/O @ 0x00002100/128, BIOS @ 0x????????/65536 (II) "extmod" will be loaded by default. (II) "dbe" will be loaded by default. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded by default. (II) "dri" will be loaded by default. (II) "dri2" will be loaded by default. (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 256.53 Fri Aug 27 20:49:59 PDT 2010 (II) Loading extension GLX (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "nvidia" (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so (II) Module nvidia: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Video Driver (II) NVIDIA dlloader X Driver 256.53 Fri Aug 27 20:29:54 PDT 2010 (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs (II) Primary Device is: PCI 01@00:00:0 Mat From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 01:16: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 C705A1065670 for ; Mon, 18 Oct 2010 01:16:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 50A6A8FC0C for ; Mon, 18 Oct 2010 01:16:41 +0000 (UTC) Received: (qmail 16433 invoked by uid 399); 18 Oct 2010 01:16:41 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Oct 2010 01:16:41 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CBB9FF6.1000106@FreeBSD.org> Date: Sun, 17 Oct 2010 18:16:38 -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: Rob Farmer References: <4CBB7EE6.3040102@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: Alexey Dokuchaev , freebsd-current@freebsd.org Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 18 Oct 2010 01:16:42 -0000 On 10/17/2010 4:49 PM, Rob Farmer wrote: > I am running 256.53 on amd64 current (r213747). I don't use anything > linux (the module isn't loaded) and built the driver with all options > off except ACPI_PM. My custom kernel does not have "device agp". Hmm. I had all the options off except linux. I'll try with your combination and see if that improves things. Thanks, Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 01:32: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 2AB6F1065670 for ; Mon, 18 Oct 2010 01:32:16 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C66D18FC15 for ; Mon, 18 Oct 2010 01:32:15 +0000 (UTC) Received: by ywh2 with SMTP id 2so124719ywh.13 for ; Sun, 17 Oct 2010 18:32: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 :content-transfer-encoding; bh=Fo49pKnM7P/p0Jl9AP30lom0Cdib/4z79jfVQ8ExvY0=; b=Ag3QWBxmsQNQ9kFvE9CGSV1be3zEs6jJYL0lcGUx6RFEs7M3bLgbror0zdwMgmurQU g1A56Il4c9kfwRLHOgIJGHJtIoyvHwetPth40zQ+A+Js6Mgik/OLSCPwx+HbDkvJOhle TA6v0WkHKIoIHekG0BP+MRg42BqteJOHCdGuQ= 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=bPhomCIHkrVnceWscQCGEv4P6sdnKLKFdszloBUByUAcx6nsIJxvwNLEZ97Q5jAmSb rUin0aDTUsD9hhdEbFAEbGnHCn8uVE/qBI1UZkHWhU+OCJPkNoG7QGUxq9uqZQ/tUVaJ 9pPmSn+437IUpBbjlU/reksZCcLdAzF/kbc/k= MIME-Version: 1.0 Received: by 10.42.220.72 with SMTP id hx8mr400776icb.63.1287365533746; Sun, 17 Oct 2010 18:32:13 -0700 (PDT) Received: by 10.231.31.195 with HTTP; Sun, 17 Oct 2010 18:32:13 -0700 (PDT) In-Reply-To: <201010171807.o9HI7b6g073145@pozo.com> References: <201010171807.o9HI7b6g073145@pozo.com> Date: Mon, 18 Oct 2010 09:32:13 +0800 Message-ID: From: Buganini To: Manfred Antar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: marius@freebsd.org, freebsd-current@freebsd.org Subject: Re: bge0 does not work anymore 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, 18 Oct 2010 01:32:16 -0000 my last known usable kernel revision is r213813 with r213920, leds are extinguished when executing dhclient On Mon, Oct 18, 2010 at 2:07 AM, Manfred Antar wrote: > At 09:06 AM 10/17/2010, Rainer Hurling wrote: >>I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With toda= ys kernel the driver 'bge0' does not work anymore. With kernel from October= 9th it does. >> >>The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev= . 0x00a002; CHIP ID 0x0000a0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. >> >>The entry in /etc/rc.conf is 'ifconfig_bge0=3D"DHCP". >> >>Does anyone else observe this behaviour? Is there something I can try? >> >>Thanks in advance, >>Rainer Hurling > > Same here, the last time it worked was Oct 14. with Current source. > uname -a : > FreeBSD pozo.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Oct 14 14:13:47 = PDT 2010 =C2=A0 =C2=A0 root@pozo.com:/sys/i386/compile/COMPAQ =C2=A0i386 > i have ifconfig_bge0=3D"inet 192.168.0.5 netmask 255.255.255.0" in rc.con= f > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > || =C2=A0 =C2=A0 =C2=A0null@pozo.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= | > || =C2=A0 =C2=A0 =C2=A0Ph. (415) 681-6235 =C2=A0 =C2=A0 =C2=A0|| > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > 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 Oct 18 01:56:14 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 604C51065670; Mon, 18 Oct 2010 01:56:14 +0000 (UTC) Date: Mon, 18 Oct 2010 01:56:14 +0000 From: Alexey Dokuchaev To: Alexander Best Message-ID: <20101018015614.GB83761@FreeBSD.org> References: <4CBB7EE6.3040102@FreeBSD.org> <4CBB8459.1090507@netscape.ca> <20101017233200.GA69700@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20101017233200.GA69700@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org, Ralph Ellis , Doug Barton Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 18 Oct 2010 01:56:14 -0000 On Sun, Oct 17, 2010 at 11:32:00PM +0000, Alexander Best wrote: > i'm running 256.52 on HEAD (amd64) without any issues. the 260.X drivers all > freze my computer when i exit X. > > it's quite easy to work around the isse that the nvidia drivers fail to compile > on HEAD. simply change the line #if __FreeBSD_version >= 900000 in > src/nv-freebsd.h to #if __FreeBSD_version >= 1000000. Or install from ports, which also patch the driver to support -CURRENT. ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 23:12: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 C0ED5106566B for ; Tue, 12 Oct 2010 23:12:24 +0000 (UTC) (envelope-from leccine@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 832448FC08 for ; Tue, 12 Oct 2010 23:12:24 +0000 (UTC) Received: by iwn8 with SMTP id 8so6905054iwn.13 for ; Tue, 12 Oct 2010 16:12:23 -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=JyMVouIIvng06t34Bm3jhqkhOP//hHAngtSAgFrOVdc=; b=AopJvJSMn6eumwdFVGyguSavoFnpnnXisqJSjyUAXIrEsysBK49cWONnsxh1rfBt7W rQTyPQ4DJKyhfvTjvxPPMyo0RZN0TJwKIWWYIyl6Q5eWmTKYRlhJ2z44DN6k5ZPF2su7 RFKRXvV4pznpA5vZueWdE6FJmZV3DJKzfY7+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=seuu2ep2ClZFvKFkMw0ZeU6gpEtiZXEd7dMjhhk0PDo3N6uZo+OmxPKMrap/g+qyKQ USohroKPyZoad8fFlUIXDFHeYtIyIGzr/cbHs0Gv/lhD0tvYABfz/XHnc3pkqxHs8QIL GGv9AsCDeB/iYLE8izRk5LtwXQEk5gtdaXZEM= MIME-Version: 1.0 Received: by 10.42.163.70 with SMTP id b6mr402014icy.338.1286923254908; Tue, 12 Oct 2010 15:40:54 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Tue, 12 Oct 2010 15:40:54 -0700 (PDT) Date: Tue, 12 Oct 2010 23:40:54 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: freebsd-current X-Mailman-Approved-At: Mon, 18 Oct 2010 02:43:51 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 12 Oct 2010 23:12:24 -0000 Hey, I am not 100% sure this is the right list to approach with this problem but let's try this one. So I am trying to use dtrace on the previously mentioned system, I followed the usual kernel rebuild process using the following wiki: http://wiki.freebsd.org/DTrace Dtrace works fine and I am able to trace the kernel.[1] My problem is: I can't trace any user land application including PostgreSQL and Ruby. I added the following lines to the /etc/make.conf as it is written in the wiki: STRIP= CFLAGS+=-fno-omit-frame-pointer I compiled both of the softwares and trying to trace them but there are no bindings in the dtrace -l ouput # dtrace -l | grep -i ruby i might have overlooked something important but not sure what. Any help is appreciated. Pls cc my email since i am not on this list. Thank you in advance. I. 1. [root@freebsd9 ~]# uname -a FreeBSD freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Oct 8 21:09:20 UTC 2010 root@freebsd9:/usr/obj/usr/src/sys/DTRACE amd64 [root@freebsd9 ~]# kldstat Id Refs Address Size Name 1 26 0xffffffff80100000 f49bb0 kernel 2 1 0xffffffff81212000 ad8 dtraceall.ko 3 1 0xffffffff81213000 4a59 profile.ko 4 11 0xffffffff81218000 3e2f opensolaris.ko 5 3 0xffffffff8121c000 3db0 cyclic.ko 6 9 0xffffffff81220000 13af4b dtrace.ko 7 1 0xffffffff8135b000 fce0 systrace.ko 8 1 0xffffffff8136b000 4128 sdt.ko 9 1 0xffffffff81370000 44b8 lockstat.ko 10 1 0xffffffff81375000 b94e fasttrap.ko 11 1 0xffffffff81381000 61ab fbt.ko 12 1 0xffffffff81388000 4a67 dtnfsclient.ko 13 1 0xffffffff8138d000 4118 dtmalloc.ko [root@freebsd9 ~]# [root@freebsd9 ~]# cat d.d vfs:namecache:enter:done { @distribution = quantize(strlen((string)arg1)); } [root@freebsd9 ~]# dtrace -s d.d dtrace: script 'd.d' matched 1 probe ^C value ------------- Distribution ------------- count 2 | 0 4 |@@@@@@@ 1 8 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5 16 | 0 -- the sun shines for all http://blog.l1x.me From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 06:21: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 EA43B106566B for ; Thu, 14 Oct 2010 06:21:22 +0000 (UTC) (envelope-from darrenr@fastmail.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id BD0308FC13 for ; Thu, 14 Oct 2010 06:21:22 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id BDC162F8 for ; Thu, 14 Oct 2010 02:02:00 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 14 Oct 2010 02:02:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:content-type:content-transfer-encoding; s=smtpout; bh=hbil60kEbfc+n+ArEq8GG05sJOo=; b=sQ0Mg2iALehmfHu1lqT/nDGb1DLhdY5Z4YUCLJvj9OWEjH5eTWkst4E9OAzsWi5nMovpZz/ixbgoYb2cDdU1xkY5F7E8w1ewoJ3RququE6gh3PyggEMf9VQk3eTq2+829Ly41ARBAHqHIGlqdFe+JFI3uR99YHNJF6VeFTioae8= X-Sasl-enc: Suk+6UZXp4giK1j3youyxNb+1JLlkb0J0S9fktgTpwKr 1287036120 Received: from [192.168.1.234] (76-191-213-211.dsl.dynamic.sonic.net [76.191.213.211]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2E9BA4018F5 for ; Thu, 14 Oct 2010 02:02:00 -0400 (EDT) Message-ID: <4CB639DB.3090907@fastmail.net> Date: Wed, 13 Oct 2010 22:59:39 +0000 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Oct 2010 02:49:25 +0000 Subject: 2TB HDD = TIMEOUT - READ_DMA48 .... 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, 14 Oct 2010 06:21:23 -0000 As another body that today bought a 2TB HDD, I can confirm the presence of kernel messages relating to READ_DMA48 with FreeBSD 8. The drive in question is a Hitachi one, not a Samsung. Is it the drive, system or operating system? Well, the drive works without any such error with both Windows 7 and NetBSD 5.1. So it looks like the finger is now pointing as a bug in FreeBSD... and if it is fixed in HEAD then it needs to be merged into the branch for 8.1. Darren From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 03:55: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 743061065696; Sat, 16 Oct 2010 03:55:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 749BB8FC15; Sat, 16 Oct 2010 03:55:15 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9G1X1nn025708; Sat, 16 Oct 2010 12:33:01 +1100 Received: from c122-106-146-165.carlnfd1.nsw.optusnet.com.au (c122-106-146-165.carlnfd1.nsw.optusnet.com.au [122.106.146.165]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9G1Wt8u026565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Oct 2010 12:32:56 +1100 Date: Sat, 16 Oct 2010 12:32:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Robert N. M. Watson" In-Reply-To: <93AB0F13-5995-4AAD-BEFC-A6F1317E3CA6@freebsd.org> Message-ID: <20101016114647.E63520@besplex.bde.org> References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> <93AB0F13-5995-4AAD-BEFC-A6F1317E3CA6@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 18 Oct 2010 02:49:44 +0000 Cc: FreeBSD Current , freebsd-net@freebsd.org, Garrett Cooper , Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , 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: Sat, 16 Oct 2010 03:55:16 -0000 On Fri, 15 Oct 2010, Robert N. M. Watson wrote: > On 15 Oct 2010, at 20:39, Garrett Cooper wrote: > >> But there are already some cases that aren't properly handled >> today in the ddb area dealing with dumping that aren't handled >> properly. Take for instance the following two scenarios: >> 1. Call doadump twice from the debugger. >> 2. Call doadump, exit the debugger, reenter the debugger, and call >> doadump again. >> Both of these scenarios hang reliably for me. >> I'm not saying that we should regress things further, but I'm just >> noting that there are most likely a chunk of edgecases that aren't >> being handled properly when doing dumps that could be handled better / >> fixed. Even thinking about calling doadump even once from within the debugger is an error. I was asleep when the similar error for panic was committed, and this error has propagated. Debuggers should use a trampoline to call the "any" function, not the least so that they can be used to debug the "any" function without the extra complications to make themself reentrant. I think gdb has always used a trampoline for this outside of the kernel. Not sure what it does within the kernel, but it would have even larger problems than in userland finding a place for the trampoline. In the kernel, there is the additional problem of keeping control while the "any" function is run. Other CPUs must be kept stopped and interrupts must be kept masked, except when the "any" function really needs other CPUs or unmasked interrupts. Single stepping also needs this and doesn't have it (other CPUs and interrupt handlers can run and execute any number of instructions while you are trying to execute a single one). All ddb "commands" that change the system state are really non-ddb commands that should use an external function via a trampoline. Panicing and dumping are just the largest ones, so they are the most impossible to do correctly as commands and the most in need of ddb to debug them. > Right: one of the points I've made to Attilio is that we need to move to a more principled model as to what sorts of things we allow in various kernel environments. The early boot is a special environment -- so is the debugger, but the debugger on panic is not the same as the debugger when you can continue. Likewise, the crash dumping code is special, but also not the same as the debugger. Right now, exceptional behaviour to limit hangs/etc is done inconsistently. We need to develop a set of principles that tell us what is permitted in what contexts, and then use that to drive design decisions, normalizing what's there already. ENONUNIXEDITOR. Format not recovered. panic() from within a debugger (or a fast interrupt handler, or a fast interrupt handler that has trappeded to the debugger by request...) is, although an error, not too bad since panic() must be prepared to work starting from the "any" state anyway, and as you mention it doesn'tneed to be able to return (except for RESTARTABLE_PANICS, which makes things impossibly difficult). Continuing from a debugger is feasible mainly because in the usual case the system state is not changed (except for time-dependent things). If you use it to modify memory or i/o or run one of its unsafe commands then you have to be careful. > This is not dissimilar to what we do with locking already, BTW: we define a set of kernel environments (fast interrupt handlers, non-sleepable threads, sleepable thread holding non-sleepable locks, etc), and based on those principles prevent significant sources of instability that might otherwise arise in a complex, concurrent kernel. We need to apply the same sort of approach to handling kernel debugging and crashing. Locking has imposed considerable discipline, which if followed by panic() would should how wrong most of the things done by panic() are -- it will hit locks, but shouldn't even be calling functions that have locks, since such functions expect their locks to work. The rules for fast interrupt handlers are simple and mostly not followed. They are that a fast interrupt handler may not access any state not specially locked by its subsystem. This means that they may not call any other subsystem or any upper layer except the null set of ones documented to be safe to call. In practice, this means not calling the "any" function, but it is necessary for atomic ops, bus space accesses, and a couple of scheduling functions to be safe enough. > BTW, my view is that except in very exceptional cases, it should not be possible to continue after generating a dump. Dumps often cause disk controllers to get reset, which may leave outstanding I/O in nasty situations. Unless the dump device and model is known not to interfere with operation, we should set state indicating that the system is non-continuable once a dump has occurred. It might be safe if the system reinitialized everything. Too hard for just dumping, but it is needed after resume anyway. So the following could reasonably work: - stop system while its state is believed to be good - dump - restart/resume. The order for this is unclear. Normal resume might want the system to have not stopped as much as it needed to for dumping. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 04:26:37 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 6B92010657BB for ; Mon, 18 Oct 2010 04:26:37 +0000 (UTC) (envelope-from delphij@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 3289A8FC22 for ; Mon, 18 Oct 2010 04:26:36 +0000 (UTC) Received: by iwn41 with SMTP id 41so699904iwn.13 for ; Sun, 17 Oct 2010 21:26:36 -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=Uc5dBPSHxkS4pZmC+vfXqABKpxQ7pONS8SZDSCdQxuw=; b=Sq/sGn9sw9fGapmnlKLmX0GHmEO1mpANJPpNVbX8nLOB4G8ggspOGjfwfrEUP1+rkV Y+7DhYKi+tAaCIFhMHpKcTIYxfgidY4nVj/SgM9Bix+7GgLu27quZDVwPwuKScwvn50V /gHccn/g7arBJavt8OegkhIMT0sWVj2uG5ooM= 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=K8xeNdkTiyIH1IFSt3krQfwrdImKrO5LqBsrKOiSRrrsQtNB6eN21QzKGw8AEZAHVD llVVeBZeiYP589vqO3URz0Lw5tvABH/PO19GY6iByauaFskHAgJDavGTVJf+TXVKO4Yc uyXRsoP0E2wuIGsidJv5I4RSHDJ+ygnk3r/vs= MIME-Version: 1.0 Received: by 10.42.176.198 with SMTP id bf6mr511108icb.415.1287374288938; Sun, 17 Oct 2010 20:58:08 -0700 (PDT) Received: by 10.231.146.10 with HTTP; Sun, 17 Oct 2010 20:58:08 -0700 (PDT) In-Reply-To: <4CB639DB.3090907@fastmail.net> References: <4CB639DB.3090907@fastmail.net> Date: Sun, 17 Oct 2010 20:58:08 -0700 Message-ID: From: Xin LI To: Darren Reed Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: 2TB HDD = TIMEOUT - READ_DMA48 .... 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, 18 Oct 2010 04:26:37 -0000 Hi, On Wed, Oct 13, 2010 at 3:59 PM, Darren Reed wrote: > As another body that today bought a 2TB HDD, I can confirm the presence > of kernel messages relating to READ_DMA48 with FreeBSD 8. > The drive in question is a Hitachi one, not a Samsung. > > Is it the drive, system or operating system? > > Well, the drive works without any such error with both Windows 7 and NetBSD > 5.1. > > So it looks like the finger is now pointing as a bug in FreeBSD... and if it > is fixed in HEAD then it needs to be merged into the branch for 8.1. Have you tried the new ahci(4) driver? What controller are you using by the way? Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 05:35: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 468011065695 for ; Mon, 18 Oct 2010 05:35:25 +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 752F98FC1D for ; Mon, 18 Oct 2010 05:35:23 +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 IAA08218; Mon, 18 Oct 2010 08:35:17 +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 1P7iNQ-000MWT-Nw; Mon, 18 Oct 2010 08:35:16 +0300 Message-ID: <4CBBDC93.6070607@icyb.net.ua> Date: Mon, 18 Oct 2010 08:35: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: Darren Reed References: <4CB639DB.3090907@fastmail.net> In-Reply-To: <4CB639DB.3090907@fastmail.net> 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: 2TB HDD = TIMEOUT - READ_DMA48 .... 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, 18 Oct 2010 05:35:25 -0000 on 14/10/2010 01:59 Darren Reed said the following: > As another body that today bought a 2TB HDD, I can confirm the presence > of kernel messages relating to READ_DMA48 with FreeBSD 8. Sounds like sector number possibly overflowing 32-bit integer. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 06:28: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 5AB171065694 for ; Mon, 18 Oct 2010 06:28:45 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by mx1.freebsd.org (Postfix) with ESMTP id E91DB8FC1D for ; Mon, 18 Oct 2010 06:28:44 +0000 (UTC) Received: from wmail26 (172.31.0.37) by cp-out4.libero.it (8.5.107) (authenticated as barbara.xxx1975@libero.it) id 4CB93C2D00122F88 for freebsd-current@freebsd.org; Mon, 18 Oct 2010 08:28:43 +0200 Message-ID: <18610943.214991287383323337.JavaMail.defaultUser@defaultHost> Date: Mon, 18 Oct 2010 08:28:43 +0200 (CEST) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 87.16.238.75 Subject: LOR kern_sig.c + vm_kern.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 06:28:45 -0000 $ uname -a FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09: 10:51 CEST 2010 root@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO i386 lock order reversal: 1st 0xc6befdd0 process lock (process lock) @ /usr/src/sys/kern/kern_sig.c:3341 2nd 0xc19b60e4 system map (system map) @ /usr/src/sys/vm/vm_kern.c:315 KDB: stack backtrace: db_trace_self_wrapper(c0914c5e,762f7379,6d762f6d,72656b5f,3a632e6e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c065397b,c0917db7,c591d340,c591e110,e83d1764,...) at kdb_backtrace+0x2a _witness_debugger(c0917db7,c19b60e4,c0936364,c591e110,c09366a4,...) at _witness_debugger+0x26 witness_checkorder(c19b60e4,9,c09366a4,13b,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c19b60e4,0,c09366a4,13b,c1995e80,...) at _mtx_lock_flags+0xc4 _vm_map_lock(c19b6088,c09366a4,13b,c09359b5,c6725b40,...) at _vm_map_lock+0x31 kmem_malloc(c19b6088,1000,101,e83d1834,c083e233,...) at kmem_malloc+0x3a page_alloc(c5de4a80,1000,e83d1827,101,c5de4a80,...) at page_alloc+0x27 keg_alloc_slab(c1995e88,4,c09359b5,83b,e83d1874,...) at keg_alloc_slab+0xe3 keg_fetch_slab(101,8,c5e1ef24,e83d18d4,c084008d,...) at keg_fetch_slab+0x17e zone_fetch_slab(c5de4a80,c1995e80,101,7f1,c0663577,...) at zone_fetch_slab+0x4c uma_zalloc_arg(c5de4a80,0,101,e83d1918,c061d135,...) at uma_zalloc_arg+0x5dd ksiginfo_alloc(0,e83d1918,e83d1970,17,c6befd48,...) at ksiginfo_alloc+0x37 sigqueue_add(c6d14aa8,0,c09116ff,81f,2,...) at sigqueue_add+0x175 tdsendsignal(c6befd48,c6bf6000,17,e83d1970,0,...) at tdsendsignal+0x3ce psignal(c6befd48,17,c09116ff,d0d,c5922140,...) at psignal+0x47 pgsigio(c5a7c0e0,17,0,c5a7c000,e83d1a98,...) at pgsigio+0xf1 tty_wakeup(c5a7c000,1,c091a9ec,447,3,...) at tty_wakeup+0x44 ttydisc_rint_done(c5a7c000,7f,0,c0,0,...) at ttydisc_rint_done+0xa4 sysmouse_event(c67064c0,14,2,0,2,...) at sysmouse_event+0x210 sc_mouse_ioctl(c5a7bc00,c014630a,c67064c0,c6725b40,c090ac47,...) at sc_mouse_ioctl+0x2a6 sctty_ioctl(c5a7bc00,c014630a,c67064c0,c6725b40,e83d1bb4,...) at sctty_ioctl+0xa4 consolectl_ioctl(c5c97b00,c014630a,c67064c0,3,c6725b40,...) at consolectl_ioctl+0x29 giant_ioctl(c5c97b00,c014630a,c67064c0,3,c6725b40,...) at giant_ioctl+0x75 devfs_ioctl_f(c67ef000,c014630a,c67064c0,c595a300,c6725b40,...) at devfs_ioctl_f+0x10b kern_ioctl(c6725b40,4,c014630a,c67064c0,13d1cec,...) at kern_ioctl+0x20d ioctl(c6725b40,e83d1cec,e83d1d28,e83d1d80,0,...) at ioctl+0x12f syscallenter(c6725b40,e83d1ce4,e83d1d1c,c089cc06,74a,...) at syscallenter+0x263 syscall(e83d1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281b179b, esp = 0xbfbfe98c, ebp = 0xbfbfeb18 --- From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 06:35: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 EA75D1065672 for ; Mon, 18 Oct 2010 06:35:06 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7FB998FC0C for ; Mon, 18 Oct 2010 06:35:06 +0000 (UTC) Received: from wmail26 (172.31.0.37) by cp-out2.libero.it (8.5.107) (authenticated as barbara.xxx1975@libero.it) id 4CB82AA9001FD79F for freebsd-current@freebsd.org; Mon, 18 Oct 2010 08:35:04 +0200 Message-ID: <4675060.215851287383704887.JavaMail.defaultUser@defaultHost> Date: Mon, 18 Oct 2010 08:35:04 +0200 (CEST) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 87.16.238.75 Subject: LOR vfs_lookup.c + ffs_softdep.c + vfs_subr.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 06:35:07 -0000 $ uname -a FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09: 10:51 CEST 2010 root@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO i386 lock order reversal: 1st 0xc68ec278 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:501 2nd 0xd995fc70 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11310 3rd 0xc6993278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2111 KDB: stack backtrace: db_trace_self_wrapper(c0914c5e,632e7262,3131323a,a0d31,70656474,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c065397b,c0917dd0,c5921168,c5924b80,e837b320,...) at kdb_backtrace+0x2a _witness_debugger(c0917dd0,c6993278,c0909713,c5924b80,c091f023,...) at _witness_debugger+0x26 witness_checkorder(c6993278,9,c091f023,83f,0,...) at witness_checkorder+0x839 __lockmgr_args(c6993278,80100,c6993298,0,0,...) at __lockmgr_args+0x816 ffs_lock(e837b448,c066428b,c091e452,80100,80100,...) at ffs_lock+0x82 VOP_LOCK1_APV(c0991580,e837b448,c67de91c,c09a9c80,c6993220,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c6993220,80100,c091f023,83f,4,...) at _vn_lock+0x5e vget(c6993220,80100,c67de870,50,0,...) at vget+0xb9 vfs_hash_get(c67a4798,2e00b,80000,c67de870,e837b59c,...) at vfs_hash_get+0xe6 ffs_vgetf(c67a4798,2e00b,80000,e837b59c,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c68ec220,0,c093400a,144,0,...) at softdep_sync_metadata+0xc92 ffs_syncvnode(c68ec220,1,c67de870,e837b65c,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c68ec220,200,0,880,c595a300,...) at ffs_truncate+0x87b ufs_direnter(c68ec220,c6993220,e837b914,e837bba4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(e837bba4,0,e837bb00,e837ba5c,c08b7b25,...) at ufs_makeinode+0x557 ufs_create(e837bb00,e837bb18,0,0,e837bb78,...) at ufs_create+0x30 VOP_CREATE_APV(c0991580,e837bb00,e837bba4,e837ba98,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e837bb78,e837bc2c,1a4,0,c595a300,...) at vn_open_cred+0x220 vn_open(e837bb78,e837bc2c,1a4,c67f0508,0,...) at vn_open+0x3b kern_openat(c67de870,ffffff9c,804c608,0,602,...) at kern_openat+0x128 kern_open(c67de870,804c608,0,601,21b6,...) at kern_open+0x35 open(c67de870,e837bcec,e837bd28,c09166de,0,...) at open+0x30 syscallenter(c67de870,e837bce4,e837bce4,0,c09c3210,...) at syscallenter+0x263 syscall(e837bd28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817485b, esp = 0xbfbfec0c, ebp = 0xbfbfec78 --- From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 06:39: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 985AB106566C; Mon, 18 Oct 2010 06:39:03 +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 39F398FC1C; Mon, 18 Oct 2010 06:39:02 +0000 (UTC) Received: by iwn41 with SMTP id 41so819671iwn.13 for ; Sun, 17 Oct 2010 23:39: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 :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=SpJX1NynKLXPFz6Zl9ftHP6s8iBkbUXWILvUiREQG5g=; b=JwsJeYwgNA4AKyYqJoGq87MmSyq7q7jNKELEeDUwkURYBLgiOCu+/R5xGMF6b9YsDT CETowrjt+wpa7YXubQogn3S7WXE1GA8zqCdTtxixO+h1bWt6bUw4EPfBR0twe2ou3TtX fgkPPvp0cRUO+crc28VBf8hReYn1sadspx+GU= 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=TwHutBMvXRB5H3bzabzj73Q2udKVqQQxDbwYS6Yct7Elw/awqYn2M+Uuo+vF+i1qSf CuGdPuQrS2QVP5THppwRJ0RGbtraD1pO69j5LQgTy8hUHVBEa5aj5wKrCoby60gSDPhB NsjnmnBJvd5Kl4kT/zNosq7XlrSHHSrxYs3jI= MIME-Version: 1.0 Received: by 10.42.175.135 with SMTP id ba7mr2515465icb.420.1287383942366; Sun, 17 Oct 2010 23:39:02 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Sun, 17 Oct 2010 23:39:02 -0700 (PDT) In-Reply-To: <4CBB9FF6.1000106@FreeBSD.org> References: <4CBB7EE6.3040102@FreeBSD.org> <4CBB9FF6.1000106@FreeBSD.org> Date: Sun, 17 Oct 2010 23:39:02 -0700 X-Google-Sender-Auth: S5XQI73L5lq43fh6yIsy0UONjrA Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexey Dokuchaev , Rob Farmer , freebsd-current@freebsd.org Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 18 Oct 2010 06:39:03 -0000 On Sun, Oct 17, 2010 at 6:16 PM, Doug Barton wrote: > On 10/17/2010 4:49 PM, Rob Farmer wrote: >> >> I am running 256.53 on amd64 current (r213747). I don't use anything >> linux (the module isn't loaded) and built the driver with all options >> off except ACPI_PM. My custom kernel does not have "device agp". > > Hmm. I had all the options off except linux. I'll try with your combination > and see if that improves things. I've given up on linux emulation support since 256.3x as it was the factor that was causing lockups on my two machines. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 06:40: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 3B3651065672; Mon, 18 Oct 2010 06:40:35 +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 ED39F8FC26; Mon, 18 Oct 2010 06:40:33 +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 JAA09108; Mon, 18 Oct 2010 09:40:32 +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 1P7jOa-000MbQ-2A; Mon, 18 Oct 2010 09:40:32 +0300 Message-ID: <4CBBEBDF.3060905@freebsd.org> Date: Mon, 18 Oct 2010 09:40:31 +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: Jeff Roberson , freebsd-current@freebsd.org References: <4C9B9B9C.6000807@freebsd.org> In-Reply-To: <4C9B9B9C.6000807@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic in uma_startup for many-core amd64 system 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, 18 Oct 2010 06:40:35 -0000 on 23/09/2010 21:25 Andriy Gapon said the following: > > Jeff, > > just for the kicks I tried to emulate a machine with 64 logical CPUs using > qemu-devel port: > qemu-system-x86_64 -smp sockets=4,cores=8,threads=2 ... > > It seems that FreeBSD agreed to recognize only first 32 CPUs, but it paniced anyway. > > Here's a backtrace: > #34 0xffffffff804fe7f5 in zone_alloc_item (zone=0xffffffff80be1554, > udata=0xffffffff80be1550, flags=1924) at /usr/src/sys/vm/uma_core.c:2506 > #35 0xffffffff804ff35d in hash_alloc (hash=0xffffff001ffdb030) at > /usr/src/sys/vm/uma_core.c:483 > #36 0xffffffff804ff642 in keg_ctor (mem=Variable "mem" is not available. > ) at /usr/src/sys/vm/uma_core.c:1396 > #37 0xffffffff804fe91b in zone_alloc_item (zone=0xffffffff80a1f300, > udata=0xffffffff80be1b60, flags=2) at /usr/src/sys/vm/uma_core.c:2544 > #38 0xffffffff804ff92e in zone_ctor (mem=Variable "mem" is not available. > ) at /usr/src/sys/vm/uma_core.c:1832 > #39 0xffffffff804ffca4 in uma_startup (bootmem=0xffffff001ffac000, boot_pages=48) > at /usr/src/sys/vm/uma_core.c:1741 > #40 0xffffffff80514822 in vm_page_startup (vaddr=18446744071576817664) at > /usr/src/sys/vm/vm_page.c:360 > #41 0xffffffff805060c5 in vm_mem_init (dummy=Variable "dummy" is not available. > ) at /usr/src/sys/vm/vm_init.c:118 > #42 0xffffffff803258b9 in mi_startup () at /usr/src/sys/kern/init_main.c:253 > #43 0xffffffff8017177c in btext () at /usr/src/sys/amd64/amd64/locore.S:81 > [[[ > Note: > 1. Frame numbers are high because the backtrace is obtained via gdb remotely > connected to qemu and also there is bunch of extra frames from DDB, etc. > 2. Line numbers in uma_core. won't match those in FreeBSD tree, because I've doing > some unrelated hacking in the file. > ]]] > > The problem seems to be with creation of "UMA Zones" zone and keg. > Because of the large number of processors, size argument in the following snippet > is set to a value of 4480: > > args.name = "UMA Zones"; > args.size = sizeof(struct uma_zone) + > (sizeof(struct uma_cache) * (mp_maxid + 1)); > > Because of this, keg_ctor() calls keg_large_init(): > > else if ((keg->uk_size+UMA_FRITM_SZ) > > (UMA_SLAB_SIZE - sizeof(struct uma_slab))) > keg_large_init(keg); > else > keg_small_init(keg); > > keg_large_init sets UMA_ZONE_OFFPAGE and UMA_ZONE_HASH flags for this keg. > This leads to hash_alloc() being invoked from keg_ctor(): > > if (keg->uk_flags & UMA_ZONE_HASH) > hash_alloc(&keg->uk_hash); > > But the problem is that "UMA Hash" zone is not created yet and thus the call leads > to the panic. "UMA Hash" zone is the last of system zones created. > > Not sure what the proper fix here could/should be. > Would it work to simply not set UMA_ZONE_HASH flag when UMA_ZFLAG_INTERNAL is set? > > > And some final calculations. > On the test system sizeof(struct uma_cache) is 128 bytes and (mp_maxid + 1) is 32, > so it's already UMA_SLAB_SIZE = PAGE_SIZE = 4096. > Here is a simple solution that seems to work: http://people.freebsd.org/~avg/uma-many-cpus.diff Not sure if it's the best we can do. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 06:54: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 64B151065673 for ; Mon, 18 Oct 2010 06:54:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id AD3B48FC1E for ; Mon, 18 Oct 2010 06:54:45 +0000 (UTC) Received: (qmail 20720 invoked by uid 399); 18 Oct 2010 06:54:44 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Oct 2010 06:54:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sun, 17 Oct 2010 23:54:41 -0700 (PDT) From: Doug Barton To: Garrett Cooper In-Reply-To: Message-ID: References: <4CBB7EE6.3040102@FreeBSD.org> <4CBB9FF6.1000106@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexey Dokuchaev , Rob Farmer , freebsd-current@freebsd.org Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 18 Oct 2010 06:54:46 -0000 On Sun, 17 Oct 2010, Garrett Cooper wrote: > On Sun, Oct 17, 2010 at 6:16 PM, Doug Barton wrote: >> On 10/17/2010 4:49 PM, Rob Farmer wrote: >>> >>> I am running 256.53 on amd64 current (r213747). I don't use anything >>> linux (the module isn't loaded) and built the driver with all options >>> off except ACPI_PM. My custom kernel does not have "device agp". >> >> Hmm. I had all the options off except linux. I'll try with your combination >> and see if that improves things. > > I've given up on linux emulation support since 256.3x as it was > the factor that was causing lockups on my two machines. Thanks. I tried again without linux support, no change, it still froze up. I suppose I can try again tomorrow without any of the options selected. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 07:22: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 CE6EA106564A for ; Mon, 18 Oct 2010 07:22:26 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from ffe1.ukr.net (ffe1.ukr.net [195.214.192.43]) by mx1.freebsd.org (Postfix) with ESMTP id 8744B8FC14 for ; Mon, 18 Oct 2010 07:22:26 +0000 (UTC) Received: from mail by ffe1.ukr.net with local ID 1P7k36-0007OW-QD ; Mon, 18 Oct 2010 10:22:24 +0300 Date: Mon, 18 Oct 2010 10:22:24 +0300 Message-Id: MIME-Version: 1.0 In-Reply-To: <4CBB1EF2.3010606@gwdg.de> References: <4CBB1EF2.3010606@gwdg.de> To: "Rainer Hurling" From: "fidaj " X-Mailer: Freemail 0 X-Originating-Ip: [95.132.144.99] X-Browser: Opera/9.80 (X11; FreeBSD 8.0-RELEASE i386; U; ru) Presto/2.2.15 Version/10.10 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: bge0 does not work anymore 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, 18 Oct 2010 07:22:26 -0000 I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays kernel the driver 'bge0' does not work anymore. With kernel from October 9th it does. The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x00a002; CHIP ID 0x0000a0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. The entry in /etc/rc.conf is 'ifconfig_bge0="DHCP". Does anyone else observe this behaviour? Is there something I can try? Thanks in advance, Rainer Hurling Hi! > > I have the same problem. > > I have a good last update r213782M > after upgrading to r213927M - as a result - bge0 is not working ... > bge0@pci0:9:0:0: class=0x020000 card=0x02271028 chip=0x171314e4 rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' device = 'Broadcom NetLink (TM) Fast Ethernet (BCM5906m)' class = network subclass = ethernet > does not change the status of the connection even after the manual input of commands > ifconfig bge0 down > ifconfig bge0 up > > Thanks! > From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 07:43:48 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 03D2C1065694 for ; Mon, 18 Oct 2010 07:43:48 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC4438FC19 for ; Mon, 18 Oct 2010 07:43:47 +0000 (UTC) Received: by gxk4 with SMTP id 4so219127gxk.13 for ; Mon, 18 Oct 2010 00:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=xg1w5O7ztvt+9jq8byjUD9cNY7FAc/lIHkXIzaiGTlM=; b=n8r0SQQeK69kqeqsdGySQadtFqXp2EQye/ctpRlt3DJB626YwrV/YXei2TOaW0O7bH Xdzkw5rB1/O7CUIlfXo4+STfA8pQunJ9zamJzmCssvkAzAOs+viR8SIjEdnAbmkD5o6W fVK4axCemueFnXNTRILBY/Wm3A8AQOBmgooVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=of6WTMNBbYf4qXolSbRE3Z4GSC5OglhshVd7uMVmdO68frfOvvOJjPYV8wil7wbsaQ NeDfqp/BJgkfZdPqyIvBDGm8LAC0KvjEouOD4kN1OZfY/fLreKeFu+o/OtVZlfgdyAPu GRc8EsgOGTrm0A5YkwbpPr3MtFonCNvj58e7k= Received: by 10.236.103.17 with SMTP id e17mr7505457yhg.89.1287387826863; Mon, 18 Oct 2010 00:43:46 -0700 (PDT) Received: from dragon.dg (41-132-93-155.dsl.mweb.co.za [41.132.93.155]) by mx.google.com with ESMTPS id m45sm2596052yha.11.2010.10.18.00.43.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Oct 2010 00:43:46 -0700 (PDT) From: David Naylor To: freebsd-current@freebsd.org Date: Mon, 18 Oct 2010 09:43:28 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.1; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1317096.xfUj6sXRYQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201010180943.37042.naylor.b.david@gmail.com> Subject: geom_sched usage 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, 18 Oct 2010 07:43:48 -0000 --nextPart1317096.xfUj6sXRYQ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've used geom_sched to some success. Normally I do not notice anything bu= t=20 today I was copying big files over a gigabit ethernet and my laptop was not= =20 very responsive. I loaded gsched and the responsiveness improved (although= =20 still rather bad for anything requiring something from the HDD). =20 Thank you for all this work :-) Some questions I have: - with a gmirror should the gsched be attached to the underlying devices (= aka=20 /dev/ad?) or to the mirror device (aka /dev/mirror/?)? - is there anyway to automatically attach gsched to a device on startup (i= =2Ee.=20 in rc.conf)? - is there a way to prioritise random IO (vs sequential reads from big=20 files)? - gsched_as does not appear to be installed. =20 Regards, David --nextPart1317096.xfUj6sXRYQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEABECAAYFAky7+qgACgkQUaaFgP9pFrL59wCfaj2C5mVkmjEO0Auagkk0vJUq iiQAoId1UUgE38k8pLqBwGfLzjEpTNKs =69dE -----END PGP SIGNATURE----- --nextPart1317096.xfUj6sXRYQ-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 08:38:48 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 7222C106566C for ; Mon, 18 Oct 2010 08:38:48 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id E067A8FC1A for ; Mon, 18 Oct 2010 08:38:47 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id o9I8ck5d016783; Mon, 18 Oct 2010 10:38:46 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id o9I8cjRC016782; Mon, 18 Oct 2010 10:38:45 +0200 (CEST) (envelope-from marius) Date: Mon, 18 Oct 2010 10:38:45 +0200 From: Marius Strobl To: Buganini Message-ID: <20101018083845.GK1416@alchemy.franken.de> References: <201010171807.o9HI7b6g073145@pozo.com> 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: freebsd-current@freebsd.org Subject: Re: bge0 does not work anymore 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, 18 Oct 2010 08:38:48 -0000 On Mon, Oct 18, 2010 at 09:32:13AM +0800, Buganini wrote: > my last known usable kernel revision is r213813 > with r213920, leds are extinguished when executing dhclient Sorry, it looks like it was my fault this time, should be fixed again with r214012. Marius From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 10:12: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 4EE3E1065673; Mon, 18 Oct 2010 10:12:45 +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 EA9BB8FC3C; Mon, 18 Oct 2010 10:12:44 +0000 (UTC) Received: by iwn41 with SMTP id 41so1020061iwn.13 for ; Mon, 18 Oct 2010 03:12: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 :content-transfer-encoding; bh=SOkVexXAy4GF22eUoKWLnbozDADwQLCileVrM6GXbqs=; b=AiCSKr8AtKtPgcAXneHFQ8dCiQVyyoCk+lewGYomJJSggvpC1Vt4n/mhYEJYXOAgWk pspSR/FG3f5gZHN7MmjfmGwQqcop2lWXctXBvyW+lm1yD12fmbG9g3mk5D8sZoGWpp2O IRChG+ciWT/tVPZRqQl0MCbxzd/PmZmLaUroc= 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=BQd/sUfAcv86hKbXxwQkq2lcdIbg1L5LWBwiCJV+YMAgGsu0nl+Ql0cJ+O6mg91UNM A1iKUd29knechF2ES0UrzPpsOfy6ZG157rTAQGTg2UQR16UnFAj29ykml08yOeECa7CH JC4fJIF6H0bZXa1HlDOYGWFUxjBxcIONyh8BA= MIME-Version: 1.0 Received: by 10.231.17.200 with SMTP id t8mr2920312iba.165.1287395050618; Mon, 18 Oct 2010 02:44:10 -0700 (PDT) Received: by 10.231.20.9 with HTTP; Mon, 18 Oct 2010 02:44:10 -0700 (PDT) In-Reply-To: References: <4CBB7EE6.3040102@FreeBSD.org> <4CBB9FF6.1000106@FreeBSD.org> Date: Mon, 18 Oct 2010 11:44:10 +0200 Message-ID: From: Daniel Nebdal To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexey Dokuchaev , Rob Farmer , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: Is nvidia-driver 256.53 expected to work on -current? 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, 18 Oct 2010 10:12:45 -0000 On Mon, Oct 18, 2010 at 8:54 AM, Doug Barton wrote: > On Sun, 17 Oct 2010, Garrett Cooper wrote: > >> On Sun, Oct 17, 2010 at 6:16 PM, Doug Barton wrote: >>> >>> On 10/17/2010 4:49 PM, Rob Farmer wrote: >>>> >>>> I am running 256.53 on amd64 current (r213747). I don't use anything >>>> linux (the module isn't loaded) and built the driver with all options >>>> off except ACPI_PM. My custom kernel does not have "device agp". >>> >>> Hmm. I had all the options off except linux. I'll try with your >>> combination >>> and see if that improves things. >> >> =A0 I've given up on linux emulation support since 256.3x as it was >> the factor that was causing lockups on my two machines. > > Thanks. I tried again without linux support, no change, it still froze up= . I > suppose I can try again tomorrow without any of the options selected. > > > Doug > For what it's worth, the newest nvidia driver in ports (256.53) reliably freezes both my 8-STABLE and 9-CURRENT machine dead within minutes (amd64 , KDE4 both with and without compositing, Geforce GT240 cards. The mouse stops moving, no keyboard input does anything, it doesn't answer on the network.) I haven't had time to look at it, so I'm using the nv driver for now. --=20 Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 10:26: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 2DDD2106566B for ; Mon, 18 Oct 2010 10:26:04 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id A5C1C8FC1E for ; Mon, 18 Oct 2010 10:26:04 +0000 (UTC) Received: from 99-144-132-95.pool.ukrtel.net ([95.132.144.99] helo=localhost) by fsm1.ukr.net with esmtps ID 1P7muo-000FiO-Rj ; Mon, 18 Oct 2010 13:26:03 +0300 Date: Mon, 18 Oct 2010 13:25:56 +0300 From: Ivan Klymenko To: Marius Strobl Message-ID: <20101018132556.6fa48bfa@ukr.net> In-Reply-To: <20101018083845.GK1416@alchemy.franken.de> References: <201010171807.o9HI7b6g073145@pozo.com> <20101018083845.GK1416@alchemy.franken.de> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Buganini , freebsd-current@freebsd.org Subject: Re: bge0 does not work anymore 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, 18 Oct 2010 10:26:05 -0000 =D0=92 Mon, 18 Oct 2010 10:38:45 +0200 Marius Strobl =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Mon, Oct 18, 2010 at 09:32:13AM +0800, Buganini wrote: > > my last known usable kernel revision is r213813 > > with r213920, leds are extinguished when executing dhclient >=20 > Sorry, it looks like it was my fault this time, should be fixed again > with r214012. >=20 > Marius r214012. Thank you! it worked! :) From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 13:40: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 7C670106566B; Mon, 18 Oct 2010 13:40:40 +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 6A2708FC28; Mon, 18 Oct 2010 13:40:39 +0000 (UTC) Received: by wwb13 with SMTP id 13so318184wwb.31 for ; Mon, 18 Oct 2010 06:40:38 -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=jlhIjpPhIheME1iQ94xo08F1IIs55qBF/rMyxW0puPk=; b=mzFdhqSJXNRJTFx6BNt29qEIv6uFeimZCbwfstkI92buggVV8YcXafw9s3v31EwiOF gtl7+RxiQhvQnR9wox7JR1VYY8brLYLmiGfaL4D49CeHGC9ipj6FGYNbT37fOhc+sWY/ 125GaeUzuoB4aWg4fAmAedcHXFrH1J5gLd5uQ= 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=pmv+IvnOZ7/yHylYYqAHpQwCYMihdd0/07npLDTBTQ05X9H5m2EyInATOYf0aOeRJw PBbkQKUPZZIwn/k/IDjEe2wyIfEfsXJ8OVs4ly4bXa2HESMwwoCfJybFHoEdHOcnHKE2 KKJadt8Q5MjwO/zBWMoB8BIJZcG5CjcuvcpmE= MIME-Version: 1.0 Received: by 10.227.128.7 with SMTP id i7mr877857wbs.165.1287409238045; Mon, 18 Oct 2010 06:40:38 -0700 (PDT) Sender: giovanni.trematerra@gmail.com Received: by 10.227.144.203 with HTTP; Mon, 18 Oct 2010 06:40:37 -0700 (PDT) In-Reply-To: <4CBBEBDF.3060905@freebsd.org> References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> Date: Mon, 18 Oct 2010 15:40:37 +0200 X-Google-Sender-Auth: S-myIx_JcK8dZdmOJH3MTfvUgmk Message-ID: From: Giovanni Trematerra To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system 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, 18 Oct 2010 13:40:40 -0000 On Mon, Oct 18, 2010 at 8:40 AM, Andriy Gapon wrote: > on 23/09/2010 21:25 Andriy Gapon said the following: >> >> Jeff, >> >> just for the kicks I tried to emulate a machine with 64 logical CPUs usi= ng >> qemu-devel port: >> qemu-system-x86_64 -smp sockets=3D4,cores=3D8,threads=3D2 ... >> >> It seems that FreeBSD agreed to recognize only first 32 CPUs, but it pan= iced anyway. >> >> Here's a backtrace: >> #34 0xffffffff804fe7f5 in zone_alloc_item (zone=3D0xffffffff80be1554, >> udata=3D0xffffffff80be1550, flags=3D1924) at /usr/src/sys/vm/uma_core.c:= 2506 >> #35 0xffffffff804ff35d in hash_alloc (hash=3D0xffffff001ffdb030) at >> /usr/src/sys/vm/uma_core.c:483 >> #36 0xffffffff804ff642 in keg_ctor (mem=3DVariable "mem" is not availabl= e. >> ) at /usr/src/sys/vm/uma_core.c:1396 >> #37 0xffffffff804fe91b in zone_alloc_item (zone=3D0xffffffff80a1f300, >> udata=3D0xffffffff80be1b60, flags=3D2) at /usr/src/sys/vm/uma_core.c:254= 4 >> #38 0xffffffff804ff92e in zone_ctor (mem=3DVariable "mem" is not availab= le. >> ) at /usr/src/sys/vm/uma_core.c:1832 >> #39 0xffffffff804ffca4 in uma_startup (bootmem=3D0xffffff001ffac000, boo= t_pages=3D48) >> at /usr/src/sys/vm/uma_core.c:1741 >> #40 0xffffffff80514822 in vm_page_startup (vaddr=3D18446744071576817664)= at >> /usr/src/sys/vm/vm_page.c:360 >> #41 0xffffffff805060c5 in vm_mem_init (dummy=3DVariable "dummy" is not a= vailable. >> ) at /usr/src/sys/vm/vm_init.c:118 >> #42 0xffffffff803258b9 in mi_startup () at /usr/src/sys/kern/init_main.c= :253 >> #43 0xffffffff8017177c in btext () at /usr/src/sys/amd64/amd64/locore.S:= 81 >> [[[ >> Note: >> 1. Frame numbers are high because the backtrace is obtained via gdb remo= tely >> connected to qemu and also there is bunch of extra frames from DDB, etc. >> 2. Line numbers in uma_core. won't match those in FreeBSD tree, because = I've doing >> some unrelated hacking in the file. >> ]]] >> >> The problem seems to be with creation of "UMA Zones" zone and keg. >> Because of the large number of processors, size argument in the followin= g snippet >> is set to a value of 4480: >> >> args.name =3D "UMA Zones"; >> args.size =3D sizeof(struct uma_zone) + >> =A0 =A0 (sizeof(struct uma_cache) * (mp_maxid + 1)); >> >> Because of this, keg_ctor() calls keg_large_init(): >> >> else if ((keg->uk_size+UMA_FRITM_SZ) > >> =A0 =A0 (UMA_SLAB_SIZE - sizeof(struct uma_slab))) >> =A0 =A0 =A0 =A0 keg_large_init(keg); >> else >> =A0 =A0 =A0 =A0 keg_small_init(keg); >> >> keg_large_init sets UMA_ZONE_OFFPAGE and UMA_ZONE_HASH flags for this ke= g. >> This leads to hash_alloc() being invoked from keg_ctor(): >> >> if (keg->uk_flags & UMA_ZONE_HASH) >> =A0 =A0 =A0 =A0 hash_alloc(&keg->uk_hash); >> >> But the problem is that "UMA Hash" zone is not created yet and thus the = call leads >> to the panic. =A0"UMA Hash" zone is the last of system zones created. >> >> Not sure what the proper fix here could/should be. >> Would it work to simply not set UMA_ZONE_HASH flag when UMA_ZFLAG_INTERN= AL is set? >> >> >> And some final calculations. >> On the test system sizeof(struct uma_cache) is 128 bytes and (mp_maxid += 1) is 32, >> so it's already UMA_SLAB_SIZE =3D PAGE_SIZE =3D 4096. >> > > Here is a simple solution that seems to work: > http://people.freebsd.org/~avg/uma-many-cpus.diff > Not sure if it's the best we can do. > I don't know if it makes sense I only want to raise a flag. Is it safe to call kmem_malloc() before bucket_init() during uma_startup() to reserve room for CPU caches? Reading the top uma_int.h comment, it seems that the best way to handle this issue would be to implement and allow for dynamic slab sizes. I'm also afraid that memory footprint will be larger than now. -- Trematerra Giovanni From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 14:18: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 011FE106566C; Mon, 18 Oct 2010 14:18:05 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 908F98FC0A; Mon, 18 Oct 2010 14:18:03 +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 RAA15898; Mon, 18 Oct 2010 17:18:02 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CBC5719.1020807@freebsd.org> Date: Mon, 18 Oct 2010 17:18:01 +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: Giovanni Trematerra References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system 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, 18 Oct 2010 14:18:05 -0000 on 18/10/2010 16:40 Giovanni Trematerra said the following: > On Mon, Oct 18, 2010 at 8:40 AM, Andriy Gapon wrote: >> on 23/09/2010 21:25 Andriy Gapon said the following: >>> >>> Jeff, >>> >>> just for the kicks I tried to emulate a machine with 64 logical CPUs using >>> qemu-devel port: >>> qemu-system-x86_64 -smp sockets=4,cores=8,threads=2 ... >>> >>> It seems that FreeBSD agreed to recognize only first 32 CPUs, but it paniced anyway. >>> >>> Here's a backtrace: >>> #34 0xffffffff804fe7f5 in zone_alloc_item (zone=0xffffffff80be1554, >>> udata=0xffffffff80be1550, flags=1924) at /usr/src/sys/vm/uma_core.c:2506 >>> #35 0xffffffff804ff35d in hash_alloc (hash=0xffffff001ffdb030) at >>> /usr/src/sys/vm/uma_core.c:483 >>> #36 0xffffffff804ff642 in keg_ctor (mem=Variable "mem" is not available. >>> ) at /usr/src/sys/vm/uma_core.c:1396 >>> #37 0xffffffff804fe91b in zone_alloc_item (zone=0xffffffff80a1f300, >>> udata=0xffffffff80be1b60, flags=2) at /usr/src/sys/vm/uma_core.c:2544 >>> #38 0xffffffff804ff92e in zone_ctor (mem=Variable "mem" is not available. >>> ) at /usr/src/sys/vm/uma_core.c:1832 >>> #39 0xffffffff804ffca4 in uma_startup (bootmem=0xffffff001ffac000, boot_pages=48) >>> at /usr/src/sys/vm/uma_core.c:1741 >>> #40 0xffffffff80514822 in vm_page_startup (vaddr=18446744071576817664) at >>> /usr/src/sys/vm/vm_page.c:360 >>> #41 0xffffffff805060c5 in vm_mem_init (dummy=Variable "dummy" is not available. >>> ) at /usr/src/sys/vm/vm_init.c:118 >>> #42 0xffffffff803258b9 in mi_startup () at /usr/src/sys/kern/init_main.c:253 >>> #43 0xffffffff8017177c in btext () at /usr/src/sys/amd64/amd64/locore.S:81 >>> [[[ >>> Note: >>> 1. Frame numbers are high because the backtrace is obtained via gdb remotely >>> connected to qemu and also there is bunch of extra frames from DDB, etc. >>> 2. Line numbers in uma_core. won't match those in FreeBSD tree, because I've doing >>> some unrelated hacking in the file. >>> ]]] >>> >>> The problem seems to be with creation of "UMA Zones" zone and keg. >>> Because of the large number of processors, size argument in the following snippet >>> is set to a value of 4480: >>> >>> args.name = "UMA Zones"; >>> args.size = sizeof(struct uma_zone) + >>> (sizeof(struct uma_cache) * (mp_maxid + 1)); >>> >>> Because of this, keg_ctor() calls keg_large_init(): >>> >>> else if ((keg->uk_size+UMA_FRITM_SZ) > >>> (UMA_SLAB_SIZE - sizeof(struct uma_slab))) >>> keg_large_init(keg); >>> else >>> keg_small_init(keg); >>> >>> keg_large_init sets UMA_ZONE_OFFPAGE and UMA_ZONE_HASH flags for this keg. >>> This leads to hash_alloc() being invoked from keg_ctor(): >>> >>> if (keg->uk_flags & UMA_ZONE_HASH) >>> hash_alloc(&keg->uk_hash); >>> >>> But the problem is that "UMA Hash" zone is not created yet and thus the call leads >>> to the panic. "UMA Hash" zone is the last of system zones created. >>> >>> Not sure what the proper fix here could/should be. >>> Would it work to simply not set UMA_ZONE_HASH flag when UMA_ZFLAG_INTERNAL is set? >>> >>> >>> And some final calculations. >>> On the test system sizeof(struct uma_cache) is 128 bytes and (mp_maxid + 1) is 32, >>> so it's already UMA_SLAB_SIZE = PAGE_SIZE = 4096. >>> >> >> Here is a simple solution that seems to work: >> http://people.freebsd.org/~avg/uma-many-cpus.diff >> Not sure if it's the best we can do. >> > > I don't know if it makes sense I only want to raise a flag. > Is it safe to call kmem_malloc() before bucket_init() during > uma_startup() to reserve room for CPU caches? Hmm, not sure what exactly you mean. > Reading the top uma_int.h comment, it seems that the best way to > handle this issue > would be to implement and allow for dynamic slab sizes. Again, not sure if I follow you, I don't see relation between per-cpu caches and dynamic slab size. > I'm also afraid that memory footprint will be larger than now. Of course, but only by sizeof(pointer) per zone. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 15:23:38 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 3C3931065672; Mon, 18 Oct 2010 15:23:38 +0000 (UTC) Date: Mon, 18 Oct 2010 15:23:38 +0000 From: Alexander Best To: Alex Dupre Message-ID: <20101018152338.GA6540@freebsd.org> References: <4C9389BC.7090300@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C9389BC.7090300@FreeBSD.org> Cc: Andriy Gapon , Jack Vogel , current@FreeBSD.org, Jakub Lach Subject: Re: Regarding pciids 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, 18 Oct 2010 15:23:38 -0000 On Fri Sep 17 10, Alex Dupre wrote: > I created hackish scripts to generate pci_vendors file from Boemler and > Mares (pciids.sf.net) lists. I haven't found the Hart list. > > The results of the scripts are here: sorry it seems i missed your post back then. i found two more lists: http://rh-software.com/downloads/pcidevs.txt and http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be based on the Hart list) the actual Hart list seems to have vanished and the web location is no longer accessible. personally i don't think it's necessary to combine the data of two files. the mares database seems extremely elaborate. all my pci devices get described properly. also making use of only one databse would make it more easy to submit additional info back to the vendor. so any objections to switching to the mares list? cheers. alex > > http://www.alexdupre.com/pci_vendors/mares.txt > http://www.alexdupre.com/pci_vendors/boemler.txt > http://www.alexdupre.com/pci_vendors/mares-boemler.txt > http://www.alexdupre.com/pci_vendors/boemler-mares.txt > > The first two are generated from single lists, the last two are > combined, with different preference order. > > -- > Alex Dupre -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 15:28:05 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id F180A10656B8; Mon, 18 Oct 2010 15:28:03 +0000 (UTC) Date: Mon, 18 Oct 2010 15:28:03 +0000 From: Alexander Best To: Alex Dupre Message-ID: <20101018152803.GA8679@freebsd.org> References: <4C9389BC.7090300@FreeBSD.org> <20101018152338.GA6540@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101018152338.GA6540@freebsd.org> Cc: Andriy Gapon , Jack Vogel , current@FreeBSD.org, Jakub Lach Subject: Re: Regarding pciids 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, 18 Oct 2010 15:28:05 -0000 On Mon Oct 18 10, Alexander Best wrote: > On Fri Sep 17 10, Alex Dupre wrote: > > I created hackish scripts to generate pci_vendors file from Boemler and > > Mares (pciids.sf.net) lists. I haven't found the Hart list. > > > > The results of the scripts are here: > > sorry it seems i missed your post back then. > > i found two more lists: > > http://rh-software.com/downloads/pcidevs.txt > and > http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be based on the > Hart list) > > the actual Hart list seems to have vanished and the web location is no longer > accessible. > > personally i don't think it's necessary to combine the data of two files. the > mares database seems extremely elaborate. all my pci devices get described > properly. also making use of only one databse would make it more easy to submit > additional info back to the vendor. > > so any objections to switching to the mares list? > > cheers. > alex > > > > > http://www.alexdupre.com/pci_vendors/mares.txt > > http://www.alexdupre.com/pci_vendors/boemler.txt > > http://www.alexdupre.com/pci_vendors/mares-boemler.txt > > http://www.alexdupre.com/pci_vendors/boemler-mares.txt > > > > The first two are generated from single lists, the last two are > > combined, with different preference order. oh...and i think it would be a good idea to move from ";" as comment character to "#". that way we wouldn't need to run a script, but could include the vendor file directly into the src tree. cheers. alex > > > > -- > > Alex Dupre > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 16:55: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 9D505106566B; Mon, 18 Oct 2010 16:55:20 +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 2724C8FC08; Mon, 18 Oct 2010 16:55:19 +0000 (UTC) Received: by qwe4 with SMTP id 4so719051qwe.13 for ; Mon, 18 Oct 2010 09:55: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:cc:content-type; bh=/Egxh4ntALxs13W3Rl9IJZ+o8Q9wORd4C1XCmRoh3WY=; b=oyejy4c9Ze1C2/NXBh4zk7E/QFRoBREwF7+F7fR1PVdOQE8NZ64MAFci7bJJQwaYpy jaL900bO+L8vb1Ff0UykqpkeiBysgEL5RO/7NBONdUj5LT3t0LXhHnDDUXrClQk7GsCe CVTANWXNVXwdtDmwUN1bdo64XcXrSDD00Xqr0= 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=V6LcnmDjPfMiOMGeM1vuPBJ2ixhClTDSZBJU9y7lA3zDnUvo6mx2Hs9QVB53JUtc4S ZkgLWkZliioG2yB4/+mM+XBA675fWKH8NXgRagCvaNUDdIhFtcOQPI2+iluwxXl8LVcv uOQ0+a2NqHxZWPJjwm582VFwucdwtBxhXimLg= MIME-Version: 1.0 Received: by 10.224.182.3 with SMTP id ca3mr2862969qab.313.1287420918922; Mon, 18 Oct 2010 09:55:18 -0700 (PDT) Received: by 10.229.61.29 with HTTP; Mon, 18 Oct 2010 09:55:18 -0700 (PDT) In-Reply-To: References: <4CB8A614.6000707@greatbaysoftware.com> <4CB8BED6.8040204@greatbaysoftware.com> Date: Mon, 18 Oct 2010 20:55:18 +0400 Message-ID: From: Sergey Kandaurov To: Charles Owens Content-Type: multipart/mixed; boundary=20cf30363f838c7da20492e70aab Cc: FreeBSD Current , Scott Long , freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state 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, 18 Oct 2010 16:55:20 -0000 --20cf30363f838c7da20492e70aab Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16 October 2010 02:18, Sergey Kandaurov wrote: > On 16 October 2010 00:51, Charles Owens wro= te: >> =A0Hmm... the problem appears to have resolved itself. =A0After a few ho= urs the >> new drive seems to have gone back into the array, and the original hot s= pare >> drive put back into hot-spare state. >> >> So I'm interpreting state 0x0020 to therefore mean something like "hang = on >> while I use this new drive to automatically put everything back as it wa= s >> before the failure". =A0Is this correct? >> >> Thanks, >> Charles >> >> [root@Bsvr ~]# mfiutil show drives >> mfi0 Physical Drives: >> ( =A0149G) ONLINE =A0SATA enclosure = 1, slot 0 >> ( =A0149G) ONLINE =A0SATA enclosure = 1, slot 1 >> ( =A0149G) ONLINE =A0SATA enclosure = 1, slot 2 >> ( =A0149G) HOT SPARE =A0SATA enclosu= re 1, slot >> 3 >> ( =A0149G) ONLINE =A0SATA enclosure = 1, slot 4 >> >> >>> [...] >>> [root@svr ~]# mfiutil show drives >>> mfi0 Physical Drives: >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot >>> 0 >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot >>> 1 >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot >>> 2 >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot >>> 3 >>> ( =A0149G) PSTATE 0x0020 =A0SATA en= closure >>> 1, slot 4 >>> >>> mfi0: =A0port 0x1000-0x10ff mem >>> ... >>> > > Hi, Charles Owens. > > 0x20 is much likely to be the copyback physical state, > which is missing in enum mfi_pd_state. > And what you've experienced is copyback feature in action :) > Your array has been rebuilt with HSP as its ordinal PD, then you > switched failed drive > with good one, and HSP came into copyback mode to move all its data back > to good disk. That prevents reordering of disk numbers in array and > double rebuilding. > So, it no one objects, I'd like to commit this change. --=20 wbr, pluknet --20cf30363f838c7da20492e70aab Content-Type: application/octet-stream; name="mfi.diff" Content-Disposition: attachment; filename="mfi.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gffl5tic0 SW5kZXg6IHN5cy9kZXYvbWZpL21maXJlZy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvbWZpL21m aXJlZy5oCShyZXZpc2lvbiAyMTQwMjUpCisrKyBzeXMvZGV2L21maS9tZmlyZWcuaAkod29ya2lu ZyBjb3B5KQpAQCAtOTc1LDcgKzk3NSw4IEBACiAJTUZJX1BEX1NUQVRFX09GRkxJTkUgPSAweDEw LAogCU1GSV9QRF9TVEFURV9GQUlMRUQgPSAweDExLAogCU1GSV9QRF9TVEFURV9SRUJVSUxEID0g MHgxNCwKLQlNRklfUERfU1RBVEVfT05MSU5FID0gMHgxOAorCU1GSV9QRF9TVEFURV9PTkxJTkUg PSAweDE4LAorCU1GSV9QRF9TVEFURV9DT1BZQkFDSyA9IDB4MjAKIH07CiAKIHVuaW9uIG1maV9s ZF9yZWYgewpJbmRleDogdXNyLnNiaW4vbWZpdXRpbC9tZmlfZHJpdmUuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSB1c3Iuc2Jpbi9tZml1dGlsL21maV9kcml2ZS5jCShyZXZpc2lvbiAyMTQwMjUpCisrKyB1c3Iu c2Jpbi9tZml1dGlsL21maV9kcml2ZS5jCSh3b3JraW5nIGNvcHkpCkBAIC02NSw2ICs2NSw4IEBA CiAJCXJldHVybiAoIlJFQlVJTEQiKTsKIAljYXNlIE1GSV9QRF9TVEFURV9PTkxJTkU6CiAJCXJl dHVybiAoIk9OTElORSIpOworCWNhc2UgTUZJX1BEX1NUQVRFX0NPUFlCQUNLOgorCQlyZXR1cm4g KCJDT1BZQkFDSyIpOwogCWRlZmF1bHQ6CiAJCXNwcmludGYoYnVmLCAiUFNUQVRFIDB4JTA0eCIs IHN0YXRlKTsKIAkJcmV0dXJuIChidWYpOwo= --20cf30363f838c7da20492e70aab-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 16:55: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 10B251065670 for ; Mon, 18 Oct 2010 16:55:36 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B72598FC20 for ; Mon, 18 Oct 2010 16:55:35 +0000 (UTC) Received: by vws1 with SMTP id 1so601269vws.13 for ; Mon, 18 Oct 2010 09:55:34 -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=VQ1AJpBZgoIZVhCXRaOOTXn5DwFk/pAjVLKZ4eojlAA=; b=g3Jx8+PJ+O9PyrIycgOE7Xynl4XKlRR8a/52HVnsDxw53de2y/qYlEeJ8nZayTtL4s NH8ewjTPtCzbRKQvvaq6Zg5Wx5ojCuojjFPbI/hRqRi6g4niOAwzLzs909bSB1YlxO+G D14a2+EpcStlT1D4raGRpSbzBsTGcDNw8k1SE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c1BlBBbpFbNGBulgoifwdQXocavaSjgWfExFP7dPl4EDNRDDtCFPnEvW145tL3L9od SpXd1odyPZ+L4EPopzCxiaXXpPZFEtZzeCpPyYjd7WGdBPq9PhwdG/3c4ydYejf/EP1U +M39vJTLKizLVfZN1FexyYnDAp1NNXch3lAoY= MIME-Version: 1.0 Received: by 10.220.193.69 with SMTP id dt5mr1257599vcb.152.1287420934222; Mon, 18 Oct 2010 09:55:34 -0700 (PDT) Received: by 10.220.171.208 with HTTP; Mon, 18 Oct 2010 09:55:34 -0700 (PDT) Date: Tue, 19 Oct 2010 00:55:34 +0800 Message-ID: From: Buganini To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: wpa_supplicant and ssid 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, 18 Oct 2010 16:55:36 -0000 It seems that wpa_supplicant iterate through all scanned ssids and try to associate with each, and that cause two problem for me. 1) in my school, there are many AP, and connection is not stable, when disconnect, it take many time to try and fail to associate with those ssids until the one I want. 2) i can't associate with a non-discoverable ssid but probably it is my wireless driver's problem, i'm using bwn0 and currently I need to force it to use mode 11b or it is unusable. or should I complain to upstream ? -- Buganini From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 17:25: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 CFEF7106564A; Mon, 18 Oct 2010 17:25:43 +0000 (UTC) (envelope-from yanegomi@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 5C6B38FC12; Mon, 18 Oct 2010 17:25:43 +0000 (UTC) Received: by gwb20 with SMTP id 20so585169gwb.13 for ; Mon, 18 Oct 2010 10:25:42 -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=cQaqS5tKBU1YZ5k9Htx2zfK48+Hd6Wur8SlEtjsm3uQ=; b=PvDr/MU9YsLkbkYjQj7tTpdiNgEztfYP8iqOgYrpWvtfX5rzK4kZd81XmhpFGpb+mw 5hu/RQQc4rw0zWVIadB7vzkyoRT00HLzjnB5NqFYW8ARQ4YweEfWyWQilcv2rUv4oSE8 6Hf6/BFTBrzPequRmRYwqyP9ApFjFKhsPDT9U= 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=lsWYiwg2aBVAVmmHIpCWcPO7sQhD0cxg0lXO6wF2TXRjrnHGk5CNWnsm2QGPhCgW5L CksJ4rXl8lRk4QF/2N8dRgsrTOHycuByvm9mDjBcq/g3l6rn8EkXZG3waXJER+UrWyq5 //17TRU90UNw9iv2d7Ta/aNGWC1RI9skQaWLQ= MIME-Version: 1.0 Received: by 10.42.175.136 with SMTP id ba8mr2394544icb.73.1287422742447; Mon, 18 Oct 2010 10:25:42 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 18 Oct 2010 10:25:42 -0700 (PDT) In-Reply-To: References: <4CB8A614.6000707@greatbaysoftware.com> <4CB8BED6.8040204@greatbaysoftware.com> Date: Mon, 18 Oct 2010 10:25:42 -0700 X-Google-Sender-Auth: NvtNG_RoZ6KQ0MLTZh8jY4kA4rg Message-ID: From: Garrett Cooper To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Charles Owens , FreeBSD Current , Scott Long , freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state 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, 18 Oct 2010 17:25:44 -0000 On Mon, Oct 18, 2010 at 9:55 AM, Sergey Kandaurov wrote= : > On 16 October 2010 02:18, Sergey Kandaurov wrote: >> On 16 October 2010 00:51, Charles Owens wr= ote: >>> =A0Hmm... the problem appears to have resolved itself. =A0After a few h= ours the >>> new drive seems to have gone back into the array, and the original hot = spare >>> drive put back into hot-spare state. >>> >>> So I'm interpreting state 0x0020 to therefore mean something like "hang= on >>> while I use this new drive to automatically put everything back as it w= as >>> before the failure". =A0Is this correct? >>> >>> Thanks, >>> Charles >>> >>> [root@Bsvr ~]# mfiutil show drives >>> mfi0 Physical Drives: >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot 0 >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot 1 >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot 2 >>> ( =A0149G) HOT SPARE =A0SATA enclos= ure 1, slot >>> 3 >>> ( =A0149G) ONLINE =A0SATA enclosure= 1, slot 4 >>> >>> > >>>> > [...] >>>> [root@svr ~]# mfiutil show drives >>>> mfi0 Physical Drives: >>>> ( =A0149G) ONLINE =A0SATA enclosur= e 1, slot >>>> 0 >>>> ( =A0149G) ONLINE =A0SATA enclosur= e 1, slot >>>> 1 >>>> ( =A0149G) ONLINE =A0SATA enclosur= e 1, slot >>>> 2 >>>> ( =A0149G) ONLINE =A0SATA enclosur= e 1, slot >>>> 3 >>>> ( =A0149G) PSTATE 0x0020 =A0SATA e= nclosure >>>> 1, slot 4 >>>> >>>> mfi0: =A0port 0x1000-0x10ff mem >>>> ... >>>> >> >> Hi, Charles Owens. >> >> 0x20 is much likely to be the copyback physical state, >> which is missing in enum mfi_pd_state. >> And what you've experienced is copyback feature in action :) >> Your array has been rebuilt with HSP as its ordinal PD, then you >> switched failed drive >> with good one, and HSP came into copyback mode to move all its data back >> to good disk. That prevents reordering of disk numbers in array and >> double rebuilding. >> > > So, it no one objects, I'd like to commit this change. Check with LSI before you commit that; you might not understand the overall nuances of that value. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 17:27: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 3F3F61065672; Mon, 18 Oct 2010 17:27:28 +0000 (UTC) (envelope-from yanegomi@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 879078FC0A; Mon, 18 Oct 2010 17:27:27 +0000 (UTC) Received: by yxe42 with SMTP id 42so59627yxe.13 for ; Mon, 18 Oct 2010 10:27:27 -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=yjGP9xZoroJUkVgytfJrXFBIQzKE5OiP+eWCW+1ezFs=; b=T5AttjjR6cxFXCHOiHp6/32CvxAi4NH1sct7gqFT8FqECeOcKrHaSRHjkiysXrjzG6 QZ1sEcuwNAmq4yQ3G1vYFS8olZKjkdohAcgug+E+XZlRLlg7KSP9cwXmBla0zO8NO+Mb Bv5VRXG+FscvjYC6Ml3NROLX8aSBlb9Ln6afA= 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=msFsVzqI5X3s87M9GFeOWFzu1DHVYmxW2g3wM45OmNxaoeUznHu37wZrjGOEv73zNN RU025U+h1isOHTHgMroAU1TeisJ37OkfXX1R5dnC9jBzkugBdwXFthypO2JZWaacaJwT 4ASQWm4YXnpB9nFokqCTaKJTFSAMZIzsfVsdA= MIME-Version: 1.0 Received: by 10.42.189.198 with SMTP id df6mr3117662icb.192.1287422845937; Mon, 18 Oct 2010 10:27:25 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 18 Oct 2010 10:27:25 -0700 (PDT) In-Reply-To: <20101018152803.GA8679@freebsd.org> References: <4C9389BC.7090300@FreeBSD.org> <20101018152338.GA6540@freebsd.org> <20101018152803.GA8679@freebsd.org> Date: Mon, 18 Oct 2010 10:27:25 -0700 X-Google-Sender-Auth: ETg587B_K8q1TM6i-zvHI-dy5dY Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org, Jakub Lach , Andriy Gapon , Alex Dupre , Jack Vogel Subject: Re: Regarding pciids 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, 18 Oct 2010 17:27:28 -0000 On Mon, Oct 18, 2010 at 8:28 AM, Alexander Best wrote: > On Mon Oct 18 10, Alexander Best wrote: >> On Fri Sep 17 10, Alex Dupre wrote: >> > I created hackish scripts to generate pci_vendors file from Boemler and >> > Mares (pciids.sf.net) lists. I haven't found the Hart list. >> > >> > The results of the scripts are here: >> >> sorry it seems i missed your post back then. >> >> i found two more lists: >> >> http://rh-software.com/downloads/pcidevs.txt >> and >> http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be based on the >> Hart list) >> >> the actual Hart list seems to have vanished and the web location is no longer >> accessible. >> >> personally i don't think it's necessary to combine the data of two files. the >> mares database seems extremely elaborate. all my pci devices get described >> properly. also making use of only one databse would make it more easy to submit >> additional info back to the vendor. >> >> so any objections to switching to the mares list? >> >> cheers. >> alex >> >> > >> > http://www.alexdupre.com/pci_vendors/mares.txt >> > http://www.alexdupre.com/pci_vendors/boemler.txt >> > http://www.alexdupre.com/pci_vendors/mares-boemler.txt >> > http://www.alexdupre.com/pci_vendors/boemler-mares.txt >> > >> > The first two are generated from single lists, the last two are >> > combined, with different preference order. > > oh...and i think it would be a good idea to move from ";" as comment character > to "#". that way we wouldn't need to run a script, but could include the vendor > file directly into the src tree. I noted this a while back to Warner and Brooke as I came up with a short script to do this, and they suggested that it be supplemented to the existing list, not replace it. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 17: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 183EC106566B for ; Mon, 18 Oct 2010 17:54:24 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id BA1D68FC22 for ; Mon, 18 Oct 2010 17:54:23 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Mon, 18 Oct 2010 13:43:31 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 3C94A33C00; Mon, 18 Oct 2010 13:43:31 -0400 (EDT) Date: Mon, 18 Oct 2010 13:43:31 -0400 From: Ed Maste To: Message-ID: <20101018174331.GA80017@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: CPU report in first line of "vmstat 1" is meaningless 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, 18 Oct 2010 17:54:24 -0000 The us/sy/id CPU usage numbers in the first line of vmstat are not useful, because they're calculated based on kern.cp_times since boot, and not a delta as are all subsequent lines. If the system has been up long enough wrapping may come in to play, giving negative results. For example, on one machine I see: $ vmstat 1 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 pa0 in sy cs us sy id 1 0 2 1097M 227M 101 0 0 0 195 45 0 0 483 40 243 -24 -33 157 1 0 2 1102M 222M 1396 0 0 0 0 0 0 0 159 2170 826 25 2 74 1 0 2 1107M 218M 1124 0 0 0 0 0 0 0 146 2217 789 24 2 74 Should we wait for one interval before displaying the first line, or display nothing (or a placeholder like '-')? Below is a quick patch that illustrates the issue, and implements the "display nothing" option. With the patch the output looks like: $ vmstat 1 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr ad0 in sy cs us sy id 3 0 0 1971M 85M 326 0 0 0 334 5 0 457 3674 1495 2 0 0 1971M 85M 23 0 0 0 0 0 0 301 3634 1209 5 7 88 1 0 0 1971M 85M 74 0 0 0 0 0 0 510 4655 1619 7 3 90 And the patch: Index: usr.bin/vmstat/vmstat.c =================================================================== --- usr.bin/vmstat/vmstat.c (revision 214019) +++ usr.bin/vmstat/vmstat.c (working copy) @@ -658,6 +658,7 @@ int ncpus, maxid; u_long cpumask; int rate_adj; + int have_prev_cp_times = 0; uptime = getuptime(); halfuptime = uptime / 2; @@ -803,10 +804,13 @@ (unsigned long)rate(sum.v_intr - osum.v_intr), (unsigned long)rate(sum.v_syscall - osum.v_syscall), (unsigned long)rate(sum.v_swtch - osum.v_swtch)); - if (Pflag) - pcpustats(ncpus, cpumask, maxid); - else - cpustats(); + if (have_prev_cp_times) { + if (Pflag) + pcpustats(ncpus, cpumask, maxid); + else + cpustats(); + } else + have_prev_cp_times = 1; (void)printf("\n"); (void)fflush(stdout); if (reps >= 0 && --reps <= 0) -Ed From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 18:33: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 D2B0A1065672 for ; Mon, 18 Oct 2010 18:33:53 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9556B8FC13 for ; Mon, 18 Oct 2010 18:33:52 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id o9IIBhhu026309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Oct 2010 13:11:44 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o9IIBhdK050100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Oct 2010 13:11:43 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.4/Submit) id o9IIBgap050099; Mon, 18 Oct 2010 13:11:43 -0500 (CDT) (envelope-from dan) Date: Mon, 18 Oct 2010 13:11:42 -0500 From: Dan Nelson To: Ed Maste Message-ID: <20101018181142.GC5644@dan.emsphone.com> References: <20101018174331.GA80017@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101018174331.GA80017@sandvine.com> X-OS: FreeBSD 8.1-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.96.3 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Mon, 18 Oct 2010 13:11:44 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-current@freebsd.org Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 18 Oct 2010 18:33:53 -0000 In the last episode (Oct 18), Ed Maste said: > The us/sy/id CPU usage numbers in the first line of vmstat are not useful, > because they're calculated based on kern.cp_times since boot, and not a > delta as are all subsequent lines. If the system has been up long enough > wrapping may come in to play, giving negative results. For example, on > one machine I see: Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit cp_time value essentially won't roll over (at 1 billion increments per second it will roll over in 500 years; we currently increment 133 times per second, I think). If the value can be calculated accurately, it should be printed. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 18:36:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B47BF106566B; Mon, 18 Oct 2010 18:36:45 +0000 (UTC) Date: Mon, 18 Oct 2010 18:36:45 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20101018183645.GA33114@freebsd.org> References: <4C9389BC.7090300@FreeBSD.org> <20101018152338.GA6540@freebsd.org> <20101018152803.GA8679@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: current@freebsd.org, Jakub Lach , Andriy Gapon , Alex Dupre , Jack Vogel Subject: Re: Regarding pciids 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, 18 Oct 2010 18:36:45 -0000 On Mon Oct 18 10, Garrett Cooper wrote: > On Mon, Oct 18, 2010 at 8:28 AM, Alexander Best wrote: > > On Mon Oct 18 10, Alexander Best wrote: > >> On Fri Sep 17 10, Alex Dupre wrote: > >> > I created hackish scripts to generate pci_vendors file from Boemler and > >> > Mares (pciids.sf.net) lists. I haven't found the Hart list. > >> > > >> > The results of the scripts are here: > >> > >> sorry it seems i missed your post back then. > >> > >> i found two more lists: > >> > >> http://rh-software.com/downloads/pcidevs.txt > >> and > >> http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be based on the > >> Hart list) > >> > >> the actual Hart list seems to have vanished and the web location is no longer > >> accessible. > >> > >> personally i don't think it's necessary to combine the data of two files. the > >> mares database seems extremely elaborate. all my pci devices get described > >> properly. also making use of only one databse would make it more easy to submit > >> additional info back to the vendor. > >> > >> so any objections to switching to the mares list? > >> > >> cheers. > >> alex > >> > >> > > >> > http://www.alexdupre.com/pci_vendors/mares.txt > >> > http://www.alexdupre.com/pci_vendors/boemler.txt > >> > http://www.alexdupre.com/pci_vendors/mares-boemler.txt > >> > http://www.alexdupre.com/pci_vendors/boemler-mares.txt > >> > > >> > The first two are generated from single lists, the last two are > >> > combined, with different preference order. > > > > oh...and i think it would be a good idea to move from ";" as comment character > > to "#". that way we wouldn't need to run a script, but could include the vendor > > file directly into the src tree. > > I noted this a while back to Warner and Brooke as I came up with a > short script to do this, and they suggested that it be supplemented to > the existing list, not replace it. why? the mares list is obviosly superior, because linux contributes to it and thus has far more people submitting changes than any other list. is there a case where the old list has an entry the mares list is missing? cheers. alex > Cheers, > -Garrett -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 18:45: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 E385B106566B for ; Mon, 18 Oct 2010 18:45:31 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id A6CDA8FC1A for ; Mon, 18 Oct 2010 18:45:31 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id DEB4111B809; Mon, 18 Oct 2010 13:45:30 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id HN9SC07LSPX4; Mon, 18 Oct 2010 13:45:30 -0500 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Message-Id: Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Mon, 18 Oct 2010 19:45:27 +0100 To: =?iso-8859-1?Q?Istv=E1n?= X-Mailer: Apple Mail (2.1081) Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 18:45:32 -0000 On 12 Oct 2010, at 23:40, Istv=E1n wrote: > Hey, >=20 >=20 > I am not 100% sure this is the right list to approach with this = problem but > let's try this one. >=20 > So I am trying to use dtrace on the previously mentioned system, I = followed > the usual kernel rebuild process using the following wiki: >=20 > http://wiki.freebsd.org/DTrace >=20 > Dtrace works fine and I am able to trace the kernel.[1] >=20 >=20 > My problem is: I can't trace any user land application including = PostgreSQL > and Ruby. >=20 > I added the following lines to the /etc/make.conf as it is written in = the > wiki: >=20 > STRIP=3D > CFLAGS+=3D-fno-omit-frame-pointer >=20 > I compiled both of the softwares and trying to trace them but there = are no > bindings in the dtrace -l ouput >=20 >=20 > # dtrace -l | grep -i ruby >=20 > i might have overlooked something important but not sure what. >=20 > Any help is appreciated. Pls cc my email since i am not on this list. >=20 >=20 > Thank you in advance. >=20 > I. >=20 > 1. >=20 > [root@freebsd9 ~]# uname -a > FreeBSD freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Oct 8 = 21:09:20 UTC > 2010 root@freebsd9:/usr/obj/usr/src/sys/DTRACE amd64 > [root@freebsd9 ~]# kldstat > Id Refs Address Size Name > 1 26 0xffffffff80100000 f49bb0 kernel > 2 1 0xffffffff81212000 ad8 dtraceall.ko > 3 1 0xffffffff81213000 4a59 profile.ko > 4 11 0xffffffff81218000 3e2f opensolaris.ko > 5 3 0xffffffff8121c000 3db0 cyclic.ko > 6 9 0xffffffff81220000 13af4b dtrace.ko > 7 1 0xffffffff8135b000 fce0 systrace.ko > 8 1 0xffffffff8136b000 4128 sdt.ko > 9 1 0xffffffff81370000 44b8 lockstat.ko > 10 1 0xffffffff81375000 b94e fasttrap.ko > 11 1 0xffffffff81381000 61ab fbt.ko > 12 1 0xffffffff81388000 4a67 dtnfsclient.ko > 13 1 0xffffffff8138d000 4118 dtmalloc.ko > [root@freebsd9 ~]# >=20 > [root@freebsd9 ~]# cat d.d > vfs:namecache:enter:done > { >=20 > @distribution =3D quantize(strlen((string)arg1)); > } > [root@freebsd9 ~]# dtrace -s d.d > dtrace: script 'd.d' matched 1 probe > ^C >=20 >=20 > value ------------- Distribution ------------- count > 2 | 0 > 4 |@@@@@@@ 1 > 8 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5 > 16 | 0 >=20 >=20 >=20 The Ruby port doesn't have DTrace support, but the PostgreSQL port has a = DTrace option (only the latest postgresql port). Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 19:13:52 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 CECD91065694; Mon, 18 Oct 2010 19:13:52 +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 3DE088FC1C; Mon, 18 Oct 2010 19:13:52 +0000 (UTC) Received: by iwn36 with SMTP id 36so6215iwn.13 for ; Mon, 18 Oct 2010 12:13:51 -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=z/eRgU+SIzTkPU10KdbG1QM9SU9PhOUDQvu6KfcDyNk=; b=GKc+ST4Wyi12EK0KzKs4qf3snliPpXhggXjz2U7fSUNSObnWSQM9d/kkdHmB4rzdR/ xzDdtw11lakwFb8H3aFx4ceDOIkqtooyAa+/0U+7YfnemYvXQBY1QSwaBc+wlxaqEsLE /7jpwvN9Y60G+Vct+2Z5DyGudPpEgywRHL07I= 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=RmSsmzw7BaMCV4WYYVm9q4ptwESeDlHcHlrxwJF3Z9cC8ovnZS/8ah7eQXeyvnSbEZ wGC6b1xpHvuP4wLkUBc4e702IiUEOVof07fk98ipQd6qf9plpMtT8KDWeBxXv1O7MMCJ PnjX3X1l4CA0gkKZaaEX9N2Z93xufQ2bfiUE4= MIME-Version: 1.0 Received: by 10.231.155.7 with SMTP id q7mr3792603ibw.105.1287429231684; Mon, 18 Oct 2010 12:13:51 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 18 Oct 2010 12:13:51 -0700 (PDT) In-Reply-To: <20101018183645.GA33114@freebsd.org> References: <4C9389BC.7090300@FreeBSD.org> <20101018152338.GA6540@freebsd.org> <20101018152803.GA8679@freebsd.org> <20101018183645.GA33114@freebsd.org> Date: Mon, 18 Oct 2010 12:13:51 -0700 X-Google-Sender-Auth: WRtIW74dvuuRa71PkHVnSLN_AR0 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Jakub Lach , Andriy Gapon , Alex Dupre , Jack Vogel Subject: Re: Regarding pciids 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, 18 Oct 2010 19:13:53 -0000 On Mon, Oct 18, 2010 at 11:36 AM, Alexander Best wrot= e: > On Mon Oct 18 10, Garrett Cooper wrote: >> On Mon, Oct 18, 2010 at 8:28 AM, Alexander Best wr= ote: >> > On Mon Oct 18 10, Alexander Best wrote: >> >> On Fri Sep 17 10, Alex Dupre wrote: >> >> > I created hackish scripts to generate pci_vendors file from Boemler= and >> >> > Mares (pciids.sf.net) lists. I haven't found the Hart list. >> >> > >> >> > The results of the scripts are here: >> >> >> >> sorry it seems i missed your post back then. >> >> >> >> i found two more lists: >> >> >> >> http://rh-software.com/downloads/pcidevs.txt >> >> and >> >> http://hobbes.nmsu.edu/h-browse.php?dir=3D/pub/incoming (seems to be = based on the >> >> Hart list) >> >> >> >> the actual Hart list seems to have vanished and the web location is n= o longer >> >> accessible. >> >> >> >> personally i don't think it's necessary to combine the data of two fi= les. the >> >> mares database seems extremely elaborate. all my pci devices get desc= ribed >> >> properly. also making use of only one databse would make it more easy= to submit >> >> additional info back to the vendor. >> >> >> >> so any objections to switching to the mares list? >> >> >> >> cheers. >> >> alex >> >> >> >> > >> >> > http://www.alexdupre.com/pci_vendors/mares.txt >> >> > http://www.alexdupre.com/pci_vendors/boemler.txt >> >> > http://www.alexdupre.com/pci_vendors/mares-boemler.txt >> >> > http://www.alexdupre.com/pci_vendors/boemler-mares.txt >> >> > >> >> > The first two are generated from single lists, the last two are >> >> > combined, with different preference order. >> > >> > oh...and i think it would be a good idea to move from ";" as comment c= haracter >> > to "#". that way we wouldn't need to run a script, but could include t= he vendor >> > file directly into the src tree. >> >> =A0 =A0 I noted this a while back to Warner and Brooke as I came up with= a >> short script to do this, and they suggested that it be supplemented to >> the existing list, not replace it. > > why? the mares list is obviosly superior, because linux contributes to it= and > thus has far more people submitting changes than any other list. > > is there a case where the old list has an entry the mares list is missing= ? Most of the values (above 99%) were the same actually between the 2 lists. I think the point was to avoid churn in the description fields because a lot of the description fields were different, the Linux list was produced by questionable sources (IIRC the other list was produced by vendors, but I could be wrong). Rather than guessing I would just ask Brookes and Warner directly though, offlist... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 19:25:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5582E1065679; Mon, 18 Oct 2010 19:25:02 +0000 (UTC) Date: Mon, 18 Oct 2010 19:25:02 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101018192502.GA44432@freebsd.org> References: <20101015204748.GA88259@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20101015204748.GA88259@freebsd.org> Subject: Re: some camcontrol(8) cleanups 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, 18 Oct 2010 19:25:02 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline here's a slighly updated version without any whitespace diffs. cheers. alex On Fri Oct 15 10, Alexander Best wrote: > hi there, > > i sent this patch to mav@, but he seems rather busy atm. > > maybe somebody else would like to take a look at it and see if it improves > camcontrol's current behavior. > > cheers. > alex > > ----- Forwarded message from Alexander Best ----- > > Date: Mon, 27 Sep 2010 00:35:41 +0000 > From: Alexander Best > To: Alexander Motin > Subject: some camcontrol(8) cleanups > > hi there, > > since you're the most active committer to camcontrol i thought i'd mail you > this patch which does some whitespace cleaning up in camcontrol.c along with > some 'camcontrol identify' improvements (imo). > > the only real change is that i removed this check: > > if (parm->satacapabilities && parm->satacapabilities != 0xffff) > > i've run the patched camcontrol against a few devices and none seemed to return > parm->satacapabilities == 0xffff. > so i don't think this check is needed in order to prevent 'camcontrol identify' > to falsely report NCQ supported/enabled. > > cheers. > alex > > -- > a13x > > diff --git a/sbin/camcontrol/camcontrol.c b/sbin/camcontrol/camcontrol.c > index 9f26906..b822282 100644 > --- a/sbin/camcontrol/camcontrol.c > +++ b/sbin/camcontrol/camcontrol.c > @@ -116,7 +116,7 @@ typedef enum { > } cam_argmask; > > struct camcontrol_opts { > - const char *optname; > + const char *optname; > cam_cmdmask cmdnum; > cam_argmask argnum; > const char *subopt; > @@ -204,7 +204,7 @@ static int readdefects(struct cam_device *device, int argc, char **argv, > char *combinedopt, int retry_count, int timeout); > static void modepage(struct cam_device *device, int argc, char **argv, > char *combinedopt, int retry_count, int timeout); > -static int scsicmd(struct cam_device *device, int argc, char **argv, > +static int scsicmd(struct cam_device *device, int argc, char **argv, > char *combinedopt, int retry_count, int timeout); > static int tagcontrol(struct cam_device *device, int argc, char **argv, > char *combinedopt); > @@ -234,7 +234,7 @@ static int atapm(struct cam_device *device, int argc, char **argv, > #endif > > camcontrol_optret > -getoption(char *arg, cam_cmdmask *cmdnum, cam_argmask *argnum, > +getoption(char *arg, cam_cmdmask *cmdnum, cam_argmask *argnum, > const char **subopt) > { > struct camcontrol_opts *opts; > @@ -622,7 +622,7 @@ scsistart(struct cam_device *device, int startstop, int loadeject, > else > fprintf(stdout, > "Error received from stop unit command\n"); > - > + > if (arglist & CAM_ARG_VERBOSE) { > cam_error_print(device, ccb, CAM_ESF_ALL, > CAM_EPF_ALL, stderr); > @@ -688,7 +688,7 @@ scsiinquiry(struct cam_device *device, int retry_count, int timeout) > union ccb *ccb; > struct scsi_inquiry_data *inq_buf; > int error = 0; > - > + > ccb = cam_getccb(device); > > if (ccb == NULL) { > @@ -721,13 +721,13 @@ scsiinquiry(struct cam_device *device, int retry_count, int timeout) > * scsi_inquiry() will convert an inq_len (which is passed in as > * a u_int32_t, but the field in the CDB is only 1 byte) of 256 > * to 0. Evidently, very few devices meet the spec in that > - * regard. Some devices, like many Seagate disks, take the 0 as > + * regard. Some devices, like many Seagate disks, take the 0 as > * 0, and don't return any data. One Pioneer DVD-R drive > * returns more data than the command asked for. > * > * So, since there are numerous devices that just don't work > * right with the full inquiry size, we don't send the full size. > - * > + * > * - The second reason not to use the full inquiry data length is > * that we don't need it here. The only reason we issue a > * standard inquiry is to get the vendor name, device name, > @@ -1181,7 +1181,7 @@ atacapprint(struct ata_params *parm) > } > > printf("\nFeature " > - "Support Enable Value Vendor\n"); > + "Support Enabled Value Vendor\n"); > printf("read ahead %s %s\n", > parm->support.command1 & ATA_SUPPORT_LOOKAHEAD ? "yes" : "no", > parm->enabled.command1 & ATA_SUPPORT_LOOKAHEAD ? "yes" : "no"); > @@ -1201,16 +1201,13 @@ atacapprint(struct ata_params *parm) > ATA_QUEUE_LEN(parm->queue) + 1); > } else > printf("\n"); > - if (parm->satacapabilities && parm->satacapabilities != 0xffff) { > - printf("Native Command Queuing (NCQ) %s ", > - parm->satacapabilities & ATA_SUPPORT_NCQ ? > - "yes" : "no"); > + printf("Native Command Queuing (NCQ) %s", > + parm->satacapabilities & ATA_SUPPORT_NCQ ? "yes" : "no"); > if (parm->satacapabilities & ATA_SUPPORT_NCQ) { > - printf(" %d tags\n", > + printf(" %d tags\n", > ATA_QUEUE_LEN(parm->queue) + 1); > } else > printf("\n"); > - } > printf("SMART %s %s\n", > parm->support.command1 & ATA_SUPPORT_SMART ? "yes" : "no", > parm->enabled.command1 & ATA_SUPPORT_SMART ? "yes" : "no"); > @@ -1223,28 +1220,39 @@ atacapprint(struct ata_params *parm) > printf("power management %s %s\n", > parm->support.command1 & ATA_SUPPORT_POWERMGT ? "yes" : "no", > parm->enabled.command1 & ATA_SUPPORT_POWERMGT ? "yes" : "no"); > - printf("advanced power management %s %s %d/0x%02X\n", > + printf("advanced power management %s %s", > parm->support.command2 & ATA_SUPPORT_APM ? "yes" : "no", > - parm->enabled.command2 & ATA_SUPPORT_APM ? "yes" : "no", > - parm->apm_value, parm->apm_value); > - printf("automatic acoustic management %s %s " > - "%d/0x%02X %d/0x%02X\n", > + parm->enabled.command2 & ATA_SUPPORT_APM ? "yes" : "no"); > + if (parm->support.command2 & ATA_SUPPORT_APM) { > + printf(" %d/0x%02X\n", > + parm->apm_value, parm->apm_value); > + } else > + printf("\n"); > + printf("automatic acoustic management %s %s", > parm->support.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no", > - parm->enabled.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no", > - ATA_ACOUSTIC_CURRENT(parm->acoustic), > - ATA_ACOUSTIC_CURRENT(parm->acoustic), > - ATA_ACOUSTIC_VENDOR(parm->acoustic), > - ATA_ACOUSTIC_VENDOR(parm->acoustic)); > + parm->enabled.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no"); > + if (parm->support.command2 & ATA_SUPPORT_AUTOACOUSTIC) { > + printf(" %d/0x%02X %d/0x%02X\n", > + ATA_ACOUSTIC_CURRENT(parm->acoustic), > + ATA_ACOUSTIC_CURRENT(parm->acoustic), > + ATA_ACOUSTIC_VENDOR(parm->acoustic), > + ATA_ACOUSTIC_VENDOR(parm->acoustic)); > + } else > + printf("\n"); > printf("media status notification %s %s\n", > parm->support.command2 & ATA_SUPPORT_NOTIFY ? "yes" : "no", > parm->enabled.command2 & ATA_SUPPORT_NOTIFY ? "yes" : "no"); > printf("power-up in Standby %s %s\n", > parm->support.command2 & ATA_SUPPORT_STANDBY ? "yes" : "no", > parm->enabled.command2 & ATA_SUPPORT_STANDBY ? "yes" : "no"); > - printf("write-read-verify %s %s %d/0x%x\n", > + printf("write-read-verify %s %s", > parm->support2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no", > - parm->enabled2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no", > - parm->wrv_mode, parm->wrv_mode); > + parm->enabled2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no"); > + if (parm->support2 & ATA_SUPPORT_WRITEREADVERIFY) { > + printf(" %d/0x%x\n", > + parm->wrv_mode, parm->wrv_mode); > + } else > + printf("\n"); > printf("unload %s %s\n", > parm->support.extension & ATA_SUPPORT_UNLOAD ? "yes" : "no", > parm->enabled.extension & ATA_SUPPORT_UNLOAD ? "yes" : "no"); > @@ -1255,7 +1263,6 @@ atacapprint(struct ata_params *parm) > parm->support_dsm & ATA_SUPPORT_DSM_TRIM ? "yes" : "no"); > } > > - > static int > ataidentify(struct cam_device *device, int retry_count, int timeout) > { > @@ -1902,7 +1909,7 @@ readdefects(struct cam_device *device, int argc, char **argv, > > /* > * XXX KDM I should probably clean up the printout format for the > - * disk defects. > + * disk defects. > */ > switch (returned_format & SRDDH10_DLIST_FORMAT_MASK){ > case SRDDH10_PHYSICAL_SECTOR_FORMAT: > @@ -2011,7 +2018,7 @@ void > reassignblocks(struct cam_device *device, u_int32_t *blocks, int num_blocks) > { > union ccb *ccb; > - > + > ccb = cam_getccb(device); > > cam_freeccb(ccb); > @@ -2114,7 +2121,7 @@ mode_select(struct cam_device *device, int save_pages, int retry_count, > err(1, "error sending mode select command"); > else > errx(1, "error sending mode select command"); > - > + > } > > cam_freeccb(ccb); > @@ -2294,7 +2301,7 @@ scsicmd(struct cam_device *device, int argc, char **argv, char *combinedopt, > if (arglist & CAM_ARG_CMD_IN) { > warnx("command must either be " > "read or write, not both"); > - error = 1; > + error = 1; > goto scsicmd_bailout; > } > arglist |= CAM_ARG_CMD_OUT; > @@ -2611,7 +2618,7 @@ camdebug(int argc, char **argv, char *combinedopt) > warnx("bus:target, or bus:target:lun to debug"); > } > } > - > + > if (error == 0) { > > ccb.ccb_h.func_code = XPT_DEBUG; > @@ -2874,7 +2881,7 @@ cts_print(struct cam_device *device, struct ccb_trans_settings *cts) > } > > /* > - * Get a path inquiry CCB for the specified device. > + * Get a path inquiry CCB for the specified device. > */ > static int > get_cpi(struct cam_device *device, struct ccb_pathinq *cpi) > @@ -2913,7 +2920,7 @@ get_cpi_bailout: > } > > /* > - * Get a get device CCB for the specified device. > + * Get a get device CCB for the specified device. > */ > static int > get_cgd(struct cam_device *device, struct ccb_getdev *cgd) > @@ -3764,9 +3771,9 @@ doreport: > fprintf(stdout, > "\rFormatting: %ju.%02u %% " > "(%d/%d) done", > - (uintmax_t)(percentage / > + (uintmax_t)(percentage / > (0x10000 * 100)), > - (unsigned)((percentage / > + (unsigned)((percentage / > 0x10000) % 100), > val, 0x10000); > fflush(stdout); > @@ -3956,7 +3963,7 @@ retry: > case RPL_LUNDATA_ATYP_PERIPH: > if ((lundata->luns[i].lundata[j] & > RPL_LUNDATA_PERIPH_BUS_MASK) != 0) > - fprintf(stdout, "%d:", > + fprintf(stdout, "%d:", > lundata->luns[i].lundata[j] & > RPL_LUNDATA_PERIPH_BUS_MASK); > else if ((j == 0) > @@ -3994,7 +4001,7 @@ retry: > field_len_code = (lundata->luns[i].lundata[j] & > RPL_LUNDATA_EXT_LEN_MASK) >> 4; > field_len = field_len_code * 2; > - > + > if ((eam_code == RPL_LUNDATA_EXT_EAM_WK) > && (field_len_code == 0x00)) { > fprintf(stdout, "%d", > @@ -4352,7 +4359,7 @@ bailout: > > #endif /* MINIMALISTIC */ > > -void > +void > usage(int verbose) > { > fprintf(verbose ? stdout : stderr, > @@ -4494,7 +4501,7 @@ usage(int verbose) > #endif /* MINIMALISTIC */ > } > > -int > +int > main(int argc, char **argv) > { > int c; > @@ -4544,7 +4551,7 @@ main(int argc, char **argv) > * this. getopt is kinda braindead, so you end up having to run > * through the options twice, and give each invocation of getopt > * the option string for the other invocation. > - * > + * > * You would think that you could just have two groups of options. > * The first group would get parsed by the first invocation of > * getopt, and the second group would get parsed by the second > @@ -4553,13 +4560,13 @@ main(int argc, char **argv) > * to the argument _after_ the first argument in the second group. > * So when the second invocation of getopt comes around, it doesn't > * recognize the first argument it gets and then bails out. > - * > + * > * A nice alternative would be to have a flag for getopt that says > * "just keep parsing arguments even when you encounter an unknown > * argument", but there isn't one. So there's no real clean way to > * easily parse two sets of arguments without having one invocation > * of getopt know about the other. > - * > + * > * Without this hack, the first invocation of getopt would work as > * long as the generic arguments are first, but the second invocation > * (in the subfunction) would fail in one of two ways. In the case > @@ -4573,14 +4580,14 @@ main(int argc, char **argv) > * whether optind had been incremented one option too far. The > * mechanics of that, however, are more daunting than just giving > * both invocations all of the expect options for either invocation. > - * > + * > * Needless to say, I wouldn't mind if someone invented a better > * (non-GPL!) command line parsing interface than getopt. I > * wouldn't mind if someone added more knobs to getopt to make it > * work better. Who knows, I may talk myself into doing it someday, > * if the standards weenies let me. As it is, it just leads to > * hackery like this and causes people to avoid it in some cases. > - * > + * > * KDM, September 8th, 1998 > */ > if (subopt != NULL) > @@ -4607,7 +4614,7 @@ main(int argc, char **argv) > > /* > * First catch people who try to do things like: > - * camcontrol tur /dev/da0 > + * camcontrol tur /dev/da0 > * camcontrol doesn't take device nodes as arguments. > */ > if (argv[2][0] == '/') { > > > ----- End forwarded message ----- > > -- > a13x -- a13x --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="camcontrol.c.diff2" diff --git a/sbin/camcontrol/camcontrol.c b/sbin/camcontrol/camcontrol.c index 9f26906..1b7febb 100644 --- a/sbin/camcontrol/camcontrol.c +++ b/sbin/camcontrol/camcontrol.c @@ -1181,7 +1181,7 @@ atacapprint(struct ata_params *parm) } printf("\nFeature " - "Support Enable Value Vendor\n"); + "Support Enabled Value Vendor\n"); printf("read ahead %s %s\n", parm->support.command1 & ATA_SUPPORT_LOOKAHEAD ? "yes" : "no", parm->enabled.command1 & ATA_SUPPORT_LOOKAHEAD ? "yes" : "no"); @@ -1197,20 +1197,17 @@ atacapprint(struct ata_params *parm) parm->support.command2 & ATA_SUPPORT_QUEUED ? "yes" : "no", parm->enabled.command2 & ATA_SUPPORT_QUEUED ? "yes" : "no"); if (parm->support.command2 & ATA_SUPPORT_QUEUED) { - printf(" %d tags\n", + printf(" %3d tags\n", ATA_QUEUE_LEN(parm->queue) + 1); } else printf("\n"); - if (parm->satacapabilities && parm->satacapabilities != 0xffff) { - printf("Native Command Queuing (NCQ) %s ", - parm->satacapabilities & ATA_SUPPORT_NCQ ? - "yes" : "no"); + printf("Native Command Queuing (NCQ) %s", + parm->satacapabilities & ATA_SUPPORT_NCQ ? "yes" : "no"); if (parm->satacapabilities & ATA_SUPPORT_NCQ) { - printf(" %d tags\n", + printf(" %3d tags\n", ATA_QUEUE_LEN(parm->queue) + 1); } else printf("\n"); - } printf("SMART %s %s\n", parm->support.command1 & ATA_SUPPORT_SMART ? "yes" : "no", parm->enabled.command1 & ATA_SUPPORT_SMART ? "yes" : "no"); @@ -1223,28 +1220,39 @@ atacapprint(struct ata_params *parm) printf("power management %s %s\n", parm->support.command1 & ATA_SUPPORT_POWERMGT ? "yes" : "no", parm->enabled.command1 & ATA_SUPPORT_POWERMGT ? "yes" : "no"); - printf("advanced power management %s %s %d/0x%02X\n", + printf("advanced power management %s %s", parm->support.command2 & ATA_SUPPORT_APM ? "yes" : "no", - parm->enabled.command2 & ATA_SUPPORT_APM ? "yes" : "no", + parm->enabled.command2 & ATA_SUPPORT_APM ? "yes" : "no"); + if (parm->support.command2 & ATA_SUPPORT_APM) { + printf(" %3d/0x%02X\n", parm->apm_value, parm->apm_value); - printf("automatic acoustic management %s %s " - "%d/0x%02X %d/0x%02X\n", + } else + printf("\n"); + printf("automatic acoustic management %s %s", parm->support.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no", - parm->enabled.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no", + parm->enabled.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no"); + if (parm->support.command2 & ATA_SUPPORT_AUTOACOUSTIC) { + printf(" %3d/0x%02X %03d/0x%02X\n", ATA_ACOUSTIC_CURRENT(parm->acoustic), ATA_ACOUSTIC_CURRENT(parm->acoustic), ATA_ACOUSTIC_VENDOR(parm->acoustic), ATA_ACOUSTIC_VENDOR(parm->acoustic)); + } else + printf("\n"); printf("media status notification %s %s\n", parm->support.command2 & ATA_SUPPORT_NOTIFY ? "yes" : "no", parm->enabled.command2 & ATA_SUPPORT_NOTIFY ? "yes" : "no"); printf("power-up in Standby %s %s\n", parm->support.command2 & ATA_SUPPORT_STANDBY ? "yes" : "no", parm->enabled.command2 & ATA_SUPPORT_STANDBY ? "yes" : "no"); - printf("write-read-verify %s %s %d/0x%x\n", + printf("write-read-verify %s %s", parm->support2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no", - parm->enabled2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no", + parm->enabled2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no"); + if (parm->support2 & ATA_SUPPORT_WRITEREADVERIFY) { + printf(" %3d/0x%x\n", parm->wrv_mode, parm->wrv_mode); + } else + printf("\n"); printf("unload %s %s\n", parm->support.extension & ATA_SUPPORT_UNLOAD ? "yes" : "no", parm->enabled.extension & ATA_SUPPORT_UNLOAD ? "yes" : "no"); @@ -1255,7 +1263,6 @@ atacapprint(struct ata_params *parm) parm->support_dsm & ATA_SUPPORT_DSM_TRIM ? "yes" : "no"); } - static int ataidentify(struct cam_device *device, int retry_count, int timeout) { --6TrnltStXW4iwmi0-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 19:30: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 60B9110656A4 for ; Mon, 18 Oct 2010 19:30:12 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8708FC16 for ; Mon, 18 Oct 2010 19:30:11 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Mon, 18 Oct 2010 15:30:11 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 0F2C433C00; Mon, 18 Oct 2010 15:30:11 -0400 (EDT) Date: Mon, 18 Oct 2010 15:30:11 -0400 From: Ed Maste To: Dan Nelson Message-ID: <20101018193010.GA88783@sandvine.com> References: <20101018174331.GA80017@sandvine.com> <20101018181142.GC5644@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20101018181142.GC5644@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 18 Oct 2010 19:30:12 -0000 On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > cp_time value essentially won't roll over (at 1 billion increments per > second it will roll over in 500 years; we currently increment 133 times per > second, I think). If the value can be calculated accurately, it should be > printed. Well, it won't roll over, but it's still different from all following lines (in that it effectively shows user/system/idle CPU usage since boot on the first line, and a snapshot over the last interval from then on). I think it's still better to avoid printing it in that case. On a related note I'm not sure if it makes sense to have the same behaviour for the first line when an interval is set as when it is invoked with no interval. -Ed From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 19:39: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 736E4106564A for ; Mon, 18 Oct 2010 19:39:18 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC618FC0A for ; Mon, 18 Oct 2010 19:39:17 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id o9IJdH30035435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Oct 2010 14:39:17 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o9IJdGKF092311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Oct 2010 14:39:17 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.4/Submit) id o9IJdGg7092310; Mon, 18 Oct 2010 14:39:16 -0500 (CDT) (envelope-from dan) Date: Mon, 18 Oct 2010 14:39:16 -0500 From: Dan Nelson To: Ed Maste Message-ID: <20101018193916.GD5644@dan.emsphone.com> References: <20101018174331.GA80017@sandvine.com> <20101018181142.GC5644@dan.emsphone.com> <20101018193010.GA88783@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101018193010.GA88783@sandvine.com> X-OS: FreeBSD 8.1-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.96.3 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Mon, 18 Oct 2010 14:39:17 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-current@freebsd.org Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 18 Oct 2010 19:39:18 -0000 In the last episode (Oct 18), Ed Maste said: > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > cp_time value essentially won't roll over (at 1 billion increments per > > second it will roll over in 500 years; we currently increment 133 times > > per second, I think). If the value can be calculated accurately, it > > should be printed. > > Well, it won't roll over, but it's still different from all following > lines (in that it effectively shows user/system/idle CPU usage since boot > on the first line, and a snapshot over the last interval from then on). I > think it's still better to avoid printing it in that case. It is documented to do that, though, and could affect scripts that expect to see average-since-boot info on the first line. iostat does the same, btw. > On a related note I'm not sure if it makes sense to have the same > behaviour for the first line when an interval is set as when it is > invoked with no interval. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 19:57: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 245481065670 for ; Mon, 18 Oct 2010 19:57:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D93DC8FC28 for ; Mon, 18 Oct 2010 19:57:07 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1FF2673098; Mon, 18 Oct 2010 21:51:25 +0200 (CEST) Date: Mon, 18 Oct 2010 21:51:25 +0200 From: Luigi Rizzo To: David Naylor Message-ID: <20101018195125.GA46115@onelab2.iet.unipi.it> References: <201010180943.37042.naylor.b.david@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010180943.37042.naylor.b.david@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: geom_sched usage 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, 18 Oct 2010 19:57:08 -0000 On Mon, Oct 18, 2010 at 09:43:28AM +0200, David Naylor wrote: > Hi, > > I've used geom_sched to some success. Normally I do not notice anything but > today I was copying big files over a gigabit ethernet and my laptop was not > very responsive. I loaded gsched and the responsiveness improved (although > still rather bad for anything requiring something from the HDD). > > Thank you for all this work :-) > > Some questions I have: > > - with a gmirror should the gsched be attached to the underlying devices (aka > /dev/ad?) or to the mirror device (aka /dev/mirror/?)? always attach as close as possible to the hardware. > - is there anyway to automatically attach gsched to a device on startup (i.e. > in rc.conf)? no, you have to build some script yourself. > > - is there a way to prioritise random IO (vs sequential reads from big > files)? no way to do that, but you can modify the quantum size and time to let sequential reads get shorter chunks kern.geom.sched.rr.quantum_kb: 8192 kern.geom.sched.rr.quantum_ms: 100 kern.geom.sched.rr.wait_ms: 10 e.g. on a laptop it might make sense to set quantum_ms=50 and quantum_kb=2048 > - gsched_as does not appear to be installed. true, gsched_as was just a proof of concept and gsched_rr includes anticipation and round robin, so it is a superset of gsched_as cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 20:02: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 551261065673 for ; Mon, 18 Oct 2010 20:02:39 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id D9EC88FC12 for ; Mon, 18 Oct 2010 20:02:34 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9IK2RV1006008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2010 07:02:28 +1100 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 o9IK2QU9051660; Tue, 19 Oct 2010 07:02:26 +1100 (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 o9IK2Qjm051659; Tue, 19 Oct 2010 07:02:26 +1100 (EST) (envelope-from peter) Date: Tue, 19 Oct 2010 07:02:26 +1100 From: Peter Jeremy To: Darren Reed Message-ID: <20101018200226.GA51447@server.vk2pj.dyndns.org> References: <4CB639DB.3090907@fastmail.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <4CB639DB.3090907@fastmail.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 Subject: Re: 2TB HDD = TIMEOUT - READ_DMA48 .... 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, 18 Oct 2010 20:02:39 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Oct-13 22:59:39 +0000, Darren Reed wrote: >As another body that today bought a 2TB HDD, I can confirm the presence >of kernel messages relating to READ_DMA48 with FreeBSD 8. >The drive in question is a Hitachi one, not a Samsung. > >Is it the drive, system or operating system? You'll need to provide some more details such as how old your FreeBSD 8 is, drive model number, controller details and the actual error message you are getting. I recently bought a Hitachi Deskstar 7K2000, which is sitting in an Astone enclosure (identifying as "Sunplus Technology Co.,Ltd."). Unfortunately, I'm limited to USB2 whilst I wait for the correct eSATA adapter. Whilst the first disk was DOA, its replacement is running perfectly (though slowly) with my 2-week-old FreeBSD 8.1-stable. In particular, one of the first tests I did was to write a pseudo-random sequence over the entire surface and then verify it to ensure that all sectors are uniquely addressable. --=20 Peter Jeremy --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAky8p9IACgkQ/opHv/APuIcZ4ACgmNmFnfd3MHew+6dSQktTKH+G MU0An3SZquOX2hdDSCmS7PngyenWypl0 =9Mco -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 20:12:17 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 12F73106566C for ; Mon, 18 Oct 2010 20:12:17 +0000 (UTC) (envelope-from leccine@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8B0C8FC12 for ; Mon, 18 Oct 2010 20:12:16 +0000 (UTC) Received: by ywh2 with SMTP id 2so745489ywh.13 for ; Mon, 18 Oct 2010 13:12: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=GUI7568nzkrCSKruj4gsrbGm/C6UJsbKx3ri8uJj6iI=; b=c1Ib1wjdGSLoqNhd+bQfTi6HdfpHOeiHq84QzSAwaiuKDK7WwnrflRvG0HGXhxitpN z1iqHH42J8OrRnMtZBVvh+7rBnv+8DZNuVVxSCsMxDTHvk9jFgX40ScoeFdqHBwXbhdc l4h3qt8ByvWkUCUt6JZ3U/9zq9oM7QUcIvjCo= 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=Z9zK8k5rXDT0+LUoD1DuQT6cPfRiHVVdkUyQW0Jl6tCknffq01NPhtT3RLTYOxfdM/ +IVZixaVRs9L9ZsitOqP7a+7zbjfRMYfXJk5Zt6mM4SfZ+q/g0lS89TveKyfI5W+Emia pQ6TvcyrFkL0x1I7EcveBxKCgwOIZuKozVzbs= MIME-Version: 1.0 Received: by 10.42.192.202 with SMTP id dr10mr2845840icb.526.1287432735680; Mon, 18 Oct 2010 13:12:15 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Mon, 18 Oct 2010 13:12:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Oct 2010 21:12:15 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: Rui Paulo X-Mailman-Approved-At: Mon, 18 Oct 2010 20:24:02 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 20:12:17 -0000 Hey, how come it doesn't work? What are the necessary requirements for using dtrace on freebsd? Do you nee= d a library or something? Do you know why Ruby has no dtrace bindings on Freebsd? Thank you. Istvan On Mon, Oct 18, 2010 at 7:45 PM, Rui Paulo wrote: > > On 12 Oct 2010, at 23:40, Istv=C3=A1n wrote: > > > Hey, > > > > > > I am not 100% sure this is the right list to approach with this problem > but > > let's try this one. > > > > So I am trying to use dtrace on the previously mentioned system, I > followed > > the usual kernel rebuild process using the following wiki: > > > > http://wiki.freebsd.org/DTrace > > > > Dtrace works fine and I am able to trace the kernel.[1] > > > > > > My problem is: I can't trace any user land application including > PostgreSQL > > and Ruby. > > > > I added the following lines to the /etc/make.conf as it is written in t= he > > wiki: > > > > STRIP=3D > > CFLAGS+=3D-fno-omit-frame-pointer > > > > I compiled both of the softwares and trying to trace them but there are > no > > bindings in the dtrace -l ouput > > > > > > # dtrace -l | grep -i ruby > > > > i might have overlooked something important but not sure what. > > > > Any help is appreciated. Pls cc my email since i am not on this list. > > > > > > Thank you in advance. > > > > I. > > > > 1. > > > > [root@freebsd9 ~]# uname -a > > FreeBSD freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Oct 8 21:09:2= 0 > UTC > > 2010 root@freebsd9:/usr/obj/usr/src/sys/DTRACE amd64 > > [root@freebsd9 ~]# kldstat > > Id Refs Address Size Name > > 1 26 0xffffffff80100000 f49bb0 kernel > > 2 1 0xffffffff81212000 ad8 dtraceall.ko > > 3 1 0xffffffff81213000 4a59 profile.ko > > 4 11 0xffffffff81218000 3e2f opensolaris.ko > > 5 3 0xffffffff8121c000 3db0 cyclic.ko > > 6 9 0xffffffff81220000 13af4b dtrace.ko > > 7 1 0xffffffff8135b000 fce0 systrace.ko > > 8 1 0xffffffff8136b000 4128 sdt.ko > > 9 1 0xffffffff81370000 44b8 lockstat.ko > > 10 1 0xffffffff81375000 b94e fasttrap.ko > > 11 1 0xffffffff81381000 61ab fbt.ko > > 12 1 0xffffffff81388000 4a67 dtnfsclient.ko > > 13 1 0xffffffff8138d000 4118 dtmalloc.ko > > [root@freebsd9 ~]# > > > > [root@freebsd9 ~]# cat d.d > > vfs:namecache:enter:done > > { > > > > @distribution =3D quantize(strlen((string)arg1)); > > } > > [root@freebsd9 ~]# dtrace -s d.d > > dtrace: script 'd.d' matched 1 probe > > ^C > > > > > > value ------------- Distribution ------------- count > > 2 | 0 > > 4 |@@@@@@@ 1 > > 8 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5 > > 16 | 0 > > > > > > > > The Ruby port doesn't have DTrace support, but the PostgreSQL port has a > DTrace option (only the latest postgresql port). > > Regards, > -- > Rui Paulo > > > --=20 the sun shines for all http://blog.l1x.me From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 20:57: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 69F5D106566B for ; Mon, 18 Oct 2010 20:57:53 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8088FC0C for ; Mon, 18 Oct 2010 20:57:52 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id 64369157543; Mon, 18 Oct 2010 15:57:52 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id J1AIGFLJAVZ6; Mon, 18 Oct 2010 15:57:52 -0500 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Mon, 18 Oct 2010 21:57:49 +0100 To: =?iso-8859-1?Q?Istv=E1n?= X-Mailer: Apple Mail (2.1081) Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 20:57:53 -0000 On 18 Oct 2010, at 21:12, Istv=E1n wrote: > Hey, >=20 > how come it doesn't work? >=20 > What are the necessary requirements for using dtrace on freebsd? Do = you need a library or something? It involves creating a DTrace provider and compiling it during the build = phase. Please read: = http://dtrace.org/blogs/ahl/user_land_tracing_gets_better >=20 > Do you know why Ruby has no dtrace bindings on Freebsd? You need to change the port Makefile to enable DTrace. >=20 >=20 > Thank you. >=20 > Istvan >=20 >=20 > On Mon, Oct 18, 2010 at 7:45 PM, Rui Paulo wrote: >=20 > On 12 Oct 2010, at 23:40, Istv=E1n wrote: >=20 > > Hey, > > > > > > I am not 100% sure this is the right list to approach with this = problem but > > let's try this one. > > > > So I am trying to use dtrace on the previously mentioned system, I = followed > > the usual kernel rebuild process using the following wiki: > > > > http://wiki.freebsd.org/DTrace > > > > Dtrace works fine and I am able to trace the kernel.[1] > > > > > > My problem is: I can't trace any user land application including = PostgreSQL > > and Ruby. > > > > I added the following lines to the /etc/make.conf as it is written = in the > > wiki: > > > > STRIP=3D > > CFLAGS+=3D-fno-omit-frame-pointer > > > > I compiled both of the softwares and trying to trace them but there = are no > > bindings in the dtrace -l ouput > > > > > > # dtrace -l | grep -i ruby > > > > i might have overlooked something important but not sure what. > > > > Any help is appreciated. Pls cc my email since i am not on this = list. > > > > > > Thank you in advance. > > > > I. > > > > 1. > > > > [root@freebsd9 ~]# uname -a > > FreeBSD freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Oct 8 = 21:09:20 UTC > > 2010 root@freebsd9:/usr/obj/usr/src/sys/DTRACE amd64 > > [root@freebsd9 ~]# kldstat > > Id Refs Address Size Name > > 1 26 0xffffffff80100000 f49bb0 kernel > > 2 1 0xffffffff81212000 ad8 dtraceall.ko > > 3 1 0xffffffff81213000 4a59 profile.ko > > 4 11 0xffffffff81218000 3e2f opensolaris.ko > > 5 3 0xffffffff8121c000 3db0 cyclic.ko > > 6 9 0xffffffff81220000 13af4b dtrace.ko > > 7 1 0xffffffff8135b000 fce0 systrace.ko > > 8 1 0xffffffff8136b000 4128 sdt.ko > > 9 1 0xffffffff81370000 44b8 lockstat.ko > > 10 1 0xffffffff81375000 b94e fasttrap.ko > > 11 1 0xffffffff81381000 61ab fbt.ko > > 12 1 0xffffffff81388000 4a67 dtnfsclient.ko > > 13 1 0xffffffff8138d000 4118 dtmalloc.ko > > [root@freebsd9 ~]# > > > > [root@freebsd9 ~]# cat d.d > > vfs:namecache:enter:done > > { > > > > @distribution =3D quantize(strlen((string)arg1)); > > } > > [root@freebsd9 ~]# dtrace -s d.d > > dtrace: script 'd.d' matched 1 probe > > ^C > > > > > > value ------------- Distribution ------------- count > > 2 | 0 > > 4 |@@@@@@@ 1 > > 8 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5 > > 16 | 0 > > > > > > >=20 > The Ruby port doesn't have DTrace support, but the PostgreSQL port has = a DTrace option (only the latest postgresql port). >=20 > Regards, > -- > Rui Paulo >=20 >=20 >=20 >=20 >=20 > --=20 > the sun shines for all >=20 > http://blog.l1x.me > Use the link below to report this message as spam. > https://lavabit.com/apps/teacher?sig=3D1414285&key=3D2325204208 Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 20:59: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 09DE91065673 for ; Mon, 18 Oct 2010 20:59:19 +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 BB5428FC2E for ; Mon, 18 Oct 2010 20:59:18 +0000 (UTC) Received: by gwb20 with SMTP id 20so782920gwb.13 for ; Mon, 18 Oct 2010 13:59:18 -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=g8uK5nNtzGCWoPUwNqd+UlX1L9nwYSwiK6Sy8psSg94=; b=dXLTGpQ7qri4zHdjuZaTKLY1IngZzkBHP6K4XgyaunzuB1phZlZ3DHLfKgU2ac9PB6 ff6eJfw6qBp/Iq3aVkY+POy8U9+9D/Iu/aQDqo4+2wQTsZkA3gWarLJ/9z0VgRuq7ydd 4WqxSZhdqv6kN5fNLCJuNlTAS2+4wSvHqYlvU= 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=GdE/hCvR9mhMAHtUyCrjAGeUABYqkXIAi0NpeNmhCKTRsSYfQ3blUAIj5v3Ybkxsob yxUEOV//vHNk8q400su3p4m/5NZ9m9kbiIZKnxApcAvI+ZphnuCiXYuid1xnH2M3TZGg vslxyaLb7aB9GFJXCePOVqSPPJ2GxTozuz8rc= MIME-Version: 1.0 Received: by 10.42.137.195 with SMTP id z3mr3461533ict.152.1287435557743; Mon, 18 Oct 2010 13:59:17 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.142.76 with HTTP; Mon, 18 Oct 2010 13:59:17 -0700 (PDT) Date: Mon, 18 Oct 2010 13:59:17 -0700 X-Google-Sender-Auth: z0g8mVg6XMxINOjADyaVPfTvJ3U Message-ID: From: mdf@FreeBSD.org To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: uma_zfree(NULL) is 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: Mon, 18 Oct 2010 20:59:19 -0000 There's explicit protection for free(NULL, M_FOO), but uma_zfree(zone, NULL) will put NULL in the local bucket and then probably return it later from a uma_zalloc call. Obviously it's not a good idea to call uma_zfree(9) on NULL, but in this case it's an easy mistake to make when e.g. converting a set of malloc(9)/free(9) uses into uma(9). So is the "right" thing to allow a uma_zfree(NULL) and silently succeed, like for free(9)? That would be my guess, but I'm open to alternatives. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 21: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 A489F1065672; Mon, 18 Oct 2010 21:01:35 +0000 (UTC) (envelope-from giovanni.trematerra@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 DB5AF8FC15; Mon, 18 Oct 2010 21:01:34 +0000 (UTC) Received: by wyb38 with SMTP id 38so1745184wyb.13 for ; Mon, 18 Oct 2010 14:01:33 -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=Ed2N+BziV1Jpgr5HR3EZIwEFcoI+wA7N46T2tDQ7J/I=; b=Qcvr5wbl3uDS8qUyNao19IrE6QCHMoSWcz7Gri2is2KiFR+eoqEMdU9bqBjN27/stA UPzw/GfTdJy8WMBYhXDsG6RHLSG8D9uGS85js66E9i0lH2Gok7BWuxobswNu510P7DBX mi4ES7aAx5R3Np58GgGLqhZUzMO8BjoP1i5aQ= 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=LNDco2X/bYbLCpnWP8PhsD+5GUuuKL1IBoVEa6xqZWdhGaFrnk7cFzjud/QE2Nnwbs 6tfFhi7BXx5/j99cytU2IKqvszpoh3aYNVy9b4+WYR6w0mQhiM1rIPLb6mWfe/ugOL/5 F6ImYMb71GH9idGlTEDS81gqlVqZrhY4bGxQU= MIME-Version: 1.0 Received: by 10.227.128.7 with SMTP id i7mr1415905wbs.165.1287435693667; Mon, 18 Oct 2010 14:01:33 -0700 (PDT) Sender: giovanni.trematerra@gmail.com Received: by 10.227.144.203 with HTTP; Mon, 18 Oct 2010 14:01:33 -0700 (PDT) In-Reply-To: <4CBC5719.1020807@freebsd.org> References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> <4CBC5719.1020807@freebsd.org> Date: Mon, 18 Oct 2010 23:01:33 +0200 X-Google-Sender-Auth: sF5rgwovGJOPCPc61PIELScdm2Y Message-ID: From: Giovanni Trematerra To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system 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, 18 Oct 2010 21:01:35 -0000 On Mon, Oct 18, 2010 at 4:18 PM, Andriy Gapon wrote: > on 18/10/2010 16:40 Giovanni Trematerra said the following: >> On Mon, Oct 18, 2010 at 8:40 AM, Andriy Gapon wrote: >>> on 23/09/2010 21:25 Andriy Gapon said the following: >>>> >>>> Jeff, >>>> >>>> just for the kicks I tried to emulate a machine with 64 logical CPUs u= sing >>>> qemu-devel port: >>>> qemu-system-x86_64 -smp sockets=3D4,cores=3D8,threads=3D2 ... >>>> >>>> It seems that FreeBSD agreed to recognize only first 32 CPUs, but it p= aniced anyway. >>>> >>>> Here's a backtrace: >>>> #34 0xffffffff804fe7f5 in zone_alloc_item (zone=3D0xffffffff80be1554, >>>> udata=3D0xffffffff80be1550, flags=3D1924) at /usr/src/sys/vm/uma_core.= c:2506 >>>> #35 0xffffffff804ff35d in hash_alloc (hash=3D0xffffff001ffdb030) at >>>> /usr/src/sys/vm/uma_core.c:483 >>>> #36 0xffffffff804ff642 in keg_ctor (mem=3DVariable "mem" is not availa= ble. >>>> ) at /usr/src/sys/vm/uma_core.c:1396 >>>> #37 0xffffffff804fe91b in zone_alloc_item (zone=3D0xffffffff80a1f300, >>>> udata=3D0xffffffff80be1b60, flags=3D2) at /usr/src/sys/vm/uma_core.c:2= 544 >>>> #38 0xffffffff804ff92e in zone_ctor (mem=3DVariable "mem" is not avail= able. >>>> ) at /usr/src/sys/vm/uma_core.c:1832 >>>> #39 0xffffffff804ffca4 in uma_startup (bootmem=3D0xffffff001ffac000, b= oot_pages=3D48) >>>> at /usr/src/sys/vm/uma_core.c:1741 >>>> #40 0xffffffff80514822 in vm_page_startup (vaddr=3D1844674407157681766= 4) at >>>> /usr/src/sys/vm/vm_page.c:360 >>>> #41 0xffffffff805060c5 in vm_mem_init (dummy=3DVariable "dummy" is not= available. >>>> ) at /usr/src/sys/vm/vm_init.c:118 >>>> #42 0xffffffff803258b9 in mi_startup () at /usr/src/sys/kern/init_main= .c:253 >>>> #43 0xffffffff8017177c in btext () at /usr/src/sys/amd64/amd64/locore.= S:81 >>>> [[[ >>>> Note: >>>> 1. Frame numbers are high because the backtrace is obtained via gdb re= motely >>>> connected to qemu and also there is bunch of extra frames from DDB, et= c. >>>> 2. Line numbers in uma_core. won't match those in FreeBSD tree, becaus= e I've doing >>>> some unrelated hacking in the file. >>>> ]]] >>>> >>>> The problem seems to be with creation of "UMA Zones" zone and keg. >>>> Because of the large number of processors, size argument in the follow= ing snippet >>>> is set to a value of 4480: >>>> >>>> args.name =3D "UMA Zones"; >>>> args.size =3D sizeof(struct uma_zone) + >>>> =A0 =A0 (sizeof(struct uma_cache) * (mp_maxid + 1)); >>>> >>>> Because of this, keg_ctor() calls keg_large_init(): >>>> >>>> else if ((keg->uk_size+UMA_FRITM_SZ) > >>>> =A0 =A0 (UMA_SLAB_SIZE - sizeof(struct uma_slab))) >>>> =A0 =A0 =A0 =A0 keg_large_init(keg); >>>> else >>>> =A0 =A0 =A0 =A0 keg_small_init(keg); >>>> >>>> keg_large_init sets UMA_ZONE_OFFPAGE and UMA_ZONE_HASH flags for this = keg. >>>> This leads to hash_alloc() being invoked from keg_ctor(): >>>> >>>> if (keg->uk_flags & UMA_ZONE_HASH) >>>> =A0 =A0 =A0 =A0 hash_alloc(&keg->uk_hash); >>>> >>>> But the problem is that "UMA Hash" zone is not created yet and thus th= e call leads >>>> to the panic. =A0"UMA Hash" zone is the last of system zones created. >>>> >>>> Not sure what the proper fix here could/should be. >>>> Would it work to simply not set UMA_ZONE_HASH flag when UMA_ZFLAG_INTE= RNAL is set? >>>> >>>> >>>> And some final calculations. >>>> On the test system sizeof(struct uma_cache) is 128 bytes and (mp_maxid= + 1) is 32, >>>> so it's already UMA_SLAB_SIZE =3D PAGE_SIZE =3D 4096. >>>> >>> >>> Here is a simple solution that seems to work: >>> http://people.freebsd.org/~avg/uma-many-cpus.diff >>> Not sure if it's the best we can do. >>> >> >> I don't know if it makes sense I only want to raise a flag. >> Is it safe to call kmem_malloc() before bucket_init() during >> uma_startup() to reserve room for CPU caches? > > Hmm, not sure what exactly you mean. Sorry, nevermind > >> Reading the top uma_int.h comment, it seems that the best way to >> handle this issue >> would be to implement and allow for dynamic slab sizes. > > Again, not sure if I follow you, I don't see relation between per-cpu cac= hes and > dynamic slab size. Your patch seems just a work around about initial slab size where the keg is backed. Having dynamic slab sizes would allow to have the keg backed on a larger sl= ab without going OFFPAGE. -- Giovanni Trematerra From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 21:33: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 687B5106564A for ; Mon, 18 Oct 2010 21:33:45 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 3BAB88FC0C for ; Mon, 18 Oct 2010 21:33:44 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id 81AB011B9F3; Mon, 18 Oct 2010 16:33:44 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id L3W017WX1262; Mon, 18 Oct 2010 16:33:44 -0500 References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Message-Id: Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Mon, 18 Oct 2010 22:33:41 +0100 To: =?iso-8859-1?Q?Istv=E1n?= X-Mailer: Apple Mail (2.1081) Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 21:33:45 -0000 On 18 Oct 2010, at 22:30, Istv=E1n wrote: > what should I do with the Makefile exactly? I can't see any dtrace = related information in it. Each software package has it's way of enabling DTrace during the build. = Check the postgres90-server port for an example on how to add DTrace = support to a port. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 21:30: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 2A4F3106564A; Mon, 18 Oct 2010 21:30:03 +0000 (UTC) (envelope-from leccine@gmail.com) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx1.freebsd.org (Postfix) with ESMTP id CC1CE8FC08; Mon, 18 Oct 2010 21:30:02 +0000 (UTC) Received: by iwn10 with SMTP id 10so1839478iwn.17 for ; Mon, 18 Oct 2010 14:30:02 -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=AdUq2+kfp10Zo88iHlcFeI5UnyRNjrxbpleHswAsWso=; b=REadjPqA7X+UJf3XE3BaONtvTq9rnrnt9fa+s0bHmURX3CBFUWdvQ3WmRQ8XU4Yi2p VtlcwWx8D/z3nzvZr1yrQwZ9i98jdGHnOMJ9EBulRERUbWQRbVATACD3XVnmhda+2aLu 9m1u69sITuFI8Zba16YxqClAcZ6i0aEIR6CFE= 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=Ggqa1xLyxa5yxI72kpFAC2AWRxontokqxW+//zV3jIRkfMnhp+yhW3tVIaRMzkLDZM JGFrJCzA/vXmT8h5yIb4f81ukTjEefkWqFzCUA3SZyvnpPCqO3lNVW4N20nGTMj+j7z6 U29WW8uXo0AThQ1t9GOGvcJ9vu/4H2hfjwXys= MIME-Version: 1.0 Received: by 10.231.36.8 with SMTP id r8mr3800392ibd.128.1287437401912; Mon, 18 Oct 2010 14:30:01 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Mon, 18 Oct 2010 14:30:01 -0700 (PDT) In-Reply-To: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> Date: Mon, 18 Oct 2010 22:30:01 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: Rui Paulo X-Mailman-Approved-At: Mon, 18 Oct 2010 21:40:10 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 21:30:03 -0000 what should I do with the Makefile exactly? I can't see any dtrace related information in it. I. > > > > Do you know why Ruby has no dtrace bindings on Freebsd? > > You need to change the port Makefile to enable DTrace. > > > From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 21:40: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 EB55A106566C for ; Mon, 18 Oct 2010 21:40:10 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id BD4F48FC17 for ; Mon, 18 Oct 2010 21:40:10 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id 34E6911B799; Mon, 18 Oct 2010 16:40:10 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id FQ33BF0OT2WD; Mon, 18 Oct 2010 16:40:10 -0500 References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Message-Id: Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Mon, 18 Oct 2010 22:40:07 +0100 To: =?iso-8859-1?Q?Istv=E1n?= X-Mailer: Apple Mail (2.1081) Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 21:40:11 -0000 On 18 Oct 2010, at 22:37, Istv=E1n wrote: > So there is no out of the box solution for FreeBSD to use DTrace for = any userland app. What have I been saying ? Userland DTrace support works on FreeBSD 9.0, = but I don't think you understand what userland DTrace support requires. = For PostgreSQL and Ruby you need to re-compile the software with DTrace = support enabled. This is the same on Solaris. >=20 > Is there somebody in the FreeBSD team actively working on this? >=20 >=20 > I. >=20 >=20 > On Mon, Oct 18, 2010 at 10:33 PM, Rui Paulo = wrote: >=20 > On 18 Oct 2010, at 22:30, Istv=E1n wrote: >=20 > > what should I do with the Makefile exactly? I can't see any dtrace = related information in it. >=20 > Each software package has it's way of enabling DTrace during the = build. Check the postgres90-server port for an example on how to add = DTrace support to a port. >=20 > Regards, > -- > Rui Paulo >=20 >=20 >=20 >=20 >=20 > --=20 > the sun shines for all >=20 > http://blog.l1x.me > Use the link below to report this message as spam. > https://lavabit.com/apps/teacher?sig=3D1414423&key=3D2849872830 Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 21:37: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 24DBD106566B; Mon, 18 Oct 2010 21:37:01 +0000 (UTC) (envelope-from leccine@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 CBBB98FC1B; Mon, 18 Oct 2010 21:37:00 +0000 (UTC) Received: by iwn36 with SMTP id 36so135016iwn.13 for ; Mon, 18 Oct 2010 14:37:00 -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=Ig4JEqgVurjdjlipxoDs2HgBG5pt6vQgbJdaOd5wAIE=; b=ERNTWkpOSWDP8JaakoghQ+c+iQUCWFHVcrg8v6ks41YxPT5bvKBMu1rzr8o3XvP0FC C54HQcAxn8L0OEDiuGvhQjih3WjHUedc2HZ0tV1B23daJNMnDuVqC3z4siYjKTeeqLg2 s47Y7kevpE2ZQ2VPUIsh5eHvPz0jo1LZPT6WE= 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=ktD0IOXbzxwjXmTGu5XMcuw2ziiIBw891t7RvwSr3DlTiHxHBiQFH3wgXp0TE6r/+P dfUl8srP4iaGxkE0FLSz7NHUaFz2yqRdjW7OROWEvRgIWFc1PlVrXQKlT21Fp3tuChHD 1DzdSqCzNwunO8VpHSoPNU/pBPpqPkPXIFZaA= MIME-Version: 1.0 Received: by 10.231.79.77 with SMTP id o13mr3991847ibk.36.1287437820143; Mon, 18 Oct 2010 14:37:00 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Mon, 18 Oct 2010 14:37:00 -0700 (PDT) In-Reply-To: References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> Date: Mon, 18 Oct 2010 22:37:00 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: Rui Paulo X-Mailman-Approved-At: Mon, 18 Oct 2010 21:46:56 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 21:37:01 -0000 So there is no out of the box solution for FreeBSD to use DTrace for any userland app. Is there somebody in the FreeBSD team actively working on this? I. On Mon, Oct 18, 2010 at 10:33 PM, Rui Paulo wrote: > > On 18 Oct 2010, at 22:30, Istv=C3=A1n wrote: > > > what should I do with the Makefile exactly? I can't see any dtrace > related information in it. > > Each software package has it's way of enabling DTrace during the build. > Check the postgres90-server port for an example on how to add DTrace supp= ort > to a port. > > Regards, > -- > Rui Paulo > > > --=20 the sun shines for all http://blog.l1x.me From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 21:49: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 91BB31065673; Mon, 18 Oct 2010 21:49:00 +0000 (UTC) (envelope-from leccine@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 4191C8FC16; Mon, 18 Oct 2010 21:49:00 +0000 (UTC) Received: by iwn36 with SMTP id 36so145756iwn.13 for ; Mon, 18 Oct 2010 14:48:59 -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=jCYaoMQ5GRAoAJ1I+zyLgHNRTW/PbXL6zw3zb0hpgGU=; b=b5yDF/q3eG9HEPsgB0QrYlyuA7kiHOISu8cpAMJQyuK13FVQUgdEXSz9dWFnULkEv8 u1XRop1HHW13LsND5zhCQuaI9/rGQmmS0jJ1hhxWLb13VevjjhRn/8J+tv8X4Ct2bu6W pXCNuQzoIgOEFGIJ0yKA6f47jgxY/ikRirQlI= 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=BaYVf7PJFvOGlUJppo0x8BWTnSAFexgv0Bt/fcq50mb99uovx7gTN2UzcOgMU1PaS2 UbeESICMAlrniQzC1AtHAl2bZXEdDnM3M2bORnkBWHhEreN5p6rqTssrU9U2GP8rISjp JDtWIZVB1yNTZmBoJlMSUrQAUWYii4NkoFrfg= MIME-Version: 1.0 Received: by 10.231.190.139 with SMTP id di11mr2039445ibb.180.1287438538817; Mon, 18 Oct 2010 14:48:58 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Mon, 18 Oct 2010 14:48:58 -0700 (PDT) In-Reply-To: References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> Date: Mon, 18 Oct 2010 22:48:58 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: Rui Paulo X-Mailman-Approved-At: Mon, 18 Oct 2010 21:52:42 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 21:49:00 -0000 I perfectly understand what you are saying and I have been DTracing on Solaris many times. Only problem here is that you don't get my point, but I try to explain it o= n the level you can get it. [root@freebsd9 /usr/ports/databases/postgresql90-server]# grep -iA3 WITH_DTRACE Makefile . if defined(WITH_DTRACE) CONFIGURE_ARGS+=3D--enable-dtrace LDFLAGS+=3D-lelf . endif [root@freebsd9 /usr/ports/databases/postgresql90-server]# grep -i dtrace /var/db/ports/postgresql90/options WITH_DTRACE=3Dtrue [root@freebsd9 /usr/ports/databases/postgresql90-server]# make install clea= n What other dependency might cause the lack of DTrace bindings for postgres90-server? If you don't get my point at this stage then we don't have anything to talk about, and I don't understand how can the FreeBSD project use a tool like you. :) Hope I make it clear what is not working and what must work. I. On Mon, Oct 18, 2010 at 10:40 PM, Rui Paulo wrote: > > On 18 Oct 2010, at 22:37, Istv=C3=A1n wrote: > > > So there is no out of the box solution for FreeBSD to use DTrace for an= y > userland app. > > What have I been saying ? Userland DTrace support works on FreeBSD 9.0, b= ut > I don't think you understand what userland DTrace support requires. For > PostgreSQL and Ruby you need to re-compile the software with DTrace suppo= rt > enabled. This is the same on Solaris. > > > > > Is there somebody in the FreeBSD team actively working on this? > > > > > > I. > > > > > > On Mon, Oct 18, 2010 at 10:33 PM, Rui Paulo wrote: > > > > On 18 Oct 2010, at 22:30, Istv=C3=A1n wrote: > > > > > what should I do with the Makefile exactly? I can't see any dtrace > related information in it. > > > > Each software package has it's way of enabling DTrace during the build. > Check the postgres90-server port for an example on how to add DTrace supp= ort > to a port. > > > > Regards, > > -- > > Rui Paulo > > > > > > > > > > > > -- > > the sun shines for all > > > > http://blog.l1x.me > > Use the link below to report this message as spam. > > https://lavabit.com/apps/teacher?sig=3D1414423&key=3D2849872830 > > Regards, > -- > Rui Paulo > > > --=20 the sun shines for all http://blog.l1x.me From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 22:47: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 50DB21065693 for ; Mon, 18 Oct 2010 22:47:45 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id B66BA8FC1B for ; Mon, 18 Oct 2010 22:47:44 +0000 (UTC) Received: from bel.soho.vwsoft.com (p57A0CBAA.dip.t-dialin.net [87.160.203.170]) by Mail.elbekies.net (Postfix) with ESMTPA id 0D7EF2E037 for ; Tue, 19 Oct 2010 00:31:35 +0200 (CEST) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id A084733C7F; Tue, 19 Oct 2010 00:31:20 +0200 (CEST) Message-ID: <4CBCCAB8.4090500@vwsoft.com> Date: Tue, 19 Oct 2010 00:31:20 +0200 From: volker@vwsoft.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.12) Gecko/20101007 Thunderbird/3.0.8 MIME-Version: 1.0 To: FreeBSD current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: 0D7EF2E037.AAF6E X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com MailScanner-NULL-Check: 1288045900.79597@MvX6DweFtewBkI3lqtTzdQ Cc: Andriy Gapon Subject: c 213323 breaks Sony Vaio P11Z w/o acpi 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, 18 Oct 2010 22:47:45 -0000 Hi Andriy & list! Since rev 213323 my Sony Vaio P11Z was unable to boot up. It broke with a divide by zero in topo_probe_0x4 at line 289 as cpu_logical is 0. The cpu is an Intel Atom Z520 (single core). System doesn't boot at all w/ acpi enabled. The following patch made me to boot up again. Index: i386/i386/mp_machdep.c =================================================================== --- i386/i386/mp_machdep.c (revision 213936) +++ i386/i386/mp_machdep.c (working copy) @@ -286,7 +286,7 @@ cpu_logical++; } - cpu_cores /= cpu_logical; + cpu_cores /= cpu_logical==0?1:cpu_logical; hyperthreading_cpus = cpu_logical; } ``mptable -grope -verbose`` gives: =============================================================================== MPTable looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 searching extended BIOS @ 0x000e0000 groping memory @ 0x00080000 groping memory @ 0x00090000 MP FPS NOT found, suggest trying -grope option!!! so it's not of much help. relevant part of dmesg looks like: FreeBSD 9.0-CURRENT #3 r213904:213936M: Sat Oct 16 22:50:53 UTC 2010 root@juno.sz.vwsoft.com:/usr/obj/usr/src/sys/JUNO i386 CPU: Intel(R) Atom(TM) CPU Z520 @ 1.33GHz (1333.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbff Features2=0x40c3bd AMD Features=0x100000 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2081042432 (1984 MB) I'm wondering if there's a better way to fix that problem or if someone wants to commit my fix. Thanks, Volker From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 22:48:17 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 E8F5A1065670 for ; Mon, 18 Oct 2010 22:48: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 8E2038FC14 for ; Mon, 18 Oct 2010 22:48:16 +0000 (UTC) Received: by iwn36 with SMTP id 36so196743iwn.13 for ; Mon, 18 Oct 2010 15: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:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bOZUtidEzkDn6hSd9EnuL4o5/DAaxSXNlcTyQvrfdk4=; b=PY4pkGgfAAbjACCdDqGgIT5Guxz5Hj3gmChXjh7TYBOIXhFesEkc5Q3hVvxEULH/05 vF3ItDfLwko2xioYjl/F5zFY1WRUAphBq4rz8FYEsa8veNAbpfTdF+ZwgC7yMVsTMon2 MAyJhsDXGFR+ob2SgEHyo/5LtjfJziljFOKmU= 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=u8B1zJIr5WNhXiHuNDxD2oErZi+kEHh/Y0uafRSsdF3VAyYkm9kg6IsLvtIgdz6mqF sPoinLyif5gzEYGfkXdwH8IklDh/x/dTjJyO9OcVf++4Pyyc5UADWxSWN65LzrehTIap 5s06DvUBBzK9rHU3f2OXGRX/MU5hbTuPlEuqk= MIME-Version: 1.0 Received: by 10.231.33.4 with SMTP id f4mr3711316ibd.197.1287442095496; Mon, 18 Oct 2010 15:48:15 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 18 Oct 2010 15:48:15 -0700 (PDT) In-Reply-To: References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> Date: Mon, 18 Oct 2010 15:48:15 -0700 X-Google-Sender-Auth: kk65RMR58h15PfOOhI3S2Ds7ZNk Message-ID: From: Garrett Cooper To: =?ISO-8859-1?B?SXN0duFu?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , Rui Paulo Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 22:48:17 -0000 On Mon, Oct 18, 2010 at 2:48 PM, Istv=E1n wrote: > I perfectly understand what you are saying and I have been DTracing on > Solaris many times. > > Only problem here is that you don't get my point, but I try to explain it= on > the level you can get it. > > > [root@freebsd9 /usr/ports/databases/postgresql90-server]# grep -iA3 > WITH_DTRACE Makefile > . =A0if defined(WITH_DTRACE) > CONFIGURE_ARGS+=3D--enable-dtrace > LDFLAGS+=3D-lelf > . =A0endif > > [root@freebsd9 /usr/ports/databases/postgresql90-server]# grep -i dtrace > /var/db/ports/postgresql90/options > WITH_DTRACE=3Dtrue > > [root@freebsd9 /usr/ports/databases/postgresql90-server]# make install cl= ean > > > What other dependency might cause the lack of DTrace bindings for > postgres90-server? > > > If you don't get my point at this stage then we don't have anything to ta= lk > about, and I don't understand how can the FreeBSD project use a tool like > you. :) > > > Hope I make it clear what is not working and what must work. > > I. > > > > > > On Mon, Oct 18, 2010 at 10:40 PM, Rui Paulo wrote: > >> >> On 18 Oct 2010, at 22:37, Istv=E1n wrote: >> >> > So there is no out of the box solution for FreeBSD to use DTrace for a= ny >> userland app. >> >> What have I been saying ? Userland DTrace support works on FreeBSD 9.0, = but >> I don't think you understand what userland DTrace support requires. For >> PostgreSQL and Ruby you need to re-compile the software with DTrace supp= ort >> enabled. This is the same on Solaris. >> >> > >> > Is there somebody in the FreeBSD team actively working on this? >> > >> > >> > I. >> > >> > >> > On Mon, Oct 18, 2010 at 10:33 PM, Rui Paulo wrote= : >> > >> > On 18 Oct 2010, at 22:30, Istv=E1n wrote: >> > >> > > what should I do with the Makefile exactly? I can't see any dtrace >> related information in it. >> > >> > Each software package has it's way of enabling DTrace during the build= . >> Check the postgres90-server port for an example on how to add DTrace sup= port >> to a port. 1. I'd do clean install, not install clean to start from a consistent s= tate. 2. What do the autoconf logs say about dtrace support being enabled (make clean configure will provide that data with the least number of cycles spent)? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 22:56:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8562A1065670; Mon, 18 Oct 2010 22:56:14 +0000 (UTC) Date: Mon, 18 Oct 2010 22:56:14 +0000 From: Alexander Best To: David Xu Message-ID: <20101018225614.GA77926@freebsd.org> References: <4C961009.6080609@freebsd.org> <20100920141023.GA27509@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100920141023.GA27509@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: sysctl -a is slow 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, 18 Oct 2010 22:56:14 -0000 On Mon Sep 20 10, Alexander Best wrote: > On Sun Sep 19 10, David Xu wrote: > > just typed sysctl -a on keyboard, and found it is slow, sometimes > > it has been stuck for a few seconds, further studied,I found it is > > stucked at sysctl kern.geom: > > > > %/usr/bin/time sysctl -a kern.geom > > kern.geom.collectstats: 1 > > kern.geom.debugflags: 0 > > kern.geom.label.debug: 0 > > kern.geom.label.ext2fs.enable: 1 > > kern.geom.label.iso9660.enable: 1 > > kern.geom.label.msdosfs.enable: 1 > > kern.geom.label.ntfs.enable: 1 > > kern.geom.label.reiserfs.enable: 1 > > kern.geom.label.ufs.enable: 1 > > kern.geom.label.ufsid.enable: 1 > > kern.geom.label.gptid.enable: 1 > > kern.geom.label.gpt.enable: 1 > > 2.01 real 0.00 user 0.00 sys > > > > it seems it needs more than 2 seconds to complete. > > have you had a look at the bug database? just noticed a few sysctl reports > there which describe issues similar to yours. these are the results from the following script: #!/bin/sh TESTS="kern vm vfs net debug hw user p1003_1b compat security dev" for i in $TESTS; do echo $i:; time sysctl $i > /dev/null; done kern: 0,09 real 0,00 user 0,07 sys vm: 0,05 real 0,00 user 0,05 sys vfs: 0,00 real 0,00 user 0,00 sys net: 0,01 real 0,01 user 0,00 sys debug: 0,36 real 0,00 user 0,35 sys hw: 0,01 real 0,00 user 0,00 sys user: 0,00 real 0,00 user 0,00 sys p1003_1b: 0,00 real 0,00 user 0,00 sys compat: 0,00 real 0,00 user 0,00 sys security: 0,00 real 0,00 user 0,00 sys dev: 0,04 real 0,00 user 0,04 sys ...that's on a very recent HEAD. cheers. alex ps: debug.witness.fullgraph is producing quite a lot of output. also debug.witness.badstacks. i think most of cpu time can be blamed on those two options. also: otaku% /usr/bin/time sysctl -a kern.geom kern.geom.debugflags: 0 kern.geom.collectstats: 1 kern.geom.label.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.gpt.enable: 1 kern.geom.label.gptid.enable: 1 0,01 real 0,00 user 0,00 sys however i ran the test app from PR 134231 and 8.1-PRELEASE (freefall) performed far worse than 7.3-STABLE (hub). 8.1 (freefall): 0.037u 28.304s 0:28.35 99.9% 5+175k 0+0io 0pf+0w 7.3 (hub): 0.007u 8.991s 0:08.99 100.0% 5+175k 0+0io 0pf+0w > > #134231 e.g. > > cheers. > alex > > > > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 23:05: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 018E71065670; Mon, 18 Oct 2010 23:05:12 +0000 (UTC) (envelope-from leccine@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 91F4E8FC16; Mon, 18 Oct 2010 23:05:11 +0000 (UTC) Received: by iwn36 with SMTP id 36so209868iwn.13 for ; Mon, 18 Oct 2010 16:05: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; bh=pmnA8NJ0z5l/NLtclYLASlOxSjBP7S82VsTy2UgE7SQ=; b=FT2+p41bRnGAkMb0TT97hBhYKp/nbzT0EwWck9xIScXLLLojoa+V+rfgbgkzVjpF/I EG2LYsf0AnRnfds1wcpudUEqxpI5qt3RFFVzowCEVRafFTOhu3ZUCckDWMGpF78JxOGq cggm6oDJXKwL1Em44vnTC+RB+kWrhc3L6nR8Q= 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=Shww+zy06uFT7S24PiN//zq/XDWk9dINZCWMFjemdQBiOf1XqBNipQ4gtSjZxZJdM9 3ghemvDuaWJb46Y8usxTm/zkAsbA2LXtUKNO7OIyiNmD9ORNbmqO3KdUU/XL4xPxLawH X/Y5w7CqX2b0w0GhB1ZXLhnSMAL4K6TiMUTMI= MIME-Version: 1.0 Received: by 10.42.169.5 with SMTP id z5mr470151icy.172.1287443110869; Mon, 18 Oct 2010 16:05:10 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Mon, 18 Oct 2010 16:05:10 -0700 (PDT) In-Reply-To: References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> Date: Tue, 19 Oct 2010 00:05:10 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: Garrett Cooper X-Mailman-Approved-At: Mon, 18 Oct 2010 23:43:57 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , Rui Paulo Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 18 Oct 2010 23:05:12 -0000 Hey Garrett, thanks for coming back to me. 1. I had make clean before I did make install clean. 2. $ ./configure --with-libraries=3D/usr/local/lib --with-includes=3D/usr/local/include --enable-thread-safety --with-openssl --enable-dtrace --with-pam --enable-nls --prefix=3D/usr/local --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ --build=3Damd64-portbld-freebsd9.0 uname -v =3D FreeBSD 9.0-CURRENT #0: Fri Oct 8 21:09:20 UTC 2010 root@freebsd9:/usr/obj/usr/src/sys/DTRACE configure:2820: checking for dtrace configure:2836: found /usr/sbin/dtrace configure:2847: result: dtrace | #define ENABLE_DTRACE 1 ac_cv_prog_DTRACE=3Ddtrace DTRACE=3D'dtrace' DTRACEFLAGS=3D'' configure_args=3D' '\''--with-libraries=3D/usr/local/lib'\'' '\''--with-includes=3D/usr/local/include'\'' '\''--enable-thread-safety'\'' '\''--with-openssl'\'' '\''--enable-dtrace'\'' '\''--with-pam'\'' '\''--enable-nls'\'' '\''--prefix=3D/usr/local'\'' '\''--mandir=3D/usr/local/man'\'' '\''--infodir=3D/usr/local/info/'\'' '\''--build=3Damd64-portbld-freebsd9.0'\'' '\''build_alias=3Damd64-portbld-freebsd9.0'\'' '\''CC=3Dcc'\'' '\''CFLAGS= =3D-O2 -pipe -fno-omit-frame-pointer -fno-strict-aliasing'\'' '\''LDFLAGS=3D -L/usr/local/lib -rpath=3D/usr/lib:/usr/local/lib -lelf -L/usr/local/lib'\'= ' '\''CPPFLAGS=3D-I/usr/local/include'\''' enable_dtrace=3D'yes' #define ENABLE_DTRACE 1 The server is running: [root@freebsd9/usr/ports/databases/postgresql90-server/work/postgresql-9.0.= 1]# ps aux | grep post pgsql 86977 0.0 1.0 61992 9984 ?? Ss 10:01PM 0:00.97 /usr/local/bin/postgres -D /usr/local/pgsql/data pgsql 86979 0.0 1.0 61992 10004 ?? Rs 10:01PM 0:06.48 postgres: writer process (postgres) pgsql 86980 0.0 1.0 61992 10004 ?? Rs 10:01PM 0:03.44 postgres: wal writer process (postgres) pgsql 86981 0.0 1.0 61992 10880 ?? Ss 10:01PM 0:00.99 postgres: autovacuum launcher process (postgres) pgsql 86982 0.0 0.8 24896 8056 ?? Ss 10:01PM 0:00.56 postgres: stats collector process (postgres) According to the manual: http://www.postgresql.org/docs/8.2/static/dynamic-trace.html [root@freebsd9/usr/ports/databases/postgresql90-server/work/postgresql-9.0.= 1]# ls src/include/pg_trace.h This file is there. But I can't see the probes in the list: dtrace -l | grep -i postgres Further info: [root@freebsd9 ~]# /usr/local/etc/rc.d/postgresql restart dtrace DOF postgres: DTrace ioctl failed for DOF at 0x801c35000: Invalid argument Any time I would like to start dtrace on the servers pid the daemon is crashing wo/ any log. I. On Mon, Oct 18, 2010 at 11:48 PM, Garrett Cooper wrote= : > On Mon, Oct 18, 2010 at 2:48 PM, Istv=C3=A1n wrote: > > I perfectly understand what you are saying and I have been DTracing on > > Solaris many times. > > > > Only problem here is that you don't get my point, but I try to explain = it > on > > the level you can get it. > > > > > > [root@freebsd9 /usr/ports/databases/postgresql90-server]# grep -iA3 > > WITH_DTRACE Makefile > > . if defined(WITH_DTRACE) > > CONFIGURE_ARGS+=3D--enable-dtrace > > LDFLAGS+=3D-lelf > > . endif > > > > [root@freebsd9 /usr/ports/databases/postgresql90-server]# grep -i dtrac= e > > /var/db/ports/postgresql90/options > > WITH_DTRACE=3Dtrue > > > > [root@freebsd9 /usr/ports/databases/postgresql90-server]# make install > clean > > > > > > What other dependency might cause the lack of DTrace bindings for > > postgres90-server? > > > > > > If you don't get my point at this stage then we don't have anything to > talk > > about, and I don't understand how can the FreeBSD project use a tool li= ke > > you. :) > > > > > > Hope I make it clear what is not working and what must work. > > > > I. > > > > > > > > > > > > On Mon, Oct 18, 2010 at 10:40 PM, Rui Paulo wrote: > > > >> > >> On 18 Oct 2010, at 22:37, Istv=C3=A1n wrote: > >> > >> > So there is no out of the box solution for FreeBSD to use DTrace for > any > >> userland app. > >> > >> What have I been saying ? Userland DTrace support works on FreeBSD 9.0= , > but > >> I don't think you understand what userland DTrace support requires. Fo= r > >> PostgreSQL and Ruby you need to re-compile the software with DTrace > support > >> enabled. This is the same on Solaris. > >> > >> > > >> > Is there somebody in the FreeBSD team actively working on this? > >> > > >> > > >> > I. > >> > > >> > > >> > On Mon, Oct 18, 2010 at 10:33 PM, Rui Paulo > wrote: > >> > > >> > On 18 Oct 2010, at 22:30, Istv=C3=A1n wrote: > >> > > >> > > what should I do with the Makefile exactly? I can't see any dtrace > >> related information in it. > >> > > >> > Each software package has it's way of enabling DTrace during the > build. > >> Check the postgres90-server port for an example on how to add DTrace > support > >> to a port. > > 1. I'd do clean install, not install clean to start from a consistent > state. > 2. What do the autoconf logs say about dtrace support being > enabled (make clean configure will provide that data with the least > number of cycles spent)? > Thanks, > -Garrett > --=20 the sun shines for all http://blog.l1x.me From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 23:50: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 8CF40106567A for ; Mon, 18 Oct 2010 23:50:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3666C8FC08 for ; Mon, 18 Oct 2010 23:50:38 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 7464CA7DBEC; Tue, 19 Oct 2010 07:50:35 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id 8HS87Wp2m7iK; Tue, 19 Oct 2010 07:50:29 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1438FA7DBE2; Tue, 19 Oct 2010 07:50:26 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=VmIDtGXfo6WpGlS/SksaeqWFGWaXH7XpMIzpWIVQOleFmrMPVvVCOIruvN1RjuMCC /Nk6okgto+NrOOCfG20jg== Message-ID: <4CBCDD3A.9070404@delphij.net> Date: Mon, 18 Oct 2010 16:50:18 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20100920 Thunderbird/3.0.8 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: FreeBSD Current , Marcel Moolenaar X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: [zfs] Mounting from (...) failed with error 19 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 23:50:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, With latest kernel I got: Mounting from (...) failed with error 19 On boot. The system is using pure ZFS setup. It seems that 19 means ENODEV but according to the dmesg the device do exist. At the beginning I thought it was because that zpool.cache was destroyed somehow, so I have tried to use LiveFS and mkdir /boot/zfs, hostid start, zpool import -f, mount pool/root, and copy /boot/zfs/zpool.cache over it but unluckily this failed. Escaping to boot loader prompt, and load old kernel, old opensolaris.ko, old zfs.ko doesn't work. However, using LiveFS to restore the whole kernel back to previous version fixed the problem (mv kernel kernel.bad && mv kernel.old kernel). Looking at the change log, I find that there is no intrusive changes to ZFS itself but there are some changes against mountroot logic, but I'm not convinced since loading kernel.old/kernel at boot loader should have override this :-/ Any idea? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMvN06AAoJEATO+BI/yjfBkuAH/0437KphO+sPWv+M0UNEW/Zi FO6c6TErSl4cZiTyGUSUjjDMAM71E+OXMin5ELjSDQbB05Dd96uLUKiCObEYdz1o hovpjbGy+ZNIeIBUvrCvdg14o8m9WipWGwVZDXEdHY9GOjcEJdWcmcL6xpsLMN7F BadVL1c/FunVXjeRwhDwhO7YmFgzfE6rBJjbtPflCj2PeKPsyk7he0hL3iNyBbAx 5IvwHvd0bu3EkGk9slc9ogahJjOdq3SRPiiSnkKIZyRjCeeC+ptSvI9ri1evIpIX EFoY1oEmNAkmtIBiVxNlRPeJ2kWQxDCkqWsDUgpwXrKKS5FL7cKssb9PYog/mVE= =Buo+ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 00:11:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 06A111065679; Tue, 19 Oct 2010 00:11:31 +0000 (UTC) Date: Tue, 19 Oct 2010 00:11:31 +0000 From: Alexander Best To: Dan Nelson Message-ID: <20101019001130.GA91234@freebsd.org> References: <20101018174331.GA80017@sandvine.com> <20101018181142.GC5644@dan.emsphone.com> <20101018193010.GA88783@sandvine.com> <20101018193916.GD5644@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101018193916.GD5644@dan.emsphone.com> Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 19 Oct 2010 00:11:31 -0000 On Mon Oct 18 10, Dan Nelson wrote: > In the last episode (Oct 18), Ed Maste said: > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > cp_time value essentially won't roll over (at 1 billion increments per > > > second it will roll over in 500 years; we currently increment 133 times > > > per second, I think). If the value can be calculated accurately, it > > > should be printed. > > > > Well, it won't roll over, but it's still different from all following > > lines (in that it effectively shows user/system/idle CPU usage since boot > > on the first line, and a snapshot over the last interval from then on). I > > think it's still better to avoid printing it in that case. > > It is documented to do that, though, and could affect scripts that expect to > see average-since-boot info on the first line. iostat does the same, btw. > > > On a related note I'm not sure if it makes sense to have the same > > behaviour for the first line when an interval is set as when it is > > invoked with no interval. don't know if you have seen this, but this behavior has been documented in a PR back in 2001: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/30360 cheers. alex > > -- > Dan Nelson > dnelson@allantgroup.com -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 00:13:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 027A01065672; Tue, 19 Oct 2010 00:13:21 +0000 (UTC) Date: Tue, 19 Oct 2010 00:13:20 +0000 From: Alexander Best To: Dan Nelson Message-ID: <20101019001320.GB91234@freebsd.org> References: <20101018174331.GA80017@sandvine.com> <20101018181142.GC5644@dan.emsphone.com> <20101018193010.GA88783@sandvine.com> <20101018193916.GD5644@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101018193916.GD5644@dan.emsphone.com> Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 19 Oct 2010 00:13:21 -0000 On Mon Oct 18 10, Dan Nelson wrote: > In the last episode (Oct 18), Ed Maste said: > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > cp_time value essentially won't roll over (at 1 billion increments per > > > second it will roll over in 500 years; we currently increment 133 times > > > per second, I think). If the value can be calculated accurately, it > > > should be printed. > > > > Well, it won't roll over, but it's still different from all following > > lines (in that it effectively shows user/system/idle CPU usage since boot > > on the first line, and a snapshot over the last interval from then on). I > > think it's still better to avoid printing it in that case. > > It is documented to do that, though, and could affect scripts that expect to > see average-since-boot info on the first line. iostat does the same, btw. > > > On a related note I'm not sure if it makes sense to have the same > > behaviour for the first line when an interval is set as when it is > > invoked with no interval. ...also vmstat seems to exist in a few other OSes (linux e.g). maybe they've fixed it already (or the netbsd/openbsd/dragonflybsd folks or apple?). cheers. alex > > -- > Dan Nelson > dnelson@allantgroup.com -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 04:56:34 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 4B5A5106566C for ; Tue, 19 Oct 2010 04:56:34 +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 959488FC0A for ; Tue, 19 Oct 2010 04:56:33 +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 HAA26822; Tue, 19 Oct 2010 07:56:27 +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 1P84FO-0000Nz-PV; Tue, 19 Oct 2010 07:56:26 +0300 Message-ID: <4CBD24FA.8040302@icyb.net.ua> Date: Tue, 19 Oct 2010 07:56: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: volker@vwsoft.com References: <4CBCCAB8.4090500@vwsoft.com> In-Reply-To: <4CBCCAB8.4090500@vwsoft.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: c 213323 breaks Sony Vaio P11Z w/o acpi 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, 19 Oct 2010 04:56:34 -0000 on 19/10/2010 01:31 volker@vwsoft.com said the following: > Hi Andriy & list! > > Since rev 213323 my Sony Vaio P11Z was unable to boot up. It broke with a divide > by zero in topo_probe_0x4 at line 289 as cpu_logical is 0. > > The cpu is an Intel Atom Z520 (single core). System doesn't boot at all w/ acpi > enabled. > > The following patch made me to boot up again. > > Index: i386/i386/mp_machdep.c > =================================================================== > --- i386/i386/mp_machdep.c (revision 213936) > +++ i386/i386/mp_machdep.c (working copy) > @@ -286,7 +286,7 @@ > cpu_logical++; > } > > - cpu_cores /= cpu_logical; > + cpu_cores /= cpu_logical==0?1:cpu_logical; > hyperthreading_cpus = cpu_logical; > } > > ``mptable -grope -verbose`` gives: > =============================================================================== > > MPTable > > looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 > searching CMOS 'top of mem' @ 0x0009f800 (638K) > searching default 'top of mem' @ 0x0009fc00 (639K) > searching BIOS @ 0x000f0000 > searching extended BIOS @ 0x000e0000 > groping memory @ 0x00080000 > groping memory @ 0x00090000 > > MP FPS NOT found, > suggest trying -grope option!!! > > so it's not of much help. > > relevant part of dmesg looks like: > > FreeBSD 9.0-CURRENT #3 r213904:213936M: Sat Oct 16 22:50:53 UTC 2010 > root@juno.sz.vwsoft.com:/usr/obj/usr/src/sys/JUNO i386 > CPU: Intel(R) Atom(TM) CPU Z520 @ 1.33GHz (1333.31-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 > > Features=0xbfe9fbff > > > Features2=0x40c3bd > AMD Features=0x100000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 2081042432 (1984 MB) > > I'm wondering if there's a better way to fix that problem or if someone wants to > commit my fix. Definitely not - it violates style(9). Kidding, of course :-) Could you please download and run the following script and send back output? http://people.freebsd.org/~jkim/cpu_topology-12212009.sh Thank you very much! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 05:19: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 BC6B5106566B for ; Tue, 19 Oct 2010 05:19:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6771E8FC08 for ; Tue, 19 Oct 2010 05:19:11 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward4.mail.yandex.net (Yandex) with ESMTP id C90B56AD88F8; Tue, 19 Oct 2010 09:03:56 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287464636; bh=wnDqq8RX+HHDXXK/mor6mriw6FzYiBe7CCh2BqsO2TM=; h=Message-ID:Date:From:MIME-Version:CC:Subject:References: In-Reply-To:Content-Type; b=wYUKu5wD6kkWanWR+lw7Rll/0XBjaeDZnDZXS41Z1tsh8TRw1u833mUc0xhl9vRXE JwKPBnXWBl2V19X3SYCaRik1JHMy+pICHdGXHONDIt9J7PKfWjy/3pNVnxO6wBxbrh A5sKgCkMPI3AzKPBlzVs8OaEhpFlH8RICdcQf94c= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 86F4429008D; Tue, 19 Oct 2010 09:03:56 +0400 (MSD) Message-ID: <4CBD26B4.2020205@yandex.ru> Date: Tue, 19 Oct 2010 09:03:48 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 References: <4CBCDD3A.9070404@delphij.net> In-Reply-To: <4CBCDD3A.9070404@delphij.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6FC52689BC3EDA53F02F9E81" X-Yandex-TimeMark: 1287464636 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Cc: Marcel Moolenaar , FreeBSD Current , Xin LI Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 05:19:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6FC52689BC3EDA53F02F9E81 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 19.10.2010 3:50, Xin LI wrote: > With latest kernel I got: >=20 > Mounting from (...) failed with error 19 >=20 > On boot. The system is using pure ZFS setup. It seems that 19 means > ENODEV but according to the dmesg the device do exist. Yes, i have the same problem. --=20 WBR, Andrey V. Elsukov --------------enig6FC52689BC3EDA53F02F9E81 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJMvSa7AAoJEAHF6gQQyKF6wnMH/19OoHNX5Ce/C+WHtzrxkClU XSEWTIZ/d51sph1xmANHRW85cHxWEbc3TLn041pvDcf1CYw6wLiRx23MdQTkrA1Q RNswVDiFOgd0qK/oy4aXqqr/39UJFo2Stu9ms5nlr9gsCdreAZFMH/PZP03rvRqB TlhLScF+S7aRda9hUJDZhrDTwwTJcr/f2AjA0K5nyaVkbIGapv72cIbBKpv6ElfN yPkgnhYr4EZIg0brbg3YSF2SAZNqaOVRF4eRsd21Iu1qGu94AdEcAE8nztHvCAbe QH7fnlTo3ShacjRVr1U7iEqQ1Z3muaU7giZAUIm+XX2MZ9+mtQ7Mh0vNgWmcGl8= =y8JR -----END PGP SIGNATURE----- --------------enig6FC52689BC3EDA53F02F9E81-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 06:08: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 B6762106564A for ; Tue, 19 Oct 2010 06:08:09 +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 314EB8FC15 for ; Tue, 19 Oct 2010 06:08:08 +0000 (UTC) Received: by wyb38 with SMTP id 38so2153473wyb.13 for ; Mon, 18 Oct 2010 23:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=6jO9QKkmMtgS7JW12kIu6agVG6mVHzu7HHln5TJapxQ=; b=XCoeaIlMRgbTyXZm/wVKwBQxc7sqru5fhrjUaajuqT8f3mhWQu8FFUBmHCqtC+qLoj 8KNDtVabIsXM/FCNvBLMBLCrajxxZob+mB7PGS/Ffuq07jJqBHyEZgV/PWdyYhpUWGO9 40k3pLNGxXC2p/K6N0qcVbvPy3LbBx/W/2FAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=KIW/SOfokfh2AMHs9htBia3FFpzJ5p8hrKLkqCpgA3S6cvtDCGZ5svAww0y0H3ZWnq IHAQvRZBMveosuMg7E82l0FlOsrVEYUSngLtZpH9nauS742rmGQLAU/ze+Nu/iIuxT/U /2LaJ9JfeXYVy5T45gEzCdSnz0SwigA8lywEc= Received: by 10.227.63.15 with SMTP id z15mr5420317wbh.214.1287468487955; Mon, 18 Oct 2010 23:08:07 -0700 (PDT) Received: from dragon.dg (41-132-93-155.dsl.mweb.co.za [41.132.93.155]) by mx.google.com with ESMTPS id x65sm7382273weq.25.2010.10.18.23.08.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Oct 2010 23:08:06 -0700 (PDT) From: David Naylor To: Luigi Rizzo Date: Tue, 19 Oct 2010 08:07:54 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.1; amd64; ; ) References: <201010180943.37042.naylor.b.david@gmail.com> <20101018195125.GA46115@onelab2.iet.unipi.it> In-Reply-To: <20101018195125.GA46115@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4209501.PVuBcdrAFh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201010190807.59491.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: geom_sched usage 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, 19 Oct 2010 06:08:09 -0000 --nextPart4209501.PVuBcdrAFh Content-Type: multipart/mixed; boundary="Boundary-01=_7WTvMoIkzLmYVWS" Content-Transfer-Encoding: 7bit --Boundary-01=_7WTvMoIkzLmYVWS Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 18 October 2010 21:51:25 Luigi Rizzo wrote: > On Mon, Oct 18, 2010 at 09:43:28AM +0200, David Naylor wrote: > > Hi, > >=20 > > I've used geom_sched to some success. Normally I do not notice anything > > but today I was copying big files over a gigabit ethernet and my laptop > > was not very responsive. I loaded gsched and the responsiveness > > improved (although still rather bad for anything requiring something > > from the HDD). > >=20 > > Thank you for all this work :-) > >=20 > > Some questions I have: > > - with a gmirror should the gsched be attached to the underlying devic= es > > (aka > >=20 > > /dev/ad?) or to the mirror device (aka /dev/mirror/?)? >=20 > always attach as close as possible to the hardware. Thanks. =20 > > - is there anyway to automatically attach gsched to a device on startup > > (i.e. > >=20 > > in rc.conf)? >=20 > no, you have to build some script yourself. Would there be any interest in having a rc.d/ script? I would find it=20 conveniant to specify a single rc.conf line and get scheduling for all my=20 devices. PC-BSD might find such functionality useful. =20 See attached for my first draft at such a script, I'm willing to hash it in= to=20 shape. =20 > > - is there a way to prioritise random IO (vs sequential reads from big > >=20 > > files)? >=20 > no way to do that, but you can modify the quantum size and time to > let sequential reads get shorter chunks >=20 > kern.geom.sched.rr.quantum_kb: 8192 > kern.geom.sched.rr.quantum_ms: 100 > kern.geom.sched.rr.wait_ms: 10 >=20 > e.g. on a laptop it might make sense to set > quantum_ms=3D50 and quantum_kb=3D2048 Is there a manual page that describes these sysctls? It looks like, in my= =20 case, scp just hogs resources. =20 I do perceive some improvements in normal usage. Thanks > > - gsched_as does not appear to be installed. >=20 > true, gsched_as was just a proof of concept and gsched_rr > includes anticipation and round robin, so it is a superset of gsched_as Thanks for clarity. Regards, David --Boundary-01=_7WTvMoIkzLmYVWS Content-Type: text/plain; charset="ISO-8859-1"; name="gsched.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="gsched.txt" #!/bin/sh # # $FreeBSD$ # # Specify gsched_enable=3D"YES" in /etc/rc.conf(.local) to activate schedul= ing on # storage devices. =20 #=20 # gsched_devs is a space separated list of accepted devices. If empty all # storage devices are used # # gsched_$dev specifies the sheduling algorithm to use (e.g. `rr') # TODO: # - add gsched profiles, such as `desktop' for kern.geom.sched.rr tunables # PROVIDE: gsched # KEYWORD: nojail =2E /etc/rc.subr gsched_enable=3D${gsched_enable:-NO} name=3D"gsched" rcvar=3D`set_rcvar` command=3D"/sbin/${name}" start_cmd=3D"gsched_start" stop_cmd=3D"gsched_stop" gsched_start_dev() { local _gsched_dev _gsched_profile _gsched_args _gsched_dev=3D$1 # Check if sched algo was specified # eval _gsched_profile=3D\$gsched_${_gsched_dev} if [ -n "${_gsched_profile}" ]; then _gsched_args=3D"-a ${_gsched_profile}" fi =09 # Start gsched for ${_gsched_dev} ${command} insert ${_gsched_args} ${_gsched_dev} } gsched_all_devs() { local _dev # Only supports upto 100 devices per device class # XXX: what other storage devices are there? for _dev in `cd /dev; echo *`; do case ${_dev} in ad[0-9]|ad[0-9][0-9]) echo ${_dev} ;; ada[0-9]|ada[0-9][0-9]) echo ${_dev} ;; da[0-9]|da[0-9][0-9]) echo ${_dev} ;; esac done } gsched_start() { local _gsched_devs _g _gsched_devs_recon _gsched_devs=3D$* if [ -z "${_gsched_devs}" ]; then # Use devices specified by gsched_devs _gsched_devs=3D${gsched_devs} # If no devices are specified then use all we can find if [ -z "${_gsched_devs}" ]; then _gsched_devs=3D`gsched_all_devs` fi elif [ -n "${gsched_devs}" ]; then # Make sure the custom device is one of the accepted for _g in ${_gsched_devs}; do case ${gsched_devs} in # _g is either by itself, at the start, middle # or the end of gsched_devs ${_g}|${_g}\ *|*\ ${_g}\ *|*\ ${_g}) _gsched_devs_recon=3D"${_gsched_devs_recon} ${_g}" ;; esac done _gsched_devs=3D${_gsched_devs_recon} fi echo -n "Starting gsched devices:" for _g in ${_gsched_devs}; do echo -n " $_g" gsched_start_dev $_g done echo "." } gsched_stop_dev() { local _gsched_dev _gsched_dev=3D$1 ${command} destroy ${_gsched_dev}.sched. } gsched_stop() { local _gsched_devs _g _gsched_devs=3D$* if [ -z "${_gsched_devs}" ]; then # Use devices specified by gsched_devs _gsched_devs=3D${gsched_devs} # If no devices are specified then use all we can find if [ -z "${_gsched_devs}" ]; then _gsched_devs=3D`gsched_all_devs` fi fi echo -n "Stopping gsched devices:" for _g in ${_gsched_devs}; do echo -n " $_g" gsched_stop_dev $_g done echo "." } load_rc_config $name run_rc_command $* --Boundary-01=_7WTvMoIkzLmYVWS-- --nextPart4209501.PVuBcdrAFh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEABECAAYFAky9Nb8ACgkQUaaFgP9pFrJ14ACfRTmC+Z7Zw2VwWe02A93OcAdW SOQAnRzJMtyMUd6eM0EVZLVG3/HNdpmm =wvam -----END PGP SIGNATURE----- --nextPart4209501.PVuBcdrAFh-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 06:30: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 60E1110656A4 for ; Tue, 19 Oct 2010 06:30:45 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E81F88FC23 for ; Tue, 19 Oct 2010 06:30:44 +0000 (UTC) Received: by bwz16 with SMTP id 16so95276bwz.13 for ; Mon, 18 Oct 2010 23:30:43 -0700 (PDT) Received: by 10.204.76.80 with SMTP id b16mr1588997bkk.160.1287469843468; Mon, 18 Oct 2010 23:30:43 -0700 (PDT) Received: from jessie.localnet (p5B0E17C5.dip0.t-ipconnect.de [91.14.23.197]) by mx.google.com with ESMTPS id y19sm17616651bkw.6.2010.10.18.23.30.41 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Oct 2010 23:30:41 -0700 (PDT) From: Bernhard Schmidt To: Buganini Date: Tue, 19 Oct 2010 08:30:37 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-25-generic; KDE/4.4.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010190830.37974.bschmidt@freebsd.org> Cc: FreeBSD Current Subject: Re: wpa_supplicant and ssid 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, 19 Oct 2010 06:30:45 -0000 On Monday, October 18, 2010 18:55:34 you wrote: > It seems that wpa_supplicant iterate through all scanned ssids and try to > associate with each, > and that cause two problem for me. > > 1) in my school, there are many AP, and connection is not stable, when > disconnect, > it take many time to try and fail to associate with those ssids until the > one I want. You can add a 'priority' statement to each network block in wpa_supplicant.conf. > 2) i can't associate with a non-discoverable ssid > > but probably it is my wireless driver's problem, > i'm using bwn0 and currently I need to force it to use mode 11b or it is > unusable. Tried different options for the scan_ssid parameter? > or should I complain to upstream ? Before doing so, can you capture the output of 'wlandebug 0xffffffff' while trying to get a connection? -- Bernhard From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 06:55:34 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 11BAF1065672; Tue, 19 Oct 2010 06:55:34 +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 E48598FC12; Tue, 19 Oct 2010 06:55:32 +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 JAA28414; Tue, 19 Oct 2010 09:55:31 +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 1P866d-0000W9-3r; Tue, 19 Oct 2010 09:55:31 +0300 Message-ID: <4CBD40E2.7030507@freebsd.org> Date: Tue, 19 Oct 2010 09:55:30 +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: Giovanni Trematerra References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> <4CBC5719.1020807@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system 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, 19 Oct 2010 06:55:34 -0000 on 19/10/2010 00:01 Giovanni Trematerra said the following: > On Mon, Oct 18, 2010 at 4:18 PM, Andriy Gapon wrote: >> Again, not sure if I follow you, I don't see relation between per-cpu caches and >> dynamic slab size. > > Your patch seems just a work around about initial slab size where the > keg is backed. Well, setting aside my confusion with the terminology - yes, the patch is just that, and precisely because I only tried to solve that particular problem. > Having dynamic slab sizes would allow to have the keg backed on a larger slab > without going OFFPAGE. I agree in principle. But without seeing code that implements that I can't guess if it would really be more efficient or more maintainable, i.e. more useful in general. Still a very good idea. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 07:01: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 6320C1065694; Tue, 19 Oct 2010 07:01:32 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 227808FC14; Tue, 19 Oct 2010 07:01:31 +0000 (UTC) Received: by pzk2 with SMTP id 2so399818pzk.13 for ; Tue, 19 Oct 2010 00:01:31 -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=Ah6AEs2CARKif3dXnOiMI1PU7QDqmn21iEZg7g67YOQ=; b=QN7LTqzdjIwKXq7Xk/w+6jnfsrTdgAFge3MVyjbdRbWsRtSz5+YdtOQRr6RnR0sCIO VoimQJWx88cKMXw4fqE0nfhstpfcGKezLAvCmcPzQoRfm8C/MOUxEfpQIexqG0LvrV/a S9ly3667+XVY2aMLZiKJPTqorhK+gZcATsTuQ= 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=pAKEQmHVECY4N+ndV+AkRBd7NDW0nHrIuAcW9zAUmXSy3I9hLtHTnAY1IkmQe/I8L7 28bAnsX55wFXBNZLILxnqeSxQh5uMxfoABKf2d4E6UfIM3eJ/3CBNtTg9DwZRFZF8aOb D7MR70zy204McMQZBYZVPxOdQdVkOyHgTNyrw= MIME-Version: 1.0 Received: by 10.143.29.1 with SMTP id g1mr4295383wfj.83.1287470233507; Mon, 18 Oct 2010 23:37:13 -0700 (PDT) Received: by 10.142.165.2 with HTTP; Mon, 18 Oct 2010 23:37:13 -0700 (PDT) In-Reply-To: References: <4C9389BC.7090300@FreeBSD.org> <20101018152338.GA6540@freebsd.org> <20101018152803.GA8679@freebsd.org> <20101018183645.GA33114@freebsd.org> Date: Mon, 18 Oct 2010 23:37:13 -0700 Message-ID: From: Jack Vogel To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Best , Jakub Lach , Andriy Gapon , Alex Dupre , current@freebsd.org Subject: Re: Regarding pciids 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, 19 Oct 2010 07:01:32 -0000 On Mon, Oct 18, 2010 at 12:13 PM, Garrett Cooper wrote: > On Mon, Oct 18, 2010 at 11:36 AM, Alexander Best > wrote: > > On Mon Oct 18 10, Garrett Cooper wrote: > >> On Mon, Oct 18, 2010 at 8:28 AM, Alexander Best > wrote: > >> > On Mon Oct 18 10, Alexander Best wrote: > >> >> On Fri Sep 17 10, Alex Dupre wrote: > >> >> > I created hackish scripts to generate pci_vendors file from Boemler > and > >> >> > Mares (pciids.sf.net) lists. I haven't found the Hart list. > >> >> > > >> >> > The results of the scripts are here: > >> >> > >> >> sorry it seems i missed your post back then. > >> >> > >> >> i found two more lists: > >> >> > >> >> http://rh-software.com/downloads/pcidevs.txt > >> >> and > >> >> http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be > based on the > >> >> Hart list) > >> >> > >> >> the actual Hart list seems to have vanished and the web location is > no longer > >> >> accessible. > >> >> > >> >> personally i don't think it's necessary to combine the data of two > files. the > >> >> mares database seems extremely elaborate. all my pci devices get > described > >> >> properly. also making use of only one databse would make it more easy > to submit > >> >> additional info back to the vendor. > >> >> > >> >> so any objections to switching to the mares list? > >> >> > >> >> cheers. > >> >> alex > >> >> > >> >> > > >> >> > http://www.alexdupre.com/pci_vendors/mares.txt > >> >> > http://www.alexdupre.com/pci_vendors/boemler.txt > >> >> > http://www.alexdupre.com/pci_vendors/mares-boemler.txt > >> >> > http://www.alexdupre.com/pci_vendors/boemler-mares.txt > >> >> > > >> >> > The first two are generated from single lists, the last two are > >> >> > combined, with different preference order. > >> > > >> > oh...and i think it would be a good idea to move from ";" as comment > character > >> > to "#". that way we wouldn't need to run a script, but could include > the vendor > >> > file directly into the src tree. > >> > >> I noted this a while back to Warner and Brooke as I came up with a > >> short script to do this, and they suggested that it be supplemented to > >> the existing list, not replace it. > > > > why? the mares list is obviosly superior, because linux contributes to it > and > > thus has far more people submitting changes than any other list. > > > > is there a case where the old list has an entry the mares list is > missing? > > Most of the values (above 99%) were the same actually between the > 2 lists. I think the point was to avoid churn in the description > fields because a lot of the description fields were different, the > Linux list was produced by questionable sources (IIRC the other list > was produced by vendors, but I could be wrong). Rather than guessing I > would just ask Brookes and Warner directly though, offlist... > Cheers, > -Garrett > Questionable, you mean like Intel? :) I brought this up in the first place asking because our new ID's go direct into the sf list. I understand the desire to avoid churn, but I suspect this would be a change for the longer term good. Just my .02 Jack From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 07:18: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 662F41065673 for ; Tue, 19 Oct 2010 07:18:19 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 331DD8FC12 for ; Tue, 19 Oct 2010 07:18:18 +0000 (UTC) Received: from b.earth.lavabit.com (b.earth.lavabit.com [192.168.111.11]) by karen.lavabit.com (Postfix) with ESMTP id 25E3011BA46; Tue, 19 Oct 2010 02:18:18 -0500 (CDT) Received: from rui-macbook.lan (bl16-141-47.dsl.telepac.pt [188.81.141.47]) by lavabit.com with ESMTP id 03D5S2WBBQ40; Tue, 19 Oct 2010 02:18:18 -0500 References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> Content-Transfer-Encoding: 7bit From: Rui Paulo Date: Tue, 19 Oct 2010 08:18:15 +0100 To: =?iso-8859-1?Q?Istv=E1n?= X-Mailer: Apple Mail (2.1081) Cc: freebsd-current , Garrett Cooper Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 19 Oct 2010 07:18:19 -0000 cd /usr/ports/*/postgres90-server make clean export DTRACE_DEBUG=1 make install Check what dtrace is doing. BTW have you added postgres to the wheel group? Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 08:06: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 839301065670 for ; Tue, 19 Oct 2010 08:06:05 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4873B8FC0C for ; Tue, 19 Oct 2010 08:06:04 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E862E730A1; Tue, 19 Oct 2010 10:18:24 +0200 (CEST) Date: Tue, 19 Oct 2010 10:18:24 +0200 From: Luigi Rizzo To: David Naylor Message-ID: <20101019081824.GB54147@onelab2.iet.unipi.it> References: <201010180943.37042.naylor.b.david@gmail.com> <20101018195125.GA46115@onelab2.iet.unipi.it> <201010190807.59491.naylor.b.david@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010190807.59491.naylor.b.david@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: geom_sched usage 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, 19 Oct 2010 08:06:05 -0000 On Tue, Oct 19, 2010 at 08:07:54AM +0200, David Naylor wrote: > On Monday 18 October 2010 21:51:25 Luigi Rizzo wrote: ... > > > - is there anyway to automatically attach gsched to a device on startup > > > (i.e. > > > > > > in rc.conf)? > > > > no, you have to build some script yourself. > > Would there be any interest in having a rc.d/ script? I would find it > conveniant to specify a single rc.conf line and get scheduling for all my > devices. PC-BSD might find such functionality useful. > > See attached for my first draft at such a script, I'm willing to hash it into > shape. it would surely be useful but try to keep it simple and user-driven (this is a general comment on rc.d scripts). Some things i think you should simplify in your script: - remove support for guessing which devices should get the scheduler. This is really a user decision and if the user names no devices then i believe it is better/safer not to install any scheduler. - use standard names such as gsched_flags or gsched_flags_${dev} to hold generic and specific flags for the insert command. It is neither useful nor flexible to have the script insert '-a' in front of the algorithm; cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 08:22:30 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 D83E9106566C; Tue, 19 Oct 2010 08:22:30 +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 A243D8FC18; Tue, 19 Oct 2010 08:22:30 +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 o9J8MTC6076802; Tue, 19 Oct 2010 04:22:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9J8MTTj076801; Tue, 19 Oct 2010 08:22:29 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Oct 2010 08:22:29 GMT Message-Id: <201010190822.o9J8MTTj076801@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 sparc64/sparc64 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: Tue, 19 Oct 2010 08:22:31 -0000 TB --- 2010-10-19 01:55:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-19 01:55:54 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-10-19 01:55:54 - cleaning the object tree TB --- 2010-10-19 01:58:17 - cvsupping the source tree TB --- 2010-10-19 01:58:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-10-19 02:03:02 - building world TB --- 2010-10-19 02:03:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 02:03:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 02:03:02 - TARGET=sparc64 TB --- 2010-10-19 02:03:02 - TARGET_ARCH=sparc64 TB --- 2010-10-19 02:03:02 - TZ=UTC TB --- 2010-10-19 02:03:02 - __MAKE_CONF=/dev/null TB --- 2010-10-19 02:03:02 - cd /src TB --- 2010-10-19 02:03:02 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 19 02:03:04 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 Tue Oct 19 06:51:31 UTC 2010 TB --- 2010-10-19 06:51:31 - generating LINT kernel config TB --- 2010-10-19 06:51:31 - cd /src/sys/sparc64/conf TB --- 2010-10-19 06:51:31 - /usr/bin/make -B LINT TB --- 2010-10-19 06:51:31 - building LINT kernel TB --- 2010-10-19 06:51:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 06:51:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 06:51:31 - TARGET=sparc64 TB --- 2010-10-19 06:51:31 - TARGET_ARCH=sparc64 TB --- 2010-10-19 06:51:31 - TZ=UTC TB --- 2010-10-19 06:51:31 - __MAKE_CONF=/dev/null TB --- 2010-10-19 06:51:31 - cd /src TB --- 2010-10-19 06:51:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 19 06:51:32 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_subr.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_trantcp.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_usr.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_common.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_lock.c cc1: warnings being treated as errors /src/sys/nfs/nfs_lock.c: In function 'nfs_dolock': /src/sys/nfs/nfs_lock.c:254: warning: passing argument 3 of 'nmp->nm_com.nmcom_getinfo' from incompatible pointer type *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-19 08:22:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-19 08:22:29 - ERROR: failed to build lint kernel TB --- 2010-10-19 08:22:29 - 3544.85 user 12258.00 system 23195.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 09:00: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 0FF26106564A for ; Tue, 19 Oct 2010 09:00:03 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id AB3748FC18 for ; Tue, 19 Oct 2010 09:00:02 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 2FF7F15147F; Tue, 19 Oct 2010 11:59:56 +0300 (EEST) Date: Tue, 19 Oct 2010 11:59:56 +0300 From: Jaakko Heinonen To: David Xu Message-ID: <20101019085955.GA4865@jh> References: <4C961009.6080609@freebsd.org> <4C96ED40.7070206@DataIX.net> <4C976F14.8000408@freebsd.org> <4C9789FD.5000008@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C9789FD.5000008@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: sysctl -a is slow 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, 19 Oct 2010 09:00:03 -0000 On 2010-09-20, David Xu wrote: > I redirect all output to a disk file, and it still needs 1 second to > complete, this machine is dual-core pentium E5500, faster than previous > one which is a dual-core AMD 5000+ machine, the 5000+ needs 2 > seconds to complete. > > $/usr/bin/time sysctl -b kern.geom.confdot > sysctl_geom_confdot.txt > 1.00 real 0.00 user 0.00 sys I couldn't reproduce the problem myself but I bet that it's a lost wakeup in g_waitfor_event(). Can you try this patch? %%% Index: sys/geom/geom_event.c =================================================================== --- sys/geom/geom_event.c (revision 214048) +++ sys/geom/geom_event.c (working copy) @@ -220,11 +220,12 @@ one_event(void) mtx_lock(&g_eventlock); TAILQ_REMOVE(&g_events, ep, events); ep->flag &= ~EV_INPROGRESS; - mtx_unlock(&g_eventlock); if (ep->flag & EV_WAKEUP) { ep->flag |= EV_DONE; wakeup(ep); + mtx_unlock(&g_eventlock); } else { + mtx_unlock(&g_eventlock); g_free(ep); } g_topology_unlock(); @@ -365,11 +366,14 @@ g_waitfor_event(g_event_t *func, void *a va_end(ap); if (error) return (error); - do - tsleep(ep, PRIBIO, "g_waitfor_event", hz); - while (!(ep->flag & EV_DONE)); + + mtx_lock(&g_eventlock); + while (!(ep->flag & EV_DONE)) + msleep(ep, &g_eventlock, PRIBIO, "g_waitfor_event", hz); if (ep->flag & EV_CANCELED) error = EAGAIN; + mtx_unlock(&g_eventlock); + g_free(ep); return (error); } %%% -- Jaakko From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 09:35: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 BBD991065674; Tue, 19 Oct 2010 09:35:12 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8843D8FC1B; Tue, 19 Oct 2010 09:35:12 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id D41FF11B914; Tue, 19 Oct 2010 04:35:11 -0500 (CDT) Received: from 172.17.1.174 (gw-eduroam-81.fc.up.pt [193.136.24.81]) by lavabit.com with ESMTP id UMHVFRVSZV8B; Tue, 19 Oct 2010 04:35:11 -0500 References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org> Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Tue, 19 Oct 2010 10:33:33 +0100 To: =?iso-8859-1?Q?Istv=E1n?= X-Mailer: Apple Mail (2.1081) Cc: freebsd-current , Garrett Cooper Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 19 Oct 2010 09:35:12 -0000 On 19 Oct 2010, at 10:15, Istv=E1n wrote: > wow, you go the point after couple of emails. better later than never, = huh :) You sure are an amusing guy. Rude, but amusing :-) >=20 > you think adding pgsql to wheel might help? cc freebsd-security@ and = see their opinion about the topic. dof needs to inject the probes in /dev/dtrace/helper, so the user needs = rw access to the /dev/dtrace/helper. I specifically added write access = to the wheel group for this. >=20 > i modified the permission of /dev/dtrace/helper instead but it gives = the following error still: >=20 > dtrace DOF postgres: DTrace ioctl failed for DOF at 0x801c35000: = Invalid argument This error usually means that there were no probes found in dof section = of the binary. Somehow they were not inserted correctly during the build = stage. > do you mean /usr/ports/databases/postgresql90-server? Yes. >=20 > I was rebuilding it with that switch, what now? Send me the build log, gzipped. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 10:00: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 712F11065674; Tue, 19 Oct 2010 10:00:14 +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 4FB4B8FC17; Tue, 19 Oct 2010 10:00:09 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D2C2546B45; Tue, 19 Oct 2010 06:00:08 -0400 (EDT) Date: Tue, 19 Oct 2010 11:00:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rui Paulo In-Reply-To: <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org> Message-ID: References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> <28FFE6A7-0ECD-4454-9364-DC555327678E@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: =?ISO-8859-15?Q?Istv=E1n?= , freebsd-current , Garrett Cooper Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 19 Oct 2010 10:00:14 -0000 On Tue, 19 Oct 2010, Rui Paulo wrote: >> you think adding pgsql to wheel might help? cc freebsd-security@ and see >> their opinion about the topic. > > dof needs to inject the probes in /dev/dtrace/helper, so the user needs rw > access to the /dev/dtrace/helper. I specifically added write access to the > wheel group for this. In the medium term, part of the solution here will be to finish adding a role-based privilege system. I had this on my todo list for 8.0 but didn't manage to get it finished. With any luck, it will make 9.0 in plenty of time. this would allow specific kernel privileges to be delegated to specific users and groups (among other things). Many of the kernel changes to support this have been done since 7.0 when I added priv(9), but we've not yet selected a specific policy and API to bind to them. Some appliances are already using priv(9) via extensible MAC modules to delegate privilege, but for a role-based privilege system, I think a tighter integration is preferable (especially in light of the risks from composing incorrectly with the root user model). In some sense, however, a privilege system is also exactly the wrong answer. Ideally, you should be able to run dtrace on any process that you have debugging rights on, which is calculated with respect to the credentials of the two processes involved (subject and object). You might also reasonably key certain kernel probes, such as systrace probes, to the same authorization scheme. The remainder of kernel tracing presumably should remain a privilege, as should the use of kernel probes. In general, I would prefer it if the kernel didn't know any more about specific users and groups than it already does -- in practice, this is somewhat unavoidable due to the way we do devfs, but minimizing it would be a good idea. In the past, where we have had special things we need to delegate that bypass some but not all system integrity protections (such as shutdown, reboot, and backup), we've assigned them via the operator group, FYI. Robert From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 10:05: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 358FF1065672; Tue, 19 Oct 2010 10:05:39 +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 000638FC1F; Tue, 19 Oct 2010 10:05:38 +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 o9JA5cpk088086; Tue, 19 Oct 2010 06:05:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9JA5cMQ088085; Tue, 19 Oct 2010 10:05:38 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Oct 2010 10:05:38 GMT Message-Id: <201010191005.o9JA5cMQ088085@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: Tue, 19 Oct 2010 10:05:39 -0000 TB --- 2010-10-19 01:15:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-19 01:15:02 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-10-19 01:15:02 - cleaning the object tree TB --- 2010-10-19 01:17:08 - cvsupping the source tree TB --- 2010-10-19 01:17:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-10-19 01:21:43 - building world TB --- 2010-10-19 01:21:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 01:21:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 01:21:43 - TARGET=powerpc TB --- 2010-10-19 01:21:43 - TARGET_ARCH=powerpc64 TB --- 2010-10-19 01:21:43 - TZ=UTC TB --- 2010-10-19 01:21:43 - __MAKE_CONF=/dev/null TB --- 2010-10-19 01:21:43 - cd /src TB --- 2010-10-19 01:21:43 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 19 01:21:45 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 Tue Oct 19 09:16:13 UTC 2010 TB --- 2010-10-19 09:16:13 - generating LINT kernel config TB --- 2010-10-19 09:16:13 - cd /src/sys/powerpc/conf TB --- 2010-10-19 09:16:13 - /usr/bin/make -B LINT TB --- 2010-10-19 09:16:13 - building LINT kernel TB --- 2010-10-19 09:16:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 09:16:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 09:16:13 - TARGET=powerpc TB --- 2010-10-19 09:16:13 - TARGET_ARCH=powerpc64 TB --- 2010-10-19 09:16:13 - TZ=UTC TB --- 2010-10-19 09:16:13 - __MAKE_CONF=/dev/null TB --- 2010-10-19 09:16:13 - cd /src TB --- 2010-10-19 09:16:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 19 09:16:13 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/netsmb/smb_subr.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/netsmb/smb_trantcp.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/netsmb/smb_usr.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/nfs/nfs_common.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/nfs/nfs_lock.c cc1: warnings being treated as errors /src/sys/nfs/nfs_lock.c: In function 'nfs_dolock': /src/sys/nfs/nfs_lock.c:254: warning: passing argument 3 of 'nmp->nm_com.nmcom_getinfo' from incompatible pointer type *** 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-19 10:05:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-19 10:05:38 - ERROR: failed to build lint kernel TB --- 2010-10-19 10:05:38 - 5044.08 user 17545.88 system 31835.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 10:16: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 C0CE2106564A; Tue, 19 Oct 2010 10:16: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 933418FC0C; Tue, 19 Oct 2010 10:16: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 o9JAGho9092519; Tue, 19 Oct 2010 06:16: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 o9JAGh4a092518; Tue, 19 Oct 2010 10:16:43 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Oct 2010 10:16:43 GMT Message-Id: <201010191016.o9JAGh4a092518@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 sparc64/sun4v 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: Tue, 19 Oct 2010 10:16:44 -0000 TB --- 2010-10-19 04:03:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-19 04:03:09 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-10-19 04:03:09 - cleaning the object tree TB --- 2010-10-19 04:04:56 - cvsupping the source tree TB --- 2010-10-19 04:04:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-10-19 04:09:53 - building world TB --- 2010-10-19 04:09:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 04:09:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 04:09:53 - TARGET=sun4v TB --- 2010-10-19 04:09:53 - TARGET_ARCH=sparc64 TB --- 2010-10-19 04:09:53 - TZ=UTC TB --- 2010-10-19 04:09:53 - __MAKE_CONF=/dev/null TB --- 2010-10-19 04:09:53 - cd /src TB --- 2010-10-19 04:09:53 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 19 04:09:55 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 Tue Oct 19 09:35:04 UTC 2010 TB --- 2010-10-19 09:35:04 - generating LINT kernel config TB --- 2010-10-19 09:35:04 - cd /src/sys/sun4v/conf TB --- 2010-10-19 09:35:04 - /usr/bin/make -B LINT TB --- 2010-10-19 09:35:04 - building LINT kernel TB --- 2010-10-19 09:35:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 09:35:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 09:35:04 - TARGET=sun4v TB --- 2010-10-19 09:35:04 - TARGET_ARCH=sparc64 TB --- 2010-10-19 09:35:04 - TZ=UTC TB --- 2010-10-19 09:35:04 - __MAKE_CONF=/dev/null TB --- 2010-10-19 09:35:04 - cd /src TB --- 2010-10-19 09:35:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 19 09:35:05 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_subr.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_trantcp.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_usr.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_common.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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_lock.c cc1: warnings being treated as errors /src/sys/nfs/nfs_lock.c: In function 'nfs_dolock': /src/sys/nfs/nfs_lock.c:254: warning: passing argument 3 of 'nmp->nm_com.nmcom_getinfo' from incompatible pointer type *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-19 10:16:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-19 10:16:43 - ERROR: failed to build lint kernel TB --- 2010-10-19 10:16:43 - 3501.72 user 12728.75 system 22414.08 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 09:15: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 1C314106566B; Tue, 19 Oct 2010 09:15:36 +0000 (UTC) (envelope-from leccine@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 B0F858FC08; Tue, 19 Oct 2010 09:15:35 +0000 (UTC) Received: by iwn36 with SMTP id 36so771517iwn.13 for ; Tue, 19 Oct 2010 02:15:35 -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=ncd6SPPbb7W0ypWqJDS0acNHIkZxDHoXVKH8WFFw6mw=; b=K2hrWi3vCNZ8NVJEVelDs+L3Bt91l5xvf5/7TaVWu2XD2AbUoHSt4yj5g9aaVVdMm5 LJiEQK6oekMZXwYAkEOv0N4vYUo91ZvtyAG3GF1uToU6VyVuV4bvNXS+KMWc1kK1JLBy DR7p5LhIVJU9lP0tb24DIo27vV/998Ge+DfOk= 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=TbgPd3dj/Kk9lyekhcaLoVEDchBuQi6h2bbPOeSx8nX+sOqIVxK/iuBUFD+GJ7eCUr hz7FMUgmNgV6SzeAOz0DUi/iKlEL5AJy0pNSOpqfK1kPPCKr7bHP6ZxVPD431yM5lwhv oqo0Y28ctkXEAJqhLq920dREoRjihljurbaho= MIME-Version: 1.0 Received: by 10.231.15.137 with SMTP id k9mr2784808iba.101.1287479734771; Tue, 19 Oct 2010 02:15:34 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Tue, 19 Oct 2010 02:15:34 -0700 (PDT) In-Reply-To: <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> Date: Tue, 19 Oct 2010 10:15:34 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: Rui Paulo X-Mailman-Approved-At: Tue, 19 Oct 2010 11:01:24 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , Garrett Cooper Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 19 Oct 2010 09:15:36 -0000 wow, you go the point after couple of emails. better later than never, huh :) you think adding pgsql to wheel might help? cc freebsd-security@ and see their opinion about the topic. i modified the permission of /dev/dtrace/helper instead but it gives the following error still: dtrace DOF postgres: DTrace ioctl failed for DOF at 0x801c35000: Invalid argument do you mean /usr/ports/databases/postgresql90-server? I was rebuilding it with that switch, what now? I. On Tue, Oct 19, 2010 at 8:18 AM, Rui Paulo wrote: > cd /usr/ports/*/postgres90-server > make clean > export DTRACE_DEBUG=1 > make install > > Check what dtrace is doing. > > BTW have you added postgres to the wheel group? > > Regards, > -- > Rui Paulo > > > -- the sun shines for all http://blog.l1x.me From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 09:53: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 D1858106566C; Tue, 19 Oct 2010 09:53:21 +0000 (UTC) (envelope-from leccine@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 6A9638FC1B; Tue, 19 Oct 2010 09:53:21 +0000 (UTC) Received: by iwn36 with SMTP id 36so807052iwn.13 for ; Tue, 19 Oct 2010 02:53:20 -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=0hhBGFds0d2jtH+aOXGSTPFSMDzbfj+M09Ec33tTc6Y=; b=l5cmmx0NZSLtKL8ou0zvMk3HZTi40xWbPV5IBlIYSv6At92PEbD7HBL24lJyoCwQ6m cOHynmGkRNH1MV1y1C2SwA+UD/EE984vnOWYHRHcQYQJ4MBWq7BtOseM8Tk29eAaq8r5 nepFR+JL6bLqFEnavnRRwuijYFzqZRx0gEsP4= 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=KItUVVAAHaPUk32OcsojouJz/vfV4zjjAouE2DI5lTo/AK3Jak9l7ijNM4rAJoKlCm JpStHjyqSnnwcvepwQdLTSFPVMdf+BCKiS7qGgPqCw1blO03bX4pByLeSrWZmRQj/tZk u8gU3xuhS7oXr62t67f1unF68o+0FmlEaOyE8= MIME-Version: 1.0 Received: by 10.231.147.131 with SMTP id l3mr4482001ibv.74.1287482000386; Tue, 19 Oct 2010 02:53:20 -0700 (PDT) Received: by 10.231.32.130 with HTTP; Tue, 19 Oct 2010 02:53:20 -0700 (PDT) In-Reply-To: <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org> References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org> Date: Tue, 19 Oct 2010 10:53:20 +0100 Message-ID: From: =?UTF-8?Q?Istv=C3=A1n?= To: Rui Paulo X-Mailman-Approved-At: Tue, 19 Oct 2010 11:01:46 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , Garrett Cooper Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps 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, 19 Oct 2010 09:53:21 -0000 On Tue, Oct 19, 2010 at 10:33 AM, Rui Paulo wrote: > > On 19 Oct 2010, at 10:15, Istv=C3=A1n wrote: > > > wow, you go the point after couple of emails. better later than never, > huh :) > > You sure are an amusing guy. Rude, but amusing :-) > > thanks! > > > > you think adding pgsql to wheel might help? cc freebsd-security@ and se= e > their opinion about the topic. > > dof needs to inject the probes in /dev/dtrace/helper, so the user needs r= w > access to the /dev/dtrace/helper. I specifically added write access to th= e > wheel group for this. > > and you think the only way to do that is to add pgsql to wheel group?!? http://images.memegenerator.net/Troll-Face/ImageMacro/2337177/LOL-U-MAD-BRO= .jpg > > > > i modified the permission of /dev/dtrace/helper instead but it gives th= e > following error still: > > > > dtrace DOF postgres: DTrace ioctl failed for DOF at 0x801c35000: Invali= d > argument > > This error usually means that there were no probes found in dof section o= f > the binary. Somehow they were not inserted correctly during the build sta= ge. > you see, we are slowly getting there :) > > > do you mean /usr/ports/databases/postgresql90-server? > > Yes. > > > > > I was rebuilding it with that switch, what now? > > Send me the build log, gzipped. > yes sir yes! (and you are talking about ppl being rude) what file do you need and which directory ___excatly___ btw. it would be beneficial for you as the DTrace maintainer of FreeBSD to have your own environment and prove me that I am wrong since you are happil= y tracing on your own box, it is just the lame user who is not able to do tha= t :) your own words: "Tracing and instrumenting userland programs is very important because it allows the understanding of what's going on, especially on highly complex systems such as databases, web servers, and language interpreters. Since DTrace on FreeBSD now has the ability to instrument both the kernel and the userland program, you can get very meaningful data on how your program is behaving and why." So instead of fixing my problem on my box, fix it for everybody and update the wiki with the process if you have a chance. As of now, I consider FreeBSD as a non-supported platform for DTrace since I spent almost 2 days to get it working without success and it is definitely less effort to spin up a (Open)Solaris instance to debug performance issue. Let me know if you get it working in the future. thank you in advance. --=20 the sun shines for all http://blog.l1x.me From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 13:16:17 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 175411065780; Tue, 19 Oct 2010 13:16:17 +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 C8B1F8FC1E; Tue, 19 Oct 2010 13:16:16 +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 7C3FE46B2C; Tue, 19 Oct 2010 09:16:16 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AB0778A029; Tue, 19 Oct 2010 09:16:14 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 19 Oct 2010 08:49:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CB8A614.6000707@greatbaysoftware.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010190849.58660.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 09:16:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Charles Owens , Sergey Kandaurov , Scott Long , freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state 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, 19 Oct 2010 13:16:17 -0000 On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: > On 16 October 2010 02:18, Sergey Kandaurov wrote: > > On 16 October 2010 00:51, Charles Owens wrote: > >> Hmm... the problem appears to have resolved itself. After a few hours the > >> new drive seems to have gone back into the array, and the original hot spare > >> drive put back into hot-spare state. > >> > >> So I'm interpreting state 0x0020 to therefore mean something like "hang on > >> while I use this new drive to automatically put everything back as it was > >> before the failure". Is this correct? > >> > >> Thanks, > >> Charles > >> > >> [root@Bsvr ~]# mfiutil show drives > >> mfi0 Physical Drives: > >> ( 149G) ONLINE SATA enclosure 1, slot 0 > >> ( 149G) ONLINE SATA enclosure 1, slot 1 > >> ( 149G) ONLINE SATA enclosure 1, slot 2 > >> ( 149G) HOT SPARE SATA enclosure 1, slot > >> 3 > >> ( 149G) ONLINE SATA enclosure 1, slot 4 > >> > >> > > >>> > [...] > >>> [root@svr ~]# mfiutil show drives > >>> mfi0 Physical Drives: > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 0 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 1 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 2 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 3 > >>> ( 149G) PSTATE 0x0020 SATA enclosure > >>> 1, slot 4 > >>> > >>> mfi0: port 0x1000-0x10ff mem > >>> ... > >>> > > > > Hi, Charles Owens. > > > > 0x20 is much likely to be the copyback physical state, > > which is missing in enum mfi_pd_state. > > And what you've experienced is copyback feature in action :) > > Your array has been rebuilt with HSP as its ordinal PD, then you > > switched failed drive > > with good one, and HSP came into copyback mode to move all its data back > > to good disk. That prevents reordering of disk numbers in array and > > double rebuilding. > > > > So, it no one objects, I'd like to commit this change. If you have access to the MFI docs (or a reference in the Linux driver, e.g.) then this is fine. The existing pd_state enum lists the values for PD state that were listed in the MFI docs I had access to at the time I wrote mfiutil. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 13:16: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 BD7CA1065780; Tue, 19 Oct 2010 13:16:19 +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 8E8288FC14; Tue, 19 Oct 2010 13:16:19 +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 39A7E46B23; Tue, 19 Oct 2010 09:16:19 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4B72E8A01D; Tue, 19 Oct 2010 09:16:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 19 Oct 2010 08:54:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101018174331.GA80017@sandvine.com> <20101018181142.GC5644@dan.emsphone.com> <20101018193010.GA88783@sandvine.com> In-Reply-To: <20101018193010.GA88783@sandvine.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010190854.38626.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 09:16:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Dan Nelson , Ed Maste Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 19 Oct 2010 13:16:19 -0000 On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > cp_time value essentially won't roll over (at 1 billion increments per > > second it will roll over in 500 years; we currently increment 133 times per > > second, I think). If the value can be calculated accurately, it should be > > printed. > > Well, it won't roll over, but it's still different from all following > lines (in that it effectively shows user/system/idle CPU usage since > boot on the first line, and a snapshot over the last interval from then > on). I think it's still better to avoid printing it in that case. All of the first line is that way though. To do this "right" you'd need to blank out the entire first line. vm_stat and iostat on OS X have the current FreeBSD behavior (instant first line that summarizes all activity since uptime), so I'd be inclined to just leave the existing behavior. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 13:16: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 2C652106589B; Tue, 19 Oct 2010 13:16: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 F11118FC1F; Tue, 19 Oct 2010 13:16:25 +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 9E17746B7F; Tue, 19 Oct 2010 09:16:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A6B8E8A009; Tue, 19 Oct 2010 09:16:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 19 Oct 2010 08:55:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010190855.48364.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 09:16:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: mdf@freebsd.org Subject: Re: uma_zfree(NULL) is 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: Tue, 19 Oct 2010 13:16:26 -0000 On Monday, October 18, 2010 4:59:17 pm mdf@freebsd.org wrote: > There's explicit protection for free(NULL, M_FOO), but uma_zfree(zone, > NULL) will put NULL in the local bucket and then probably return it > later from a uma_zalloc call. Obviously it's not a good idea to call > uma_zfree(9) on NULL, but in this case it's an easy mistake to make > when e.g. converting a set of malloc(9)/free(9) uses into uma(9). > > So is the "right" thing to allow a uma_zfree(NULL) and silently > succeed, like for free(9)? That would be my guess, but I'm open to > alternatives. Given that free(3) and free(9) both handle NULL, I think it makes sense for uma_zfree() to do so as well. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 13:40: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 0973510656A3 for ; Tue, 19 Oct 2010 13:40:38 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id BE0E68FC0C for ; Tue, 19 Oct 2010 13:40:37 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9BFF219E02A; Tue, 19 Oct 2010 15:21:01 +0200 (CEST) Received: from [10.43.15.14] (cage.codelab.cz [94.124.105.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id A062E19E02E; Tue, 19 Oct 2010 15:20:59 +0200 (CEST) Message-ID: <4CBD9B39.1040101@quip.cz> Date: Tue, 19 Oct 2010 15:20:57 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8 MIME-Version: 1.0 To: David Naylor References: <201010180943.37042.naylor.b.david@gmail.com> <20101018195125.GA46115@onelab2.iet.unipi.it> <201010190807.59491.naylor.b.david@gmail.com> In-Reply-To: <201010190807.59491.naylor.b.david@gmail.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: geom_sched usage 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, 19 Oct 2010 13:40:38 -0000 David Naylor wrote: > On Monday 18 October 2010 21:51:25 Luigi Rizzo wrote: [...] >>> - is there anyway to automatically attach gsched to a device on startup >>> (i.e. >>> >>> in rc.conf)? >> >> no, you have to build some script yourself. > > Would there be any interest in having a rc.d/ script? I would find it > conveniant to specify a single rc.conf line and get scheduling for all my > devices. PC-BSD might find such functionality useful. > > See attached for my first draft at such a script, I'm willing to hash it into > shape. [...] You can use `sysctl kern.disks` to find available disk devices in your rc script. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 14:05: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 241A5106564A; Tue, 19 Oct 2010 14:05:26 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D4C338FC0A; Tue, 19 Oct 2010 14:05:25 +0000 (UTC) Received: by pvg7 with SMTP id 7so303644pvg.13 for ; Tue, 19 Oct 2010 07:05:25 -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=SJnUT1mehkASUwjfVD82he0NJvmynqL7NLfgEcjG97w=; b=kNIIWedDgmErJniT9P5YyxW3Q0MTADBUQv3YH3Pk2TMl2RJLUTZQyjKFx7KKvSKzVT u5PYOKb32oMoUYJYMYKzLQ4DKAYnMKbLr5Gy/64ttGO1MOsgtXuWR11qTC84sN8ZhZb0 P7pohX1FQiiTO4eLvogZfIvNGeQM/1F3k3wfE= 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=paiT3qgkqsPHjOdI4OGgyyXlKzR5E5UbrOcffrYxuTVqHlscuefGTOeamw0o/Rzk+X sgclK06mw01jNBGLOwXJ6RTiqWEVYXmXgv5yiVVoaknOsLdUaytel9+xpxi2c7xZbkDK khJyZxUm9z2d7IAcIqk7ihm2IzdJG/eP6r/9I= MIME-Version: 1.0 Received: by 10.229.91.75 with SMTP id l11mr5215807qcm.24.1287497124458; Tue, 19 Oct 2010 07:05:24 -0700 (PDT) Received: by 10.229.61.29 with HTTP; Tue, 19 Oct 2010 07:05:24 -0700 (PDT) In-Reply-To: <201010190849.58660.jhb@freebsd.org> References: <4CB8A614.6000707@greatbaysoftware.com> <201010190849.58660.jhb@freebsd.org> Date: Tue, 19 Oct 2010 18:05:24 +0400 Message-ID: From: Sergey Kandaurov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Charles Owens , freebsd-current@freebsd.org, Scott Long , freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state 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, 19 Oct 2010 14:05:26 -0000 On 19 October 2010 16:49, John Baldwin wrote: > On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: >> On 16 October 2010 02:18, Sergey Kandaurov wrote: >> > On 16 October 2010 00:51, Charles Owens = wrote: >> >> =A0Hmm... the problem appears to have resolved itself. =A0After a few= hours the >> >> new drive seems to have gone back into the array, and the original ho= t spare >> >> drive put back into hot-spare state. >> >> >> >> So I'm interpreting state 0x0020 to therefore mean something like "ha= ng on >> >> while I use this new drive to automatically put everything back as it= was >> >> before the failure". =A0Is this correct? >> >> >> >> Thanks, >> >> Charles >> >> >> >> [root@Bsvr ~]# mfiutil show drives >> >> mfi0 Physical Drives: >> >> ( =A0149G) ONLINE =A0SATA enclosu= re 1, slot 0 >> >> ( =A0149G) ONLINE =A0SATA enclosu= re 1, slot 1 >> >> ( =A0149G) ONLINE =A0SATA enclosu= re 1, slot 2 >> >> ( =A0149G) HOT SPARE =A0SATA encl= osure 1, slot >> >> 3 >> >> ( =A0149G) ONLINE =A0SATA enclosu= re 1, slot 4 >> >> >> >> >> >> >>> >> [...] >> >>> [root@svr ~]# mfiutil show drives >> >>> mfi0 Physical Drives: >> >>> ( =A0149G) ONLINE =A0SATA enclos= ure 1, slot >> >>> 0 >> >>> ( =A0149G) ONLINE =A0SATA enclos= ure 1, slot >> >>> 1 >> >>> ( =A0149G) ONLINE =A0SATA enclos= ure 1, slot >> >>> 2 >> >>> ( =A0149G) ONLINE =A0SATA enclos= ure 1, slot >> >>> 3 >> >>> ( =A0149G) PSTATE 0x0020 =A0SATA= enclosure >> >>> 1, slot 4 >> >>> >> >>> mfi0: =A0port 0x1000-0x10ff mem >> >>> ... >> >>> >> > >> > Hi, Charles Owens. >> > >> > 0x20 is much likely to be the copyback physical state, >> > which is missing in enum mfi_pd_state. >> > And what you've experienced is copyback feature in action :) >> > Your array has been rebuilt with HSP as its ordinal PD, then you >> > switched failed drive >> > with good one, and HSP came into copyback mode to move all its data ba= ck >> > to good disk. That prevents reordering of disk numbers in array and >> > double rebuilding. >> > >> >> So, it no one objects, I'd like to commit this change. > > If you have access to the MFI docs (or a reference in the Linux driver, e= .g.) > then this is fine. =A0The existing pd_state enum lists the values for PD = state > that were listed in the MFI docs I had access to at the time I wrote mfiu= til. > Hi, John. I've no such access unfortunately. As for FreeBSD vendor's driver, it doesn't list PD states at all (and looks like their version lags behind other OS versions). However, they (LSI) are listing COPYBACK entry as 0x20 in its Linux driver= , and there: http://lkml.org/lkml/2009/5/5/389 --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 14:12: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 BEA491065679; Tue, 19 Oct 2010 14:12:32 +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 76A068FC34; Tue, 19 Oct 2010 14:12:32 +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 08AB646BA0; Tue, 19 Oct 2010 10:12:32 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F06E58A01D; Tue, 19 Oct 2010 10:12:30 -0400 (EDT) From: John Baldwin To: Sergey Kandaurov Date: Tue, 19 Oct 2010 10:11:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CB8A614.6000707@greatbaysoftware.com> <201010190849.58660.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010191011.44962.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 10:12:31 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Charles Owens , freebsd-current@freebsd.org, Scott Long , freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state 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, 19 Oct 2010 14:12:33 -0000 On Tuesday, October 19, 2010 10:05:24 am Sergey Kandaurov wrote: > On 19 October 2010 16:49, John Baldwin wrote: > > On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: > >> On 16 October 2010 02:18, Sergey Kandaurov wrote: > >> > On 16 October 2010 00:51, Charles Owens wrote: > >> >> Hmm... the problem appears to have resolved itself. After a few hours the > >> >> new drive seems to have gone back into the array, and the original hot spare > >> >> drive put back into hot-spare state. > >> >> > >> >> So I'm interpreting state 0x0020 to therefore mean something like "hang on > >> >> while I use this new drive to automatically put everything back as it was > >> >> before the failure". Is this correct? > >> >> > >> >> Thanks, > >> >> Charles > >> >> > >> >> [root@Bsvr ~]# mfiutil show drives > >> >> mfi0 Physical Drives: > >> >> ( 149G) ONLINE SATA enclosure 1, slot 0 > >> >> ( 149G) ONLINE SATA enclosure 1, slot 1 > >> >> ( 149G) ONLINE SATA enclosure 1, slot 2 > >> >> ( 149G) HOT SPARE SATA enclosure 1, slot > >> >> 3 > >> >> ( 149G) ONLINE SATA enclosure 1, slot 4 > >> >> > >> >> > >> > >> >>> > >> [...] > >> >>> [root@svr ~]# mfiutil show drives > >> >>> mfi0 Physical Drives: > >> >>> ( 149G) ONLINE SATA enclosure 1, slot > >> >>> 0 > >> >>> ( 149G) ONLINE SATA enclosure 1, slot > >> >>> 1 > >> >>> ( 149G) ONLINE SATA enclosure 1, slot > >> >>> 2 > >> >>> ( 149G) ONLINE SATA enclosure 1, slot > >> >>> 3 > >> >>> ( 149G) PSTATE 0x0020 SATA enclosure > >> >>> 1, slot 4 > >> >>> > >> >>> mfi0: port 0x1000-0x10ff mem > >> >>> ... > >> >>> > >> > > >> > Hi, Charles Owens. > >> > > >> > 0x20 is much likely to be the copyback physical state, > >> > which is missing in enum mfi_pd_state. > >> > And what you've experienced is copyback feature in action :) > >> > Your array has been rebuilt with HSP as its ordinal PD, then you > >> > switched failed drive > >> > with good one, and HSP came into copyback mode to move all its data back > >> > to good disk. That prevents reordering of disk numbers in array and > >> > double rebuilding. > >> > > >> > >> So, it no one objects, I'd like to commit this change. > > > > If you have access to the MFI docs (or a reference in the Linux driver, e.g.) > > then this is fine. The existing pd_state enum lists the values for PD state > > that were listed in the MFI docs I had access to at the time I wrote mfiutil. > > > > Hi, John. > > I've no such access unfortunately. > As for FreeBSD vendor's driver, it doesn't list PD states at all > (and looks like their version lags behind other OS versions). > > However, they (LSI) are listing COPYBACK entry as 0x20 in its Linux driver, > and there: http://lkml.org/lkml/2009/5/5/389 Ok. You should add the SYSTEM state too (0x40) while you are at it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 14:15: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 75C02106564A for ; Tue, 19 Oct 2010 14:15:35 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from gse-mta-27.emailfiltering.com (gse-mta-27-tx.emailfiltering.com [194.116.198.158]) by mx1.freebsd.org (Postfix) with ESMTP id D3B878FC18 for ; Tue, 19 Oct 2010 14:15:34 +0000 (UTC) Received: from mail-gw12.york.ac.uk ([144.32.129.162]) by gse-mta-27.emailfiltering.com with emfmta (version 4.6.0.72) by TLS id 781287768 for buganini@gmail.com; ab731f9ce778008a; Tue, 19 Oct 2010 15:04:22 +0100 Received: from buffy-128.york.ac.uk ([144.32.128.160]:10740 helo=buffy.york.ac.uk) by mail-gw12.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1P8Cnd-0005yx-Ny; Tue, 19 Oct 2010 15:04:21 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.4/8.14.4) with ESMTP id o9JE4L1i095172; Tue, 19 Oct 2010 15:04:21 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.4/8.14.4/Submit) id o9JE4Lcn095171; Tue, 19 Oct 2010 15:04:21 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Buganini In-Reply-To: References: Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Oct 2010 15:04:20 +0100 Message-ID: <1287497061.93256.60.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 FreeBSD GNOME Team Port Cc: FreeBSD Current Subject: Re: wpa_supplicant and ssid 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, 19 Oct 2010 14:15:35 -0000 On Tue, 2010-10-19 at 00:55 +0800, Buganini wrote: > It seems that wpa_supplicant iterate through all scanned ssids and try to > associate with each, > and that cause two problem for me. >=20 > 1) in my school, there are many AP, and connection is not stable, when > disconnect, > it take many time to try and fail to associate with those ssids until the > one I want. This appears to be the same as the bug reported in PR bin/98220. wpa_supplicant is contributed code, so I think the correct answer is to report this upstream. As far as I could tell when I last checked, this hasn't yet been fixed upstream. Gavin --=20 Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 14:31: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 5F4141065741; Tue, 19 Oct 2010 14:31:14 +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 6225E8FC08; Tue, 19 Oct 2010 14:31:13 +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 o9JEGM3s046461; Tue, 19 Oct 2010 08:16:22 -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: Date: Tue, 19 Oct 2010 08:16:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5B6C7929-8868-487C-97DC-DACEAEBFBC55@samsco.org> References: <4CB8A614.6000707@greatbaysoftware.com> <4CB8BED6.8040204@greatbaysoftware.com> To: Garrett Cooper 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: Charles Owens , Sergey Kandaurov , freebsd-hardware@freebsd.org, FreeBSD Current Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state 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, 19 Oct 2010 14:31:14 -0000 On Oct 18, 2010, at 11:25 AM, Garrett Cooper wrote: > On Mon, Oct 18, 2010 at 9:55 AM, Sergey Kandaurov = wrote: >> On 16 October 2010 02:18, Sergey Kandaurov wrote: >>>=20 >=20 > Check with LSI before you commit that; you might not understand > the overall nuances of that value. In all fairness, we're talking about an information reporting attribute, = not an action attribute. And yes, most of us in this discussion have = been writing device drivers and working with vendors for years. Scott From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 14:56: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 8BC6E1065674 for ; Tue, 19 Oct 2010 14:56:51 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id 3079D8FC1E for ; Tue, 19 Oct 2010 14:56:50 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward13.mail.yandex.net (Yandex) with ESMTP id 52A631080E27; Tue, 19 Oct 2010 18:56:49 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287500209; bh=jLN+OsO/RnAGhq3v18rnzcdLO43ytI9MDoU6ba5tvxI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=HEz3BCRInk8XVnBCtlJuLOzIvuAG/ciAe2zYdPWBd9OBZHWIycMNCLIgcIV5rlWpF M3zK6/OgAiPNR+45mYVV1jkPzGNwKMNR/66Q8j/Gsc8cRqPq6cG22HwEfQQpMmAK6/ BFN3WkSRo6CsD0vU8ZYyBXEIqDM1x6XhGTr16XB8= Received: from [10.43.163.197] (nat-77-119.kirovnet.ru [92.39.77.119]) by smtp13.mail.yandex.net (Yandex) with ESMTPSA id DAA9F4158088; Tue, 19 Oct 2010 18:56:48 +0400 (MSD) Message-ID: <4CBDB17C.4040607@yandex.ru> Date: Tue, 19 Oct 2010 18:55:56 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100925 Thunderbird/3.1.4 MIME-Version: 1.0 To: FreeBSD Current References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> In-Reply-To: <4CBD26B4.2020205@yandex.ru> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F7F4E52FC567B1555BB59E2" X-Yandex-TimeMark: 1287500209 X-Yandex-Spam: 1 X-Yandex-Front: smtp13.mail.yandex.net Cc: Marcel Moolenaar , Xin LI Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 14:56:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F7F4E52FC567B1555BB59E2 Content-Type: multipart/mixed; boundary="------------040201060102040101070507" This is a multi-part message in MIME format. --------------040201060102040101070507 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 19.10.2010 09:03, Andrey V. Elsukov wrote: >> Mounting from (...) failed with error 19 >> >> On boot. The system is using pure ZFS setup. It seems that 19 means >> ENODEV but according to the dmesg the device do exist. >=20 > Yes, i have the same problem. I fixed it with attached patch. --=20 WBR, Andrey V. Elsukov --------------040201060102040101070507 Content-Type: text/plain; name="vfs_mountroot.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="vfs_mountroot.c.diff" Index: vfs_mountroot.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- vfs_mountroot.c (revision 214058) +++ vfs_mountroot.c (working copy) @@ -713,7 +713,8 @@ goto out; } =20 - if (dev[0] !=3D '\0' && !parse_mount_dev_present(dev)) { + if (strcmp(fs, "zfs") && dev[0] !=3D '\0' && + !parse_mount_dev_present(dev)) { printf("mountroot: waiting for device %s ...\n", dev); delay =3D hz / 10; timeout =3D root_mount_timeout * hz; --------------040201060102040101070507-- --------------enig2F7F4E52FC567B1555BB59E2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJMvbF8AAoJEAHF6gQQyKF60XkIAJZK1TlRow5eoOZNJiuKReuv /JgDTG0iQRigPkxRk7v1caargnPjzDI6FT2g9yJ90uGxiF1Gaxu8tNKzh2VJjqVx VhC7q17BL8jzyDO/kfbHySN2MdMopIkjaJko/534afpoqHRdSPpHBb03FpLhFCQu bDZQ6swnzQafoV7m7iAZky9iZL3WpaKEDpV9Y4Jqmee/bD5BLD3PGFF3/CpBSzUW jg61PDaN+VP/JuxPM38qMa9b4lIpTNkOvsfMHYnXELXXJb+ZFjpVChQpLsD58ZGZ w+FF4L8ljf59CMOTWtGPnfrezj9fUuG3UhmEQAtmlvmPumQrrBxizcUdiCDud1Y= =vNna -----END PGP SIGNATURE----- --------------enig2F7F4E52FC567B1555BB59E2-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 15:00: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 AFEB81065673; Tue, 19 Oct 2010 15:00:31 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 6D90E8FC12; Tue, 19 Oct 2010 15:00:31 +0000 (UTC) Received: by mail.0x20.net (Postfix, from userid 1002) id 3380F39DFE; Tue, 19 Oct 2010 16:40:56 +0200 (CEST) Date: Tue, 19 Oct 2010 16:40:56 +0200 From: Lars Engels To: John Baldwin Message-ID: <20101019144056.GY34884@e.0x20.net> Mail-Followup-To: Lars Engels , John Baldwin , freebsd-current@freebsd.org, Dan Nelson , Ed Maste References: <20101018174331.GA80017@sandvine.com> <20101018181142.GC5644@dan.emsphone.com> <20101018193010.GA88783@sandvine.com> <201010190854.38626.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xUyMHIOv46mebLva" Content-Disposition: inline In-Reply-To: <201010190854.38626.jhb@freebsd.org> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ed Maste , freebsd-current@freebsd.org, Dan Nelson Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 19 Oct 2010 15:00:31 -0000 --xUyMHIOv46mebLva Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 19, 2010 at 08:54:38AM -0400, John Baldwin wrote: > On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > >=20 > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > cp_time value essentially won't roll over (at 1 billion increments per > > > second it will roll over in 500 years; we currently increment 133 tim= es per > > > second, I think). If the value can be calculated accurately, it shou= ld be > > > printed. > >=20 > > Well, it won't roll over, but it's still different from all following > > lines (in that it effectively shows user/system/idle CPU usage since > > boot on the first line, and a snapshot over the last interval from then > > on). I think it's still better to avoid printing it in that case. >=20 > All of the first line is that way though. To do this "right" you'd need = to > blank out the entire first line. >=20 > vm_stat and iostat on OS X have the current FreeBSD behavior (instant fir= st > line that summarizes all activity since uptime), so I'd be inclined to ju= st > leave the existing behavior. I'd be very happy if all vmstat and iostat would get a command line switch to suppress the "summary since last reboot" line. This information may be useful for some cases but in other cases, like creating performance data for monitoring systems like Icinga / Nagios one has to remove the first line(s) manually. --xUyMHIOv46mebLva Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAky9rfcACgkQKc512sD3afi8DQCgkKTgtKgktPnKHK91l5qcKehL EEAAniXkgwVW/INOTOZ2U62Hz/R6ug+B =9l2y -----END PGP SIGNATURE----- --xUyMHIOv46mebLva-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 15: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 6737D1065674 for ; Tue, 19 Oct 2010 15:43:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1DC8FC2A for ; Tue, 19 Oct 2010 15:43:40 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LAJ003F2NOMPF10@asmtp028.mac.com> for freebsd-current@FreeBSD.ORG; Tue, 19 Oct 2010 08:43:36 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010190111 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-19_05:2010-10-19, 2010-10-19, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <4CBD26B4.2020205@yandex.ru> Date: Tue, 19 Oct 2010 08:43:19 -0700 Message-id: References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , Xin LI Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 15:43:40 -0000 On Oct 18, 2010, at 10:03 PM, Andrey V. Elsukov wrote: > On 19.10.2010 3:50, Xin LI wrote: >> With latest kernel I got: >> >> Mounting from (...) failed with error 19 >> >> On boot. The system is using pure ZFS setup. It seems that 19 means >> ENODEV but according to the dmesg the device do exist. > > Yes, i have the same problem. Can you both boot verbose and send me the output. Also, please boot with -a and show me the console output, as well as the output of the '?' command. Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 16:25: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 0B31B106566B for ; Tue, 19 Oct 2010 16:25:50 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward17.mail.yandex.net (forward17.mail.yandex.net [95.108.253.142]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6A68FC12 for ; Tue, 19 Oct 2010 16:25:47 +0000 (UTC) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward17.mail.yandex.net (Yandex) with ESMTP id 2F3C7A588E7; Tue, 19 Oct 2010 20:25:46 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287505546; bh=ax/9ngOsJz0HEv5fseu/KLnJXUjv7fFmVq2Hc/ikZ8M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=RB8lX9b6F7Ty7cs6wELzrs0yWYD5J2J5Uwu7Pw+LiPb7kLYlyysnX/XhYkNOX6d2v DzIgG49Q+WKMgnPiMIZl2u+EbfvArOAHDn1BZNbdhfbtgpwupgW8zlmhTZfUTxdCgj eywlKgxQfWFMcU5JwzY8MG3+kuJ7R4/3BKygFLx4= Received: from [10.43.163.197] (nat-77-119.kirovnet.ru [92.39.77.119]) by smtp17.mail.yandex.net (Yandex) with ESMTPSA id 642D8307005A; Tue, 19 Oct 2010 20:25:43 +0400 (MSD) Message-ID: <4CBDC655.5050701@yandex.ru> Date: Tue, 19 Oct 2010 20:24:53 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100925 Thunderbird/3.1.4 MIME-Version: 1.0 To: Marcel Moolenaar References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------010702060305010600020708" X-Yandex-TimeMark: 1287505546 X-Yandex-Spam: 1 X-Yandex-Front: smtp17.mail.yandex.net Cc: FreeBSD Current , Xin LI Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 16:25:50 -0000 This is a multi-part message in MIME format. --------------010702060305010600020708 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit On 19.10.2010 19:43, Marcel Moolenaar wrote: >> Yes, i have the same problem. > > Can you both boot verbose and send me the output. > Also, please boot with -a and show me the console > output, as well as the output of the '?' command. It is ZFS-only system and I have this line in /boot/loader.conf: vfs.root.mountfrom="zfs:zroot" With "boot -a -v -s" I got the same result that with "boot -s -v" but when I enter zfs:zroot in mountroot prompt it printed: Trying to mount root from zfs:zroot []... mountroot: waiting for device zroot ... Mounting from zfs:zroot failed with error 19. Trying to mount root from zfs:zroot []... mountroot: waiting for device zroot ... Mounting from zfs:zroot failed with error 19. panic: mountroot: unable to (re-)mount root. So, it seems that waiting for device when we are booting from zfs is not necessary.. -- WBR, Andrey V. Elsukov --------------010702060305010600020708 Content-Type: text/plain; name="boot_-v_-s.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_-v_-s.txt" 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 #8 r214013: Wed Oct 20 00:06:20 MSD 2010 root@:/usr/obj/usr/src/sys/BTR i386 Table 'FACP' at 0x7f7a0200 Table 'APIC' at 0x7f7a0390 Table 'MCFG' at 0x7f7a03f0 Table 'OEMB' at 0x7f7ae040 Table 'HPET' at 0x7f7a5900 Table 'SSDT' at 0x7f7aeb80 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0x83d7c000. Preloaded elf module "/boot/kernel/zfs.ko" at 0x83d7c198. Preloaded elf module "/boot/kernel/opensolaris.ko" at 0x83d7c240. Preloaded elf module "/boot/kernel/linux.ko" at 0x83d7c2f0. Preloaded elf module "/boot/kernel/snd_hda.ko" at 0x83d7c39c. Preloaded elf module "/boot/kernel/sound.ko" at 0x83d7c448. Preloaded elf module "/boot/kernel/coretemp.ko" at 0x83d7c4f4. Preloaded elf module "/boot/kernel/acpi_video.ko" at 0x83d7c5a4. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x83d7c654. Preloaded elf module "/boot/kernel/drm.ko" at 0x83d7c6ac. Preloaded elf module "/boot/kernel/i915.ko" at 0x83d7c754. Preloaded elf module "/boot/kernel/acpi_asus.ko" at 0x83d7c800. Preloaded elf module "/boot/modules/video4bsd.ko" at 0x83d7c8b0. Preloaded elf module "/boot/kernel/usb.ko" at 0x83d7c960. Preloaded elf module "/boot/kernel/usb_quirk.ko" at 0x83d7ca08. Preloaded elf module "/boot/kernel/ehci.ko" at 0x83d7cab8. Preloaded elf module "/boot/kernel/umass.ko" at 0x83d7cb64. Calibrating TSC clock ... TSC clock: 1596041208 Hz CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d AMD Features=0x100000 AMD Features2=0x1 TSC: P-state invariant 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 512 kbytes, 16-way associative, 64 bytes/line real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001026000 - 0x000000007d36ffff, 2083823616 bytes (508746 pages) avail memory = 2079625216 (1983 MB) Table 'FACP' at 0x7f7a0200 Table 'APIC' at 0x7f7a0390 APIC: Found table at 0x7f7a0390 MP Configuration Table version 1.4 found at 0x830f1160 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 bios32: Found BIOS32 Service Directory header at 0x830f0000 bios32: Entry = 0xf0010 (830f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0x830f88b0 pnpbios: Entry = f0000:996a Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfb9e0 00014 (v00 ACPIAM) ACPI: RSDT 0x7f7a0000 0003C (v01 A_M_I_ OEMRSDT 03000903 MSFT 00000097) ACPI: FACP 0x7f7a0200 00084 (v02 A_M_I_ OEMFACP 03000903 MSFT 00000097) ACPI: DSDT 0x7f7a05b0 05342 (v01 A1028 A1028000 00000000 INTL 20051117) ACPI: FACS 0x7f7ae000 00040 ACPI: APIC 0x7f7a0390 0005C (v01 A_M_I_ OEMAPIC 03000903 MSFT 00000097) ACPI: MCFG 0x7f7a03f0 0003C (v01 A_M_I_ OEMMCFG 03000903 MSFT 00000097) ACPI: OEMB 0x7f7ae040 00061 (v01 A_M_I_ AMI_OEM 03000903 MSFT 00000097) ACPI: HPET 0x7f7a5900 00038 (v01 A_M_I_ OEMHPET 03000903 MSFT 00000097) ACPI: SSDT 0x7f7aeb80 004F0 (v01 PmRef CpuPm 00003000 INTL 20051117) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 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: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x00000000 video4bsd: /dev/video0..9, /dev/video_daemon0..9 wlan: mac acl policy registered snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> null: random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device CPU0: local APIC error 0x80 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 3.00 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0x87eb6000 pa 0x1000 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7f700000 (3) failed ACPI timer: 1/2 0/3 1/2 1/2 1/2 1/2 0/3 1/2 1/1 1/2 -> 8 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI: SSDT 0x7f7ae180 0023C (v01 PmRef Cpu0Ist 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0023C (v01 PmRef Cpu0Ist 00003000 INTL 20051117) ACPI: SSDT 0x7f7ae450 00724 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00724 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) cpu1: on acpi0 ACPI: SSDT 0x7f7ae0b0 000CC (v01 PmRef Cpu1Ist 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 000CC (v01 PmRef Cpu1Ist 00003000 INTL 20051117) ACPI: SSDT 0x7f7ae3c0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x27ac, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27ae, 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=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xf7f00000, size 19, enabled map[14]: type I/O Port, range 32, base 0xdc00, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xf7ec0000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27a6, 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 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf7f80000, size 19, enabled found-> vendor=0x8086, dev=0x27d8, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf7eb8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d0, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 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=0x27d2, revid=0x02 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 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=0x27d6, revid=0x02 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27c8, revid=0x02 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=3 map[20]: type I/O Port, range 32, base 0xd400, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x02 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=11 map[20]: type I/O Port, range 32, base 0xd480, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x02 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=7 map[20]: type I/O Port, range 32, base 0xd800, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x02 domain=0, bus=0, slot=29, func=3 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=d, irq=5 map[20]: type I/O Port, range 32, base 0xd880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x02 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=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf7eb7c00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xe2 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27c4, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled vgapci0: port 0xdc00-0xdc07 mem 0xf7f00000-0xf7f7ffff,0xd0000000-0xdfffffff,0xf7ec0000-0xf7efffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7932k stolen memory acpi_video0: on vgapci0 found VGA CRT or VESA Compatible Analog Monitor(100), idx#0, port#0, detectable by BIOS, head #0 found TV/HDTV or Analog-Video Monitor(200), idx#0, port#0, detectable by BIOS, head #0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, detectable by BIOS, head #0 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: mem 0xf7f80000-0xf7ffffff at device 2.1 on pci0 hdac0: mem 0xf7eb8000-0xf7ebbfff irq 16 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 256 to local APIC 0 vector 49 hdac0: using IRQ 256 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 4 pcib1: subordinate bus 4 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P4 - AE_NOT_FOUND pci4: on pcib1 pci4: domain=0, physical bus=4 pcib2: irq 17 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 3 pcib2: subordinate bus 3 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfbf00000-0xfbffffff pcib2: no prefetched decode pci3: on pcib2 pci3: domain=0, physical bus=3 found-> vendor=0x1969, dev=0x1026, revid=0xb0 domain=0, bus=3, slot=0, func=0 class=02-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=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfbfc0000, size 18, enabled pcib2: requested memory range 0xfbfc0000-0xfbffffff: good map[18]: type I/O Port, range 32, base 0xec00, size 7, enabled pcib2: requested I/O range 0xec00-0xec7f: in range pcib2: matched entry for 3.0.INTA pcib2: slot 0 INTA hardwired to IRQ 17 pci3: at device 0.0 (no driver attached) pci0:3:0:0: Transition from D0 to D3 pcib3: irq 19 at device 28.3 on pci0 pcib3: domain 0 pcib3: secondary bus 1 pcib3: subordinate bus 2 pcib3: I/O decode 0x0-0x0 pcib3: memory decode 0xf8000000-0xfbefffff pcib3: prefetched decode 0xf0000000-0xf6ffffff pci1: on pcib3 pci1: domain=0, physical bus=1 found-> vendor=0x168c, dev=0x001c, revid=0x01 domain=0, bus=1, slot=0, func=0 class=02-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 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfbef0000, size 16, enabled pcib3: requested memory range 0xfbef0000-0xfbefffff: good pcib3: matched entry for 1.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 pci1: at device 0.0 (no driver attached) pci0:1:0:0: Transition from D0 to D3 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) ehci0: mem 0xf7eb7c00-0xf7eb7fff irq 23 at device 29.7 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 50 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 5 pcib4: subordinate bus 5 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci5: on pcib4 pci5: domain=0, physical bus=5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 51 ata1: on atapci0 ata1: reset tp1 mask=03 ostat0=03 ostat1=03 ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata1: stat1=0x0f err=0x0f lsb=0x0f msb=0x0f ata1: reset tp2 stat0=87 stat1=8f devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 52 acpi_asus0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 53 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 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 54 Event timer "RTC" frequency 32768 Hz quality 0 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 55 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 56 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 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 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 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 57 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it 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 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: Can not get Tj(target) from your CPU, using 100C. coretemp0: Setting TjMax=100 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Can not get Tj(target) from your CPU, using 100C. coretemp1: Setting TjMax=100 est1: on cpu1 p4tcc1: on cpu1 Device configuration finished. procfs registered ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 4 ZFS storage pool version 15 Timecounter "TSC" frequency 1596041208 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: 00000001 ata0: New devices: 00000001 usbus0: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad0: setting UDMA100 battery0: battery initialization startad0: 152627MB at ata0-master UDMA100 SATA ad0: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue ata1: Identifying devices: 00000000 ata1: New devices: 00000000 hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC269 hdac0: HDA Codec ID: 0x10ec0269 hdac0: Vendor: 0x10ec hdac0: Device: 0x0269 hdac0: Revision: 0x00 hdac0: Stepping: 0x04 hdac0: PCI Subvendor: 0x831a1043 hdac0: Found audio FG nid=1 startnode=2 endnode=37 total=35 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x00000000 NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdac0: nid 17 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 18 0x99a30920 as 2 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x0121401f as 1 seq 15 Headphones Jack jack 1 loc 1 color Green misc 0 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 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 27 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 29 0x4005822d as 2 seq 13 Line-out None jack 5 loc 0 color Purple misc 2 hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patched pins configuration: hdac0: nid 17 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 18 0x99a30920 as 2 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x0121401f as 1 seq 15 Headphones Jack jack 1 loc 1 color Green misc 0 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 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 27 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 29 0x4005822d as 2 seq 13 Line-out None jack 5 loc 0 color Purple misc 2 [DISABLED] hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: 3 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Pin nid=21 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=18 seq=0 hdac0: Association 2 (3) in: hdac0: Pin nid=24 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Pin 21 traced to DAC 2 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Unable to trace pin 18 to ADC 7, undo traces hdac0: Pin 18 traced to ADC 8 hdac0: Association 1 (2) trace succeeded hdac0: Tracing association 2 (3) hdac0: Pin 24 traced to ADC 7 hdac0: Association 2 (3) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 11 to out hdac0: nid 11 is input monitor hdac0: Tracing nid 36 to out hdac0: Tracing other input monitors hdac0: Tracing nid 18 to out hdac0: Tracing nid 24 to out hdac0: Tracing beeper hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=21 [UNSOL] hdac0: Pin sense: nid=21 res=0x00000000 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: 0x000e05f0 hdac0: 16 20 24 bits, 32 44 48 88 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: 0x0003403f hdac0: mute=0 step=64 size=3 offset=63 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: 0x0003403f hdac0: mute=0 step=64 size=3 offset=63 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: 0x000e05f0 hdac0: 16 20 24 bits, 32 44 48 88 96 192 KHz hdac0: hdac0: nid: 7 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 2 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x80032e11 hdac0: mute=1 step=46 size=3 offset=17 hdac0: connections: 1 hdac0: | hdac0: + <- nid=36 [audio mixer] hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x80032e11 hdac0: mute=1 step=46 size=3 offset=17 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 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 5 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm, mix 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 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] 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: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000211 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e05f0 hdac0: 16 20 24 bits, 32 44 48 88 96 192 KHz hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400380 hdac0: DIGITAL UNSOL hdac0: Pin cap: 0x00000014 hdac0: PDC OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] [DISABLED] hdac0: hdac0: nid: 18 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x99a30920 hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x0040010d hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x00010050 hdac0: OUT BAL 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: 2 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0001001c hdac0: PDC HP OUT EAPD hdac0: Pin config: 0x0121401f hdac0: Pin control: 0x000000c0 HP OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] 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: 2 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00003734 hdac0: PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x01a19830 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: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 25 [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: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Pin cap: 0x0000373c hdac0: PDC HP 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: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 27 [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: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Line-out (None) hdac0: Widget cap: 0x00400000 hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x4005822d hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400380 hdac0: DIGITAL UNSOL hdac0: Pin cap: 0x00000014 hdac0: PDC 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: 0x00300101 hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: monitor hdac0: connections: 7 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: + <- nid=18 [pin: Mic (Fixed)] (selected) hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 36 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: mic, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 6 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] 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 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: ADC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] 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=21 [pin: Headphones (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: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio selector] [src: monitor] pcm0: | pcm0: + <- nid=18 [pin: Mic (Fixed)] [src: monitor] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 2 out): -63/1dB (65 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 16 (nid 20 in ): mute pcm0: +- ctl 17 (nid 21 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 2 out): -63/1dB (65 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor) pcm0: | pcm0: +- ctl 4 (nid 8 in 0): -17/29dB (47 steps) + mute pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 8 in 0): -17/29dB (47 steps) + mute pcm0: pcm0: Input Mix Level (OSS: mix) pcm0: | pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 11a0000, 4000; 0xc85f6000 -> 11a0000 pcm0: sndbuf_setmap 11b0000, 4000; 0xc8606000 -> 11b0000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0160 pcm1: 16 20 24 bits, 44 48 96 KHz pcm1: ADC: 7 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Record: pcm1: pcm1: nid=7 [audio input] pcm1: | pcm1: + <- nid=36 [audio mixer] [src: mic, mix] pcm1: | pcm1: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Microphone Volume (OSS: mic) pcm1: | pcm1: +- ctl 20 (nid 24 out): 0/30dB (4 steps) pcm1: +- ctl 27 (nid 36 in 0): mute pcm1: pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 3 (nid 7 in 0): -17/29dB (47 steps) + mute pcm1: +- ctl 27 (nid 36 in 0): mute pcm1: +- ctl 32 (nid 36 in 5): mute pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: | pcm1: +- ctl 5 (nid 11 in 0): -34/12dB (32 steps) + mute pcm1: +- ctl 32 (nid 36 in 5): mute pcm1: pcm1: Mixer "mic": pcm1: Mixer "mix": pcm1: Mixer "rec": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 11c0000, 4000; 0xc8616000 -> 11c0000 ugen0.1: at usbus0 uhub0: on usbus0 GEOM: new disk ad0 acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x00000000 CPU1: local APIC error 0x80 Root mount waiting for: usbus0 battery0: battery initialization done, tried 1 times Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 1 port with 0 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 umass0: on usbus0 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1984MB (4063232 512 byte sectors: 255H 63S/T 252C) Root mount waiting for: usbus0 ugen0.4: at usbus0 Trying to mount root from zfs:zroot []... mountroot: waiting for device zroot ... Mounting from zfs:zroot failed with error 19. Loader variables: vfs.root.mountfrom=zfs:zroot Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ? List of GEOM managed disk devices: ufs/roota ufsid/4cb7558275cbf154a da0s1a ufs/root ufsid/4cb7558275cbf154 da0s1 da0 gptid/beeff9c7-6fb3-11de-b2b4-00248c1d353a gpt/zfs gptid/92325e73-6fb3-11de-b2b4-00248c1d353a gpt/swap gptid/7b7ad1d7-6fb3-11de-b2b4-00248c1d353a gpt/boot ad0p3 ad0p2 ad0p1 ad0 mountroot> ufs:/dev/ufs/root Trying to mount root from ufs:/dev/ufs/root []... ct_to_ts([2010-10-19 20:10:08]) = 1287519008.000000000 start_init: trying /sbin/init --------------010702060305010600020708 Content-Type: text/plain; name="gpart_show.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gpart_show.txt" => 34 312581741 ad0 GPT (149G) 34 256 1 freebsd-boot (128K) 290 4194304 2 freebsd-swap (2.0G) 4194594 251658240 3 freebsd-zfs (120G) 255852834 56728941 - free - (27G) => 63 4063122 da0 MBR (1.9G) 63 4063122 1 freebsd [active] (1.9G) --------------010702060305010600020708-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 16:27: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 37FC910656A4 for ; Tue, 19 Oct 2010 16:27:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 1D30E8FC2A for ; Tue, 19 Oct 2010 16:27:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LAJ00DBVPOY3IN0@asmtp029.mac.com> for freebsd-current@FreeBSD.ORG; Tue, 19 Oct 2010 09:27:02 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010190119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-19_07:2010-10-19, 2010-10-19, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <4CBDB17C.4040607@yandex.ru> Date: Tue, 19 Oct 2010 08:49:45 -0700 Message-id: <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , Xin LI Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 16:27:12 -0000 On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: > On 19.10.2010 09:03, Andrey V. Elsukov wrote: >>> Mounting from (...) failed with error 19 >>> >>> On boot. The system is using pure ZFS setup. It seems that 19 means >>> ENODEV but according to the dmesg the device do exist. >> >> Yes, i have the same problem. > > I fixed it with attached patch. Makes sense. "tank" (or its namesake) isn't a real device. Feel free to commit to unbreak things, but we may want to rethink this from a generality point of view. Listing exceptions doesn't scale and we now have 2 (the first was the empty device name as used by nfs, and now also zfs). Good catch, BTW. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 16:32:17 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 51DB5106566B; Tue, 19 Oct 2010 16:32:17 +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 1FB1C8FC12; Tue, 19 Oct 2010 16:32:17 +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 A186B46B9C; Tue, 19 Oct 2010 12:32:16 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF68A8A009; Tue, 19 Oct 2010 12:32:15 -0400 (EDT) From: John Baldwin To: Lars Engels Date: Tue, 19 Oct 2010 11:23:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101018174331.GA80017@sandvine.com> <201010190854.38626.jhb@freebsd.org> <20101019144056.GY34884@e.0x20.net> In-Reply-To: <20101019144056.GY34884@e.0x20.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010191123.00199.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 12:32:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ed Maste , freebsd-current@freebsd.org, Dan Nelson Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 19 Oct 2010 16:32:17 -0000 On Tuesday, October 19, 2010 10:40:56 am Lars Engels wrote: > On Tue, Oct 19, 2010 at 08:54:38AM -0400, John Baldwin wrote: > > On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > > > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > > cp_time value essentially won't roll over (at 1 billion increments per > > > > second it will roll over in 500 years; we currently increment 133 times per > > > > second, I think). If the value can be calculated accurately, it should be > > > > printed. > > > > > > Well, it won't roll over, but it's still different from all following > > > lines (in that it effectively shows user/system/idle CPU usage since > > > boot on the first line, and a snapshot over the last interval from then > > > on). I think it's still better to avoid printing it in that case. > > > > All of the first line is that way though. To do this "right" you'd need to > > blank out the entire first line. > > > > vm_stat and iostat on OS X have the current FreeBSD behavior (instant first > > line that summarizes all activity since uptime), so I'd be inclined to just > > leave the existing behavior. > > I'd be very happy if all vmstat and iostat would get a command line > switch to suppress the "summary since last reboot" line. > This information may be useful for some cases but in other cases, like > creating performance data for monitoring systems like Icinga / Nagios > one has to remove the first line(s) manually. I would be fine with that, but I wouldn't alter the format of that line by default. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 18:39: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 A5F76106564A for ; Tue, 19 Oct 2010 18:39:10 +0000 (UTC) (envelope-from matpockuh@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 498358FC17 for ; Tue, 19 Oct 2010 18:39:09 +0000 (UTC) Received: by qyk10 with SMTP id 10so559015qyk.13 for ; Tue, 19 Oct 2010 11:39: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:content-type; bh=63iJIygIDHPIbD9mKbBWn/vTHrnd2WBAx+5XMfthhcg=; b=CcJB8PRgGijloFK6cybHs20R+92LrW1ugrARt3f+kTr5w5H+dMCkzD3sAdk73HjtXl JgAJBAFJpSP+BFOQmNeRbr3f+xnQ1kpVTnPDzIU14fpgA6cL9ESky13t8e09NqwJAv3x eaM/CbZtCanMRQEESXEwtju7SQ+x0asRqcXf0= 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=aDXPNXdM9Z7QknlVxxmq8f7ZdF4USER6G36njFTDPKGGApKIVngDPulCYr7zLLTL/+ lv4avWxyT6aWWdHWkQvuauAzbu8Bj65/hVLKoh31hGL8lqcrPC3YoUND8MehgkWYpsXg 6TO2jxckal5X4d/8DOKhu/gOH2Uw8endOqSAs= MIME-Version: 1.0 Received: by 10.229.109.199 with SMTP id k7mr2160484qcp.267.1287512195774; Tue, 19 Oct 2010 11:16:35 -0700 (PDT) Received: by 10.229.248.201 with HTTP; Tue, 19 Oct 2010 11:16:35 -0700 (PDT) In-Reply-To: <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> Date: Tue, 19 Oct 2010 22:16:35 +0400 Message-ID: From: KOT MATPOCKuH To: FreeBSD Current Content-Type: multipart/mixed; boundary=0016364273ad12c0810492fc4b79 Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 18:39:10 -0000 --0016364273ad12c0810492fc4b79 Content-Type: text/plain; charset=ISO-8859-1 On my sparc64 system with today kernel I also got this problem. With old kernel system boots properly. boot -sv log attached. -- MATPOCKuH --0016364273ad12c0810492fc4b79 Content-Type: application/octet-stream; name="boot-sv.log" Content-Disposition: attachment; filename="boot-sv.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfh3hk3w0 Ck9LIGxzbW9kCiAweGMwMDAwMDAwOiAvYm9vdC9rZXJuZWwva2VybmVsIChlbGYga2VybmVsLCAw eDY4YjdjMCkKICBtb2R1bGVzOiBzc20uMSBuZXh1cy4xIG9md19wY2lidXMuMSBlYnVzLjEgYXV4 aW8uMSB1ZnMuMSBrZXJuZWxfbWFjX3N1cHBvcnQuNCBrcnBjLjEgbmZzbG9ja2QuMSBuZnMuMSBu ZnNsb2NrLjEgbmZzX2NvbW1vbi4xIGlmX3ZsYW4uMyBldGhlci4xIHN5c3ZzaG0uMSBzeXN2c2Vt LjEgc3lzdm1zZy4xIGZpcm13YXJlLjEga2VybmVsLjkwMDAyMyBpc2EuMSBwc2V1ZG9mcy4xIHVz Yl9xdWlyay4xIHVoaWQuMSB1Y29tLjEgdXBsY29tLjEgdWh1Yi4xIHVzYi4xIHVzYl9saW51eC4x IHVtYXNzLjEgcmFuZG9tLjEgcGNpLjEgbnVsbC4xIG1wdF91c2VyLjEgbXB0X3JhaWQuMSBtcHQu MSBtcHRfY2FtLjEgbXB0X2NvcmUuMSBtaWlidXMuMSBtZW0uMSBwZi4xIHBmbG9nLjEgY2FtLjEg CiAweGMwNjhjMDAwOiAvYm9vdC9rZXJuZWwvemZzLmtvIChlbGYgbW9kdWxlLCAweDJlMzcxOCkK ICBtb2R1bGVzOiB6ZnMuMSAKIDB4YzA5NzAwMDA6IC9ib290L2tlcm5lbC9vcGVuc29sYXJpcy5r byAoZWxmIG1vZHVsZSwgMHgxMDNmZDApCiAgbW9kdWxlczogb3BlbnNvbGFyaXMuMSAKIDB4YzBh NzNmZDA6IC9ib290L3pmcy96cG9vbC5jYWNoZSAoL2Jvb3QvemZzL3pwb29sLmNhY2hlLCAweDUx MCkKT0sgYm9vdCAtdiAtcwpqdW1waW5nIHRvIGtlcm5lbCBlbnRyeSBhdCAweGMwMDcwMDAwLgpD b3B5cmlnaHQgKGMpIDE5OTItMjAxMCBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMp IDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5 OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdo dHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJl ZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDkuMC1DVVJSRU5UICMxOTogVHVlIE9jdCAxOSAxODo1 OTowNiBNU0QgMjAxMAogICAgcm9vdEBzdW5yaXNlLW5ldzovdXNyL29iai91c3Ivc3JjL3N5cy9z dW5yaXNlIHNwYXJjNjQKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwi IGF0IDB4YzBhNzgwMDAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvemZzLmtv IiBhdCAweGMwYTc4MWEwLgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL29wZW5z b2xhcmlzLmtvIiBhdCAweGMwYTc4MjcwLgpQcmVsb2FkZWQgL2Jvb3QvemZzL3pwb29sLmNhY2hl ICIvYm9vdC96ZnMvenBvb2wuY2FjaGUiIGF0IDB4YzBhNzgzNDguCnJlYWwgbWVtb3J5ICA9IDIx NDc0ODM2NDggKDIwNDggTUIpCmF2YWlsIG1lbW9yeSA9IDIwODAzOTExNjggKDE5ODQgTUIpCm1h Y2hpbmU6IFNVTlcsU3VuLUZpcmUtVjIxNQpjcHUwOiBTdW4gTWljcm9zeXN0ZW1zIFVsdHJhU3Bh cmMtSUlJaSBQcm9jZXNzb3IgKDE1MDQuMDAgTUh6IENQVSkKICBtYXNrPTB4MzQgbWF4dGw9NSBt YXh3aW49Nwppbml0YWxpemluZyBpbnRyX2NvdW50cApjcHUxOiBTdW4gTWljcm9zeXN0ZW1zIFVs dHJhU3BhcmMtSUlJaSBQcm9jZXNzb3IgKDE1MDQuMDAgTUh6IENQVSkKICBtYXNrPTB4MzQgbWF4 dGw9NSBtYXh3aW49NwpJTlRSOiBBZGRpbmcgQ1BVIDEgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6 IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzClNlY3VyaXR5IHBvbGljeSBs b2FkZWQ6IFRydXN0ZWRCU0QgTUFDL3NlZW90aGVydWlkcyAobWFjX3NlZW90aGVydWlkcykKU2Vj dXJpdHkgcG9saWN5IGxvYWRlZDogVHJ1c3RlZEJTRCBNQUMvcG9ydGFjbCAobWFjX3BvcnRhY2wp CnJhbmRvbTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93PgpuZnNsb2NrOiBwc2V1 ZG8tZGV2aWNlCm9wZW5maXJtOiA8T3BlbiBGaXJtd2FyZSBjb250cm9sIGRldmljZT4Ka2JkMCBh dCBrYmRtdXgwCm1lbTogPG1lbW9yeT4KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4K bmV4dXMwOiA8T3BlbiBGaXJtd2FyZSBOZXh1cyBkZXZpY2U+CnBjaWIwOiA8U3VuIEhvc3QtUENJ ZSBicmlkZ2U+IG1lbSAweDQwMDBmNjAwMDAwLTB4NDAwMGY2ZWZmZmYsMHg0MDAwZjQxMDAwMC0w eDQwMDBmNDczZmZmIGlycSAxOTgzLDE5ODIgb24gbmV4dXMwCnBjaWIwOiBGaXJlLCBtb2R1bGUt cmV2aXNpb24gMywgSUdOIDB4MWUKVGltZWNvdW50ZXIgInBjaWIwIiBmcmVxdWVuY3kgMTg4MDAw MDAwIEh6IHF1YWxpdHkgLTEwMApwY2liMDogRFZNQSBtYXA6IDB4YzAwMDAwMDAgdG8gMHhmZmZm ZmZmZiAxMzEwNzIgZW50cmllcwpwY2liMDogUFJPTSBJT1RTQiBzaXplOiAwICgxMDI0IGVudHJp ZXMpCnBjaWIwOiBidXMgcmFuZ2UgMiB0byAxMzsgUENJIGJ1cyAyCnBjaTA6IDxPRlcgUENJIGJ1 cz4gb24gcGNpYjAKcGNpMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0yCmZvdW5kLT4JdmVuZG9y PTB4MTBiNSwgZGV2PTB4ODUzMiwgcmV2aWQ9MHhiYgoJZG9tYWluPTAsIGJ1cz0yLCBzbG90PTAs IGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4 MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBp bj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMSAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1T SSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdl IDMyLCBiYXNlIDB4MTAwMDAwLCBzaXplIDE3LCBlbmFibGVkCnBjaWIxOiA8T0ZXIFBDSWUtUENJ ZSBicmlkZ2U+IG1lbSAweDEwMDAwMC0weDExZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTAKcGNp YjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAzCnBj aWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEzCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4 MC0weDNmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHgyMDAwMDAtMHg1NWZmZmZmCnBj aWIxOiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaTE6IDxPRlcgUENJIGJ1cz4gb24gcGNpYjEK cGNpMTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0zCmZvdW5kLT4JdmVuZG9yPTB4MTBiNSwgZGV2 PTB4ODUzMiwgcmV2aWQ9MHhiYgoJZG9tYWluPTAsIGJ1cz0zLCBzbG90PTEsIGZ1bmM9MAoJY2xh c3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJl Zz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MjU1 Cglwb3dlcnNwZWMgMSAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAx IG1lc3NhZ2UsIDY0IGJpdApmb3VuZC0+CXZlbmRvcj0weDEwYjUsIGRldj0weDg1MzIsIHJldmlk PTB4YmIKCWRvbWFpbj0wLCBidXM9Mywgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBo ZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNo ZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDEg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBi aXQKZm91bmQtPgl2ZW5kb3I9MHgxMGI1LCBkZXY9MHg4NTMyLCByZXZpZD0weGJiCglkb21haW49 MCwgYnVzPTMsIHNsb3Q9OCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBt ZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAxICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CmZvdW5kLT4JdmVu ZG9yPTB4MTBiNSwgZGV2PTB4ODUzMiwgcmV2aWQ9MHhiYgoJZG9tYWluPTAsIGJ1cz0zLCBzbG90 PTksIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVn PTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWlu dHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMSAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAK CU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdApmb3VuZC0+CXZlbmRvcj0weDEwYjUsIGRl dj0weDg1MzIsIHJldmlkPTB4YmIKCWRvbWFpbj0wLCBidXM9Mywgc2xvdD0xMCwgZnVuYz0wCglj bGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0 cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0y NTUKCXBvd2Vyc3BlYyAxICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRz IDEgbWVzc2FnZSwgNjQgYml0CnBjaWIyOiA8T0ZXIFBDSWUtUENJZSBicmlkZ2U+IGF0IGRldmlj ZSAxLjAgb24gcGNpMQpwY2liMjogICBkb21haW4gICAgICAgICAgICAwCnBjaWIyOiAgIHNlY29u ZGFyeSBidXMgICAgIDQKcGNpYjI6ICAgc3Vib3JkaW5hdGUgYnVzICAgNQpwY2liMjogICBJL08g ZGVjb2RlICAgICAgICAweDAtMHgxZmZmCnBjaWIyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4MjAw MDAwLTB4M2ZmZmZmZgpwY2liMjogICBubyBwcmVmZXRjaGVkIGRlY29kZQpwY2kyOiA8T0ZXIFBD SSBidXM+IG9uIHBjaWIyCnBjaTI6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NApmb3VuZC0+CXZl bmRvcj0weDEwYjksIGRldj0weDUyNDksIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9NCwgc2xv dD0wLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgyMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgyMyAoODc1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJ cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCnBjaWIzOiA8T0ZXIFBDSWUt UENJZSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24gcGNpMgpwY2liMzogICBkb21haW4gICAgICAg ICAgICAwCnBjaWIzOiAgIHNlY29uZGFyeSBidXMgICAgIDUKcGNpYjM6ICAgc3Vib3JkaW5hdGUg YnVzICAgNQpwY2liMzogICBJL08gZGVjb2RlICAgICAgICAweDEwMDAtMHgxZmZmCnBjaWIzOiAg IG1lbW9yeSBkZWNvZGUgICAgIDB4MjAwMDAwLTB4M2ZmZmZmZgpwY2liMzogICBubyBwcmVmZXRj aGVkIGRlY29kZQpwY2liMzogICBTdWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdlLgpwY2kzOiA8 T0ZXIFBDSSBidXM+IG9uIHBjaWIzCnBjaTM6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NQpmb3Vu ZC0+CXZlbmRvcj0weDEwYjksIGRldj0weDUyMzcsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9 NSwgc2xvdD0yOCwgZnVuYz0wCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0x CgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHg1MCAo MjAwMDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQx IEQyIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCgltYXBbMTBdOiB0eXBl IE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHgxMDAwMDAwLCBzaXplIDEyLCBtZW1vcnkgZGlzYWJs ZWQKcGNpYjM6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHgxMDAwMDAwLTB4MTAwMGZmZjogZ29v ZApwY2liMjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDEwMDAwMDAtMHgxMDAwZmZmOiBnb29k CnBjaWIxOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4MTAwMDAwMC0weDEwMDBmZmY6IGdvb2QK Zm91bmQtPgl2ZW5kb3I9MHgxMGI5LCBkZXY9MHg1MjM3LCByZXZpZD0weDAzCglkb21haW49MCwg YnVzPTUsIHNsb3Q9MjgsIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0xNiAoZHdvcmRz KQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 NTAgKDIwMDAwIG5zKQoJaW50cGluPWIsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQoJbWFwWzEwXTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4MjAwMDAwMCwgc2l6ZSAxMiwgbWVtb3J5IGRp c2FibGVkCnBjaWIzOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4MjAwMDAwMC0weDIwMDBmZmY6 IGdvb2QKcGNpYjI6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHgyMDAwMDAwLTB4MjAwMGZmZjog Z29vZApwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDIwMDAwMDAtMHgyMDAwZmZmOiBn b29kCmZvdW5kLT4JdmVuZG9yPTB4MTBiOSwgZGV2PTB4NTIzOSwgcmV2aWQ9MHgwMQoJZG9tYWlu PTAsIGJ1cz01LCBzbG90PTI4LCBmdW5jPTMKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MTYgKGR3 b3JkcykKCWxhdHRpbWVyPTB4ODAgKDM4NDAgbnMpLCBtaW5nbnQ9MHgxMCAoNDAwMCBucyksIG1h eGxhdD0weDIwICg4MDAwIG5zKQoJaW50cGluPWQsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQoJbWFwWzEwXTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4MjAwMDAwLCBzaXplICA4LCBtZW1vcnkgZGlz YWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHgyMDAwMDAtMHgyMDAwZmY6IGdv b2QKcGNpYjI6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHgyMDAwMDAtMHgyMDAwZmY6IGdvb2QK cGNpYjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHgyMDAwMDAtMHgyMDAwZmY6IGdvb2QKZm91 bmQtPgl2ZW5kb3I9MHgxMGI5LCBkZXY9MHgxNTc1LCByZXZpZD0weDAwCglkb21haW49MCwgYnVz PTUsIHNsb3Q9MzAsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAyMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDA4ICgyNDAgbnMpLCBtaW5nbnQ9MHgwMSAoMjUwIG5zKSwgbWF4bGF0PTB4MTgg KDYwMDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTBiOSwgZGV2PTB4NTIyOSwgcmV2aWQ9MHhjOAoJ ZG9tYWluPTAsIGJ1cz01LCBzbG90PTMxLCBmdW5jPTAKCWNsYXNzPTAxLTAxLWZmLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9 MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQoJbWFwWzEwXTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxMDQwLCBzaXplICAzLCBwb3J0IGRpc2Fi bGVkCnBjaWIzOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MTA0MC0weDEwNDc6IGluIHJhbmdlCglt YXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDEwODAsIHNpemUgIDIsIGVu YWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgxMDgwLTB4MTA4MzogaW4gcmFuZ2UK CW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTBjMCwgc2l6ZSAgMywg ZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIEkvTyByYW5nZSAweDEwYzAtMHgxMGM3OiBpbiByYW5n ZQoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxMTAwLCBzaXplICAy LCBlbmFibGVkCnBjaWIzOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MTEwMC0weDExMDM6IGluIHJh bmdlCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDEwMDAsIHNpemUg IDQsIGVuYWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgxMDAwLTB4MTAwZjogaW4g cmFuZ2UKcGNpYjQ6IDxPRlcgUENJZS1QQ0llIGJyaWRnZT4gYXQgZGV2aWNlIDIuMCBvbiBwY2kx CnBjaWI0OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjQ6ICAgc2Vjb25kYXJ5IGJ1cyAgICAg NgpwY2liNDogICBzdWJvcmRpbmF0ZSBidXMgICA2CnBjaWI0OiAgIEkvTyBkZWNvZGUgICAgICAg IDB4MjAwMC0weDFmZmYKcGNpYjQ6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpNDogPE9GVyBQ Q0kgYnVzPiBvbiBwY2liNApwY2k0OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTYKcGNpYjU6IDxP RlcgUENJZS1QQ0llIGJyaWRnZT4gYXQgZGV2aWNlIDguMCBvbiBwY2kxCnBjaWI1OiAgIGRvbWFp biAgICAgICAgICAgIDAKcGNpYjU6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNwpwY2liNTogICBzdWJv cmRpbmF0ZSBidXMgICA3CnBjaWI1OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MjAwMC0weDFmZmYK cGNpYjU6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpNTogPE9GVyBQQ0kgYnVzPiBvbiBwY2li NQpwY2k1OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTcKcGNpYjY6IDxPRlcgUENJZS1QQ0llIGJy aWRnZT4gYXQgZGV2aWNlIDkuMCBvbiBwY2kxCnBjaWI2OiAgIGRvbWFpbiAgICAgICAgICAgIDAK cGNpYjY6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgOApwY2liNjogICBzdWJvcmRpbmF0ZSBidXMgICAx MApwY2liNjogICBJL08gZGVjb2RlICAgICAgICAweDIwMDAtMHgyZmZmCnBjaWI2OiAgIG1lbW9y eSBkZWNvZGUgICAgIDB4NDAwMDAwMC0weDRiZmZmZmYKcGNpYjY6ICAgbm8gcHJlZmV0Y2hlZCBk ZWNvZGUKcGNpNjogPE9GVyBQQ0kgYnVzPiBvbiBwY2liNgpwY2k2OiBkb21haW49MCwgcGh5c2lj YWwgYnVzPTgKZm91bmQtPgl2ZW5kb3I9MHgxMTY2LCBkZXY9MHgwMTAzLCByZXZpZD0weGI1Cglk b21haW49MCwgYnVzPTgsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0w eDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2 IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MjMgKDg3NTAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBE MApwY2liNzogPE9GVyBQQ0llLVBDSWUgYnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBjaTYKcGNp Yjc6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNzogICBzZWNvbmRhcnkgYnVzICAgICA5CnBj aWI3OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEwCnBjaWI3OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4 MjAwMC0weDJmZmYKcGNpYjc6ICAgbWVtb3J5IGRlY29kZSAgICAgMHg0MDAwMDAwLTB4NGJmZmZm ZgpwY2liNzogICBubyBwcmVmZXRjaGVkIGRlY29kZQpwY2k3OiA8T0ZXIFBDSSBidXM+IG9uIHBj aWI3CnBjaTc6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9OQpmb3VuZC0+CXZlbmRvcj0weDE0ZTQs IGRldj0weDE2NjgsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9OSwgc2xvdD00LCBmdW5jPTAK CWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDIsIHN0 YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4ZjggKDc0NDAg bnMpLCBtaW5nbnQ9MHg0MCAoMTYwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1h LCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBz dXBwb3J0cyA4IG1lc3NhZ2VzLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2 NCwgYmFzZSAweDQyMDAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjc6IHJlcXVlc3RlZCBtZW1v cnkgcmFuZ2UgMHg0MjAwMDAwLTB4NDIwZmZmZjogZ29vZApwY2liNjogcmVxdWVzdGVkIG1lbW9y eSByYW5nZSAweDQyMDAwMDAtMHg0MjBmZmZmOiBnb29kCnBjaWIxOiByZXF1ZXN0ZWQgbWVtb3J5 IHJhbmdlIDB4NDIwMDAwMC0weDQyMGZmZmY6IGdvb2QKCW1hcFsxOF06IHR5cGUgTWVtb3J5LCBy YW5nZSA2NCwgYmFzZSAweDQwMTAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjc6IHJlcXVlc3Rl ZCBtZW1vcnkgcmFuZ2UgMHg0MDEwMDAwLTB4NDAxZmZmZjogZ29vZApwY2liNjogcmVxdWVzdGVk IG1lbW9yeSByYW5nZSAweDQwMTAwMDAtMHg0MDFmZmZmOiBnb29kCnBjaWIxOiByZXF1ZXN0ZWQg bWVtb3J5IHJhbmdlIDB4NDAxMDAwMC0weDQwMWZmZmY6IGdvb2QKZm91bmQtPgl2ZW5kb3I9MHgx NGU0LCBkZXY9MHgxNjY4LCByZXZpZD0weGEzCglkb21haW49MCwgYnVzPTksIHNsb3Q9NCwgZnVu Yz0xCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAw LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weGY4ICg3 NDQwIG5zKSwgbWluZ250PTB4NDAgKDE2MDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw aW49YiwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgOCBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFu Z2UgNjQsIGJhc2UgMHg0NDAwMDAwLCBzaXplIDE2LCBtZW1vcnkgZGlzYWJsZWQKcGNpYjc6IHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg0NDAwMDAwLTB4NDQwZmZmZjogZ29vZApwY2liNjogcmVx dWVzdGVkIG1lbW9yeSByYW5nZSAweDQ0MDAwMDAtMHg0NDBmZmZmOiBnb29kCnBjaWIxOiByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NDQwMDAwMC0weDQ0MGZmZmY6IGdvb2QKCW1hcFsxOF06IHR5 cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweDQwMzAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNp Yjc6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg0MDMwMDAwLTB4NDAzZmZmZjogZ29vZApwY2li NjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDQwMzAwMDAtMHg0MDNmZmZmOiBnb29kCnBjaWIx OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NDAzMDAwMC0weDQwM2ZmZmY6IGdvb2QKZm91bmQt Pgl2ZW5kb3I9MHgxMTY2LCBkZXY9MHgwMTA0LCByZXZpZD0weGI0Cglkb21haW49MCwgYnVzPTks IHNsb3Q9OCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCglj bWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDIzMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0 aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MjMgKDg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKcGNpYjg6IDxPRlcgUENJZS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgOC4wIG9uIHBjaTcK cGNpYjg6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liODogICBzZWNvbmRhcnkgYnVzICAgICAx MApwY2liODogICBzdWJvcmRpbmF0ZSBidXMgICAxMApwY2liODogICBJL08gZGVjb2RlICAgICAg ICAweDIwMDAtMHgyZmZmCnBjaWI4OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4NDYwMDAwMC0weDRi ZmZmZmYKcGNpYjg6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpODogPE9GVyBQQ0kgYnVzPiBv biBwY2liOApwY2k4OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTEwCmZvdW5kLT4JdmVuZG9yPTB4 MTAwMCwgZGV2PTB4MDAzMCwgcmV2aWQ9MHgwOAoJZG9tYWluPTAsIGJ1cz0xMCwgc2xvdD0xLCBm dW5jPTAKCWNsYXNzPTAxLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAw MDIsIHN0YXRyZWc9MHgwMjMwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4ODAg KDM4NDAgbnMpLCBtaW5nbnQ9MHgxMCAoNDAwMCBucyksIG1heGxhdD0weDA2ICgxNTAwIG5zKQoJ aW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3Vy cmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIwMDAsIHNpemUgIDgsIHBvcnQgZGlzYWJsZWQKcGNp Yjg6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgyMDAwLTB4MjBmZjogaW4gcmFuZ2UKcGNpYjc6IHJl cXVlc3RlZCBJL08gcmFuZ2UgMHgyMDAwLTB4MjBmZjogaW4gcmFuZ2UKcGNpYjY6IHJlcXVlc3Rl ZCBJL08gcmFuZ2UgMHgyMDAwLTB4MjBmZjogaW4gcmFuZ2UKCW1hcFsxNF06IHR5cGUgTWVtb3J5 LCByYW5nZSA2NCwgYmFzZSAweDQ2MDAwMDAsIHNpemUgMTcsIGVuYWJsZWQKcGNpYjg6IHJlcXVl c3RlZCBtZW1vcnkgcmFuZ2UgMHg0NjAwMDAwLTB4NDYxZmZmZjogZ29vZApwY2liNzogcmVxdWVz dGVkIG1lbW9yeSByYW5nZSAweDQ2MDAwMDAtMHg0NjFmZmZmOiBnb29kCnBjaWI2OiByZXF1ZXN0 ZWQgbWVtb3J5IHJhbmdlIDB4NDYwMDAwMC0weDQ2MWZmZmY6IGdvb2QKcGNpYjE6IHJlcXVlc3Rl ZCBtZW1vcnkgcmFuZ2UgMHg0NjAwMDAwLTB4NDYxZmZmZjogZ29vZAoJbWFwWzFjXTogdHlwZSBN ZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4NDYyMDAwMCwgc2l6ZSAxNywgZW5hYmxlZApwY2liODog cmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDQ2MjAwMDAtMHg0NjNmZmZmOiBnb29kCnBjaWI3OiBy ZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NDYyMDAwMC0weDQ2M2ZmZmY6IGdvb2QKcGNpYjY6IHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg0NjIwMDAwLTB4NDYzZmZmZjogZ29vZApwY2liMTogcmVx dWVzdGVkIG1lbW9yeSByYW5nZSAweDQ2MjAwMDAtMHg0NjNmZmZmOiBnb29kCnBjaWI5OiA8T0ZX IFBDSWUtUENJZSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTEKcGNpYjk6ICAgZG9tYWlu ICAgICAgICAgICAgMApwY2liOTogICBzZWNvbmRhcnkgYnVzICAgICAxMQpwY2liOTogICBzdWJv cmRpbmF0ZSBidXMgICAxMwpwY2liOTogICBJL08gZGVjb2RlICAgICAgICAweDMwMDAtMHgzZmZm CnBjaWI5OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4NGMwMDAwMC0weDU1ZmZmZmYKcGNpYjk6ICAg bm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpOTogPE9GVyBQQ0kgYnVzPiBvbiBwY2liOQpwY2k5OiBk b21haW49MCwgcGh5c2ljYWwgYnVzPTExCmZvdW5kLT4JdmVuZG9yPTB4MTE2NiwgZGV2PTB4MDEw MywgcmV2aWQ9MHhiNQoJZG9tYWluPTAsIGJ1cz0xMSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2 LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgw MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgyMyAoODc1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCnBjaWIxMDogPE9GVyBQQ0llLVBDSWUgYnJpZGdlPiBhdCBkZXZp Y2UgMC4wIG9uIHBjaTkKcGNpYjEwOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjEwOiAgIHNl Y29uZGFyeSBidXMgICAgIDEyCnBjaWIxMDogICBzdWJvcmRpbmF0ZSBidXMgICAxMwpwY2liMTA6 ICAgSS9PIGRlY29kZSAgICAgICAgMHgzMDAwLTB4M2ZmZgpwY2liMTA6ICAgbWVtb3J5IGRlY29k ZSAgICAgMHg0YzAwMDAwLTB4NTVmZmZmZgpwY2liMTA6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUK cGNpMTA6IDxPRlcgUENJIGJ1cz4gb24gcGNpYjEwCnBjaTEwOiBkb21haW49MCwgcGh5c2ljYWwg YnVzPTEyCmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4MTY2OCwgcmV2aWQ9MHhhMwoJZG9t YWluPTAsIGJ1cz0xMiwgc2xvdD00LCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDIsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MTYg KGR3b3JkcykKCWxhdHRpbWVyPTB4ZjggKDc0NDAgbnMpLCBtaW5nbnQ9MHg0MCAoMTYwMDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyA4IG1lc3NhZ2VzLCA2NCBiaXQK CW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweDRlMDAwMDAsIHNpemUgMTYs IGVuYWJsZWQKcGNpYjEwOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NGUwMDAwMC0weDRlMGZm ZmY6IGdvb2QKcGNpYjk6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg0ZTAwMDAwLTB4NGUwZmZm ZjogZ29vZApwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDRlMDAwMDAtMHg0ZTBmZmZm OiBnb29kCgltYXBbMThdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHg0YzEwMDAwLCBz aXplIDE2LCBlbmFibGVkCnBjaWIxMDogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDRjMTAwMDAt MHg0YzFmZmZmOiBnb29kCnBjaWI5OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NGMxMDAwMC0w eDRjMWZmZmY6IGdvb2QKcGNpYjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg0YzEwMDAwLTB4 NGMxZmZmZjogZ29vZApmb3VuZC0+CXZlbmRvcj0weDE0ZTQsIGRldj0weDE2NjgsIHJldmlkPTB4 YTMKCWRvbWFpbj0wLCBidXM9MTIsIHNsb3Q9NCwgZnVuYz0xCgljbGFzcz0wMi0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVs bnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weGY4ICg3NDQwIG5zKSwgbWluZ250PTB4NDAgKDE2 MDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTI1NQoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgOCBtZXNzYWdlcywg NjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHg1MDAwMDAwLCBz aXplIDE2LCBtZW1vcnkgZGlzYWJsZWQKcGNpYjEwOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4 NTAwMDAwMC0weDUwMGZmZmY6IGdvb2QKcGNpYjk6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg1 MDAwMDAwLTB4NTAwZmZmZjogZ29vZApwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDUw MDAwMDAtMHg1MDBmZmZmOiBnb29kCgltYXBbMThdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJh c2UgMHg0YzMwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWIxMDogcmVxdWVzdGVkIG1lbW9yeSBy YW5nZSAweDRjMzAwMDAtMHg0YzNmZmZmOiBnb29kCnBjaWI5OiByZXF1ZXN0ZWQgbWVtb3J5IHJh bmdlIDB4NGMzMDAwMC0weDRjM2ZmZmY6IGdvb2QKcGNpYjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFu Z2UgMHg0YzMwMDAwLTB4NGMzZmZmZjogZ29vZApmb3VuZC0+CXZlbmRvcj0weDExNjYsIGRldj0w eDAxMDQsIHJldmlkPTB4YjQKCWRvbWFpbj0wLCBidXM9MTIsIHNsb3Q9OCwgZnVuYz0wCgljbGFz cz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVn PTB4MDIzMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwg bWluZ250PTB4MjMgKDg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpYjExOiA8T0ZXIFBD SWUtUENJIGJyaWRnZT4gYXQgZGV2aWNlIDguMCBvbiBwY2kxMApwY2liMTE6ICAgZG9tYWluICAg ICAgICAgICAgMApwY2liMTE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTMKcGNpYjExOiAgIHN1Ym9y ZGluYXRlIGJ1cyAgIDEzCnBjaWIxMTogICBJL08gZGVjb2RlICAgICAgICAweDMwMDAtMHgzZmZm CnBjaWIxMTogICBtZW1vcnkgZGVjb2RlICAgICAweDUyMDAwMDAtMHg1NWZmZmZmCnBjaWIxMTog ICBubyBwcmVmZXRjaGVkIGRlY29kZQpwY2kxMTogPE9GVyBQQ0kgYnVzPiBvbiBwY2liMTEKcGNp MTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MTMKZm91bmQtPgl2ZW5kb3I9MHgxMDAwLCBkZXY9 MHgwMDUwLCByZXZpZD0weDAyCglkb21haW49MCwgYnVzPTEzLCBzbG90PTEsIGZ1bmM9MAoJY2xh c3M9MDEtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAxNiwgc3RhdHJl Zz0weDAyMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHhmOCAoNzQ0MCBucyks IG1pbmdudD0weDQwICgxNjAwMCBucyksIG1heGxhdD0weDBhICgyNTAwIG5zKQoJaW50cGluPWEs IGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJ TVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCBy YW5nZSAzMiwgYmFzZSAweDMwMDAsIHNpemUgIDgsIHBvcnQgZGlzYWJsZWQKcGNpYjExOiByZXF1 ZXN0ZWQgSS9PIHJhbmdlIDB4MzAwMC0weDMwZmY6IGluIHJhbmdlCnBjaWIxMDogcmVxdWVzdGVk IEkvTyByYW5nZSAweDMwMDAtMHgzMGZmOiBpbiByYW5nZQpwY2liOTogcmVxdWVzdGVkIEkvTyBy YW5nZSAweDMwMDAtMHgzMGZmOiBpbiByYW5nZQoJbWFwWzE0XTogdHlwZSBNZW1vcnksIHJhbmdl IDY0LCBiYXNlIDB4NTIwMDAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMTE6IHJlcXVlc3RlZCBt ZW1vcnkgcmFuZ2UgMHg1MjAwMDAwLTB4NTIwM2ZmZjogZ29vZApwY2liMTA6IHJlcXVlc3RlZCBt ZW1vcnkgcmFuZ2UgMHg1MjAwMDAwLTB4NTIwM2ZmZjogZ29vZApwY2liOTogcmVxdWVzdGVkIG1l bW9yeSByYW5nZSAweDUyMDAwMDAtMHg1MjAzZmZmOiBnb29kCnBjaWIxOiByZXF1ZXN0ZWQgbWVt b3J5IHJhbmdlIDB4NTIwMDAwMC0weDUyMDNmZmY6IGdvb2QKCW1hcFsxY106IHR5cGUgTWVtb3J5 LCByYW5nZSA2NCwgYmFzZSAweDUyMTAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjExOiByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NTIxMDAwMC0weDUyMWZmZmY6IGdvb2QKcGNpYjEwOiByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NTIxMDAwMC0weDUyMWZmZmY6IGdvb2QKcGNpYjk6IHJlcXVl c3RlZCBtZW1vcnkgcmFuZ2UgMHg1MjEwMDAwLTB4NTIxZmZmZjogZ29vZApwY2liMTogcmVxdWVz dGVkIG1lbW9yeSByYW5nZSAweDUyMTAwMDAtMHg1MjFmZmZmOiBnb29kCnBjaWIxMjogPFN1biBI b3N0LVBDSWUgYnJpZGdlPiBtZW0gMHg0MDAwZmYwMDAwMC0weDQwMDBmZmVmZmZmLDB4NDAwMGZj MTAwMDAtMHg0MDAwZmM3M2ZmZiBpcnEgMjA0NywyMDQ2IG9uIG5leHVzMApwY2liMTI6IEZpcmUs IG1vZHVsZS1yZXZpc2lvbiAzLCBJR04gMHgxZgpwY2liMTI6IERWTUEgbWFwOiAweGMwMDAwMDAw IHRvIDB4ZmZmZmZmZmYgMTMxMDcyIGVudHJpZXMKcGNpYjEyOiBQUk9NIElPVFNCIHNpemU6IDAg KDEwMjQgZW50cmllcykKcGNpYjEyOiBidXMgcmFuZ2UgMiB0byAyNTU7IFBDSSBidXMgMgpwY2kx MjogPE9GVyBQQ0kgYnVzPiBvbiBwY2liMTIKcGNpMTI6IGRvbWFpbj0xMiwgcGh5c2ljYWwgYnVz PTIKZWJ1czA6IDxKQnVzLUVCdXMgYnJpZGdlPiBtZW0gMHg0MDAwZmM2NDAwMC0weDQwMDBmYzY0 MDFmIG9uIG5leHVzMApuZXh1czA6IDxtZW1vcnktY29udHJvbGxlcj4gbWVtIDB4NDAwMDAwMDAw MDAtMHg0MDAwMDAwMDAwNyB0eXBlIG1lbW9yeS1jb250cm9sbGVyIChubyBkcml2ZXIgYXR0YWNo ZWQpCm5leHVzMDogPG1lbW9yeS1jb250cm9sbGVyPiBtZW0gMHg0MDAwMDgwMDAwMC0weDQwMDAw ODAwMDA3IHR5cGUgbWVtb3J5LWNvbnRyb2xsZXIgKG5vIGRyaXZlciBhdHRhY2hlZCkKb2hjaTA6 IDxBY2VyTGFicyBNNTIzNyAoQWxhZGRpbi1WKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4MTAwMDAw MC0weDEwMDBmZmYgYXQgZGV2aWNlIDI4LjAgb24gcGNpMwp1c2J1czA6IDxBY2VyTGFicyBNNTIz NyAoQWxhZGRpbi1WKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTAKb2hjaTE6IDxBY2VyTGFicyBN NTIzNyAoQWxhZGRpbi1WKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4MjAwMDAwMC0weDIwMDBmZmYg YXQgZGV2aWNlIDI4LjEgb24gcGNpMwp1c2J1czE6IDxBY2VyTGFicyBNNTIzNyAoQWxhZGRpbi1W KSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTEKZWhjaTA6IDxBTGkgTTUyMzkgVVNCIDIuMCBjb250 cm9sbGVyPiBtZW0gMHgyMDAwMDAtMHgyMDAwZmYgYXQgZGV2aWNlIDI4LjMgb24gcGNpMwp1c2J1 czI6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMyOiA8QUxpIE01MjM5IFVTQiAyLjAgY29udHJvbGxl cj4gb24gZWhjaTAKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNp Mwppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNpMzogPG1hc3Mgc3RvcmFnZSwgQVRBPiBhdCBk ZXZpY2UgMzEuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpiZ2UwOiA8QnJvYWRjb20gQkNNNTcxNSBB MywgQVNJQyByZXYuIDB4MDA5MDAzPiBtZW0gMHg0MjAwMDAwLTB4NDIwZmZmZiwweDQwMTAwMDAt MHg0MDFmZmZmIGF0IGRldmljZSA0LjAgb24gcGNpNwpiZ2UwOiBhdHRlbXB0aW5nIHRvIGFsbG9j YXRlIDEgTVNJIHZlY3RvcnMgKDggc3VwcG9ydGVkKQpiZ2UwOiB1c2luZyBJUlEgMCBmb3IgTVNJ CmJnZTA6IENISVAgSUQgMHgwMDAwOTAwMzsgQVNJQyBSRVYgMHgwOTsgQ0hJUCBSRVYgMHg5MDsg UENJLVgKbWlpYnVzMDogPE1JSSBidXM+IG9uIGJnZTAKYnJncGh5MDogPEJDTTU3MTQgMTAvMTAw LzEwMDBiYXNlVFggUEhZPiBQSFkgMSBvbiBtaWlidXMwCmJyZ3BoeTA6IE9VSSAweDAwMDgxOCwg bW9kZWwgMHgwMDM0LCByZXYuIDAKYnJncGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBi YXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bwpiZ2Uw OiBicGYgYXR0YWNoZWQKYmdlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTQ6NGY6YTI6ZWY6MmMK YmdlMTogPEJyb2FkY29tIEJDTTU3MTUgQTMsIEFTSUMgcmV2LiAweDAwOTAwMz4gbWVtIDB4NDQw MDAwMC0weDQ0MGZmZmYsMHg0MDMwMDAwLTB4NDAzZmZmZiBhdCBkZXZpY2UgNC4xIG9uIHBjaTcK YmdlMTogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICg4IHN1cHBvcnRlZCkK YmdlMTogdXNpbmcgSVJRIDEgZm9yIE1TSQpiZ2UxOiBDSElQIElEIDB4MDAwMDkwMDM7IEFTSUMg UkVWIDB4MDk7IENISVAgUkVWIDB4OTA7IFBDSS1YCm1paWJ1czE6IDxNSUkgYnVzPiBvbiBiZ2Ux CmJyZ3BoeTE6IDxCQ001NzE0IDEwLzEwMC8xMDAwYmFzZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVz MQpicmdwaHkxOiBPVUkgMHgwMDA4MTgsIG1vZGVsIDB4MDAzNCwgcmV2LiAwCmJyZ3BoeTE6ICAx MGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQs IDEwMDBiYXNlVC1GRFgsIGF1dG8KYmdlMTogYnBmIGF0dGFjaGVkCmJnZTE6IEV0aGVybmV0IGFk ZHJlc3M6IDAwOjE0OjRmOmEyOmVmOjJkCm1wdDA6IDxMU0lMb2dpYyAxMDMwIFVsdHJhNCBBZGFw dGVyPiBwb3J0IDB4MjAwMC0weDIwZmYgbWVtIDB4NDYwMDAwMC0weDQ2MWZmZmYsMHg0NjIwMDAw LTB4NDYzZmZmZiBhdCBkZXZpY2UgMS4wIG9uIHBjaTgKbXB0MDogTVBJIFZlcnNpb249MS4yLjE0 LjAKbXB0MDogY2hhaW4gZGVwdGggbGltaXRlZCB0byA0OCAoZnJvbSAyNTUwKQptcHQwOiBNYXhp bXVtIFNlZ21lbnQgQ291bnQ6IDMzNiwgTWF4aW11bSBDQU0gU2VnbWVudCBDb3VudDogMTcKbXB0 MDogTXNnTGVuZ3RoPTE1IElPQ051bWJlciA9IDAKbXB0MDogSU9DRkFDVFM6IEdsb2JhbENyZWRp dHM9MjU1IEJsb2NrU2l6ZT04IGJ5dGVzIFJlcXVlc3QgRnJhbWUgU2l6ZSA5NiBieXRlcyBNYXgg Q2hhaW4gRGVwdGggNDgKbXB0MDogSU9DRkFDVFM6IE51bSBQb3J0cyAxLCBGV0ltYWdlU2l6ZSA0 MDc1MiwgRmxhZ3M9MAptcHQwOiBObyBIYW5kbGVycyBGb3IgQW55IEV2ZW50IE5vdGlmeSBGcmFt ZXMuIEV2ZW50IDB4YSAoQUNLIG5vdCByZXF1aXJlZCkuCm1wdDA6IE5vIEhhbmRsZXJzIEZvciBB bnkgRXZlbnQgTm90aWZ5IEZyYW1lcy4gRXZlbnQgMHhhIChBQ0sgbm90IHJlcXVpcmVkKS4KYmdl MjogPEJyb2FkY29tIEJDTTU3MTUgQTMsIEFTSUMgcmV2LiAweDAwOTAwMz4gbWVtIDB4NGUwMDAw MC0weDRlMGZmZmYsMHg0YzEwMDAwLTB4NGMxZmZmZiBhdCBkZXZpY2UgNC4wIG9uIHBjaTEwCmJn ZTI6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBNU0kgdmVjdG9ycyAoOCBzdXBwb3J0ZWQpCmJn ZTI6IHVzaW5nIElSUSAyIGZvciBNU0kKYmdlMjogQ0hJUCBJRCAweDAwMDA5MDAzOyBBU0lDIFJF ViAweDA5OyBDSElQIFJFViAweDkwOyBQQ0ktWAptaWlidXMyOiA8TUlJIGJ1cz4gb24gYmdlMgpi cmdwaHkyOiA8QkNNNTcxNCAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czIK YnJncGh5MjogT1VJIDB4MDAwODE4LCBtb2RlbCAweDAwMzQsIHJldi4gMApicmdwaHkyOiAgMTBi YXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCAx MDAwYmFzZVQtRkRYLCBhdXRvCmJnZTI6IGJwZiBhdHRhY2hlZApiZ2UyOiBFdGhlcm5ldCBhZGRy ZXNzOiAwMDoxNDo0ZjphMjplZjoyZQpiZ2UzOiA8QnJvYWRjb20gQkNNNTcxNSBBMywgQVNJQyBy ZXYuIDB4MDA5MDAzPiBtZW0gMHg1MDAwMDAwLTB4NTAwZmZmZiwweDRjMzAwMDAtMHg0YzNmZmZm IGF0IGRldmljZSA0LjEgb24gcGNpMTAKYmdlMzogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1T SSB2ZWN0b3JzICg4IHN1cHBvcnRlZCkKYmdlMzogdXNpbmcgSVJRIDMgZm9yIE1TSQpiZ2UzOiBD SElQIElEIDB4MDAwMDkwMDM7IEFTSUMgUkVWIDB4MDk7IENISVAgUkVWIDB4OTA7IFBDSS1YCm1p aWJ1czM6IDxNSUkgYnVzPiBvbiBiZ2UzCmJyZ3BoeTM6IDxCQ001NzE0IDEwLzEwMC8xMDAwYmFz ZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVzMwpicmdwaHkzOiBPVUkgMHgwMDA4MTgsIG1vZGVsIDB4 MDAzNCwgcmV2LiAwCmJyZ3BoeTM6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAx MDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8KYmdlMzogYnBmIGF0 dGFjaGVkCmJnZTM6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE0OjRmOmEyOmVmOjJmCm1wdDE6IDxM U0lMb2dpYyBTQVMvU0FUQSBBZGFwdGVyPiBwb3J0IDB4MzAwMC0weDMwZmYgbWVtIDB4NTIwMDAw MC0weDUyMDNmZmYsMHg1MjEwMDAwLTB4NTIxZmZmZiBhdCBkZXZpY2UgMS4wIG9uIHBjaTExCm1w dDE6IE1QSSBWZXJzaW9uPTEuNS4xMi4wCm1wdDE6IGNoYWluIGRlcHRoIGxpbWl0ZWQgdG8gOTYg KGZyb20gMjA0MCkKbXB0MTogTWF4aW11bSBTZWdtZW50IENvdW50OiA4NjQsIE1heGltdW0gQ0FN IFNlZ21lbnQgQ291bnQ6IDE3Cm1wdDE6IE1zZ0xlbmd0aD0yMCBJT0NOdW1iZXIgPSAwCm1wdDE6 IElPQ0ZBQ1RTOiBHbG9iYWxDcmVkaXRzPTUxMSBCbG9ja1NpemU9OCBieXRlcyBSZXF1ZXN0IEZy YW1lIFNpemUgMTI4IGJ5dGVzIE1heCBDaGFpbiBEZXB0aCA5NgptcHQxOiBJT0NGQUNUUzogTnVt IFBvcnRzIDEsIEZXSW1hZ2VTaXplIDAsIEZsYWdzPTAKbXB0MTogTm8gSGFuZGxlcnMgRm9yIEFu eSBFdmVudCBOb3RpZnkgRnJhbWVzLiBFdmVudCAweGEgKEFDSyBub3QgcmVxdWlyZWQpLgptcHQx OiBObyBIYW5kbGVycyBGb3IgQW55IEV2ZW50IE5vdGlmeSBGcmFtZXMuIEV2ZW50IDB4MTIgKEFD SyBub3QgcmVxdWlyZWQpLgptcHQxOiBObyBIYW5kbGVycyBGb3IgQW55IEV2ZW50IE5vdGlmeSBG cmFtZXMuIEV2ZW50IDB4MTIgKEFDSyBub3QgcmVxdWlyZWQpLgptcHQxOiBObyBIYW5kbGVycyBG b3IgQW55IEV2ZW50IE5vdGlmeSBGcmFtZXMuIEV2ZW50IDB4ZiAoQUNLIHJlcXVpcmVkKS4KbXB0 MTogTm8gSGFuZGxlcnMgRm9yIEFueSBFdmVudCBOb3RpZnkgRnJhbWVzLiBFdmVudCAweGYgKEFD SyByZXF1aXJlZCkuCm1wdDE6IENhcGFiaWxpdGllczogKCBSQUlELTAgUkFJRC0xRSBSQUlELTEg KQptcHQxOiAwIEFjdGl2ZSBWb2x1bWVzICgyIE1heCkKbXB0MTogMCBIaWRkZW4gRHJpdmUgTWVt YmVycyAoMTAgTWF4KQptcHQxOiBObyBIYW5kbGVycyBGb3IgQW55IEV2ZW50IE5vdGlmeSBGcmFt ZXMuIEV2ZW50IDB4YSAoQUNLIG5vdCByZXF1aXJlZCkuCmVidXMwOiA8Zmxhc2hwcm9tPiBhZGRy IDAtMHgxZmZmZmYgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWFydDA6IDwxNjU1MCBvciBjb21wYXRp YmxlPiBhZGRyIDB4MjAwMDAwMDgwLTB4MjAwMDAwMDg3IGlycSAxOTkyIG9uIGVidXMwCnVhcnQw OiBmYXN0IGludGVycnVwdAp1YXJ0MDogY29uc29sZSAoOTYwMCxuLDgsMSkKdWFydDE6IDwxNjU1 MCBvciBjb21wYXRpYmxlPiBhZGRyIDB4MjAwMDAwMDQwLTB4MjAwMDAwMDQ3IGlycSAxOTkzIG9u IGVidXMwCnVhcnQxOiBmYXN0IGludGVycnVwdAplYnVzMDogPHJtYy1jb21tPiBhZGRyIDB4MjAw MDAwMDAwLTB4MjAwMDAwMDA3IGlycSAxOTk0IChubyBkcml2ZXIgYXR0YWNoZWQpCmVidXMwOiA8 Z3Bpbz4gYWRkciAweDIwMDAwMDBjMCAobm8gZHJpdmVyIGF0dGFjaGVkKQplcGljMDogPFN1biBG aXJlIFYyMTUvVjI0NSBMRURzPiBhZGRyIDB4MzAwMDAwMDAwLTB4MzAwMDAwMDgwIG9uIGVidXMw CmVwaWMwOiB2ZXJzaW9uIDB4NWEKZWJ1czA6IDxwb3dlcj4gYWRkciAweDMwMDAwMDA0MC0weDMw MDAwMDBjMSBpcnEgMTk4NyAobm8gZHJpdmVyIGF0dGFjaGVkKQpuZXh1czA6IDxpMmM+IG1lbSAw eDQwMDBmZDMwMDAwLTB4NDAwMGZkMzAwM2YgaXJxIDE5ODUgdHlwZSBpMmMgKG5vIGRyaXZlciBh dHRhY2hlZCkKc3lzY29uczA6IG5vIHZpZGVvIGFkYXB0ZXIgZm91bmQuCm5leHVzMDogPHN5c2Nv bnM+IHR5cGUgdW5rbm93biAobm8gZHJpdmVyIGF0dGFjaGVkKQpydGMwOiA8UmVhbC1UaW1lIENs b2NrPiBhdCBwb3J0IDB4NzAtMHg3MyBvbiBpc2EwCnBjaWIzOiBydGMwIHJlcXVlc3RlZCBJL08g cmFuZ2UgMHg3MC0weDczOiBpbiByYW5nZQpydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1k YXkgY2xvY2sgKHJlc29sdXRpb24gMTAwMDAwMHVzLCBhZGp1c3RtZW50IDAuNTAwMDAwMDAwcykK Y3RfdG9fdHMoWzIwMTAtMTAtMTkgMTc6MTQ6MTBdKSA9IDEyODc1MDg0NTAuMDAwMDAwMDAwCnJ0 YzA6IGN1cnJlbnQgdGltZTogMTI4NzUwODQ1MC4wMDAwMDAwMDAKWkZTIE5PVElDRTogUHJlZmV0 Y2ggaXMgZGlzYWJsZWQgYnkgZGVmYXVsdCBpZiBsZXNzIHRoYW4gNEdCIG9mIFJBTSBpcyBwcmVz ZW50OwogICAgICAgICAgICB0byBlbmFibGUsIGFkZCAidmZzLnpmcy5wcmVmZXRjaF9kaXNhYmxl PTAiIHRvIC9ib290L2xvYWRlci5jb25mLgpaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uIDQKWkZTIHN0 b3JhZ2UgcG9vbCB2ZXJzaW9uIDE1ClRpbWVjb3VudGVyICJ0aWNrIiBmcmVxdWVuY3kgMTUwNDAw MDAwMCBIeiBxdWFsaXR5IDEwClRpbWVjb3VudGVyICJzdGljayIgZnJlcXVlbmN5IDIwMDAwMDAw IEh6IHF1YWxpdHkgMTAKRXZlbnQgdGltZXIgInRpY2siIGZyZXF1ZW5jeSAxNTA0MDAwMDAwIEh6 IHF1YWxpdHkgMTAwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCnZsYW46IGlu aXRpYWxpemVkLCB1c2luZyBoYXNoIHRhYmxlcyB3aXRoIGNoYWluaW5nCmxvMDogYnBmIGF0dGFj aGVkCnBmbG9nMDogYnBmIGF0dGFjaGVkCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1Z2VuMC4xOiA8QWNlckxhYnM+ IGF0IHVzYnVzMAp1aHViMDogPEFjZXJMYWJzIE9IQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEFjZXJMYWJzPiBhdCB1c2J1 czEKdWh1YjE6IDxBY2VyTGFicyBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNidXMxCnVzYnVzMjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4w Cihub3BlcmlwaDptcHQwOjA6LTE6LTEpOiByZXNldCBidXMKdWdlbjIuMTogPEFjZXJMYWJzPiBh dCB1c2J1czIKdWh1YjI6IDxBY2VyTGFicyBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAy LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKKHByb2JlNjQ6bXB0MToxOjA6MCk6IEVycm9yIDIyLCBVbnJldHJ5YWJsZSBlcnJvcgoo cHJvYmU2NTptcHQxOjE6MTowKTogRXJyb3IgMjIsIFVucmV0cnlhYmxlIGVycm9yCihwcm9iZTY2 Om1wdDE6MToyOjApOiBFcnJvciAyMiwgVW5yZXRyeWFibGUgZXJyb3IKKHByb2JlNjc6bXB0MTox OjM6MCk6IEVycm9yIDIyLCBVbnJldHJ5YWJsZSBlcnJvcgoocHJvYmU2ODptcHQxOjE6NDowKTog RXJyb3IgMjIsIFVucmV0cnlhYmxlIGVycm9yCihwcm9iZTY5Om1wdDE6MTo1OjApOiBFcnJvciAy MiwgVW5yZXRyeWFibGUgZXJyb3IKKHByb2JlNzA6bXB0MToxOjY6MCk6IEVycm9yIDIyLCBVbnJl dHJ5YWJsZSBlcnJvcgoocHJvYmU3MTptcHQxOjE6NzowKTogRXJyb3IgMjIsIFVucmV0cnlhYmxl IGVycm9yCihwcm9iZTcyOm1wdDE6MTo4OjApOiBFcnJvciAyMiwgVW5yZXRyeWFibGUgZXJyb3IK KHByb2JlNzM6bXB0MToxOjk6MCk6IEVycm9yIDIyLCBVbnJldHJ5YWJsZSBlcnJvcgp1aHViMjog OCBwb3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGFzczAgYXQgbXB0MSBidXMg MCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKcGFzczA6IDxGVUpJVFNVIE1BWTIwNzNSQ1NVTjcyRyAw NTAxPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNCBkZXZpY2UgCnBhc3MwOiBTZXJpYWwgTnVt YmVyIDAwMDczM1MwRDZQSwpwYXNzMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzCnBhc3MwOiBDb21t YW5kIFF1ZXVlaW5nIGVuYWJsZWQKcGFzczEgYXQgbXB0MSBidXMgMCBzY2J1czEgdGFyZ2V0IDEg bHVuIDAKcGFzczE6IDxGVUpJVFNVIE1BWTIwNzNSQ1NVTjcyRyAwNTAxPiBGaXhlZCBEaXJlY3Qg QWNjZXNzIFNDU0ktNCBkZXZpY2UgCnBhc3MxOiBTZXJpYWwgTnVtYmVyIDAwMDczM1MwRDczUwpw YXNzMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzCnBhc3MxOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJs ZWQKR0VPTTogbmV3IGRpc2sgZGEwCkdFT006IG5ldyBkaXNrIGRhMQpkYTAgYXQgbXB0MSBidXMg MCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8RlVKSVRTVSBNQVkyMDczUkNTVU43MkcgMDUw MT4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTQgZGV2aWNlIApkYTA6IFNlcmlhbCBOdW1iZXIg MDAwNzMzUzBENlBLCmRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogQ29tbWFuZCBRdWV1 ZWluZyBlbmFibGVkCmRhMDogNzAwMDdNQiAoMTQzMzc0NzM4IDUxMiBieXRlIHNlY3RvcnM6IDI1 NUggNjNTL1QgODkyNEMpCmRhMSBhdCBtcHQxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMSBsdW4gMApk YTE6IDxGVUpJVFNVIE1BWTIwNzNSQ1NVTjcyRyAwNTAxPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFND U0ktNCBkZXZpY2UgCmRhMTogU2VyaWFsIE51bWJlciAwMDA3MzNTMEQ3M1MKZGExOiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMKZGExOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGExOiA3MDAwN01C ICgxNDMzNzQ3MzggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA4OTI0QykKU01QOiBBUCBD UFUgIzEgTGF1bmNoZWQhCkdFT01fTUlSUk9SOiBEZXZpY2UgbWlycm9yL2Jvb3QgbGF1bmNoZWQg KDIvMikuCkdFT006IG1pcnJvci9ib290OiBpbnZhbGlkIFZUT0M4IGxhYmVsLgpHRU9NOiB1ZnNp ZC80YWJiN2NiMDY2YWFlNjljOiBpbnZhbGlkIFZUT0M4IGxhYmVsLgpHRU9NOiB1ZnMvYm9vdDog aW52YWxpZCBWVE9DOCBsYWJlbC4KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6c3Vucmlz ZS9yb290IFtdLi4uCm1vdW50cm9vdDogd2FpdGluZyBmb3IgZGV2aWNlIHN1bnJpc2Uvcm9vdCAu Li4KTW91bnRpbmcgZnJvbSB6ZnM6c3VucmlzZS9yb290IGZhaWxlZCB3aXRoIGVycm9yIDE5LgoK TG9hZGVyIHZhcmlhYmxlczoKICB2ZnMucm9vdC5tb3VudGZyb209emZzOnN1bnJpc2Uvcm9vdAoK TWFudWFsIHJvb3QgZmlsZXN5c3RlbSBzcGVjaWZpY2F0aW9uOgogIDxmc3R5cGU+OjxkZXZpY2U+ IFtvcHRpb25zXQogICAgICBNb3VudCA8ZGV2aWNlPiB1c2luZyBmaWxlc3lzdGVtIDxmc3R5cGU+ CiAgICAgIGFuZCB3aXRoIHRoZSBzcGVjaWZpZWQgKG9wdGlvbmFsKSBvcHRpb24gbGlzdC4KCiAg ICBlZy4gdWZzOi9kZXYvZGEwczFhCiAgICAgICAgemZzOnRhbmsKICAgICAgICBjZDk2NjA6L2Rl di9hY2QwIHJvCiAgICAgICAgICAod2hpY2ggaXMgZXF1aXZhbGVudCB0bzogbW91bnQgLXQgY2Q5 NjYwIC1vIHJvIC9kZXYvYWNkMCAvKQoKICA/ICAgICAgICAgICAgICAgTGlzdCB2YWxpZCBkaXNr IGJvb3QgZGV2aWNlcwogIC4gICAgICAgICAgICAgICBZaWVsZCAxIHNlY29uZCAoZm9yIGJhY2tn cm91bmQgdGFza3MpCiAgPGVtcHR5IGxpbmU+ICAgIEFib3J0IG1hbnVhbCBpbnB1dAoKbW91bnRy b290PiA/CgpMaXN0IG9mIEdFT00gbWFuYWdlZCBkaXNrIGRldmljZXM6CiAgdWZzL2Jvb3QgdWZz aWQvNGFiYjdjYjA2NmFhZTY5YyBtaXJyb3IvYm9vdCBkYTFkIGRhMWEgZGEwZCBkYTBhIGRhMSBk YTAKCm1vdW50cm9vdD4gCg== --0016364273ad12c0810492fc4b79-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 19: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 BCB0F106566C; Tue, 19 Oct 2010 19:48:28 +0000 (UTC) (envelope-from giovanni.trematerra@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 F2AF38FC08; Tue, 19 Oct 2010 19:48:27 +0000 (UTC) Received: by fxm12 with SMTP id 12so1952172fxm.13 for ; Tue, 19 Oct 2010 12:48:26 -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=ntagXPkHFFeSUdjbdXGbXR/CSIOYMFfX9RtdfXdqXVU=; b=FZVLMqgQYCufbmdx2XNEuoM+GKxL57GrAMJFf2l6UFOQVRGNuaK6A4WlWVeMrBl7Rz EATxSOjzdTQnAds+kT6Rv00aO+/4itbdD4m3mYbaMyeLnaJn8n/mmNZq6GWrou6Dr5le TL1wVaJ8aCbww51u1yQTMqtO9dBLqxYOD84mM= 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=J6DFf5FYPfg0mjN0C348dluo59QyKSucFdKoyp3dLlQoxFxoKgCmws22zG+Xbmtyen 0OME0To7ucvyyI5p0uG6bQTkvbr2Ga3qt4XnyRtqppAYZKFyn1oomHS4k8ZI4IqG6mOs eaIenAshlXWXYG1E+NcHTXdcGrgR7ox8/wHTc= MIME-Version: 1.0 Received: by 10.103.221.1 with SMTP id y1mr5341797muq.120.1287517706529; Tue, 19 Oct 2010 12:48:26 -0700 (PDT) Received: by 10.223.115.75 with HTTP; Tue, 19 Oct 2010 12:48:26 -0700 (PDT) In-Reply-To: <4CBD40E2.7030507@freebsd.org> References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> <4CBC5719.1020807@freebsd.org> <4CBD40E2.7030507@freebsd.org> Date: Tue, 19 Oct 2010 21:48:26 +0200 Message-ID: From: Giovanni Trematerra To: Andriy Gapon , Jeff Roberson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system 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, 19 Oct 2010 19:48:28 -0000 On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote: > >> Having dynamic slab sizes would allow to have the keg backed on a larger slab >> without going OFFPAGE. > > I agree in principle. > But without seeing code that implements that I can't guess if it would really be > more efficient or more maintainable, i.e. more useful in general. > Still a very good idea. > I'm going to work on that. Unfortunately I think that could take a long time to me. I hope someone will have some insight to share. -- Giovanni Trematerra From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 19:50: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 56258106566C for ; Tue, 19 Oct 2010 19:50:25 +0000 (UTC) (envelope-from matpockuh@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 D81E08FC15 for ; Tue, 19 Oct 2010 19:50:24 +0000 (UTC) Received: by eydd26 with SMTP id d26so216785eyd.13 for ; Tue, 19 Oct 2010 12:50:23 -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:content-transfer-encoding; bh=fCll8t3QS0sAjsRR+rA4Y7VsjxKs6vk8b33Czh3uf9g=; b=LKyGfaQ5gArkbZTgjEURkK41JKU2KI88ze0TKw3dyaMJKIghSBdOYAHInXDM9uxQT9 vanB11v9rzMLMHs/JJZTX1vR/xLujZy8DDacyPO3wud7p/jm0Ag6jeWRNV3j3McwJegw +MBDSnNrfXuSSq/CcHW63Fax4HXeLT4JpppXI= 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:content-transfer-encoding; b=YKrs/AwvyTfN0B386Wa2fzbVZzTtXHL8SwsQX8xBxJkrmbsN8GDISEtz2tec4oaC7C C5epuFxQuJY3cAWN+nlQpAs/fZpxfaHg0M804L/XUtu2qw2D4J28T09swLJflSD7fVRk nLuGra1kMHY5jrnmutj0NmeIrGp+2YEZLdoT4= Received: by 10.213.28.205 with SMTP id n13mr5974775ebc.5.1287517823478; Tue, 19 Oct 2010 12:50:23 -0700 (PDT) Received: from [84.52.74.162] ([84.52.74.162]) by mx.google.com with ESMTPS id v56sm8983917eeh.14.2010.10.19.12.50.21 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Oct 2010 12:50:22 -0700 (PDT) Message-ID: <4CBDF67C.3080001@GMail.Com> Date: Tue, 19 Oct 2010 23:50:20 +0400 From: KOT MATPOCKuH User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20100926 Thunderbird/3.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org, delphij@delphij.net References: <4CBCDD3A.9070404@delphij.net> In-Reply-To: <4CBCDD3A.9070404@delphij.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 19:50:25 -0000 On 19.10.2010 03:50, Xin LI wrote: > Escaping to boot loader prompt, and load old kernel, old opensolaris.ko, > old zfs.ko doesn't work. I think you forgot to load zpool.cache: load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 20:36:41 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 1DB131065673 for ; Tue, 19 Oct 2010 20:36:41 +0000 (UTC) (envelope-from sfourman@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 D23498FC08 for ; Tue, 19 Oct 2010 20:36:40 +0000 (UTC) Received: by qwe4 with SMTP id 4so1567057qwe.13 for ; Tue, 19 Oct 2010 13:36:40 -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=YSBfc1gDMhElPlB2Lp81yI+QJEjMJ5LhneUhfOMF1Q0=; b=Z1ceGmRUjKwlo8qf3rZzIXiyDX+yMwI106OodWwafo3uFqTQP8wk/PhvIu7zbRMBzm 5JYPoyarJbh0MNQYR8n7NIc7r8D6xUFsufq0p6xfAxutjg6laQceq5nSFYiMLbaEwY1L 87QIYFARFg61q5UeG4nmw3bkbwwbw8ukIxTdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ToQxw/Okp7F9jN1zQjakI1ygry+Vwtq6CS2HwlqdhR0LVmcpvBYUaclMYCifjLXHSW XCIYIWrWMOC5sKgD1VL9kLuu7iN74PIygCBejXavunpuqfkw5b95NP1qIu+SIjKKNkN0 t80mvf+5B9fDNdoj93fLHCYiQB7VYwDdqLKjI= MIME-Version: 1.0 Received: by 10.229.215.19 with SMTP id hc19mr5603390qcb.107.1287520599926; Tue, 19 Oct 2010 13:36:39 -0700 (PDT) Received: by 10.229.95.7 with HTTP; Tue, 19 Oct 2010 13:36:39 -0700 (PDT) Date: Tue, 19 Oct 2010 15:36:39 -0500 Message-ID: From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: ath9k 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, 19 Oct 2010 20:36:41 -0000 Recently there were changes made to the ath driver on CURRENT does FreeBSD still need these changes? http://marc.info/?l=linux-wireless&m=128746728412954&w=2 I did notice they went in OpenBSD's Tree today -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 21:21: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 F0D4B106566C for ; Tue, 19 Oct 2010 21:21:55 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0D38FC13 for ; Tue, 19 Oct 2010 21:21:55 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id A7E61A7DF9D; Wed, 20 Oct 2010 05:21:53 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id qFkADcWaBXHl; Wed, 20 Oct 2010 05:21:47 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 95306A7DF78; Wed, 20 Oct 2010 05:21:45 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=u73DY/g/z0xTEul7a0V08+Ia5ENOruD1m3ld7lm4K1eb2ag2//2sVEgz/oF8+hYva Jh32circZXxLOeQmqFJsw== Message-ID: <4CBE0BE5.2060708@delphij.net> Date: Tue, 19 Oct 2010 14:21:41 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20100920 Thunderbird/3.0.8 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Marcel Moolenaar References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> In-Reply-To: <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------090607000805030906040809" Cc: "Andrey V. Elsukov" , FreeBSD Current Subject: Re: [zfs] Mounting from (...) failed with error 19 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 21:21:56 -0000 This is a multi-part message in MIME format. --------------090607000805030906040809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/19/10 08:49, Marcel Moolenaar wrote: > > On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: > >> On 19.10.2010 09:03, Andrey V. Elsukov wrote: >>>> Mounting from (...) failed with error 19 >>>> >>>> On boot. The system is using pure ZFS setup. It seems that 19 means >>>> ENODEV but according to the dmesg the device do exist. >>> >>> Yes, i have the same problem. >> >> I fixed it with attached patch. > > Makes sense. "tank" (or its namesake) isn't a real device. > Feel free to commit to unbreak things, but we may want to > rethink this from a generality point of view. Listing > exceptions doesn't scale and we now have 2 (the first was > the empty device name as used by nfs, and now also zfs). > > Good catch, BTW. Yes good catch, it fixed the problem for me as well. What about the attached patch? I'm going to give it a swirl soon. The difference is that it tests whether dev begins with /dev/. Note that I'm not quite convinced with this yet as we may want to wait for the devices from a zpool be ready, which may also need some yielding during boot. A better way of solving this might be to register a "watchlist" of devices (so that ZFS can register its vdev devices for example) and have mountroot wait for that list? Or perhaps a set of EVENTHANDLER callback? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMvgvkAAoJEATO+BI/yjfBX/gIAIRnS4eQVBe/Zh6RrT8BjI91 J1r7wNz1AYXda2t4/RUVnPZYr97GG1quEewtgcxTxW2nkii1ZkftjMg6Ik4Gio6Y AxNdjEB35tXqhVUV1oS8JS09ejZij2Y43SHxWxOkhUnFEmuhjK4+euM/+obpJ4Kl AR61E/DYqwv/8bqhofknylroDsveN3Vhd1n7dK4s+e3YcmANnZxTCWcxroD7C2yb gCH6TDZPDVKVbfyS73QFoyic2Jml5eK/dkmlLMRubP5qs5aIgy0P1zcjhvRrrgOf bYLM3IUEbVhPSQnO8d2sDhXytgCI/s6p39rMdKPR3jrf2+UnW6IM46NvVkSaOP8= =cAxC -----END PGP SIGNATURE----- --------------090607000805030906040809 Content-Type: text/plain; name="vfs_mountroot.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vfs_mountroot.diff" Index: sys/kern/vfs_mountroot.c =================================================================== --- sys/kern/vfs_mountroot.c (revision 214082) +++ sys/kern/vfs_mountroot.c (working copy) @@ -713,8 +713,7 @@ parse_mount(char **conf) goto out; } - if (strcmp(fs, "zfs") != 0 && dev[0] != '\0' && - !parse_mount_dev_present(dev)) { + if ((strstr(dev, "/dev/") == dev) && !parse_mount_dev_present(dev)) { printf("mountroot: waiting for device %s ...\n", dev); delay = hz / 10; timeout = root_mount_timeout * hz; --------------090607000805030906040809-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 22: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 82AEF1065679 for ; Tue, 19 Oct 2010 22:49:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6684B8FC19 for ; Tue, 19 Oct 2010 22:49:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LAK0093N6NK2W30@asmtp026.mac.com> for freebsd-current@FreeBSD.ORG; Tue, 19 Oct 2010 15:33:21 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010190192 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-19_10:2010-10-19, 2010-10-19, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <4CBE0BE5.2060708@delphij.net> Date: Tue, 19 Oct 2010 15:33:20 -0700 Message-id: <023E61D3-7E4C-4793-95A0-088ABCD0F92F@mac.com> References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> <4CBE0BE5.2060708@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1081) Cc: "Andrey V. Elsukov" , FreeBSD Current Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 19 Oct 2010 22:49:09 -0000 On Oct 19, 2010, at 2:21 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 10/19/10 08:49, Marcel Moolenaar wrote: >> >> On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: >> >>> On 19.10.2010 09:03, Andrey V. Elsukov wrote: >>>>> Mounting from (...) failed with error 19 >>>>> >>>>> On boot. The system is using pure ZFS setup. It seems that 19 means >>>>> ENODEV but according to the dmesg the device do exist. >>>> >>>> Yes, i have the same problem. >>> >>> I fixed it with attached patch. >> >> Makes sense. "tank" (or its namesake) isn't a real device. >> Feel free to commit to unbreak things, but we may want to >> rethink this from a generality point of view. Listing >> exceptions doesn't scale and we now have 2 (the first was >> the empty device name as used by nfs, and now also zfs). >> >> Good catch, BTW. > > Yes good catch, it fixed the problem for me as well. > > What about the attached patch? I'm going to give it a swirl soon. The > difference is that it tests whether dev begins with /dev/. Interesting. I've been thinking about this too, but isn't exactly fool-proof. When devfs is the root file system, you can use "ufs:da0s1a" to refer to the device special file. It seems inconsistent to have "ufs:da0s1" fail when ufs:/dev/da0s1" works (a real scenario with USB based mass storage devices -- root mount is unheld as soon as umass is created, but before daX exists for it). This patch at least covers the problem cases with a single strstr(), and we may get away with the inconsistency given above by documenting it properly. Andrey: any thoughts? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 01:16: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 BE309106566C for ; Wed, 20 Oct 2010 01:16:00 +0000 (UTC) (envelope-from sendtomatt@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 7081E8FC19 for ; Wed, 20 Oct 2010 01:16:00 +0000 (UTC) Received: by qyk30 with SMTP id 30so2150845qyk.13 for ; Tue, 19 Oct 2010 18:15:59 -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:content-transfer-encoding; bh=FDieWAGLXajo0G9Uhbe971MYN7sgXWH6zTS9R33Zutk=; b=kbag8MQZO1V1RcE7IdTZB/IeFz1lOTI6E2FbOhiPHxc3lfLjnm7pynKyNm0j0F8N4t 1Hsezponwn5mTew5d2OSyGUWPIfqjCSSWuIw51OBHHqUYlqvQbN+gCxGEu1zaKY+YJW2 f30eiV+Lea2fL1dMx+Wx8ZHgYWuFGRH/azc4g= 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:content-transfer-encoding; b=wh8NlGV9z4DK608m9mfrZBpUjZQUQYtonBNVOVbLexpZ0H1yqweOLfTPVSyzeTlSEO nSIMrCGcqGDm+IatHJECLyXzUvt6cpMeMY79bLxXA925C0nWiiltDqc5RW1LkczkKEjk VturncAs4DUhyvedbJjgBdSIjclL+RpWpMxlM= Received: by 10.224.201.201 with SMTP id fb9mr4209329qab.60.1287537359531; Tue, 19 Oct 2010 18:15:59 -0700 (PDT) Received: from ono-sendai.local ([75.111.34.169]) by mx.google.com with ESMTPS id w30sm1432060vcr.16.2010.10.19.18.15.56 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Oct 2010 18:15:57 -0700 (PDT) Message-ID: <4CBE42CA.3050103@gmail.com> Date: Tue, 19 Oct 2010 18:15:54 -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-current@freebsd.org References: <4C732522.1010400@gmail.com> <4CA556EB.902@gmail.com> <20101001144505.C62022@sola.nimnet.asn.au> <20101002142419.G62022@sola.nimnet.asn.au> <1286051977.1655.45.camel@RabbitsDen.RabbitsLawn.verizon.net> <20101003174833.V62022@sola.nimnet.asn.au> In-Reply-To: <20101003174833.V62022@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 01:16:00 -0000 My experience with a sleeping freebsd laptop has been shortlived! Today I rebuilt world using clang & this morning's csup current. Clang build went just swimmingly. Unthinkingly, I closed my laptop lid and put it in my case. When I got to my house, it was roasting with fans spinning and sleep light flashing. No damage, thankfully. Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop sleep! I had recently fiddled with powerd, but problem persisted after reverting to previous configuration of associated sysctls etc. Interestingly, sleep bounce now fails with a hard freeze, which it never has in the past. Verbose output shows the wifi then re0 network interfaces going from D0->D3 as last living output. Please note problem persists regardless of user, X running, sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd running/not running. Without sleep bounce, problem is characterized by flashing sleep light and spinning fans (CPU temperature is high). No devices added or removed, was sleeping this morning before buildworld. Is it worth rebuilding with gcc? Or a content change and not a compiler issue? Any major pci changes lately maybe? Matt sendtomatt@gmail.com Not sure where to go from here... If it is helpful, I can provide any required logs, verbose dmesg etc. From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 01:47: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 6E874106564A; Wed, 20 Oct 2010 01:47:51 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 416C08FC0A; Wed, 20 Oct 2010 01:47:51 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9K1lnZn066806; Wed, 20 Oct 2010 01:47:50 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4CBEBAC5.4030506@freebsd.org> Date: Wed, 20 Oct 2010 09:47:49 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Jaakko Heinonen References: <4C961009.6080609@freebsd.org> <4C96ED40.7070206@DataIX.net> <4C976F14.8000408@freebsd.org> <4C9789FD.5000008@freebsd.org> <20101019085955.GA4865@jh> In-Reply-To: <20101019085955.GA4865@jh> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sysctl -a is slow 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, 20 Oct 2010 01:47:51 -0000 Jaakko Heinonen wrote: > On 2010-09-20, David Xu wrote: >> I redirect all output to a disk file, and it still needs 1 second to >> complete, this machine is dual-core pentium E5500, faster than previous >> one which is a dual-core AMD 5000+ machine, the 5000+ needs 2 >> seconds to complete. >> >> $/usr/bin/time sysctl -b kern.geom.confdot > sysctl_geom_confdot.txt >> 1.00 real 0.00 user 0.00 sys > > I couldn't reproduce the problem myself but I bet that it's a lost > wakeup in g_waitfor_event(). Can you try this patch? > > %%% > Index: sys/geom/geom_event.c > =================================================================== > --- sys/geom/geom_event.c (revision 214048) > +++ sys/geom/geom_event.c (working copy) > @@ -220,11 +220,12 @@ one_event(void) > mtx_lock(&g_eventlock); > TAILQ_REMOVE(&g_events, ep, events); > ep->flag &= ~EV_INPROGRESS; > - mtx_unlock(&g_eventlock); > if (ep->flag & EV_WAKEUP) { > ep->flag |= EV_DONE; > wakeup(ep); > + mtx_unlock(&g_eventlock); > } else { > + mtx_unlock(&g_eventlock); > g_free(ep); > } > g_topology_unlock(); > @@ -365,11 +366,14 @@ g_waitfor_event(g_event_t *func, void *a > va_end(ap); > if (error) > return (error); > - do > - tsleep(ep, PRIBIO, "g_waitfor_event", hz); > - while (!(ep->flag & EV_DONE)); > + > + mtx_lock(&g_eventlock); > + while (!(ep->flag & EV_DONE)) > + msleep(ep, &g_eventlock, PRIBIO, "g_waitfor_event", hz); > if (ep->flag & EV_CANCELED) > error = EAGAIN; > + mtx_unlock(&g_eventlock); > + > g_free(ep); > return (error); > } > %%% > Yes, the patch seems fixed the problem, I can not reproduce it. Thanks! From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 04:38: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 D9AE4106566B for ; Wed, 20 Oct 2010 04:38:52 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 8347D8FC0C for ; Wed, 20 Oct 2010 04:38:52 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward2.mail.yandex.net (Yandex) with ESMTP id C149538A86D8; Wed, 20 Oct 2010 08:38:50 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287549530; bh=jOIlvLsx0ywbzYabBuaxQWqytv3qRfBA/AhZ3lhlWc0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=CbRy0ZVUt941VRL/iyap3JcgJppS2UErgWSUJ838vXWJOMGryVfObx9lPgko+zoqJ 0m58EnSu4WccQ3cdSjTkz9ZXAoqRJRuckh1VsODnIro5nUJblI0b8AAVT8hi9b8up/ cUpQ261VYUHDjk/qZVsS8BgsBnfa9ht8SuKlHhwk= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp2.mail.yandex.net (Yandex) with ESMTPSA id 7994A52809A; Wed, 20 Oct 2010 08:38:50 +0400 (MSD) Message-ID: <4CBE7254.5060502@yandex.ru> Date: Wed, 20 Oct 2010 08:38:44 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Marcel Moolenaar References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> <4CBE0BE5.2060708@delphij.net> <023E61D3-7E4C-4793-95A0-088ABCD0F92F@mac.com> In-Reply-To: <023E61D3-7E4C-4793-95A0-088ABCD0F92F@mac.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig210543F6031B07D81115EFDD" X-Yandex-TimeMark: 1287549530 X-Yandex-Spam: 1 X-Yandex-Front: smtp2.mail.yandex.net Cc: FreeBSD Current , d@delphij.net Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 04:38:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig210543F6031B07D81115EFDD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 20.10.2010 2:33, Marcel Moolenaar wrote: >> What about the attached patch? I'm going to give it a swirl soon. Th= e >> difference is that it tests whether dev begins with /dev/. >=20 > Interesting. I've been thinking about this too, but isn't > exactly fool-proof. When devfs is the root file system, > you can use "ufs:da0s1a" to refer to the device special > file. It seems inconsistent to have "ufs:da0s1" fail when > ufs:/dev/da0s1" works (a real scenario with USB based mass > storage devices -- root mount is unheld as soon as umass > is created, but before daX exists for it). >=20 > This patch at least covers the problem cases with a single > strstr(), and we may get away with the inconsistency given > above by documenting it properly. >=20 > Andrey: any thoughts? Currently usage information in parse_dir_ask() says that device should be specified with "/dev/". But conf0 does not use "/dev/". Also, Marcel,= do you have any plans write some documentation with examples about using of new features? --=20 WBR, Andrey V. Elsukov --------------enig210543F6031B07D81115EFDD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJMvnJZAAoJEAHF6gQQyKF6q3MIAIk2x7atebcX/PrMJ7bByyWC tlES0gH8EUoKMwbuuSENj+2H3u5+MdOS/PFfdert9O4W8PASt7cjjNk86BseW6dN 1WKoXj7nGlhI9K3PcLzQGvfshjTeowPShzL8MmzlAPyeH2CFaUggYe2fgBMiH16R O2TbxT6oVFm+ctOETANlF+MNfK+uNrNXgCl2AwzmluxAoCzBg55S2/hqw+w21ej/ P1bP6mww5aEKz9pzNSvJmCo+271Y24uwZqpvkt+h5EofrTXumGmbTIKYMho95oJ2 ICG3WIvH7sO9w+B2bNi9znFjki+QIAO6NDBFNNrWI0Qi0gwWAFbKw7+EoEx4H5s= =PzCL -----END PGP SIGNATURE----- --------------enig210543F6031B07D81115EFDD-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 06:43:44 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 1AB96106566C for ; Wed, 20 Oct 2010 06:43:44 +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 E3A738FC15 for ; Wed, 20 Oct 2010 06:43:43 +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 o9K6hd1h043051; Tue, 19 Oct 2010 23:43:39 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o9K6hdkZ043050; Tue, 19 Oct 2010 23:43:39 -0700 (PDT) Date: Tue, 19 Oct 2010 23:43:39 -0700 (PDT) From: Matthew Dillon Message-Id: <201010200643.o9K6hdkZ043050@apollo.backplane.com> To: Alexander Best References: <20101018174331.GA80017@sandvine.com> <20101018181142.GC5644@dan.emsphone.com> <20101018193010.GA88783@sandvine.com> <20101018193916.GD5644@dan.emsphone.com> <20101019001320.GB91234@freebsd.org> Cc: Ed Maste , freebsd-current@freebsd.org, Dan Nelson Subject: Re: CPU report in first line of "vmstat 1" is meaningless 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, 20 Oct 2010 06:43:44 -0000 :> :> > On a related note I'm not sure if it makes sense to have the same :> > behaviour for the first line when an interval is set as when it is :> > invoked with no interval. : :...also vmstat seems to exist in a few other OSes (linux e.g). maybe they've :fixed it already (or the netbsd/openbsd/dragonflybsd folks or apple?). : :cheers. :alex No, we haven't. I think it is meaningless too, and I can't imagine any script that would try to snarf that line. Another problem is that vmstat output in general is blowing out its column formatting. We have made some changes in DFly... sub-second intervals can be specified, and I think we enforce at least one space between fields so the output doesn't become totally unreadable. But the blowouts still remain. -Matt From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 06:50: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 7ACE0106566C for ; Wed, 20 Oct 2010 06:50:39 +0000 (UTC) (envelope-from matpockuh@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 2C96D8FC08 for ; Wed, 20 Oct 2010 06:50:39 +0000 (UTC) Received: by qyk10 with SMTP id 10so1076553qyk.13 for ; Tue, 19 Oct 2010 23:50: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:cc:content-type; bh=Xi2HQlwB72CVfQCxzSrmKjXIOzzEKc8iCfllddTv1wE=; b=e/c0pV9s86NNpriHT4cvQfzIvejrunBOm3jAWWuGwbFtnatm1pFyv1lKxHoU6CmRoS saOKghdxcGzL9ShfywEfWIt1NZbt67o2THNJNbwYLXwy+leHL1mljavNGmboXUUqPTBH mUB51g083ydCi7LwHSb/gFvn09kJW21WFfZ8M= 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=qOLk0n/BBVS6eMclup4kiXc4A3ymwkh/gv0aanESijvwNJVRf5CagBQ9RyQIOPg9vK JFZGwNC8COWVwYC8I32R0dukxukSOZNq1Ag5BuAFZ1EQGeMXZf6vuHOqfWPmLFuEqdcs iCZA7hVDiJw23EWc4qw+lsU3X65nDg5pdy0pQ= MIME-Version: 1.0 Received: by 10.229.215.208 with SMTP id hf16mr6105673qcb.79.1287557438381; Tue, 19 Oct 2010 23:50:38 -0700 (PDT) Received: by 10.229.248.201 with HTTP; Tue, 19 Oct 2010 23:50:38 -0700 (PDT) In-Reply-To: <4CBDB17C.4040607@yandex.ru> References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> Date: Wed, 20 Oct 2010 10:50:38 +0400 Message-ID: From: KOT MATPOCKuH To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Cc: Xin LI , FreeBSD Current , Marcel Moolenaar Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 06:50:39 -0000 Hello! > I fixed it with attached patch. Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"))? -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 07:21: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 E0A0B106566B for ; Wed, 20 Oct 2010 07:21:51 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id 89EFF8FC17 for ; Wed, 20 Oct 2010 07:21:51 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward15.mail.yandex.net (Yandex) with ESMTP id BF2CF4458DDC; Wed, 20 Oct 2010 11:21:49 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287559309; bh=3xfCl4STTthDi7Oy615rQTy/BwB7ZTL61iIbry4c2s8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=mAypcIaKprCIPJg3smd9SpZrBmwzbiYg76fJqUcJHb6B1vz8sTsfJ1jiMousOVHfH kUuhm1NkLQm3GqUnOLoTn2U6fRMml0yZNir+bWiKqIZ0DjfD7RvEqGjRFqEpXe9FFd y2E1vj6Yo61mp9plajTHHJlmsu3zsF5abSpVeNhE= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp13.mail.yandex.net (Yandex) with ESMTPSA id 6264C41580B1; Wed, 20 Oct 2010 11:21:49 +0400 (MSD) Message-ID: <4CBE9889.6010107@yandex.ru> Date: Wed, 20 Oct 2010 11:21:45 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: KOT MATPOCKuH References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1F31B0B7532F9DCFDEC19D7" X-Yandex-TimeMark: 1287559309 X-Yandex-Spam: 1 X-Yandex-Front: smtp13.mail.yandex.net Cc: Xin LI , FreeBSD Current , Marcel Moolenaar Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 07:21:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1F31B0B7532F9DCFDEC19D7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 20.10.2010 10:50, KOT MATPOCKuH wrote: > Hello! >=20 >> I fixed it with attached patch. > Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs= "))? :) Just because it is not first access to the fs variable in this function. And it is already checked with strcmp. --=20 WBR, Andrey V. Elsukov --------------enigB1F31B0B7532F9DCFDEC19D7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJMvpiMAAoJEAHF6gQQyKF6v0QH/3Fh1PZtj6KMuSU0knvsATXG Gi6mwyHoFJHH9CRBiNKT84BhodVAqHMLl95EKgUtBX1rMmqEF3p2vdCfsBbVfK9c hSO75CZHVoaGcVH7BJtFRJTM4ph1YKCqAsJ6pNU5L7JIQHLyGDGor1d8PLRlPtFg zWofrsmS3UEMSZHSDyhLxzpb7IIRAHfMA5eCqophbFwuEBxa1p58LWmQikZWpBvg Izot7J2hVcm9/LJ6N4wFzI+7gCUr7INKmCJZA+WBamHLDU7mGaHpu8dld6W7CAGm CKmoV33QSxQlViY0RvG+hpJN1MTrNvVZ+9L0UghhDDBkBAXsxfs1GemgkQVK0RI= =JWXN -----END PGP SIGNATURE----- --------------enigB1F31B0B7532F9DCFDEC19D7-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 09:41: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 1F0AD1065679 for ; Wed, 20 Oct 2010 09:41:27 +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 9AA178FC16 for ; Wed, 20 Oct 2010 09:41:25 +0000 (UTC) Received: by fxm12 with SMTP id 12so2432171fxm.13 for ; Wed, 20 Oct 2010 02:41:24 -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=q6oZGwMHmxwdsNtKXq4kGVnBGNGroo8ojIGEnsFRVP8=; b=nwom/0X5UVm2SISx7GgxV4kYfS/raHEb1pUX8WC6zpLzhRD+Efu6sXrcmj/XO0kI98 FUb2wZFC3tAaFqfXybzHDghsqoWSvSHegX3R+foo3Xf4SVhGGHi+Wu7oxVGDrpw/grXK 3SImregAHJYxDAdHs76hKxa30vnk4oayUhWHY= 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=pGlQIfb2H8fCHDfRUyf2KeqJcYViUTsWH9Zm6fbtoFKI1AdrJWdneM5Pd+SdwRMeK4 LGv/6TVeHmg6/9yaZQWAbqS+ai7i6lSblgcyqTm7z6yURbayRSnCjqaq4C1sSlvqdCPV ZZKQqI5NpoXG86TwE0R8heC4tn2ceQnQpJB2g= Received: by 10.103.221.6 with SMTP id y6mr6310912muq.17.1287567684532; Wed, 20 Oct 2010 02:41:24 -0700 (PDT) Received: from ernst.jennejohn.org (p578E1575.dip.t-dialin.net [87.142.21.117]) by mx.google.com with ESMTPS id y19sm3573670fau.41.2010.10.20.02.41.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 02:41:23 -0700 (PDT) Date: Wed, 20 Oct 2010 11:41:21 +0200 From: Gary Jennejohn To: Matt Message-ID: <20101020114121.476961db@ernst.jennejohn.org> In-Reply-To: <4CBE42CA.3050103@gmail.com> References: <4C732522.1010400@gmail.com> <4CA556EB.902@gmail.com> <20101001144505.C62022@sola.nimnet.asn.au> <20101002142419.G62022@sola.nimnet.asn.au> <1286051977.1655.45.camel@RabbitsDen.RabbitsLawn.verizon.net> <20101003174833.V62022@sola.nimnet.asn.au> <4CBE42CA.3050103@gmail.com> 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: freebsd-current@freebsd.org Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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: Wed, 20 Oct 2010 09:41:27 -0000 On Tue, 19 Oct 2010 18:15:54 -0700 Matt wrote: > My experience with a sleeping freebsd laptop has been shortlived! > > Today I rebuilt world using clang & this morning's csup current. > Clang build went just swimmingly. > > Unthinkingly, I closed my laptop lid and put it in my case. > When I got to my house, it was roasting with fans spinning and sleep > light flashing. No damage, thankfully. > > Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop sleep! > > I had recently fiddled with powerd, but problem persisted after > reverting to previous configuration of associated sysctls etc. > > Interestingly, sleep bounce now fails with a hard freeze, which it never > has in the past. > > Verbose output shows the wifi then re0 network interfaces going from > D0->D3 as last living output. > > Please note problem persists regardless of user, X running, sleep_delay > sysctl, do_power_resume, do_power_nodriver, powerd running/not running. > > Without sleep bounce, problem is characterized by flashing sleep light > and spinning fans (CPU temperature is high). > > No devices added or removed, was sleeping this morning before > buildworld. Is it worth rebuilding with gcc? Or a content change and not > a compiler issue? Any major pci changes lately maybe? > > Matt > sendtomatt@gmail.com > > Not sure where to go from here... > If it is helpful, I can provide any required logs, verbose dmesg etc. > Did you _not_ have this problem when compiling with the base C compiler (gcc)? Not really clear from your description. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 10:11: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 D93B81065670 for ; Wed, 20 Oct 2010 10:11:24 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A37D18FC12 for ; Wed, 20 Oct 2010 10:11:24 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id E793351C; Wed, 20 Oct 2010 05:53:48 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 20 Oct 2010 05:53:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=6Q+Mq0+OKZTyTATC9NTBFhDPF8U=; b=kXiHVuXuoVvdPPQ5zUELC6sFx0SCUpqG9f+KD64tbTzc8kgBQWcnM3SBXpNanVI6HNYKcnAyvIZLSXiiMeZMhSWL+T7zDVzMAn8CgQtMjnr1VtwvMJz8UJJ9RNhI7iVEdwGaWzhYbmjhAsWUaCBLqE7TYfZPGgE4r7ToBNYrV70= X-Sasl-enc: svnNiJNwlRf34RBH0UMu5Encd/IKgweGXqnC3ITi6kMy 1287568428 Received: from [192.168.1.234] (76-191-213-211.dsl.dynamic.sonic.net [76.191.213.211]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7A810401043; Wed, 20 Oct 2010 05:53:48 -0400 (EDT) Message-ID: <4CBEBC24.3060007@freebsd.org> Date: Wed, 20 Oct 2010 02:53:40 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Jeremy References: <4CB639DB.3090907@fastmail.net> <20101018200226.GA51447@server.vk2pj.dyndns.org> In-Reply-To: <20101018200226.GA51447@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 2TB HDD = TIMEOUT - READ_DMA48 .... 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, 20 Oct 2010 10:11:24 -0000 Peter Jeremy wrote: > On 2010-Oct-13 22:59:39 +0000, Darren Reed wrote: > >> As another body that today bought a 2TB HDD, I can confirm the presence >> of kernel messages relating to READ_DMA48 with FreeBSD 8. >> The drive in question is a Hitachi one, not a Samsung. >> >> Is it the drive, system or operating system? >> > > You'll need to provide some more details such as how old your FreeBSD > 8 is, drive model number, controller details and the actual error > message you are getting. > > I recently bought a Hitachi Deskstar 7K2000, which is sitting in an > Astone enclosure (identifying as "Sunplus Technology Co.,Ltd."). > Unfortunately, I'm limited to USB2 whilst I wait for the correct eSATA > adapter. Whilst the first disk was DOA, its replacement is running > perfectly (though slowly) with my 2-week-old FreeBSD 8.1-stable. In > particular, one of the first tests I did was to write a pseudo-random > sequence over the entire surface and then verify it to ensure that all > sectors are uniquely addressable > When I booted FreeBSD on the bare metal, the problem was not present. Nor was it present when I attached the drive via USB to NetBSD and that got me to thinking because it did show up with NetBSD under VMWare... thus... This turned out to be a VMWare issue. The problem was solved by upgrading VMWare Workstation from 6.5.3 to 7.1.2. Hope this helps. Darren From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 15:30:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2B6F51065670; Wed, 20 Oct 2010 15:30:40 +0000 (UTC) Date: Wed, 20 Oct 2010 15:30:40 +0000 From: Alexander Best To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Message-ID: <20101020153040.GA3184@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: serious issue caused by usb device, stalling almost all operations 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, 20 Oct 2010 15:30:40 -0000 hi there, i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: after attaching my mobile phone, it simply resets without doing mount or anything. however after letting the device come up again it won't show up in the console. after detaching it the usb subsystem seemed to have completely crashed. but that's not all. the following programs now simply hang without producing any output C-C won't do anything: - dmesg - top - ps - killall - camcontrol devlist - usbconfig i cannot even kill the apps, since top and ps aren't working so there's no way to find out the PIDs. using 'killall dmesg' e.g. won't work either, since killall will also stall. this is the console output which i could grab with 'vidcontrol -H -P < /dev/ttyv0' (since dmesg doesn't work anymore): ugen3.3: at usbus3 umass0: on usbus3 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to rea dy change, medium may have changed) da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3777MB (7736320 512 byte sectors: 255H 63S/T 481C) (da0:umass-sim0:0:0:0): AutoSense failed ugen3.3: at usbus3 (disconnected) umass0: at uhub8, port 3, addr 3 (disconnected) (da0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): Invalidating pack (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scsi status == 0x0 (da0:umass-sim0:0:0:0): removing device entry lock order reversal: 1st 0xffffffff80a37d50 GEOM topology (GEOM topology) @ /usr/src/sys/geom/label/ g_label.c:320 2nd 0xffffffff808387a0 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysct l.c:257 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x35 kdb_backtrace() at kdb_backtrace+0x4e _witness_debugger() at _witness_debugger+0x29 witness_checkorder() at witness_checkorder+0xad2 _sx_xlock() at _sx_xlock+0xae sysctl_ctx_free() at sysctl_ctx_free+0x2e dacleanup() at dacleanup+0x65 camperiphfree() at camperiphfree+0x152 cam_periph_release_locked() at cam_periph_release_locked+0x84 cam_periph_release() at cam_periph_release+0x6d daclose() at daclose+0x223 g_disk_access() at g_disk_access+0x21c g_access() at g_access+0x3b7 g_label_taste() at g_label_taste+0x3be g_new_provider_event() at g_new_provider_event+0x145 one_event() at one_event+0x2d5 g_run_events() at g_run_events+0xe g_event_procbody() at g_event_procbody+0x8b fork_exit() at fork_exit+0xfd fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800003ecf0, rbp = 0 --- cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 16: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 20D80106566C for ; Wed, 20 Oct 2010 16:23:42 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 042EA8FC1C for ; Wed, 20 Oct 2010 16:23:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LAL006J9K7A6020@asmtp030.mac.com> for freebsd-current@FreeBSD.ORG; Wed, 20 Oct 2010 09:23:36 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010200085 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-20_08:2010-10-20, 2010-10-20, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <4CBE7254.5060502@yandex.ru> Date: Wed, 20 Oct 2010 09:23:34 -0700 Message-id: References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <44B33168-C432-4AA0-A765-8222DB4C048D@mac.com> <4CBE0BE5.2060708@delphij.net> <023E61D3-7E4C-4793-95A0-088ABCD0F92F@mac.com> <4CBE7254.5060502@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , d@delphij.net Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 16:23:42 -0000 On Oct 19, 2010, at 9:38 PM, Andrey V. Elsukov wrote: > On 20.10.2010 2:33, Marcel Moolenaar wrote: >>> What about the attached patch? I'm going to give it a swirl soon. The >>> difference is that it tests whether dev begins with /dev/. >> >> Interesting. I've been thinking about this too, but isn't >> exactly fool-proof. When devfs is the root file system, >> you can use "ufs:da0s1a" to refer to the device special >> file. It seems inconsistent to have "ufs:da0s1" fail when >> ufs:/dev/da0s1" works (a real scenario with USB based mass >> storage devices -- root mount is unheld as soon as umass >> is created, but before daX exists for it). >> >> This patch at least covers the problem cases with a single >> strstr(), and we may get away with the inconsistency given >> above by documenting it properly. >> >> Andrey: any thoughts? > > Currently usage information in parse_dir_ask() says that device should > be specified with "/dev/". But conf0 does not use "/dev/". Also, Marcel, > do you have any plans write some documentation with examples about using > of new features? Yes, this will be documented. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 16:58: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 2C0F6106564A for ; Wed, 20 Oct 2010 16:58:04 +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 D0DA08FC0C for ; Wed, 20 Oct 2010 16:58:03 +0000 (UTC) Received: by gwb20 with SMTP id 20so2171633gwb.13 for ; Wed, 20 Oct 2010 09:58:03 -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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fZc5TrtPJhCjXr20Sf1fRQUVna1qOIhH3SgNRIn4Dus=; b=DhEfQPt4Q965SyYA/XI0bUl9cUSQqVOUt33/7OcDDJHXKCXvQbF0G3nldGYtUtFA4B +/Y2SHt9MkFNJWlyb7sf6z+tZV8lpAv6PwA75JhLgUDdu20mHNmPVVdDGd97qDRpuU11 +l1FSJ6k3rpUzOFP0UZYtqgGaVs8KJu+zHXiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vLmuVD6fJeiG+nBF2KS6jBeFRmm7+m1obyTiM6HK8uMjCOPjHdxnXUZCDtNeNiJjcO 3AvmG0Odn1c/ofgdZVyozbplvkmuqUAqsEg7XaIYGMJQDpsb+AkMv3fdVcDSKBmUhveG +YuT5ygpXSoGK79i0pJ0WVgjQd/oZ54uGVkM0= Received: by 10.103.131.9 with SMTP id i9mr6837034mun.77.1287593882397; Wed, 20 Oct 2010 09:58:02 -0700 (PDT) Received: from ono-sendai.local ([75.111.34.169]) by mx.google.com with ESMTPS id d17sm252813fav.29.2010.10.20.09.57.49 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 09:57:51 -0700 (PDT) Message-ID: <4CBF1F88.2070805@gmail.com> Date: Wed, 20 Oct 2010 09:57:44 -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: gljennjohn@googlemail.com References: <4C732522.1010400@gmail.com> <4CA556EB.902@gmail.com> <20101001144505.C62022@sola.nimnet.asn.au> <20101002142419.G62022@sola.nimnet.asn.au> <1286051977.1655.45.camel@RabbitsDen.RabbitsLawn.verizon.net> <20101003174833.V62022@sola.nimnet.asn.au> <4CBE42CA.3050103@gmail.com> <20101020114121.476961db@ernst.jennejohn.org> In-Reply-To: <20101020114121.476961db@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 16:58:04 -0000 On 10/20/10 02:41, Gary Jennejohn wrote: > On Tue, 19 Oct 2010 18:15:54 -0700 > Matt wrote: > >> My experience with a sleeping freebsd laptop has been shortlived! >> >> Today I rebuilt world using clang& this morning's csup current. >> Clang build went just swimmingly. >> >> Unthinkingly, I closed my laptop lid and put it in my case. >> When I got to my house, it was roasting with fans spinning and sleep >> light flashing. No damage, thankfully. >> >> Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop sleep! >> >> I had recently fiddled with powerd, but problem persisted after >> reverting to previous configuration of associated sysctls etc. >> >> Interestingly, sleep bounce now fails with a hard freeze, which it never >> has in the past. >> >> Verbose output shows the wifi then re0 network interfaces going from >> D0->D3 as last living output. >> >> Please note problem persists regardless of user, X running, sleep_delay >> sysctl, do_power_resume, do_power_nodriver, powerd running/not running. >> >> Without sleep bounce, problem is characterized by flashing sleep light >> and spinning fans (CPU temperature is high). >> >> No devices added or removed, was sleeping this morning before >> buildworld. Is it worth rebuilding with gcc? Or a content change and not >> a compiler issue? Any major pci changes lately maybe? >> >> Matt >> sendtomatt@gmail.com >> >> Not sure where to go from here... >> If it is helpful, I can provide any required logs, verbose dmesg etc. >> > Did you _not_ have this problem when compiling with the base C compiler > (gcc)? Not really clear from your description. > > -- > Gary Jennejohn > It wasn't particularly clear to me at the time of posting. I subsequently compiled generic with both gcc and clang and issue persists, ruling out clang as source of issue. A diff of dmesg output from before csup buildworld and after did not reveal any startling differences. Booting from kernel.prev allowed it to sleep again, so it seems something changed in cvs. Matt From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:00:29 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8B70E106566C; Wed, 20 Oct 2010 17:00:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 20 Oct 2010 12:59:52 -0400 User-Agent: KMail/1.6.2 References: <4C732522.1010400@gmail.com> <20101003174833.V62022@sola.nimnet.asn.au> <4CBE42CA.3050103@gmail.com> In-Reply-To: <4CBE42CA.3050103@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010201300.05886.jkim@FreeBSD.org> Cc: Matt Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 17:00:29 -0000 On Tuesday 19 October 2010 09:15 pm, Matt wrote: > My experience with a sleeping freebsd laptop has been shortlived! > > Today I rebuilt world using clang & this morning's csup current. > Clang build went just swimmingly. > > Unthinkingly, I closed my laptop lid and put it in my case. > When I got to my house, it was roasting with fans spinning and > sleep light flashing. No damage, thankfully. > > Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop > sleep! > > I had recently fiddled with powerd, but problem persisted after > reverting to previous configuration of associated sysctls etc. > > Interestingly, sleep bounce now fails with a hard freeze, which it > never has in the past. > > Verbose output shows the wifi then re0 network interfaces going > from D0->D3 as last living output. > > Please note problem persists regardless of user, X running, > sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd > running/not running. > > Without sleep bounce, problem is characterized by flashing sleep > light and spinning fans (CPU temperature is high). > > No devices added or removed, was sleeping this morning before > buildworld. Is it worth rebuilding with gcc? Or a content change > and not a compiler issue? Any major pci changes lately maybe? Can you please update source and try again? If it does not work, please set a new tunable "hw.pci.do_power_suspend=0" and tell me whether it helps or not. FYI, hw.pci.do_power_resume does not apply to suspend any more. So, if you want to restore the previous behaviour, you need both "hw.pci.do_power_resume=0" and "hw.pci.do_power_suspend=0". However, my hunch tells me that you only need the latter. Also, if possible, I'd like to see 'devinfo -rv', 'pciconf -clv', 'acpidump -dt', and 'lspci -vvv' output. Note lspci is available via ports/sysutils/pciutils. Thanks, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:18:17 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 157CD106566B for ; Wed, 20 Oct 2010 17:18:17 +0000 (UTC) (envelope-from justin.victoria@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF9178FC19 for ; Wed, 20 Oct 2010 17:18:16 +0000 (UTC) Received: by gxk3 with SMTP id 3so1601884gxk.13 for ; Wed, 20 Oct 2010 10:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :in-reply-to:message-id:references:user-agent:mime-version :content-type; bh=A/bWBBIW5xxHlXqe8+baguXSiFmYBDSHV4mDeYcfvTQ=; b=RzkjpcEWcrmgiZNgnNrZ6Hk4Y6h3uacVWoFxJMQMEAA5XfYpvjOv3kNtXfnm32UwAp fgBNIzq3EwGWKAfwe4lDMzlRTecRDD9ua9lkjGWznFybY5/9q70wXbu2xl96DmCvZjnq o9GPw2scZUFQ0Vxzl8lM8suBmUdfJi5oYe/ms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; b=DAyN2Okp/V9/bZvHXDoZp0WQSJnCtocgzv1bXrXvP7D7clqF99L2yFAKRzEwGJG3kc D8cYGQWMjVFn4B8S+LYfo2fYLw3XfAEezicSMjnTCMm8pJuxoRJyR5AR+zk4/DfT2VII 7UlqVSkjdIA4FJZ9EJ161/zEh2Of9dw9yb5nA= Received: by 10.100.136.7 with SMTP id j7mr5505041and.64.1287594671159; Wed, 20 Oct 2010 10:11:11 -0700 (PDT) Received: from [192.168.1.169] (cpe-67-49-120-184.socal.res.rr.com [67.49.120.184]) by mx.google.com with ESMTPS id w3sm469051anw.25.2010.10.20.10.11.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 10:11:10 -0700 (PDT) Date: Wed, 20 Oct 2010 10:11:04 -0700 (PDT) From: jcv To: Alexander Best In-Reply-To: <20101020153040.GA3184@freebsd.org> Message-ID: References: <20101020153040.GA3184@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, freebsd-usb@freebsd.org Subject: Re: serious issue caused by usb device, stalling almost all operations 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, 20 Oct 2010 17:18:17 -0000 Sorry, I replied to another message regarding this matter by mistake.. Here is my intended response to the USB issue: Wow, i mounted my phone last nite and nothing that bad happened to my FreeBSD server. The only negative issue that I had was my Phone reset. This definately makes me nervous plugging my phone in now. Is there any other messages in /var/log/messages?? hbca# dmesg | grep da rum0: need multicast update callback da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry hbca# On Wed, 20 Oct 2010, Alexander Best wrote: > hi there, > > i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: > > after attaching my mobile phone, it simply resets without doing mount or > anything. however after letting the device come up again it won't show up in > the console. after detaching it the usb subsystem seemed to have completely > crashed. but that's not all. the following programs now simply hang without > producing any output C-C won't do anything: > > - dmesg > - top > - ps > - killall > - camcontrol devlist > - usbconfig > > i cannot even kill the apps, since top and ps aren't working so there's no way > to find out the PIDs. using 'killall dmesg' e.g. won't work either, since > killall will also stall. > > this is the console output which i could grab with > 'vidcontrol -H -P < /dev/ttyv0' (since dmesg doesn't work anymore): > > ugen3.3: at usbus3 > umass0: on usbus3 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to rea > dy change, medium may have changed) > da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3777MB (7736320 512 byte sectors: 255H 63S/T 481C) > (da0:umass-sim0:0:0:0): AutoSense failed > ugen3.3: at usbus3 (disconnected) > umass0: at uhub8, port 3, addr 3 (disconnected) > (da0:umass-sim0:0:0:0): AutoSense failed > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): Invalidating pack > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scsi status == > 0x0 > (da0:umass-sim0:0:0:0): removing device entry > lock order reversal: > 1st 0xffffffff80a37d50 GEOM topology (GEOM topology) @ /usr/src/sys/geom/label/ > g_label.c:320 > 2nd 0xffffffff808387a0 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysct > l.c:257 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x35 > kdb_backtrace() at kdb_backtrace+0x4e > _witness_debugger() at _witness_debugger+0x29 > witness_checkorder() at witness_checkorder+0xad2 > _sx_xlock() at _sx_xlock+0xae > sysctl_ctx_free() at sysctl_ctx_free+0x2e > dacleanup() at dacleanup+0x65 > camperiphfree() at camperiphfree+0x152 > cam_periph_release_locked() at cam_periph_release_locked+0x84 > cam_periph_release() at cam_periph_release+0x6d > daclose() at daclose+0x223 > g_disk_access() at g_disk_access+0x21c > g_access() at g_access+0x3b7 > g_label_taste() at g_label_taste+0x3be > g_new_provider_event() at g_new_provider_event+0x145 > one_event() at one_event+0x2d5 > g_run_events() at g_run_events+0xe > g_event_procbody() at g_event_procbody+0x8b > fork_exit() at fork_exit+0xfd > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff800003ecf0, rbp = 0 --- > > cheers. > alex > > -- > a13x > _______________________________________________ > 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 Oct 20 17:19: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 08DBB1065670 for ; Wed, 20 Oct 2010 17:19:50 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from lon1-post-3.mail.demon.net (lon1-post-3.mail.demon.net [195.173.77.150]) by mx1.freebsd.org (Postfix) with ESMTP id C7FEC8FC1A for ; Wed, 20 Oct 2010 17:19:49 +0000 (UTC) Received: from rakuman.demon.co.uk ([80.177.154.53] helo=rakuba.rakupottery.org.uk) by lon1-post-3.mail.demon.net with esmtp (Exim 4.69) id 1P8c76-0004nJ-fG for freebsd-current@freebsd.org; Wed, 20 Oct 2010 17:06:35 +0000 Message-ID: <4CBF2180.7040209@rakupottery.org.uk> Date: Wed, 20 Oct 2010 18:06:08 +0100 From: Martin Smith User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: installer unable to find device node 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, 20 Oct 2010 17:19:50 -0000 I am attempting to install a recent snapshot on a Biostar GF7100P-M7S mobo, with an atapi cdrom and on sata hd, after setting up the slices and selecting the install medium I am presented with the following error: Unable to find device node for ad4s1b in dev! The creation of filesystems will be aborted. This also happened with an 8.0 installer, is this just me, is there something funny about this motherboard? -- Martin From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:27: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 325511065672; Wed, 20 Oct 2010 17:27:35 +0000 (UTC) (envelope-from justin.victoria@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C57078FC19; Wed, 20 Oct 2010 17:27:34 +0000 (UTC) Received: by ywh2 with SMTP id 2so2194672ywh.13 for ; Wed, 20 Oct 2010 10:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :in-reply-to:message-id:references:user-agent:mime-version :content-type; bh=BQ6c7nzmBuRiWQyLWjGiiW3GlKXbAcQkKZapVRkcq8Y=; b=t3KcMtLW/+flhyBhjHU84/Ak4CTR15w/KlHuQVwi1IghvsCo3H8qRO4bG4OOQDRnSU g7ss3TG7V628oTEXG36+c7uxJOtOGKrArS1YTbsSfk+q4+isKs8PCAe+QHAjpNRaf8lp /9lLpi5izSinhQGcGf9etZgq6ZDgl3OpEvAoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; b=iEQFz5aJ1wX5T3hxZL9DXXUwdsmxU+HUvoqc/8vNuOuAgJkeNF/7Mbtpr35TFBGgcO r15RI7EIcsefMAh2mzV3siGMtF45OyPcs/STMziHE9LmPAxDJFZ+aqoxY0ObpzV7ZBpf e9JHWO4VSvgjlew1Ag8tBXm7RXBXeIeklfkv0= Received: by 10.42.179.135 with SMTP id bq7mr441969icb.151.1287594226640; Wed, 20 Oct 2010 10:03:46 -0700 (PDT) Received: from [192.168.1.169] (cpe-67-49-120-184.socal.res.rr.com [67.49.120.184]) by mx.google.com with ESMTPS id w9sm434192ibc.7.2010.10.20.10.03.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 10:03:46 -0700 (PDT) Date: Wed, 20 Oct 2010 10:03:39 -0700 (PDT) From: jcv To: Jung-uk Kim In-Reply-To: <201010201300.05886.jkim@FreeBSD.org> Message-ID: References: <4C732522.1010400@gmail.com> <20101003174833.V62022@sola.nimnet.asn.au> <4CBE42CA.3050103@gmail.com> <201010201300.05886.jkim@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: Matt , freebsd-current@freebsd.org Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 17:27:35 -0000 Wow, i mounted my phone last nite and nothing that bad happened. Is there any other messages in /var/log/messages?? hbca# dmesg | grep da rum0: need multicast update callback da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry hbca# On Wed, 20 Oct 2010, Jung-uk Kim wrote: > On Tuesday 19 October 2010 09:15 pm, Matt wrote: >> My experience with a sleeping freebsd laptop has been shortlived! >> >> Today I rebuilt world using clang & this morning's csup current. >> Clang build went just swimmingly. >> >> Unthinkingly, I closed my laptop lid and put it in my case. >> When I got to my house, it was roasting with fans spinning and >> sleep light flashing. No damage, thankfully. >> >> Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop >> sleep! >> >> I had recently fiddled with powerd, but problem persisted after >> reverting to previous configuration of associated sysctls etc. >> >> Interestingly, sleep bounce now fails with a hard freeze, which it >> never has in the past. >> >> Verbose output shows the wifi then re0 network interfaces going >> from D0->D3 as last living output. >> >> Please note problem persists regardless of user, X running, >> sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd >> running/not running. >> >> Without sleep bounce, problem is characterized by flashing sleep >> light and spinning fans (CPU temperature is high). >> >> No devices added or removed, was sleeping this morning before >> buildworld. Is it worth rebuilding with gcc? Or a content change >> and not a compiler issue? Any major pci changes lately maybe? > > Can you please update source and try again? If it does not work, > please set a new tunable "hw.pci.do_power_suspend=0" and tell me > whether it helps or not. FYI, hw.pci.do_power_resume does not apply > to suspend any more. So, if you want to restore the previous > behaviour, you need both "hw.pci.do_power_resume=0" and > "hw.pci.do_power_suspend=0". However, my hunch tells me that you > only need the latter. > > Also, if possible, I'd like to see 'devinfo -rv', 'pciconf -clv', > 'acpidump -dt', and 'lspci -vvv' output. Note lspci is available via > ports/sysutils/pciutils. > > Thanks, > > Jung-uk Kim > _______________________________________________ > 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 Oct 20 17:28: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 B089C106566B for ; Wed, 20 Oct 2010 17:28:15 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5F98FC1B for ; Wed, 20 Oct 2010 17:28:15 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9DC51E87D7; Wed, 20 Oct 2010 18:28:14 +0100 (BST) Received: from unknown (unknown [109.144.239.106]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 20 Oct 2010 18:28:14 +0100 (BST) Date: Wed, 20 Oct 2010 18:28:16 +0100 From: Bruce Cran To: Martin Smith Message-ID: <20101020182816.0000552b@unknown> In-Reply-To: <4CBF2180.7040209@rakupottery.org.uk> References: <4CBF2180.7040209@rakupottery.org.uk> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: installer unable to find device node 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, 20 Oct 2010 17:28:15 -0000 On Wed, 20 Oct 2010 18:06:08 +0100 Martin Smith wrote: > I am attempting to install a recent snapshot on a Biostar GF7100P-M7S > mobo, with an atapi cdrom and on sata hd, after setting up the slices > and selecting the install medium I am presented with the following > error: > > Unable to find device node for ad4s1b in dev! The creation of > filesystems will be aborted. > > This also happened with an 8.0 installer, is this just me, is there > something funny about this motherboard? Has the HDD previously been partitioned using GPT, or something other than a traditional MBR? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:37: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 EA7361065701 for ; Wed, 20 Oct 2010 17:37:34 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3178FC12 for ; Wed, 20 Oct 2010 17:37:34 +0000 (UTC) Received: by gxk3 with SMTP id 3so1618458gxk.13 for ; Wed, 20 Oct 2010 10:37:34 -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:content-transfer-encoding; bh=LgHP4zbAZJdI9VWInn2iaz2+jJWExZ9k/CG4A2xtGwA=; b=qcOx09PaoPdt1im4sVe8OpaqsWBcqvHLmF4Zw5LVxsbZihzDZlIPs7DoelJw0qFqpQ SoN69GrTXLvBSNfhC38w7YPHwF4OJ/H6RR9RZS93a9+ZLXDnP+UuT1YLkAucZZDcGTmE s52CTv4LI6drvktUkCpiz8WC6/AnxOGZFQ2ys= 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:content-transfer-encoding; b=CyqRkoTICZF8owaMmFnwMcPwBPA9kijsghRacs//Ov5xxMQ39g80dlajquSCR9MEdI OddrDO04O5qC0KJI6MMZqlMozgsIpqNRWr8jrMGUJz3omiR4eLnktolcVBeeE1USvDVf r504HE7UeayIq/JH8hmDFN9rjpPVRkUQJx9x4= Received: by 10.103.247.1 with SMTP id z1mr2819936mur.74.1287596253036; Wed, 20 Oct 2010 10:37:33 -0700 (PDT) Received: from ono-sendai.local ([75.111.34.169]) by mx.google.com with ESMTPS id y19sm283801fau.17.2010.10.20.10.37.30 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 10:37:31 -0700 (PDT) Message-ID: <4CBF28D8.3090207@gmail.com> Date: Wed, 20 Oct 2010 10:37:28 -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-current@freebsd.org References: <4C732522.1010400@gmail.com> <20101003174833.V62022@sola.nimnet.asn.au> <4CBE42CA.3050103@gmail.com> <201010201300.05886.jkim@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 17:37:35 -0000 > On Wed, 20 Oct 2010, Jung-uk Kim wrote: > >> On Tuesday 19 October 2010 09:15 pm, Matt wrote: >>> My experience with a sleeping freebsd laptop has been shortlived! >>> >>> Today I rebuilt world using clang & this morning's csup current. >>> Clang build went just swimmingly. >>> >>> Unthinkingly, I closed my laptop lid and put it in my case. >>> When I got to my house, it was roasting with fans spinning and >>> sleep light flashing. No damage, thankfully. >>> >>> Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop >>> sleep! >>> >>> I had recently fiddled with powerd, but problem persisted after >>> reverting to previous configuration of associated sysctls etc. >>> >>> Interestingly, sleep bounce now fails with a hard freeze, which it >>> never has in the past. >>> >>> Verbose output shows the wifi then re0 network interfaces going >>> from D0->D3 as last living output. >>> >>> Please note problem persists regardless of user, X running, >>> sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd >>> running/not running. >>> >>> Without sleep bounce, problem is characterized by flashing sleep >>> light and spinning fans (CPU temperature is high). >>> >>> No devices added or removed, was sleeping this morning before >>> buildworld. Is it worth rebuilding with gcc? Or a content change >>> and not a compiler issue? Any major pci changes lately maybe? >> >> Can you please update source and try again? If it does not work, >> please set a new tunable "hw.pci.do_power_suspend=0" and tell me >> whether it helps or not. FYI, hw.pci.do_power_resume does not apply >> to suspend any more. So, if you want to restore the previous >> behaviour, you need both "hw.pci.do_power_resume=0" and >> "hw.pci.do_power_suspend=0". However, my hunch tells me that you >> only need the latter. >> >> Also, if possible, I'd like to see 'devinfo -rv', 'pciconf -clv', >> 'acpidump -dt', and 'lspci -vvv' output. Note lspci is available via >> ports/sysutils/pciutils. >> >> Thanks, >> >> Jung-uk Kim >> _______________________________________________ >> 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 >> dump file of the above commands in order: http://pastebin.com/KhFn9xaK I'm grabbing a new csup now, glad it wasn't clang at least. When I did Mac development, LLVM binaries were generally significantly faster for some things. Interesting, I got some phone related topic added into your post, and no direct mail, so hopefully you can get your hands on the pastebin link. Thank you, I will let you know if the new tunable does the trick. Matt From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:38: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 CC7531065673 for ; Wed, 20 Oct 2010 17:38:28 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from anchor-post-3.mail.demon.net (anchor-post-3.mail.demon.net [195.173.77.134]) by mx1.freebsd.org (Postfix) with ESMTP id 9483C8FC0C for ; Wed, 20 Oct 2010 17:38:28 +0000 (UTC) Received: from rakuman.demon.co.uk ([80.177.154.53] helo=rakuba.rakupottery.org.uk) by anchor-post-3.mail.demon.net with esmtp (Exim 4.69) id 1P8ccN-0005dK-oG for freebsd-current@freebsd.org; Wed, 20 Oct 2010 17:38:27 +0000 Message-ID: <4CBF2913.8040303@rakupottery.org.uk> Date: Wed, 20 Oct 2010 18:38:27 +0100 From: Martin Smith User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CBF2180.7040209@rakupottery.org.uk> <20101020182816.0000552b@unknown> In-Reply-To: <20101020182816.0000552b@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: installer unable to find device node 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, 20 Oct 2010 17:38:28 -0000 On 20/10/2010 18:28, Bruce Cran wrote: > On Wed, 20 Oct 2010 18:06:08 +0100 > Martin Smith wrote: > >> I am attempting to install a recent snapshot on a Biostar GF7100P-M7S >> mobo, with an atapi cdrom and on sata hd, after setting up the slices >> and selecting the install medium I am presented with the following >> error: >> >> Unable to find device node for ad4s1b in dev! The creation of >> filesystems will be aborted. >> >> This also happened with an 8.0 installer, is this just me, is there >> something funny about this motherboard? > > Has the HDD previously been partitioned using GPT, or something other > than a traditional MBR? It was previously attached to a mac, do I need to zero out the partition table? > -- Martin From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:39: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 A426910656A3 for ; Wed, 20 Oct 2010 17:39:12 +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 26FE98FC18 for ; Wed, 20 Oct 2010 17:39:11 +0000 (UTC) Received: by wyb38 with SMTP id 38so4138728wyb.13 for ; Wed, 20 Oct 2010 10:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=UZ/0Ji/3MXGU56tNu+pD5MStlfJ14lYdo8LPVpNdQiw=; b=YoCmXsswSS4yqU3xJP/znpWpmDmYmlkQ2yj+78B/fZOX7Z5ee88ZV6v6yjFLG8D5Qw PyGX+wlSdtCXZY+9kN3gJw/7VEdzuMJNNypoCITMe8hRqHHQ0YM5RnzsWf3ul5bhFJqO RRjqn7t1NBVecdl1oPtGydYFw3xSlzPfX3LZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=MLLJMQ9t+hxNuAhq1uwsxhTR67q7JdB3Q78NVOpNnPUrIAl584/E81W30icueyzbLJ ME1dn2jXCPIpVD+fgORQY8hxUl1Rf4zQzSo3n2ak5UPUh06ZJOGNKxVfstC24+8/w0Yz p/x56iyOsvcW2Q1lxEFNsK8346XStYn4RGPl0= Received: by 10.227.145.66 with SMTP id c2mr4639643wbv.34.1287596351043; Wed, 20 Oct 2010 10:39:11 -0700 (PDT) Received: from dragon.dg (41-132-93-155.dsl.mweb.co.za [41.132.93.155]) by mx.google.com with ESMTPS id ga16sm400085wbb.13.2010.10.20.10.39.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 10:39:09 -0700 (PDT) From: David Naylor To: Luigi Rizzo Date: Wed, 20 Oct 2010 19:38:54 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.1; amd64; ; ) References: <201010180943.37042.naylor.b.david@gmail.com> <201010190807.59491.naylor.b.david@gmail.com> <20101019081824.GB54147@onelab2.iet.unipi.it> In-Reply-To: <20101019081824.GB54147@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2844468.XcjDmbjXDk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201010201938.58687.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: geom_sched usage 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, 20 Oct 2010 17:39:12 -0000 --nextPart2844468.XcjDmbjXDk Content-Type: multipart/mixed; boundary="Boundary-01=_ukyvMrk5pPo7POE" Content-Transfer-Encoding: 7bit --Boundary-01=_ukyvMrk5pPo7POE Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 19 October 2010 10:18:24 Luigi Rizzo wrote: > On Tue, Oct 19, 2010 at 08:07:54AM +0200, David Naylor wrote: > > Would there be any interest in having a rc.d/ script? I would find it > > conveniant to specify a single rc.conf line and get scheduling for all = my > > devices. PC-BSD might find such functionality useful. > >=20 > > See attached for my first draft at such a script, I'm willing to hash it > > into shape. >=20 > it would surely be useful but try to keep it simple and user-driven > (this is a general comment on rc.d scripts). > Some things i think you should simplify in your script: > - remove support for guessing which devices should get the scheduler. > This is really a user decision and if the user names no devices then > i believe it is better/safer not to install any scheduler. I agree but I do think there is a case for an 'ALL' command as the user may= =20 want scheduling on newly attached devices without knowning their device nam= es=20 (i.e. attached USB storage devices). =20 I would also like to add a ``gsched_nodev'' that allows one to use 'ALL'=20 without having to apply gsched to everything. =20 See attached for a devd.conf file that add supports for that. =20 > - use standard names such as gsched_flags or gsched_flags_${dev} to hold > generic and specific flags for the insert command. > It is neither useful nor flexible to have the script insert '-a' > in front of the algorithm; I've changed the variable names. See attached for the rc.d script. =20 @Miroslav: thanks for the tip --Boundary-01=_ukyvMrk5pPo7POE Content-Type: text/plain; charset="ISO-8859-1"; name="gsched.conf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gsched.conf.txt" notify 100 { match "system" "DEVFS"; match "subsystem" "CDEV"; match "type" "CREATE"; match "cdev" "(ad|ada|cd|da)[0-9]+"; action "/etc/rc.d/gsched start $cdev"; }; --Boundary-01=_ukyvMrk5pPo7POE Content-Type: text/plain; charset="ISO-8859-1"; name="gsched.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="gsched.txt" #!/bin/sh # # $FreeBSD$ # # Specify gsched_enable=3D"YES" in /etc/rc.conf(.local) to activate schedul= ing on # storage devices. =20 #=20 # gsched_devs is a space separated list of accepted devices. `ALL' may be = used=20 # to indicate all storage devices. =20 # # gsched_flags_$dev specifies storage device specific flags (i.e. ``-a rr''= to # use rr scheduling, see gsched(8) insert command). =20 # TODO: # - add gsched profiles, such as `desktop' for kern.geom.sched.rr tunables # - add rejected list # PROVIDE: gsched # KEYWORD: nojail =2E /etc/rc.subr gsched_enable=3D${gsched_enable:-NO} name=3D"gsched" rcvar=3D`set_rcvar` command=3D"/sbin/${name}" start_cmd=3D"gsched_start" stop_cmd=3D"gsched_stop" gsched_filter() { local _gsched_devs _devs _devs_recon _kern_disks _kern_disks=3D`sysctl -n kern.disks` _devs=3D$* if [ -z "${_devs}" ]; then _devs=3D${_kern_disks} fi _gsched_devs=3D${gsched_devs} case ${_gsched_devs} in [aA][lL][lL]) _gsched_devs=3D${_kern_disks} ;; esac for _g in ${_devs}; do # Filter all devs that are part of gsched_devs case " ${_gsched_devs} " in *\ ${_g}\ *) # Filter all devs that exist case " ${_kern_disks} " in *\ ${_g}\ *) # ${_g} is part of ${gsched_dev} and it exists _devs_recon=3D"${_devs_recon} ${_g}" ;; esac ;; esac done echo ${_devs_recon} } gsched_start() { local _devs _g _gsched_flags # Make sure only accepted (and existing) devices are used # _devs=3D`gsched_filter $*` echo -n "Starting gsched devices:" for _g in ${_devs}; do echo -n " $_g" eval _gsched_flags=3D\$gsched_flags_${_g} ${command} insert ${_gsched_flags} ${_g} done echo "." } gsched_stop() { local _devs _g # Make sure only accepted (and existing) devices are used # _devs=3D`gsched_filter $*` echo -n "Stopping gsched devices:" for _g in ${_devs}; do echo -n " $_g" ${command} destroy ${_g}.sched. done echo "." } load_rc_config $name run_rc_command $* --Boundary-01=_ukyvMrk5pPo7POE-- --nextPart2844468.XcjDmbjXDk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEABECAAYFAky/KTIACgkQUaaFgP9pFrKINwCeOqM9aIPT3/nVAAM3IEXDlc0J HVgAoIUXmVzFHqNGaLF/NgUZObcJVXPK =jnBA -----END PGP SIGNATURE----- --nextPart2844468.XcjDmbjXDk-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:50: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 EFA9F1065741 for ; Wed, 20 Oct 2010 17:50:49 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B24158FC1B for ; Wed, 20 Oct 2010 17:50:49 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 06A3CE87D7; Wed, 20 Oct 2010 18:50:49 +0100 (BST) Received: from unknown (unknown [109.144.239.106]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 20 Oct 2010 18:50:48 +0100 (BST) Date: Wed, 20 Oct 2010 18:50:50 +0100 From: Bruce Cran To: Martin Smith Message-ID: <20101020185050.00004ba3@unknown> In-Reply-To: <4CBF2913.8040303@rakupottery.org.uk> References: <4CBF2180.7040209@rakupottery.org.uk> <20101020182816.0000552b@unknown> <4CBF2913.8040303@rakupottery.org.uk> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: installer unable to find device node 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, 20 Oct 2010 17:50:50 -0000 On Wed, 20 Oct 2010 18:38:27 +0100 Martin Smith wrote: > It was previously attached to a mac, do I need to zero out the > partition table? If it was an x86 Mac then you'll need to zero out the start and end of the disk since GPT has entries in the first and last sectors. If it was a PowerPC Mac then I don't know where the Apple Partition Table entries are stored. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:52: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 99E961065693 for ; Wed, 20 Oct 2010 17:52:49 +0000 (UTC) (envelope-from sendtomatt@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 231518FC0A for ; Wed, 20 Oct 2010 17:52:48 +0000 (UTC) Received: by fxm12 with SMTP id 12so2881443fxm.13 for ; Wed, 20 Oct 2010 10:52:48 -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:content-transfer-encoding; bh=SRHFdV2PiFSZoZptW6uwZ/ymV28uVQh/2Z1OQMUbzBw=; b=ifrYAKWk8mygLOAc/+mJcvL6EOAm59bfASNheHZnfggb/5C4UPeoQwb+nYtea3uApl o6+xGFnSeEv3hK1TL8jxuOBucjLYpJ7FNPcUl6wh+HkgqnWpZKFXVFRDOipnGer1MP+9 5Mwtxbxrqnm1SM687ssgoO+I9Vv7ApDpK+oDs= 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:content-transfer-encoding; b=KoM2Mx4o9UYwZoWOxv5zy/xmmY9/+6crvIFVGx3gRGSbJ+zaD/e3Lqgv6mllgt/+0Q o6OAxSh0HbWv0VkKRQ8MjdLZK8NhchWNOkuOX26HjI0hua6kCaUTWwOb6BhIGYGQMCVh P6YKhulnU0jYy23Rb6Pk253/u84WGjlduHX7M= Received: by 10.102.228.2 with SMTP id a2mr7171936muh.60.1287597167801; Wed, 20 Oct 2010 10:52:47 -0700 (PDT) Received: from ono-sendai.local ([75.111.34.169]) by mx.google.com with ESMTPS id 10sm295451fax.18.2010.10.20.10.52.45 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 10:52:46 -0700 (PDT) Message-ID: <4CBF2C6B.4030704@gmail.com> Date: Wed, 20 Oct 2010 10:52:43 -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-current@freebsd.org References: <4C732522.1010400@gmail.com> <20101003174833.V62022@sola.nimnet.asn.au> <4CBE42CA.3050103@gmail.com> <201010201300.05886.jkim@FreeBSD.org> <4CBF28D8.3090207@gmail.com> In-Reply-To: <4CBF28D8.3090207@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 17:52:49 -0000 On 10/20/10 10:37, Matt wrote: > >> On Wed, 20 Oct 2010, Jung-uk Kim wrote: >> >>> On Tuesday 19 October 2010 09:15 pm, Matt wrote: >>>> My experience with a sleeping freebsd laptop has been shortlived! >>>> >>>> Today I rebuilt world using clang & this morning's csup current. >>>> Clang build went just swimmingly. >>>> >>>> Unthinkingly, I closed my laptop lid and put it in my case. >>>> When I got to my house, it was roasting with fans spinning and >>>> sleep light flashing. No damage, thankfully. >>>> >>>> Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop >>>> sleep! >>>> >>>> I had recently fiddled with powerd, but problem persisted after >>>> reverting to previous configuration of associated sysctls etc. >>>> >>>> Interestingly, sleep bounce now fails with a hard freeze, which it >>>> never has in the past. >>>> >>>> Verbose output shows the wifi then re0 network interfaces going >>>> from D0->D3 as last living output. >>>> >>>> Please note problem persists regardless of user, X running, >>>> sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd >>>> running/not running. >>>> >>>> Without sleep bounce, problem is characterized by flashing sleep >>>> light and spinning fans (CPU temperature is high). >>>> >>>> No devices added or removed, was sleeping this morning before >>>> buildworld. Is it worth rebuilding with gcc? Or a content change >>>> and not a compiler issue? Any major pci changes lately maybe? >>> >>> Can you please update source and try again? If it does not work, >>> please set a new tunable "hw.pci.do_power_suspend=0" and tell me >>> whether it helps or not. FYI, hw.pci.do_power_resume does not apply >>> to suspend any more. So, if you want to restore the previous >>> behaviour, you need both "hw.pci.do_power_resume=0" and >>> "hw.pci.do_power_suspend=0". However, my hunch tells me that you >>> only need the latter. >>> >>> Also, if possible, I'd like to see 'devinfo -rv', 'pciconf -clv', >>> 'acpidump -dt', and 'lspci -vvv' output. Note lspci is available via >>> ports/sysutils/pciutils. >>> >>> Thanks, >>> >>> Jung-uk Kim >>> _______________________________________________ >>> 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 >> dump file of the above commands in order: > http://pastebin.com/KhFn9xaK > > I'm grabbing a new csup now, glad it wasn't clang at least. When I did > Mac development, LLVM binaries were generally significantly faster for > some things. > > Interesting, I got some phone related topic added into your post, and > no direct mail, so hopefully you can get your hands on the pastebin link. > > Thank you, I will let you know if the new tunable does the trick. > > Matt Build fails. I will also try gcc, but it seems like it doesn't know about do_power_suspend yet! cd /usr/obj/usr/src/sys/ONOSENDAI; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=nocona GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 9.0-CURRENT amd64 900023" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel all -DNO_MODULES_OBJ clang -c -O2 -fno-strict-aliasing -pipe -march=nocona -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/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/dev/pci/pci_pci.c clang: warning: argument unused during compilation: '-mfpmath=387' /usr/src/sys/dev/pci/pci_pci.c:450:20: error: use of undeclared identifier 'pci_do_power_suspend'; did you mean 'pci_do_power_resume'? if (error == 0 && pci_do_power_suspend) { ^~~~~~~~~~~~~~~~~~~~ pci_do_power_resume In file included from /usr/src/sys/dev/pci/pci_pci.c:51: /usr/src/sys/dev/pci/pci_private.h:41:13: note: 'pci_do_power_resume' declared here extern int pci_do_power_resume; ^ 1 error generated. *** Error code 1 Stop in /usr/obj/usr/src/sys/ONOSENDAI. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Matt From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:54: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 1F0AB10656A4; Wed, 20 Oct 2010 17:54:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 253908FC0C; Wed, 20 Oct 2010 17:54:44 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=88e7-T71Oz4A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=zk-QPIRbcTxHS1SbQ3EA:9 a=Moe5nSEDNAsiRCxPdgNk8Or1ydcA:4 a=wPNLvfGTeEIA:10 a=iTBbjxRKQiG1Xzjl:21 a=YgJZt3ZVx1deoEbO:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 38038615; Wed, 20 Oct 2010 19:54:43 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Wed, 20 Oct 2010 19:55:56 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101020153040.GA3184@freebsd.org> In-Reply-To: <20101020153040.GA3184@freebsd.org> 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="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010201955.56816.hselasky@c2i.net> Cc: Alexander Best , mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: serious issue caused by usb device, stalling almost all operations 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, 20 Oct 2010 17:54:46 -0000 On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: > hi there, > > i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: > > after attaching my mobile phone, it simply resets without doing mount or > anything. however after letting the device come up again it won't show up > in the console. after detaching it the usb subsystem seemed to have > completely crashed. but that's not all. the following programs now simply > hang without producing any output C-C won't do anything: > > - dmesg > - top > - ps > - killall > - camcontrol devlist > - usbconfig That's most likely because USB's umass driver is waiting for cam to drain. Possibly some refcounting is not correct. I suspect this is not a USB problem. Try to enter into the debugger, and look for backtrace for function stuck in umass_detach. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 18:46:41 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 10F95106566B; Wed, 20 Oct 2010 18:46:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 20 Oct 2010 14:46:20 -0400 User-Agent: KMail/1.6.2 References: <4C732522.1010400@gmail.com> <4CBF28D8.3090207@gmail.com> <4CBF2C6B.4030704@gmail.com> In-Reply-To: <4CBF2C6B.4030704@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010201446.26383.jkim@FreeBSD.org> Cc: Matt Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 18:46:41 -0000 On Wednesday 20 October 2010 01:52 pm, Matt wrote: > On 10/20/10 10:37, Matt wrote: > >> On Wed, 20 Oct 2010, Jung-uk Kim wrote: > >>> On Tuesday 19 October 2010 09:15 pm, Matt wrote: > >>>> My experience with a sleeping freebsd laptop has been > >>>> shortlived! > >>>> > >>>> Today I rebuilt world using clang & this morning's csup > >>>> current. Clang build went just swimmingly. > >>>> > >>>> Unthinkingly, I closed my laptop lid and put it in my case. > >>>> When I got to my house, it was roasting with fans spinning and > >>>> sleep light flashing. No damage, thankfully. > >>>> > >>>> Low and behold, hw.pci.do_power_resume=0 no longer lets my > >>>> laptop sleep! > >>>> > >>>> I had recently fiddled with powerd, but problem persisted > >>>> after reverting to previous configuration of associated > >>>> sysctls etc. > >>>> > >>>> Interestingly, sleep bounce now fails with a hard freeze, > >>>> which it never has in the past. > >>>> > >>>> Verbose output shows the wifi then re0 network interfaces > >>>> going from D0->D3 as last living output. > >>>> > >>>> Please note problem persists regardless of user, X running, > >>>> sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd > >>>> running/not running. > >>>> > >>>> Without sleep bounce, problem is characterized by flashing > >>>> sleep light and spinning fans (CPU temperature is high). > >>>> > >>>> No devices added or removed, was sleeping this morning before > >>>> buildworld. Is it worth rebuilding with gcc? Or a content > >>>> change and not a compiler issue? Any major pci changes lately > >>>> maybe? > >>> > >>> Can you please update source and try again? If it does not > >>> work, please set a new tunable "hw.pci.do_power_suspend=0" and > >>> tell me whether it helps or not. FYI, hw.pci.do_power_resume > >>> does not apply to suspend any more. So, if you want to restore > >>> the previous behaviour, you need both > >>> "hw.pci.do_power_resume=0" and "hw.pci.do_power_suspend=0". > >>> However, my hunch tells me that you only need the latter. > >>> > >>> Also, if possible, I'd like to see 'devinfo -rv', 'pciconf > >>> -clv', 'acpidump -dt', and 'lspci -vvv' output. Note lspci is > >>> available via ports/sysutils/pciutils. > >>> > >>> Thanks, > >>> > >>> Jung-uk Kim > >>> _______________________________________________ > >>> 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 >> dump file of the above commands in order: > > http://pastebin.com/KhFn9xaK > > > > I'm grabbing a new csup now, glad it wasn't clang at least. When > > I did Mac development, LLVM binaries were generally significantly > > faster for some things. > > > > Interesting, I got some phone related topic added into your post, > > and no direct mail, so hopefully you can get your hands on the > > pastebin link. > > > > Thank you, I will let you know if the new tunable does the trick. > > > > Matt > > Build fails. I will also try gcc, but it seems like it doesn't know > about do_power_suspend yet! > > > cd /usr/obj/usr/src/sys/ONOSENDAI; MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=nocona > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 9.0-CURRENT > amd64 900023" INSTALL="sh /usr/src/tools/install.sh" > PATH=/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:/usr/obj/usr/src/tm >p/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/gam >es:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel all > -DNO_MODULES_OBJ > clang -c -O2 -fno-strict-aliasing -pipe -march=nocona -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/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx > -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fstack-protector /usr/src/sys/dev/pci/pci_pci.c > clang: warning: argument unused during compilation: '-mfpmath=387' > /usr/src/sys/dev/pci/pci_pci.c:450:20: error: use of undeclared > identifier 'pci_do_power_suspend'; did you mean > 'pci_do_power_resume'? if (error == 0 && pci_do_power_suspend) { > ^~~~~~~~~~~~~~~~~~~~ > pci_do_power_resume > In file included from /usr/src/sys/dev/pci/pci_pci.c:51: > /usr/src/sys/dev/pci/pci_private.h:41:13: note: > 'pci_do_power_resume' declared > here > extern int pci_do_power_resume; > ^ > 1 error generated. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/ONOSENDAI. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. It seems your sys/dev/pci/pci_private.h is out of sync somehow. It was updated with pci_pci.c in the same commit. Please try csup again. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 19:45: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 2C9C9106566B for ; Wed, 20 Oct 2010 19:45:52 +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 956F68FC1C for ; Wed, 20 Oct 2010 19:45:51 +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 o9KJjmh7030662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 06:45:49 +1100 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 o9KJjmfo094298; Thu, 21 Oct 2010 06:45:48 +1100 (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 o9KJjlJJ094297; Thu, 21 Oct 2010 06:45:47 +1100 (EST) (envelope-from peter) Date: Thu, 21 Oct 2010 06:45:47 +1100 From: Peter Jeremy To: KOT MATPOCKuH Message-ID: <20101020194547.GA94244@server.vk2pj.dyndns.org> References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 19:45:52 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Oct-20 10:50:38 +0400, KOT MATPOCKuH wrote: >> I fixed it with attached patch. >Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"))? Can you explain why you think it should be strncmp() please. --=20 Peter Jeremy --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAky/RusACgkQ/opHv/APuIfTawCfeyG2RXkxfhKjoGOdHD2Eif0h BFMAnA11SiMUhJeV38jBLo2ZXME/62Ja =WJyt -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 20:39: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 8E7D81065672 for ; Wed, 20 Oct 2010 20:39:27 +0000 (UTC) (envelope-from yanegomi@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 2022E8FC14 for ; Wed, 20 Oct 2010 20:39:26 +0000 (UTC) Received: by wyb38 with SMTP id 38so4310152wyb.13 for ; Wed, 20 Oct 2010 13:39:25 -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=TpvMBhLDdYNuGLO8jBpVr2wGDULJxN1WGs1sS2QDaAY=; b=uBm00oE0gSn/m8Dqa4Pii8sAZ4RCsGx6ewbiA06VROSWXPKK7A7PpEkkM1q++bc/b6 jlaNUbViSyLjZZHV0XkDtKzYMsa3IyHq9qQT6QpgZAetyH0Mua38yZdrX42V1JFoi4HU PRyZIshHZZ2E1wFy7/YixQz6zGKh5ZW7mSFYM= 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=Qr5G10IUgGpCsUtb/OfCttdCJdUGYipnNZHuEzJiCx37CIYG19MG2OjbTigl2TzKKG Ki3xCgKSzUsXGc5IY+P8633EeJ379iQzSkZo5PglEr9n/lHUb3xolenEoEpedxJPRc0i mljnIaYXjJBGKtdv2H/n2pmCC1SC66eXhrOXE= MIME-Version: 1.0 Received: by 10.216.35.74 with SMTP id t52mr8198436wea.41.1287607165600; Wed, 20 Oct 2010 13:39:25 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.135.67 with HTTP; Wed, 20 Oct 2010 13:39:25 -0700 (PDT) In-Reply-To: <20101020194547.GA94244@server.vk2pj.dyndns.org> References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <20101020194547.GA94244@server.vk2pj.dyndns.org> Date: Wed, 20 Oct 2010 13:39:25 -0700 X-Google-Sender-Auth: GnMktJOOfeNGO-EeUj5qs0l34bw Message-ID: From: Garrett Cooper To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 20:39:27 -0000 On Wed, Oct 20, 2010 at 12:45 PM, Peter Jeremy wrote: > On 2010-Oct-20 10:50:38 +0400, KOT MATPOCKuH wrote: >>> I fixed it with attached patch. >>Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"))? > > Can you explain why you think it should be strncmp() please. I'd say that strcmp is perfectly fine because zfs is a 3 character (4 if you count NUL) string. The comparison logic is dang near the same: /* * Compare strings. */ int strcmp(const char *s1, const char *s2) { while (*s1 == *s2++) if (*s1++ == '\0') return (0); return (*(const unsigned char *)s1 - *(const unsigned char *)(s2 - 1)); } int strncmp(const char *s1, const char *s2, size_t n) { if (n == 0) return (0); do { if (*s1 != *s2++) return (*(const unsigned char *)s1 - *(const unsigned char *)(s2 - 1)); if (*s1++ == '\0') break; } while (--n != 0); return (0); } Weird how n == 0 with strcmp returns 0... -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 20:40: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 382241065679 for ; Wed, 20 Oct 2010 20:40:13 +0000 (UTC) (envelope-from yanegomi@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 BA7F28FC08 for ; Wed, 20 Oct 2010 20:40:12 +0000 (UTC) Received: by wyb38 with SMTP id 38so4310862wyb.13 for ; Wed, 20 Oct 2010 13:40:11 -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=IYAVlv+xe523OWKF1RQoVy7GstibqMQmHgS3+HnvM70=; b=rLt/jfml2IHOWlQpDnGclL0RcwMnjaGK3MS6pz7IlkTJbiezM8XWhXiJf47fmT6kz6 5MsEYgAoVG2ESc8ALgsVuLR/IPItKUxPPwy269f0BhBXlhTWBkRIUga/1q7fMyQfmhXT nHTpxY6VpgQgGNFmebm6OvdPWL2prQ7sTcjz8= 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=IydkrefzXfo8mFZTqMbRg1w3m9V8FtsEOlcG2zooP4VEsQsfsOjCCbMfml5MMKMfW3 5c3jdHzSCoNauO3w86WRjpwclXO5Z4fZmaZxRxpo2v3QpVNjQ/nHOH4lKzSlQEFD056z WtxH2o5z7EHI7zujZOu5oEHLp6jk//2JNmMc8= MIME-Version: 1.0 Received: by 10.216.93.9 with SMTP id k9mr8171840wef.89.1287607211566; Wed, 20 Oct 2010 13:40:11 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.135.67 with HTTP; Wed, 20 Oct 2010 13:40:11 -0700 (PDT) In-Reply-To: References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <20101020194547.GA94244@server.vk2pj.dyndns.org> Date: Wed, 20 Oct 2010 13:40:11 -0700 X-Google-Sender-Auth: pU711c7O5GjulbSHaHCgSNoOlFc Message-ID: From: Garrett Cooper To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 20:40:13 -0000 On Wed, Oct 20, 2010 at 1:39 PM, Garrett Cooper wrote= : > On Wed, Oct 20, 2010 at 12:45 PM, Peter Jeremy wrot= e: >> On 2010-Oct-20 10:50:38 +0400, KOT MATPOCKuH wrote= : >>>> I fixed it with attached patch. >>>Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"= ))? >> >> Can you explain why you think it should be strncmp() please. > > I'd say that strcmp is perfectly fine because zfs is a 3 character (4 > if you count NUL) string. The comparison logic is dang near the same: > > /* > =A0* Compare strings. > =A0*/ > int > strcmp(const char *s1, const char *s2) > { > =A0 =A0 =A0 =A0while (*s1 =3D=3D *s2++) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (*s1++ =3D=3D '\0') > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > =A0 =A0 =A0 =A0return (*(const unsigned char *)s1 - *(const unsigned char= *)(s2 - 1)); > } > > int > strncmp(const char *s1, const char *s2, size_t n) > { > > =A0 =A0 =A0 =A0if (n =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > =A0 =A0 =A0 =A0do { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (*s1 !=3D *s2++) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (*(const unsigned c= har *)s1 - > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*(const un= signed char *)(s2 - 1)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (*s1++ =3D=3D '\0') > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0} while (--n !=3D 0); > =A0 =A0 =A0 =A0return (0); > } > > Weird how n =3D=3D 0 with strcmp returns 0... s/strcmp/strncmp/ -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 20:53: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 1BDD91065670; Wed, 20 Oct 2010 20:53:13 +0000 (UTC) (envelope-from jfvogel@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 78DCA8FC16; Wed, 20 Oct 2010 20:53:12 +0000 (UTC) Received: by ewy21 with SMTP id 21so2791917ewy.13 for ; Wed, 20 Oct 2010 13:53:11 -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=UWt0dHlGRTQr5n87BpAGxbwucqshBBcLbHMTUjyvYOY=; b=flh9PjkbuCoQqtH1pfgkeYrhVmWMphZLvcALsCRZdZl1etV23GwJEqeiHI49OYnJ5m MPSLyg1JvL7AhFc0u0My8cMYCwrE0X3saVbBHippvySrVC75x2aFyUJ9UXZH8PY/iK0L ObuI7px9dsx78lGMcRsOxvoQlSqWIpJRFQZEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BOceohfc7NwOH+2uC5iFBliyXjU4Ihf4B0jwViGkq9HkS6hYm1zB+rT0SyY+mlAUBU RULomogVrJETZIjr3Ii3zC/MHTZXKY3IefiyTQtBO19Owk6kWwClEGG/ZV12sKmW8TXj t/KirznHTfggXUh8KkNcEs8+/h2Tklt/KOhCE= MIME-Version: 1.0 Received: by 10.216.236.42 with SMTP id v42mr8768434weq.10.1287607991193; Wed, 20 Oct 2010 13:53:11 -0700 (PDT) Received: by 10.216.232.132 with HTTP; Wed, 20 Oct 2010 13:53:11 -0700 (PDT) Date: Wed, 20 Oct 2010 13:53:11 -0700 Message-ID: From: Jack Vogel To: FreeBSD Net , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: IPV6 Checksum offload and TSO6 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, 20 Oct 2010 20:53:13 -0000 I had occasion to think about this, and I was wondering if someone is working to add either or both of these features, Intel's hardware supports it, it does not seem that hard to add, or am I missing something? Cheers, Jack From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 20:58: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 841FD106564A for ; Wed, 20 Oct 2010 20:58:10 +0000 (UTC) (envelope-from sendtomatt@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 099DE8FC17 for ; Wed, 20 Oct 2010 20:58:09 +0000 (UTC) Received: by eydd26 with SMTP id d26so990530eyd.13 for ; Wed, 20 Oct 2010 13:58:08 -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:content-transfer-encoding; bh=LP46bbjlZqgosAmVBVIQdPQzWH1xp1RwRK2nYlR6zfY=; b=QDqLsQ6C2az1yKOS+wxi+8Ua9eVoUppq1vqNqTNZ+qgrYreSJl9gzrWvxN0I3mlq12 U62wPLHsHUwhag+oFiinWJTFWMNNFr0U7lYR/l5NGqSntxEdpv0Fp8zlrReExy294+1W YQOm3wkgsyPAGfuT6+Bd4hXZGewMtX8nlyB30= 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:content-transfer-encoding; b=WS8ETeGtye7lvWdbb7Gd/BJGBpsd/qMiSItc4Qp8W1rka4xgS44ltnpKSY4BlomyNV JRMsg1n2tXbIQxL6T1teH9tHPxl4v5l/cSM+RP4cbbjxECgEHKd94GxSif2roai8z5rY gbny4/NV4N9gQLqH4zwYA9O5mfahcYzfH95zo= Received: by 10.103.121.17 with SMTP id y17mr1781580mum.10.1287608288351; Wed, 20 Oct 2010 13:58:08 -0700 (PDT) Received: from ono-sendai.local ([70.237.48.30]) by mx.google.com with ESMTPS id z19sm431072fam.16.2010.10.20.13.58.05 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 13:58:07 -0700 (PDT) Message-ID: <4CBF57CE.7090504@gmail.com> Date: Wed, 20 Oct 2010 13:57:50 -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-current@freebsd.org References: <4C732522.1010400@gmail.com> <20101003174833.V62022@sola.nimnet.asn.au> <4CBE42CA.3050103@gmail.com> <201010201300.05886.jkim@FreeBSD.org> <4CBF28D8.3090207@gmail.com> <4CBF2C6B.4030704@gmail.com> In-Reply-To: <4CBF2C6B.4030704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 20:58:11 -0000 On 10/20/10 10:52, Matt wrote: > On 10/20/10 10:37, Matt wrote: >> >>> On Wed, 20 Oct 2010, Jung-uk Kim wrote: >>> >>>> On Tuesday 19 October 2010 09:15 pm, Matt wrote: >>>>> My experience with a sleeping freebsd laptop has been shortlived! >>>>> >>>>> Today I rebuilt world using clang & this morning's csup current. >>>>> Clang build went just swimmingly. >>>>> >>>>> Unthinkingly, I closed my laptop lid and put it in my case. >>>>> When I got to my house, it was roasting with fans spinning and >>>>> sleep light flashing. No damage, thankfully. >>>>> >>>>> Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop >>>>> sleep! >>>>> >>>>> I had recently fiddled with powerd, but problem persisted after >>>>> reverting to previous configuration of associated sysctls etc. >>>>> >>>>> Interestingly, sleep bounce now fails with a hard freeze, which it >>>>> never has in the past. >>>>> >>>>> Verbose output shows the wifi then re0 network interfaces going >>>>> from D0->D3 as last living output. >>>>> >>>>> Please note problem persists regardless of user, X running, >>>>> sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd >>>>> running/not running. >>>>> >>>>> Without sleep bounce, problem is characterized by flashing sleep >>>>> light and spinning fans (CPU temperature is high). >>>>> >>>>> No devices added or removed, was sleeping this morning before >>>>> buildworld. Is it worth rebuilding with gcc? Or a content change >>>>> and not a compiler issue? Any major pci changes lately maybe? >>>> >>>> Can you please update source and try again? If it does not work, >>>> please set a new tunable "hw.pci.do_power_suspend=0" and tell me >>>> whether it helps or not. FYI, hw.pci.do_power_resume does not apply >>>> to suspend any more. So, if you want to restore the previous >>>> behaviour, you need both "hw.pci.do_power_resume=0" and >>>> "hw.pci.do_power_suspend=0". However, my hunch tells me that you >>>> only need the latter. >>>> >>>> Also, if possible, I'd like to see 'devinfo -rv', 'pciconf -clv', >>>> 'acpidump -dt', and 'lspci -vvv' output. Note lspci is available via >>>> ports/sysutils/pciutils. >>>> >>>> Thanks, >>>> >>>> Jung-uk Kim >>>> _______________________________________________ >>>> 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 >> dump file of the above commands in order: >> http://pastebin.com/KhFn9xaK >> >> I'm grabbing a new csup now, glad it wasn't clang at least. When I >> did Mac development, LLVM binaries were generally significantly >> faster for some things. >> >> Interesting, I got some phone related topic added into your post, and >> no direct mail, so hopefully you can get your hands on the pastebin >> link. >> >> Thank you, I will let you know if the new tunable does the trick. >> >> Matt > > Build fails. I will also try gcc, but it seems like it doesn't know > about do_power_suspend yet! > > > cd /usr/obj/usr/src/sys/ONOSENDAI; MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=nocona > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 9.0-CURRENT > amd64 900023" INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > make KERNEL=kernel all -DNO_MODULES_OBJ > clang -c -O2 -fno-strict-aliasing -pipe -march=nocona -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/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx > -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fstack-protector /usr/src/sys/dev/pci/pci_pci.c > clang: warning: argument unused during compilation: '-mfpmath=387' > /usr/src/sys/dev/pci/pci_pci.c:450:20: error: use of undeclared > identifier > 'pci_do_power_suspend'; did you mean 'pci_do_power_resume'? > if (error == 0 && pci_do_power_suspend) { > ^~~~~~~~~~~~~~~~~~~~ > pci_do_power_resume > In file included from /usr/src/sys/dev/pci/pci_pci.c:51: > /usr/src/sys/dev/pci/pci_private.h:41:13: note: 'pci_do_power_resume' > declared > here > extern int pci_do_power_resume; > ^ > 1 error generated. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/ONOSENDAI. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > Matt Commented out code at as though "pci_do_power_suspend" = false, still does not sleep. Tried setting do_power_resume to 1 and 0, same result. debug.acpi.suspend_bounce returns to VT and freezes, nothing logged (was not verbose booted at the time however). From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 22:18:17 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 BCEB7106564A for ; Wed, 20 Oct 2010 22:18:17 +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 7200C8FC1B for ; Wed, 20 Oct 2010 22:18:17 +0000 (UTC) Received: by iwn41 with SMTP id 41so1658063iwn.13 for ; Wed, 20 Oct 2010 15:18: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; bh=OhdCcccC0RBN/rUsEhn9TKX1G/r9+5PluNqy4FvTI5E=; b=iCJr57OB83i6aA6bE0klVnX1zDDbRenRjSzvoJ19pqpTGOsFmeovSzB/j4zjp0yQjX vVvvA9dThK+AVC6Gh57S6tQgHAmDsa/rSHJgQNQB8o6H3rVGvunK89GN6UqEoiA0AUti XRzpAxDoj4O5KzG03+Q8e48OtvYUwQSwtAPRY= 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=hbB3wbvxYvHULum8UoyurJyuQxUBT6qCC0zaFrQXDU80lzZpF4zfp6DX6l0roOwJ+w XAyRB1D/Iwv5eViZNY0gx8QqRH9OnUWa3/An0NnsHLhYiOqLYnWZPNF0rJKrp1k0/gAB 16NiJZwHJ9230jM/kO2uPmw1tgb8+mjuMrEKk= MIME-Version: 1.0 Received: by 10.231.146.80 with SMTP id g16mr169555ibv.70.1287613096849; Wed, 20 Oct 2010 15:18:16 -0700 (PDT) Received: by 10.231.166.199 with HTTP; Wed, 20 Oct 2010 15:18:16 -0700 (PDT) In-Reply-To: References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <20101020194547.GA94244@server.vk2pj.dyndns.org> Date: Wed, 20 Oct 2010 15:18:16 -0700 Message-ID: From: Matthew Fleming To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: KOT MATPOCKuH , FreeBSD Current , Peter Jeremy Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 22:18:17 -0000 On Wed, Oct 20, 2010 at 1:39 PM, Garrett Cooper wrote: > On Wed, Oct 20, 2010 at 12:45 PM, Peter Jeremy wrote: >> On 2010-Oct-20 10:50:38 +0400, KOT MATPOCKuH wrote: >>>> I fixed it with attached patch. >>>Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"))? >> >> Can you explain why you think it should be strncmp() please. > > I'd say that strcmp is perfectly fine because zfs is a 3 character (4 > if you count NUL) string. The comparison logic is dang near the same: It wouldn't be about the length of the string, but whether you want a match on other strings like "zfs2", "zfs_foo", and anything else prefixed with zfs. That's the difference between strcmp and strncmp(... strlen()). Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 22:20: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 88E3E106564A; Wed, 20 Oct 2010 22:20:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 180C38FC12; Wed, 20 Oct 2010 22:20:39 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4A3A841C710; Thu, 21 Oct 2010 00:20:37 +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 QUYLdw37ZSmB; Thu, 21 Oct 2010 00:20:36 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 88AB341C71D; Thu, 21 Oct 2010 00:20:36 +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 5C1EC44496D; Wed, 20 Oct 2010 22:20:15 +0000 (UTC) Date: Wed, 20 Oct 2010 22:20:15 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jack Vogel In-Reply-To: Message-ID: <20101020221142.L66242@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , FreeBSD Current Subject: Re: IPV6 Checksum offload and TSO6 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, 20 Oct 2010 22:20:39 -0000 On Wed, 20 Oct 2010, Jack Vogel wrote: Hi, > I had occasion to think about this, and I was wondering if someone is > working to add > either or both of these features, Intel's hardware supports it, it does not > seem that > hard to add, or am I missing something? Strange that I had been thinking of that last night and talking to poeple today. It's kind of on the roadmap here for mid-November. It's mostly freebsd infrastructure that's missing for it (along with some cleanup on the flags in a couple of places). tuexen@ wanted to get the CSUM_* stuff done for SCTP as well but I haven't re-pinged him on that one yet. Do you know if we have Intel cards in the netperf cluster that can actually do it for testing? What's the matrix for the various cards for v6 offloads? TCP/UDP/SCTP? IP? TSO? TOE? Imho noone does TOE6 yet (correct me if wrong) but I'd like to get the others all sorted then. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 22:46: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 2952E106566B for ; Wed, 20 Oct 2010 22:46:02 +0000 (UTC) (envelope-from yanegomi@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 A7CB98FC0A for ; Wed, 20 Oct 2010 22:46:01 +0000 (UTC) Received: by wyb38 with SMTP id 38so4423431wyb.13 for ; Wed, 20 Oct 2010 15:46:00 -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=UB/+kMCFQ25lKdgYi+cbQ8rHtogfmth92sCMXuSZYqo=; b=te+fTvKpRX9DLhwpQZCryUWC7OuRaWjJi2EHBPYDP8xG5s+hC3mqA+N4O7838xGzTL TCgd7u6pSj6cC+K21845LNYQc4Da4bJLbEugKrSk4Lvgqv9bhsI9q8VJLcs+VVvP3awd nYYe7fwSPSbiqp0Ra9pSuUnyPQ8+vib7BO6ro= 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=SxMBU8yXjgTpQHd0YFg2yVOyVlxEqKmPQ5zieyONDJltpsR8pA4PHfqnVafoK7k7VZ /r41FrdnBZKmghEBYWAHGlaMuCM+OvJOOkfWOoDThwZOU9KB3mGVI0VzykwJEmWtce2g WJVAHbmaY6BkW1PgQldEKAUNe7hUfjDyB6qQA= MIME-Version: 1.0 Received: by 10.216.26.194 with SMTP id c44mr10135wea.104.1287614760108; Wed, 20 Oct 2010 15:46:00 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.135.67 with HTTP; Wed, 20 Oct 2010 15:46:00 -0700 (PDT) In-Reply-To: References: <4CBCDD3A.9070404@delphij.net> <4CBD26B4.2020205@yandex.ru> <4CBDB17C.4040607@yandex.ru> <20101020194547.GA94244@server.vk2pj.dyndns.org> Date: Wed, 20 Oct 2010 15:46:00 -0700 X-Google-Sender-Auth: DqfFLDdn9Mfo-Leps6qzmkmZD7c Message-ID: From: Garrett Cooper To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: KOT MATPOCKuH , FreeBSD Current , Peter Jeremy Subject: Re: [zfs] Mounting from (...) failed with error 19 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, 20 Oct 2010 22:46:02 -0000 On Wed, Oct 20, 2010 at 3:18 PM, Matthew Fleming wrote: > On Wed, Oct 20, 2010 at 1:39 PM, Garrett Cooper wro= te: >> On Wed, Oct 20, 2010 at 12:45 PM, Peter Jeremy wro= te: >>> On 2010-Oct-20 10:50:38 +0400, KOT MATPOCKuH wrot= e: >>>>> I fixed it with attached patch. >>>>Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs= "))? >>> >>> Can you explain why you think it should be strncmp() please. >> >> I'd say that strcmp is perfectly fine because zfs is a 3 character (4 >> if you count NUL) string. The comparison logic is dang near the same: > > It wouldn't be about the length of the string, but whether you want a > match on other strings like "zfs2", "zfs_foo", and anything else > prefixed with zfs. =A0That's the difference between strcmp and > strncmp(... strlen()). Well, yeah... the because using the above strategy would introduce parsing bugs as you so elegantly put it :). -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 22:49: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 6E32D106566C for ; Wed, 20 Oct 2010 22:49:49 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 28DFD8FC0C for ; Wed, 20 Oct 2010 22:49:48 +0000 (UTC) Received: by ywh2 with SMTP id 2so2431328ywh.13 for ; Wed, 20 Oct 2010 15:49:48 -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=C3qYplApP5KT4j7wEZgw9m6pUo30914GT0kC7OBmKKc=; b=Eo889Ct/z4mLV4xKplNcC1bFNPMtLPz/VR/tG3Qrbk6UMUZQYJ1ME/52glY9shPivA bc3QGTChSIhsPZXfhbzQMVhTiRRM57ET1fG4qxpzePzkS/0qvVeOzxx6ElQqIXOZStc3 Aurr95cHg0I29G7tpps/wR3PENkTsf03QMrxw= 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=w/Mk5m83IpQhCSaF6fzw5zaL27nlM4/3w0H5LLq2Hbrm1zDcmwCjp8zp7MSNRLA5x9 IWRvxcC4+G5yAHSMjhtwb83PrENvFlMhGLoBzabCLvs7fEfVzcQNYvdThtuIlklgUUex eF0EIMlxLL8p1PA7RLZ3IsXPESo+rih5PVMqU= MIME-Version: 1.0 Received: by 10.42.174.194 with SMTP id w2mr1153008icz.368.1287614988215; Wed, 20 Oct 2010 15:49:48 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.166.199 with HTTP; Wed, 20 Oct 2010 15:49:48 -0700 (PDT) Date: Wed, 20 Oct 2010 15:49:48 -0700 X-Google-Sender-Auth: u3z0V1pg7a2SovxvQQqYmfLaJic Message-ID: From: mdf@FreeBSD.org To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Poul-Henning Kamp Subject: kldload of compressed modules 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, 20 Oct 2010 22:49:49 -0000 I'm trying to add support for kldload of compressed modules; they work at boot time but not at runtime. I'm having trouble uncompressing the module in the kernel to try processing it. The difficulty is several-fold: 1) gzip(1) doesn't seem to produce a compressed image that net/zlib.c understands. It gets hung up on the first byte, since it's not 0x8 indicating Z_DEFLATED. I tried setting next_in to the input buffer + 2 since that is the Z_DEFLATED marker, but it dies one byte later with the "incorrect header check" failure. 2) I was using inflate in kern/inflate.c wrong earlier (not skipping the first 10 bytes + comment), but even so that code and the net/zlib code aren't compatible, since they both define an inflate() function that takes differing numbers of arguments, etc. And link_elf.c already can include net/zlib.h when DDB_CTF is set, so that would conflict with sys/inflate.h. It's likely that kern/inflate.c is what I want, since it's the code the boot loader uses, but I'm annoyed that it's only available with device gzip (I can change this, of course) and that it's incompatible with what seems to be the somewhat standard compress/decompress code in net/zlib.c. All of this is on stable/7 at the moment, though if I had something that worked I want to commit to CURRENT and MFC. So, what's the basic problem? Should net/zlib support this gzipped file? Should I have compressed with some other user-space utility? Should I add a new link_elf_compress.c file to support compressed images (and use sys/inflate.h instead of net/zlib.h) instead of trying to add it to the existing link_elf_load_file() functions? For reference, here's the beginning of the compressed module (on amd64): # od -h mnvf.ko.gz | less 0000000 8b1f 0808 fd2a 4cbe 0300 6e6d 6676 6b2e 0000020 006f 7ded 740f d554 f7b5 484d f842 6613 0000040 0340 4401 182e 2820 0484 1208 3425 4ca3 0000060 d198 4409 0121 3a51 924c 1909 3249 6663 0000100 0426 1a2a 8c9a 9c65 e6c6 d6d9 fb5a 3cb4 0000120 5adb 9ffa 5fb6 0979 362d 4b58 6b42 a529 0000140 54a8 52ad 72ad a0c7 c546 7f88 6f20 7def 0000160 99ce 73b9 4733 6b7d 7df5 adeb 7d6f b8b3 0000200 7b9c 677e 7d9f def6 9ce7 cf7d 9b9f ef73 0000220 3ab6 52ca 5253 28c6 37fc 594a a4a9 5840 0000240 8b30 4bc5 de39 79ff f625 552b 0396 a95d 0000260 ad92 224c 74da fe45 46fb 6265 28a8 fa66 0000300 f31f c065 97b5 7be3 cd2b 6109 2641 97c3 0000320 2667 4be6 f9e5 6ff6 e862 4dfe 84e6 4d50 0000340 1251 9142 05dd 7d57 f912 c236 06b5 25ae 0000360 d570 b5c2 092a b54d 9e21 d70b 7e22 628f 0000400 80cc 8eab f3c7 bae1 df82 06df 6ad7 6cb8 0000420 2d70 6b86 5c1d c397 45b5 abc7 7742 92bf 0000440 c287 65d4 34ba be61 e15b 90da 4644 0f2b Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 22:52: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 ABEF4106564A; Wed, 20 Oct 2010 22:52:54 +0000 (UTC) (envelope-from jfvogel@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 9AD268FC0A; Wed, 20 Oct 2010 22:52:53 +0000 (UTC) Received: by wwb13 with SMTP id 13so3383134wwb.31 for ; Wed, 20 Oct 2010 15:52:52 -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=5bFxbqWdbnRws+HZ6CJ5lL96Jf+B1c48Vt3pHudMsUM=; b=ksLBefcWIXIsBXuiC1TznLgTj379zNz6Dg7J576bbOx/S7YzxosLPDz1mzW7kPfBwD /YDNJFq/cEVBKzzTYAXujHoRJRlhfL/7yfPZGs8YGF+hJJjHi9zsU0aaInZzcl6JF2aR YH79l2UqJZlQd4PTzK777E2JdmPIPPCBUjNzY= 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=PXCly3g9s0okyHQzoJmupj0vPPFJu5VrSTeirGQGQ8S0IGpNtDt973vanrEU0gNxWQ o2RgK5gFVnqpbVydx5c1ya3ojy1DtkIWiFOLFehAIw7sCdmzv+xIrAR6Ql8pRKNRSMXC kfJt6BVhKFwggrlfwxgC3mpOLqX3pQpug+P5U= MIME-Version: 1.0 Received: by 10.216.6.133 with SMTP id 5mr8845445wen.32.1287615171521; Wed, 20 Oct 2010 15:52:51 -0700 (PDT) Received: by 10.216.232.132 with HTTP; Wed, 20 Oct 2010 15:52:51 -0700 (PDT) In-Reply-To: <20101020221142.L66242@maildrop.int.zabbadoz.net> References: <20101020221142.L66242@maildrop.int.zabbadoz.net> Date: Wed, 20 Oct 2010 15:52:51 -0700 Message-ID: From: Jack Vogel To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , FreeBSD Current Subject: Re: IPV6 Checksum offload and TSO6 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, 20 Oct 2010 22:52:54 -0000 Looked to me like Michael already has the SCTP stuff in the inet6 code. Not sure if it needs further enabling or what?? I'm not positive about what cards are in the netperf cluster. Any card that em, igb, and ixgbe supports can do the TCP/UDP checksum offloads whether in IPv4 or 6 if handed to it. TSO is a TCP segmentation so it also is a matter of IPv6 allowing it to do so, at least that is my present understanding. SCTP offload can only be handled in the igb and ixgbe drivers, none of the em hardware can do it (at least not as of today). Personally its TSO that I care most about, but the protocol checksums might as well be available too. Jack On Wed, Oct 20, 2010 at 3:20 PM, Bjoern A. Zeeb wrote: > On Wed, 20 Oct 2010, Jack Vogel wrote: > > Hi, > > > I had occasion to think about this, and I was wondering if someone is >> working to add >> either or both of these features, Intel's hardware supports it, it does >> not >> seem that >> hard to add, or am I missing something? >> > > Strange that I had been thinking of that last night and talking to > poeple today. It's kind of on the roadmap here for mid-November. > > It's mostly freebsd infrastructure that's missing for it (along with > some cleanup on the flags in a couple of places). tuexen@ wanted to > get the CSUM_* stuff done for SCTP as well but I haven't re-pinged > him on that one yet. > > Do you know if we have Intel cards in the netperf cluster that can > actually do it for testing? What's the matrix for the various cards > for v6 offloads? > TCP/UDP/SCTP? > IP? > TSO? > TOE? > > Imho noone does TOE6 yet (correct me if wrong) but I'd like to get > the others all sorted then. > > /bz > > -- > Bjoern A. Zeeb Welcome a new stage of life. > Going to jail sucks -- All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 23:15:15 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id C25021065697; Wed, 20 Oct 2010 23:15:13 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 20 Oct 2010 19:15:03 -0400 User-Agent: KMail/1.6.2 References: <4C732522.1010400@gmail.com> <4CBF2C6B.4030704@gmail.com> <4CBF57CE.7090504@gmail.com> In-Reply-To: <4CBF57CE.7090504@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010201915.05502.jkim@FreeBSD.org> Cc: Matt Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 20 Oct 2010 23:15:15 -0000 On Wednesday 20 October 2010 04:57 pm, Matt wrote: > On 10/20/10 10:52, Matt wrote: > > On 10/20/10 10:37, Matt wrote: > >>> On Wed, 20 Oct 2010, Jung-uk Kim wrote: > >>>> On Tuesday 19 October 2010 09:15 pm, Matt wrote: > >>>>> My experience with a sleeping freebsd laptop has been > >>>>> shortlived! > >>>>> > >>>>> Today I rebuilt world using clang & this morning's csup > >>>>> current. Clang build went just swimmingly. > >>>>> > >>>>> Unthinkingly, I closed my laptop lid and put it in my case. > >>>>> When I got to my house, it was roasting with fans spinning > >>>>> and sleep light flashing. No damage, thankfully. > >>>>> > >>>>> Low and behold, hw.pci.do_power_resume=0 no longer lets my > >>>>> laptop sleep! > >>>>> > >>>>> I had recently fiddled with powerd, but problem persisted > >>>>> after reverting to previous configuration of associated > >>>>> sysctls etc. > >>>>> > >>>>> Interestingly, sleep bounce now fails with a hard freeze, > >>>>> which it never has in the past. > >>>>> > >>>>> Verbose output shows the wifi then re0 network interfaces > >>>>> going from D0->D3 as last living output. > >>>>> > >>>>> Please note problem persists regardless of user, X running, > >>>>> sleep_delay sysctl, do_power_resume, do_power_nodriver, > >>>>> powerd running/not running. > >>>>> > >>>>> Without sleep bounce, problem is characterized by flashing > >>>>> sleep light and spinning fans (CPU temperature is high). > >>>>> > >>>>> No devices added or removed, was sleeping this morning before > >>>>> buildworld. Is it worth rebuilding with gcc? Or a content > >>>>> change and not a compiler issue? Any major pci changes lately > >>>>> maybe? > >>>> > >>>> Can you please update source and try again? If it does not > >>>> work, please set a new tunable "hw.pci.do_power_suspend=0" and > >>>> tell me whether it helps or not. FYI, hw.pci.do_power_resume > >>>> does not apply to suspend any more. So, if you want to > >>>> restore the previous behaviour, you need both > >>>> "hw.pci.do_power_resume=0" and "hw.pci.do_power_suspend=0". > >>>> However, my hunch tells me that you only need the latter. > >>>> > >>>> Also, if possible, I'd like to see 'devinfo -rv', 'pciconf > >>>> -clv', 'acpidump -dt', and 'lspci -vvv' output. Note lspci is > >>>> available via ports/sysutils/pciutils. > >>>> > >>>> Thanks, > >>>> > >>>> Jung-uk Kim > >>>> _______________________________________________ > >>>> 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 >> dump file of the above commands in order: > >> http://pastebin.com/KhFn9xaK > >> > >> I'm grabbing a new csup now, glad it wasn't clang at least. When > >> I did Mac development, LLVM binaries were generally > >> significantly faster for some things. > >> > >> Interesting, I got some phone related topic added into your > >> post, and no direct mail, so hopefully you can get your hands on > >> the pastebin link. > >> > >> Thank you, I will let you know if the new tunable does the > >> trick. > >> > >> Matt > > > > Build fails. I will also try gcc, but it seems like it doesn't > > know about do_power_suspend yet! > > > > > > cd /usr/obj/usr/src/sys/ONOSENDAI; MAKEOBJDIRPREFIX=/usr/obj > > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=nocona > > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD > > 9.0-CURRENT amd64 900023" INSTALL="sh /usr/src/tools/install.sh" > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/le > >gacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/sr > >c/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/u > >sr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel all > > -DNO_MODULES_OBJ > > clang -c -O2 -fno-strict-aliasing -pipe -march=nocona -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/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h > > -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone > > -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow > > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > > -fstack-protector /usr/src/sys/dev/pci/pci_pci.c clang: > > warning: argument unused during compilation: '-mfpmath=387' > > /usr/src/sys/dev/pci/pci_pci.c:450:20: error: use of undeclared > > identifier > > 'pci_do_power_suspend'; did you mean 'pci_do_power_resume'? > > if (error == 0 && pci_do_power_suspend) { > > ^~~~~~~~~~~~~~~~~~~~ > > pci_do_power_resume > > In file included from /usr/src/sys/dev/pci/pci_pci.c:51: > > /usr/src/sys/dev/pci/pci_private.h:41:13: note: > > 'pci_do_power_resume' declared > > here > > extern int pci_do_power_resume; > > ^ > > 1 error generated. > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/ONOSENDAI. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > Matt > > Commented out code at as though "pci_do_power_suspend" = false, > still does not sleep. > > Tried setting do_power_resume to 1 and 0, same result. > > debug.acpi.suspend_bounce returns to VT and freezes, nothing logged > (was not verbose booted at the time however). I am quite surprised it didn't work for you. Can you please csup again and make sure you have the latest source? Have you ever set debug.acpi.do_powerstate tunable before? Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Oct 21 04:21: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 BD0F8106566C for ; Thu, 21 Oct 2010 04:21:04 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70F788FC0A for ; Thu, 21 Oct 2010 04:21:04 +0000 (UTC) Received: by gyd8 with SMTP id 8so1235129gyd.13 for ; Wed, 20 Oct 2010 21:21:03 -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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XSugUmjjHT8i73BbfiyvuZP9Ku51AW3hKxAdmaZqswY=; b=T1hXhJmjVUqD7ZUWg45uAzC0rwpKo0FRgYtVLtOl1zNfUdNRzLCCVZK4OTUosHSJCk h+SMONta5+wXozfZ+vL7ONfAWHemR8vVX4oRZf8n9saU/Qve0dDNrj/EumefC+uTMLJG PZHispuXJS3qWBw5E9DT7pZEE4hyRdtXd62zQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kfQTpUETQhK5GJAIF/EmMCc2KIWX06b3augzSAwIBBEMcnPyC6HHC83pkSULCXHBR1 ULixqikzdPjCY/4u+pTXrOt+6ucrVR7fZK3aDKzvH0nqq7/1o8AqBpgsFwkaSZ9tYIS2 2tmrSo/4WrFBfuHVrQ+THjnbjRpLOxXE6diUo= Received: by 10.150.206.6 with SMTP id d6mr2883996ybg.39.1287634863483; Wed, 20 Oct 2010 21:21:03 -0700 (PDT) Received: from ono-sendai.local ([75.111.34.169]) by mx.google.com with ESMTPS id t4sm7593804ybe.1.2010.10.20.21.20.52 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 21:21:02 -0700 (PDT) Message-ID: <4CBFBF93.204@gmail.com> Date: Wed, 20 Oct 2010 21:20:35 -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: Jung-uk Kim References: <4C732522.1010400@gmail.com> <4CBF28D8.3090207@gmail.com> <4CBF2C6B.4030704@gmail.com> <201010201446.26383.jkim@FreeBSD.org> In-Reply-To: <201010201446.26383.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Sleep/Lenovo SL410 fails again after csup & clang 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, 21 Oct 2010 04:21:04 -0000 On 10/20/10 11:46, Jung-uk Kim wrote: > On Wednesday 20 October 2010 01:52 pm, Matt wrote: >> On 10/20/10 10:37, Matt wrote: >>>> On Wed, 20 Oct 2010, Jung-uk Kim wrote: >>>>> On Tuesday 19 October 2010 09:15 pm, Matt wrote: >>>>>> My experience with a sleeping freebsd laptop has been >>>>>> shortlived! >>>>>> >>>>>> Today I rebuilt world using clang& this morning's csup >>>>>> current. Clang build went just swimmingly. >>>>>> >>>>>> Unthinkingly, I closed my laptop lid and put it in my case. >>>>>> When I got to my house, it was roasting with fans spinning and >>>>>> sleep light flashing. No damage, thankfully. >>>>>> >>>>>> Low and behold, hw.pci.do_power_resume=0 no longer lets my >>>>>> laptop sleep! >>>>>> >>>>>> I had recently fiddled with powerd, but problem persisted >>>>>> after reverting to previous configuration of associated >>>>>> sysctls etc. >>>>>> >>>>>> Interestingly, sleep bounce now fails with a hard freeze, >>>>>> which it never has in the past. >>>>>> >>>>>> Verbose output shows the wifi then re0 network interfaces >>>>>> going from D0->D3 as last living output. >>>>>> >>>>>> Please note problem persists regardless of user, X running, >>>>>> sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd >>>>>> running/not running. >>>>>> >>>>>> Without sleep bounce, problem is characterized by flashing >>>>>> sleep light and spinning fans (CPU temperature is high). >>>>>> >>>>>> No devices added or removed, was sleeping this morning before >>>>>> buildworld. Is it worth rebuilding with gcc? Or a content >>>>>> change and not a compiler issue? Any major pci changes lately >>>>>> maybe? >>>>> Can you please update source and try again? If it does not >>>>> work, please set a new tunable "hw.pci.do_power_suspend=0" and >>>>> tell me whether it helps or not. FYI, hw.pci.do_power_resume >>>>> does not apply to suspend any more. So, if you want to restore >>>>> the previous behaviour, you need both >>>>> "hw.pci.do_power_resume=0" and "hw.pci.do_power_suspend=0". >>>>> However, my hunch tells me that you only need the latter. >>>>> >>>>> Also, if possible, I'd like to see 'devinfo -rv', 'pciconf >>>>> -clv', 'acpidump -dt', and 'lspci -vvv' output. Note lspci is >>>>> available via ports/sysutils/pciutils. >>>>> >>>>> Thanks, >>>>> >>>>> Jung-uk Kim >>>>> _______________________________________________ >>>>> 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>> dump file of the above commands in order: >>> http://pastebin.com/KhFn9xaK >>> >>> I'm grabbing a new csup now, glad it wasn't clang at least. When >>> I did Mac development, LLVM binaries were generally significantly >>> faster for some things. >>> >>> Interesting, I got some phone related topic added into your post, >>> and no direct mail, so hopefully you can get your hands on the >>> pastebin link. >>> >>> Thank you, I will let you know if the new tunable does the trick. >>> >>> Matt >> Build fails. I will also try gcc, but it seems like it doesn't know >> about do_power_suspend yet! >> >> >> cd /usr/obj/usr/src/sys/ONOSENDAI; MAKEOBJDIRPREFIX=/usr/obj >> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=nocona >> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 9.0-CURRENT >> amd64 900023" INSTALL="sh /usr/src/tools/install.sh" >> PATH=/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:/usr/obj/usr/src/tm >> p/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/gam >> es:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel all >> -DNO_MODULES_OBJ >> clang -c -O2 -fno-strict-aliasing -pipe -march=nocona -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/usr/src/sys >> -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS >> -include opt_global.h -fno-omit-frame-pointer -mcmodel=kernel >> -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx >> -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables >> -ffreestanding -fstack-protector /usr/src/sys/dev/pci/pci_pci.c >> clang: warning: argument unused during compilation: '-mfpmath=387' >> /usr/src/sys/dev/pci/pci_pci.c:450:20: error: use of undeclared >> identifier 'pci_do_power_suspend'; did you mean >> 'pci_do_power_resume'? if (error == 0&& pci_do_power_suspend) { >> ^~~~~~~~~~~~~~~~~~~~ >> pci_do_power_resume >> In file included from /usr/src/sys/dev/pci/pci_pci.c:51: >> /usr/src/sys/dev/pci/pci_private.h:41:13: note: >> 'pci_do_power_resume' declared >> here >> extern int pci_do_power_resume; >> ^ >> 1 error generated. >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/ONOSENDAI. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. > It seems your sys/dev/pci/pci_private.h is out of sync somehow. It > was updated with pci_pci.c in the same commit. Please try csup > again. > > Jung-uk Kim > After current cvsup, SL410 sleeps again (with both hw.pci.do_power_suspend and hw.pci.do_power_resume set to 0). Initial toggling indicated that at least would work, I will experiment more. Thank you all for a quick resolution to the problem! Matt From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 00:56: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 D7E841065674 for ; Fri, 22 Oct 2010 00:56:29 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AEB648FC0A for ; Fri, 22 Oct 2010 00:56:29 +0000 (UTC) Received: by iwn41 with SMTP id 41so238485iwn.13 for ; Thu, 21 Oct 2010 17:56:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.73 with SMTP id w9mr1695994ibw.95.1287708988880; Thu, 21 Oct 2010 17:56:28 -0700 (PDT) Received: by 10.220.176.141 with HTTP; Thu, 21 Oct 2010 17:56:28 -0700 (PDT) X-Originating-IP: [128.95.133.211] Date: Thu, 21 Oct 2010 17:56:28 -0700 Message-ID: From: Rob Farmer To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: "trying to mount root" message in single user mode 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, 22 Oct 2010 00:56:29 -0000 I just updated current from about a week ago to r214187. Now, when I boot, the kernel message has switched to: "Trying to mount root from ufs:/dev/ufs/root [rw]..." Problem is, it always prints [rw], even when booting single user, where [ro] is expected. The issue is only cosmetic - root is still mounted read only in single user, as before. -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 04:45: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 26EF9106564A; Fri, 22 Oct 2010 04:45:02 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 043168FC13; Fri, 22 Oct 2010 04:45:01 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.2.10] (atm.xcllnt.net [70.36.220.6]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LAO000X5D6Z0S70@asmtp029.mac.com>; Thu, 21 Oct 2010 21:45:01 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010210272 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-22_02:2010-10-22, 2010-10-22, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> Date: Thu, 21 Oct 2010 21:44:58 -0700 Message-id: <94486EC3-6BBB-4830-A95B-B3ACAC25B724@mac.com> References: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: multiple problems between r212316 and r212643 on ia64 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, 22 Oct 2010 04:45:02 -0000 On Sep 16, 2010, at 3:57 AM, Anton Shterenlikht wrote: >>> >>> % man ls >>> zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged >>> % man man >>> zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged >>> >>> # cd /etc/mail >>> # make start >>> Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf >>> sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf >>> . >>> # >>> >>> # cd /usr/src >>> # svn up >>> svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence >>> # >>> This is now fixed (revision 214194). >From the commit log: With r169630 I disabled symbol versioning because it broke rtld. With r211706 rtld got broken for ia64 & powerpc64. It was fixed for powerpc64 with r212497. In between, r211749 removed the exports table because the version script handled the exports. But wait, symbol versioning was disabled on ia64. With exports controlled by the version script and symbol versioning disabled, all symbols are exported and too many symbols bind to the definition in rtld. Let's just say that waird things happen. So, enable symbol versioning on ia64 and apply a work-around for the SIGSEGV that triggered r169630 to begin with: when rtld relocates itself, it comes across r_debug_state and for some reason can't find the definition. This causes a failure, relocation aborts and null pointers galore. The work-around is to ignore the missing definition when rtld is relocating itself and keep going. Maybe with the next binutils this will all go away. Maybe not, in which case I still need to figure out why r_debug_state cannot be found. BTW: r_debug_state is in the symbol map -- I don't think any other rtld symbols that rtld references are in the symbol map... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 07:48: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 5DE01106564A for ; Fri, 22 Oct 2010 07:48:21 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17F298FC14 for ; Fri, 22 Oct 2010 07:48:20 +0000 (UTC) Received: by gxk2 with SMTP id 2so381158gxk.13 for ; Fri, 22 Oct 2010 00:48:20 -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=tu8sefeGGcw11AmtfhiNCSZtVxA0u0Cg95Milf/A5Ao=; b=F5LycNaiurivXwtBfAn/x4KqjoQaziy3nY+CXMvvhMBBiKOE5K3mKy/oYToQR0HwfX YNZh9wLf9teq52rapbLro6KTHIXpdTq6ql98/2T2BaZZg+ZWeSg2xfv0CiNB5FnxttIE GZdXAg6hab327R5iJEc2p3ozNRaZhtTAQUKu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lVJT/Yp+ZT25V1Q7sXdgQi3hZsFaMbGt03DxXxzAYh1wzCDqGG5zptFMcvVREGufjf 0HI8arDlijQA7N8wybirAWKpnvQLtgxlWa+ekB+uYWcX7c24E2EhEbo+n56KcH40j0jr BuejO/36fUsS4WJjICKfOtOrZfbuSQuGZjjAQ= MIME-Version: 1.0 Received: by 10.229.14.143 with SMTP id g15mr1870795qca.208.1287733700263; Fri, 22 Oct 2010 00:48:20 -0700 (PDT) Received: by 10.229.248.201 with HTTP; Fri, 22 Oct 2010 00:48:19 -0700 (PDT) Date: Fri, 22 Oct 2010 11:48:19 +0400 Message-ID: From: KOT MATPOCKuH To: FreeBSD Current Content-Type: multipart/mixed; boundary=0015175770bac5000e04932fddb4 Subject: ports/151636: net/isc-dhcp31-server and net/isc-dhcp41-server does not work with VLAN interfaces 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, 22 Oct 2010 07:48:21 -0000 --0015175770bac5000e04932fddb4 Content-Type: text/plain; charset=ISO-8859-1 Hi all! I got another problem with latest kernel: net/isc-dhcp31-server not started on VLAN interface with message: Internet Systems Consortium DHCP Server 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 64 leases to leases file. Unsupported device type 135 for "bge1.48" I tried to update dhcpd to net/isc-dhcp41-server, but without result. I attached a patch for net/isc-dhcp41-server , but not sure is it correct. I think a similar change should solve the problem for net/isc-dhcp31-server... -- MATPOCKuH --0015175770bac5000e04932fddb4 Content-Type: text/plain; charset=US-ASCII; name="isc-dhcp41-server.patch.txt" Content-Disposition: attachment; filename="isc-dhcp41-server.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfkr9x6b0 ZGlmZiAtcnVOIG5ldC9pc2MtZGhjcDQxLXNlcnZlci5vcmlnL2ZpbGVzL3BhdGNoLXNlcnZlcl9f YnBmLmMgbmV0L2lzYy1kaGNwNDEtc2VydmVyL2ZpbGVzL3BhdGNoLXNlcnZlcl9fYnBmLmMKLS0t IG5ldC9pc2MtZGhjcDQxLXNlcnZlci5vcmlnL2ZpbGVzL3BhdGNoLXNlcnZlcl9fYnBmLmMJMTk3 MC0wMS0wMSAwMzowMDowMC4wMDAwMDAwMDAgKzAzMDAKKysrIG5ldC9pc2MtZGhjcDQxLXNlcnZl ci9maWxlcy9wYXRjaC1zZXJ2ZXJfX2JwZi5jCTIwMTAtMTAtMjIgMTA6Mzk6MjIuODg3NTYxNTEy ICswNDAwCkBAIC0wLDAgKzEsMTAgQEAKKy0tLSBjb21tb24vYnBmLmMub3JpZwkyMDEwLTEwLTIy IDEwOjM4OjA2LjYyMzU1OTkzOSArMDQwMAorKysrIGNvbW1vbi9icGYuYwkyMDEwLTEwLTIyIDEw OjM4OjI2LjQzNjU2Mzk4NiArMDQwMAorQEAgLTU3Nyw2ICs1NzcsNyBAQAorIAkgKi8KKyAgICAg ICAgIHN3aXRjaCAoc2EtPnNkbF90eXBlKSB7CisgICAgICAgICAgICAgICAgIGNhc2UgSUZUX0VU SEVSOgorKyAgICAgICAgICAgICAgICBjYXNlIElGVF9MMlZMQU46CisgICAgICAgICAgICAgICAg ICAgICAgICAgaHctPmhsZW4gPSBzYS0+c2RsX2FsZW4gKyAxOworICAgICAgICAgICAgICAgICAg ICAgICAgIGh3LT5oYnVmWzBdID0gSFRZUEVfRVRIRVI7CisgICAgICAgICAgICAgICAgICAgICAg ICAgbWVtY3B5KCZody0+aGJ1ZlsxXSwgTExBRERSKHNhKSwgc2EtPnNkbF9hbGVuKTsK --0015175770bac5000e04932fddb4-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 07:53: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 DF84E106564A for ; Fri, 22 Oct 2010 07:53:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 72B808FC15 for ; Fri, 22 Oct 2010 07:53:02 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9M7qrYg091110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2010 10:52:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9M7qrfL092209; Fri, 22 Oct 2010 10:52:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9M7qrTW092208; Fri, 22 Oct 2010 10:52:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Oct 2010 10:52:53 +0300 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20101022075253.GD2392@deviant.kiev.zoral.com.ua> References: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> <94486EC3-6BBB-4830-A95B-B3ACAC25B724@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0IJx3QbyLjjHpPuQ" Content-Disposition: inline In-Reply-To: <94486EC3-6BBB-4830-A95B-B3ACAC25B724@mac.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: multiple problems between r212316 and r212643 on ia64 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, 22 Oct 2010 07:53:03 -0000 --0IJx3QbyLjjHpPuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2010 at 09:44:58PM -0700, Marcel Moolenaar wrote: >=20 > On Sep 16, 2010, at 3:57 AM, Anton Shterenlikht wrote: > >>>=20 > >>> % man ls > >>> zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged > >>> % man man > >>> zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged > >>>=20 > >>> # cd /etc/mail > >>> # make start > >>> Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.= conf > >>> sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > >>> . > >>> #=20 > >>>=20 > >>> # cd /usr/src > >>> # svn up > >>> svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byt= e sequence > >>> #=20 > >>>=20 >=20 > This is now fixed (revision 214194). >=20 > >From the commit log: >=20 > With r169630 I disabled symbol versioning because it broke rtld. With > r211706 rtld got broken for ia64 & powerpc64. It was fixed for powerpc64 > with r212497. In between, r211749 removed the exports table because the > version script handled the exports. But wait, symbol versioning was > disabled on ia64. Doh. >=20 > With exports controlled by the version script and symbol versioning > disabled, all symbols are exported and too many symbols bind to the > definition in rtld. Let's just say that waird things happen. >=20 > So, enable symbol versioning on ia64 and apply a work-around for the > SIGSEGV that triggered r169630 to begin with: when rtld relocates > itself, it comes across r_debug_state and for some reason can't find the > definition. This causes a failure, relocation aborts and null pointers > galore. The work-around is to ignore the missing definition when rtld > is relocating itself and keep going. >=20 > Maybe with the next binutils this will all go away. Maybe not, in > which case I still need to figure out why r_debug_state cannot be found. >=20 > BTW: r_debug_state is in the symbol map -- I don't think any other rtld > symbols that rtld references are in the symbol map... Thank you for tracking it. I will wait for your merge of the revision to RELENG_8 before synchronizing rtld with HEAD. --0IJx3QbyLjjHpPuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzBQtQACgkQC3+MBN1Mb4hPQQCg7ALj+q0WTmzUSVlrUJeOMjZk vNMAnRPvIZ9b+5PuDmCtVnmAXm1Uwogu =gb1o -----END PGP SIGNATURE----- --0IJx3QbyLjjHpPuQ-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 08:53: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 E0EF0106566B for ; Fri, 22 Oct 2010 08:53:42 +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 347628FC13 for ; Fri, 22 Oct 2010 08:53:41 +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 LAA10291; Fri, 22 Oct 2010 11:53:33 +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 1P9DNV-000CTl-1T; Fri, 22 Oct 2010 11:53:33 +0300 Message-ID: <4CC1510C.2020000@freebsd.org> Date: Fri, 22 Oct 2010 11:53:32 +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: volker@vwsoft.com References: <4CBCCAB8.4090500@vwsoft.com> <4CBD24FA.8040302@icyb.net.ua> In-Reply-To: <4CBD24FA.8040302@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: c 213323 breaks Sony Vaio P11Z w/o acpi 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, 22 Oct 2010 08:53:43 -0000 [ping] on 19/10/2010 07:56 Andriy Gapon said the following: > on 19/10/2010 01:31 volker@vwsoft.com said the following: >> Hi Andriy & list! >> >> Since rev 213323 my Sony Vaio P11Z was unable to boot up. It broke with a divide >> by zero in topo_probe_0x4 at line 289 as cpu_logical is 0. >> >> The cpu is an Intel Atom Z520 (single core). System doesn't boot at all w/ acpi >> enabled. >> >> The following patch made me to boot up again. >> >> Index: i386/i386/mp_machdep.c >> =================================================================== >> --- i386/i386/mp_machdep.c (revision 213936) >> +++ i386/i386/mp_machdep.c (working copy) >> @@ -286,7 +286,7 @@ >> cpu_logical++; >> } >> >> - cpu_cores /= cpu_logical; >> + cpu_cores /= cpu_logical==0?1:cpu_logical; >> hyperthreading_cpus = cpu_logical; >> } >> >> ``mptable -grope -verbose`` gives: >> =============================================================================== >> >> MPTable >> >> looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 >> searching CMOS 'top of mem' @ 0x0009f800 (638K) >> searching default 'top of mem' @ 0x0009fc00 (639K) >> searching BIOS @ 0x000f0000 >> searching extended BIOS @ 0x000e0000 >> groping memory @ 0x00080000 >> groping memory @ 0x00090000 >> >> MP FPS NOT found, >> suggest trying -grope option!!! >> >> so it's not of much help. >> >> relevant part of dmesg looks like: >> >> FreeBSD 9.0-CURRENT #3 r213904:213936M: Sat Oct 16 22:50:53 UTC 2010 >> root@juno.sz.vwsoft.com:/usr/obj/usr/src/sys/JUNO i386 >> CPU: Intel(R) Atom(TM) CPU Z520 @ 1.33GHz (1333.31-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 >> >> Features=0xbfe9fbff >> >> >> Features2=0x40c3bd >> AMD Features=0x100000 >> AMD Features2=0x1 >> TSC: P-state invariant >> real memory = 2147483648 (2048 MB) >> avail memory = 2081042432 (1984 MB) >> >> I'm wondering if there's a better way to fix that problem or if someone wants to >> commit my fix. > > Definitely not - it violates style(9). > Kidding, of course :-) > > Could you please download and run the following script and send back output? > http://people.freebsd.org/~jkim/cpu_topology-12212009.sh > Thank you very much! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 09:09: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 E9B49106564A for ; Fri, 22 Oct 2010 09:09:54 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4458FC0C for ; Fri, 22 Oct 2010 09:09:54 +0000 (UTC) Received: from bel.soho.vwsoft.com (p57A0CB2E.dip.t-dialin.net [87.160.203.46]) by Mail.elbekies.net (Postfix) with ESMTPA id 685BF2E067; Fri, 22 Oct 2010 11:09:51 +0200 (CEST) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id 9313233C7F; Fri, 22 Oct 2010 11:09:26 +0200 (CEST) Message-ID: <4CC154C5.3020500@vwsoft.com> Date: Fri, 22 Oct 2010 11:09:25 +0200 From: volker@vwsoft.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.12) Gecko/20101007 Thunderbird/3.0.8 MIME-Version: 1.0 To: Andriy Gapon References: <4CBCCAB8.4090500@vwsoft.com> <4CBD24FA.8040302@icyb.net.ua> <4CC1510C.2020000@freebsd.org> In-Reply-To: <4CC1510C.2020000@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: 685BF2E067.ABFF6 X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com MailScanner-NULL-Check: 1288343393.13835@GLLY1KLCYLvLeiH0+Vsg9Q Cc: FreeBSD current Subject: Re: c 213323 breaks Sony Vaio P11Z w/o acpi 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, 22 Oct 2010 09:09:55 -0000 On 10/22/10 10:53, Andriy Gapon wrote: > > [ping] Sorry, Andriy! I haven't found the time to hack yesterday. The Intel website doesn't provide the 20091221 tarball anymore (but a more recent one) and I need to lay my hands on the script and the code tarball to get it working. As a result, I hope I can provide a more recent script that should work out of the box. Please stay tuned (I guess I'll find the time to get it working over the upcoming weekend). TIA, Volker PS: I can provide immediate results if someone has a copy of the Intel 20091221 code tarball > > on 19/10/2010 07:56 Andriy Gapon said the following: >> on 19/10/2010 01:31 volker@vwsoft.com said the following: >>> Hi Andriy& list! >>> >>> Since rev 213323 my Sony Vaio P11Z was unable to boot up. It broke with a divide >>> by zero in topo_probe_0x4 at line 289 as cpu_logical is 0. >>> >>> The cpu is an Intel Atom Z520 (single core). System doesn't boot at all w/ acpi >>> enabled. >>> >>> The following patch made me to boot up again. >>> >>> Index: i386/i386/mp_machdep.c >>> =================================================================== >>> --- i386/i386/mp_machdep.c (revision 213936) >>> +++ i386/i386/mp_machdep.c (working copy) >>> @@ -286,7 +286,7 @@ >>> cpu_logical++; >>> } >>> >>> - cpu_cores /= cpu_logical; >>> + cpu_cores /= cpu_logical==0?1:cpu_logical; >>> hyperthreading_cpus = cpu_logical; >>> } >>> >>> ``mptable -grope -verbose`` gives: >>> =============================================================================== >>> >>> MPTable >>> >>> looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 >>> searching CMOS 'top of mem' @ 0x0009f800 (638K) >>> searching default 'top of mem' @ 0x0009fc00 (639K) >>> searching BIOS @ 0x000f0000 >>> searching extended BIOS @ 0x000e0000 >>> groping memory @ 0x00080000 >>> groping memory @ 0x00090000 >>> >>> MP FPS NOT found, >>> suggest trying -grope option!!! >>> >>> so it's not of much help. >>> >>> relevant part of dmesg looks like: >>> >>> FreeBSD 9.0-CURRENT #3 r213904:213936M: Sat Oct 16 22:50:53 UTC 2010 >>> root@juno.sz.vwsoft.com:/usr/obj/usr/src/sys/JUNO i386 >>> CPU: Intel(R) Atom(TM) CPU Z520 @ 1.33GHz (1333.31-MHz 686-class CPU) >>> Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 >>> >>> Features=0xbfe9fbff >>> >>> >>> Features2=0x40c3bd >>> AMD Features=0x100000 >>> AMD Features2=0x1 >>> TSC: P-state invariant >>> real memory = 2147483648 (2048 MB) >>> avail memory = 2081042432 (1984 MB) >>> >>> I'm wondering if there's a better way to fix that problem or if someone wants to >>> commit my fix. >> >> Definitely not - it violates style(9). >> Kidding, of course :-) >> >> Could you please download and run the following script and send back output? >> http://people.freebsd.org/~jkim/cpu_topology-12212009.sh >> Thank you very much! > > From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 09:29:49 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 703C31065718 for ; Fri, 22 Oct 2010 09:29:49 +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 B94148FC19 for ; Fri, 22 Oct 2010 09:29: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 MAA10980; Fri, 22 Oct 2010 12:29:40 +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 1P9DwS-000CX4-5q; Fri, 22 Oct 2010 12:29:40 +0300 Message-ID: <4CC15983.80003@freebsd.org> Date: Fri, 22 Oct 2010 12:29:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: volker@vwsoft.com References: <4CBCCAB8.4090500@vwsoft.com> <4CBD24FA.8040302@icyb.net.ua> <4CC1510C.2020000@freebsd.org> <4CC154C5.3020500@vwsoft.com> In-Reply-To: <4CC154C5.3020500@vwsoft.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: c 213323 breaks Sony Vaio P11Z w/o acpi 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, 22 Oct 2010 09:29:49 -0000 on 22/10/2010 12:09 volker@vwsoft.com said the following: > On 10/22/10 10:53, Andriy Gapon wrote: >> >> [ping] > > Sorry, Andriy! > > I haven't found the time to hack yesterday. The Intel website doesn't provide > the 20091221 tarball anymore (but a more recent one) and I need to lay my hands > on the script and the code tarball to get it working. As a result, I hope I can > provide a more recent script that should work out of the box. > > Please stay tuned (I guess I'll find the time to get it working over the > upcoming weekend). Volker, thanks a lot! Perhaps, meanwhile you can provide a verbose boot dmesg? The problem that you get is quite unexpected. Essentially, that division by zero that you get is a form of an assert and I am planning to put a real KASSERT there. Neither cpu_logical nor cpu_cores should be zero after that loop because they both should be incremented when the iterator is equal to boot CPU ID. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 10:54:25 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 599421065670 for ; Fri, 22 Oct 2010 10:54:25 +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 E7F488FC26 for ; Fri, 22 Oct 2010 10:54:24 +0000 (UTC) Received: by wwb24 with SMTP id 24so683189wwb.31 for ; Fri, 22 Oct 2010 03:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=SKsY9i1Hz+rYc2v65SX6sUZk1NYYYw3+4kt1aCfUvUU=; b=PQ45dZq+Dej/ZrJ/axRgQJ/4Rbc1pv/rOgpEBM2b6nrQPkcysVS02InYKmRPA6Wbqu g8ki0q3Ww0LZGYkzqxXKJH6dZNn6/4MoDDJo14iCCGMGvsCtEgoKCwK3gcoXH9crdf1D 43CeKVSI+fC8wXgfqoxRiq0YooCriukLnqY5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=j7TOfpPuWjv0vo+XeMSA1HrkGWz5GHdDARJLNmQwbfwm99hyGWIk0amyI8vuQBdBli VgIcaSrLR75SvKqYZbqmOPqc9efjjUo+npmo95ONy5KDTIN/xtX7RZXQdWC8hDc9Jh/x WvwKTPFZGdvaB1uScG281/1fRM+h3/sODg6Js= Received: by 10.227.133.134 with SMTP id f6mr2518922wbt.202.1287744863124; Fri, 22 Oct 2010 03:54:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.15.153 with HTTP; Fri, 22 Oct 2010 03:54:02 -0700 (PDT) From: Renato Botelho Date: Fri, 22 Oct 2010 08:54:02 -0200 Message-ID: To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Openoffice doesn't work with kernel+world built with Clang 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, 22 Oct 2010 10:54:25 -0000 I have a 9.0-current (r214167) amd64, kernel and world built with clang and all ports built with gcc, and i cannot start openoffice anymore, it shows splash, start to go up and die. If I reinstall world+kernel built with gcc openoffice works fine. The is a ktrace result available [1], let me know if you need more information or tests. Thanks [1] - http://people.freebsd.org/~garga/ktrace.out -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 12:53: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 2DAE2106566B for ; Fri, 22 Oct 2010 12:53:42 +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 E32858FC18 for ; Fri, 22 Oct 2010 12:53:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:d078:763c:c1b4:ed0d] (unknown [IPv6:2001:7b8:3a7:0:d078:763c:c1b4:ed0d]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 951D55C43; Fri, 22 Oct 2010 14:53:40 +0200 (CEST) Message-ID: <4CC18958.6050104@FreeBSD.org> Date: Fri, 22 Oct 2010 14:53:44 +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.12pre) Gecko/20101016 Lanikai/3.1.6pre MIME-Version: 1.0 To: Renato Botelho References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Openoffice doesn't work with kernel+world built with Clang 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, 22 Oct 2010 12:53:42 -0000 On 2010-10-22 12:54, Renato Botelho wrote: > I have a 9.0-current (r214167) amd64, kernel and world built > with clang and all ports built with gcc, and i cannot start > openoffice anymore, it shows splash, start to go up and die. > > If I reinstall world+kernel built with gcc openoffice works fine. > > The is a ktrace result available [1], let me know if you need > more information or tests. > > Thanks > > [1] - http://people.freebsd.org/~garga/ktrace.out I guess the permissions of that file are still 700? I get "403 - Forbidden". :) From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 13:08: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 AD8DC1065675; Fri, 22 Oct 2010 13:08: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 1DAC48FC1E; Fri, 22 Oct 2010 13:08:57 +0000 (UTC) Received: by wyb42 with SMTP id 42so799859wyb.13 for ; Fri, 22 Oct 2010 06:08:57 -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=hbX/rxWsqTdsB0wPN8fgGrNq6kTtlIJY7GUc0pCZuyI=; b=wDt4wwXHwVyK9pmU2eur97/puxrY4ANGAy3N2QspO4TYnlMYLwkPl+kjv5OmAlJaeU Vue95xOWdZAGraL4V7Y+NkEMzKf7CoGFPn5U8cg4p2FexFJ3joj3+JmDiccn0dpL4sWc GeoupVnMJNtjppx84sycu6g5Z1d8BtObNadNk= 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=fI+YLM/9y36obIjjE6ojlmDNbTGgc5zgIASWcs3rn1eUsvJZltbJVIchNGFUnsR/sP aPGEVYpWntESWTqd7olJoGt5iJ+FyNf5NtuPG6mfipdhtGU+O41zZD9keaXeWKVVX67/ 3Rs+XjkPzvALWevb1VWoxs8gRT0v1+98CXoJQ= Received: by 10.216.35.78 with SMTP id t56mr2548953wea.34.1287752935894; Fri, 22 Oct 2010 06:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.15.153 with HTTP; Fri, 22 Oct 2010 06:08:33 -0700 (PDT) In-Reply-To: <4CC18958.6050104@FreeBSD.org> References: <4CC18958.6050104@FreeBSD.org> From: Renato Botelho Date: Fri, 22 Oct 2010 11:08:33 -0200 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Openoffice doesn't work with kernel+world built with Clang 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, 22 Oct 2010 13:08:58 -0000 On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric wrote: > On 2010-10-22 12:54, Renato Botelho wrote: >> >> I have a 9.0-current (r214167) amd64, kernel and world built >> with clang and all ports built with gcc, and i cannot start >> openoffice anymore, it shows splash, start to go up and die. >> >> If I reinstall world+kernel built with gcc openoffice works fine. >> >> The is a ktrace result available [1], let me know if you need >> more information or tests. >> >> Thanks >> >> [1] - http://people.freebsd.org/~garga/ktrace.out > > I guess the permissions of that file are still 700? =A0I get "403 - > Forbidden". :) Fixed, sorry. --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 13:16: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 4C5A61065674; Fri, 22 Oct 2010 13:16:24 +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 A0AF58FC1A; Fri, 22 Oct 2010 13:16:23 +0000 (UTC) Received: by wwb24 with SMTP id 24so845553wwb.31 for ; Fri, 22 Oct 2010 06:16:22 -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=fvMm9+rDAxC2iyM1GTfbetBUXZFLyebHErIdZLpoxA4=; b=JDF8frYEkk/aPtIHZUeOZs3PfU/S6qtWjuN2xIG/OASytyF+ObeFircgedy5AdonvW ZgcgPldoXkKHKGLLAEBHFAQC9oBuYrNiCxvPkFQf3UXyEpR4CnZfkSP4B4Hzj5cfZUny JSAByn4MPbT5XayI/FKID8S+0bhf7B2WS3BMM= 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=rRQbQjiKlBV23Is0td3pSrtpkM4meAE9GODDaLTz7r5aPOnd8/8srx/uzMMJxhB2He TfBoa1OyJrZzcbsFA4tggZvyaRRKTinIwKn5Fj2FfRLmbJ5OzOOao++aTThw6DnFdQUN YJRx9eye+9+Oq89MrcYd1JnCMRqXJkNs/1+Hc= Received: by 10.216.242.12 with SMTP id h12mr2568812wer.26.1287753381454; Fri, 22 Oct 2010 06:16:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.15.153 with HTTP; Fri, 22 Oct 2010 06:16:01 -0700 (PDT) In-Reply-To: <4CC18958.6050104@FreeBSD.org> References: <4CC18958.6050104@FreeBSD.org> From: Renato Botelho Date: Fri, 22 Oct 2010 11:16:01 -0200 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Openoffice doesn't work with kernel+world built with Clang 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, 22 Oct 2010 13:16:24 -0000 On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric wrote: > On 2010-10-22 12:54, Renato Botelho wrote: >> >> I have a 9.0-current (r214167) amd64, kernel and world built >> with clang and all ports built with gcc, and i cannot start >> openoffice anymore, it shows splash, start to go up and die. >> >> If I reinstall world+kernel built with gcc openoffice works fine. >> >> The is a ktrace result available [1], let me know if you need >> more information or tests. >> >> Thanks >> >> [1] - http://people.freebsd.org/~garga/ktrace.out > > I guess the permissions of that file are still 700? =A0I get "403 - > Forbidden". :) I've added a dumped version to make it easy: http://people.freebsd.org/~garga/ktrace-error.txt.gz --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 13:37: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 172F31065693 for ; Fri, 22 Oct 2010 13:37:06 +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 C5C838FC1C for ; Fri, 22 Oct 2010 13:37:05 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 137C99CB080 for ; Fri, 22 Oct 2010 15:37:03 +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 dP-B7Rn4PzVi for ; Fri, 22 Oct 2010 15:37:02 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 627529CB432 for ; Fri, 22 Oct 2010 15:37:02 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o9MDb2h0023535 for current@freebsd.org; Fri, 22 Oct 2010 15:37:02 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 22 Oct 2010 15:37:02 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20101022133702.GA22912@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [PATCH]: boot2 optimizations to shrink it 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, 22 Oct 2010 13:37:06 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, can you guys review this patch: http://lev.vlakno.cz/~rdivacky/boot2.safe.patch It shrinks boot2 by 52 bytes by: eliminating memcpy() calls buffer shrinking as we are only ever called with argument < 256 for the %u modifier constifying write-only variable Rui Paulo tested this, is this patch ok? May I commit this? thank you, roman --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzBk34ACgkQLVEj6D3CBEz/7ACbBO1YrWsbcHa2C12CBHNPlMbl 9SoAn3/3GPZP+Lr9A/nSRo+UDDCh56bN =PbfE -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 13:46:09 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 DF74F106564A; Fri, 22 Oct 2010 13:46:08 +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 4E8B88FC15; Fri, 22 Oct 2010 13:46:08 +0000 (UTC) Received: by wyb42 with SMTP id 42so835057wyb.13 for ; Fri, 22 Oct 2010 06:46:07 -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=fs0faIMQZHbZ+ROFk0XOwILjHf0fAmF95Ew/sK9GN90=; b=k1k/pE21P753Q9C1pAXTUNiRxFDklFe7pRS1e2AtvpjDdp57TOJ7aoJRxELQfOWw2t 2eDx9GVp7QsiGEpsjEkt4Ii0zrQYsCaamH1Hcn3Nk+WiYd0Pvu8nMQWNaqLZfhJ9gT8J BboqZldFxOTs4h+LprM4Kh1l8guTIDSOq3Zro= 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=Xye6PS/VzWxxXx7JyDb9m7pfsZRo4FrWh3indaCCY732SJpqwsvgw2Jkni5lWt7bh3 DMVU6phXUh8Rz0jSKEV3uHU9WiX6h8KlIgeWV6OA7JxW3jxeT3mD8xmLPZ20QEr6l5ww FbfPTkcnA40uL5DPYRwQ1Dlw3qCUcP+kM6gKE= Received: by 10.227.37.8 with SMTP id v8mr2719615wbd.180.1287755165876; Fri, 22 Oct 2010 06:46:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.15.153 with HTTP; Fri, 22 Oct 2010 06:38:59 -0700 (PDT) In-Reply-To: <4CC18958.6050104@FreeBSD.org> References: <4CC18958.6050104@FreeBSD.org> From: Renato Botelho Date: Fri, 22 Oct 2010 11:38:59 -0200 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Openoffice doesn't work with kernel+world built with Clang 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, 22 Oct 2010 13:46:09 -0000 On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric wrote: > On 2010-10-22 12:54, Renato Botelho wrote: >> >> I have a 9.0-current (r214167) amd64, kernel and world built >> with clang and all ports built with gcc, and i cannot start >> openoffice anymore, it shows splash, start to go up and die. >> >> If I reinstall world+kernel built with gcc openoffice works fine. >> >> The is a ktrace result available [1], let me know if you need >> more information or tests. >> >> Thanks >> >> [1] - http://people.freebsd.org/~garga/ktrace.out > > I guess the permissions of that file are still 700? =A0I get "403 - > Forbidden". :) > I ran ktrace -di to collect information of child processes, here is the result: http://people.freebsd.org/~garga/ktrace-error2.txt.gz --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 14:22: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 3C4261065674 for ; Fri, 22 Oct 2010 14:22:27 +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 0E4288FC12 for ; Fri, 22 Oct 2010 14:22:27 +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 A599846B90; Fri, 22 Oct 2010 10:22:26 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86C6F8A009; Fri, 22 Oct 2010 10:22:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 22 Oct 2010 10:10:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010221010.27725.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Oct 2010 10:22:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: KOT MATPOCKuH Subject: Re: ports/151636: net/isc-dhcp31-server and net/isc-dhcp41-server does not work with VLAN interfaces 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, 22 Oct 2010 14:22:27 -0000 On Friday, October 22, 2010 3:48:19 am KOT MATPOCKuH wrote: > Hi all! > > I got another problem with latest kernel: net/isc-dhcp31-server not > started on VLAN interface with message: > Internet Systems Consortium DHCP Server 4.1.1-P1 > Copyright 2004-2010 Internet Systems Consortium. > All rights reserved. > For info, please visit https://www.isc.org/software/dhcp/ > Wrote 0 deleted host decls to leases file. > Wrote 0 new dynamic host decls to leases file. > Wrote 64 leases to leases file. > Unsupported device type 135 for "bge1.48" > > I tried to update dhcpd to net/isc-dhcp41-server, but without result. > > I attached a patch for net/isc-dhcp41-server , but not sure is it correct. > I think a similar change should solve the problem for net/isc-dhcp31- server... Yes, this should fix it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 14:22: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 828F21065670; Fri, 22 Oct 2010 14:22:30 +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 525758FC0C; Fri, 22 Oct 2010 14:22:30 +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 EE5E146B91; Fri, 22 Oct 2010 10:22:29 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C07948A01D; Fri, 22 Oct 2010 10:22:27 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 22 Oct 2010 10:18:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101022133702.GA22912@freebsd.org> In-Reply-To: <20101022133702.GA22912@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010221018.52671.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Oct 2010 10:22:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Roman Divacky Subject: Re: [PATCH]: boot2 optimizations to shrink it 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, 22 Oct 2010 14:22:30 -0000 On Friday, October 22, 2010 9:37:02 am Roman Divacky wrote: > Hi, > > can you guys review this patch: > > http://lev.vlakno.cz/~rdivacky/boot2.safe.patch > > It shrinks boot2 by 52 bytes by: > > eliminating memcpy() calls > > buffer shrinking as we are only ever called with argument > < 256 for the %u modifier > > constifying write-only variable > > Rui Paulo tested this, is this patch ok? May I commit this? @@ -348,7 +348,7 @@ return; p += hdr.ex.a_data + roundup2(hdr.ex.a_bss, PAGE_SIZE); bootinfo.bi_symtab = VTOP(p); - memcpy(p, &hdr.ex.a_syms, sizeof(hdr.ex.a_syms)); + *p = hdr.ex.a_syms; p += sizeof(hdr.ex.a_syms); if (hdr.ex.a_syms) { if (xfsread(ino, p, hdr.ex.a_syms)) @@ -385,7 +385,7 @@ if (xfsread(ino, &es, sizeof(es))) return; for (i = 0; i < 2; i++) { - memcpy(p, &es[i].sh_size, sizeof(es[i].sh_size)); + *p = es[i].sh_size; p += sizeof(es[i].sh_size); fs_off = es[i].sh_offset; if (xfsread(ino, p, es[i].sh_size)) These are ok. @@ -567,7 +567,7 @@ printf(const char *fmt,...) { va_list ap; - char buf[10]; + char buf[4]; /* we are only passed values < 256 */ char *s; unsigned u; int c; This may not always be true in the future. I know I've printed out LBAs before for debugging issues with zfsboot. I'd really rather not make this change if at all possible. @@ -612,10 +612,10 @@ static int drvread(void *buf, unsigned lba, unsigned nblk) { - static unsigned c = 0x2d5c7c2f; + static const unsigned c = 0x2d5c7c2f; if (!OPT_CHECK(RBX_QUIET)) - printf("%c\b", c = c << 8 | c >> 24); + printf("%c\b", c << 8 | c >> 24); v86.ctl = V86_ADDR | V86_CALLF | V86_FLAGS; v86.addr = XREADORG; /* call to xread in boot1 */ v86.es = VTOPSEG(buf); This breaks the twiddle. With this change it will only ever print the second character in the twiddle set rather than rotating them. Perhaps you could use an rol instruction for this instead? Something like: if (!OPT_CHECK(RBX_QUIET)) { __asm ("rol %0,$8" : "=m" (&c)); printf("%c\b", c); } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 14:30:25 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 63389106566B; Fri, 22 Oct 2010 14:30:25 +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 C86408FC17; Fri, 22 Oct 2010 14:30:24 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 248532A28CCB; Fri, 22 Oct 2010 16:30:24 +0200 (CEST) Date: Fri, 22 Oct 2010 16:30:24 +0200 From: Ed Schouten To: current@freebsd.org, hackers@freebsd.org Message-ID: <20101022143024.GA94137@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt 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, 22 Oct 2010 14:30:25 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, At EuroBSDCon I was talking with some committers active in the area of Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed implementation called libcompiler_rt. See: http://compiler-rt.llvm.org/ Right now it is already complete enough to replace libgcc.a and libgcc_p.a (mostly math rountines), but it doesn't yet implement the functionality (e.g. unwinder) to replace libgcc_eh.a, libgcc_eh_p.a and libgcc_s.so.1. I've created a branch in Subversion which replaces libgcc.a and libgcc_p.a with libcompiler_rt.a and libcompiler_rt_p.a and symlinks it to the original names. It seems to survive a `make universe' and it works properly on at least amd64. Right now the only issue I can think of, is that __clear_cache() is broken on ARM, but that can be fixed trivially. My plan would be to commit this work to HEAD by the end of November (1 month from now), but it would be nice if it could get some more testing in the mean time, especially on non-x86 architectures. How to test this: - Check out the branch from SVN: svn co svn://svn.freebsd.org/base/user/ed/compiler-rt/ - Rebuild and reinstall world (and kernel). - Rebuild all your software (yes, I know it's unfortunate). - See whether software crashes or misbehaves, while it didn't do that previously. In the mean time, I'll see if I can get the Ports folks to run an exp-run with this branch, which should already give some coverage. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzBoAAACgkQ52SDGA2eCwWDaACfb/TwZQ9h9UqkuZJ1Lz2WtFp2 HSUAn3P9xtDvcdPbN81gBTfMjhWzswuE =2A+f -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 14:33: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 E4F071065670; Fri, 22 Oct 2010 14:33:11 +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 A878E8FC08; Fri, 22 Oct 2010 14:33:11 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 0D8102A28CCB; Fri, 22 Oct 2010 16:33:11 +0200 (CEST) Date: Fri, 22 Oct 2010 16:33:11 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Hackers Message-ID: <20101022143311.GB94137@hoeg.nl> References: <20101022143024.GA94137@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <20101022143024.GA94137@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt 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, 22 Oct 2010 14:33:12 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten , 20101022 16:30: > - Rebuild all your software (yes, I know it's unfortunate). Right after I sent this, I thought I'd better clarify this. You don't need to rebuild your software. This change will not break the existing ABI. This step is just mentioned here, since libgcc.a is statically linked into applications. Simply rebuilding and reinstall world is not sufficient to make 3rd party applications use this. --=20 Ed Schouten WWW: http://80386.nl/ --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzBoKcACgkQ52SDGA2eCwWvuwCff0LX4ot9srkQoQA+zSdw5BXa SKQAnj9GZTlhAVQYewy3dKOBgbihCs+o =023B -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 14:37: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 168821065672; Fri, 22 Oct 2010 14:37:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id ED84F8FC13; Fri, 22 Oct 2010 14:37:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.2.10] (atm.xcllnt.net [70.36.220.6]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LAP00FI94L5FA30@asmtp030.mac.com>; Fri, 22 Oct 2010 07:36:42 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010220088 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-22_06:2010-10-22, 2010-10-22, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <20101022075253.GD2392@deviant.kiev.zoral.com.ua> Date: Fri, 22 Oct 2010 07:36:40 -0700 Message-id: References: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> <94486EC3-6BBB-4830-A95B-B3ACAC25B724@mac.com> <20101022075253.GD2392@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: multiple problems between r212316 and r212643 on ia64 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, 22 Oct 2010 14:37:09 -0000 On Oct 22, 2010, at 12:52 AM, Kostik Belousov wrote: > > Thank you for tracking it. I will wait for your merge of the revision > to RELENG_8 before synchronizing rtld with HEAD. Ok. I'll try to MFC over the weekend. If you find yourself waiting for me too long (in case I didn't do it over the weekend), feel free to grab the revision and commit it to -stable. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 15:40: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 7D8FD106564A; Fri, 22 Oct 2010 15:40:02 +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 D97C98FC12; Fri, 22 Oct 2010 15:40:01 +0000 (UTC) Received: by wwb24 with SMTP id 24so981145wwb.31 for ; Fri, 22 Oct 2010 08:40:00 -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=gzZhVizIQ9RBFoH95Y28zUOEWF6V3MmnuVExRnANGP0=; b=FYKF7Y2ZYT/UDx8a4JiGDIgo7LN5rc569N161J16twed4F8ZG5xiwPKaS4Emv/2A3X 6FY3v6FpLLIvjGsZ/tg2pSOpf+uejROZ7XVUOcGQ9v7/RcyfEhI1xPkamw3OOVTYtDmm ubuw8gRdhgaE4Z5xkkc+oE7ir0+igquW+KzgY= 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=LPaGrJ2WsMWbPPDUo7uRry2uEZ4Zt0m3XYrP8/oWcZf/irsgxo6vfSnYlzZhpmwOc3 wUPWiIH3xuk20Vi9QENyrKeE5mOP+fPvGwOyxm1X/ysE1Z5raPLF7O5NGSi22jfsZyY5 orOs3GjBf8DmH4eLst5QMzDqPESR8P0kULyrg= Received: by 10.216.232.29 with SMTP id m29mr11593498weq.0.1287761971929; Fri, 22 Oct 2010 08:39:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.15.153 with HTTP; Fri, 22 Oct 2010 08:39:11 -0700 (PDT) In-Reply-To: <4CC18958.6050104@FreeBSD.org> References: <4CC18958.6050104@FreeBSD.org> From: Renato Botelho Date: Fri, 22 Oct 2010 13:39:11 -0200 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Openoffice doesn't work with kernel+world built with Clang 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, 22 Oct 2010 15:40:02 -0000 On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric wrote: > On 2010-10-22 12:54, Renato Botelho wrote: >> >> I have a 9.0-current (r214167) amd64, kernel and world built >> with clang and all ports built with gcc, and i cannot start >> openoffice anymore, it shows splash, start to go up and die. >> >> If I reinstall world+kernel built with gcc openoffice works fine. >> >> The is a ktrace result available [1], let me know if you need >> more information or tests. >> >> Thanks >> >> [1] - http://people.freebsd.org/~garga/ktrace.out > > I guess the permissions of that file are still 700? =A0I get "403 - > Forbidden". :) One more information, i found the problem is on libgcc_s.so, after build /usr/src/gnu/lib/libgcc with gcc and install openoffice back to work fine. --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 18:39: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 5CCAF106564A for ; Fri, 22 Oct 2010 18:39:06 +0000 (UTC) (envelope-from behrnetworks@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 E18938FC0C for ; Fri, 22 Oct 2010 18:39:05 +0000 (UTC) Received: by wyb42 with SMTP id 42so1128911wyb.13 for ; Fri, 22 Oct 2010 11:39:04 -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=QVbE/PZYE4qmiF1VkRLHGlaiX7KPV3MzujPj1pCBedU=; b=nrAGmbb72G+ByL/N3PUGt7kk21mXgmXpFe4VSDUMlqNe5ViA7t+7JhDhemvY8z/SGm Lbx1WtS/YMNXLUlwFIOfRUJiN3XhLLcUVgF3zYTzpX3WHn/tV/W6bAV6Ogood0i9jtZ6 szjugZQqB6DgY+OE1/UrRfKbKfdbgG7JT99Wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pBkYkDbM3ZixwXJQmwo4t7xHb0wIZiNueJbpXJj1gs6Fh5wnPRZ+31tfqmQX8XsUuJ W9dw3Ag+reGFnLVIqp4KsYKzdEP1npU8AuA1k55FivPRcBKC0crBD9wcBpujdCOW2KHw CW0Ho2+qmWoAT0Np5Zprq7JJblrdiDL5tZUHQ= MIME-Version: 1.0 Received: by 10.227.135.141 with SMTP id n13mr3157308wbt.146.1287771218464; Fri, 22 Oct 2010 11:13:38 -0700 (PDT) Received: by 10.227.143.205 with HTTP; Fri, 22 Oct 2010 11:13:38 -0700 (PDT) Date: Fri, 22 Oct 2010 14:13:38 -0400 Message-ID: From: Chris To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: DRI build failing 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, 22 Oct 2010 18:39:06 -0000 Hello, Seeing this on an amd64 box when doing a fresh Xorg build: ===> Building for dri-7.6.1,2 gmake[1]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' Making sources for autoconf gmake[2]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' rm -f depend touch depend /usr/local/bin/makedepend -fdepend -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/glapi -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include glcontextmodes.c clientattrib.c compsize.c eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c indirect_init.c indirect_size.c indirect_window_pos.c indirect_texture_compression.c indirect_transpose_matrix.c indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c dri2_glx.c dri2.c \ ../../../src/mesa/main/dispatch.c ../../../src/mesa/glapi/glapi.c ../../../src/mesa/glapi/glapi_getproc.c ../../../src/mesa/glapi/glthread.c ../../../src/mesa/x86-64/glapi_x86-64.S gmake[2]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' gmake[2]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' cc -L/usr/local/lib -I/usr/local/include -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/glapi -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -O2 -pipe -march=native -fno-strict-aliasing -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\" glcontextmodes.c -o glcontextmodes.o glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': glcontextmodes.c:193: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:194: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:196: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:197: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:200: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_get_context_mode_data': glcontextmodes.c:333: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:336: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:339: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:343: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:346: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_create': glcontextmodes.c:418: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:419: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:420: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:421: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:422: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_are_same': glcontextmodes.c:539: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:539: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:540: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:540: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:541: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:541: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:542: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:542: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:543: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c:543: error: '__GLcontextModes' has no member named 'yInverted' gmake[2]: *** [glcontextmodes.o] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' gmake: *** [default] Error 1 *** Error code 1 Stop in /usr/ports/graphics/dri. *** Error code 1 Stop in /usr/ports/x11/xorg. It looks like a boo-boo in the code. This is from a freshly pulled down ports tree from this morning and with "WITHOUT_NOUVEAU=yes" in /etc/make.conf. Is there a patch in the works or do we need to let the Freedesktop folks know? Thanks, Chris From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 18:47: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 8843E106566C for ; Fri, 22 Oct 2010 18:47:09 +0000 (UTC) (envelope-from behrnetworks@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 08E098FC26 for ; Fri, 22 Oct 2010 18:47:08 +0000 (UTC) Received: by wwb24 with SMTP id 24so1155262wwb.31 for ; Fri, 22 Oct 2010 11:47:07 -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=CxYQVC+Y32oSqI5CH6YcOVHfCHHDKcETDyQD65GeXJE=; b=FF6xfiMpc934+5YjDtLOpwatR1MXtDMFqcJmvlDAeFU5kKaJ3NOHy5yVsyyjjcKLDT DmQjOFq6BQeeEaQpzmZNj46lejVpMmwDdAOLcsfYk6b9qSdbzjAaeDUDw7ZiqWStTXdw DuIM9o0IEeVMIsp9l6Q7uf3/Rq6UStxNuNLXE= 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=McGd8A8zCM6eQjgUekH5MnJD3BVYLBfqTkbq/fMvsGWCHPSXM+O30uJfr7y58d8xsi d199KJZHUWG4Iq+W1IxMeliJCO4wSi9mR/YQuWarLXoVMUilAFNJ1dldHa8C/atHjWrc DQEN4WAOtqOazSf/ekFqD2mYOTdPEBcxPTZjs= MIME-Version: 1.0 Received: by 10.227.127.132 with SMTP id g4mr3200722wbs.114.1287771355609; Fri, 22 Oct 2010 11:15:55 -0700 (PDT) Received: by 10.227.143.205 with HTTP; Fri, 22 Oct 2010 11:15:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Oct 2010 14:15:55 -0400 Message-ID: From: Chris To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: DRI build failing 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, 22 Oct 2010 18:47:09 -0000 Sorry, I should have posted this in the ports mailing list and will do so. On Fri, Oct 22, 2010 at 2:13 PM, Chris wrote: > Hello, > > Seeing this on an amd64 box when doing a fresh Xorg build: > > =3D=3D=3D> =A0Building for dri-7.6.1,2 > gmake[1]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src= ' > Making sources for autoconf > gmake[2]: Entering directory > `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' > rm -f depend > touch depend > /usr/local/bin/makedepend -fdepend -I. -I../../../include > -I../../../include/GL/internal -I../../../src/mesa > -I../../../src/mesa/glapi -I/usr/local/include > -I/usr/local/include/drm =A0 -I/usr/local/include =A0 -D_THREAD_SAFE > -I/usr/local/include =A0 glcontextmodes.c clientattrib.c compsize.c > eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c > indirect_init.c indirect_size.c indirect_window_pos.c > indirect_texture_compression.c indirect_transpose_matrix.c > indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c > render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c > glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c > glxhash.c dri2_glx.c dri2.c \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0../../../src/mesa/main/dispatch.c > ../../../src/mesa/glapi/glapi.c > ../../../src/mesa/glapi/glapi_getproc.c > ../../../src/mesa/glapi/glthread.c > ../../../src/mesa/x86-64/glapi_x86-64.S > gmake[2]: Leaving directory > `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' > gmake[2]: Entering directory > `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' > cc -L/usr/local/lib -I/usr/local/include -c -I. -I../../../include > -I../../../include/GL/internal -I../../../src/mesa > -I../../../src/mesa/glapi -I/usr/local/include > -I/usr/local/include/drm =A0 -I/usr/local/include =A0 -D_THREAD_SAFE > -I/usr/local/include =A0 -I/usr/local/include -O2 -pipe -march=3Dnative > -fno-strict-aliasing -Wall -Wmissing-prototypes -std=3Dc99 -ffast-math > -fno-strict-aliasing =A0-fPIC =A0-DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN > -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1 -DIN_DRI_DRIVER > -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING > -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER > -DDEFAULT_DRIVER_DIR=3D\"/usr/local/lib/dri\" glcontextmodes.c -o > glcontextmodes.o > glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': > glcontextmodes.c:193: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:194: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:196: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:197: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:200: error: '__GLcontextModes' has no member named 'yInv= erted' > glcontextmodes.c: In function '_gl_get_context_mode_data': > glcontextmodes.c:333: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:336: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:339: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:343: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:346: error: '__GLcontextModes' has no member named 'yInv= erted' > glcontextmodes.c: In function '_gl_context_modes_create': > glcontextmodes.c:418: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:419: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:420: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:421: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:422: error: '__GLcontextModes' has no member named 'yInv= erted' > glcontextmodes.c: In function '_gl_context_modes_are_same': > glcontextmodes.c:539: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:539: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:540: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:540: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:541: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:541: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:542: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:542: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:543: error: '__GLcontextModes' has no member named 'yInv= erted' > glcontextmodes.c:543: error: '__GLcontextModes' has no member named 'yInv= erted' > gmake[2]: *** [glcontextmodes.o] Error 1 > gmake[2]: Leaving directory > `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' > gmake[1]: *** [subdirs] Error 1 > gmake[1]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' > gmake: *** [default] Error 1 > *** Error code 1 > > Stop in /usr/ports/graphics/dri. > *** Error code 1 > > Stop in /usr/ports/x11/xorg. > > > It looks like a boo-boo in the code. This is from a freshly pulled > down ports tree from this morning and with "WITHOUT_NOUVEAU=3Dyes" in > /etc/make.conf. Is there a patch in the works or do we need to let the > Freedesktop folks know? > > Thanks, > > Chris > From owner-freebsd-current@FreeBSD.ORG Sat Oct 23 13:36:25 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 023171065698; Sat, 23 Oct 2010 13:36:25 +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 8F3598FC17; Sat, 23 Oct 2010 13:36:24 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 8EE1A2A28CCB; Sat, 23 Oct 2010 15:36:23 +0200 (CEST) Date: Sat, 23 Oct 2010 15:36:23 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Hackers Message-ID: <20101023133623.GE94137@hoeg.nl> References: <20101022143024.GA94137@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Lb0e7rgc7IsuDeGj" Content-Disposition: inline In-Reply-To: <20101022143024.GA94137@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt 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, 23 Oct 2010 13:36:25 -0000 --Lb0e7rgc7IsuDeGj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, * Ed Schouten , 20101022 16:30: > At EuroBSDCon I was talking with some committers active in the area of > Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC > 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed > implementation called libcompiler_rt. See: >=20 > http://compiler-rt.llvm.org/ I was talking with Robert Watson about this the other day. The codebase of compiler-rt also contains the libBlocksRuntime.so library, which is fundamental in making Grand Central Dispatch (GCD) work. Because of its small size (12 KB), I think I'll also include it in the import. This means that after the import, libdispatch is the only port needed to make Grand Central Dispatch work on FreeBSD HEAD. --=20 Ed Schouten WWW: http://80386.nl/ --Lb0e7rgc7IsuDeGj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzC5NcACgkQ52SDGA2eCwXYJgCfU5IGoxU9aMOMS/YYTAdQyUhh ypsAnRn4AC+GdZGdOc3qz88wDg7fv1Pe =kjS1 -----END PGP SIGNATURE----- --Lb0e7rgc7IsuDeGj-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 23 20:42: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 114541065672 for ; Sat, 23 Oct 2010 20:42:15 +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 D4D4B8FC16 for ; Sat, 23 Oct 2010 20:42:14 +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 o9NKe2pM050062 for ; Sat, 23 Oct 2010 13:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1287866402; bh=TGH9cRyddzPqar0zUpSAmnI+dNFuE98xkkcYgT5+XAw=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=GoVOP9X4JcyFlBFotFE6b6x8g/ahSAjbfUNbbDjpYcdoBTPwVtx0BvNUC0cWCGP5q U8FdmkP4jWDLDOlV9j4jruamV8XZAFybzLJOiBp03LyyPHxmbcKtJG1cSqvvv7WKWi QgxPJoj1ul1QyOz0BNpDs2LEYRgXW76gPd8q0pdk= From: Sean Bruno To: freebsd-current Content-Type: text/plain; charset="UTF-8" Date: Sat, 23 Oct 2010 13:40:01 -0700 Message-ID: <1287866401.2580.5.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: Small /etc/src.conf 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: Sat, 23 Oct 2010 20:42:15 -0000 Anyone have a src.conf + make.conf that I can steal to build a small installation of BSD? I've been trying to shrink the installation so I can cram an ISO of BSD across the network into a remote installation thing in an HP box. Sean From owner-freebsd-current@FreeBSD.ORG Sat Oct 23 21:21: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 520341065670 for ; Sat, 23 Oct 2010 21:21:43 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05D218FC2B for ; Sat, 23 Oct 2010 21:21:42 +0000 (UTC) Received: by gwaa18 with SMTP id a18so994455gwa.13 for ; Sat, 23 Oct 2010 14:21:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.113.15 with SMTP id q15mr9292986ybm.203.1287868902058; Sat, 23 Oct 2010 14:21:42 -0700 (PDT) Received: by 10.220.202.77 with HTTP; Sat, 23 Oct 2010 14:21:41 -0700 (PDT) X-Originating-IP: [128.95.133.19] In-Reply-To: <1287866401.2580.5.camel@home-yahoo> References: <1287866401.2580.5.camel@home-yahoo> Date: Sat, 23 Oct 2010 14:21:41 -0700 Message-ID: From: Rob Farmer To: sbruno@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Small /etc/src.conf 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, 23 Oct 2010 21:21:43 -0000 On Sat, Oct 23, 2010 at 13:40, Sean Bruno wrote: > Anyone have a src.conf + make.conf that I can steal to build a small > installation of BSD? =A0I've been trying to shrink the installation so I > can cram an ISO of BSD across the network into a remote installation > thing in an HP box. Have you checked this: http://phk.freebsd.dk/misc/build_options/ I'm not sure exactly what you're looking for, but in my experience (I care more about build time than size though, and still want a fairly functional system) these are the most important variables to set: NO_MODULES (stick everything in the kernel - tons of stuff is built twice, like ufs support) WITHOUT_PROFILE WITHOUT_LIB32 WITHOUT_CLANG WITHOUT_KERBEROS WITHOUT_CDDL Some of the options involving src/share like WITHOUT_LOCALES seem to kill a lot of files too. Everything else either just skips a couple files (of course, that can add up) or starts to cut into basic functionality (like no man pages), IMHO. --=20 Rob Farmer From owner-freebsd-current@FreeBSD.ORG Sat Oct 23 22:03: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 7C95C106566B; Sat, 23 Oct 2010 22:03:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE4B8FC18; Sat, 23 Oct 2010 22:03:53 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 3C296E7F63; Sat, 23 Oct 2010 23:03:52 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sat, 23 Oct 2010 23:03:51 +0100 (BST) Date: Sat, 23 Oct 2010 23:03:48 +0100 From: Bruce Cran To: sbruno@freebsd.org Message-ID: <20101023230348.00004aa3@unknown> In-Reply-To: <1287866401.2580.5.camel@home-yahoo> References: <1287866401.2580.5.camel@home-yahoo> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current , seanbru@yahoo-inc.com Subject: Re: Small /etc/src.conf 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, 23 Oct 2010 22:03:53 -0000 On Sat, 23 Oct 2010 13:40:01 -0700 Sean Bruno wrote: > Anyone have a src.conf + make.conf that I can steal to build a small > installation of BSD? I've been trying to shrink the installation so I > can cram an ISO of BSD across the network into a remote installation > thing in an HP box. The following might be useful on a small system to speed up build times and reduce the ISO size on a UFS only system where IPFW is used for firewalling: In /etc/src.conf: MODULES_OVERRIDE=md ipfw libalias WITHOUT_GPIB=yes WITHOUT_INFO=yes WITHOUT_ATM=yes WITHOUT_BLUETOOTH=yes WITHOUT_GAMES=yes WITHOUT_IPFILTER=yes WITHOUT_IPX=yes WITHOUT_NCP=yes WITHOUT_NDIS=yes WITHOUT_PF=yes WITHOUT_PPP=yes WITHOUT_PROFILE=yes WITHOUT_WIRELESS=yes # No wireless cards WITHOUT_WPA_SUPPLICANT_EAPOL=yes WITHOUT_ZFS=yes # UFS only system In make.conf you might want to set WITH_X11/WITHOUT_X11 so that for example editors/vim doesn't pull in X11. I also set DISTDIR and WRKDIRPREFIX to directories under my homedir so I can build ports as an unprivileged user. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Oct 23 22:35:37 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 8FB07106566B for ; Sat, 23 Oct 2010 22:35:37 +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 75C8B8FC08 for ; Sat, 23 Oct 2010 22:35:37 +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 o9NMZNmg066427 for ; Sat, 23 Oct 2010 15:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1287873323; bh=TLiVj1khIEibO3v5h005JxKtqvsU7zk5T89qweEVKjY=; h=Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=xetRSyUmqPJah2PF2qdTyp9Pg8seEyod6rcghfIDamlZMTcw4MvILjyaFLGNiqONF 7h/FP6jMfQp1aSUzMqWxhDgW0b/Dp3jmIXorJiTvLYTx3ipTqoGuQV0NNsBIhPc3J1 vXvul0Of1kI7QYU/6uMMQwaPcGEUWausWy0TxSX4= From: Sean Bruno To: freebsd-current In-Reply-To: References: <1287866401.2580.5.camel@home-yahoo> Content-Type: text/plain; charset="UTF-8" Date: Sat, 23 Oct 2010 15:35:22 -0700 Message-ID: <1287873322.2580.16.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: Re: Small /etc/src.conf 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: Sat, 23 Oct 2010 22:35:37 -0000 On Sat, 2010-10-23 at 14:21 -0700, Rob Farmer wrote: > On Sat, Oct 23, 2010 at 13:40, Sean Bruno wrote: > > Anyone have a src.conf + make.conf that I can steal to build a small > > installation of BSD? I've been trying to shrink the installation so I > > can cram an ISO of BSD across the network into a remote installation > > thing in an HP box. > > Have you checked this: > http://phk.freebsd.dk/misc/build_options/ > > I'm not sure exactly what you're looking for, but in my experience (I > care more about build time than size though, and still want a fairly > functional system) these are the most important variables to set: > > NO_MODULES (stick everything in the kernel - tons of stuff is built > twice, like ufs support) > WITHOUT_PROFILE > WITHOUT_LIB32 > WITHOUT_CLANG > WITHOUT_KERBEROS > WITHOUT_CDDL > > Some of the options involving src/share like WITHOUT_LOCALES seem to > kill a lot of files too. > > Everything else either just skips a couple files (of course, that can > add up) or starts to cut into basic functionality (like no man pages), > IMHO. > Thanks for the clue, I've come up with some stuff now that got me down to ~100MB, but I think I can go smaller. src.conf: WITHOUT_AMD=true WITHOUT_APM=true WITHOUT_BIND=true WITHOUT_BSNMP=true WITHOUT_BSD_CPIO=true WITHOUT_BZIP2=true WITHOUT_BLUETOOTH=tree WITHOUT_CDDL=true WITHOUT_CLANG=true WITHOUT_CPP=true WITHOUT_CRYPT=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_CXX=true WITHOUT_DICT=true WITHOUT_EXAMPLES=true WITHOUT_FREEBSD_UPDATE=true WITHOUT_GAMES=true WITHOUT_GDB=true WITHOUT_GNU=true WITHOUT_GPIB=true WITHOUT_GROFF=true WITHOUT_GCOV=true WITHOUT_HTML=true WITHOUT_INET6=true WITHOUT_INFO=true #WITHOUT_INSTALLLIB=true WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_IPX_SUPPORT=true WITHOUT_JAIL=true WITHOUT_LIB32=true WITHOUT_LOCATE=true WITHOUT_LPR=true WITHOUT_MAIL=true WITHOUT_MAN=true WITHOUT_NCP=true WITHOUT_NDIS=true WITHOUT_NETGRAPH=true WITHOUT_NIS=true WITHOUT_NLS=true WITHOUT_NLS_CATALOGS=true WITHOUT_NS_CACHING=true WITHOUT_NTP=true WITHOUT_OBJC=true WITHOUT_PAM=true WITHOUT_PF=true WITHOUT_PORTSNAP=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_RCS=true WITHOUT_RESCUE=true WITHOUT_ROUTED=true WITHOUT_SHAREDOCS=true WITHOUT_SYSINSTALL=true WITHOUT_TCSH=true WITHOUT_TELNET=true WITHOUT_TOOLCHAIN=true WITHOUT_WIRELESS=true make.conf: NO_MODULES=true NO_SHARE=true Then I removed a lot of USB, Wireless, SCSI, RAID and Ethernet adapters from the kernel config. I also yanked the COMPAT options for now. Sean p.s. In order to get NO_CRYPT to work, I had to munge lib/libfetch/common.c Index: /mnt/nfs/fbsd/head/lib/libfetch/common.c =================================================================== --- /mnt/nfs/fbsd/head/lib/libfetch/common.c (revision 214249) +++ /mnt/nfs/fbsd/head/lib/libfetch/common.c (working copy) @@ -321,9 +321,9 @@ int fetch_ssl(conn_t *conn, int verbose) { +#ifdef WITH_SSL int ret, ssl_err; -#ifdef WITH_SSL /* Init the SSL library and context */ if (!SSL_library_init()){ fprintf(stderr, "SSL library init failed\n");