From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 00:29:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31FFC16A40F for ; Sun, 10 Dec 2006 00:29:24 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16B5E43CA1 for ; Sun, 10 Dec 2006 00:28:17 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 7BEFF1CE6F; Sat, 9 Dec 2006 19:29:23 -0500 (EST) Date: Sat, 9 Dec 2006 19:29:23 -0500 From: Adam McDougall To: freebsd-current@freebsd.org Message-ID: <20061210002923.GO81923@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 00:29:24 -0000 src/sys/i386/cpufreq/est.c has many Pentium M cpus but nothing from the Intel Core and Core 2 families that I can see. I tried looking up the values myself, but could not find them in: http://www.intel.com/design/mobile/datashts/314078.htm It seems that even the latest version of the Linux kernel does not list values for at least Yonah (Core 2). Is it a big mystery, or is this data actually available somewhere? I have a Core 2 Duo T7600 in my laptop and est won't touch my cpu because it doesn't recognize it. I did get it to use some other form of speed control by putting hint.acpi_perf.0.disabled="1" in /boot/loader.conf according to another post. Another thing I wish could work is the Enhanced cpu Sleep States; this Dell Latitude D820 laptop only sees C1 although the document above indicates it should probably support 4 unique states. Is there a way I can debug and/or fix this? I can post dumps of the acpi stuff and/or verbose boot logs if it would be helpful. Thanks From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 00:42:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF85216A492 for ; Sun, 10 Dec 2006 00:42:17 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [213.154.244.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CDE643C9E for ; Sun, 10 Dec 2006 00:41:10 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from [192.168.0.3] (kilgore.lan.dim [192.168.0.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id 49C47B80C; Sun, 10 Dec 2006 01:42:15 +0100 (CET) Message-ID: <457B57E5.30705@andric.com> Date: Sun, 10 Dec 2006 01:42:13 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0b1 (Windows/20061208) MIME-Version: 1.0 To: Adam McDougall References: <20061210002923.GO81923@egr.msu.edu> In-Reply-To: <20061210002923.GO81923@egr.msu.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 00:42:18 -0000 Adam McDougall wrote: > src/sys/i386/cpufreq/est.c has many Pentium M cpus but nothing > from the Intel Core and Core 2 families that I can see. I tried > looking up the values myself, but could not find them in: > http://www.intel.com/design/mobile/datashts/314078.htm > > It seems that even the latest version of the Linux kernel does not > list values for at least Yonah (Core 2). Is it a big mystery, or is > this data actually available somewhere? The SpeedStep tables for newer Pentium M and Core models are kept secret by Intel. For some unknown reason, they only want to give out this information to "BIOS writers", probably under some very cumbersome NDA. And then you are at the mercy of those buggy BIOSes' ACPI implementation... I have no idea why it suddenly became so important to hide it, since they used to publish it freely in their older datasheets. If anyone is able to put some pressure on Intel to give out this info again, please do so. > I have a Core 2 Duo > T7600 in my laptop and est won't touch my cpu because it doesn't > recognize it. I did get it to use some other form of speed control > by putting hint.acpi_perf.0.disabled="1" in /boot/loader.conf according > to another post. In OpenBSD, we use a little trick to be able to use at least the lowest and highest power states, so the SpeedStep feature is actually usable, and useful. But still, it would be much nicer to just have the "official" state tables. From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 01:08:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D6EB16A542 for ; Sun, 10 Dec 2006 01:08:25 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E58043C9E for ; Sun, 10 Dec 2006 01:07:17 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 47BC71CE6F; Sat, 9 Dec 2006 20:08:24 -0500 (EST) Date: Sat, 9 Dec 2006 20:08:24 -0500 From: Adam McDougall To: freebsd-current@freebsd.org Message-ID: <20061210010823.GS81923@egr.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CNfT9TXqV7nd4cfk" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Fwd: Re: pf: BAD state happens often with portsnap fetch update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 01:08:25 -0000 --CNfT9TXqV7nd4cfk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Posting to get more exposure, due to the below errors: FreeBSD ice 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #2: Sat Dec 9 16:50:47 EST 2006 root@ice:/usr/obj/usr/src/sys/PE2650 i386 # portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 2 mirrors found. Fetching snapshot tag from portsnap2.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Tue Oct 24 13:57:53 EDT 2006 to Sat Dec 9 18:34:57 EST 2006. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 4 metadata files... done. Fetching 2597 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160....170....180....190....200....210....220....230....240....250....260....270....280....290....300....310....320....330....340....350....360....370....380....390....400....410.... done. Applying patches... done. Fetching 2688 new ports or files... /usr/sbin/portsnap: cannot open 3f115cb168a8e51fd0d19798f005ab7a251a1de6a5b9eda60cd327b60aa48799.gz: No such file or directory snapshot is corrupt. 2597 should have been fetched, but there was a stall at 30.. and after about a minute, it continued on to 410...... and gave up apparently. For all my servers without direct internet access, I have to run portsnap several times until it succeeds. Thanks for any help, and let me know how to help. --CNfT9TXqV7nd4cfk Content-Type: message/rfc822 Content-Disposition: inline Date: Thu, 5 Oct 2006 15:27:25 -0400 From: Adam McDougall To: cperciva@FreeBSD.org Cc: Adam McDougall Subject: Re: pf: BAD state happens often with portsnap fetch update Message-ID: <20061005192725.GN46920@egr.msu.edu> References: <20061005160827.GB46920@egr.msu.edu> <20061005162021.GD21693@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061005162021.GD21693@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.13 (2006-08-11) X-Original-Status: RO On Thu, Oct 05, 2006 at 06:20:21PM +0200, Daniel Hartmeier wrote: On Thu, Oct 05, 2006 at 12:08:27PM -0400, Adam McDougall wrote: > (44.18 is the squid server (trident), 37.163 is the system running portsnap (ice)) > > Oct 5 11:22:03 jolly-fw1 kernel: pf: BAD state: TCP 35.9.44.18:3128 35.9.44.18:3128 35.9.37.163:55357 > [lo=646710754 high=646777361 win=33304 modulator=0 wscale=1] [lo=4033525074 high=4033590770 win=33304 > modulator=0 wscale=1] 9:9 S seq=650709460 ack=4033525074 len=0 ackskew=0 pkts=5:4 dir=in,fwd > Oct 5 11:22:03 jolly-fw1 kernel: pf: State failure on: 1 | 5 The client (37.163) is running out of random high source ports, and starts re-using ports from previous connections, violating 2MSL. pf keeps states of closed connections around for a while (default is 90s), so late packets related to the old connection can be associated with the state. Creating a second, concurrent state entry for the same source/destination address:port quadruple is not possible. You can a) lower pf's tcp.closed timeout, so states of closed connections get purged sooner. b) give the client more random high ports (sysctl net.inet.ip.portrange.*) or add aliases, if the client can make use of them concurrently. c) reduce the connection establishment rate of the client. if portsnap needs one connection for every single file, that's a poor protocol, if you expect a single client to fetch thousands of files in a few seconds. Daniel It seems like portsnap doesn't use client ports sequentially but rather skips many ports at a time, 100 or more, and once it wraps around to the bottom of the range, it tries to reuse an old port. When I test using a simple while script to fetch a file from a local web server through the same proxy, it appears to be almost strictly sequential. Do you have any comment on the local port assignment method or the reuse of ports that ought to be avoided? Thanks. BTW Thanks for writing portsnap, I find it enjoyable to use and beneficial. --CNfT9TXqV7nd4cfk-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 01:28:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA2DA16A40F for ; Sun, 10 Dec 2006 01:28:44 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6608043C9D for ; Sun, 10 Dec 2006 01:27:37 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr6so.prod.shaw.ca (pd3mr6so-qfe3.prod.shaw.ca [10.0.141.21]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JA1007FFANG2JA0@l-daemon> for freebsd-current@freebsd.org; Sat, 09 Dec 2006 18:26:04 -0700 (MST) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd3mr6so.prod.shaw.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JA1006OHANGZFT0@pd3mr6so.prod.shaw.ca> for freebsd-current@freebsd.org; Sat, 09 Dec 2006 18:26:04 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JA100AOAANF67A0@l-daemon> for freebsd-current@freebsd.org; Sat, 09 Dec 2006 18:26:04 -0700 (MST) Received: (qmail 1133 invoked from network); Sun, 10 Dec 2006 01:25:50 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Sun, 10 Dec 2006 01:25:50 +0000 Date: Sat, 09 Dec 2006 17:25:50 -0800 From: Colin Percival In-reply-to: <20061210010823.GS81923@egr.msu.edu> To: Adam McDougall Message-id: <457B621E.3020100@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 References: <20061210010823.GS81923@egr.msu.edu> User-Agent: Thunderbird 1.5.0.8 (X11/20061207) Cc: freebsd-current@freebsd.org Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 01:28:45 -0000 Adam McDougall wrote: > # portsnap fetch update > [...] > Fetching 2688 new ports or files... /usr/sbin/portsnap: cannot open > 3f115cb168a8e51fd0d19798f005ab7a251a1de6a5b9eda60cd327b60aa48799.gz: No such file or > directory > snapshot is corrupt. > > 2597 should have been fetched, but there was a stall at 30.. and after about a minute, > it continued on to 410...... and gave up apparently. For all my servers without > direct internet access, I have to run portsnap several times until it succeeds. You have four options: (a) Lower pf's tcp.closed timeout, (b) Increase the high port range, (c) Fix squid so that it groks HTTP/1.1 properly, or (d) Stop using squid. The problem here is that your proxy is closing portsnap's HTTP connection after each file is downloaded. Colin Percival From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 01:49:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B980616A403; Sun, 10 Dec 2006 01:49:25 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32BA743C9D; Sun, 10 Dec 2006 01:48:18 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 050CF1CE6F; Sat, 9 Dec 2006 20:49:25 -0500 (EST) Date: Sat, 9 Dec 2006 20:49:24 -0500 From: Adam McDougall To: Colin Percival Message-ID: <20061210014924.GU81923@egr.msu.edu> References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457B621E.3020100@freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 01:49:25 -0000 On Sat, Dec 09, 2006 at 05:25:50PM -0800, Colin Percival wrote: Adam McDougall wrote: > # portsnap fetch update > [...] > Fetching 2688 new ports or files... /usr/sbin/portsnap: cannot open > 3f115cb168a8e51fd0d19798f005ab7a251a1de6a5b9eda60cd327b60aa48799.gz: No such file or > directory > snapshot is corrupt. > > 2597 should have been fetched, but there was a stall at 30.. and after about a minute, > it continued on to 410...... and gave up apparently. For all my servers without > direct internet access, I have to run portsnap several times until it succeeds. You have four options: (a) Lower pf's tcp.closed timeout, (b) Increase the high port range, (c) Fix squid so that it groks HTTP/1.1 properly, or (d) Stop using squid. The problem here is that your proxy is closing portsnap's HTTP connection after each file is downloaded. I just tested tcp.closed with 3 seconds, down from 15 earlier but both were unsuccessful. I will look at the other options as well, but do you have any explanation for why portsnap would use wildly randomish local ports that overlap too quickly when fetch does not? Is that a kernel controlled behavior that I can adjust? 65535-49152=16383 (unless I am looking at the wrong sysctl for the default values) and I would think there are many less connections involved for 2597 fetches than 16363. If 16363 isn't enough ports for 2597 fetches then it seems like a crapshoot to try doubling or tripling the range. From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 02:28:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C7EF16A403 for ; Sun, 10 Dec 2006 02:28:52 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd5mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59D5C43CA0 for ; Sun, 10 Dec 2006 02:27:44 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JA100K3MDHTG550@l-daemon> for freebsd-current@freebsd.org; Sat, 09 Dec 2006 19:27:29 -0700 (MST) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd4mr5so.prod.shaw.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JA100M8PDHTJN51@pd4mr5so.prod.shaw.ca> for freebsd-current@freebsd.org; Sat, 09 Dec 2006 19:27:29 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JA10014ODHTF4F1@l-daemon> for freebsd-current@freebsd.org; Sat, 09 Dec 2006 19:27:29 -0700 (MST) Received: (qmail 1266 invoked from network); Sun, 10 Dec 2006 02:27:16 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Sun, 10 Dec 2006 02:27:16 +0000 Date: Sat, 09 Dec 2006 18:27:16 -0800 From: Colin Percival In-reply-to: <20061210014924.GU81923@egr.msu.edu> To: Adam McDougall Message-id: <457B7084.9070409@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> <20061210014924.GU81923@egr.msu.edu> User-Agent: Thunderbird 1.5.0.8 (X11/20061207) Cc: freebsd-current@freebsd.org Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 02:28:52 -0000 Adam McDougall wrote: > I just tested tcp.closed with 3 seconds, down from 15 earlier but both were > unsuccessful. I will look at the other options as well, but do you have any explanation > for why portsnap would use wildly randomish local ports that overlap too quickly > when fetch does not? Is that a kernel controlled behavior that I can adjust? Try setting net.inet.ip.portrange.randomized=0. This shouldn't make any difference, but it might. Colin Percival From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 03:11:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D016716A40F; Sun, 10 Dec 2006 03:11:42 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C5543C9F; Sun, 10 Dec 2006 03:10:34 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 97AE68C9A18; Sun, 10 Dec 2006 11:11:40 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 72FE98C984F; Sun, 10 Dec 2006 11:11:40 +0800 (CST) Date: Sun, 10 Dec 2006 11:11:40 +0800 (CST) From: Tai-hwa Liang To: Robert Watson In-Reply-To: <20061209214233.L2273@fledge.watson.org> Message-ID: <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andrew Pantyukhin , freebsd-current@freebsd.org, yal Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 03:11:42 -0000 On Sat, 9 Dec 2006, Robert Watson wrote: [...] > Right now, setting debug.mpsafenet=1 has three effects: > > (1) Place Giant over the network stack, creating a single lock that spans the > entire stack, preventing parallelism, as well as acting as a "master" > lock > which implicitly prevents lock order-related deadlocks in the stack. > > (2) Effectively disabling preemption in the network stack, as ithreads and > the > netisr will be unable to start running until user threads exit the stack, > regardless of priority. > > (3) Effectively disable direct dispatch, as non-MPSAFE netisr handlers are > always deferred rather than executing in the ithread context. > > I suspect that many of the people setting debug.mpsafenet=1 and declaring the > problem fixed are seeing the change due to (2) and (3), indirect rather than > direct effects of (1). I would much rather people experimented with: > > - Disabling direct dispatch (net.isr.direct=0) > > - Disabling preemption (compiling out options PREEMPTION) > > - Running with WITNESS, which reports lock order reversals. > > which get a bit more to the heart of most problems. debug.mpsafenet=1 really > exists for the purposes of supporting components which are not sufficiently > locked to allow the stack to run MPSAFE, rather than as a means of disabling > direct dispatch and preemption, which speak to different types of problems. > The main reason that I haven't removed the administrator tunable to date is > that I suspect it will be quite helpful when KAME IPSEC locking happens, but > since that appears not to have happened yet, debug.mpsafenet as an option is > likely causing more harm than good by being available as a stand-in sysctl > masking other problems, causing people to not get to the point of properly > identifying the actual cause (device driver bugs, etc). Can the aforementioned tricks(1/2/3) being applied to RELENG_6 as well? We are using RELENG_6 as our production server(postfix, squid, pf firewall/NAT, FAST_IPSEC VPN, ...), which is a dual Athlon MP board with three NICs(two fxp cards and one onboard xl, connected to three different networks). I haven't try WITNESS, yet; however, I'm very sure that net.isr.direct=0 plus that there is no PREEMPTION in current kernel. The problem is that, with debug.mpsafenet=1, we'll always run into hard freeze w/o having any kdb> prompt on console. Whilst turning debug.mpsafenet off only masks the real problem, I'm still wondering about if there is any less damaging way to track such problem down in a _production_ environment. -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 07:56:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39C8216A403; Sun, 10 Dec 2006 07:56:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7C9B43CA7; Sun, 10 Dec 2006 07:55:18 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBA7uR0V049048; Sun, 10 Dec 2006 02:56:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBA7uQVK045373; Sun, 10 Dec 2006 02:56:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C543773034; Sun, 10 Dec 2006 02:56:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061210075626.C543773034@freebsd-current.sentex.ca> Date: Sun, 10 Dec 2006 02:56:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean 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: Sun, 10 Dec 2006 07:56:33 -0000 TB --- 2006-12-10 06:30:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-10 06:30:19 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-10 06:30:19 - cleaning the object tree TB --- 2006-12-10 06:31:06 - checking out the source tree TB --- 2006-12-10 06:31:06 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-10 06:31:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-10 06:39:02 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-10 06:39:02 - cd /src TB --- 2006-12-10 06:39:02 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 10 06:39:04 UTC 2006 >>> 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 Sun Dec 10 07:44:14 UTC 2006 TB --- 2006-12-10 07:44:14 - generating LINT kernel config TB --- 2006-12-10 07:44:14 - cd /src/sys/sun4v/conf TB --- 2006-12-10 07:44:14 - /usr/bin/make -B LINT TB --- 2006-12-10 07:44:14 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-10 07:44:14 - cd /src TB --- 2006-12-10 07:44:14 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 10 07:44:14 UTC 2006 >>> 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 -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/sun4v/sun4v/swtch.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/sun4v/sun4v/tsb.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/sun4v/sun4v/tte.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/sun4v/sun4v/tte_hash.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/sun4v/sun4v/tick.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/sun4v/sun4v/trap.c /src/sys/sun4v/sun4v/trap.c: In function `trap_pfault': /src/sys/sun4v/sun4v/trap.c:461: error: subscripted value is neither array nor pointer *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-10 07:56:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-10 07:56:26 - ERROR: failed to build lint kernel TB --- 2006-12-10 07:56:26 - tinderbox aborted TB --- 0.50 user 2.03 system 5166.60 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 08:06:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AAEA16A403 for ; Sun, 10 Dec 2006 08:06:29 +0000 (UTC) (envelope-from fulanpeng@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id B524E43C9D for ; Sun, 10 Dec 2006 08:05:19 +0000 (GMT) (envelope-from fulanpeng@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so672823pyh for ; Sun, 10 Dec 2006 00:06:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=C0qCqAlBaTocSFTq0w1DEheoylvRiIDTjuwpRK3HaYUtVQ0IqH8Z7KXzgrEzDuyRkATRYSKG0VjT2bQDqE6zEP66HRQyb05bHdchmw1mNVcf4WrrrakRRiK20DWm6uVpI6EdW5cn5x95g2uPsTEd8dnvr/gnMyto6uQZgEMkUNI= Received: by 10.64.199.2 with SMTP id w2mr8711798qbf.1165737987489; Sun, 10 Dec 2006 00:06:27 -0800 (PST) Received: by 10.64.241.6 with HTTP; Sun, 10 Dec 2006 00:06:27 -0800 (PST) Message-ID: Date: Sun, 10 Dec 2006 03:06:27 -0500 From: "fulan Peng" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: samba-cups-pdf virtual printer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 08:06:29 -0000 Hi, I am using 6.1. I just went /usr/ports/net/samba3 and print/cups-pdf and did make clean installs. I made samba_enable="YES" and cupsd_enable="YES" in /etc/rc.conf file. I managed to make swat running and the cupsd listening at 631. I went http://192.158.0.1:631, I clicked printer and add button, it showed Name, Location, Description, then there is an add button. From Samba's swat, I could not find any printer either. I added a printer named cups. Now I do not know what I should do in cupsd at http://192.168.0.1:631/admin. When making Samba, I just selected CUPS and no other options and I choose share for the security options. Please help to give some hint to make Samba-Cups-pdf writer work! Thanks a lot! Fulan Peng. From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 08:42:36 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AFEC16A407 for ; Sun, 10 Dec 2006 08:42:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB05543C9E for ; Sun, 10 Dec 2006 08:41:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8FBD046B0A; Sun, 10 Dec 2006 03:42:35 -0500 (EST) Date: Sun, 10 Dec 2006 08:42:35 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Konovalov In-Reply-To: <20061210013735.D11309@mp2.macomnet.net> Message-ID: <20061210083752.G9926@fledge.watson.org> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061210013735.D11309@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, yal Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 08:42:36 -0000 On Sun, 10 Dec 2006, Maxim Konovalov wrote: >> Do you have any information about the actual source of this problem? > > No, I don't. The whole system is unstable. E.g. ifconfig hangs at the > random time. Wireless stops working, mouse is lagging. Suddenly the whole > system just hangs. > > yal@ replied in the private email debug.mpsafenet="0" did help him too. > >> Would it motivate solving the problem if I were to remove the >> debug.mpsafenet tunable? :-) > > I didn't suggest to turn off mpsafenet forever and forget, I just wanted to > check my guess. I would like to help to debug the problem but I need some > initial instructions to start. There is a firewire console. What do I need > to check? Start with the information in my followup e-mail to Andrew: - Configure WITNESS and see if you get any console output regarding lock order problems. - Try setting net.isr.direct=0 and see if the problem goes away. - Try removing options PREEMPTION and see if the problem goes away. Don't try them all at once, rather, try them individually until you've managed to find some arrangement that makes the source of the problem more clear (i.e., a WITNESS warning involving, say, the network stack). When suggesting debug.mpsafenet=0 as a debugging step, please make it clear that this is not a solution. The hope is that in 7.0, all components of the network stack will be MPSAFE, so whether in the short or long term, it is going away, and workarounds masking the problem don't get us any closer to solving the problem. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 09:52:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED46216A407 for ; Sun, 10 Dec 2006 09:52:33 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-1.orange.nl (smtp-1.orange.nl [193.252.22.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E9DF43CA0 for ; Sun, 10 Dec 2006 09:51:24 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6004.orange.nl (SMTP Server) with ESMTP id 3DCCB1C00083 for ; Sun, 10 Dec 2006 10:52:32 +0100 (CET) X-ME-UUID: 20061210095232253.3DCCB1C00083@mwinf6004.orange.nl Received: (qmail 22577 invoked from network); 10 Dec 2006 09:52:31 -0000 Received: from 10.66.0.143 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:1(10.66.0.143):. Processed in 0.378305 secs); 10 Dec 2006 09:52:31 -0000 X-Qmail-Scanner-Mail-From: nick@van-laarhoven.org via uitsmijter.van-laarhoven.org X-Qmail-Scanner: 1.25 (Clear:RC:1(10.66.0.143):. Processed in 0.378305 secs) Received: from unknown (HELO van-laarhoven.org) (nick@10.66.0.143) by uitsmijter.van-laarhoven.org with SMTP; 10 Dec 2006 09:52:31 -0000 Received: (nullmailer pid 48439 invoked by uid 1001); Sun, 10 Dec 2006 09:52:30 -0000 Date: Sun, 10 Dec 2006 10:52:30 +0100 (CET) From: Nick Hibma X-X-Sender: nick@localhost To: Marius Strobl In-Reply-To: <20061209210629.GG86517@alchemy.franken.de> Message-ID: <20061210105101.G42195@localhost> References: <20061209154559.B1408@localhost> <20061209185539.GA34399@alchemy.franken.de> <20061209201438.B42195@localhost> <20061209210629.GG86517@alchemy.franken.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD CURRENT Mailing List Subject: Re: mk48txx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 09:52:34 -0000 > I favor having no man page over having something incomplete > or inadequate like f.e. esp.4 or bus_space.9 as IMO wrong > information can confuse way more and leaves a worse impression > than no information at all. I favor having no code than code that isn't documented. Nick From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 09:53:33 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E0FB16A40F; Sun, 10 Dec 2006 09:53:33 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67A7D43CA0; Sun, 10 Dec 2006 09:52:23 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id kBA9rTmb053280; Sun, 10 Dec 2006 12:53:30 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Sun, 10 Dec 2006 12:53:29 +0300 (MSK) From: Maxim Konovalov To: Robert Watson In-Reply-To: <20061210083752.G9926@fledge.watson.org> Message-ID: <20061210123204.V52497@mp2.macomnet.net> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061210013735.D11309@mp2.macomnet.net> <20061210083752.G9926@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@FreeBSD.org, yal Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 09:53:33 -0000 > > I didn't suggest to turn off mpsafenet forever and forget, I just > > wanted to check my guess. I would like to help to debug the > > problem but I need some initial instructions to start. There is a > > firewire console. What do I need to check? > > Start with the information in my followup e-mail to Andrew: > > - Configure WITNESS and see if you get any console output regarding > lock order problems. Yes, there is one: lock order reversal 1st 0xd0f277c8 inp (rawinp) @ /usr/src/sys/netinet/raw_ip.c 2nd 0xd0ecbb54 wi0 (network driver) @ /usr/src/sys/modules/wi/../../dev/wi/if_wi.c KDB db_trace_self_wrapper(ce626f9d) at db_trace_self_wrapper+0x25 kdb_backtrace(ffffffff,ce6a6378,ce6a6b20,ce65bd24,ce6e4ed0,...) at kdb_backtrace+0x29 witness_checkorder(d0ecbb54,9,d0e73d13,388) at witness_checkorder+0x4db _mtx_lock_flags(d0ecbb54,0,d0e73d13,388,ce4d8cdd,...) at _mtx_lock_flags+0x1e wi_start(d0e05800) at wi_start+0x32 if_start(d0e05800) at if_start+0x53 ether_output_frame(d0e05800,d0d18100,0,1,0,...) at ether_output_frame+0x180 ether_output(d0e05800,d0d18100,d0e652b0,d0e61bb8,ce6e6b18,...) at ether_output+0x3c0 ieee80211_output(d0e05800,d0d18100,d0e652b0,d0e61bb8,0,...) at ieee80211_output+0x33 ip_output(d0d18100,0,e1afbb38,20,0,...) at ip_output+0x7f0 rip_output(d0d18100,d102ee44,1d2722c3,2000,e1afbbf0,...) at rip_output+0x29b rip_send(d102ee44,0,d0d18100,0,0,...) at rip_send+0x4f sosend_generic(d102ee44,0,0,d0d18100,0,...) at sosend_generic+0x3e1 sosend(d102ee44,0,0,d0d18100,0,...) at sosend+0x22 ng_ksocket_rcvdata(d10ab280,d104f750,1,e1afbc78,0,...) at ng_ksocket_rcvdata+0xa3 ng_apply_item(d10ab200,d104f750,0,0,d10ab200,...) at ng_apply_item+0xf8 ngintr(0) at ngintr+0x13d swi_net(0) at swi_net+0xba ithread_execute_handlers(d09acb40,d09dba00) at ithread_execute_handlers+0xce ithread_loop(d09dc180,e1afbd38,ce697af0,0,ce622832,328) at ithread_loop+0x4f fork_exit(ce4cdf0c,d09dc180,e1afbd38) at fork_exit+0x68 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe1afbd6c, ebp = 0 --- At this point ifconfig wlan0 hangs, reboot hangs. > - Try setting net.isr.direct=0 and see if the problem goes away. This indeed help. LOR has gone and wireless works. > - Try removing options PREEMPTION and see if the problem goes away. Haven't try. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 10:04:43 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3329416A40F for ; Sun, 10 Dec 2006 10:04:43 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-4.orange.nl (smtp-4.orange.nl [193.252.22.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24AE243C9E for ; Sun, 10 Dec 2006 10:03:33 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf6309.orange.nl (SMTP Server) with ESMTP id 2A34C1C00083 for ; Sun, 10 Dec 2006 11:04:41 +0100 (CET) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6309.orange.nl (SMTP Server) with ESMTP id CD9A21C00081 for ; Sun, 10 Dec 2006 11:04:40 +0100 (CET) X-ME-UUID: 20061210100440842.CD9A21C00081@mwinf6309.orange.nl Received: (qmail 22902 invoked from network); 10 Dec 2006 10:04:40 -0000 Received: from 10.66.0.143 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:1(10.66.0.143):. Processed in 0.537084 secs); 10 Dec 2006 10:04:40 -0000 X-Qmail-Scanner-Mail-From: nick@van-laarhoven.org via uitsmijter.van-laarhoven.org X-Qmail-Scanner: 1.25 (Clear:RC:1(10.66.0.143):. Processed in 0.537084 secs) Received: from unknown (HELO van-laarhoven.org) (nick@10.66.0.143) by uitsmijter.van-laarhoven.org with SMTP; 10 Dec 2006 10:04:39 -0000 Received: (nullmailer pid 48569 invoked by uid 1001); Sun, 10 Dec 2006 10:04:39 -0000 Date: Sun, 10 Dec 2006 11:04:39 +0100 (CET) From: Nick Hibma X-X-Sender: nick@localhost To: FreeBSD CURRENT Mailing List Message-ID: <20061210110419.H42195@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 10:04:43 -0000 I'm planning on committing the following change to make the implementations of the various hardware watchdogs more consistent. A timeout of 0 passed to the ioctl is now a valid input and will disable the watchdog. Previously it produced an error for the Elan chip watchdog, which is _not_ what you want to see when disarming a watchdog :-) I'd appreciate review of the individual changes in the files by the following people. The change as a whole was discussed with phk. cognet@freebsd.org i80321_wdog.c (*) des ichwd.c (**) ambrisko ipmi.c marius mk48txx.c phk kern_clock.c, elan-mmcr.c, watchdog.c (**) (*) The i80321_wdog.c cannot be disarmed. Is this correct? (**) These have been tested to arm, disarm, and fire. Others have only been compile tested. This change has been tested on 6.2-STABLE and 7-CURRENT. Commit message: Convert all watchdog event handlers to the following format: - If the timeout value passed is >0 and acceptable arm the watchdog and set the *error to 0 (a watchdog is armed). - Otherwise disarm the watchdog and leave *error as is (valid disarm). - If the timeout value passed is 0, disarm the watchdog. set *error to an error if disarm failed. The default of *error in the ioctl is a failed arm and a succesful disarm. Also: - Return an error if WD_PASSIVE is passed in to the ioctl as only WD_ACTIVE is implemented at the moment. See sys/watchdog.h for an explanation of the difference between WD_ACTIVE and WD_PASSIVE. - Remove the I_HAVE_TOTALLY_LOST_MY_SENSE_OF_HUMOR define. If you've lost your sense of humor, than don't add a define. i80321_wdog.c Don't roll your own passive watchdog tickle as this would defeat the purpose of an active (userland) watchdog tickle. ichwd.c / ipmi.c: WD_ACTIVE means userland pats of the watchdog, not whether the watchdog is active. See sys/watchdog.h. kern_clock.c: Remove a check for WD_ACTIVE as this does not make sense here. This reverts r1.181, as that commit doesn't make sense. Index: sys/arm/xscale/i80321/i80321_wdog.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/i80321/i80321_wdog.c,v retrieving revision 1.2 diff -u -r1.2 i80321_wdog.c --- sys/arm/xscale/i80321/i80321_wdog.c 15 Jan 2005 18:38:10 -0000 1.2 +++ sys/arm/xscale/i80321/i80321_wdog.c 9 Dec 2006 12:40:40 -0000 @@ -62,7 +62,6 @@ device_t dev; int armed; int wdog_period; - struct callout_handle wdog_callout; }; static __inline void @@ -83,8 +82,6 @@ return; wdtcr_write(WDTCR_ENABLE1); wdtcr_write(WDTCR_ENABLE2); - sc->wdog_callout = timeout(iopwdog_tickle, sc, - hz * (sc->wdog_period - 1)); } static int @@ -112,14 +109,19 @@ { struct iopwdog_softc *sc = private; - if (cmd == 0) - return; - if ((((uint64_t)1 << (cmd & WD_INTERVAL))) > - (uint64_t)sc->wdog_period * 1000000000) - return; - sc->armed = 1; - iopwdog_tickle(sc); - *error = 0; + cmd &= WD_INTERVAL; + if (cmd > 0 && cmd <= 63 + && (uint64_t)1 << (cmd & WD_INTERVAL) <= + (uint64_t)sc->wdog_period * 1000000000) { + /* Valid value -> Enable watchdog */ + iopwdog_tickle(sc); + sc->armed = 1; + *error = 0; + } else { + /* XXX Can't disable this watchdog? */ + if (sc->armed) + *error = EOPNOTSUPP; + } } static int Index: sys/dev/ichwd/ichwd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ichwd/ichwd.c,v retrieving revision 1.5.2.1 diff -u -r1.5.2.1 ichwd.c --- sys/dev/ichwd/ichwd.c 15 Jun 2006 15:15:07 -0000 1.5.2.1 +++ sys/dev/ichwd/ichwd.c 9 Dec 2006 12:40:46 -0000 @@ -178,38 +178,20 @@ struct ichwd_softc *sc = arg; unsigned int timeout; + /* convert from power-of-two-ns to WDT ticks */ + cmd &= WD_INTERVAL; + timeout = ((uint64_t)1 << cmd) / ICHWD_TICK; + if (cmd > 0 && cmd <= 63 + && timeout >= ICHWD_MIN_TIMEOUT && timeout <= ICHWD_MAX_TIMEOUT) { + if (timeout != sc->timeout) + ichwd_tmr_set(sc, timeout); - /* disable / enable */ - if (!(cmd & WD_ACTIVE)) { + ichwd_tmr_reload(sc); + *error = 0; + } else { if (sc->active) ichwd_tmr_disable(sc); - *error = 0; - return; } - if (!sc->active) - ichwd_tmr_enable(sc); - - cmd &= WD_INTERVAL; - /* convert from power-of-to-ns to WDT ticks */ - if (cmd >= 64) { - *error = EINVAL; - return; - } - timeout = ((uint64_t)1 << cmd) / ICHWD_TICK; - if (timeout < ICHWD_MIN_TIMEOUT || timeout > ICHWD_MAX_TIMEOUT) { - *error = EINVAL; - return; - } - - /* set new initial value */ - if (timeout != sc->timeout) - ichwd_tmr_set(sc, timeout); - - /* reload */ - ichwd_tmr_reload(sc); - - *error = 0; - return; } static unsigned int pmbase = 0; Index: sys/dev/ipmi/ipmi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ipmi/ipmi.c,v retrieving revision 1.3.2.3 diff -u -r1.3.2.3 ipmi.c --- sys/dev/ipmi/ipmi.c 19 Oct 2006 14:50:48 -0000 1.3.2.3 +++ sys/dev/ipmi/ipmi.c 9 Dec 2006 12:40:47 -0000 @@ -649,25 +649,14 @@ struct ipmi_softc *sc = arg; unsigned int timeout; - /* disable / enable */ - if (!(cmd & WD_ACTIVE)) { - ipmi_set_watchdog(sc, 0); - *error = 0; - return; - } - cmd &= WD_INTERVAL; - /* convert from power-of-to-ns to WDT ticks */ - if (cmd >= 64) { - *error = EINVAL; - return; + if (cmd > 0 && cmd <= 63) { + timeout = ((uint64_t)1 << cmd) / 1800000000; + ipmi_set_watchdog(sc, timeout); + *error = 0; + } else { + ipmi_set_watchdog(sc, 0); } - timeout = ((uint64_t)1 << cmd) / 1800000000; - - /* reload */ - ipmi_set_watchdog(sc, timeout); - - *error = 0; } #ifdef CLONING Index: sys/dev/watchdog/watchdog.c =================================================================== RCS file: /home/ncvs/src/sys/dev/watchdog/watchdog.c,v retrieving revision 1.2 diff -u -r1.2 watchdog.c --- sys/dev/watchdog/watchdog.c 16 Jun 2004 09:47:02 -0000 1.2 +++ sys/dev/watchdog/watchdog.c 9 Dec 2006 12:40:51 -0000 @@ -55,9 +55,16 @@ return (EINVAL); if ((u & (WD_ACTIVE | WD_PASSIVE)) == (WD_ACTIVE | WD_PASSIVE)) return (EINVAL); - if ((u & WD_INTERVAL) == WD_TO_NEVER) + if (u & WD_PASSIVE) + return (ENOSYS); /* XXX Not implemented yet */ + if ((u & WD_INTERVAL) == WD_TO_NEVER) { u = 0; - error = EOPNOTSUPP; + /* Assume all is well; watchdog signals failure. */ + error = 0; + } else { + /* Assume no watchdog available; watchdog flags success */ + error = EOPNOTSUPP; + } EVENTHANDLER_INVOKE(watchdog_list, u, &error); return (error); } Index: sys/i386/i386/elan-mmcr.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/elan-mmcr.c,v retrieving revision 1.31.2.1 diff -u -r1.31.2.1 elan-mmcr.c --- sys/i386/i386/elan-mmcr.c 16 Aug 2005 22:47:14 -0000 1.31.2.1 +++ sys/i386/i386/elan-mmcr.c 9 Dec 2006 12:40:53 -0000 @@ -367,11 +367,11 @@ static void elan_watchdog(void *foo __unused, u_int spec, int *error) { - u_int u, v; + u_int u, v, w; static u_int cur; u = spec & WD_INTERVAL; - if (spec && u <= 35) { + if (spec && u > 0 && u <= 35) { u = imax(u - 5, 24); v = 2 << (u - 24); v |= 0xc000; @@ -383,7 +383,7 @@ * for other reasons. Save and restore the GP echo mode * around our hardware tom-foolery. */ - u = elan_mmcr->GPECHO; + w = elan_mmcr->GPECHO; elan_mmcr->GPECHO = 0; if (v != cur) { /* Clear the ENB bit */ @@ -401,17 +401,17 @@ elan_mmcr->WDTMRCTL = 0xaaaa; elan_mmcr->WDTMRCTL = 0x5555; } - elan_mmcr->GPECHO = u; + elan_mmcr->GPECHO = w; *error = 0; return; } else { - u = elan_mmcr->GPECHO; + w = elan_mmcr->GPECHO; elan_mmcr->GPECHO = 0; elan_mmcr->WDTMRCTL = 0x3333; elan_mmcr->WDTMRCTL = 0xcccc; elan_mmcr->WDTMRCTL = 0x4080; - elan_mmcr->WDTMRCTL = u; - elan_mmcr->GPECHO = u; + elan_mmcr->WDTMRCTL = w; /* XXX What does this statement do? */ + elan_mmcr->GPECHO = w; cur = 0; return; } Index: sys/kern/kern_clock.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_clock.c,v retrieving revision 1.178.2.3 diff -u -r1.178.2.3 kern_clock.c --- sys/kern/kern_clock.c 10 Mar 2006 19:37:33 -0000 1.178.2.3 +++ sys/kern/kern_clock.c 9 Dec 2006 12:40:55 -0000 @@ -541,7 +541,7 @@ u_int u; u = cmd & WD_INTERVAL; - if ((cmd & WD_ACTIVE) && u >= WD_TO_1SEC) { + if (u >= WD_TO_1SEC) { watchdog_ticks = (1 << (u - WD_TO_1SEC)) * hz; watchdog_enabled = 1; *err = 0; Index: sys/sys/watchdog.h =================================================================== RCS file: /home/ncvs/src/sys/sys/watchdog.h,v retrieving revision 1.3 diff -u -r1.3 watchdog.h --- sys/sys/watchdog.h 28 Feb 2004 20:06:58 -0000 1.3 +++ sys/sys/watchdog.h 9 Dec 2006 12:41:08 -0000 @@ -30,11 +30,7 @@ #include -#ifdef I_HAVE_TOTALLY_LOST_MY_SENSE_OF_HUMOUR -#define _PATH_WATCHDOG "watchdog" -#else #define _PATH_WATCHDOG "fido" -#endif #define WDIOCPATPAT _IOW('W', 42, u_int) Index: share/man/man4/Makefile =================================================================== RCS file: /home/ncvs/src/share/man/man4/Makefile,v retrieving revision 1.320.2.21 diff -u -r1.320.2.21 Makefile --- share/man/man4/Makefile 23 Nov 2006 09:21:24 -0000 1.320.2.21 +++ share/man/man4/Makefile 9 Dec 2006 12:41:08 -0000 @@ -500,6 +500,7 @@ MLINKS+=wi.4 if_wi.4 MLINKS+=xe.4 if_xe.4 MLINKS+=xl.4 if_xl.4 +MLINKS+=watchdog.4 SW_WATCHDOG.4 .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" _amdsmb.4= amdsmb.4 Index: share/man/man4/watchdog.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/watchdog.4,v retrieving revision 1.6.8.1 diff -u -r1.6.8.1 watchdog.4 --- share/man/man4/watchdog.4 1 May 2006 19:42:45 -0000 1.6.8.1 +++ share/man/man4/watchdog.4 9 Dec 2006 12:41:08 -0000 @@ -32,54 +32,84 @@ .Nm watchdog .Nd "hardware and software watchdog" .Sh SYNOPSIS -.Cd "options CPU_ELAN" -.Cd "options CPU_GEODE" -.Cd "options SW_WATCHDOG" -.Pp .In sys/watchdog.h .Sh DESCRIPTION The .Nm facility is used for controlling hardware and software watchdogs. .Pp -The interface is through a device .Pa /dev/fido -which responds to a single +responds to a single .Xr ioctl 2 call, .Dv WDIOCPATPAT . +It takes a single argument which represents a timeout value specified as a +power of two nanoseconds, or-ed with a flag selecting active or passive control +of the watchdog. .Pp -The call takes a single argument which represents a timeout value -specified as an integer power of two nanoseconds. -.Pp -The .Dv WD_ACTIVE -flag signals that the +indicates that the .Nm -will be kept from -timing out from userland, for instance by the +will be kept from timing out from userland, for instance by the .Xr watchdogd 8 daemon. -.Pp -To disable the watchdogs, an argument of zero should be used. +.Dv WD_PASSIVE +indicates that the +.Nm +will be kept from timing out from the kernel. .Pp The .Xr ioctl 2 call will return success if just one of the available .Xr watchdog 9 -implementations support the request. -If the call fails, for instance if none of +implementations supports setting the timeout to the specified timeout. This +means that at least one watchdog is armed. If the call fails, for instance if +none of .Xr watchdog 9 -implementations support the timeout -length, all watchdogs are disabled and must be explicitly re-enabled. +implementations support the timeout length, all watchdogs are disabled and must +be explicitly re-enabled. +.Pp +To disable the watchdogs pass +.Dv WD_TO_NEVER . +If disarming the watchdog(s) failed an error is returned. The watchdog might +still be armed! .Sh EXAMPLES -.\" XXX insert some descriptive text here .Bd -literal -offset indent -u_int u = WD_ACTIVE | WD_TO_8SEC; -int fd = open("/dev/fido", O_RDWR); +#include +#include + +#define WDPATH "/dev/" _PATH_WATCHDOG +int wdfd = -1; -ioctl(fd, WDIOCPATPAT, &u); +static void +wd_init(void) +{ + wdfd = open(WDPATH, O_RDWR); + if (wdfd == -1) + err(1, WDPATH); +} +static void +wd_reset(u_int timeout) +{ + if (ioctl(wdfd, WDIOCPATPAT, &timeout) == -1) + err(1, "WDIOCPATPAT"); +} + +/* in main() */ +wd_init(); +wd_reset(WD_ACTIVE|WD_TO_8SEC); +/* potential freeze point */ +wd_reset(WD_TO_NEVER); .Ed +.Pp +Enables a watchdog to recover from a potentially freezing piece of code. +.Pp +.Bd -literal -offset indent +options SW_WATCHDOG +.Ed +.Pp +in your kernel config adds a software watchdog in the kernel, dropping to KDB +or panic-ing when firing. .Sh SEE ALSO .Xr watchdogd 8 , .Xr watchdog 9 @@ -88,14 +118,17 @@ .Nm code first appeared in .Fx 5.1 . +.Sh BUGS +The +.Dv WD_PASSIVE +option has not yet been implemented. .Sh AUTHORS .An -nosplit The .Nm facility was written by .An Poul-Henning Kamp Aq phk@FreeBSD.org . -The software watchdog code -and this manual page were written by +The software watchdog code and this manual page were written by .An Sean Kelly Aq smkelly@FreeBSD.org . Some contributions were made by .An Jeff Roberson Aq jeff@FreeBSD.org . Index: watchdog.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/watchdog.9,v retrieving revision 1.3 diff -u -r1.3 watchdog.9 --- watchdog.9 6 Jul 2004 07:39:50 -0000 1.3 +++ watchdog.9 9 Dec 2006 13:14:54 -0000 @@ -35,6 +35,7 @@ .Ft void .Fn watchdog_fn "void *private" "u_int cmd" "int *error" .Fn EVENTHANDLER_REGISTER watchdog_list watchdog_fn private 0 +.Fn EVENTHANDLER_DEREGISTER watchdog_list eventhandler_tag .Sh DESCRIPTION To implement a watchdog in software or hardware, only a single function needs to be written and registered on the global @@ -60,7 +61,9 @@ If the watchdog cannot be configured to the proposed timeout, it must be disabled and the .Fa error -argument left untouched. +argument left untouched. If the watchdog cannot be disabled, the +.Fa error +argument must be set to indicate the error. .Pp There is no specification of what the watchdog should do when it times out, but a hardware reset or similar From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 12:57:15 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD78216A407 for ; Sun, 10 Dec 2006 12:57:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 161DE43C9D for ; Sun, 10 Dec 2006 12:56:05 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3E0C246F09; Sun, 10 Dec 2006 07:57:14 -0500 (EST) Date: Sun, 10 Dec 2006 12:57:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Konovalov In-Reply-To: <20061210123204.V52497@mp2.macomnet.net> Message-ID: <20061210125011.F2296@fledge.watson.org> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061210013735.D11309@mp2.macomnet.net> <20061210083752.G9926@fledge.watson.org> <20061210123204.V52497@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, yal Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 12:57:16 -0000 On Sun, 10 Dec 2006, Maxim Konovalov wrote: >>> I didn't suggest to turn off mpsafenet forever and forget, I just wanted >>> to check my guess. I would like to help to debug the problem but I need >>> some initial instructions to start. There is a firewire console. What do >>> I need to check? >> >> Start with the information in my followup e-mail to Andrew: >> >> - Configure WITNESS and see if you get any console output regarding >> lock order problems. > > Yes, there is one: > > lock order reversal > 1st 0xd0f277c8 inp (rawinp) @ /usr/src/sys/netinet/raw_ip.c > 2nd 0xd0ecbb54 wi0 (network driver) @ /usr/src/sys/modules/wi/../../dev/wi/if_wi.c > KDB > db_trace_self_wrapper(ce626f9d) at db_trace_self_wrapper+0x25 > kdb_backtrace(ffffffff,ce6a6378,ce6a6b20,ce65bd24,ce6e4ed0,...) at kdb_backtrace+0x29 > witness_checkorder(d0ecbb54,9,d0e73d13,388) at witness_checkorder+0x4db > _mtx_lock_flags(d0ecbb54,0,d0e73d13,388,ce4d8cdd,...) at _mtx_lock_flags+0x1e > wi_start(d0e05800) at wi_start+0x32 > if_start(d0e05800) at if_start+0x53 > ether_output_frame(d0e05800,d0d18100,0,1,0,...) at ether_output_frame+0x180 > ether_output(d0e05800,d0d18100,d0e652b0,d0e61bb8,ce6e6b18,...) at ether_output+0x3c0 > ieee80211_output(d0e05800,d0d18100,d0e652b0,d0e61bb8,0,...) at ieee80211_output+0x33 > ip_output(d0d18100,0,e1afbb38,20,0,...) at ip_output+0x7f0 > rip_output(d0d18100,d102ee44,1d2722c3,2000,e1afbbf0,...) at rip_output+0x29b > rip_send(d102ee44,0,d0d18100,0,0,...) at rip_send+0x4f > sosend_generic(d102ee44,0,0,d0d18100,0,...) at sosend_generic+0x3e1 > sosend(d102ee44,0,0,d0d18100,0,...) at sosend+0x22 > ng_ksocket_rcvdata(d10ab280,d104f750,1,e1afbc78,0,...) at ng_ksocket_rcvdata+0xa3 > ng_apply_item(d10ab200,d104f750,0,0,d10ab200,...) at ng_apply_item+0xf8 > ngintr(0) at ngintr+0x13d > swi_net(0) at swi_net+0xba > ithread_execute_handlers(d09acb40,d09dba00) at ithread_execute_handlers+0xce > ithread_loop(d09dc180,e1afbd38,ce697af0,0,ce622832,328) at ithread_loop+0x4f > fork_exit(ce4cdf0c,d09dc180,e1afbd38) at fork_exit+0x68 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe1afbd6c, ebp = 0 --- > > At this point ifconfig wlan0 hangs, reboot hangs. > >> - Try setting net.isr.direct=0 and see if the problem goes away. > > This indeed help. LOR has gone and wireless works. > >> - Try removing options PREEMPTION and see if the problem goes away. > > Haven't try. As speculated by others, this is a bug in the if_wi driver, which improperly holds a device driver lock over a call into the network stack. While this can result in a deadlock under other circumstances, net.isr.direct makes the chances of that deadlock much greater. It appears also that you have netgraph in the mix somehow, which might well also increase the chances of the deadlock triggering. Someone(tm) needs to fix if_wi to operate properly with respect to the network stack lock order; another feature likely to trigger the same device driver bug is IP fast forwarding from a wireless interface. Sam has mentioned to me that this same bug exists in several wireless drivers. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 13:03:53 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5931A16A47B for ; Sun, 10 Dec 2006 13:03:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90C4743CA1 for ; Sun, 10 Dec 2006 13:02:24 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 15E18170C5; Sun, 10 Dec 2006 13:03:32 +0000 (UTC) To: Nick Hibma From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 10 Dec 2006 11:04:39 +0100." <20061210110419.H42195@localhost> Date: Sun, 10 Dec 2006 13:03:27 +0000 Message-ID: <12904.1165755807@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD CURRENT Mailing List Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 13:03:53 -0000 In message <20061210110419.H42195@localhost>, Nick Hibma writes: > cognet@freebsd.org i80321_wdog.c (*) >(*) The i80321_wdog.c cannot be disarmed. Is this correct? If true, then this is a poster-child for the WD_PASSIVE need, the idea being that if userland says "I'll not pat the dog anymore" and the hardware cannot be disabled, the kernel shoul do it. >- If the timeout value passed is >0 and acceptable arm the watchdog and set the >*error to 0 (a watchdog is armed). Agreed, the WD_ACTIVE/WD_PASSIVE shouldn't matter to the drivers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 13:08:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BF0516A403; Sun, 10 Dec 2006 13:08:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9985B43CA1; Sun, 10 Dec 2006 13:07:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1B34846F56; Sun, 10 Dec 2006 08:08:37 -0500 (EST) Date: Sun, 10 Dec 2006 13:08:36 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tai-hwa Liang In-Reply-To: <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> Message-ID: <20061210084254.X9926@fledge.watson.org> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andrew Pantyukhin , freebsd-current@freebsd.org, yal Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 13:08:38 -0000 On Sun, 10 Dec 2006, Tai-hwa Liang wrote: >> which get a bit more to the heart of most problems. debug.mpsafenet=1 >> really exists for the purposes of supporting components which are not >> sufficiently locked to allow the stack to run MPSAFE, rather than as a >> means of disabling direct dispatch and preemption, which speak to different >> types of problems. The main reason that I haven't removed the administrator >> tunable to date is that I suspect it will be quite helpful when KAME IPSEC >> locking happens, but since that appears not to have happened yet, >> debug.mpsafenet as an option is likely causing more harm than good by being >> available as a stand-in sysctl masking other problems, causing people to >> not get to the point of properly identifying the actual cause (device >> driver bugs, etc). > > Can the aforementioned tricks(1/2/3) being applied to RELENG_6 as well? WITNESS is available in RELENG_6, and should be used in combination with INVARIANTS, DDB, KDB, and BREAK_TO_DEBUGGER to debug deadlocks. In RELENG_6, net.isr.direct is not enabled by default, so unless you've enabled it yourself (or are using IP fast forwarding, which is functionally similar), that won't apply. In RELENG_6, PREEMPTION is in GENERIC and hence enabled by default, and it can be disabled by removing it from your kernel configuration. I'd like it if we could add a run-time sysctl to disable preemption even if PREEMPTION is compiled in, as it would make it easier to explore its stability and performance impact. However, this is also just a debugging step to see if that quiesces the problem, and not a fix for the actual bug. Right now, we're discussing removing the manual debug.mpsafenet configuration flag from 7.x, and not 6.x. I fully recognize the importance of having it in place as a workaround for bugs in production, although it concerns me greatly that we're not getting these problems debugged and fixed, and instead masking them. Architectural changes are on the way that will require these bugs to be fixed properly, not just masked. > We are using RELENG_6 as our production server(postfix, squid, pf > firewall/NAT, FAST_IPSEC VPN, ...), which is a dual Athlon MP board with > three NICs(two fxp cards and one onboard xl, connected to three different > networks). > > I haven't try WITNESS, yet; however, I'm very sure that net.isr.direct=0 > plus that there is no PREEMPTION in current kernel. The problem is that, > with debug.mpsafenet=1, we'll always run into hard freeze w/o having any > kdb> prompt on console. > > Whilst turning debug.mpsafenet off only masks the real problem, I'm still > wondering about if there is any less damaging way to track such problem down > in a _production_ environment. It sounds like you need to follow the instructions for kernel debugging. Depending on your tolerance of performance loss, downtime, etc, a good starting point is to configure the kernel with INVARIANTS and WITNESS. WITNESS is particularly important, if you can tolerate the performance hit, as it warns of potential deadlocks, not just actual deadlocks. Also, compile the kernel with KDB, DDB, and BREAK_TO_DEBUGGER, and user a serial or firewire console. If the hang occurs, see if you can get into the debugger, in which case the logged output from DDB for the following commands would be very useful: show pcpu show allpcpu trace alltrace ps show locks show alllocks show lockedvnods show uma show malloc Please open a PR that describes your configuration, includes your kernel config (since it seems quite customized), any loader.conf settings, a detailed description of the problem, and the output. I'd be quite interested in know, once the machine is in a hung state, whether the numlock light goes on and off when you hit the numlock key on the keyboard. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 13:15:20 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1BA716A40F for ; Sun, 10 Dec 2006 13:15:20 +0000 (UTC) (envelope-from yal@yal.hopto.org) Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6D5643CA3 for ; Sun, 10 Dec 2006 13:14:00 +0000 (GMT) (envelope-from yal@yal.hopto.org) Received: from koala.unime.lan (87.11.169.84) by vsmtp4.tin.it (7.2.072.1) id 45741B2600465417 for freebsd-current@FreeBSD.org; Sun, 10 Dec 2006 14:15:09 +0100 Received: from koala.unime.lan (localhost [127.0.0.1]) by koala.unime.lan (8.13.8/8.13.8) with ESMTP id kBAD4Uem014079 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Dec 2006 14:04:31 +0100 (CET) (envelope-from yal@yal.hopto.org) Received: (from www@localhost) by koala.unime.lan (8.13.8/8.13.8/Submit) id kBAD4Udl014078; Sun, 10 Dec 2006 14:04:30 +0100 (CET) (envelope-from yal@yal.hopto.org) X-Authentication-Warning: koala.unime.lan: www set sender to yal@yal.hopto.org using -f Received: from 192.168.1.110 (SquirrelMail authenticated user yal) by yal.hopto.org with HTTP; Sun, 10 Dec 2006 14:04:29 +0100 (CET) Message-ID: <54937.192.168.1.110.1165755869.squirrel@yal.hopto.org> Date: Sun, 10 Dec 2006 14:04:29 +0100 (CET) From: "yal" To: freebsd-current@FreeBSD.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yal@yal.hopto.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2006 13:15:21 -0000 On Sun, December 10, 2006 13:57, Robert Watson wrote: >> >>> - Try setting net.isr.direct=0 and see if the problem goes away. >> >> This indeed help. LOR has gone and wireless works. >> > result in a deadlock under other circumstances, net.isr.direct makes the chances of that deadlock much greater. It helped on Latutide D520 as well. No freeze or anything anymore. Top shows now 100% idle most of the time. The debug.mpsafent="0" has been deleted, as suggested. Thanks to Robert N. M. Watson. From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 13:53:23 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C82E116A412; Sun, 10 Dec 2006 13:53:23 +0000 (UTC) (envelope-from jmp.lists@alvorlig.dk) Received: from cauchy.aub.dk (cauchy.aub.dk [194.255.124.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF51D43C9E; Sun, 10 Dec 2006 13:52:04 +0000 (GMT) (envelope-from jmp.lists@alvorlig.dk) Received: from localhost (localhost.aub.dk [127.0.0.1]) by cauchy.aub.dk (Postfix) with ESMTP id A3136114E4; Sun, 10 Dec 2006 14:53:09 +0100 (CET) X-Virus-Scanned: amavisd-new at aub.dk Received: from cauchy.aub.dk ([127.0.0.1]) by localhost (cauchy.aub.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq3R4sKaxGKx; Sun, 10 Dec 2006 14:53:03 +0100 (CET) Received: from [10.4.50.223] (unknown [10.4.50.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jmp) by cauchy.aub.dk (Postfix) with ESMTP id 97FBD114D4; Sun, 10 Dec 2006 14:53:03 +0100 (CET) Message-ID: <457C1140.5040703@alvorlig.dk> Date: Sun, 10 Dec 2006 14:53:04 +0100 From: "J. Martin Petersen" User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG References: <4578E1AD.3090505@isc.org> <457A9DA0.1020601@alvorlig.dk> <20061209114555.A2273@fledge.watson.org> <20061209185802.GT98520@evil.alameda.net> In-Reply-To: <20061209185802.GT98520@evil.alameda.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ulf@Alameda.net, Robert Watson , Peter_Losher@isc.org Subject: Re: FreeBSD 6 (or 7) on a HP DL140 G3 SATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 13:53:23 -0000 Ulf Zimmermann wrote: > On Sat, Dec 09, 2006 at 11:47:21AM +0000, Robert Watson wrote: >> Upgrading proved to be a bit of a pain because the >> boxes don't have CDROM or floppy drives, and the HP firmware updater >> download is rather weird, but once it was updated (using a USB floppy >> drive) all was happiness. >> Oddly, the i386 loader had no problem at all... I think we tried both without success, but I am not 100% sure. > Here is how I update the bios on DL140. Create a DOS boot disk (I usual > use 6.22), put a ramdisk driver on it and whatever you need to flash > the bios. Then make an image of the disk and load it into your pxe > server. Boot via PXE said floppy image, copy BIOS flash utils and > firmware to ramdisk. Then run software from there. If you don't use > the ram disk, I have seen it fail often. We created a bootable USB stick with each of the BIOS'es and used that to flash with. Very easy and worked like a charm, once we found a Windows-"enabled" laptop. What kind of disk performance are you seeing from the disks hooked up to the mpt-controller? We are seeing disk transfers around 6MB/sec, which seems very slow, but I do not know how to diagnose it. Martin From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 15:10:26 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94DEE16A407 for ; Sun, 10 Dec 2006 15:10:26 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-4.orange.nl (smtp-4.orange.nl [193.252.22.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BA0A43C9D for ; Sun, 10 Dec 2006 15:09:15 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf6307.orange.nl (SMTP Server) with ESMTP id B9D0B7000089 for ; Sun, 10 Dec 2006 16:10:24 +0100 (CET) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6307.orange.nl (SMTP Server) with ESMTP id 9121F7000085 for ; Sun, 10 Dec 2006 16:10:24 +0100 (CET) X-ME-UUID: 20061210151024594.9121F7000085@mwinf6307.orange.nl Received: (qmail 29430 invoked from network); 10 Dec 2006 15:10:24 -0000 Received: from 10.66.0.143 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:1(10.66.0.143):. Processed in 0.382402 secs); 10 Dec 2006 15:10:24 -0000 X-Qmail-Scanner-Mail-From: nick@van-laarhoven.org via uitsmijter.van-laarhoven.org X-Qmail-Scanner: 1.25 (Clear:RC:1(10.66.0.143):. Processed in 0.382402 secs) Received: from unknown (HELO van-laarhoven.org) (nick@10.66.0.143) by uitsmijter.van-laarhoven.org with SMTP; 10 Dec 2006 15:10:23 -0000 Received: (nullmailer pid 50652 invoked by uid 1001); Sun, 10 Dec 2006 15:10:23 -0000 Date: Sun, 10 Dec 2006 16:10:23 +0100 (CET) From: Nick Hibma X-X-Sender: nick@localhost To: Poul-Henning Kamp In-Reply-To: <12904.1165755807@critter.freebsd.dk> Message-ID: <20061210160457.W42195@localhost> References: <12904.1165755807@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Nick Hibma , FreeBSD CURRENT Mailing List Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 15:10:26 -0000 >> cognet@freebsd.org i80321_wdog.c (*) >> (*) The i80321_wdog.c cannot be disarmed. Is this correct? > > If true, then this is a poster-child for the WD_PASSIVE need, the idea > being that if userland says "I'll not pat the dog anymore" and the hardware > cannot be disabled, the kernel shoul do it. ~he implementation of the WD_PASSIVE part is on my list. I don't quite agree with you on the kernel taking over though. When testing watchdogs you should be able to see that you could not disarm it, as you would otherwise get mysterious hard reboots. I'd rather have watchdogd refuse to exit if it cannot disarm the watchdog. I'll put that on my list too. Nick From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 15:29:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EECF516A533 for ; Sun, 10 Dec 2006 15:29:22 +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 2B9C743E4D for ; Sun, 10 Dec 2006 15:26:47 +0000 (GMT) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.13.8/8.13.8/ALCHEMY.FRANKEN.DE) with ESMTP id kBAFRt00046406; Sun, 10 Dec 2006 16:27:55 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.13.8/8.13.8/Submit) id kBAFRtMC046405; Sun, 10 Dec 2006 16:27:55 +0100 (CET) (envelope-from marius) Date: Sun, 10 Dec 2006 16:27:55 +0100 From: Marius Strobl To: Nick Hibma Message-ID: <20061210152755.GA45265@alchemy.franken.de> References: <20061210110419.H42195@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061210110419.H42195@localhost> User-Agent: Mutt/1.4.2.2i Cc: FreeBSD CURRENT Mailing List Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 15:29:23 -0000 On Sun, Dec 10, 2006 at 11:04:39AM +0100, Nick Hibma wrote: > I'm planning on committing the following change to make the implementations > of the various hardware watchdogs more consistent. A timeout of 0 passed to > the ioctl is now a valid input and will disable the watchdog. Previously it > produced an error for the Elan chip watchdog, which is _not_ what you want > to see when disarming a watchdog :-) I'd appreciate review of the > individual changes in the files by the following people. The change as a > whole was discussed with phk. > > cognet@freebsd.org i80321_wdog.c (*) > des ichwd.c (**) > ambrisko ipmi.c > marius mk48txx.c > phk kern_clock.c, elan-mmcr.c, watchdog.c (**) > > (*) The i80321_wdog.c cannot be disarmed. Is this correct? > (**) These have been tested to arm, disarm, and fire. Others have only been > compile tested. > > This change has been tested on 6.2-STABLE and 7-CURRENT. > > > Commit message: > > Convert all watchdog event handlers to the following format: > > - If the timeout value passed is >0 and acceptable arm the watchdog and set > the *error to 0 (a watchdog is armed). > - Otherwise disarm the watchdog and leave *error as is (valid disarm). > - If the timeout value passed is 0, disarm the watchdog. set *error to an > error if disarm failed. > I recognise this as the previous watchdog function API with the extension that when told to disarm via a timeout value of 0 the watchdog may now report failure to do so by setting *error, correct? If so this is fine with the stock mk48txx.c. Regarding your changes to watchdog.4 and watchdog.9 AFAICT they violate the established style guidelines for FreeBSD man pages; the source should wrap the line on sentence breaks. Marius From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 15:35:53 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BFE216A492 for ; Sun, 10 Dec 2006 15:35:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B92F43CAC for ; Sun, 10 Dec 2006 15:34:35 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 056421747D; Sun, 10 Dec 2006 15:35:44 +0000 (UTC) To: Nick Hibma From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 10 Dec 2006 16:10:23 +0100." <20061210160457.W42195@localhost> Date: Sun, 10 Dec 2006 15:35:40 +0000 Message-ID: <13532.1165764940@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD CURRENT Mailing List Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 15:35:53 -0000 In message <20061210160457.W42195@localhost>, Nick Hibma writes: >>> cognet@freebsd.org i80321_wdog.c (*) >>> (*) The i80321_wdog.c cannot be disarmed. Is this correct? >> >> If true, then this is a poster-child for the WD_PASSIVE need, the idea >> being that if userland says "I'll not pat the dog anymore" and the hardware >> cannot be disabled, the kernel shoul do it. > >~he implementation of the WD_PASSIVE part is on my list. > >I don't quite agree with you on the kernel taking over though. When >testing watchdogs you should be able to see that you could not disarm >it, as you would otherwise get mysterious hard reboots. I'd rather have >watchdogd refuse to exit if it cannot disarm the watchdog. I'll put that >on my list too. Watchdog[d](8) may not be the only program that calls the ioctl, in many embedded apps the central application will do so itself. It seems to me a much more intuitive behaviour if the kernel takes over the job of patting the offending piece of hardware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 18:07:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAD1416A40F for ; Sun, 10 Dec 2006 18:07:50 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 161C443CA6 for ; Sun, 10 Dec 2006 18:06:38 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from insp.local (jn@c-68-59-28-54.hsd1.sc.comcast.net [68.59.28.54]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id kBAI7n2R059543; Sun, 10 Dec 2006 10:07:49 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Sun, 10 Dec 2006 13:07:41 -0500 User-Agent: KMail/1.9.4 References: In-Reply-To: X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612101307.42690.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: fulan Peng Subject: Re: samba-cups-pdf virtual printer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 18:07:51 -0000 On Sunday 10 December 2006 03:06, fulan Peng wrote: > I am using 6.1. I just went /usr/ports/net/samba3 and print/cups-pdf > and did make clean installs. I made samba_enable="YES" and > cupsd_enable="YES" in /etc/rc.conf file. I managed to make swat > running and the cupsd listening at 631. I went http://192.158.0.1:631, > I clicked printer and add button, it showed Name, Location, > Description, then there is an add button. From Samba's swat, I could > not find any printer either. I added a printer named cups. Now I do > not know what I should do in cupsd at http://192.168.0.1:631/admin. > When making Samba, I just selected CUPS and no other options and I > choose share for the security options. > Please help to give some hint to make Samba-Cups-pdf writer work! I have this working. In my /usr/local/etc/smb.conf file I have (among other things): [global] printing = CUPS printcap name = cups On the cups side, you have to go through and add the virtual printer through the web interface. Just select "Add New Printer" and follow the prompts. Give it a name, and for "Device" select "Virtual Printer (PDF Printer)". The defaults should be fine for the other screens (it should show "cups-pdf:/" as the device URI). You should then have a CUPS printer which will also be exported (automatically) via Samba. Note that the resulting PDF documents will be stored locally on your print server (in /var/spool/cups-pdf by default), so you should also make that directory available over the network somehow. (Samba is an obvious candidate for your Windows clients.) HTH, JN From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 20:05:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18A5916A407; Sun, 10 Dec 2006 20:05:43 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [64.81.53.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD04243C9D; Sun, 10 Dec 2006 20:04:30 +0000 (GMT) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id 34B5633D6B; Sun, 10 Dec 2006 12:05:35 -0800 (PST) Date: Sun, 10 Dec 2006 12:05:35 -0800 From: Ulf Zimmermann To: "J. Martin Petersen" Message-ID: <20061210200534.GU98520@evil.alameda.net> References: <4578E1AD.3090505@isc.org> <457A9DA0.1020601@alvorlig.dk> <20061209114555.A2273@fledge.watson.org> <20061209185802.GT98520@evil.alameda.net> <457C1140.5040703@alvorlig.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457C1140.5040703@alvorlig.dk> User-Agent: Mutt/1.4.2.1i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: ulf@Alameda.net, freebsd-current@FreeBSD.ORG, Robert Watson , Peter_Losher@isc.org Subject: Re: FreeBSD 6 (or 7) on a HP DL140 G3 SATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2006 20:05:43 -0000 On Sun, Dec 10, 2006 at 02:53:04PM +0100, J. Martin Petersen wrote: > Ulf Zimmermann wrote: > >On Sat, Dec 09, 2006 at 11:47:21AM +0000, Robert Watson wrote: > >>Upgrading proved to be a bit of a pain because the > >>boxes don't have CDROM or floppy drives, and the HP firmware updater > >>download is rather weird, but once it was updated (using a USB floppy > >>drive) all was happiness. > >>Oddly, the i386 loader had no problem at all... > > I think we tried both without success, but I am not 100% sure. > > >Here is how I update the bios on DL140. Create a DOS boot disk (I usual > >use 6.22), put a ramdisk driver on it and whatever you need to flash > >the bios. Then make an image of the disk and load it into your pxe > >server. Boot via PXE said floppy image, copy BIOS flash utils and > >firmware to ramdisk. Then run software from there. If you don't use > >the ram disk, I have seen it fail often. > > We created a bootable USB stick with each of the BIOS'es and used that > to flash with. Very easy and worked like a charm, once we found a > Windows-"enabled" laptop. > > What kind of disk performance are you seeing from the disks hooked up to > the mpt-controller? We are seeing disk transfers around 6MB/sec, which > seems very slow, but I do not know how to diagnose it. We only have some DL140 g1 and one g2. The g2 is running 4.11-REL right now, it was suppose to be a squid box but so far it is just sitting idle. As to upgrading the bios, I went the pxe way, because I did some machines 700 miles that way. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 21:36:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 338C616A47C for ; Sun, 10 Dec 2006 21:36:34 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-3.orange.nl (smtp-3.orange.nl [193.252.22.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F4F43CBF for ; Sun, 10 Dec 2006 21:35:09 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf6212.orange.nl (SMTP Server) with ESMTP id EF09A1C00087 for ; Sun, 10 Dec 2006 22:36:19 +0100 (CET) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6212.orange.nl (SMTP Server) with ESMTP id C5FDE1C00081 for ; Sun, 10 Dec 2006 22:36:19 +0100 (CET) X-ME-UUID: 20061210213619811.C5FDE1C00081@mwinf6212.orange.nl Received: (qmail 37896 invoked from network); 10 Dec 2006 21:36:19 -0000 Received: from 10.66.0.143 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:1(10.66.0.143):. Processed in 0.398791 secs); 10 Dec 2006 21:36:19 -0000 X-Qmail-Scanner-Mail-From: nick@van-laarhoven.org via uitsmijter.van-laarhoven.org X-Qmail-Scanner: 1.25 (Clear:RC:1(10.66.0.143):. Processed in 0.398791 secs) Received: from unknown (HELO van-laarhoven.org) (nick@10.66.0.143) by uitsmijter.van-laarhoven.org with SMTP; 10 Dec 2006 21:36:18 -0000 Received: (nullmailer pid 1339 invoked by uid 1001); Sun, 10 Dec 2006 21:36:17 -0000 Date: Sun, 10 Dec 2006 22:36:17 +0100 (CET) From: Nick Hibma X-X-Sender: nick@localhost To: Marius Strobl In-Reply-To: <20061210152755.GA45265@alchemy.franken.de> Message-ID: <20061210223217.M1174@localhost> References: <20061210110419.H42195@localhost> <20061210152755.GA45265@alchemy.franken.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD CURRENT Mailing List Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 21:36:34 -0000 > I recognise this as the previous watchdog function API with > the extension that when told to disarm via a timeout value > of 0 the watchdog may now report failure to do so by setting > *error, correct? True, see the changes on the manpage. > If so this is fine with the stock mk48txx.c. Yes, that was the one watchdog that followed the sample in the Elan specific code correctly. At first I didn't have the interface change in and that meant changing mk48txx.c and I missed that afterwards I changed everything back to what is was in that driver. > Regarding your changes to watchdog.4 and watchdog.9 AFAICT > they violate the established style guidelines for FreeBSD > man pages; the source should wrap the line on sentence breaks. Is there a manual for man page writing? I've not done much of that yet. Nick From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 21:55:32 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5D3E16A505 for ; Sun, 10 Dec 2006 21:55:32 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-1.orange.nl (smtp-1.orange.nl [193.252.22.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id E219843E4B for ; Sun, 10 Dec 2006 21:48:30 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6006.orange.nl (SMTP Server) with ESMTP id 820B27000082 for ; Sun, 10 Dec 2006 22:49:25 +0100 (CET) X-ME-UUID: 20061210214925532.820B27000082@mwinf6006.orange.nl Received: (qmail 38211 invoked from network); 10 Dec 2006 21:49:25 -0000 Received: from 10.66.0.143 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:1(10.66.0.143):. Processed in 0.406023 secs); 10 Dec 2006 21:49:25 -0000 X-Qmail-Scanner-Mail-From: nick@van-laarhoven.org via uitsmijter.van-laarhoven.org X-Qmail-Scanner: 1.25 (Clear:RC:1(10.66.0.143):. Processed in 0.406023 secs) Received: from unknown (HELO van-laarhoven.org) (nick@10.66.0.143) by uitsmijter.van-laarhoven.org with SMTP; 10 Dec 2006 21:49:24 -0000 Received: (nullmailer pid 1445 invoked by uid 1001); Sun, 10 Dec 2006 21:49:23 -0000 Date: Sun, 10 Dec 2006 22:49:23 +0100 (CET) From: Nick Hibma X-X-Sender: nick@localhost To: Sam Leffler In-Reply-To: <457C48A8.4010703@errno.com> Message-ID: <20061210224138.Y1174@localhost> References: <20061210110419.H42195@localhost> <457C48A8.4010703@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD CURRENT Mailing List Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2006 21:55:32 -0000 >> (*) The i80321_wdog.c cannot be disarmed. Is this correct? >> (**) These have been tested to arm, disarm, and fire. Others have only >> been compile tested. >> >> This change has been tested on 6.2-STABLE and 7-CURRENT. > > FWIW there's another watchdog in xscale/ixp425 for the avila boards. Oops, I missed the watchdogs available in CURRENT: imp at91_st.c ./arm/at91/at91_st.c That one doesn't set *error to error on success. See patch below. ./arm/xscale/ixp425/ixp425_wdog.c Is correct as it is. Index: arm/at91/at91_st.c =================================================================== RCS file: /home/ncvs/src/sys/arm/at91/at91_st.c,v retrieving revision 1.5 diff -u -r1.5 at91_st.c --- arm/at91/at91_st.c 9 Aug 2006 20:58:55 -0000 1.5 +++ arm/at91/at91_st.c 10 Dec 2006 21:47:26 -0000 @@ -170,10 +170,13 @@ uint32_t wdog; int t; - wdog = 0; t = cmd & WD_INTERVAL; - if (cmd != 0 && t >= 22 && t <= 37) + if (cmd != 0 && t >= 22 && t <= 37) { wdog = (1 << (t - 22)) | ST_WDMR_RSTEN; + *error = 0; + } else { + wdog = 0; + } WR4(ST_WDMR, wdog); WR4(ST_CR, ST_CR_WDRST); } From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 21:57:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E24B216A501 for ; Sun, 10 Dec 2006 21:57:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 729E243FA5 for ; Sun, 10 Dec 2006 21:52:46 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 30483 invoked by uid 399); 10 Dec 2006 21:53:47 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 10 Dec 2006 21:53:47 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <457C81E9.7040806@FreeBSD.org> Date: Sun, 10 Dec 2006 13:53:45 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061125) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Socket problems with latest -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, 10 Dec 2006 21:57:33 -0000 With sources cvsup'ed around 20:35 PST on 8 December everything works just fine. With sources cvsup'ed early this morning, 12:42 am PST on 10 December, I'm getting a lot of errors related to sockets: Dec 10 13:44:20 lap sm-mta[634]: NOQUEUE: SYSERR(root): opendaemonsocket: daemon Daemon0: cannot bind: Can't assign requested address Dec 10 13:44:20 lap sm-mta[634]: daemon Daemon0: problem creating SMTP socket This is on a Core 2 Duo running i386. I'm also having problems with amd, named, etc. Any suggestions on where to look? Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 04:11:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F19C716A415 for ; Mon, 11 Dec 2006 04:11:05 +0000 (UTC) (envelope-from eprha.carvajal@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2861943C9E for ; Mon, 11 Dec 2006 04:09:51 +0000 (GMT) (envelope-from eprha.carvajal@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1345339wxc for ; Sun, 10 Dec 2006 20:11:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=kyclUkzBcZ80M+aU77Z/YD5rc+LQN1WOcQuaMn6+V9RwX3wK0axi8Q4uDaWNODI3c1z45yk8ZGYHWwas1qsoB9zukTx6bA9h2Glt/f5ktCgYUrkfL5c65maShetwjNSrDIy1/DjQsLpJ1VbpHPz6P/la0KiYD6UpXTHXGh1/5Qw= Received: by 10.70.125.11 with SMTP id x11mr11513915wxc.1165810264284; Sun, 10 Dec 2006 20:11:04 -0800 (PST) Received: by 10.70.7.9 with HTTP; Sun, 10 Dec 2006 20:11:04 -0800 (PST) Message-ID: Date: Mon, 11 Dec 2006 00:11:04 -0400 From: "Eprha Carvajal" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: New Challenges ( FreeBSD on PS3 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 04:11:06 -0000 I was wondering if anyone though of installing FreeBSD in a PS3, i'm sure there are some big challanges there. The Hardware seems to be extremely powerful and there is people running different linux flavors on it. There is a lot to be done there, the cell processor will probably require a long term effort, the blue ray device drivers, keyboard and mouse are USB so i don't think that will be a problem for BSD, the video card is designed for the PS3, will NVIDIA provide support as before, not sure. In other words this is a new architecture. Some of the questions i have right now are: Is possible to the Sony/IBM/Toshiba documents for the Cell Processor ? Is there any specific linux patch set for the PS3 ? ( Looks like there is none, will have more info once i try both installs ) What is the approach of LINUX with the cell processor and the 8 cores ? The NVIDIA RSX video Card was designed for the PS3, any chance they will support this ? I'm receiving one next weekend and i was wondering if there is a group of developers thinking on this, i will love to see FreeBSD running in a cell processor. Comments are appreciated. Regards Eprha From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 04:44:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A4FE16A417 for ; Mon, 11 Dec 2006 04:44:05 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id E08FD43CA8 for ; Mon, 11 Dec 2006 04:42:49 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so1793791nfc for ; Sun, 10 Dec 2006 20:44:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eDjHYDQIRMEdG5GahTFa+StzKTV5HbS4lE6vxz4j2hBVKDD5kmpV8dQ48bxavKXGabMm91UzKhFbVLpyxl2zyvwwjSjgy2xngyhI2NmdruGSG4nRoqiNuEdmFiVJcLlY+El8wdbTHRZoFx0tV49QmLhvfoFJXQa/GBo2IfmIgcs= Received: by 10.82.126.5 with SMTP id y5mr262736buc.1165812241924; Sun, 10 Dec 2006 20:44:01 -0800 (PST) Received: by 10.82.151.10 with HTTP; Sun, 10 Dec 2006 20:44:01 -0800 (PST) Message-ID: Date: Sun, 10 Dec 2006 20:44:01 -0800 From: "Kip Macy" To: "Eprha Carvajal" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: New Challenges ( FreeBSD on PS3 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 04:44:05 -0000 I'd love to see it happen although I don't think anyone is thinking about it. I saw an article indicating that Sony had put the code for it back in the main linux tree. Working from docs is a lot more fun, this looks like your best bet: http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F On 12/10/06, Eprha Carvajal wrote: > > I was wondering if anyone though of installing FreeBSD in a PS3, i'm sure > there are some big challanges there. > > The Hardware seems to be extremely powerful and there is people running > different linux flavors on it. > > There is a lot to be done there, the cell processor will probably require > a > long term effort, the blue ray device drivers, keyboard and mouse are USB > so > i don't think that will be a problem for BSD, the video card is designed > for > the PS3, will NVIDIA provide support as before, not sure. > > In other words this is a new architecture. > > Some of the questions i have right now are: > > Is possible to the Sony/IBM/Toshiba documents for the Cell Processor ? > Is there any specific linux patch set for the PS3 ? ( Looks like there is > none, will have more info once i try both installs ) > What is the approach of LINUX with the cell processor and the 8 cores ? > The NVIDIA RSX video Card was designed for the PS3, any chance they will > support this ? > > I'm receiving one next weekend and i was wondering if there is a group of > developers thinking on this, i will love to see FreeBSD running in a cell > processor. > > Comments are appreciated. > > Regards > > Eprha > _______________________________________________ > 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 Dec 11 06:06:05 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DAFB16A40F for ; Mon, 11 Dec 2006 06:06:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F23943C9D for ; Mon, 11 Dec 2006 06:04:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kBB65PrO084144; Sun, 10 Dec 2006 23:05:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 10 Dec 2006 23:06:22 -0700 (MST) Message-Id: <20061210.230622.-1844001233.imp@bsdimp.com> To: peo@intersonic.se From: "M. Warner Losh" In-Reply-To: <4579EB08.8080704@intersonic.se> References: <4579EB08.8080704@intersonic.se> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 10 Dec 2006 23:05:26 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 06:06:05 -0000 In message: <4579EB08.8080704@intersonic.se> Per olof Ljungmark writes: : Am I an idiot or is anyone else out there running -current on production : systems? I figured if one MX goes haywire at least we've got another : one... Very interested in your opinion. People use -current on production servers. But not just any old version of -current. Rather, carefully selected versions of -current that have been validated and tested. The -stable branches are a lot more likely to be suitabe for a server, but -current can be useful. However, be prepared to compile everything yourself. Also be prepared to do it again when you upgrade. While you may get a stable system out of it, you are signing up for the "I know what I'm doing club" and the bar to enter that club is a lot higher than the "I run stable club." It isn't recommended by the project, since at any given moment -current may be useful or it may have some horrible bug and the waters are a lot choppier. Warner From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 06:12:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9E7616A47E for ; Mon, 11 Dec 2006 06:12:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2683D43CA7 for ; Mon, 11 Dec 2006 06:10:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kBB6AelQ084169; Sun, 10 Dec 2006 23:10:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 10 Dec 2006 23:11:37 -0700 (MST) Message-Id: <20061210.231137.-1749707382.imp@bsdimp.com> To: marius@alchemy.franken.de From: "M. Warner Losh" In-Reply-To: <20061209210629.GG86517@alchemy.franken.de> References: <20061209185539.GA34399@alchemy.franken.de> <20061209201438.B42195@localhost> <20061209210629.GG86517@alchemy.franken.de> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 10 Dec 2006 23:10:41 -0700 (MST) Cc: nick@van-laarhoven.org, current@freebsd.org Subject: Re: mk48txx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 06:12:08 -0000 In message: <20061209210629.GG86517@alchemy.franken.de> Marius Strobl writes: : On Sat, Dec 09, 2006 at 08:19:29PM +0100, Nick Hibma wrote: : > >On platforms which don't use genclock(4), yet, sys/kern/subr_rtc.c : > >will clash with the MD RTC driver, f.e. with sys/i386/isa/clock.c. : > >So far mk48txx(4) is only used on FreeBSD/sparc64 and requires : > >eeprom(4) and genclock(4) to be actually usable. For compile- : > >testing changes to mk48txx(4) on another platform, cross-compiling : > >the sparc64 GENERIC is probably the simplest approach. : > >AFAICT the reset pin of the MK48Txx watchdog is only connected to : > >something in Sun E250, E450 and Exx00 but one can actually test : > >the watchdog support in the driver in any sun4u machine where : > >eeprom(4) attaches by observing the MK48TXX_FLAGS_WDF bit. : > : > Sun? Enlightning. : > : > >>What's it do anyway? No manpage. : > > : > >I didn't get around to adapt the NetBSD mk48txx.4 so far but : > >the user point of view is covered by eeprom.4. : > : > I would like to suggest that you spend two hours putting in a very basic : > man page. Rip out the guts of an existing one and fill in the blanks : > with a few details. It makes the driver so much more finished and it : > might just be that someone updates the page. : : I favor having no man page over having something incomplete : or inadequate like f.e. esp.4 or bus_space.9 as IMO wrong : information can confuse way more and leaves a worse impression : than no information at all. bus_space.9 isn't incomplete. The problem is that it is too complete and general, if anything. It is hard to penetrate. Warner From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 06:21:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C071D16A403 for ; Mon, 11 Dec 2006 06:21:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AFBE43CA6 for ; Mon, 11 Dec 2006 06:19:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kBB6JiNI084215; Sun, 10 Dec 2006 23:19:44 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 10 Dec 2006 23:20:41 -0700 (MST) Message-Id: <20061210.232041.221854090.imp@bsdimp.com> To: nick@van-laarhoven.org From: "M. Warner Losh" In-Reply-To: <20061210224138.Y1174@localhost> References: <20061210110419.H42195@localhost> <457C48A8.4010703@errno.com> <20061210224138.Y1174@localhost> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 10 Dec 2006 23:19:47 -0700 (MST) Cc: current@freebsd.org Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 06:21:07 -0000 In message: <20061210224138.Y1174@localhost> Nick Hibma writes: : >> (*) The i80321_wdog.c cannot be disarmed. Is this correct? : >> (**) These have been tested to arm, disarm, and fire. Others have only : >> been compile tested. : >> : >> This change has been tested on 6.2-STABLE and 7-CURRENT. : > : > FWIW there's another watchdog in xscale/ixp425 for the avila boards. : : Oops, I missed the watchdogs available in CURRENT: : : imp at91_st.c : : ./arm/at91/at91_st.c : That one doesn't set *error to error on success. See patch below. I wasn't aware of that requirement... : ./arm/xscale/ixp425/ixp425_wdog.c : Is correct as it is. : : Index: arm/at91/at91_st.c : =================================================================== : RCS file: /home/ncvs/src/sys/arm/at91/at91_st.c,v : retrieving revision 1.5 : diff -u -r1.5 at91_st.c : --- arm/at91/at91_st.c 9 Aug 2006 20:58:55 -0000 1.5 : +++ arm/at91/at91_st.c 10 Dec 2006 21:47:26 -0000 : @@ -170,10 +170,13 @@ : uint32_t wdog; : int t; : : - wdog = 0; : t = cmd & WD_INTERVAL; : - if (cmd != 0 && t >= 22 && t <= 37) : + if (cmd != 0 && t >= 22 && t <= 37) { : wdog = (1 << (t - 22)) | ST_WDMR_RSTEN; : + *error = 0; : + } else { : + wdog = 0; : + } : WR4(ST_WDMR, wdog); : WR4(ST_CR, ST_CR_WDRST); : } Go ahead and commit this. I can do it if you'd like. Warner From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 06:39:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6AEC16A415 for ; Mon, 11 Dec 2006 06:39:49 +0000 (UTC) (envelope-from ph.schulz@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 165EC43CAD for ; Mon, 11 Dec 2006 06:38:33 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: (qmail invoked by alias); 11 Dec 2006 06:39:47 -0000 Received: from dslb-084-056-249-215.pools.arcor-ip.net (EHLO [192.168.1.6]) [84.56.249.215] by mail.gmx.net (mp048) with SMTP; 11 Dec 2006 07:39:47 +0100 X-Authenticated: #1954550 Message-ID: <457CFD31.9000603@gmx.de> Date: Mon, 11 Dec 2006 07:39:45 +0100 From: "Philip S. Schulz" User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Eprha Carvajal References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org Subject: Re: New Challenges ( FreeBSD on PS3 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 06:39:49 -0000 on 11.12.2006 5:11 Uhr Eprha Carvajal said the following: > > Is possible to the Sony/IBM/Toshiba documents for the Cell Processor ? > Is there any specific linux patch set for the PS3 ? ( Looks like there is > none, will have more info once i try both installs ) > What is the approach of LINUX with the cell processor and the 8 cores ? > The NVIDIA RSX video Card was designed for the PS3, any chance they will > support this ? > The Cell Processer consists of PPE, a 64-Bit Power-core very similar to the PowerPC 970 (aka "G5") and eight so-called SPEs, which are SIMD units with local memory. You can run code compiled for the 970 directly and w/o any modifications on the PPE but with some performance loss. Linux uses the Power core to run the operating system and normal, non-Cell-aware applications. It provides SPUfs [1] which allows application developers to use the SPEs. The SPUfs is in the Linux tree it seems, so that could serve as "documentation" but I'm not sure right now if there is public documentation for the SPEs. In order to run FreeBSD on the Cell you'd need a working port for the PowerPC 970 CPU plus possibly some extra bits in order to be able to boot on the PS3. HTH, Phil. [1] http://www-128.ibm.com/developerworks/power/library/pa-cell/ -- Don't fix it if it ain't broke. From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 09:29:02 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8ACE816A403 for ; Mon, 11 Dec 2006 09:29:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C2BA43CA7 for ; Mon, 11 Dec 2006 09:27:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C312046E99; Mon, 11 Dec 2006 04:29:01 -0500 (EST) Date: Mon, 11 Dec 2006 09:29:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "J. Martin Petersen" In-Reply-To: <457C1140.5040703@alvorlig.dk> Message-ID: <20061211092808.U62822@fledge.watson.org> References: <4578E1AD.3090505@isc.org> <457A9DA0.1020601@alvorlig.dk> <20061209114555.A2273@fledge.watson.org> <20061209185802.GT98520@evil.alameda.net> <457C1140.5040703@alvorlig.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.ORG, ulf@Alameda.net, Peter_Losher@isc.org Subject: Re: FreeBSD 6 (or 7) on a HP DL140 G3 SATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 09:29:02 -0000 On Sun, 10 Dec 2006, J. Martin Petersen wrote: > Ulf Zimmermann wrote: >> On Sat, Dec 09, 2006 at 11:47:21AM +0000, Robert Watson wrote: >>> Upgrading proved to be a bit of a pain because the boxes don't have CDROM >>> or floppy drives, and the HP firmware updater download is rather weird, >>> but once it was updated (using a USB floppy drive) all was happiness. >>> Oddly, the i386 loader had no problem at all... > > I think we tried both without success, but I am not 100% sure. > >> Here is how I update the bios on DL140. Create a DOS boot disk (I usual use >> 6.22), put a ramdisk driver on it and whatever you need to flash the bios. >> Then make an image of the disk and load it into your pxe server. Boot via >> PXE said floppy image, copy BIOS flash utils and firmware to ramdisk. Then >> run software from there. If you don't use the ram disk, I have seen it fail >> often. > > We created a bootable USB stick with each of the BIOS'es and used that to > flash with. Very easy and worked like a charm, once we found a > Windows-"enabled" laptop. > > What kind of disk performance are you seeing from the disks hooked up to the > mpt-controller? We are seeing disk transfers around 6MB/sec, which seems > very slow, but I do not know how to diagnose it. I'm only using ATA RAID on my boxes, so can't comment on that, sorry! These boxes are primarily used for 10gbps network testing, not storage testing... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 09:35:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7229916A417 for ; Mon, 11 Dec 2006 09:35:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 7654043CB6 for ; Mon, 11 Dec 2006 09:34:04 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 28871 invoked by uid 399); 11 Dec 2006 09:35:19 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 11 Dec 2006 09:35:19 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <457D2655.9050500@FreeBSD.org> Date: Mon, 11 Dec 2006 01:35:17 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061125) MIME-Version: 1.0 To: hrs@FreeBSD.org References: <457C81E9.7040806@FreeBSD.org> In-Reply-To: <457C81E9.7040806@FreeBSD.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, re@freebsd.org Subject: Re: Socket problems with latest -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, 11 Dec 2006 09:35:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doug Barton wrote: > With sources cvsup'ed around 20:35 PST on 8 December everything works > just fine. With sources cvsup'ed early this morning, 12:42 am PST on > 10 December, I'm getting a lot of errors related to sockets: I found the problem, it's the change made in version 1.4 of rc.d/auto_linklocal. Reverting only that change, and using otherwise up to date -current sources allows things to work just fine. Adding that change on the same exact system causes the breakage I described in my previous message. It's probably worth mentioning that I exactly fit the criteria from the 1.4 commit message, I have INET6 in my kernel, but at the moment I have ipv6_enable=no in rc.conf. This change should be backed out of HEAD and RELENG_6[_2] until the cause of this breakage is understood. Doug - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFfSZUyIakK9Wy8PsRAhwVAKCBNyHhJ4Hme0DyjQYSwJTUYVzaWACfaYUf qxtAyyP3VBc9SIfi4uhBEsg= =OvOO -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 10:12:49 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7FC516A417 for ; Mon, 11 Dec 2006 10:12:49 +0000 (UTC) (envelope-from casper@web.am) Received: from mx1.web.am (mx1.web.am [217.113.0.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99EE443D67 for ; Mon, 11 Dec 2006 10:10:58 +0000 (GMT) (envelope-from casper@web.am) Received: from antispam (localhost.web.am [127.0.0.1]) by localhost (Postfix) with ESMTP id 4CFFB62D2F for ; Mon, 11 Dec 2006 14:11:13 +0400 (AMT) Received: from localhost (localhost.web.am [127.0.0.1]) by localhost (Postfix) with SMTP id 7E2AB62340; Mon, 11 Dec 2006 13:52:14 +0400 (AMT) Received: from [192.168.0.3] (unknown [217.113.1.123]) by mx1.web.am (Postfix) with ESMTP id 59CB461F25; Mon, 11 Dec 2006 11:04:54 +0400 (AMT) Message-ID: <457D033C.2000307@web.am> Date: Mon, 11 Dec 2006 11:05:32 +0400 From: Gaspar Chilingarov User-Agent: Thunderbird 2.0a1 (X11/20061118) MIME-Version: 1.0 To: Per olof Ljungmark References: <4579EB08.8080704@intersonic.se> In-Reply-To: <4579EB08.8080704@intersonic.se> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.web.am X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.60 X-Spam-Level: Cc: freebsd-current@FreeBSD.ORG Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 10:12:49 -0000 Per olof Ljungmark wrote: > Hi all, > > We're running around 25 FBSD servers, mostly 6 and a few 5-STABLE. For a > few months, we also run our internal storage/smb/whatnot machine on > -current. Never had ANY issues. Just works, and better than 6-*. > > Now, we are about to replace our MX's and I'm thinking of deploying > -current on them instead of upcoming 6.2. Right now running tests on the > hardware, two ProLiant DL360G3 cpu's and everything looks just fine. > > Am I an idiot or is anyone else out there running -current on production > systems? I figured if one MX goes haywire at least we've got another > one... Very interested in your opinion. > > Thanks /per At least it's fun to run -current on production servers :) In case if you can have hot-swap server to test upgrades there and you carefully watch this mailing list and can suspect which things will break after each upgrade and which - not, it's OK. Especially if you run opensource software, which can be recompiled at any moment, and you can easility change servers without disturbing working environment - why not? -- Gaspar Chilingarov System Administrator, Network security consulting t +37493 419763 (mob) i 63174784 e nm@web.am From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 10:37:43 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D18716A47B; Mon, 11 Dec 2006 10:37:43 +0000 (UTC) (envelope-from yal@yal.hopto.org) Received: from vsmtp3.tin.it (vsmtp3alice.tin.it [212.216.176.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id B197443CF8; Mon, 11 Dec 2006 10:34:59 +0000 (GMT) (envelope-from yal@yal.hopto.org) Received: from koala.unime.lan (87.11.169.84) by vsmtp3.tin.it (7.2.072.1) id 456AB7910054ADA6; Mon, 11 Dec 2006 11:33:15 +0100 Received: from koala.unime.lan (localhost [127.0.0.1]) by koala.unime.lan (8.13.8/8.13.8) with ESMTP id kBBAMMST021625 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 11 Dec 2006 11:22:23 +0100 (CET) (envelope-from yal@yal.hopto.org) Received: (from www@localhost) by koala.unime.lan (8.13.8/8.13.8/Submit) id kBBAML18021624; Mon, 11 Dec 2006 11:22:21 +0100 (CET) (envelope-from yal@yal.hopto.org) X-Authentication-Warning: koala.unime.lan: www set sender to yal@yal.hopto.org using -f Received: from 87.11.169.84 (SquirrelMail authenticated user yal) by yal.hopto.org with HTTP; Mon, 11 Dec 2006 11:22:20 +0100 (CET) Message-ID: <4489.87.11.169.84.1165832540.squirrel@yal.hopto.org> Date: Mon, 11 Dec 2006 11:22:20 +0100 (CET) From: "yal" To: "Robert Watson" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@FreeBSD.org Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yal@yal.hopto.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2006 10:37:43 -0000 On Mon, December 11, 2006 10:27, Robert Watson wrote: > > > Sam has committed changes to if_wi in the last 24 hours that may fix this > problem with the default net.isr.direct setting. Could you try updating > to > these changes, removing net.isr.direct=0, and seeing what happens? Dell Latitude D520 comes equipped with an Intel 3945g which is still unsupported. So I'm using a beta driver by Bergamini, who as far as I know abandoned the development early this year. http://damien.bergamini.free.fr/wpi-freebsd.tgz - yal From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 11:03:31 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9D0016A4D2 for ; Mon, 11 Dec 2006 11:03:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCF8943EFA for ; Mon, 11 Dec 2006 10:59:17 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 058DA46E35 for ; Mon, 11 Dec 2006 06:00:28 -0500 (EST) Date: Mon, 11 Dec 2006 11:00:27 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20061211110009.K62822@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: CURRENT freezes on Laitude D520 (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 11:03:32 -0000 Retransmit due to bad CC. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 11 Dec 2006 09:27:56 +0000 (GMT) From: Robert Watson To: yal Cc: freebsd-current-request@FreeBSD.org Subject: Re: CURRENT freezes on Laitude D520 On Sun, 10 Dec 2006, yal wrote: > On Sun, December 10, 2006 13:57, Robert Watson wrote: > >>>> - Try setting net.isr.direct=0 and see if the problem goes away. >>> >>> This indeed help. LOR has gone and wireless works. > >> result in a deadlock under other circumstances, net.isr.direct makes the >> chances of that deadlock much greater. > > It helped on Latutide D520 as well. No freeze or anything anymore. Top shows > now 100% idle most of the time. The debug.mpsafent="0" has been deleted, as > suggested. Thanks to Robert N. M. Watson. Sam has committed changes to if_wi in the last 24 hours that may fix this problem with the default net.isr.direct setting. Could you try updating to these changes, removing net.isr.direct=0, and seeing what happens? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 11:14:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A5F516A529 for ; Mon, 11 Dec 2006 11:14:01 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id D54C94402D for ; Mon, 11 Dec 2006 11:05:48 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id kBBB6v0g020819; Mon, 11 Dec 2006 11:06:57 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.8/8.13.6) with ESMTP id kBBB6ueb006662; Mon, 11 Dec 2006 11:06:56 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.8/8.13.6/Submit) id kBBB6uOB006661; Mon, 11 Dec 2006 11:06:56 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Eprha Carvajal In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 11 Dec 2006 11:06:56 +0000 Message-Id: <1165835216.1373.9.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org Subject: Re: New Challenges ( FreeBSD on PS3 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 11:14:01 -0000 On Mon, 2006-12-11 at 00:11 -0400, Eprha Carvajal wrote: > I was wondering if anyone though of installing FreeBSD in a PS3, i'm sure > there are some big challanges there. This is something I've been looking at for a few days. As already mentioned, a Cell is basically a dual threaded POWER chip, so I suspect FreeBSD/ppc is the place to start, as these processors are quite similar. You can ignore the SPEs for now. As I understand it, PS3 uses OpenFirmware, so you may be able to get it booting over the network and stuff easily, depending on how complete the implementation is. A Cell emulator exists, so access to real hardware may not be necessary. Although, it may be worthwhile somebody able to speak for FreeBSD approaching IBM and trying to get one of their Cell-based blade servers, for testing. I'm guessing it will be a lot easier, and more beneficial in the long run to start there than start with a PS3. Linux code is at http://lxr.linux.no/source/arch/powerpc/platforms/cell/?v=2.6.18 Gavin From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 07:59:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A3EF16A403 for ; Mon, 11 Dec 2006 07:59:31 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C48B643CA5 for ; Mon, 11 Dec 2006 07:58:15 +0000 (GMT) (envelope-from amistry@am-productions.biz) Received: from [192.168.1.100] (cpe-24-210-75-119.columbus.res.rr.com [24.210.75.119]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id kBB8K6ao077639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Dec 2006 03:20:13 -0500 (EST) (envelope-from amistry@am-productions.biz) From: Anish Mistry Organization: AM Productions To: freebsd-current@freebsd.org Date: Mon, 11 Dec 2006 03:00:41 -0500 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1789224.turjmvTa26"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612110300.51432.amistry@am-productions.biz> X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,MYFREEBSD2, RCVD_IN_NJABL_DUL,SPF_SOFTFAIL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.5/2314/Sun Dec 10 15:02:13 2006 on mail.united-ware.com X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 11 Dec 2006 12:45:41 +0000 Subject: dcons kldunload panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 07:59:31 -0000 --nextPart1789224.turjmvTa26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This is probably one of those "don't do that" problems. I can=20 reliably panic my -CURRENT system by having dcons setup then doing=20 the following: kldunload fireware kldunload dcons kill And then I get this panic, the message seems corrupt and adding the=20 dcons symbols file doesn't seem to help. #0 doadump () at pcpu.h:166 #1 0xc0444e2a in db_fncall (dummy1=3D-1068514612, dummy2=3D0, dummy3=3D1,= =20 dummy4=3D0xcc82e908 "") at /usr/src/sys/ddb/db_command.c:486 #2 0xc0445105 in db_command_loop ()=20 at /usr/src/sys/ddb/db_command.c:401 #3 0xc0446d13 in db_trap (type=3D3, code=3D0)=20 at /usr/src/sys/ddb/db_main.c:222 #4 0xc04fc6eb in kdb_trap (type=3D3, code=3D0, tf=3D0x0) at /usr/src/sys/kern/subr_kdb.c:502 #5 0xc061207c in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -1038531312, tf_= esi=20 =3D -1067202952, tf_ebp =3D -863835460, tf_isp =3D -863835480, tf_ebx=20 =3D -863835420, tf_edx =3D -1067199496, tf_ecx =3D -1056878592, tf_eax=20 =3D -1067189541, tf_trapno =3D 3, tf_err =3D 0, tf_eip =3D -1068514612, tf_= cs=20 =3D 32, tf_eflags =3D 646, tf_esp =3D -863835432, tf_ss =3D -1068646766})=20 at /usr/src/sys/i386/i386/trap.c:622 #6 0xc060244a in calltrap ()=20 at /usr/src/sys/i386/i386/exception.s:138 #7 0xc04fc2cc in kdb_enter (msg=3D0xc063fadb "KDB: enter: %s\n") at=20 cpufunc.h:60 #8 0xc04dbe92 in panic ( fmt=3D0xc063c678 "_mtx_lock_sleep: recursed on non-recursive=20 mutex %s @ %s:%d\n") at /usr/src/sys/kern/kern_shutdown.c:551 #9 0xc04d3746 in _mtx_lock_sleep (m=3D0xc06a4284, tid=3D3227783745,=20 opts=3D0,=20 file=3D0xc0641241 "/usr/src/sys/kern/subr_unit.c", line=3D719) at /usr/src/sys/kern/kern_mutex.c:294 #10 0xc04d37c3 in _mtx_lock_flags (m=3D0xc1015000, opts=3D0,=20 file=3D0xc0641241 "/usr/src/sys/kern/subr_unit.c", line=3D719) =2D--Type to continue, or q to quit--- at /usr/src/sys/kern/kern_mutex.c:138 #11 0xc05076e9 in free_unr (uh=3D0xc1c08d00, item=3D31) at /usr/src/sys/kern/subr_unit.c:719 #12 0xc0486612 in devfs_free (cdev=3D0xc063fadb) at /usr/src/sys/fs/devfs/devfs_devs.c:144 #13 0xc04b4d54 in destroy_devl (dev=3D0xc1c4d800) at /usr/src/sys/kern/kern_conf.c:712 #14 0xc04b4db3 in destroy_dev (dev=3D0xc1c4d800) at /usr/src/sys/kern/kern_conf.c:721 #15 0xc093d7b3 in ?? () #16 0xc1c4d800 in ?? () #17 0xc093ed20 in ?? () #18 0x00000000 in ?? () #19 0x0000005c in ?? () #20 0xc093da21 in ?? () #21 0x00000019 in ?? () #22 0x00000000 in ?? () #23 0xc1bfab80 in ?? () #24 0xcc82ec04 in ?? () #25 0xc093d92a in ?? () #26 0xc093eae0 in ?? () #27 0xc093ed88 in ?? () #28 0x00000000 in ?? () =2D--Type to continue, or q to quit--- #29 0xc093da42 in ?? () #30 0x00000000 in ?? () #31 0xc1bfab80 in ?? () #32 0xcc82ec20 in ?? () #33 0xc04d2d72 in module_unload (mod=3D0xc1c4d800, flags=3D-1064047224) at /usr/src/sys/kern/kern_module.c:244 Previous frame inner to this frame (corrupt stack?) =2D-=20 Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ --nextPart1789224.turjmvTa26 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFfRAzxqA5ziudZT0RAhstAJ9lLpUlGmMIfyiLWc5BkCJTSVY7SQCeL5Ry chX94suGBx6QaCLYMRAlYaY= =3Xrt -----END PGP SIGNATURE----- --nextPart1789224.turjmvTa26-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 13:50:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 079FB16A40F; Mon, 11 Dec 2006 13:50:44 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC8C43D36; Mon, 11 Dec 2006 13:49:07 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 7FAE18C9D8F; Mon, 11 Dec 2006 21:50:14 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 6AB1A8C9D8B; Mon, 11 Dec 2006 21:50:14 +0800 (CST) Date: Mon, 11 Dec 2006 21:50:14 +0800 (CST) From: Tai-hwa Liang To: Robert Watson In-Reply-To: <20061210084254.X9926@fledge.watson.org> Message-ID: <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 13:50:44 -0000 On Sun, 10 Dec 2006, Robert Watson wrote: > > On Sun, 10 Dec 2006, Tai-hwa Liang wrote: > >>> which get a bit more to the heart of most problems. debug.mpsafenet=1 >>> really exists for the purposes of supporting components which are not >>> sufficiently locked to allow the stack to run MPSAFE, rather than as a >>> means of disabling direct dispatch and preemption, which speak to >>> different types of problems. The main reason that I haven't removed the >>> administrator tunable to date is that I suspect it will be quite helpful >>> when KAME IPSEC locking happens, but since that appears not to have >>> happened yet, debug.mpsafenet as an option is likely causing more harm >>> than good by being available as a stand-in sysctl masking other problems, >>> causing people to not get to the point of properly identifying the actual >>> cause (device driver bugs, etc). >> >> Can the aforementioned tricks(1/2/3) being applied to RELENG_6 as well? > > WITNESS is available in RELENG_6, and should be used in combination with > INVARIANTS, DDB, KDB, and BREAK_TO_DEBUGGER to debug deadlocks. Would a kernel with WITNESS/[KD]DB/BREAK_TO_DEBUGGER enabled but w/o INVARIANTS compiled adequate to dump useful information through remote serial console? > In RELENG_6, net.isr.direct is not enabled by default, so unless you've > enabled it yourself (or are using IP fast forwarding, which is functionally > similar), that won't apply. > > In RELENG_6, PREEMPTION is in GENERIC and hence enabled by default, and it > can be disabled by removing it from your kernel configuration. I'd like it > if we could add a run-time sysctl to disable preemption even if PREEMPTION is > compiled in, as it would make it easier to explore its stability and > performance impact. However, this is also just a debugging step to see if > that quiesces the problem, and not a fix for the actual bug. > > Right now, we're discussing removing the manual debug.mpsafenet configuration > flag from 7.x, and not 6.x. I fully recognize the importance of having it in > place as a workaround for bugs in production, although it concerns me greatly > that we're not getting these problems debugged and fixed, and instead masking > them. Architectural changes are on the way that will require these bugs to > be fixed properly, not just masked. > >> We are using RELENG_6 as our production server(postfix, squid, pf >> firewall/NAT, FAST_IPSEC VPN, ...), which is a dual Athlon MP board with >> three NICs(two fxp cards and one onboard xl, connected to three different >> networks). >> >> I haven't try WITNESS, yet; however, I'm very sure that net.isr.direct=0 >> plus that there is no PREEMPTION in current kernel. The problem is that, >> with debug.mpsafenet=1, we'll always run into hard freeze w/o having any >> kdb> prompt on console. >> >> Whilst turning debug.mpsafenet off only masks the real problem, I'm still >> wondering about if there is any less damaging way to track such problem >> down in a _production_ environment. > > It sounds like you need to follow the instructions for kernel debugging. > Depending on your tolerance of performance loss, downtime, etc, a good > starting point is to configure the kernel with INVARIANTS and WITNESS. > WITNESS is particularly important, if you can tolerate the performance hit, > as it warns of potential deadlocks, not just actual deadlocks. Also, compile With WITNESS enabled(debug.mpsafenet=0), I got another three pf related warnings in the last 8 hours: # # this one looks like lor#046; however, I'm not sure if it is safe to drop # pf_task_mtx with PF_UNLOCK before invoking pf_test() in pf_check_out(). # lock order reversal: 1st 0xc06fca2c tcp (tcp) @ netinet/tcp_input.c:625 2nd 0xc69a1060 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6386 KDB: stack backtrace: kdb_backtrace(ffffffff,c06bc0d0,c06ba6b8,c06847a4,c06f8b00,...) at kdb_backtrace+0x29 witness_checkorder(c69a1060,9,c699e609,18f2) at witness_checkorder+0x4cd _mtx_lock_flags(c69a1060,0,c699e609,18f2,0,...) at _mtx_lock_flags+0x1e pf_test(2,c64c6800,e4f6cae0,0,0,...) at pf_test+0x6b pf_check_out(0,e4f6cae0,c64c6800,2,0,...) at pf_check_out+0x3d pfil_run_hooks(c06fc5e0,e4f6cb5c,c64c6800,2,0,...) at pfil_run_hooks+0xb3 ip_output(c64e0300,0,e4f6cb28,0,0,...) at ip_output+0x75e tcp_respond(0,c650a030,c650a044,c64e0300,eb232182,0,14) at tcp_respond+0x22a tcp_input(c64e0300,14,8,121245cb,1,...) at tcp_input+0x2559 ip_input(c64e0300) at ip_input+0x729 netisr_processqueue(c06fa298) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x8c ithread_execute_handlers(c63ff430,c644a080) at ithread_execute_handlers+0xce ithread_loop(c63b6b10,e4f6cd38,c06aafc0,0,c06514db,...) at ithread_loop+0x4f fork_exit(c04dd70c,c63b6b10,e4f6cd38) at fork_exit+0x61 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f6cd6c, ebp = 0 --- lock order reversal: 1st 0xc6b3984c inp (tcpinp) @ netinet/tcp_usrreq.c:368 2nd 0xc69a1060 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6386 KDB: stack backtrace: kdb_backtrace(ffffffff,c06bc0a8,c06ba6b8,c06847a4,c06f8b38,...) at kdb_backtrace+0x29 witness_checkorder(c69a1060,9,c699e609,18f2) at witness_checkorder+0x4cd _mtx_lock_flags(c69a1060,0,c699e609,18f2,0,...) at _mtx_lock_flags+0x1e pf_test(2,c6568800,e8ef7b40,0,c6b397bc,...) at pf_test+0x6b pf_check_out(0,e8ef7b40,c6568800,2,c6b397bc,...) at pf_check_out+0x3d pfil_run_hooks(c06fc5e0,e8ef7bbc,c6568800,2,c6b397bc,...) at pfil_run_hooks+0xb3 ip_output(c66d3400,0,e8ef7b88,0,0,c6b397bc) at ip_output+0x75e tcp_output(c6cf8740) at tcp_output+0xd51 tcp_usr_connect(c6ca242c,c6c25260,c6b48600) at tcp_usr_connect+0xe3 soconnect(c6ca242c,c6c25260,c6b48600) at soconnect+0x4e kern_connect(c6b48600,4,c6c25260,c6c25260,0,...) at kern_connect+0xbb connect(c6b48600,e8ef7d04) at connect+0x2f syscall(3b,3b,3b,804f380,80521a0,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x28126fbf, esp = 0xbfbfd26c, ebp = 0xbfbfd3d8 --- lock order reversal: 1st 0xc6d667d0 ipsec request (ipsec request) @ netipsec/xform_esp.c:897 2nd 0xc69a1060 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6386 KDB: stack backtrace: kdb_backtrace(ffffffff,c06ba4b0,c06ba6b8,c06847a4,c06f8ac8,...) at kdb_backtrace+0x29 witness_checkorder(c69a1060,9,c699e609,18f2) at witness_checkorder+0x4cd _mtx_lock_flags(c69a1060,0,c699e609,18f2,0,...) at _mtx_lock_flags+0x1e pf_test(2,c64c6800,e4f6c7cc,0,0,...) at pf_test+0x6b pf_check_out(0,e4f6c7cc,c64c6800,2,0,...) at pf_check_out+0x3d pfil_run_hooks(c06fc5e0,e4f6c848,c64c6800,2,0,...) at pfil_run_hooks+0xb3 ip_output(c64e4e00,0,e4f6c814,2,0,...) at ip_output+0x75e ipsec_process_done(c64e4e00,c6d66780,c6f59e88,c6f4a240,c0693460,...) at ipsec_process_done+0x120 esp_output_cb(c6f59e88) at esp_output_cb+0x1ed crypto_done(c6f59e88,2,c6452000,c6f59e88,c6f4a264,...) at crypto_done+0xa0 swcr_process(0,c6f59e88,0,c04e7b7d,c0693460,...) at swcr_process+0x126 crypto_invoke(c6452000,c6f59e88,0) at crypto_invoke+0x9e crypto_dispatch(c6f59e88,1a,c6f59e88,c6f5be38,c6f0d488,...) at crypto_dispatch+0x4a esp_output(c64e4e00,c6d66780,0,14,9,...) at esp_output+0x4ee ipsec4_process_packet(c64e4e00,c6d66780,0,0,c6786400,...) at ipsec4_process_packet+0x206 ip_output(c64e4e00,0,c6de9bb0,0,0,...) at ip_output+0x6df in_gif_output(c6539000,2,c64e4e00,c6de9b84,c6de9b80,...) at in_gif_output+0x237 gif_output(c6539000,c6b95300,c6d73790,c6ba04a4,c6e1de00,...) at gif_output+0x20f ip_output(c6b95300,0,e4f6caf8,0,0,...) at ip_output+0x8de syncache_respond(c6d5eaf0,c6b95300) at syncache_respond+0x2a1 syncache_add(e4f6cbec,e4f6cc3c,c694a86c,e4f6cbe8,c6912b00,e4f6cc3c,c694a880,8,1) at syncache_add+0x37f tcp_input(c6912b00,14,8,c065b728,0,...) at tcp_input+0x6dc ip_input(c6912b00) at ip_input+0x729 netisr_processqueue(c06fa298) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x8c ithread_execute_handlers(c63ff430,c644a080) at ithread_execute_handlers+0xce ithread_loop(c63b6b10,e4f6cd38,c06aafc0,0,c06514db,...) at ithread_loop+0x4f fork_exit(c04dd70c,c63b6b10,e4f6cd38) at fork_exit+0x61 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f6cd6c, ebp = 0 --- > the kernel with KDB, DDB, and BREAK_TO_DEBUGGER, and user a serial or > firewire console. If the hang occurs, see if you can get into the debugger, > in which case the logged output from DDB for the following commands would be > very useful: > > show pcpu > show allpcpu > trace > alltrace > ps > show locks > show alllocks > show lockedvnods > show uma > show malloc > > Please open a PR that describes your configuration, includes your kernel > config (since it seems quite customized), any loader.conf settings, a > detailed description of the problem, and the output. I'd be quite interested Okay, I'll file a PR once I can collect more information with the serial console(probably weekend). For now our system administrator is pretty nervous about my suggestion on turning debug.mpsafenet back to 1. ;) > in know, once the machine is in a hung state, whether the numlock light goes > on and off when you hit the numlock key on the keyboard. The numlock light doesn't respond to the key when the machine is hanging; hence Ctrl-Alt-Esc wouldn't break to debugger. -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 13:36:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AA6416A40F for ; Mon, 11 Dec 2006 13:36:32 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32711.mail.mud.yahoo.com (web32711.mail.mud.yahoo.com [68.142.206.24]) by mx1.FreeBSD.org (Postfix) with SMTP id 23A1743CA4 for ; Mon, 11 Dec 2006 13:35:15 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 1775 invoked by uid 60001); 11 Dec 2006 13:36:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=lLMJGAS/PwwsRVXJP0lYGb0/zMvfzx9nlfRJaJLPj33WcZhtiA9BRSjE1QoI6hgsqQanxWNa7erxwviUnksubBs8CHjr82ogi3gIh1RE2Bfo8OfVdA/R6uiDXsjxT9ukaiKD/CJE7Sjk4blrMDYTKvwrO6qmg43dtiuFobdZl8A=; X-YMail-OSG: ieh5o2gVM1lsg0z4RlJdqypmPKhyZOaSdpZ7fnZLwMNGHwkMV8wLcmlvqA0WejxIMy2I8sTsmW2R7XZkDa0EFvNga31MqnQlFfIIu8Ud_UMBH_GzR0z6A3O1y9yKbfdKZU4AzViZt8XsJUU- Received: from [200.118.62.90] by web32711.mail.mud.yahoo.com via HTTP; Mon, 11 Dec 2006 14:36:31 CET Date: Mon, 11 Dec 2006 14:36:31 +0100 (CET) From: To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <177693.1750.qm@web32711.mail.mud.yahoo.com> X-Mailman-Approved-At: Mon, 11 Dec 2006 13:53:16 +0000 Cc: Eprha Carvajal Subject: Re: New Challenges ( FreeBSD on PS3 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2006 13:36:32 -0000 FWIW, There was a similar thread on the OpenSolaris lists. Someone pointed out this site, which seems to have the patches, and other goodies, more clearly discriminated: http://www.powerdeveloper.org/playstation.php good luck, Pedro. __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 14:00:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10E6516A416 for ; Mon, 11 Dec 2006 14:00:38 +0000 (UTC) (envelope-from eprha.carvajal@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2A2B43E10 for ; Mon, 11 Dec 2006 13:54:26 +0000 (GMT) (envelope-from eprha.carvajal@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1459401wxc for ; Mon, 11 Dec 2006 05:55:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FnDXxDa0xos//gVjZsCA0kzuixITtUww4jrUa6wj+BKBJn498pB2eCrArt+XZnCr6FxDaOk0g7c7ubnsQiczUmbeutf07fNlS15X/JGqAKF9cNRPnQgymaNPywlh60UQHvnd2kIbXpv1jwj/4/aVhrHJ2wa8E0LXoq/XtqZ8wsE= Received: by 10.70.8.8 with SMTP id 8mr12368549wxh.1165845337722; Mon, 11 Dec 2006 05:55:37 -0800 (PST) Received: by 10.70.7.9 with HTTP; Mon, 11 Dec 2006 05:55:37 -0800 (PST) Message-ID: Date: Mon, 11 Dec 2006 08:55:37 -0500 From: "Eprha Carvajal" To: pfgshield-freebsd@yahoo.com, "Enmanuel Rivera" , "juan fuentes" In-Reply-To: <177693.1750.qm@web32711.mail.mud.yahoo.com> MIME-Version: 1.0 References: <177693.1750.qm@web32711.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: New Challenges ( FreeBSD on PS3 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 14:00:38 -0000 Thanks everyone for the information. While approaching IBM to get the servers is the best option, i'm not sure how long will take to get these server so isn't a bad idea to start with the PS3 if available. I will start my research and will post progress as possible, hopefully i will be able to finish the documentation and do some trials in the emulator before this weekend. References: http://lxr.linux.no/source/arch/powerpc/platforms/cell/?v=2.6.18 http://www.powerdeveloper.org/playstation.php http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F Regards Eprha From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 14:32:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B85F716A494 for ; Mon, 11 Dec 2006 14:32:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B949944347 for ; Mon, 11 Dec 2006 14:07:09 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A11B846F52; Mon, 11 Dec 2006 09:08:04 -0500 (EST) Date: Mon, 11 Dec 2006 14:08:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tai-hwa Liang In-Reply-To: <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> Message-ID: <20061211140519.Q4227@fledge.watson.org> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 14:32:11 -0000 On Mon, 11 Dec 2006, Tai-hwa Liang wrote: >> WITNESS is available in RELENG_6, and should be used in combination with >> INVARIANTS, DDB, KDB, and BREAK_TO_DEBUGGER to debug deadlocks. > > Would a kernel with WITNESS/[KD]DB/BREAK_TO_DEBUGGER enabled but w/o > INVARIANTS compiled adequate to dump useful information through remote > serial console? It depends a lot on the deadlock. The warnings you've attached below provide a lot of information, however. >> It sounds like you need to follow the instructions for kernel debugging. >> Depending on your tolerance of performance loss, downtime, etc, a good >> starting point is to configure the kernel with INVARIANTS and WITNESS. >> WITNESS is particularly important, if you can tolerate the performance hit, >> as it warns of potential deadlocks, not just actual deadlocks. Also, >> compile > > With WITNESS enabled(debug.mpsafenet=0), I got another three pf related > warnings in the last 8 hours: Are you using uid/gid credential rules with pf? >> the kernel with KDB, DDB, and BREAK_TO_DEBUGGER, and user a serial or >> firewire console. If the hang occurs, see if you can get into the >> debugger, in which case the logged output from DDB for the following >> commands would be very useful: >> >> show pcpu >> show allpcpu >> trace >> alltrace >> ps >> show locks >> show alllocks >> show lockedvnods >> show uma >> show malloc >> >> Please open a PR that describes your configuration, includes your kernel >> config (since it seems quite customized), any loader.conf settings, a >> detailed description of the problem, and the output. I'd be quite >> interested > > Okay, I'll file a PR once I can collect more information with the serial > console(probably weekend). For now our system administrator is pretty > nervous about my suggestion on turning debug.mpsafenet back to 1. ;) Thanks. >> in know, once the machine is in a hung state, whether the numlock light >> goes on and off when you hit the numlock key on the keyboard. > > The numlock light doesn't respond to the key when the machine is hanging; > hence Ctrl-Alt-Esc wouldn't break to debugger. Serial break is significantly more reliable for getting into the debugger on the system as it stands, as syscons requires the Giant lock while the serial interrupt handler doesn't. As a result, serial break can often get you into the debugger even when Giant has been leaked. The numlock light not going on and off is a reasonable test of whether Giant has been leaked and/or interrupts have been left disabled on all CPUs, as it means that the syscons interrupt handler is unable to run, hence my inquiring. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 15:35:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47B6416A416 for ; Mon, 11 Dec 2006 15:35:21 +0000 (UTC) (envelope-from rodperson@comcast.net) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [204.127.225.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7A7943CF0 for ; Mon, 11 Dec 2006 15:32:44 +0000 (GMT) (envelope-from rodperson@comcast.net) Received: from atomizer.opensourcebeef.net (unknown[71.61.11.4]) by comcast.net (alnrmhc11) with ESMTP id <20061211153400b1100k48vte>; Mon, 11 Dec 2006 15:34:01 +0000 From: Rod Person Organization: Open Source Beef To: Current Mailing List Date: Mon, 11 Dec 2006 10:31:00 -0500 User-Agent: KMail/1.9.4 X-Face: $72, ]$Z1y\/nYF:T[d"3TSO@]'dM+)/B@hdK(?fAY@F4IPU, wTha8oQ\ish]&GCe&C[vAG g; v~`wM,7H'7TW"!3zWJ_o]nb]i>oMCl=g1F$+$v+8i,xRtU(vKPxX\oK7/9to!z08{J%A p#` MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2296171.HSdJKrNavl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612111031.06109.rodperson@comcast.net> X-Mailman-Approved-At: Mon, 11 Dec 2006 15:39:20 +0000 Cc: Subject: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 15:35:21 -0000 --nextPart2296171.HSdJKrNavl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, I'm having a problem with the latest nvidia driver on 7 current. This drive= r=20 is causing a few problem with my system. 1) When I start X either by using the startx command or using a Graphical=20 login manager such as gdm or kdm, I can not switch virtual consoles using=20 ALT+F#. Doing so locks my system. 2) Once X is started, trying to kill X or log out of a window manager using= =20 any method, such as CTRL + Backspace or the exit function of a Window Manag= er=20 causes my machine to lock. In either case, the only thing I can do is hit the power button and reset. I was wondering if anyone else is seeing this or has any suggestions on=20 correcting this behavior. Currently I switched to the nv driver, but that=20 driver does not support the max resolution of my widescreen monitor=20 (1680x1050) only the nvidia driver does. My graphics card is XFX ndivida 7800 GTX with 256MB Ram. I last rebuilt my= =20 world on Dec 9th. Any suggestion would be helpful. Thanks Rod --nextPart2296171.HSdJKrNavl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFfXm63rDijyy3LEcRAsKNAJ9cUf2ncxGwm9MKIXBOUA1OOry7KgCgn8MO MwEW9jJignk/93NljPjQpck= =cNf5 -----END PGP SIGNATURE----- --nextPart2296171.HSdJKrNavl-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 16:27:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9327716A412 for ; Mon, 11 Dec 2006 16:27:47 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a10.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9A843D7C for ; Mon, 11 Dec 2006 16:26:06 +0000 (GMT) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.203.16.7]) by spunkymail-a10.dreamhost.com (Postfix) with ESMTP id F1C7B16312C; Mon, 11 Dec 2006 08:27:19 -0800 (PST) Date: Mon, 11 Dec 2006 14:27:13 -0200 From: Ricardo Nabinger Sanchez To: current@freebsd.org Message-Id: <20061211142713.ec4cbc4e.rnsanchez@wait4.org> In-Reply-To: <200612111031.06109.rodperson@comcast.net> References: <200612111031.06109.rodperson@comcast.net> Organization: SYS_WAIT4 X-Mailer: Sylpheed version 2.3.0beta6 (GTK+ 2.10.6; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Rod Person Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 16:27:47 -0000 On Mon, 11 Dec 2006 10:31:00 -0500 Rod Person wrote: > I was wondering if anyone else is seeing this or has any suggestions on > correcting this behavior. Currently I switched to the nv driver, but that > driver does not support the max resolution of my widescreen monitor > (1680x1050) only the nvidia driver does. > > My graphics card is XFX ndivida 7800 GTX with 256MB Ram. I last rebuilt my > world on Dec 9th. Any suggestion would be helpful. Yes, IIRC there are other reports both on current@ and stable@. The old driver (8774) works, but has the local root exploit vulnerability. -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 18:22:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A68216A415 for ; Mon, 11 Dec 2006 18:22:34 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0DCA447C8 for ; Mon, 11 Dec 2006 17:56:06 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [192.168.0.13] (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id CJY45510 (AUTH peterg@ptree32.com.au); Tue, 12 Dec 2006 03:57:20 +1000 (EST) Message-ID: <457D9B77.1090106@freebsd.org> Date: Mon, 11 Dec 2006 09:55:03 -0800 From: Peter Grehan User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: New Challenges ( FreeBSD on PS3 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2006 18:22:34 -0000 >I was wondering if anyone though of installing >FreeBSD in a PS3, i'm sure there are some big >challanges there. The main Cell CPU, the PPE, looks like a slow G5. Linux runs under the control of a hypervisor. You can't run direct on bare metal. For FreeBSD, the challenge would be to get the loader running, and get the kernel to use hypervisor calls for all the low-level operations. later, Peter. From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 19:12:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 340F716A530; Mon, 11 Dec 2006 19:12:08 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B29C643D6A; Mon, 11 Dec 2006 19:09:44 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id kBBJAjek057515; Mon, 11 Dec 2006 22:10:45 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 11 Dec 2006 22:10:41 +0300 (MSK) From: Maxim Konovalov To: Robert Watson In-Reply-To: <20061211110009.K62822@fledge.watson.org> Message-ID: <20061211183048.S20189@mp2.macomnet.net> References: <20061211110009.K62822@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 19:12:08 -0000 On Mon, 11 Dec 2006, 11:00-0000, Robert Watson wrote: > On Sun, 10 Dec 2006, yal wrote: > > On Sun, December 10, 2006 13:57, Robert Watson wrote: > > > > > - Try setting net.isr.direct=0 and see if the problem goes away. > > > > > > > > This indeed help. LOR has gone and wireless works. > > > > > result in a deadlock under other circumstances, net.isr.direct makes the > > > chances of that deadlock much greater. > > > > It helped on Latutide D520 as well. No freeze or anything anymore. Top shows > > now 100% idle most of the time. The debug.mpsafent="0" has been deleted, as > > suggested. Thanks to Robert N. M. Watson. > > Sam has committed changes to if_wi in the last 24 hours that may fix > this problem with the default net.isr.direct setting. Could you try > updating to these changes, removing net.isr.direct=0, and seeing > what happens? It works for me. Thanks Sam and Robert! -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 19:16:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBA9E16A4A7; Mon, 11 Dec 2006 19:16:51 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F0B43CCC; Mon, 11 Dec 2006 19:14:14 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id kBBJFVxl067761; Mon, 11 Dec 2006 11:15:31 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id kBBJFV00067760; Mon, 11 Dec 2006 11:15:31 -0800 (PST) (envelope-from david) Date: Mon, 11 Dec 2006 11:15:31 -0800 From: David Wolfskill To: Robert Watson Message-ID: <20061211191531.GP29001@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Robert Watson , current@freebsd.org References: <20061211110009.K62822@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F67xnxMyVwCoXwbx" Content-Disposition: inline In-Reply-To: <20061211110009.K62822@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 19:16:52 -0000 --F67xnxMyVwCoXwbx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 11, 2006 at 11:00:27AM +0000, Robert Watson wrote: > ... > Sam has committed changes to if_wi in the last 24 hours that may fix this= =20 > problem with the default net.isr.direct setting. Could you try updating = to=20 > these changes, removing net.isr.direct=3D0, and seeing what happens? This appears to have helped so far: I just finished the "make buildworld" & friends on my laptop (a Dell Inspiron 8200 with a mini-PCI wireless NIC that the wi driver handles); presently running: localhost(7.0-C)[1] uname -a FreeBSD localhost 7.0-CURRENT FreeBSD 7.0-CURRENT #264: Mon Dec 11 09:47:47= PST 2006 root@localhost:/common/S4/obj/usr/src/sys/LAPTOP_30W i386 localhost(7.0-C)[2]=20 I have the following kernels handy: localhost(7.0-C)[2] ls -ld /boot/kern* drwxr-xr-x 2 root wheel 24576 Dec 11 10:13 /boot/kernel drwxr-xr-x 2 root wheel 24576 Nov 28 09:56 /boot/kernel.old drwxr-xr-x 2 root wheel 24576 Dec 10 09:45 /boot/kernel.wi-LOR drwxr-xr-x 2 root wheel 24576 Nov 28 09:56 /boot/kernel.working localhost(7.0-C)[3]=20 The LOR in question no is no longer apparent; it was apparent in all kernels from 29 Nov through 10 Dec. (I normally update & build daily.) I'll plan on givinig it a more strenuous test tomorrow morning -- the "make buildworld" (while using the wi0 NIC) test. :-} And thank you, Sam, for trying to mitigate some of the problems with the wi(4) driver. :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 19= 99. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --F67xnxMyVwCoXwbx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkV9rlIACgkQmprOCmdXAD132wCghSMkKljTdVM4gZKljTqXhS4W cpUAn2QaudoXO/pEHWiZ1X0H8xdC2zep =E80I -----END PGP SIGNATURE----- --F67xnxMyVwCoXwbx-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 16:06:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D173316A4AB for ; Mon, 11 Dec 2006 16:06:25 +0000 (UTC) (envelope-from walkingshadow@grummel.net) Received: from mail1.bytemine.net (mat.bytemine.net [193.41.144.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FA1843CA7 for ; Mon, 11 Dec 2006 16:04:09 +0000 (GMT) (envelope-from walkingshadow@grummel.net) Received: from 4be54-4-82-234-154-189.fbx.proxad.net ([82.234.154.189]:11689 helo=mailsvr.my.domain) by mail1.bytemine.net with esmtpa (Exim 4.62) (envelope-from ) id 1GtneZ-0003Bt-FY; Mon, 11 Dec 2006 17:05:19 +0100 Received: from localhost (localhost [127.0.0.1]) by mailsvr.my.domain (Postfix) with ESMTP id D6F32456D2; Mon, 11 Dec 2006 17:05:12 +0100 (CET) Received: from mailsvr.my.domain ([127.0.0.1]) by localhost (mailsvr.my.domain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28104-05; Mon, 11 Dec 2006 17:04:24 +0100 (CET) Received: from localhost (unknown [192.168.0.11]) by mailsvr.my.domain (Postfix) with ESMTP id EB591456DA; Mon, 11 Dec 2006 17:04:08 +0100 (CET) Date: Mon, 11 Dec 2006 17:04:04 +0100 From: Jona Joachim To: freebsd-current@freebsd.org Message-ID: <20061211170404.43500de2@localhost> In-Reply-To: <200612111031.06109.rodperson@comcast.net> References: <200612111031.06109.rodperson@comcast.net> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-Face: &>dujC`JZV!}?Y^1"%N{x!f+rW}; PX\_Cg[!|MA~tn3ebIKM|~p=,,U~YJt,Exd`Spk.1Ln zg, Q]0=:!/LTs-eg.Fz, @giLyD'D=s, L\-AJyZ8tcV`kPifedMA@rhoEikoo~K%@iDLNq2?aHZjIt) GqBY7o#9+8j/uuXDVG3`XFEH_4$T%._*%;|vIaP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at my.domain X-Mailman-Approved-At: Mon, 11 Dec 2006 19:26:13 +0000 Cc: Rod Person Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 16:06:25 -0000 On Mon, 11 Dec 2006 10:31:00 -0500 Rod Person wrote: > Hi All, > > I'm having a problem with the latest nvidia driver on 7 current. This > driver is causing a few problem with my system. > > 1) When I start X either by using the startx command or using a > Graphical login manager such as gdm or kdm, I can not switch virtual > consoles using ALT+F#. Doing so locks my system. > > 2) Once X is started, trying to kill X or log out of a window manager > using any method, such as CTRL + Backspace or the exit function of a > Window Manager causes my machine to lock. > > In either case, the only thing I can do is hit the power button and > reset. I experienced a similar behaviour some time ago but that was related to GLX. Everytime I started an OpenGL application it worked fine but once I quitted it the system locked up. I wasn't able to figure it out and the people in the NVIDIA forum couldn't help me either. My solution was to use an older driver. There is a driver archive on the NVIDIA website. Fortunately the latest driver fixed my problem. Perhaps you could also try to use different driver versions to see if that changes something. By the way, this is the wrong mailing list to ask such questions. You should consider asking on questions@ or ports@ Jona From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 16:23:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2263116A416 for ; Mon, 11 Dec 2006 16:23:04 +0000 (UTC) (envelope-from rodperson@comcast.net) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.192.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CE6043CAA for ; Mon, 11 Dec 2006 16:21:46 +0000 (GMT) (envelope-from rodperson@comcast.net) Received: from atomizer.opensourcebeef.net (unknown[71.61.11.4]) by comcast.net (rwcrmhc12) with ESMTP id <20061211162302m1200sq9gke>; Mon, 11 Dec 2006 16:23:02 +0000 From: Rod Person Organization: Open Source Beef To: Jona Joachim Date: Mon, 11 Dec 2006 11:20:03 -0500 User-Agent: KMail/1.9.4 References: <200612111031.06109.rodperson@comcast.net> <20061211170404.43500de2@localhost> In-Reply-To: <20061211170404.43500de2@localhost> X-Face: $72, ]$Z1y\/nYF:T[d"3TSO@]'dM+)/B@hdK(?fAY@F4IPU, =?utf-8?q?wTha8oQ=5Cish=5D=26GCe=26C=5BvAG=0A=09g=3Bv=7E=60wM?=, 7H'7TW"!3zWJ_o]nb]i>oMCl=g1F$+$v+8i, xRtU(=?utf-8?q?vKPxX=5CoK7/9to!z08=7BJ=25A=0A=09p=23=60?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8389172.3xLQgoAuz7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612111120.07327.rodperson@comcast.net> X-Mailman-Approved-At: Mon, 11 Dec 2006 19:26:21 +0000 Cc: Current Mailing List Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 16:23:04 -0000 --nextPart8389172.3xLQgoAuz7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 11 December 2006 11:04, you wrote: > By the way, this is the wrong mailing list to ask such questions. You > should consider asking on questions@ or ports@ > Sorry, I figured since I am running current and when you download older nvidia drivers (even the version prior to this that worked fine) from nvidia and build them you get a message that it's not compatible with 7.x I figure= d=20 this is the place to go. --nextPart8389172.3xLQgoAuz7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFfYU33rDijyy3LEcRArkhAJwOVSE0S9Y8HYUQ+ut6woWY3gY3SQCgqnQs epRQbX74lDSTNaxDAoV2LG8= =CUWK -----END PGP SIGNATURE----- --nextPart8389172.3xLQgoAuz7-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 19:27:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C80116A4CA for ; Mon, 11 Dec 2006 19:27:31 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA1CA43CA1 for ; Mon, 11 Dec 2006 19:24:12 +0000 (GMT) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1290398uge for ; Mon, 11 Dec 2006 11:25:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type; b=E2b5G6vHmpScoFklkqcgDeF20uQm+QxjfyVoat9i3mhL7oRj4rjEPNah3xbWxI8OhnnxnE6AIJqPBOGORSgeuhqJ6g9vxDriXdyuc+idVdkgjh0OB7FZAwkEM0xqHVBXfo9fIWqCe72gFb1e8aWJCq5D5pJCdMT6FBIVm44fy+I= Received: by 10.67.121.15 with SMTP id y15mr10355126ugm.1165865124076; Mon, 11 Dec 2006 11:25:24 -0800 (PST) Received: from ?192.168.123.106? ( [195.241.221.201]) by mx.google.com with ESMTP id 54sm7635240ugp.2006.12.11.11.25.20; Mon, 11 Dec 2006 11:25:23 -0800 (PST) Message-ID: <457DB09C.7030405@gmail.com> Date: Mon, 11 Dec 2006 20:25:16 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: current@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------020303070201020001040105" Cc: Subject: rescue/rescue not compiling ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 19:27:31 -0000 This is a multi-part message in MIME format. --------------020303070201020001040105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, since last week or so, buildworld doesn't want to compile rescue/rescue anymore. I don't have NO_CLEAN set, and neither explicitly removing /usr/obj nor re-cvsupping help. It seems that some .h files in src/bin/sh/ are not generated. The log is attached. Any ideas? Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------020303070201020001040105 Content-Type: application/octet-stream; name="buildworld-20061206-2121-i386.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="buildworld-20061206-2121-i386.bz2" QlpoOTFBWSZTWWhZ/lABbsVfgGBSXf//+3//3uv////wYOe+8o+JQ0BNYGdO4zUqHBQs1AAA AaEzAAAAAAABoTMAACNdD4H3vp9PrLYAuT0PI8ALToaYAAAAAAAAPgCQAAAAAAAAMB1PZ8uM rYYsDAAAAANABsMBM4MBUlGhrW0znNRyK1UmbBV3uPRIr1oaWyJjMaayLYAFaU2jBt3Po9pr S2+sugriQR0CgiFUqoL7PR557u5u2bNoQLezRu3djSsKu2rpzdw0rkAAAGVKEPKIyyxK21eZ vAd2zd26aN3ttNcl69dYAG2INJtXiz2eqZaoumsAsYPYADXPbXo1YsG2283O253cPbZdfcc5 8ZuzMjWbcGrevqUjW+7h53ueze3rndsbPnavR5t22q+mIvAAAAAAACz5M5ju7vrTtt2a6973 rz1obxVcq4N3t7xutlBR8zWUKpCudvLkPht0aLXtuml3LsXfdk6L7h3d3zzr0dFW32yVfPbq rabne7HebodbrrtrNdIrM6y+A2y0vjPrl7Zffd32KXu3dfdgw9q3nvU8tixiSLu7ra07unW8 UKToxzQAFLsCg16+q57L3bhqtZGunz2ApzgAbsOc6QvO2rnrugALZR5Tct2nbUjMKW3d2dzr abdd9N1YfDdyqGpgECAQIEJo1KnlG0m0yCMAACYBqCUzUkgSaBMjRTUeo0BoBoANAAAAAae1 VJSanlT1PKejU00yaNMQAAMhkMJoyaGIaYJPVSIhAIaJkyU8kGgDQA0AANNDTQeoESRACBND RAQmITIxDInppT9KejI8pNMZAFRJBAgAiAhqJop+lPU9NJ6gNAaANAA0wFEPvviiiqDj70Ag iSCKof+Pp/2/2/9/u/4+ef737Lfz+P0/mAQAAAAAQAWtX4tfL5/Nq9N/I9Web/x+z538uESM E5vWHIhCEIQ6e07dUEt/4te4XqjiIxiIiH791+Hv5cP5e9zzrbvX2K2Na1FRqo1tG+jV/ba+ Sr1m3xY10q/rzVumq982Tb98qvvkasjtUnxRaLRaSMoyi0Wi0Wi0WpOtHzYMo1RaQtkjKLRu qJJvY2qQSZfmnzV/Mr0V4bi43oI1fFrk2+Crk2/tTbpV1I0kaTVUa2rw25NoZU3saUKoZRaL RaLQVFRVybJsm3FXJVfpLjSbdKuTb/1LjZlSarpVybJsm3lUY1ybJsmybJt1LjXSoxoxrkuN GrkjSbJmEXwRaIsIZVSX3pagGxColyEjuNtRWKxWKxWKxWKxWKxWKxWKxWKxWKxWKxWKxq/C bdTZNk2S+LXJt2qNxrirkquLWMa5Nupt0q6mybJskaTZNk2SNezcaSL1Rra0Wv54k5y1VsYq 9FvvzWupaS0lpLSSQgkIBRDCBnHOKrhFQEw/72zuCrUBLRZFSQQzjaIgJaALnMoEn/upHlQR 1sEOKgPei096EirpEVHrGRZGREMYgAL7KZH6deb4fst3t3EkpLFlNGZJSpZlSUmlCmUkVG1s mKSmhsbJViwSUWIrG0SUs0lpmszUhI2UmyUW1JVpKKZrLIktotMoItYrFiiHXC3NhIyqqyek JOKRJiiVSw6ao80Tlx7oR0RqyT3QHjXnX0TKvz/R/b9Ff+4V+3576af06fG23G8OpHku1EHI +B8DuP6Rd/zz8OieRw6Mf7Hhs3fD6f3f/l1fDTl3dXy8P6btOzu4f2bHRp0cuH+Hu5bN2P/0 x6PJyfYQ1ionSEJJ1NSFy97ljkdbjhJJCEAAQQOOAAT4uEAPa+l8rl32IgCeXBAAgIjEsCMr 1ucejgfiuW7pjSm+/kxzrJ+1cHQlWRVKpIqyRVlWRRKlB3/1QJP0fuiQ/l9RaVViv9D7h/L/ VzHCeAEfYO7R4QF37f5T+/+VmxdVVbK8M1mpVaEDZT4nQ/vDFPNnxFQfinhOSfN/CJilJQfn /rFQYH6UP5baByX16SEgwahSlRMkFJUswkRjSpr98Y1lSOaKskktktLIrb7EFNRADJvi4Epo khRmoJHK1s1MNY9Yn5ez+nu0/Csaf4eT0bP9z4fs7t3L/Jy6uWz2dnL/Y/litz/Np3ebqxp2 V3eH/9ct27dWPJ2fy0x5N3D/e2HZTsp1f7nV/LZ1dnm93h6Ppuxw/3PZp3Y6FdW7I9BRUXGA Q7hc3VPBGEceBqFnI01DCORFYXWwgaDwZMPCX0FTCWK+OwgMzEeRYeEPIZ/CgWIWBCvgV8KK i2nAxr2DA38bpcxNCq2fC1vgu7gDAoAAP53Rn8PfGicmyVwvJ3sy8pF78VkkXffWtZGaIbId nY//XiNAQQEP7YIVFwYMdhsEDAtyuHGRq06rN/Q82zd5vh1dHSu71aVy2a9a4f1/p/WKYUN3 WL45Q1on7Mn6YD2Tpj1I25Tf4+30Vui+MdZ/HH9r32StYhdbbp7LYSb8JA7FSe/Q0oh1z9Yc nRNZWfRxe6gtMR81GxXJp/kqYLxonYMEFx7hwNhyJvzfb6BiA5BCG1wnP26ft1/YIA/xi4wB YcpgEKbDQbCAwxp9t35bvV6OT93V8OVVjl7K/zVOjdshyPBke5uex6FzU9Tg5nodyjg7G7Td ze70dm7m4Ps7vo4PJ3ac3Joe7s9Xu3eR7HI0MDA6hBYMIHYCRUQHHIYVH9gIMIFQQwLBr6xK 4wXMyaVRlNYuN+LBjzLeWp4NDYoyNjMrimOAibVtCYNk2svc8WZe6Re+9ZJF21V4gYpU3Q21 ZuMn2L8lXBn32Ri3Kz52SpDUaounMxUr7IUKgb8/f6Ul57rF8coa0T8sn5YD5Tpj1I25Tf8/ b7FbkvfHWf24/PvslaxC623T2Wwk34SB2Kk9+hpRDrn6w5Oiays+ji91BaYj5qNiuX2N8bX0 6c7+/kbzWvN9voGIckIbXCc/bp+35cfm1xU7FTTGjsadm8tpmB8V3giOPJfkqSyl48x7Y9d1 t4zr36PPGDWetrrLesd20wcwY6vv0unrSrNulmjsJrD8tX8k0VLFp1eZvcKJBVMxBWKlHXKA aifauRu4ZQngwuWbCZ47Eg4nIQq3uOL/frWQdorZ11XkMY2KFfqDYj7lKEv3MfRCSDECtY5/ jri+wfzKSlfLdEhYnv4T5jBxOD73LRhVqh8Wel90+r8X8wYjR8kZedWJ0ufOSlBI+O9pWSsV J2qOL90ogVs2bnXI7svsEVwQmsLqPt1x29i/H49Y79j1pyO2tBsa+G6Yk+Pj39wv4g+AXtn2 +X+NuJ44tA+Eomeo7AuPiqa7a693yskjk5n87fckbn8ctyXCbSeDWrpoQJ1QyfOiMZ6yrqUL HjfxyrCCHfOujsyp86snbYaLCBtt5O5NscsoNKtupFmL869OmBbTrR0s2mcGpU7E6aNrV7GV LoyiUDyttf7IGjm4QP7rX8Ryi53N7HD/gvf1veGvx+zba8WfN+3HNs8rwVS2a3sptlVDFC79 CWIgXozIyo5C1S/3zVqTfnAvwgKTxiSI0jRSRa+3L4KTdCLcLhfZ9EkpEHc3JTKu54tB7Hf9 r4tbHawXPaOIbWrSgMe1WCkd5I9TNJ0SPfZqQNHygY0vdOFcW6kHlL/JJBsdwqF5sdXbvu2X ejkKYIRlXBPG8nVq7+NaILX+1W12sebWVKp7VLZK7zX1OgyTd+WrzebaJ2NkrZcHezL2SL38 VkkXvr7lta1RpRDZDu7H6fjUGEBD9AhV4Yx9vZpuvve7h5PVp1VvfQ82zd5vl1ciSFxsEBCA o2Wjj9fv9zUwobwsXxyhrRP0yfpgPdOiYtSNuU3/j8/sVui+cdZ/fj9e+yVrELrbdPZbCTfh IHYqT36GlEOufthydE1lZ9HF7qC0xHzUbFcmn7qmC8Hp2DAxce4cDYcib832+gYgOQQhtcJz 9un7dfcQB/o7vB2Z8eGJ6vN6uW7Gn23flu9Xo5P3dXw5ZjGOXsr/NU6N2yvN+XL9Xh+j7bOz 8PI5nodyjg7G7Tdze70dm7m4Ps7vo4PJ3ac3Joe7s9Xu3eR7HI0MDA6ljUwMjzDM0MjE8jAV H5BBhAqCGBYNfWJXGAokFUzEFYqUdcoA+tI9kyN3F1CeDC5ZspXjsSDichCre45v9+tZB2it nXVeQxjYoV+oNiPuUoS/cx9EJIMQK1jn9+uL7B/MpKV8t0SFisv368B6fNLUmh0rS1LUMSLF owq1Q+lnodd1+r8X86mIl8kZedWJ0ufOhSgkfHe0rJWKk7VHF+6UQK2bNzrkd2X2CK4ITWBo wbUfbrjt7F+Px608dzxTod9aDc19K3Zy+G9h2/Bbgh3t5+L++u877+8D3SiadR2BfO1U1211 7vlZJHJzP52+5I3P45bkuE2k8GtXTQgTqhk+dEItZh1KFjxv45VhBDvnXR2ZU+dWTtsNFhA2 28ncm2OWUGlW3UizF+denTAtp1o6WbTODUqdidNG1q9jKl0ZQYaEtr/Fxo5uED+61/Ecoudz exw/4L39b3hrjjVi03q2Ldb8Wxwu5VLVrelNsqoYoXbkSxEC8mZGVHIWqX6mrUm/OBfhAUnj EkRpGiki19cvgpN0ItwuF9PoklIg7m5KZV3PFoPY7/i+LWx2sFz2jiG1q0oDHqrBSO8kepmk 6JHts1IGj5QMaXunCuLdSDyl/gkg2O4VC82Ort33bLvRyFMEIyrgnjeTq1d/GtEFr/VW12se bWVKp7VLZK7zX1OgyW2B3q72vSnNU819VZHLsUIFQgmCql0Mamo+jUcmNEHj2UVtl1htdrNr qcwY839dl055Slo1vc07t82e5HHzXwpMOgXG572h5HlO/PoFw62jwRT13j1HnjoRtWe5jy62 h7rfmN72t+hfLn7s4nm/76nnf3EAhIYbiBuEt4TSrdX9NaxzBj1fTsvmeyd629/02/t49tVx 7bHK+NdF8XfiUqbJNVyfVmXlIvfWski68etqyNKXN0O7se+niRNzGxStso5DAui34mKl20Qo VA3X791LfukXx5Q1on6ZP0wH0nTHqRtym/8ff6K3BfGOc/xx+vfZK1iF1tunsthJvwkDsVJ7 9DSiHXP1hydE1lZ9ji91BaYj7VGxXJpwvtto20Y+QY2ckIY0CbfW78MPzWwkxm+WwafthGDU 3Prhj7Xi3aVhvfnVudjmDH7X26XqI18DxPi2a/m72ChwUmYguCpR1ygD6j8noN2F1CeDC5Zs JnjsSDichCre44v9+tZB2itnXVeQxjYoV+oNiPuUoS/cx8EJIMQK1jn9+uL7B/MpKV8t0SFi vc/h1Nnt2qWVFXqHzZ6Hsnzbe3j0YjR8kZedWJ0ufOhSgkfHe0rJWKk7VHF+6UQK2bNzrkd2 X2CK4ITWF1H2647exff7+sd+x605HbWg2NfTdMXn4+H9wv4g+AQx6+W+Nd433+IHwlEz1HYF x8VTXbXXu+VkkcnM/nb7kjc/jluS4TaTwa1dNCBOqGT50RjPWVdShY8b8Ioch2xpl2ZU+dGT rUZWEDa7SdybU5ZQaVbZSLMX415dMC2nOjpZtM4NSp0Tpo2tXsZUujKJQPK21/iBo5uED+61 /Ecoudzexw/4L29b3hrjhddN6ti3W/FscLuVS1a3pTbKqGKF25EsRAvJmRlRyFoOjW4sJ3QF c7YkiNIypItfPD4KTdCLYLhfL6JJSIO5uSmVdjxaD2O/3vi1sdWC56jiG1q0oDHmrBSO8kep mk6JHrZqQNHygY0vdOFcW6kHlL/JJBsdwqF4sdXbvu2XejkKYIRlXBPG8nVq7+NaILX+atrt Y82sqVT1UtkrvNfU6DODGP4BGKv7XHpLnb39kLu/b1LsVyxxPvbFY1Lla6nY7XPusB3/Ptq3 vXH611+ruPb382zjo5nTffTRO5slbL7nezLhIvfiski/PjsW1rVGlENkO7sfl/OoMICHuCFR 4Yx+72abr73u4eT1adVb30PNs3eb5dXKSFxsEBCAo2Wjj9fv7GphQ3hYvjlDWifpk/TAe6dE xakbcpv/H4+St0XzjrP78fr32StYhdbbp7LYSb8JA7FSe/Q0oh1z9sOTomsrPo4vdQWmI+aj Yrk0/dUwXhk07BwYuPcQBsORNeb7fQMQGcwpDa4Tn7dP26+4gP9Hd5HZnx4Ynm83q5bsafbd +W71ejk/d1fDlmMY5eyv81To3bK835cv1eH6Pts7Pw4OZ6Hco4Oxu03c3u9HZu5uD7O76ODy d2nNyaHu7PV7t3kexyNDAwOpY1MDI8wzNDIxPIYVH7ggwgVBDAsGvrErjAUSCqZiCsVKOuUA fUR7JkbuLqE8GFyzZSvHYkHE5CFW9xzf79ayDtFbOuq8hjGxQr9QbEfcpQl+5j6ISQYgVrHP 8dcX2D+ZSUr5bokLFZfv14D0+aWpNDpWlqWoYkWLRhVqh9LPQ67r9X4v51MRL5Iy86sTpc+d ClBI+O9pWSsVJ2qOL90ogVs2bnXI7svsEVwQmsDRg2o+3XHb2L8fj1p47ninQ760G5r6Vuzl z8fEe4X8QfAIeL+vl/jbieOPiB8JRNO0dwXO1U12117vlZJHJzP52+5I3P45bkuE2k8GtXTQ gTqhk+dEYz1lXUoWPG/jlWEEO+ddHZlT51ZO2w0WEDbbydybY5ZQaVbdSLMX516dMC2nWjpZ tM4NSp2J00bWr2MqXRlEoHlba/qBo5uED+61/Ecoudzexw/4L39b3hrjjVi03q2Ldb8Wxwu5 VLVrelNsqoYoXbkSxEC8mZGVHIWqX6mrUm/OBfhAUnjEkRpGiki19cvgpN0ItwuF9PoklIg7 m5KZV3PFoPY7/i+LWx2sFz2jiG1q0oDHqrBSO8kepmk6JHts1IGj5QMaXunCuLdSDyl/gkg2 O4VC82Ort33bLvRyFMEIyrgnjeTq1d/GtEFr/VW12sebWVKp7VLZK7zX1OgzfYIHjY7BXMWJ OkHfwfTfGnwSc+ePe1vXbXYk238rzl93lj8fbv3023224uKJb8P+Xp8DqwTwJQAo/mP6p8v+ 31j+Z/1YH+Z2BACCoOX7P+lP/8GzQX6Of8z115f7KCeRovqfYQRxKTEiqn92FwD2YkT9RENJ VVKQpUSVJIlWEYHuqIhGAB8j6oPQUH2TmIpctri2ktrbFSpmiVLNGhWyjjJF+RzEeMQFTfJB T6v/MgW+QjlFEmF79bct+d8YfOF9elgD7NEqLI7gfk/T1f2fsjcJaEIXIfcVarMIZ5ih+Ty6 +mGHp+i35fPLH3wt+avl6OHwQVvJDIrxZPumsAsQ5hArbbvj1mt23ezPZTzODw8PAAAAAAAA AAAAAADAAAAAFW9+u8vLc9bxvHh4MACmJKY8PACy7YAALbJdsgAAAA+j30Ku+d/Wff+nBD8P 4fxy70GzD+Pm8OyHYQp/GXiU5lTdWhOskSe/cT027scV1uP+bN7VPMBncnuuksjVAZaHQgQI dxqYgg8CqqCpULRCul9GuNNmnEw1VcMY2E+fT6/59XO03r69X9TMrsfSVUiqKlUUj+FYpJkt 6SSspaUpKSkq2QVWCP0Y/ZXVU0qsYjdWlf4cOWk2f05aafux/ZTqp2KnVEn7Kx5v+ksWHk84 gpVoIsgj+oCSEQqqYLNaYVUqkyGMEqqKqpUWLJqvZubZJSTJJSVkslKlqSlJmVplpmbq9IRE YE1LIQsqGPQvNwupAEx/fWLLFoXuEU2E9fj+j5t01EVQyaYbpr+K1a2V+OlySSSSSSSkkpKS kkkpJKSkkspJJJJSUlJJJJJJJJJSSUkkkkklJSSSSSSUlJJJJSSSSSSSSSSSUkkklJJJSUkk lJJJSUkkkkkklJSSSSSSSSSSShCGj/oNgH7Agv7pAggj4o6g3G6H7MYsHMDmjHvNKAUGn9Re P3n24kdfc/aUD/yr1hhQZIFf5U/oV6/bRt/4P2t/Wz5wg4+3qY+/4jXteN+j7HZvJUr6odRH s/FxJMwAaa1Ma9ion9ZNrcVjbAwKKMrBYKLFhkxRy+KIpZ74/rsZGbCjbDyx8ZgOcsOu3cjj 9D6qTNClBlJZSWUkIMeBzzxMAMZic6b4/z+4sBcNpzbNACiaTQlRaBesRB2mGGFiYSobjCvq gpiKphYq5CGFrY3bESoNW8I8XIKLNVvR9+7SA+kTSaECQMVBMBsWaGUZ7QkZezG1pqvo4/Mm u4RxxqHW6WE2kgDZwlbdISOgJw3N5hzXCna8mlr+koJBmQonsMey47ovO+QZQcUDP2LORscW yinL+KqIl73NUmPOrkzFRY8+1GEwJAyowoarIhUx/qvxqb26e3lyBBNXutdpMYyUZKiKctta 5wBsEgFAUlGMAOWuS04CSQil9v9TrdQjBJJGSCDBkvirbX059JbjXpvx9/17vOVf5qurbVnq SAJCSSQJmSYkACUpAAAkJAAkkACUwEgAABIDMEkgSBJIABKYEgSBP89fTXN3X69VziBR7l3N NGnGyCPqcqwISHrRUWGMNrpZ8gm7I0wxd/YE02vukhO7dPf0K+VaOQNxriwagOfwKlhDiJfc 64l0QvhTU7stMSF41Aq1WJM6bm9Dl6B95EBPaHrtmBh5fJLKTm5TDMzAX9to6RqSi2SgCyxS iDHGDciN4twEF22s4YZffVZIe56dsMj4aCW7eRa3CNGqolqDaIkmFDRatjwoJ1W2iqInllxa 2t+I8sd7N+9SqOIMmr4WUX5gA0HPdVETZd4iIGwTewWbokkPy1zOhnPv5Iq6HqH+AZMQgnM5 oKfARRbCKLmADqqiJgV+7aj+P/XU9OPPHYVUF/yEAIZgGGAf2fvzth/Yh7O8VWsWsWsWsWsW sWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsYxi1i1i1jbbaqqrWLWLWLWL WLWLWLWLWLWLWLWLWLWKqq1VWMKkRKiIpESpESoiKWpSpalKkRKlqUqIiiIoiKWpSoiqrFrF KlqUqREqREqREqREqWpSpaiqrGFS1KVIiVIiVIiVIiVIiVIiVIiVIjWLlSIlSIlS1KVIiVIi VIiVLUqxW2wiWpSpEaxaxaxSpESpESoisWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsWsW sWsWsWsVW1ZWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLW LWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWLWKVi1i1i1i1i1i1i1i1 i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1iqraqqqqq22rCVVWMKiIpESoiKIi kRKiIoiKIilqWsWsWsWsWsWsWsWsWsXKkRq2OVIjWLWLWLWLWLWLWLWLWLWLWLWK24oiKWpS palKlqUqWpSpalKlqUqWottYwqIilqUqIilqUqREqREqREqREqREqREqREqREqIiiIoiKREq IilqUqIiiIpESoiKIlWjSCiIpalypESoiKIiiIpESpESoiKIiiIoiKIiiIpESpESpESoiKRI kREURFERREURFERREURFIiVERRHFy1xRURiTK5SuXK5a5crlrlyuWuXK5a5crlrlyuWuXK5a 5crlrlyuWuXK5a5crlrlyuWuXK5a5crlrlyuWuXK5a5crlrlyuWuXK5a5crlrlyuWuXK5a5c rlrlKiIoiKIiiIoiKIikRKkRKkRKiIpalKkRKlqUqWpSpESoiKIikRKiIoiKIiiIoiKIiiIo iKREqI22q1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1i1 i1iqqrWM+I2Rllllllllkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkAD15eXnnjeCC5SuUr kcSuRxK5HErkcSuRxK5HErkcaiKkSWWWWWWWWWWSSSSSSSSSQCSSSSSSSSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSRVVEkkkkkkkkkkkk kkkkkkkkkkkkkskkkgEkkklqS1JJJJJakkkkAkkkkkkskkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkklqSSSSSSSSSSSSSCSSSSSSSSSSS SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS SSSSSSSSSSSWpJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJBIJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJIBIBJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJLJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ567d6t23V222 9d5CxRTeQINQs0orQyIpICxRCj+kHQdH/3FBP2qvZF8RQVWhBVckB1RNYCGqqaCn8wU/tP1f 2ySSSSWFN0RRe4gixR/0IiJ/YRD0A1PkfP5hY7GJ1D74BY8MDkkQEFXAFzaP1mMkJCQkrP4J iKLeIqPr/XJQiqH59Mk/AuI9NbVVVVVVUBpYuH6AgiqG4qxw2aIhHTzxIY3R5E/1eirHSPIc hGTAGAKmgca8j4fs+7F1DOg5HJPsLHg1x1xFiecw/BN5ISqhIP6sJu1r/r9M/28XysiWQlsK QEq0oLZolKMSssRtbbVrqtbVLuD/V0oBZX7rCFBAAar9rYQgItUKvgOx+w3OhOhIB2IeR6Gh 4LmBY+WX9+b6X/H74YW8PdZNP7zdh/W/33CT4HSEOKR+xfartof9Xf8j7nw7C3hyBCR0QfsH 9bcCBrM9gY6dXDegnIbeokeqhZ+7ng5cz/I2ownOxBURWG1eUzCTHlptL+wZuHg/Q7v4P8zd p/UOWPl/+DQ/1J+hj+i8W11Of5fT1v9vLNXXxOLPpjl9sfs0xVclYx/Tls8OX4d3d+7s/Zp0 eSnk5dHd5thwg0EBx9huIChgY/YGNBgQBYWowWdBlSyqM5tRBj4BfAsIBnRRsJDDA1FhwIgS CmhDQGNnLl0bq16tmvJy/w93zPedXh7uz2nL4btP4ZRBAINS+Q0737CIEAhJ/xOBkOHFRUXG qDcXHBwaFzU5HpZhvwYvZ1NSxoczgsYnB6GRRoNmPDd1bvJTdN3yxy6KrH29Xdp7tHo4btPl WzTZwYaT7d2zd6PJ6OGOjHDTTG5Wj3acq9G7ThjzeGzobtFejZwrds7PDTd3Y4Maad2zwrsd SlDhAQMGBIuDFJBDYKBuGFNIcrb2HS1m8zzC8ymmUNh3/bXC869TyOV7b610Lcz5jtcoTsp9 pqx6WBuVOxLiyZUVaXcjPmr422ktuUva42tfCsN1yaiNpj4Y1Gk1OD5dmN1bq3V3ctn27N3L yPo/R+LyfufuPgeb1KPBRsdCjqcjM5HM0KNHs7PZDEzPBq4Ob5scnyY3e7k5vo+rg7vZweHZ 5uz3dXu7Du2bPdwbtndweb6Po6tnIezye7cd3/B6vJu7OzZ5PxYx1eHV9Hs7Pm/ofg+Gw836 jvsZ+zw2fmci5yNjGziZU9WioWyrVxrS+HS/XlpVsHu1bRnSVqZYenrrf9R7xVbQU+hgeAO4 G4FP9Q0ZzMzHIHYD8gfgBxt21nnB/ZT44b6P7VZe6Rjy85e8ZweVOZbB5qy5SM5eWHg6CpoQ H2AHcD6A5A0alwY/IA6AkBh/hHa/O5/GrMN989G5KkiuvLOowJH2oPBXBWucan4IEdtLVcAW tqlHQMZmSk3gxpDYIHQR9yF/QwIE37Tav5LQZHQ68xT4K72jZA2QYv0ORuu5GZQ6jsEM0HI/ YX37CNq2c699YIZBEbPtWvQ2qHPa1jt2UZHlZSppfHWsOxvSqGFJYP+Vz1Z4I7GDsI0khgVB 88fsLuw+sjATLk53Zh6KnkghAlyIXUN3PmnN28Zfyz6wybqdw0jQaugWe8v2Ly063uHKj61a 19iyTCXGWDKXAyY2IwY7ajYWrmyFFah98KLCBlaGN7WhbexMEBEDXkajuPsPwJGRpI7cjjIg DYzfwvfuty56JKlY+orIJQV09X89xn/VqIEQeSpcuLwtriYH7jhIsQ3dvFhVFQ+jG0g2EZpC mCQxC6cOgYcI1rMM3+ghwCODcaQxuwyJGrrMn7yEFVIAny03bZQO7A8MfN2NbMe720t86CKL PAsfZudDnBPGcsnGruMvX6NyVJEVv2eOS6eezxiLSW26MhVPQQEv1nzeWMi8JCqY1KlLKrFr gc4Mb6dWO6V94i2zG+11jJdhcWHX1FPRXe0aoGyLoPI1G6ckZlDqPIQzQV17BtIlzjw+aXBE bPpWvA0qHPS1jtyoyO6ylTS+ONYdjelUMKSwfq56s8EdjB2EaSQwKg/XC/Quw9XB4UnOzeXp 4IBCBLgQugbufNObt4y/0z9Qybqdw0jQaugWe8v2Ly063uHKj61a19iyTCXGWDKXAyY2IwY7 ajYWrmwSK1D74UWEjK0Mb2tC29iYICIKnI1HcfQ+hIyNKjtyOMiANjN/C9+63LnokqVj6isg lBXT1fz3GfrUQIg8lS5cXhbXEwPocJFiG7t4sKoqH0Y2kGwjNIUwSGIXTh0DDhGtZhm/0EOA RwbjSGN2GRI1d3j3mqGpmwBPlpu2ygd2B4Y+bsa2Y93tm3zoIovFrGXZudDnBPOcnxqzCJ+j YtEkVv2Z/evQkWDPjtGQlNnkKMhhuwYbCWG7VfGLiDGIDisHjphu4XUrIOA4yzFYLwvh8aCW QeCoLAhaPUC+grgXGedjtia854TD7KPmfREQCAgQ9wPgCnCU/Q+TdHY8qMR8EkiFcur/BX8g NsBQACgcQAO3nzzT3cvYKI7kjz7yztX+PTcexzBj3v88r2iPhx1AgYgX/mmusD6Sp7+wwhDl 9IZSsQ1D8zaX0BDwu2gMhcvnD0bA+wqNAwv7AxYcDz5Go1DDIsBbwj6Gn2oYQGMCwgQNO2JC IiDAKQ/sOFUKoXrwFGiXSoWxjufeuBWwqKpZLBamLHa1gweUBcggw0D9xDQCgEIECIG16dRP hUHGo2Ge1Vxq3e/pu+pzBj2vxld53pruuioN8ioziq33be+7b6nMGN775XfamhUJbDZEQIj7 C4MwY0Vh7IiBHEIDBmIwRaD2HuOfOfZKMGBszJToD0JpQIBuPA1HA2HIFwoMDsNhA9DYWHsB wBrjbbJkiHXyo28Z+0NCShNp+f/Cj+PZ9t2xjndcmw4kCQHA1A+IQKAPtDELHfwms2hpb626 dOnSeeFSB0D3Cl8KAw8ybvZuyeH8NOravRp+rdjyebd+7H07N2z3ad3R6P3curT3erhpy5fu 2ctlNP3fbu092MejZo/h1ezh/TuxsxWPtXLTZ/m0PtR3burly+Gnw9XVp7tPV2Y7uo3Fg4gd DInmThR4RRrrgeBAbIUZGori0JcjCQLCwW1hpcMI2FXTawcajsZMOyW0FTCWLTHgQGZiPIsO yHkM/ZQLELAhXsK91FRbTgY17Bgb990uYmhVbPha3wXc9wVyl+4Ux3qHGqdz2YamEElnDdCA 7uWRda9zTIeO6gYIXBC09pGehbsMDTtsdoCTfslsl+/Ye2Yw408FdWH73P6ugt5xzhhQdyBX 0U9hXf60bfz9W91fOEE8d/VZ+Pade2I36Psdm8lSv/zb+bcBzQ334SOBmWG4lD/MkRLuh5J4 H9h3n7JBP1iOYidlHiJJKD6vUeGyGpAHkMBVHgzfvDUvcIIaugZGZcEVu8MUAaTEUIKJSsXa 1t8Lc5b3el1V1WqxIG2oAAAAAAAAAAAgAABJCQgEgSkAAAAAAA2zbVfZXmpSlSlKClKUlKKU iUpE9ZIk09PmnojyP7xv3rck/xH6k9jePCw3HqyeqWHTzP6e7k3bK8P6+3TN+LbbYJTz9aaO vkMg7Q6eyun7EDcaHLiGh3fzPSGwYnG8inaZbLZbLXTRcEWe7aRseTlY4P2jdg0WHs4EPJqT Cjl3UZFjsYYamGx8iPs+fOVxRRSVMpZSUUqVWMMpcwylzDMwwpaWlC00o2KKKWUrVS1y2/y6 uvpe6EgSatpvgiJy2vXbbTqTd4HYqoqVIkr5Z8R/U5HopCyyJ0noiH8mijxnlbbbRkJtGtNd UqegDbe23X2Vy4t8rXfkAQ4OxHX6tttpNjDe9D2niYm5usnY7TGVVP3leUNSRJwyFK0OWNkh seXanBqKdnY42tq1dpMN2HqdXVshWA0mudUSSEhIRVAgg+ZTNjl1jzNjRps1BmJiOuJkO5Yd dJgU3jhodyRjtK1JuY4aOE2K3aGrbbbDmeaWYKftO022Orq50dI6naKe06pZvH7HAqRhv05u XLly8cc3kAX4a1krbW3NNrltSyVRpsbw8dkyS+2R2h0fT9jYT0FB8wMc+bnkCJwgxAIooxAS 7bodIaLilR1IwYvlbbbQpNvNONXdABts14r6XWt42ZZtrxy3BucFhU7mB02DExLmhkcqeQ1T aQkkJCCCCCCCfx84ggggggggnurV76WVwLWimk3kGxw0kMh78Jj2m8yTRY7LGRZItHQzJKdo YPd+jZu7umHbgti6f4OiJa1rWYzexWKtinzl8DAYXFxgzvghJXfB0nGIPGGxi9Q7u73M4wVi q+Dm+IwMBhgYNarbeGc2x3pz33yo0S4AocJ9HRDu7hcOEIuIahS0EWBn6jm0x7MdWOKExJiK lI+BjDqilPxH5buriczwEBRzAul+jd0tvmfMsD7BojmWGjuHsWSRod5J2jBdYZFkYUf7ZT2b Rh3MjD49Jh+fAYO0fvH0eDYdcYeciGj5k2Kx+q6ttttsR04ORTbawQQQQQQQQQQQQTm3KbKb KbK6rquttRT1bNmiy1atXdHy8ct3Dl6OkdHmeYbeI3k6l3FOIXLbbbaklR5O+j4cI7mjPFtX CRmVcMyrbVtsEEEEEETmq+nVua8plOsUMJxe5JElLI+ZeG8k2d2A0SCZpSVtJJJJFRAvgoWS 6DcawsmBTdy9VdmDGMYx7k6k5Fjqg0GaJYM27cPQCIYLNUwVgeS7HqjTAeGGBhSuJIn7nEZJ 0DR1c0uGCYFLAgUnZbB5Kq7vEJJGU+vS4HJRS8hIz1BQZQgBQoRMUrEkYJMi4kizFRFlIVUt qWL8ysfRjLXkH0phpLMmZqyW1lIs9rlcik0lrFbDWvhanK9bW3ORpQNNmzNqYVyDJYHPlNpV SqlVKSy0EpLogCa8/c1+n4bK0rkrTDzij8Fttt6Fkhw/DYmhQ+EbSOZE4OCFaq9GzGPJprpb bbBTrHD9ToN46xw00NRUd6nzYc/VTO8Q6DnQw2YZ0jB7Fh7bpkFLJSyUslLDj8ikpIm7djkP ZpycBdyIcnyA3CksFOuEyFkwp+FPVJIqRxO0+k2FIKERUkVF5Z4ze1WltPUvxjjaY443xrHG 8d2Cu7oTu4V3ZmkbigpWgDigIACBSgJVB29u7O88wy1mm0bZrrk0ZrSscwxjEJDIml1jiGqx mrhaqrWoZYi60xW8MlhalaqshlgtharGIxYVjUxMXJWMRcRRRNuXNxFtXerirLmTItXWJlLl YmoZrEQ2RpZTS7NQzeFWFWI03hqxEiVkVFWN8ZVqsYm8NYtVZWmJ/okVNK3pu7e6t2rfSQkC SXLlba+tKt1WavpNq5tpq3Jt4hIFVUVINEsRJFJTlYkZFh/krIsj9Sw/KxvJ4edttueDUgxo eN5CMsO6wdYskPsyHU1EE3LZSrW+Fd1uWtmpqvOJIhVWVCyQkWUmiyQjaLIPsSIIq+4mINAr 3SgaQhBQ4YsR+j6Oje55I2fq+HENj9Y4ScpfU9jq6rv2tetXXQCtvflbrS3kqgLaSSlKWGbJ g840ad4YqRjwRUmFaK0rc/iEyTDiKN+MP2NClHsescRvCtspz6r8bLWd9aa1rTWtaa1xqSaI WD0LAr0eFenZzPUYPyeGnNp0Wz5uwXcWOC2CLAzAgUOXm1X6O8PHA5fB7Ro3PuOqeexTBTIn GkyOGZbbbzFkwome0erq6y3SimqokqimikUoBUIo0qZJSZbenVc2U2U2U2lNlNqU2SyUo6Mw uto4DRsdAp4UcOj2VWofXKZEdYUMnSRT9zQzZ83hG5zhAQQQRGX6a4ucJAiPnzcI3OcIIIz4 3JZLZKkqXBBPNfD8b43yvW8bclkpScmWrzmVdDMq4eJIUm0lNm2rDQp1jJNjvGGKbRT0KCkA eVhPI2MQsmyoqpGjUVpE7joF9Gzom4YnhoQjiOQYiqNN2wPx8gOhi8ijQ4DILGrdHSmkaiMi MiY1jWNY1jWNZy3NbjWNY1jWNY1jWNY1jWNZzc1M+mPMDgd7Dx0MhrSYHlGTzTRnOGMw9p5p Zhp3WMHB2jJOSyU/E6T+JZsQ5cRhVPwp8NuljFjrtbbIjy8HMwLhzSA6pAsLoOw2BuAl0wbf ouGoxNoahrSZGhE+4wyNMiXtUyPI+mzQco941O00k53OlPS5r7N53tm+Gbzt6UqU9SIibawT rYakhqH5xMFOser1acHzwNSCjxAUAYqihFQZKWBcoMhzAxsGg6uRklwySwUhyoaV9KGkbqyz 6nd1VqTcsili1Yb4WEpGImGFsMgaa0P0naYaSlinCODJKU1lYFotOqKfkfvNpNSbhs/BQB+i FKm/LDFYEA2CybIWT2OtXn0rbWV5QQQQQRW86pwe+2tI8ZmZmZmZnsfT1eFbQ+OExFo6U6Gs RUsQOJ8T4mTR6kedUsJcOh5xgo7HXI2hhYbSYWMU3csO20MP0imQ1CTDg81TY6W0f1fenvY4 NdqdDrFjpHaMknYpt+sechCSSyRNSyEnmclNEblMge7w6Y7vueyY5k3KVEmJJFN3GPYuESzi btN2MNk0+GaWwtid43dBsUzPH82227HkWTY7TBkd71/CJExmrkG0lixmYYU+6aNTBzFk1tTU aPhkbtRPi222k+27ePJyc3gU7xgjUU3jauGNF0uxri2221K61z1AV18kRH27xfNpsql2nlIR IfpxbbbbYKjBBGB0BsYJQIcsqWBw5u5wfMmIWxiyQkkIYf5PecwqaN94yTCnenp8KVGGMbxW jhjitGzUYfiKcqOxIUfDpJjVVVVVVSQIqoebFAEI2E7LYSzUJsWApZJSxSNpgjQ2jUzG1ttu GppGjXyH9lttsfvDLcLTSzTSttirFrasbYRBkUVCSP9h/wP7BFH9SCEEIERedSalu1dajSqa VbbjJ1aaqrk21WUrbRZlraLGtMzLa1SlsbaKylVKilJGRZN3GoZDIpFLJGNT/lJBvIDBEk3s ID/wkRLahEWSCpCSyESFEEf1LljLMsh8fx/Z8RzRHo+o+RlG7kaY+322bx1MfzjUn5tttvQw wmdYvFXRJikWSAZBAskBfoDA2/B+Ix/oabheD7SBNq/hle/SrtRV3ucoqilv5+uyqrtne/Zt /L7etfAAP5M83Nu/iGatTRNP9Ts3NSq/Ybyj/hJsbaG0pLJmDJqYKpk1h/iGpYc/n21xN55D 0HggfqZ8P73zD2g5bc4ogysoxSjVv+SNZY7WccuHQs9ZYsrudDpstbm6aLuZGQ6vQn/En+E/ mSw5NhcRzMnmeRO84Es4hgVOJY40YamGC1BQQGNqChtNOnl5cnN9Tu5WegpuFB5Bg5Tcz5ZT 7kJ9WIlZUrFIVln+w5gDXmXNw93Zjs/i7NPzcQsHxyOKorzDUcA52CgC4XYJs6t2PoB8Dk7H q4swAnC2YKecwyeOZo1OPxNGp0lcdDY1xMMGB8wrCXPI8/fP1ttnjWgfQPq9ISSMgHQP0mED 8g7mB0flfuqqqrAAy/TMwzPiHwzN+xsHgPIHAIGWDRbvRXlRVuqgu3p9cNnJzO/z+cPV1tm8 n5Bd+3BBQKCCqhQdfn5yw1iNYjWcMz4dZ8jwEPiFM/dncPAaHn92HkdxI4K6SjpKh33XuiRD uiIh3LeRUawtqv9AtfJJpjj88vQ2LvqCPc7oI8ClKWoCG9E7U1oDMwnLM1GoGZlUiDEzMysb SYYYWxVxGkyIwgZQ4DMfJs3LQlFSLZa2PB6G5u3hyyKZDJIRqaczSCf91Dn2/4TM6+QP0PsG /2s3vok3aLWvDHm4PmYe2WaU+mZy7C9QQ2cDLN8kpT6h+1+8Pxuuw3ddhu67DeusD6Z34fpA zyCe7NTsFwxtN5UrUIFZgAdVbxy+9MyjsITvtk53saNhPqFfOTqHIPhhJJJl22qTyqqqqqqt 6O4cw5BjycH8wX0TyDM/AHMXAPtEl6T4ZbPrVfDgPRz1xTR6SSSdBTPP8T6ryDUHcMPHqQLn QxDApNBQbxGg5H4EfsDK7j8fpv07fX1kMz8B9Xs4q4q4r9Q4fPPQddjMEbbu1UyNxCNcBTRr rk5Ghhg4FWwQ/H84SgoP5fHx/OB/QKLSlvkZ8daIqtp3Nj7rTaSh0Q6qaq0pRqJSKLRaLRab vSa0gQIEApUJMK0Vd3ery7u8vLIHoGAilaLRaKFBXZosTtQUoKPaY7UA1QiIRIhY5gJpFd4v FaWdou8RNtiUFQV28flOp6fkPh+rEy+X5u+OeE6z+n8Lnr+XT6bYCfdAr5U/5Cv1204fQqp8 +TfP82cMJ7/E/z+z7dsV2v3Tv3xB+TFx1vDWWYLyV8KHzXF2FB5IZPGjH5FtvOrWtXz48rDn gvM+X8+X06tO3c+3a7n5MeOt1Nx5c7Qgvi97sKDyQK+VPyK6+dGLvwd6ptfTSI4IQPUA7n69 L6X1b16fnxme3ndY4ZlD3BADNAKUHCL/Rx95y6wQgxk6AD/1RBP2h/WH+SH/6UIIv6RAX/YM Kgf6AP+oftBVQB/YAqoA2/zSD/yKT0MxBF/f+8/WMM0RSmKKoH9xAAEGlSKiQahZiiFRUiIG pqR2kfsfwV7CKLEAXdCPOQP4rzC4f/P/QdTyAc+n700T96Kj0D+B4we6AI0W7GGQoi/8Tqvt /sJYQRcEwGCCLcEEW6f4h7H/zs4E+OSHoh/6RUf5JYQReoiovuEFKYU/zFEUkFQeaeEsdVQX /2EIiowEEXwhsnpwGacz/fgf5+4J2UJOhSoRJyfgeEIk4kn6fzub7nWL7CKLmcgGLwEUiUKY hYQRa+AecYHI8k7v5l6BzE1C4cIYp9DwnYD0RVE+J9BTvuoC6Bkio90AXE+gdVBN0MhFFzDs HqdU6pqh6h3/ZuHMT0SAKP1IuYb3D2CBcHVNPkCIvIQzH0R1NBvH2yOiex8PD3iSJ5dZD+Hb XMX7PwabH0kfRHm+T2j0hUf9sWfqfR6IJNVCJKfvD5Oqnz7XIZHMjooC+YoIsEEWk5pA+atg xBFEvoCIvHg6bDsnu6hLt/yn5jAURfP2BBF8HQ8niJ5B1N0MkL8gpOXN+QQfyGSYPxQ2CIbJ uA7qm6e4eoaGefiIeofJN1Q4inf/V+hCJOhESfrHRIp5Hgpuh/qA81AX1EEXgvkHolCgn+/+ Nj2jmPY+EIk8zZtGt9rCxR2ix6xp8rBTslZJYPtPiAftOA+Z+0/0P1nxP8DEh/F1P72B8jE/ eUbh+4f0n9mXzk1Oa8rn95qfuIUHU3MV7vd7NRjofE3js94mHmrCyx0DHhP+EkkkOXWgzzk3 /g/4vX/EAyODzTA5PUw+Aj28mg/7mmQXrMiy/DTf0t6hu6sPxr14cvdH1KMgDEwNieJLdpMy 5iD3Oyf5th7sZJwdz1aDtpsf+lHg/FtttPV5Kn/oe2rd2SHZ7O7u0Huw8Pg3fd7OQZvbbb+H DXc7O6N3q5NdLa67W7P2B6Q4ejZ9xs8FKdXoxurTzdGxh2d3HreInksr9owOqh5To5PHT1ry dGPC7q8m88TYAwTDu/5uZsFyFEObxI5mxsZHCxkhEQ83v15ty8a31vugAyQePld3h4VXXTsn MHYO7rxsiV0YcndyDlOGzh4dI/c5Djq6tB2OJv2ttt4Nw8n27jJPr+PJrO/ajFvPHb2kufAT gB1jjLtu2NneNOJCt8L2wN+d8zKqaB+zHZ5eh99lx1V062792GnhStFWdP2N2mzcjg6PXfw6 pDd4fh2fw2Nznvxt69M/Ox7ZbB61ZcpG2zzl7xnB5U5lsHmrLlIzl5w4UgXLZxiVChQoUMwY MGDBqXHQGgwNKDAGAAHKhzNBh0E5HAQ7mBgY6SWehkVq4q4ERxqS5ZG6O0dsXGTqYEMgAYQx cD/iw23i+N63wvFy+25wDfXfxVREbatG0CglQLRIKqFv/QTi1Z/zED9Co0CIiba70Nw4ej0V 3obu4cGZq70N6OHcW+OLWOSiBjlz2K6uQ9mNOli/Kiq9q0ODGra6DuBo4lBZ1aFhkR2rPOqq SsAcRMoP+LsiezQ/S2keqQ866WZWWZWWYuNa186/Kr230wzAMwHmvr+rIyMgb1VVSkDVcPz0 PMUgQNloXpwXEwfE0SHSSJtOCxO8Q+MiGzofg8Nm0f2gT9U821uMWsxi1mMWsy5GkyZU1Siv x9wFvd/Gc2ufYGlg8BmJmGwiXCDZUX6KjYiU9Edw5CULgD0S6b8SSEJsDgmih5mPvbUbvD1P lpT4kjY+04tttVIyGp+5u1xjcXGNxcY3Fxq2995r7q8xsRIP/ESpPiKT2fsf3ZMq1atWfuzJ P/X93ZrNXTW1/EJhwNTYnwbB6qhLD4er5VVK7plLZbFtfh+GpCT2OHU6QZfr+mGYwzGGYyT/ qElqxFFRsWiIjVFioiK1FrY1aLUav3sbbiiIiIiKKK2KxSbWxkyYxjGMYxjGMYxjGMYxjGLa KI2qgk1RLWMVbUarm20102oRaiPJMjEQkPgeT7Y8/rH9eutNV/mZHYGENuijkg6h/zDFO4At xMT3SQ+n5I4LWYqwmC3TSlMwmWEIFDMQqwkkWLLKkSYqRDSpAxGonDZVVVV8mDBRH3EhPqMC KKQMD8gNw8B1dIzClqqWqpczDb5zw1mrlBLJTtPqXyYzGZjJmN9TSaWqMU1tkbSHCdV2T/M3 kbGo3jqdJOvqbtnK2slvkxpWpbpmq1LUrCEHJEhihJkpc/llPgQIQMcN5EhEnOKSy8VyyrrK 5XN6222w6wGIbyIpz1UT1WVfds+Ww4DA1CgPCPXA0GN0MlNjzD7inXA+RbTd3Tc3a7Lu3dLm 749w3SHOP52EpC5MxVzaZoxtw/VmMbnJHPvHd8o5WOj0fCUKUSWV1VKqWqiSSfYrwn4Pfnq9 /RZs9Nb7zGSAuK/+svmmxgbrQcEEvnJJJwHY2BoDpoodiJBeRznvHV8FrVxTLMXKxTL6e4Jk cVbISbnCaOvwTPNg4ODrHRCbBuaoEDhsDHFIUNIOzB44kkkgEUTsa043bxI3bFSmHSH0aI/y cPYhJ0UhD5KyLfvPU95sPMBYpj2KQh2b2nadpsO0BYpnYht7V7TtO02HaAsUDtsKQh2b2nad psO0BYpnbZTuEDYmSbnn28Eea6Tc0CEIEJyUJlw0x9u0nz54c9FPRJ1nd84xmMZjGXKtYFKa eoSEhJ5M/X2LIflFLIMUsgx0y1rWBIj6Wlk3+JkZkwbcDMJyuXMpoAprq9b2tlmybbmr5nQf 8z6mGn5fA+efI9iSh80RBVC1pRGu/nrjjiuO733+LvxK5OvXN+vCQxGgbRwIBpmBDDQgG4c2 4aEw06VarXXTpbbbavWN4PtT3YaUqikqiDZMgOEepQGhC+EkkkV8ycRcjvJLb6ocSeZvFh0i WKqqJqI4Uj7gg+pYpRVnhhhSi3MmLY/d/Y51NKVJu7muEd986kO3NKVc5ciO++dYaUqTd3Nc iO+6sQdcPtEbhdlpSECDMfFWzlXqiJExzGBhC8/iJzeEDm8JzeEO3WyBbJmd7SaJEWOpkhSj JJZUowhUZFEQliySEgwsiDIqTqRG+9tuhs96rdod3nIR9fWGyTyVEHu0ZJMNKqpoNCJ5LJJG VZIySJokECk7NC0EVTLOlQU/BVT8ROrg2kj0LBNyx3WDpE4Z+YPoeSJqQ9ohPWQgpkObIkk2 XJClW6MVENkGBkQL/LcqqKqisxmY7xtDoLzhFtsjr/TVW3MYtt44Q5y5B1ZVrlKqlKlKUqIi NalKpps1raBbBRRKUShZIlkmKMKWSmGouFshDUijDUWLFw0Yai4aLIpZKJSksMNRWkaJMmku iaIskKYaizSNGGoqZJKZFZJqJKUshqMMiNGosWKMGhMNRWiaLJFKUKUUpZBSUyyXJEYRKMNR dGikWQpUhCkpGGouiJqSySlkZRgskksSihhqLg0TDUXUNAsksWJYpLIqDMKai6CWpogw1FNE 0KUsklgUUphqLg1IpLIJRRhqLhGgopUlFJSiksiihLCMNRQ0kGihKUUUw1FjBTIuDRZIyajR JMMi6k0WRSlMNRbFLF1AahSiyFIqJZEphqKmE0YaSxAwakmopMKWFKWRSLIpqajDUjU1GBqR KRRqajAmiUSkoLJKWSiUpIoopRRRKUoKEoooUsiNQsWSXLie34wzMMzDM2aJJN/bu1bVq1ZE h+RjTIMY6KBBPx9ZnKmdwBDcnkgKCP6SAGYqlkiJ3SeqeSpTd6BzaIVasq1ZSrIk0n5sA+in 1smAg3o8BKqqqqqq625xLgiepvJJJhZBlcpJs2JkkEmuLcSTqfoKwTkqSJ3fTJCedWrV4Seq yKsaIeDDsQShzAhZaVNtqDFW1tSmDmLyTY4hy3Ytqy2ysxLSv2LGpJKmkkosFQmSROFkISbS NGCKSg7xhzFI1FFSeT8kp+DzTfw+ePNmScm+7dh/ZU6wdHK222xEyRtiP3gUl/wQVELglEzj C4eu+1VVVVVVVWghISSMg8EBwPIoVTsiWXPSkT4flN94bkPMwCvSdbO5X1xAwYA+0PUOv38H BuNutFmJhBzm+lG3LfK/BoaGpcxNSP6XuXCBiLW563OmtzQEAxCmCxqd7umkzVXqWmlkAZCG ldR6BYbVx5jZiFilNi0NQRhZ9LbgWFRRNzFmJhF7TXajrvxlfmaGhqXcTUj2exsWXC0OlcDg FhtXHEbMQsUpsWhqCMJw5il5MJrvvo7V434WlX30PFLkYIBCFMFfUxVj0iJVxa5gJghidhwC u2zjiNWIWKU1LY1BGK7voumOJmRgXFE3MJSJhF7TXijfjllfoaGhqXcTUj2ehsWXC0Omm52J vhzxO2XTCGszt0nKrkosTG8C4j+BSV9tAOBXmmPO816S44MOfzys95DU9TmcFFVVFFLmMyVj 860kIlRqSJMRMSoQlMaWFqfh7NzmCEkmL5GzTrJoUeps7GXnjfPr1z8A4GRDq5HBuFyHTStT k7sFHotHAOlxbDZkIE71WqiAjGhERyVElhIRZWVEhGNCIjkqEKMBQEAw841100zpIDq5mbw2 drWtmaoanGkxhUuFwgO4TTCY6TkbAOD1MTWm0cm5xqE9UNzMkiU3mmRqDbZ5yDT1tq1avJ0c zq1G8k1GVHo1DI1GzeaRqNoMI6rHQiwb0wDUslXnBtZDQV0RAs7hkmgCaoYAI2TCJSRMokwF b2QYlqSRL5NdcbR1KbbkTIsZhwWNRZJu7KvcFDNFM7ZJkkyA4DUSAQE4c2MpSm4AnMFWpWRS RSVFJGZkIZPAVRQMcAYAxDs1FcI45yN3prpwkOTdFUlq8q2T3nke7LWxCL6BE0TeSSSAjs2h JJLascMPrUMpask6dcTY7Heet9ay5KlRqVAomjCmQguIcI+58yxibFA8jtaW0tpYj7FKYyZx 9xhISEgZ8w8nWCGHfL0dxD3D3w5+CZ3LS+BHESLazTTU00zT9XX1JMabQhRYkNrC2FsMVH/y SU7RK7QsnfjDqDZC1+offJJJOQYhkdDyPTtVVVVVV+gVH6EEkkkjJJJJJJJJJJJJJJJJJEkk kkmIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI2r4Xn4Sr1WQfXDIH5B4M 85DPPo0/mX9ZiNZiNZiNYuzZVzWqy5TR7/2TYpsOru4kHcq7pv+iIni8X1+0AV/JXvteu/LT 3cPe34TDYbtm0Nhu2bTNhu2bRM0uHvJ5taVtjMgcAon83D3/d8rb+3yPJDSfGSS3qd0Tc+vr ocmtaNzhyeSJzDleWKXOriB5i5rmYoYEyKKXKuSh7fSSSTDWu55uXNvPP1bVuXQFSjGM776m obPk8eSYNm75eTc5v3cuXLly5o0TAjUVSUIZSmYIUOg0CgmXKNGEhopN6tWrtP4lmk9LLRO/ i2223DM5HQkdnaKOJ5ya8MTDdu/u3iEgTGuurnSy03VdX6X7b3+/xtcw9UgkSdzHKumHwaj2 5emdWY7TdPTvWXKy5WXK5Ts43Mhuw9VJ9KYlPHgmSkqWJR3ttt7j6jUmc25PXRh2zFoBTITL DApAh29f0otYtY2q07p+dxB2DsehwQfMtVo2uXteN+WPt1100z0Kla1rWtazUqVrWta1rNSp Wta1qmv9oa7C9xcgZAH7FKJcxlmMsY9zAO/2cA0ND4HfCgHxIoqh6mh6FVVUZ2589en34WPl Ounyy/T64zjE4tnMVyyDJZrmM5csuM2zmK5ZBks1zGcuWXGbZzGnGFjicacZccYzDjSqqFFF VJRZ/RCQkJH49PM8y42sWJOwn4vOEhISfE+qOjnPwqqqqqqhnjxJQQwhmnCEk+5bfKoxaqjD IveiZF2i4wqj8Rws7HtalA6ihitjMyOBtEMhtWK9lOyN3sYf99UMLJsJwcv0PRhsqqqqpSeE Sg/AR6g3vOLDhEJCMHeqFAYgJAUYCilToO8CQJAlgpVfsBiGax/mOGmoyP5tttqekVs2j/JN jY9yXiSSSSVb3W2vfbfq/CgBf2Yqw3PNXLHyUNlTDtP739uvn/b8Z0/Hp9Wta02sdrWta1rT ax2ta1rWtNrHa1rcClhQqagUDR5vOKR0lhybO6q9OcqdSREHCKK5H2oCCrETsQ8MYwGiImKd FNvzh91atWyDqdTHCqrygUkAXGw3TYcioUKOQJAcSHBiAYiIEB4DsKAABIRd+hUczDmB3FgY uHGCO/uzntf7evazlvrfXfe8aQ5jfU9nG5HfLOe99997OTW+bXY7jiS9nvvohVqMWxG4lxuK qdRmObqGDGEWuMXhYMwt14uRiN5af/qM8accQCxhbNvv0KiZhzAuNwY5DjQjvsznxfrrqzk1 ubXY7jiS5ffGiFWoxbE7iXG4qp1GY5uoYMYRa4xeFgzC3Xi5GI3lp6jPGnHEAsYSlOjE6nzW uZ55s96w5iyjQr22dz4t111Zya3NrsdxvJcvtjRCrUYtidhLjkVU6jMc3UMGMItcYvCwZhbr xcjEby09RnjTjiAWMQXD3jjjoXFqw5gWHAMXDjQjvsznxfrrqzk1ubXY7jiS5ffGiFWoxbE7 iXG4qp1GY5uoYMYRa4xeFgzC3Xi5GI3lp6jPHLt2yJvvljRFHA6ICLH31pAG8w+ymzlcCSRh oWNHSNkWNSPU1Nnz77cx8gnDCRpcM4IEJLiLUvSwodIrzNlAXk1RERCgKxjONhKnZSQZkSMB ZiGvfMOFTCYFXOqkgxgXGAsxDXwQfAcIogAJAYwQMBA8h5xQMLFdXZjd1cujsctnLloxjjjd w45ccccavDjh69uOxJDE7jvjsho9IcbNGdfJs6DoqXDpDkwpsKYdDpg0Mw3kSmiskGsahx5G HBJsnKmjfvp0nTdNMRhipXNbOqSRib1QzAwVsW4KMkaQyClXUKUDkIcZZVmZmb7uybVPJkx2 KMpF84LizwuF0XCVzhlWnE8jTfYzCsWVahflbC1rWuOpyDYfUOaDSJgPIuPJkZGR+CqInKqL YFEfgQshc98KCydXzDwbkBAERF7aEHAcOHDs5BWZwEdnIO7gGHCDjfit429ldO+VZs5XJWFT qRUqNQYGrdgGFA43mxmeZuzMzMzMzMzMzN8Cgp4vSiRE2K5j0Tk8Pc0zGZjMxmYzMZclllpQ pSlhND5b+35IqiqKuG4faT9O+12Xdrsu7XZd2v2OQ+5Qz7vww6MzP3ZmZmecgT8ZfNNc1y7T U1y7TUNcu03ETE1HdkN7C2mkQQ92N07PYIWwYAFEAEaGZmZmZnUAqAh6F8+d+yyTMzKxMzMr EzMys4IdA7DQYGw4A22+Q2B5CBAHch5fXfciIe6AOqr8be/229bVUv62kiJH++Ca7nKqqniO 9WrVqPOQ+5+KtWrkgJCuHFNk0Ym0FFHknCWRENOlIDgyEkjJCJBWDKsaxPWH4O/7Rs7KtW22 1wzMXo0whIQhHe+wd08kS8HF9WMYuOdB5o215trattltWWK9TidW0bXwzMMzDMwzMP1lGIpR +ZJCQ5esk5e7lSABtUD378Pjd9/Hd93faSSSQH3Xm3v09Oq+71OV9u+eIMZZeg5593Lsec8L L8MmMXJcZMZLEqKQPU8xU8kduyWRV1fJGhB6AnMPMPB0k9fbD5idCeA7xKNoKG8JHaBjcT+U RJBfKKVBCorUVqKVBDKb2227Mu7WhqKIi0B/Bu3jUboke56SdUR2cHqamVbbLR4o/cOT+Okt lstn6M8mI2U/J8x8HBt2ej7sY6g2RsNI6G5ZSg8IijSHQj+aFm/t7+tR/KRMzEQImRMyszIm RMzMzIlZJxIUuAQpT39aUqqCFE5o9g6h9TpJJJJhhzD1TyUsG3HkYbPeikwIjIiDQCmGT0cv 1fwxWzZukhPqJ+rZy00qtaWtJRlmbwfMMj6lV2yIeqcGxNTbErU2jqa7A2vBXFhF/bTKEQ1z rimCIbbJEaJXBTVXXUjaxaKcgyZjbDBAbCXSMNFIJCUQ4UhSoDjYGeIBDagxRdNtsoRCmmNt aYIhtskRolcFNVddSNrFopyDJmNsMEBsJdIw0UgkgJOBOtcmjsETAtAqosQYbAls83F77bZQ iGmdsUuRDbZIjRK4Kaq66kbWLRTkGTMbYYIDYS6RhopBIya4aBVxBClwJGwM2koBitBgNptt lCIU0ztimCIbbJEaJXBTVXXUjaxaKcgyZjbDBAbCXSMNFIJJGtbgUABlqULyNBHDbc0MjExH ohHn05YabAnKSSwenciJjnfyGee6InFc+sdBO53SE3lhCHnzx6vHm6PI7q81dGO7St3Sd9lc Orq6sK6OFdXd5G5sad2mzdw6LZhYEYGBgXpNLUsNDMCkVIgwIwrYfWxYlnEYrWozZRIriTB6 YQ0M7CDIIeTMiR2qFF29jDPkOl4YFhETIMjGa4/nrq8a5TW9cyHzFsC9lEiuZMHphDQzsIMg h5MyJHaoUXbUwz5DpeGBYREyDIxmuFWdVGmrZ2sQtCg0IqBRA9a81rnvjTTo9hIQKixSsZr8 twPQB6wzMz2yxETXoLCRkkHsxPRYaJRCnQyIGFkWSyCKk5VE0djbSWKXWJtGsSpCVJtGMNTV WrVgkME01K0TSZJIprLZhkYiMIspyjCGJdyWTeQo0XcjvpGlG0UymGSYmypGFNSEkZJkWVLu YmEnErYRolMqTEpTMMIYwxMgbVJGCyKVosOsukvFMFqUVLKlorCFxFliQgtMSyRiBRaWlhGx iYqXDCoplKiTVTUxMmjyow2gwxhcMMwuytFskXRRS6jQTDjYyTwbJ0O8cAgyssYJVVWVVVRL AxUBR3Fg1BTIMAcAwOxw2fTk6vVu+E6Hk4dGcW5HB2dJ7v0ZPgAtyesZGRkEBMktjZVDNMAz TG1wgcNI+QNh1EWx/Dwv8GaECEknOUwlONymQ45kpxuTa9ty4wKPLGCNSkSMS0yD+JbmZMrL mZM/AwLw5hDBssrkcwHgE6+SMDmOy/NhKYrYMTUNRIkm52earf4tx0366zVhziO8a2HfM660 3nTWw5xHeNbBP9Wd9AnTeYPHnby1+7ffe2uOLc1wZltu7uldMTEXcXU4RPTndHosTqfyjrxX 3mM1OxwU4cqmcYzMZmMzEjiSk7PwFthFUOan1xB8JFyNSUEGVVBBlVhUuZhUtkeTBhY7+Vtt tP2JsFldsAt81iSRNBwgqkQOTgCFAcBmejwdve2222p0GjJJJ5ztnWQ7zlRLGqWNcSxu5mGZ gO/vCZKXJhAtz44dzoJ+AmHwDP4To6ysWuQRytWpbLaFFFmrSc7/MqjCMIFCHfzpDwnY7ScI nhNNT77W5DIe5o8GkRNoe8j5OjmO73OZOkG8T+HiRtB9nlIR1RyKUVRYotd8jLMeKlptpLU2 jyP2cHJ5Nzw/u8PnDdyj6qA7FQSSKjhMax7RFjWxHWJ5coDg7FDToDIEzDDM/TPRH5edN3d0 3d3Td3d1MmifX8ci+EkTBEAVYxDcy0XhOZsHSlpaWdZI6HsnnvmZmZmZn+JQ7B5QwA+vb7Ft 1XGC1Vxy57wiXD4huGYKDSqdRcDZPHMxBuQNeCg9uhzu2sWsFQz90cJHL+9YFVpCGDqlQlav UqwKpCGdUqErV6lWBVKQhg6pUJWr1XiFptcAAUqEghS9BY6Qe3jTTd03OSh41Dc2mbsknVED IGEGnL97bbfk/J5CcpqQ6FHnEp0jdN0ihU6xPKQg9x6we9FlT/IirTYkJ5AHyIqLNThk2htY ptC1qJGClxg+Q9nhoZQ4ZmZMHAy3CnMMhP2E19fFp0p90vskyK221f2uPTjZ1BUOAbu7K5Ox +5M0ITCGUMCocUZIJWhlo4ZkZoQOhxEEhwZMIZQwKhxRkglanIalAABRChIQtEojiQ4GxAuY tPs3cTFw992vadZCzdys3IWcME8UIUoUzBudzOEbNobpYajdUTIWPCSbkbStlWFdQSk0bxtD RkYJIaVppGQqMZEimSThDacz8tRvqMjAkQbqWCmxegvOJmYmZiZmJtcq+yvpkVM2QqZrMr8t 5tvXUPIegn3t9S5G1lI2soRtZgUhkIh6sTMuZmLlzMwmW1CfU2fbC9Yl1Xe0Rq+FrlvSSAAD E0kpDQda5wDltpcvF1rkxNQsVhGREqx5MjyEiptbbbB5BghR+XhqSMjIyNsEfSshTfADmokx +GJHqbttEibxkxBwNJKknruzs2749+pvZTTTSU405ra69W5vL1b2c73p5762mk8+QAAA+y5w AAAAAAAAAAAPpW9q7uV+VvHxq9+R/BKYVKJJUphVj30Jg4IqP8djHHVFP9/tPLnz3OfWSSTU 1OBJcSxKKKA5V2MrySSQK8ipE6xvzwQdCwfrJ8vy5fspa92n3YempOHOcXdxYcanHGcznXL+ sOlLxRytdFXiwRBaoqLFQBUpS4c4pCQLmBLGAbkDlr3VbyEQSLlS5WFyoAyBnOKQkC5gSQBO QOVvdVvYIgmxCosVAFSlLhzikJAuYEsYBvCs8Ntr32zLWNNtfsWxVIA5QH5KCcfKxhyJmakK KDVLA23vRAu4Mc3Fmm+P2VbAnnrk2XbfnnNbrzzy7brKVWHCrZa8e08DxZa7fMEgSfGm1q9p a9dquUCkhEFSwRXC4UndXYb6ySaMMwxUMhLDsXKMSyWNR3DRUe/fdOcDkQfy+zjjd3OXx2R4 jwNj08NDZtEp7w2PI2KwPHjB0Keos8o9o1ZZ1m1BhNfhe6bKbI02RpsjTZGTaWgA2q1NNq+d S+Uaq1au+FO7utXDc/mJ8nLycSEeROTafgyOJEh7MtttrhO7km2afGeGbSaXZs0nzGtf8EfL crgjoWHCWPzr9zQeX1Bwyztra1gdOUj2NIRxDhKCAdRkfv3Xu198W2228Gv0d3cNqhbBbtRq qaa7r46aNGjRo0aNGjRo0aNGr3Wtrxturra2lByEhoUlH1+EkkkpAM9T4pbTMPgXG5P4jkw4 Z/k93Lh/KvV2fu4afh1dduvTreevV0rX6pZrVdLKs2s6RarrKNG9wtXtCXVa2s6RerrN1eUu tXtCXVa2s6RerrKNF70Wr2hLqtbWdIvV1m6vKdUpSlKL4+sWiSacXF9MAUpQF4BDQBvGc4s2 dZXb6StavUWtZbWsL0YMNBgQCFhgYDhBcWFVrNSitXSta1aalFasla123rWsE29rDGbUHIoK SJ1KKQciK0kVxC6tuNMuON+JhtxscWa1rVsTWta5Xu973tcmve1rnFBQggAyB8kRERd/awjg m0kkkpb3oKrG0kkiXCLa9BzhtE+jXe222z6U4nJcNn4ifNtYT51t+z2u3s75b5bJZLJdm3v8 9z18/0AzMzPlGljYM3eGepfo3T4KacErCBD3Phnw9u7iqKoKv3hkhM7B7h8j9TufM7R8/h/L DTopVGKZTL2b2Z7MGYtpyByNo3Xk5ylGZdLlNgcjaN15OcprmzFtNgcjaN15OcpcZl0sxtTe 6zGs21vd98m61H2iSQ8fhx1tbiXCnRCEO5O7PdyiQl/Pl6eIzgyTLJvLx4jODJCxMpqGkMEm WBZZhl2it1UxUmEqoooqSthVKrH2jsscRMLNPv6/QHxAnDQRZJ8FUllJyiRkmuMPp1RlUWtr Wq1qq1vS3s2+HbvXr3MMMGZkI7nojzhfTMZmK2YeUH+X24/jT6um6mzTdTZpupunrv7nyKAf oqHsZzLAMlm21JW3XZ7/p9oHLmvS34148+3YduaZnd7ja8qrXbW2jM7bMtttyOSGtctiT3MP qOskU+ojaEdEsqibyA3Yc9PzB1xpw+V22/Te+Hg/X8GJO5XMSdFhVJKJSFCyJSwqCJYVJZEQ oogjIMSKKE6wjYPYXALjhFMBIRNjW0kkiZJYIGghyIqXV5BFMoRERa1a+G7GMZ9bm5dV+fyA 53w8kk+X4qRVkWpFWW5AgTJmZpnktWirJ55iKYOOwcNj5ix59szMzMzOffY0eqJ5qdn/+xIS jGlfhcXJQzO9+u8rwPJd+s9W8uenebyilLiSwN1GBduI1cZG5JmqMCzLbosjaUuJLA3UYF24 h0YEMJJCwDihSRYtSwVFSixCCRFVSkQBL0txgyCaoKTMzCwNwOoGEeIwwICQSRESTm/XZuLJ MulH8HLw675LlxR3y7dbYSnRMwXbJExEpMMAIFJlIWszWECxpLKRocJWSRtNpMgu6aZMhI2b NlikWSpP3mmFCwqrDMAHc9WuuVVzlqq7gKVeElBjyhEQtcruvhrcq9t0iJ9urqiaVOxydFjd YNk0wknREkhvNoTJ3MlBOHEMAx3zRbgaomQQIFhXQgsi1D5ehSDZdjXU1KQ0hGIYqhA0Mhob INhimpEhEhEhFkZFWr31+dK8+QEqXs9nWrqOsubfHjWH0G7sjtEw5klkjpFQaiS7Q6xT8v05 zMzMzMzM7uho3Nodm83nohB4k8AwRe6mM/UUDMwZmo/ZhIJUEyomXoJhhIJUBCZUTLCYYSCV AUyomWoJhhIJUBY3T4XDqR8iJYjw3NettbFrWtgPqWsRhNtttchHg4OsNMHYf9hPvz+czMzM zNKSHySKjgvHHHFrWta1rbsHcKaPCFoECHMfD3akT1OiRDwWDlYA5t9DDRBkQuMwGRCgkzJM ZELgMxkTDSpLYlVFqtMISwixIsjFxKsIirEIFEskkJUqRKsKsKsKsJRZBIUkSza1s0qm1qVZ MpZTbfbs3ela2tmpaq29WtWtXSATAMwMNOfck8fgUUqosFLp4vMiRW8xNNsmxNxqeg1To4jo fcbnmNHECKB9AMj0Dg8e2e3aSSTjvJJJ8RDNOR9A+Z8CT3PrJVFVVxVz7e+/GbnCkklP4hT0 L72221Ibp7LHPeI8O5sdAHgirSeRKA7gkC2PedB/KoJt7TtU1tVtuSZmHmfA/SpalqWyJvvb 0zODM0GyFregPYha26epiq6RGRGRGQaJJalqBU1GjuahO5h5p4j05T685vizONl3XZzZdrMz Gy7VrsmGWKliirJKskxTCp8RFVCJDxwtsq2qoKLJSoaHaHqo2IOi8udBoGIijAxE9VkCSBFI IahYO6fRxAiDBcYMiqckuLc+Ic+ocxQznhhUqHpS02lMC1BUYFVq5WskyauSmsMs9EkjIsMe O44aaqzinhRlMWNTmSQkDULIkyI7E9IB1pbbFpixImRUiqESAokSIxIoxIIKThH5y34QAAAA AAAAAACEAAAAJBBAFGAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLBGK AAAAAAAAIAAxAAAURjQUGwEajAAAAAAAABsBABjUYAAAAAAAAAAEkgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAASIAAIAAAABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAAAAS AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABCAAAAAAAAAAAAAAAAAAxgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJJ9oBFqKgfopA+By2DaqK79LF4F73sG1bbbabU222 0A8H93NttuP2LHdJPmydZSFmMSLURarCTqUE9vXoIh4SgMFQCQFVO634P5DMjM3ww+DT3j4F YStTgSwqaVaoJKwlayoqcVioSsLWpsJYVNKtUOKhvPKXCnaQcJ6fB0kdmPqcq6aP2aYZXPOt NaxYNT3hp0XlZH2dp5rbbb+nz3KK71VFFWuGxWHmhgXPdM1MTE8FNOh3DgNu+3Oqqqqqoo9v dZAkkkQkZAkBUk2ijFisaNGJCIsUbEYg0WKCSNVrZZUttq7iCNyTtBqEkQ9NSq9sYqsxKT9v u3lp+qpG8klJ0lOJy16eDRvCPkfiYnavyfAiO/k4j8y0LaFWiqqKSqqKVFVTTv+4gUNKGtPt NL5cgQ1C2LHMs0wcsSDCrLZzI4lyxhkSPg4Dgu70l1t+EySZG35VVlbmhFHP/Dyu6G0HD46L VVhVSq/U3f4fKz2LJYdyJGCRIwSJGCR0KM2GXJZbcMkTg3LHBRTD2VJqe1ERfH482tc4Bytz gAcre1I9W22h3VH7pzDxSnUTZ9myNq81TDk7ET6KSPeJ0hy/tDYdS94o7IQpdbnz9vpe5e97 3L3ve5e97nhewAomPz7w17Ur3XxxESrqZK5auUiNh3m7aQXqbp7bHwqy1atWyRtEkHGkXA5k CxsfOnJkN2NSqzLJULZURkmMtRwsHKjnwhu2fvpcOrepZtjI2zbWbysKntTwT38PBVVJqQh8 FThy6p4+vftFDufTlMTyaVUurbJIGwE5XUUOgcjk8J2KUHZdgEofcmiyVknk8klbsjHg+Dq0 +VtlWoyRy+NrbWrKzX3VLbbKa9TDtH7J8Phseqw/up09nmeGLa8pbcidjXjUzcHQlo7mrOZk 5Alo7mrOZvQ6EtHc1bq3X+UYZ0YduxCAfSZlt+trnVpsyakltWb1ReMvY0etYEJJMaKHo2bF gHgW5xarls2311yrz6gHmvyrdXAHwpwSDEii2Ckcz1EQQ1CB4TQRN0br8sZJ85xHo1qRGyWF FQqosKiyiFFJC2j/YbuwqO7r7EW/bTsrEzMysTMzKxMzMq3GgMAxjsBQhShBSlxs8HdPcG8O 5R8oVNW225FZFFL0qg4CJFMylwvSlVSlVSlVkS3QzVuIdTYfKb4jg7HZ1ltUtWWXaRmMmMWV bIwm81FnLse5k7HAwYZxLbYttTRo5jaSeporp43JvLDgI9vCfOV1yT2nZVcN2MUbglJAoMwS mng4pWokMPAIWKixKGU0k2k5Lv52ZaXzC3eiY+Oed7fFE+/hPHbM4aWTxRSwnLSVthL4tvtn t3O5w9iHtPGzGl8wt3OsmPjnne3sie3hPHbM4aWTxRSwnLSVpkCZGM7FSzGeKYdcFWpUQwdi BmrFRJaqxhAh7eE8dszhpZPFFLCctJW2E19ur55b7Z7MIDCAQwVVKiGDsQM1o9ColWssYQIM VQVilOGlk8UUsJy0lbYQ43v1mYZmBblIUgArQb0lvbi5hkZHGq6aBVDk5GBqYnYqp4bOjzQ2 HU0tUJLpKo3t5WOJsXxtZy19aeC3PjLl7XuXctuPe3x5SzTrpc8+e+nktdZTWWdpVyqotHOF y5RfTC6gAmmBxuchIGmmhobzwQh4OxDPBLCRNLSbQ001136RFbjEglLOHQ1GpTeJNJs3W3Y2 G5DWjq0nsLNN+LbekdXRiVSVUlVVLvVu0aYpxPbHuCVwk/Q7b5mZmZmXEp7viSTc0fb/zGTu PMlSRg+gp06LVcp9z0eiGzudUgYnWSSSTLubOb6HsEDENgrs8jaSsOnubBmRmNgzIzGwZkZj 7/kUFNKpQgO9AdKBqSRlcr8aXw/dfGAD25+TdRFeL5VFUFCyOiUZcfSSqqqqsjQTIRxgcwrD 4ZbD9q42DQcbBuONg0CkIBRftoNW/WTLcwbIslUqWT9I7djSfUfbh4bpJH5NRHJz1i1tcsZT Ky5YynaRSTFRCKqFKDgm5LH0tJJJSaHveiquP7+ZkIJ8oPmHEkkg2Af0KVXpbv7IiJrq2tXV sIYkAV9iB1lRc40QLQtGrVIto0U1ZqmVr9G77jHWZt87/Szw5dHUQsTS0tqak1Ja2m2alNSm ps1NNSalS001KamaUqKKCySEWFlhQsKspNTTalNTNS1TU01NITImVpqS0raWmrLTbLSlpbTU zU01NNTZqNps1M1NWpaaWk1mtLbVpmpU1NNSWlbWajUIpYUlQtQsiLCwElRZNS01Gps1Kama mWm1NTNTNqaWlVLTat++eMrclq6XFVbnAADmtxznKyXJm3Ndstl3ZZbdshrWzXbLhu7Vl3bZ rMzd1a121Du1bKkqoxWMYSWoqlWFUxUkkKskZczJFrLIy5mBahayrjUbnOVjBhbZpqzaptlU gpYpYSkW5mEtzMkW5mSKG3W121d3Vssh21DdutZnB21DdQ3bqy3ZrZrtkOFuZkLczCVTFRis YyQqmLc0c2a3ZDt1rZru3Id2od3UO21Du6h3a3drZrbkO7UN3bmu2Q7ttrWZm7dazM7dtt1D u6su3ZDt1at2tZmJVhaywiYrGMJbmZC2qR7y3ZrbzXbIdu6h3brWZnbWsYxJLZFuZkkREtBi oxWMZO7qtdtQ7uzXbLZd2Q7tQ2613NbbkO7UO7Vu1rMzt1rMVPg6p4I9I+cbpXRnoiEh2T/p VaVVtsWWeh7+XOftm4J0xXoX9Uf8VkMjpYv9esGn7ve223GnVu0008vrZtq1ZVMcI/eR+T/D +bbbbfGpHEUffCZbd7CtwrcK3Ltu27ut8nWfseut4MyaIEVKFpKVJSyMG6GIWEVUOe8lkMUY hogp9VAD6NFvMopetboO4+yg/MEeZuSSYVVVVVVVUJB59gPav21fXb89re213Xul9CK1b/se bZW0GlSOCKaf05NGk+J/X8ZS38OLjGRqguLCHk+O/GGwmB8epJJPAfUP4r+vrvxmc485xmc4 85xmc485xmewBvN4o4NR4ah0Pyfbo2HeH4mGzl5QGwKlI4o0mTRI1RUj99rNiRtVWoqQtLWa JG0K5H0sB37GGVHi3kVTccqRDIGskMkBFkiZgYDKhL0TaevTwepye7oZNqtWrf2LJIo9jDBq N3qkEiTAk3EjiPB8ySL1mjqWRvVlRDwcHmeL6dG/9O6PV/44rUEVNBURowqJECAoSgUfQZhM zMTEKgWUC7pvVllHOULVwFDC4e7C4kQIChKBRcIFsl6sso5yhXcBUqhGj1ZRdmBzdpgPat5Z bI5yhXeilVUerKSqLibsJECBAUJQKJCBbJerLKY1nabYhe2e5ZEHe5wfQQATi22gaUVe+d93 u43dFRjhw4nLbZuTnjZqfc3TV89W40RZKMJ249dzmnc6EecLadJIb0SFBpopxrjY4ukN25pI eYikmJxG6wTYpsFiybsjJNkLGRxLGOGNkFixBGkiZHRLHGkbRStkoBiZBS4Pt3kkk2X5iDtt rroFr3vcm2tabamlkGihkk+JZJMDShK3YgaVIjubM/C1QbTRgSjYwPJpiQ/kxIfr9W5mW5mW 5mW45gh7PkxwL3C7EaYdBH2JIeQdxLSxUlM9j6flOfPUm3d1Jt3dSbd3Vw6PwICJbiCXqCbJ YURzwkkkpEEP8oCVa0mivxAXw01e98VccVxxXFknIGBk7mXM/Tfbsqqqr7HCGQ+5SEIUQ+y3 llte973hTmHsIaBc+XKSSQhuacq9rwfkenTXD1xq8tY3dHa2234h5+dttvXfWbFfENXxRodR Dqm4INIGIaHsJZDgX3iyJJJM1IFD0UwDrpVVVVVVQw9+SSSfjNLD2SjBaMFyjBfghTox2Elh uAkQgEbtBQwOFXn0pfVB5oUje9Bw80GlvehhBxMh0IS1NiSCNxJGkbiSQRuJIRplJJJCQgi3 O+bdSWMYxKtYpUUdEeS4f3fqcTqoJ7nY3UxfJFWO58qxGlkp0L2ttttvR1YepO/lkA1Vvvrs BZcl9KXWt79fZWx4dtua5p3DzR6KmZsDgHgDzClc2amPZcY3ietlibk3UcEpwsP8IMZyxkm2 VhrWJGZhHrB+si4dXur1OkbSfPszMZmMzFCUfI6vlu/LeG8gbCHxQvBdGHLkTMRuwBQe2Ovv VVVVbUDcP0CYaBkPRIT9/vVVVV9D6nJrqru88bDuHdh3cO7Du7Du2ZkjMwVjDjvVpPLqn92E 6Ro/LMZb+tDqGIaW7c2YJtLJtDYDtKFLdobA5CYbx6O5OcPnnc6tyS25HtCG4YK1MxvEgxUh STGzGGokAuElrYjoaNOFiRkTYj8t1PsNlwwR1xulkhYLhgFd0y8z0L8808B0Um1RU9D011Vz fa8IbKek/tVtstGB/F8ZmZmZmMKsrHkpqRT9VepwY6lKV37+sNQ0umMk2z8SK2eh5wntBNFB KPidymiqbBC95v/d1pxDEwciM9kEq8ydJDtSSKUBmY9lZzI/kxotArkQggZE10eyVPU569XO B0cz0TJ4qLQ8bzqy+qz1cN6ks7QZOXR7JUzvUfU69ernXXA7eEtp43nVl9U9bhvUh2hZOXR7 JXvb6nXr1c4HY5nYmTxUWh43nVl9Vnq4b1JZ2gycujzpmumMSI7kkS5Zsqzixl/9hQTJx8bJ jANMFs5VdzblNl0KH4XojdNHu5Eqb0o5ERBPQbZoIUDhxBHY1CEREDiFghQMcO0y07LsKUod gnDThMpaUt2bnMK2602q2vbLVW3YDWUtatt4y1ttd3QHLV5Vta6AFaEKWKSITiUhE3liSQcr dsxlzMysshlQXCFEl4ttyEqOHoHFwoqAQIwYMGQpYD3IidFdmZmZmZmbffffff43n5vSstuV lJ+D7BKT+7c1OPQL8w3zkwwzCzVqBG4XQ9j4JvLSpUqVKuXF2XGMj2JWNjvltttjc9DNJTQh nCQSJKn7nwfMO9KdRw4cpJwWdHMkcSyFSbw3lQHEYpTjh+ttyOnDpXFOnDpcaR04arTVJEki wsVlysuUyEixwZINP5SxHHccnUU2joXmScDCN4bSbGxY6VRI2YlWXJWJcmTJObnJZzcjaMba 5pbNLVSlWKsTDaHNR9HMTgB9z+bLVqPbrly5xbg5TVzRCT15tt1dCSV1OxTgETk9oSEhKqFU 0LCqeqfVMQT0sk6dMkXMI8bHUQnZVJB1zVXwgC+DxrrVWNiq9tu71tIYIcoSEhIgxiSKO6g2 USlIdUBtqMLI6yTbVttuSU0YeirK6qhJwlTrzbaYWzhBuVkkVgSEG6WDojdS4XMTclYo7GdB ZC+iGp6+DcPVFQ3TgIpkZgA5FB0R+uHlLi3MtxeHq8j3LZbLZbFDNYaej0Ad05B4DYTcPp76 pMXyxoqqKqiqzp62KJmMTViWVHB2LwMkRJmjdEEAmesIINw00JBF+IKptkCaTtTm8CcIbC0n LpOcOECJOcE5xCcIaucnjvq7SVm5uU3MickrtXHLJmYy5ZMzULilUuCyITciIAKrcWIIKJEs wG4WRiglmmSQ2Mf2K/aCpsWdRy4DRsVW4WClOa6wYFAYwxIUvxKHr22EPPp+czMzMzKE4KSp SqPB4hJIaAiouqkiSJIklQ5tDuEfQIQPXxiItm1rak21Vt6/PYsrxX6GRuU2Kbp3ScuYRHEd ltW1VhCShZiZZqbe1eteuvzvGEoEwXd7V91rfKr9c1WWsvNqUoJYeaClj3IQknp5xaLPWqlr xKtdiNyEwsll2ZlHLo2NyEwsK1ZJdgMZLchMLCbGOzMo5dGxuQmMuuUcxBRT/kqsDZtvug/P fEzKpu4bb13d27dvPLzLh2yy2WyKLVUC1VCtSoqGdrXuFrUlVSVCqh3BLJrWDMxJGVlSGVlz MGZkTMtqJJDIWspJ/6kojiyAk3dUgOp0Xq2qVZcY8i5TabzHMknwuFLTSHLu7bSlokNu7tuU ubdua6OV1XJSuXG1tZMyzLJi1dTc5IHN4zbdrVt3Ntu9stUWEQsUTaNYttaxiptbXaEcg8jw nEQQew/uE/pERVKQFVLEj8QpasiUKJYMsK+8SZ/c9SOtSLTuomWTFkTLGKJlkxUlj1XFNWLc gyLUUCxREsWIlRSQyZSEsLGraiip8QOxnvgfqfQhIS/NVVVVkBmSEIKv9lj8SJoWixiwuLW5 pzJNoRR1TFNUpFVO5SR1TZvBkJAkI0Roo2t8ERFa1zXvr2v27MOQ6pyCwvwIwjCMIxMhE2Sg sWD2IEmDb7wzBawzBawzBawwIJaO921m1lsQZJLES4Y3kkk6sPOZpiuwrkdE8iMTEtLZaWpa tkkmGEDrnn9iWnarjFrFuMhM5DAzIZiQjzS6dh1LhAiomJE7ZjgNyVaWscpo/wQ4zcTlNHiX mxTlNHkOM3E5jZrevmWO9ETYsTlYrhRmEsaKnKnSHNT+TtCR/v+KtWrc8mHWOBEHMQ6Fg0uF 1YjCCfpIncVTgMICYWQde9ttth5x+ak9BIkZelrWQplIZlM2rVSBFVUiKsMEjAwkleN/Ppxu 333333b77777t9999998TSsOIbSTZSq+n5kVV8s3przd4SiZm63OSbc3KpW8W7APa5zXt7kX j1t+6wAdeNRq8Xf9zw996jGMV5txERpWvCeaJGkhrtVrC1YSSjp/pDbktBIpzzreLuIxjF86 6utdChJJGlfmOH9sCwAd09UNQUsq5DciEJCEgPmdHAnFVVVVVXdG44J5MPrbGsyqfI3nMhBs 0+m8SaOpPjhxPdH7KOCyCtK6qw0Ry0bpInkstD90/hS4MYMwYuUxjDAwAfBhcy5WSUYpBVQ1 JJYE0JQskBWJschwBDzCCqwIF0Hsualg+J6SSScHbJQeoezqCZqwYbh4zGAdSzoaTarVq3Eb yfNe7yYTqrTFUGZkQ+TCCwRwvHADikDmlRgEDqFBS9ksFtYPSJrYjV4rEuweDNCUqRBndqMg eHJwQUslaKGMTIqVxewQOEwFioDikCaVFgQNXitIl2DwZoSkIgzw1GQPDk4IKWCtFDGJkVKh MDF3grh5e0BjRUwFtYPEg1aGd2D1M0JSpEGeGoyB4cnBBSwWIoYxMipUVyuL2DCQmAtbAOKQ LUqLAgavFaRLsHgzQlKkQZ4ajIHhycEFm81yaN88zSOp80HW2NlMhsZbwacwBRbTqVYX7VjZ xrveNp2aY2ZOKmyoeXnyP1IGA4Onmn2p+qXh6LpSOCXJCyZ1ZGIE4I0qfNYBB6OIdEIVSsMj ECcEaVOtYBB6PBIrhtrPDlxtbu4cGPny4NOphmZWZnlmocCJU0NZJJKFQYBcKQoF5thdi5cU 6FiQDkZIM6att4aksYw72TXa223EZl2a+WPSP3tVYlUT9z4Ye3HtHQxH1PJBzYAwQgiKWQP6 c6Qw3cN3Ddw3cN3Ddw3cN3Ddw27Ddw3cN3Ddw3cN3Ddw3cN3Ddw3cO2x675+3ezdvZqK+YoG 8cuqHXXbk9fvjf9mtcabMdI/Y00qqqqqqrR+P6fp5ZmZmZmfTS20eKrqvlfSEyJmrnte1y+g G+F8o9rbbbaG0c/pGROi10YkdtexqODdPNzhpCoVVFQqFeBWk0IimUEYQ117vpCSRmAVCK7h itkYpAgbjZE9cfpDzPm222pwegqSMMNvufm5Zhemfsc1HMK8VWlSRmqdaisK8VWlSRmqdais K8aXdJbDDStNDTK+OWgmhgmSIRW4eRUJCRbJTY3UjyPCaXDFi3hmY0YjxHasOY4Y08ycQ2H4 JEhOVyQAfrWwfM9s6qqqqqqUzD1ENwVxImyOxn68udK5bcVftJMww0hSBcIQIHxG3yb5mq9A ByutVdm309bbfM7Wz2htIjtP1MPOOpkjtYtLUtSKMCBB6pzULpyfbLJAxVAnIE00kkj1r+ID 8/bra5zlenxgwaWZpftuoTudnxPtjZsySNjk0i+1ttv+jItVRVVUtSbHkdh+XWfB9z+KttlX SzKWYjgrx3GJ1j6esw0/VY4crQAEg7rn4fFHicR7V314O68Rp7dfi3TM2I+46Zpsx8qPedqt WrZ7JqNQfNWrVrzJ8FMjc9DZwcRFfMBa80tuXmvz+YHdb6V+zXxOvEqiqKomZAxwpQDIIHjM O/x+OgJwFzonQuuoOBRh4nGZ842vL6mEcJJJJ+lemru77AAAAAAPCbOprbzPBmvSOiyDlH2P g2fsj0R9YfHAPczvmZ69wz97hPzLadhURURUcV0nDfbzt03/7M3kcTtpoRNIfgaah+Q3BKCL esemYMzMrEzMzMGZmUwQcEQUyCGd9zrrl1zbuvXXVfWvsgH52u2ff2B5nSDoIE8SMTY6nZNE VFT8uE3Dgsen5mT101NT31p1e0eeW221HK8MZI4z4OxxCbmSPBHi3by8mZjMxmY83nGT+4aS NH+a1VWqOzR5MVzzDGo51mZmZmZ8tFin6HJ+fJ6K5eTdWxAYQgn3VAjZdAUEHJBYGPYLIaZd Ckg5JJzWUHRZHggdJ7nTF1BhClQlKnkOzugLJByQZBjIgxksEQIiD4OlqqDCFChKZayWTL5C TWELJBylzGSzggZEJydLVUGEKVCUXJ5XIZ4dAXEMZYzKODKjibziipDLinbW5RaZ3LOs2Enh Bzwc75VRKsJF/ioJt5LKebNC9/kKiK8t5oZEDJKMuRsaGI7kAhgYUqTjnnGRss0yZOFTG+/X latZtUoGotQjC60SVMQYUhKiFQlDMJorhGErRJ2namwTp7iHoMzMMB89dxRRtL5Bvwnc7hTc RGDUQ8vU7GQOB4DMy52Eu7NMGgstXe1ttt3ytlei811RVS4XoFRVdxLii4TOpKhJXLc997a5 evrF1q86t3fbvMMhGaBhB9fHcdToaFkNANg8guIbrs4tDHYILtPmhoRhCETNRIOeJgG2J2TP jkSMzyN3Po83s3KktWjYyOn8kRpkhBYr6+PdbbLbXxkhCSS59LqJCYiHwXyEaXn0oGVQHrGR kZAWSSGmq32fYB5vjHwcccccc591xs5ao+4rSR27dDUhsstO+GZkyWmYZ5RUd7yrld1G+RCR xISRSSNSkTAlMamtaifM8VatWvl0rpqI66u198hIEiZVJqWqnVELEuUUuFbCj7hdcL0HnX1C X5AcCWLGhoIHQHVNIksWTuadqaqmqpqqQ3Ty0k5odrkI8FNkbZBgd8bhkFzgtc5Ekltv4aLP FQhJJ9RzFiuNz1EfmParbZaEa288XLmZmZkJExUgRYpAqWSRIf4EyVJEiykhgI4jbbsF7hFl 72HqAQPbOSksLyTG3ZX3ivTrJJJcDmvmOChBeoB815yRLm8JJCwleThqOI7+lvXOsdB8FQZI icmI3LCw7idfglkIfqnsiOY+6QuOboaFgyGlSEnPXK9y972ve973he9/0JwEIqhFMEzbGVHK EsXbjAnO1FSSSWUwUshcmBRS4VcB1LhfMOcbPOOFT4KcjW0U8R7pg7b9UidYgHx/gTZfxqbN 3RNm7omzd0TZu7lTDa7tNLTVtpptXVl4Aa++vvoSQhJGEwYZsQpxVFwE2PUczk2JKsqyqodB E/cioQLD5e4MT0kkkiuwxNU02TqqIbB1UECGO2v+E216W29a8Aff8uq6pV/AB1y23OI7Rn1V q1apNp+/3jMtxmZJIc1ugFxXKX1gpLNreKl6V454xqqBgI81BBVuHQLj6pEf4jEqG1sy121G o1G8q8LsbbV3Zr8rwBtxor01qv3XgC3dW87e7r3Yejh49iT60pbZLSltcshJcQ6BwKK7rg/g rUbRjYwqo+O2Gm8ShL3usqgKqyrfNDVMcaA1AytSGYCbyTeNRPWcqqqqqWDY4u8fTBp07DiW XsrFxZi4rFxTGWdVmTpnMpq9222q3P4X7E+jhD05cY2pa/y+9v398OyuKnT8OB1UOHRjZTZQ vcq97ZNG5RVzzKPyGOE2vWnIt2J9DLYIt3zFL01oVBoCDSQ0PCA6masegdi0U9NAmS0i4Ki6 C+hDQpMBSpQWKBEIW1xol2BlM6ZbQRga3Nnt4fQWiGUqNdSGrJNHNtDiMtQxkGDUbAxAdi3v XPmW4JzMtgi3eY7PDE5kMM7BhFNZcIhC2uNEuwMpk9MtoLTga4N4rs+gu6oVFwpDVkijm2p2 TMmU3ytEcbSShiBi7uEcnLArrUGxmrHgOxaKe2wwul5C5F8lGgClSgsUCIQtbjRLsDKZ0y2g jA1ubPbZ9BaIZSo11LVkmjm2hnjYOhnpOVmjEoq5iUZmOE3vXPmW4JzMtgi3eY7U0oVBoCDS gDFSgsSgRCFtcaJdgZTJ6ZbQWnA1wbxXZ9BeIZSo2FIask0c21M9Ioewe32AFKUGiCnS+Fxb ih040MAuDzls6M1w5fbcEDQAGAPtwZVxSqIllV1iisiCFjW1ota2xa2NVW2La0QKd790cS4u cdg0zxunUohTVzE7NFyHYhyDoZGYYkO5Rke5RccqqcvrT3L4V21MGMMEg0waerRq3MMruXTG qrBtb0va1g5THqEYF9YBhXR0BuG2pQwrglQKa0UgUhK8vhxIIRlbCyWfk2ib2EE9KFJYCuA2 agwt0dAbhopQwrglQKa0UgVglsvlxIIRhbCyWfJtE3IaadtnOcSXpXYmyL7O3F2nlhxpMFY4 4bcXWmavDg5bP18+0v6+3fzebh5idlbNlYKIBa5QQiFThgPSYetHJU5kel8BbEsZs9WkFJtH gxuIbI7DGxpNk5OI3OkbPHvHNjTkp0Oj7jqSNlahpGmJohsdYp0cW1atXeHCOTnUXmSefkbE mxJ1OWoVoTJBh1jY6NztHEkcOBBGN9MibscGx1YOh12OXSHbtbbbboTykUm0PiLDBN40jUNE sKJ2eMeG0UVMR1wPXyN253jg7wRqOsWR1CqiclTx2hycI4ix1myFnCtkSQxWorLG0bMkMbcZ F9U5N43h2gWHU01HXzixOI4hvDsrsqygxvSSbIbmlvQ6ys2jDdrmSlict9kY2bR/2t06HZKe 0o3KZktWrZgiUqgFhtkLzw2YDvM5rdpG8vL3aCbbZNt3GWDq9DPRmmppo6MdyvVvHWJjTjaM bPWbmlVXt42zM3HPPPzbbb+E+GDGhTvHqdjMioZpc802oH4Z0GYgN+ldIotqUraubmuAc3K5 XJhZSymEZMMIMmGETJhZTJIyYMilElMlMMmGDJhgyYWUsphJkwwUoyYWUspZSymGTBJgolKU iUyUwZMMFMlEYQyYWUspZTEMmGCRkwspZTCZMGFzcplMplTKZXK3NymUyYQpRkwspgpSZMMA oyUsphIlKTJhZTDJhgZMMMmFlMEZMMDJhZTBSlKZMMIyYYMmCyllMiJkwwZMMITIF+ifhU94 8ST9ak/EIKcJyD0DU1Ow+SoeiRLr050GyBmHUctj+/a81l6XYr6YVFjFh1ieCYYYB8A+x+X5 fEVRVFU+uAIYhAyCKUKSlCilKUpSwlVU22Kqm87uu3xe6mGGG7frlidBGIjEaWKLE6Pu/Fy5 cuXJvd3Hbrd9A3Hb4Pm/H8l8W9+vpGOWhiXPkX8rsra222+pufMTl1g7JBKVWIkBWUARUeUk kgMsbFwDzL0TgO4UI3C54MsrGYZdQm4WVd09OUkHi+l+gHjXt7b5oMW11LavtvpenPbmZmZm ZXLZZix9tKxVVjHtVyHqterCbawx6mR5qcf62225w5evoevWPqNvSpX6r36IiaiaVbr33i5E dvpn0m7rsNv1vOczkzbxx5x5Dby85zOTNvLhfERVD7UFR5QkRVP4oQshcUvzAAD3X25uugOf FXXOFdc64Ftu8Mzq7KtWkDiXMSMhttkmSWkEWQpaEqilJKsCyRS+HFttuvcrfhNaXTiJsU5j CYnV2YntbbbevBmPYyP1HRpxGj/qKeUUiPkDk84SEhOeHChrIsiwYYBsGjIejDSfhbW+MmZl uXFmUEN5OmdByS7SZfMKPVGAckOgnyCwZO6ia68jgraHSlM2q2kahYY94yEnWr5buW23itfu rxXisUY0JtEJYqgpIrsU+UiRP3T0jq6TeySQbJSh8O9rl5JJMA5Q4G6bBiWCyXNTkHNNsAyM qkkkyGL5a0BJonsCKiQyIID76x8H/nieo+Vc1MVlTFZUxWOHxpNbEsotJaLRLj6kh1JuNG8d IrynvbxkxmZVzJjLTS4onK63ivNvEQY337xubW6tomQsRYjtMTiOhs6K0I2r2OpZhJnYVkwk wRWTMkxFZMJMEVlKfiSpNSuu+Trbzy1bvvk3t33aKVTiabt+k6qqziVPWRwiCDqjSsnIAULS m5mBGKDvT5HwCLCKfnwk+Y586F4+2Q4xm55ymcxnGSznL4zc85TOYzjJZzlyBDGbnnKZzGcZ LPHGMIcvTmXuwtYKLFj2kkk5mWckkmZ6B609ChVIqEPC1X3IkROWjU2VjCsil4OIsTCJSPOQ bn4k2lks3E/D4/vmZmZmZ5vN9uzlX29mzTZWz5Y0ru3NNN2x5Kmip+P2ezRW531+TTCcVFsP aK7PZ2DQ3/TDkibOz3LW2MMuW1mMMzJUdGuXLOZIaTq5O7cfgKdT7STwdTt22Seo4DmisfQI uONB1ATAWU/jd7ExumckkhU1o7MibK17MVclRCiRVRJaRKpKqyyDWYj/aVPso+PTw8v3/L8v wfmdEP1PiBhieMPB0aJ5EonCnNNeNeVvSfkTrJ4heU+x3O4dzooOdY52PI8+pTitimhSRudr SJcwjpFkabkcwbEFm5wWakCYPBCy1cd2E3k6ujk9Hc4ITBVQMCKHqa0Ihkx7pLm9ze9YVVUV BTQrEDYxoLCQJDgwEo9EpAqEbNTmDYgslpQoLSpAzZ4IWWsDLCbydXRyejucEJgqoGBFD1Na EQyY0SXN7m96w5ksaJAglc7nOgisYlKypNQqm1ohZY3NtJOHNiCwVigtMECYPBCy1cZYTeTq 6OT0dzghMFVAwIoeprQiGTGiS5vc3vWCdgiGGZBUFNCsQNjGgqJAkODASj0SkCoRs1OYNiCy WlCgtKkDNg8ELLWBlhN5Oro5PR3OCEwVUDAih6mtCIZMaJLm9ze9YVEDigFAAKmwDggQIOQS bgjEkCxFKdgYWlKTrc5UyEjTZcMCChBcIHCMl4r+psZsrzeHd0x1cKpXq2bNNienjrxxjta9 TXpTWFY8iixqcELD+du6Dm4YU2Lb04Ne6I4IlMG73IgqGzcRix5gSL0qdnYKEs1GF0JQik6M hzKSQdhJHa9tkZngaoEut8sWRJZMHirkQVDZs1xU7wJF6VOzsFCWajC6EoRSdGQ5lJIOwkjt e2UZnjKIMmowa4ViwxIiPKwKfP4DyThwO4Xv3tvUk4JuWeYc6ukScE4dHBOENRtLt15d27t9 zYXkA4J7G+NpEJpxNsaSQxU3GmMMZCJJRgkxESYqJBuskw2UmQFQgXKUBaGIqotAwdAqpJJZ 3K4hVi1xWdNaa1q6NI3dHh2bRO8NndPDZVJJVO0lMX2XTTFWJsQR1FuUGR2dvcoqjYOgevj0 yswsywGKOwaAlnZHB7EkYSQkYkgwjuYp5B1TA66IdgtqFjFCg1WJxd1jIyMgIotxYoooahAL nBgYofK5LlgwD55MkJMiyLCUeQrpB2HEZeN7eoSBy5wAA5t1X41t7+oFIYjCGZ9VuaVfG9r3 V3r6h6D16uAFvw8dW2eV9tYzV3WM1d1jNta22691IJsiyCRKUT7NlVbDcek3ffI3bubvvkbt 3N33yN27m77wkkRmrklrWtW6ktZq4xSqSUm0xJJJPhubbxr3167wA19u6hJIx3opfiENi/Ex NQOicBYE9jeElUUVKkqVIVKprkeD0L3WQSFxSDo7eRFkDULQgYQGAwgABQOSK3uyetnR3dHd 0d3tjjjbHHG2OOp1ZmHc9SkUzUsPZUfNIjeMbD4tttsjRzU3Cbj7VZVirkr7jlyb1nTIm6y5 tVS3NVlDNKaVlcmjDmIj2H8ZJpNHRwacm0P5S9mMnqkqNLGfTv1erq1qMTtlt7QR1UhJ8j1d tqtWrcbtb6+umZm0mVatWvOhheh2h2kn1Hm9Svvdwd8ttt83jQW22TGJpkk7DzU7o2RyPSNi byc721xGWGQk09MtT4InMdicGonCybuk/SdQ0sKqVSVQShSBSpSlK09VqWKRUshZDI6HCsTH NXJG05P2Q6oakO9AkPx4dYnnmMzCdnJJM1bsj4CRFj7SwkkjPxodPqrVq1b5vtsidpO7Y9yu s/McvNaqqqqtwVE1RIRyJFP+hPR6x+I3jule+98vqAuWWWSSqS16W1yYA8LqFzmdSSObCiNM qSNMKI0sRllwJuh0XaWzWZMzJmZMwiix+CxqDsNiqqnB8RrWZm8Ubg0DhfVMgDdvNYVKhUqF Svh0N7yWTW1VWZmZmfXuzoPkctm79mZ2OTdInsbuv3bbbOrXZj11V7Yu7WdJHiEkhVFiJ8zt 1fpbbbnLDgkk4jcqU+oob7PB2DOgcKPQ7kw03R3JhpujuTDTdFA+xAvtS4ec6cb9G4Exq0Dv nYTAFFROEoRw0x2KcxOIqR9lkNBDo+50iHrMy/oFAT0HXAtp2VBgtFUH4ftw3GhvyEu9zv0G Ge2H4wz7HuHISEhIiZrrrQbmyOGx059aqqqqqvNNjsXv+B45wD3fOr75qz2R8rc186+UsaSx jSW4U2m1ZbvfG1z05yW6MTwQKOxhVuzTzCwTBhEk95673swjeXvrJhs3dHITNm7Z+kOZ8zaS SGfQphoGiJJI/5at8ELQqI9kldj7MTwzDmqoCfANylQRQ5rhBgeqpueR8R1zJmZMzGZjSkRO SRLMaVVVMaNMgkkaSyESGOpRPyG5bXLa9r5atXuWWSpaqIMKJzSnkRXNLqIqGJklw8gzNzoi Km3tIej2chrLbbafUnSTipTUNlGAZKaB7hgvjxQYII9XI4kqiqqqpqq+mJiVuaGxIVOecSMk bd21XTgJxvIaqNN2gSyaqWIsFcnSG+Ukl07CImZAoL36KBcdM/f30vgEwwwwvgEwwwwvgEww wwvmAKJMYSEZiq+8kkm/sOBceYZhZfCoI9hgBgLBRst+Fd235d1bW22+t9+ZMGZkgMGZkj2e dzq6vjc4kkkHe5bJkPD4hiKsUiPSTudZHyeh6cZMzJmZMzz1LqMNDlUqQsKWSSFBZQWQhRJU UKkFEiyChZJSpIhSWUSopZKZqytottjWlrKqylWaRKSSwSlLFKkoWKUiiWUKIpIopBYpZSRK iU1VsUVFFbM1VUtKUVgRAEiiACNkct3OjGzaxazbTWprTVlywth7mpCfb+E/MMeTozFIWWS0 pCzM8nqz3+pZb+YM2allubgu6zdbxeL57iMYw6u7mutTTawSIpBIoxIikHgg7rEbegQ2IQk0 PkOKLn2lJugiGyjLZtFzZSboIhspEtz6wJk5JJM4frWCNYVviVWKqq2EZYypI/60/3nd7PLz PNWcAAAAAAA9fUa66AAD43yr53pXLkq/htcoBwNAyCnAhRiPgczyV3iSKMY3XwAt9/mEhCWb 63285HOclSmonc8n0xWMbuU5y283Lly5cuWqeOMUzQ9jU91vCSQjsnY3HlCQkJFL66lnE7I2 WKbp55Kd8YzGMxjMcc7aNiU8cSDCxHk+zRueMtttd2jJebfpLV9u/ooMdtoza6tv00YwzJoV 5cpJJJCUnkYIFARdDeSZ8Ud5IbN2myTZu02SZs3abJwrPsEEv2gXfxLU0VYwYcysIySTEMDt pJJJF80eoSG6TT2es4H7Kepe53NGtPSO9s8ZkHDnm7zy7q7ddt3xe3u+Hq+UAa3RYNzoYjui SQw1Vtt8sttt+WRkTqkpxSmcO8aNjd1g839S1dvuhTocw+aHgTIIlwyIopjlJJJbxONwPsdP 6GnxwmfQcUW/kQ2ZpuXSFjdVukbxuXauQt5IkwRptY+tA4scGB0yvc0nUoc5zTSHMWhLJBMb TQJlwIFbNYq2tStMOqG82kQ0on+FJsecdmkeT0NJvTZCDodTIyR2jIkbx5YaGoashw6yMcmu EiWm1WrVoxsYnCVJFTIySa/D5j6TiaMGNAYMEQIELgof5HmgWnYbm8HJGSTMhZk3iTIbGAiq LGYIICW1hagWlhY3iTIWMBFUWI5KppU1clIyi0OFixvEmQsYCKosZgggJbWFqBaWFjeJMhYw EVRYghBSa7gptZ6MKgwRClMKX88WfTyc03dN3Dq9qWROiyFJJMKSkIKmgqnJQAu4AaJTgl+c ltvY4hto3RPyhKanxsn5o8yUsNiR9TRvexQ8pJIJrNFhTM6pFQ0CCsCQIo8wxgWTqHjZ29yi pVZlZZ6Fgfh3kp0q2LYti1Nny2A+A+0ZGRk5+lb1SaqMDEplvhJJJQbjqeRo//4u5IpwoSDQ s/yg --------------020303070201020001040105-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 19:48:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FEDA16A40F for ; Mon, 11 Dec 2006 19:48:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C743E43EF3 for ; Mon, 11 Dec 2006 19:34:09 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0415146F25; Mon, 11 Dec 2006 14:35:24 -0500 (EST) Date: Mon, 11 Dec 2006 19:35:23 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Konovalov In-Reply-To: <20061211183048.S20189@mp2.macomnet.net> Message-ID: <20061211193334.W62822@fledge.watson.org> References: <20061211110009.K62822@fledge.watson.org> <20061211183048.S20189@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 19:48:33 -0000 On Mon, 11 Dec 2006, Maxim Konovalov wrote: > On Mon, 11 Dec 2006, 11:00-0000, Robert Watson wrote: >> On Sun, 10 Dec 2006, yal wrote: >>> On Sun, December 10, 2006 13:57, Robert Watson wrote: >>>>>> - Try setting net.isr.direct=0 and see if the problem goes away. >>>>> >>>>> This indeed help. LOR has gone and wireless works. >>> >>>> result in a deadlock under other circumstances, net.isr.direct makes the >>>> chances of that deadlock much greater. >>> >>> It helped on Latutide D520 as well. No freeze or anything anymore. Top >>> shows now 100% idle most of the time. The debug.mpsafent="0" has been >>> deleted, as suggested. Thanks to Robert N. M. Watson. >> >> Sam has committed changes to if_wi in the last 24 hours that may fix this >> problem with the default net.isr.direct setting. Could you try updating to >> these changes, removing net.isr.direct=0, and seeing what happens? > > It works for me. Thanks Sam and Robert! So, just to confirm: you can now run with default net.isr.direct and debug.mpsafenet settings and without problems? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 19:53:07 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DD2116A49E; Mon, 11 Dec 2006 19:53:07 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DF52440A0; Mon, 11 Dec 2006 19:36:45 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id kBBJbRnN059808; Mon, 11 Dec 2006 22:37:27 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 11 Dec 2006 22:37:27 +0300 (MSK) From: Maxim Konovalov To: Robert Watson In-Reply-To: <20061211193334.W62822@fledge.watson.org> Message-ID: <20061211223602.U59524@mp2.macomnet.net> References: <20061211110009.K62822@fledge.watson.org> <20061211183048.S20189@mp2.macomnet.net> <20061211193334.W62822@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@FreeBSD.org Subject: Re: CURRENT freezes on Laitude D520 (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 19:53:07 -0000 [...] > > > Sam has committed changes to if_wi in the last 24 hours that may > > > fix this problem with the default net.isr.direct setting. > > > Could you try updating to these changes, removing > > > net.isr.direct=0, and seeing what happens? > > > > It works for me. Thanks Sam and Robert! > > So, just to confirm: you can now run with default net.isr.direct and > debug.mpsafenet settings and without problems? Yes. $ sysctl debug.mpsafenet net.isr.direct debug.mpsafenet: 1 net.isr.direct: 1 $ uname -a FreeBSD sonnie.mtu.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #35: Mon Dec 11 17:28:07 MSK 2006 maxim@sonnie.mtu.ru:/usr/obj/usr/src/sys/SONNIE i386 -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 20:31:41 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48C7A16A47C for ; Mon, 11 Dec 2006 20:31:41 +0000 (UTC) (envelope-from keramida@FreeBSD.ORG) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD67E44912 for ; Mon, 11 Dec 2006 20:04:47 +0000 (GMT) (envelope-from keramida@FreeBSD.ORG) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kBBK0gPZ015874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Dec 2006 22:00:54 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kBBK0Vi0014706; Mon, 11 Dec 2006 22:00:34 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kBBK0VuJ014705; Mon, 11 Dec 2006 22:00:31 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Mon, 11 Dec 2006 22:00:30 +0200 From: Giorgos Keramidas To: Rene Ladan Message-ID: <20061211200030.GA14578@kobe.laptop> References: <457DB09C.7030405@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <457DB09C.7030405@gmail.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.692, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.71, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: current@FreeBSD.ORG Subject: Re: rescue/rescue not compiling ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 20:31:41 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2006-12-11 20:25, Rene Ladan wrote: > Hi, >=20 > since last week or so, buildworld doesn't want to compile rescue/rescue > anymore. I don't have NO_CLEAN set, and neither explicitly removing > /usr/obj nor re-cvsupping help. It seems that some .h files in > src/bin/sh/ are not generated. The log is attached. >=20 > Any ideas? Try rebuilding crunchgen. There was a short period when crunchgen was broken, and you may have installed crunchgen during the breakage. Reinstalling crunghgen would be: # cd /usr/src/usr.sbin/crunch # make cleandir && make cleandir # make all install # make cleandir && make cleandir --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFfbje1g+UGjGGA7YRAkbSAKCVK1o4LXkhze+qZguIY1V9i1QwiQCfTOLr cVH7IR8Oq13cs22VFbSqCDM= =EFwz -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 20:50:26 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51F1616A412 for ; Mon, 11 Dec 2006 20:50:26 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC60A442A1 for ; Mon, 11 Dec 2006 20:30:59 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 98CC06109; Mon, 11 Dec 2006 23:32:15 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 90396604A; Mon, 11 Dec 2006 23:32:15 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kBBKW9sN000714; Mon, 11 Dec 2006 23:32:09 +0300 (MSK) (envelope-from ru) Date: Mon, 11 Dec 2006 23:32:09 +0300 From: Ruslan Ermilov To: Rene Ladan Message-ID: <20061211203209.GB608@rambler-co.ru> References: <457DB09C.7030405@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8P1HSweYDcXXzwPJ" Content-Disposition: inline In-Reply-To: <457DB09C.7030405@gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@freebsd.org Subject: Re: rescue/rescue not compiling ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 20:50:26 -0000 --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 11, 2006 at 08:25:16PM +0100, Rene Ladan wrote: > Hi, >=20 > since last week or so, buildworld doesn't want to compile rescue/rescue > anymore. I don't have NO_CLEAN set, and neither explicitly removing > /usr/obj nor re-cvsupping help. It seems that some .h files in > src/bin/sh/ are not generated. The log is attached. >=20 > Any ideas? >=20 Stop using ccache. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFfcBJqRfpzJluFF4RAqLiAJ9ZGUvShSABMReHdAuLrPdJ7lzsbQCeP2JQ WtcrfZJZEhodgCa+eIVFnhQ= =vcUq -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 21:41:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A62F16A403 for ; Mon, 11 Dec 2006 21:41:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4412D44CD8 for ; Mon, 11 Dec 2006 21:08:13 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBBL9Jxd010798; Mon, 11 Dec 2006 16:09:26 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Dec 2006 16:08:06 -0500 User-Agent: KMail/1.9.1 References: <20061210110419.H42195@localhost> In-Reply-To: <20061210110419.H42195@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612111608.06677.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 11 Dec 2006 16:09:27 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2315/Mon Dec 11 04:55:24 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Nick Hibma Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 21:41:38 -0000 On Sunday 10 December 2006 05:04, Nick Hibma wrote: > I'm planning on committing the following change to make the implementations of > the various hardware watchdogs more consistent. A timeout of 0 passed to the > ioctl is now a valid input and will disable the watchdog. Previously it > produced an error for the Elan chip watchdog, which is _not_ what you want to > see when disarming a watchdog :-) I'd appreciate review of the individual > changes in the files by the following people. The change as a whole was > discussed with phk. > > cognet@freebsd.org i80321_wdog.c (*) > des ichwd.c (**) > ambrisko ipmi.c > marius mk48txx.c > phk kern_clock.c, elan-mmcr.c, watchdog.c (**) > > (*) The i80321_wdog.c cannot be disarmed. Is this correct? > (**) These have been tested to arm, disarm, and fire. Others have only been > compile tested. > > This change has been tested on 6.2-STABLE and 7-CURRENT. > > Index: sys/dev/ipmi/ipmi.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/ipmi/ipmi.c,v > retrieving revision 1.3.2.3 > diff -u -r1.3.2.3 ipmi.c > --- sys/dev/ipmi/ipmi.c 19 Oct 2006 14:50:48 -0000 1.3.2.3 > +++ sys/dev/ipmi/ipmi.c 9 Dec 2006 12:40:47 -0000 > @@ -649,25 +649,14 @@ > struct ipmi_softc *sc = arg; > unsigned int timeout; > > - /* disable / enable */ > - if (!(cmd & WD_ACTIVE)) { > - ipmi_set_watchdog(sc, 0); > - *error = 0; > - return; > - } > - > cmd &= WD_INTERVAL; > - /* convert from power-of-to-ns to WDT ticks */ > - if (cmd >= 64) { > - *error = EINVAL; > - return; > + if (cmd > 0 && cmd <= 63) { > + timeout = ((uint64_t)1 << cmd) / 1800000000; > + ipmi_set_watchdog(sc, timeout); > + *error = 0; > + } else { > + ipmi_set_watchdog(sc, 0); > } > - timeout = ((uint64_t)1 << cmd) / 1800000000; > - > - /* reload */ > - ipmi_set_watchdog(sc, timeout); > - > - *error = 0; > } > > #ifdef CLONING It would be nice to not lose the comments. Might also be nice to reduce the diff (so it doesn't have to reindent everything) by just adding a simple test after masking off WD_INTERVAL like so: if (cmd == 0 || cmd >= 64) { ipmi_set_watchdog(sc, 0); return; } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 21:41:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF0DB16A506 for ; Mon, 11 Dec 2006 21:41:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BFB044CD6 for ; Mon, 11 Dec 2006 21:08:13 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBBL9Jxc010798; Mon, 11 Dec 2006 16:09:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Dec 2006 15:55:45 -0500 User-Agent: KMail/1.9.1 References: <4578E1AD.3090505@isc.org> In-Reply-To: <4578E1AD.3090505@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612111555.45792.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 11 Dec 2006 16:09:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2315/Mon Dec 11 04:55:24 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Peter Losher Subject: Re: FreeBSD 6 (or 7) on a HP DL140 G3 SATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 21:41:50 -0000 On Thursday 07 December 2006 22:53, Peter Losher wrote: > Just got my hands on a HP DL140 G3 (generation 3) server, which has a > LSI Logic SAS controller. You can run the live CD or install FreeBSD > (6.2-RC1 or 7-CURRENT) onto the HD's, but when you boot from the disks, > the boot loader barfs: > > -=- > int=0000000d err=0000001a efl=00030287 eip=0000291d > eax=1400000a ebx=00000b3e ecx=00000000 edx=0000c900 > esi=00000d1c edi=00000001 ebp=00000206 esp=00000200 > cs=c900 ds=9a00 es=9a00 fs=0000 gs=0000 ss=9a00 > cs:eip=cc 68 32 06 ff 34 e8 db-fc 83 c4 04 89 46 fe 5f > 5e c9 c3 55 8b ec 1e 33-c0 8e d8 a0 75 04 3c 00 > ss:esp=1c 0d 02 00 00 00 34 02-d8 45 1c 0d 00 00 00 14 > 00 00 00 00 01 00 00 00-1c 0d 02 00 00 00 00 00 > BTX halted > -=- > > Here is the relevant BIOS output from the controller: This was just fixed a few days ago. If re@ did a new snap over the weekend try that as it should have the fix. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 22:01:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C8CF16A72E for ; Mon, 11 Dec 2006 22:01:34 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2638644033 for ; Mon, 11 Dec 2006 21:38:59 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.77.103]) by VL-MH-MR002.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JA400BCWPJ4QYB0@VL-MH-MR002.ip.videotron.ca> for freebsd-current@freebsd.org; Mon, 11 Dec 2006 16:40:16 -0500 (EST) Date: Mon, 11 Dec 2006 16:40:10 -0500 From: Nicolas Blais In-reply-to: <200612111031.06109.rodperson@comcast.net> To: freebsd-current@freebsd.org Message-id: <200612111640.15083.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart2491421.giYluXJIZZ; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit References: <200612111031.06109.rodperson@comcast.net> User-Agent: KMail/1.9.4 Cc: Rod Person Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 22:01:34 -0000 --nextPart2491421.giYluXJIZZ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 11 December 2006 10:31, Rod Person wrote: > Hi All, > > I'm having a problem with the latest nvidia driver on 7 current. This > driver is causing a few problem with my system. > > 1) When I start X either by using the startx command or using a Graphical > login manager such as gdm or kdm, I can not switch virtual consoles using > ALT+F#. Doing so locks my system. > > 2) Once X is started, trying to kill X or log out of a window manager usi= ng > any method, such as CTRL + Backspace or the exit function of a Window > Manager causes my machine to lock. > > In either case, the only thing I can do is hit the power button and reset. > > I was wondering if anyone else is seeing this or has any suggestions on > correcting this behavior. Currently I switched to the nv driver, but that > driver does not support the max resolution of my widescreen monitor > (1680x1050) only the nvidia driver does. > > My graphics card is XFX ndivida 7800 GTX with 256MB Ram. I last rebuilt my > world on Dec 9th. Any suggestion would be helpful. > > Thanks > > Rod +1 for the same symptoms. Also, when I quit nvidia-settings, it crashes too. =2D-=20 =46reeBSD 7.0-CURRENT #12: Sat Dec 2 12:30:58 EST 2006 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://www.clkroot.net/security/nb_root.asc --nextPart2491421.giYluXJIZZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFfdA/4wTBlvcsbJURAr0OAJ9+ky+mlznRKHNlWc+53bfvvDPxiACfZWnF KXGb4F2GLnBTaBBCexXd4Xc= =aJSY -----END PGP SIGNATURE----- --nextPart2491421.giYluXJIZZ-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 22:16:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 074F916A4FD for ; Mon, 11 Dec 2006 22:16:00 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F09D43E09 for ; Mon, 11 Dec 2006 22:07:31 +0000 (GMT) (envelope-from r.c.ladan@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so41037nfc for ; Mon, 11 Dec 2006 14:08:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=jWCSbvdAVmEyt5/EYHG42sItJR6IGf3zk1g386PpDpjPkarXMqEbmscRX32963dMVuuxECbjA+O8h5okiXwOFm7nU2UWp5NYC5yMdRtVRUYnYuEi2zl6RQ3GBJxRzuSBsvNOfOGV811tlobI6xYeblhE6wmm4uVEGGRj8r5rwN0= Received: by 10.49.75.20 with SMTP id c20mr155340nfl.1165874914576; Mon, 11 Dec 2006 14:08:34 -0800 (PST) Received: from ?192.168.123.106? ( [195.241.221.201]) by mx.google.com with ESMTP id l21sm545744nfc.2006.12.11.14.08.33; Mon, 11 Dec 2006 14:08:34 -0800 (PST) Message-ID: <457DD6E0.7070702@gmail.com> Date: Mon, 11 Dec 2006 23:08:32 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Giorgos Keramidas References: <457DB09C.7030405@gmail.com> <20061211200030.GA14578@kobe.laptop> In-Reply-To: <20061211200030.GA14578@kobe.laptop> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.ORG Subject: Re: rescue/rescue not compiling ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 22:16:00 -0000 Giorgos Keramidas schreef: > On 2006-12-11 20:25, Rene Ladan wrote: >> Hi, >> >> since last week or so, buildworld doesn't want to compile rescue/rescue >> anymore. I don't have NO_CLEAN set, and neither explicitly removing >> /usr/obj nor re-cvsupping help. It seems that some .h files in >> src/bin/sh/ are not generated. The log is attached. >> >> Any ideas? > > Try rebuilding crunchgen. There was a short period when crunchgen was > broken, and you may have installed crunchgen during the breakage. > That turned out to be the solution. Thanks :) Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 23:09:26 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39F9716A407 for ; Mon, 11 Dec 2006 23:09:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB30043CB4 for ; Mon, 11 Dec 2006 23:08:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 11 Dec 2006 14:54:40 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBBN9OcR069659 for ; Mon, 11 Dec 2006 15:09:24 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <457DE51C.905@elischer.org> Date: Mon, 11 Dec 2006 15:09:16 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kdb_backtrace 'feature'? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 23:09:26 -0000 I often have the following: code x() does some bad thing 'A'.. it's a known thing and you can tell where it was done from (x()) but x() tell at the time that it is bad. at some later time, you discover 'A' is bad but now you don't know who was teh bad caller of x() The solution I'm looking for: when x() is called it calls kdb_backtrace, but has teh backtrace written to a static 16K buffer instead of being put out the normal way. when A is found to be wrong, we can see who the last caller of x() was and how it was called. I am looking at it now.. but if anyone has any thoughts let me know... From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 23:32:09 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CAE216A49E for ; Mon, 11 Dec 2006 23:32:09 +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 0F2BE43CEB for ; Mon, 11 Dec 2006 23:27:22 +0000 (GMT) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.13.8/8.13.8/ALCHEMY.FRANKEN.DE) with ESMTP id kBBNSK6V067121; Tue, 12 Dec 2006 00:28:20 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.13.8/8.13.8/Submit) id kBBNSKRX067120; Tue, 12 Dec 2006 00:28:20 +0100 (CET) (envelope-from marius) Date: Tue, 12 Dec 2006 00:28:20 +0100 From: Marius Strobl To: Nick Hibma Message-ID: <20061211232820.GI86517@alchemy.franken.de> References: <20061210110419.H42195@localhost> <20061210152755.GA45265@alchemy.franken.de> <20061210223217.M1174@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061210223217.M1174@localhost> User-Agent: Mutt/1.4.2.2i Cc: FreeBSD CURRENT Mailing List Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 23:32:09 -0000 On Sun, Dec 10, 2006 at 10:36:17PM +0100, Nick Hibma wrote: > > >Regarding your changes to watchdog.4 and watchdog.9 AFAICT > >they violate the established style guidelines for FreeBSD > >man pages; the source should wrap the line on sentence breaks. > > Is there a manual for man page writing? I've not done much of that yet. I've learnt the FreeBSD man page Do's and Don'ts I'm aware of by gleaning at commits doc people do and at what they change/suggest when asking them to fix/review a man page. AFAICT "rules" like the one mentioned above aren't documented anywhere but I could be wrong and all of this actually is burried in mdoc(7) somewhere, I just haven't found it, yet :) Marius From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 23:57:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8D3716A412 for ; Mon, 11 Dec 2006 23:57:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E37E443E32 for ; Mon, 11 Dec 2006 23:54:56 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id DD8ED4E08A; Mon, 11 Dec 2006 18:56:04 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 11 Dec 2006 18:56:04 -0500 X-Sasl-enc: xppX1XLi4iDLW1QkYBfd+eNnMm9AE6XGyKCEytTzTy/f 1165881364 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id AC962C9E1; Mon, 11 Dec 2006 18:56:03 -0500 (EST) Message-ID: <457DF011.9010701@FreeBSD.org> Date: Mon, 11 Dec 2006 23:56:01 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> In-Reply-To: <20061129013052.GC71523@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 23:57:53 -0000 Hi, I successfully tested this driver under 7-CURRENT as of today on an ASUS Vintage AH-1 based system. lspci has the following to say about it: 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus) Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at fe4fc000 (64-bit, non-prefetchable) I/O ports at c800 Expansion ROM at fe4c0000 [disabled] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [e0] Express Legacy Endpoint IRQ 0 A few sample netperf runs between this system (AMD Athlon64 3000+) and an Intel Dothan 1.8Ghz based Lenovo T43 with bge(4) interconnected via a 3Com 5-port gigabit workgroup switch reveal the following. anglepoise# netperf -t UDP_STREAM -H 192.168.123.18 UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 (192.168.123.18) port 0 AF_INET Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.00 129443 1135712 954.30 42080 10.00 128739 949.11 anglepoise# netperf -t UDP_RR -H 192.168.123.18 UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 (192.168.123.18) port 0 AF_INET Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 9216 42080 1 1 10.00 2804.30 9216 42080 anglepoise# netperf -t TCP_STREAM -H 192.168.123.18 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 (192.168.123.18) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 10.00 642.80 anglepoise# netperf -t TCP_RR -H 192.168.123.18 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 (192.168.123.18) port 0 AF_INET Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 32768 65536 1 1 10.00 2790.69 32768 65536 anglepoise# netperf -t TCP_CRR -H 192.168.123.18 TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 (192.168.123.18) port 0 AF_INET Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 32768 65536 1 1 10.00 1350.91 32768 65536 anglepoise# netperf -t TCP_MAERTS -H 192.168.123.18 TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 (192.168.123.18) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 10.00 407.51 And a statistically tighter test: anglepoise# netperf -t TCP_STREAM -I 99 -i 30,10 -H 192.168.123.18 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 (192.168.123.18) port 0 AF_INET : +/-49.5% @ 99% conf. Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 10.00 644.98 Another test, this time between the same box and a dual PIII 933Mhz running 6.1-RELEASE with an em(4) card and 66Mhz 64-bit PCI data path on the same workgroup switch: anglepoise# netperf -t TCP_STREAM -I 99 -i 30,10 -H 192.168.123.6 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.6 (192.168.123.6) port 0 AF_INET : +/-49.5% @ 99% conf. Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 262144 32768 32768 10.00 161.17 ...probably harder on the old machine than anything, it is very unlikely it could saturate at line rate. Thank you for all the excellent work on this driver, I hope this data is useful. regards, BMS From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 22:14:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A451816A4B3 for ; Mon, 11 Dec 2006 22:14:09 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE2E443D36 for ; Mon, 11 Dec 2006 21:58:46 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kBBMAAMP009089; Mon, 11 Dec 2006 23:10:10 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kBBMAArR009088; Mon, 11 Dec 2006 23:10:10 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 11 Dec 2006 23:10:10 +0100 From: Olivier Houchard To: Nick Hibma Message-ID: <20061211221009.GA9012@ci0.org> References: <20061210110419.H42195@localhost> <200612111608.06677.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612111608.06677.jhb@freebsd.org> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Mon, 11 Dec 2006 23:58:39 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 22:14:09 -0000 Hi Nick, On Sunday 10 December 2006 05:04, Nick Hibma wrote: > (*) The i80321_wdog.c cannot be disarmed. Is this correct? This is correct :) Olivier From owner-freebsd-current@FreeBSD.ORG Mon Dec 11 23:05:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D02BB16A407 for ; Mon, 11 Dec 2006 23:05:41 +0000 (UTC) (envelope-from rodperson@comcast.net) Received: from alnrmhc14.comcast.net (alnrmhc14.comcast.net [206.18.177.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EFC543CBA for ; Mon, 11 Dec 2006 23:04:22 +0000 (GMT) (envelope-from rodperson@comcast.net) Received: from atomizer.opensourcebeef.net (unknown[71.61.11.4]) by comcast.net (alnrmhc14) with ESMTP id <20061211230540b1400mgmkoe>; Mon, 11 Dec 2006 23:05:40 +0000 From: Rod Person Organization: Open Source Beef To: Nicolas Blais Date: Mon, 11 Dec 2006 18:02:41 -0500 User-Agent: KMail/1.9.4 References: <200612111031.06109.rodperson@comcast.net> <200612111640.15083.nb_root@videotron.ca> In-Reply-To: <200612111640.15083.nb_root@videotron.ca> X-Face: $72, ]$Z1y\/nYF:T[d"3TSO@]'dM+)/B@hdK(?fAY@F4IPU, =?utf-8?q?wTha8oQ=5Cish=5D=26GCe=26C=5BvAG=0A=09g=3Bv=7E=60wM?=, 7H'7TW"!3zWJ_o]nb]i>oMCl=g1F$+$v+8i, xRtU(=?utf-8?q?vKPxX=5CoK7/9to!z08=7BJ=25A=0A=09p=23=60?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart582940082.hrnGcorjDN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612111802.45539.rodperson@comcast.net> X-Mailman-Approved-At: Mon, 11 Dec 2006 23:58:51 +0000 Cc: freebsd-current@freebsd.org Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Dec 2006 23:05:41 -0000 --nextPart582940082.hrnGcorjDN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 11 December 2006 16:40, Nicolas Blais wrote: > +1 for the same symptoms. Also, when I quit nvidia-settings, it crashes > too. I forgot to add that one. As suggested I went back to version 8774 and things work as normal, but I'm= =20 getting a missing GL lib, but I'm not worried about that. Rod --nextPart582940082.hrnGcorjDN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFfeOV3rDijyy3LEcRAjTxAJwOd0vw064iZvlFD77AX/hroy/86wCeJ/it SVOSQIjY1QPP2+GADYLdIBE= =sL8A -----END PGP SIGNATURE----- --nextPart582940082.hrnGcorjDN-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 00:19:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F4A216A403 for ; Tue, 12 Dec 2006 00:19:44 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E99F543FC8 for ; Tue, 12 Dec 2006 00:10:42 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 9C6B11A4D8D; Mon, 11 Dec 2006 16:11:55 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AB3F0515BC; Mon, 11 Dec 2006 19:11:54 -0500 (EST) Date: Mon, 11 Dec 2006 19:11:54 -0500 From: Kris Kennaway To: Julian Elischer Message-ID: <20061212001154.GA87602@xor.obsecurity.org> References: <457DE51C.905@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <457DE51C.905@elischer.org> User-Agent: Mutt/1.4.2.2i Cc: FreeBSD Current Subject: Re: kdb_backtrace 'feature'? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 00:19:44 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 11, 2006 at 03:09:16PM -0800, Julian Elischer wrote: > I often have the following: >=20 >=20 > code x() does some bad thing 'A'.. it's a known thing and you can tell > where it was done from (x()) but x() tell at the time that it is bad. >=20 > at some later time, you discover 'A' is bad but now you don't know who > was teh bad caller of x() >=20 >=20 > The solution I'm looking for: >=20 > when x() is called it calls kdb_backtrace, but has teh backtrace written= =20 > to a static 16K buffer instead of being put out the normal way. >=20 > when A is found to be wrong, we can see who the last caller of x() was > and how it was called. >=20 >=20 > I am looking at it now.. but if anyone has any thoughts let me know... See Kris --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFffPKWry0BWjoQKURAtV3AJ92uIehebL/jagF/HvqJVp/g9hWLACg3PXj FiFNNbCyshp9xLdCETEnk0A= =ppti -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 00:46:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8521D16A492 for ; Tue, 12 Dec 2006 00:46:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75B1F43DAA for ; Tue, 12 Dec 2006 00:42:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 11 Dec 2006 16:29:21 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBC0i5Ep091588; Mon, 11 Dec 2006 16:44:06 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <457DFB48.7020704@elischer.org> Date: Mon, 11 Dec 2006 16:43:52 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Kris Kennaway References: <457DE51C.905@elischer.org> <20061212001154.GA87602@xor.obsecurity.org> In-Reply-To: <20061212001154.GA87602@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: kdb_backtrace 'feature'? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 00:46:19 -0000 Kris Kennaway wrote: > On Mon, Dec 11, 2006 at 03:09:16PM -0800, Julian Elischer wrote: >> I often have the following: >> >> >> code x() does some bad thing 'A'.. it's a known thing and you can tell >> where it was done from (x()) but x() tell at the time that it is bad. >> >> at some later time, you discover 'A' is bad but now you don't know who >> was teh bad caller of x() >> >> >> The solution I'm looking for: >> >> when x() is called it calls kdb_backtrace, but has teh backtrace written >> to a static 16K buffer instead of being put out the normal way. >> >> when A is found to be wrong, we can see who the last caller of x() was >> and how it was called. >> >> >> I am looking at it now.. but if anyone has any thoughts let me know... > > See interesting... is there any documentation on how to use this and what its limitations are? man -k stack doesn't provide anything.. grrrrr. > > Kris From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 01:01:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E87016A416 for ; Tue, 12 Dec 2006 01:01:27 +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 489A543CCF for ; Tue, 12 Dec 2006 00:56:38 +0000 (GMT) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.13.8/8.13.8/ALCHEMY.FRANKEN.DE) with ESMTP id kBC0vr7l068059; Tue, 12 Dec 2006 01:57:53 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.13.8/8.13.8/Submit) id kBC0vr2h068058; Tue, 12 Dec 2006 01:57:53 +0100 (CET) (envelope-from marius) Date: Tue, 12 Dec 2006 01:57:53 +0100 From: Marius Strobl To: "M. Warner Losh" Message-ID: <20061212005753.GJ86517@alchemy.franken.de> References: <20061209185539.GA34399@alchemy.franken.de> <20061209201438.B42195@localhost> <20061209210629.GG86517@alchemy.franken.de> <20061210.231137.-1749707382.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061210.231137.-1749707382.imp@bsdimp.com> User-Agent: Mutt/1.4.2.2i Cc: nick@van-laarhoven.org, current@freebsd.org Subject: Re: mk48txx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 01:01:27 -0000 On Sun, Dec 10, 2006 at 11:11:37PM -0700, M. Warner Losh wrote: > In message: <20061209210629.GG86517@alchemy.franken.de> > Marius Strobl writes: > : > : I favor having no man page over having something incomplete > : or inadequate like f.e. esp.4 or bus_space.9 as IMO wrong > : information can confuse way more and leaves a worse impression > : than no information at all. > > bus_space.9 isn't incomplete. The problem is that it is too complete > and general, if anything. It is hard to penetrate. I mentioned bus_space.9 as an example of a man page that I'd describe as inadequate; both the sections about mapping and unmapping as well as allocating and freeing bus space are still verbatim from the NetBSD rev. 1.9 one AFAICT, which describes concepts in these sections that don't really apply to FreeBSD. Granted, on some platforms like FreeBSD/i386 one can probably succeed in doing actual reads and writes by only using the functions mentioned in bus_space.9, but it totally fails to give the slightest hint (not even a .Xr) on how to obtain the bus space tag and handle the right way in FreeBSD, so it will actually work on all platforms, which is the whole point of the bus_space interface. The current bus_space.9 actually tells that some of its sections "may or may not apply to the FreeBSD version" and "many parts of the interface are unspecified", but that's essentially telling the user that she/he has to figure it out herself/himself, which IMO defeats the purpose of having a man page in the first place. Marius From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 01:04:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6D0C16A500 for ; Tue, 12 Dec 2006 01:04:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outY.internet-mail-service.net [216.240.47.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25E1F43EA4 for ; Tue, 12 Dec 2006 01:00:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 11 Dec 2006 16:46:33 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBC117l0013396; Mon, 11 Dec 2006 17:01:07 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <457DFF4C.2010806@elischer.org> Date: Mon, 11 Dec 2006 17:01:00 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Julian Elischer References: <457DE51C.905@elischer.org> <20061212001154.GA87602@xor.obsecurity.org> <457DFB48.7020704@elischer.org> In-Reply-To: <457DFB48.7020704@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Kris Kennaway Subject: Re: kdb_backtrace 'feature'? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 01:04:29 -0000 Julian Elischer wrote: > Kris Kennaway wrote: >> On Mon, Dec 11, 2006 at 03:09:16PM -0800, Julian Elischer wrote: >>> I often have the following: >>> >>> >>> code x() does some bad thing 'A'.. it's a known thing and you can tell >>> where it was done from (x()) but x() tell at the time that it is bad. >>> >>> at some later time, you discover 'A' is bad but now you don't know who >>> was teh bad caller of x() >>> >>> >>> The solution I'm looking for: >>> >>> when x() is called it calls kdb_backtrace, but has teh backtrace >>> written to a static 16K buffer instead of being put out the normal way. >>> >>> when A is found to be wrong, we can see who the last caller of x() was >>> and how it was called. >>> >>> >>> I am looking at it now.. but if anyone has any thoughts let me know... >> >> See > > interesting... is there any documentation on how to use this and what > its limitations are? > > man -k stack doesn't provide anything.. grrrrr. cute.. after reading code.. interesting but it doesn't save any arguments.. but definitly interesting.. thanks for pointing it out. I missed that being added.. > > >> >> Kris > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 01:04:32 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C170B16A532 for ; Tue, 12 Dec 2006 01:04:32 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3840643E1F for ; Tue, 12 Dec 2006 01:00:17 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id BBC0D1A3C1C; Mon, 11 Dec 2006 17:01:35 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1B88A513F8; Mon, 11 Dec 2006 20:01:32 -0500 (EST) Date: Mon, 11 Dec 2006 20:01:31 -0500 From: Kris Kennaway To: Julian Elischer Message-ID: <20061212010131.GA88098@xor.obsecurity.org> References: <457DE51C.905@elischer.org> <20061212001154.GA87602@xor.obsecurity.org> <457DFB48.7020704@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <457DFB48.7020704@elischer.org> User-Agent: Mutt/1.4.2.2i Cc: FreeBSD Current , Kris Kennaway Subject: Re: kdb_backtrace 'feature'? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 01:04:32 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 11, 2006 at 04:43:52PM -0800, Julian Elischer wrote: > Kris Kennaway wrote: > >On Mon, Dec 11, 2006 at 03:09:16PM -0800, Julian Elischer wrote: > >>I often have the following: > >> > >> > >>code x() does some bad thing 'A'.. it's a known thing and you can tell > >>where it was done from (x()) but x() tell at the time that it is bad. > >> > >>at some later time, you discover 'A' is bad but now you don't know who > >>was teh bad caller of x() > >> > >> > >>The solution I'm looking for: > >> > >>when x() is called it calls kdb_backtrace, but has teh backtrace writte= n=20 > >>to a static 16K buffer instead of being put out the normal way. > >> > >>when A is found to be wrong, we can see who the last caller of x() was > >>and how it was called. > >> > >> > >>I am looking at it now.. but if anyone has any thoughts let me know... > > > >See >=20 > interesting... is there any documentation on how to use this and what=20 > its limitations are? >=20 > man -k stack doesn't provide anything.. grrrrr. I thought threre was a manpage but couldnt find it when I replied (hence citing the header). It's pretty trivial though, see kern/subr_stack.c and also grep for usage of stack_save. Kris --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFff9rWry0BWjoQKURAp3qAKC+DxPUFXnUUcwy3nb54Vfh/rX+4QCcDFi3 xydWwPkI+HeKUISZ4X9vVg4= =ChLn -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 01:04:38 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2EB4416A619; Tue, 12 Dec 2006 01:04:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7C2C43EB7; Tue, 12 Dec 2006 01:00:49 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBC128vC053072; Mon, 11 Dec 2006 20:02:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBC128MM064219; Mon, 11 Dec 2006 20:02:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0D6B773034; Mon, 11 Dec 2006 20:02:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212010208.0D6B773034@freebsd-current.sentex.ca> Date: Mon, 11 Dec 2006 20:02:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 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, 12 Dec 2006 01:04:38 -0000 TB --- 2006-12-12 00:09:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 00:09:23 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-12 00:09:23 - cleaning the object tree TB --- 2006-12-12 00:10:01 - checking out the source tree TB --- 2006-12-12 00:10:01 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-12 00:10:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 00:21:00 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 00:21:00 - cd /src TB --- 2006-12-12 00:21:00 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 00:21:01 UTC 2006 >>> 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 [...] /src/sbin/ifconfig/ifbridge.c:418: error: (Each undeclared identifier is reported only once /src/sbin/ifconfig/ifbridge.c:418: error: for each function it appears in.) /src/sbin/ifconfig/ifbridge.c: In function `unsetbridge_p2p': /src/sbin/ifconfig/ifbridge.c:424: error: `IFBIF_BSTP_P2P' undeclared (first use in this function) /src/sbin/ifconfig/ifbridge.c: In function `setbridge_autop2p': /src/sbin/ifconfig/ifbridge.c:430: error: `IFBIF_BSTP_AUTOP2P' undeclared (first use in this function) /src/sbin/ifconfig/ifbridge.c: In function `unsetbridge_autop2p': /src/sbin/ifconfig/ifbridge.c:436: error: `IFBIF_BSTP_AUTOP2P' undeclared (first use in this function) *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/pc98/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 01:02:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 01:02:07 - ERROR: failed to build world TB --- 2006-12-12 01:02:07 - tinderbox aborted TB --- 0.83 user 2.64 system 3163.77 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 01:28:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D57B916A403 for ; Tue, 12 Dec 2006 01:28:34 +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 A188243E5B for ; Tue, 12 Dec 2006 01:17:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBC1I5q9093337; Mon, 11 Dec 2006 18:18:11 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <457E034A.7080103@samsco.org> Date: Mon, 11 Dec 2006 18:18:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Marius Strobl References: <20061209185539.GA34399@alchemy.franken.de> <20061209201438.B42195@localhost> <20061209210629.GG86517@alchemy.franken.de> <20061210.231137.-1749707382.imp@bsdimp.com> <20061212005753.GJ86517@alchemy.franken.de> In-Reply-To: <20061212005753.GJ86517@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: nick@van-laarhoven.org, "M. Warner Losh" , current@freebsd.org Subject: Re: mk48txx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 01:28:34 -0000 Marius Strobl wrote: > On Sun, Dec 10, 2006 at 11:11:37PM -0700, M. Warner Losh wrote: >> In message: <20061209210629.GG86517@alchemy.franken.de> >> Marius Strobl writes: >> : >> : I favor having no man page over having something incomplete >> : or inadequate like f.e. esp.4 or bus_space.9 as IMO wrong >> : information can confuse way more and leaves a worse impression >> : than no information at all. >> >> bus_space.9 isn't incomplete. The problem is that it is too complete >> and general, if anything. It is hard to penetrate. > > I mentioned bus_space.9 as an example of a man page that I'd > describe as inadequate; both the sections about mapping and > unmapping as well as allocating and freeing bus space are > still verbatim from the NetBSD rev. 1.9 one AFAICT, which > describes concepts in these sections that don't really apply > to FreeBSD. Granted, on some platforms like FreeBSD/i386 > one can probably succeed in doing actual reads and writes > by only using the functions mentioned in bus_space.9, but > it totally fails to give the slightest hint (not even a .Xr) > on how to obtain the bus space tag and handle the right way > in FreeBSD, so it will actually work on all platforms, which > is the whole point of the bus_space interface. The current > bus_space.9 actually tells that some of its sections "may or > may not apply to the FreeBSD version" and "many parts of the > interface are unspecified", but that's essentially telling > the user that she/he has to figure it out herself/himself, > which IMO defeats the purpose of having a man page in the > first place. > > Marius > Hate to say it, but these things don't fix themselves. If you're hoping to shame Warner into fixing it, I think that his free time is quite spoken for. Mine is too, though I'd be happy to review corrections to it for technical and grammar correctness. Scott From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 01:42:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C906416A54F for ; Tue, 12 Dec 2006 01:42:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1206A44123 for ; Tue, 12 Dec 2006 01:32:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kBC1WeiH001249; Mon, 11 Dec 2006 18:32:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 11 Dec 2006 18:33:38 -0700 (MST) Message-Id: <20061211.183338.1120057412.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <457E034A.7080103@samsco.org> References: <20061210.231137.-1749707382.imp@bsdimp.com> <20061212005753.GJ86517@alchemy.franken.de> <457E034A.7080103@samsco.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 11 Dec 2006 18:32:41 -0700 (MST) Cc: current@freebsd.org, nick@van-laarhoven.org Subject: Re: mk48txx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 01:42:34 -0000 In message: <457E034A.7080103@samsco.org> Scott Long writes: : Marius Strobl wrote: : > On Sun, Dec 10, 2006 at 11:11:37PM -0700, M. Warner Losh wrote: : >> In message: <20061209210629.GG86517@alchemy.franken.de> : >> Marius Strobl writes: : >> : : >> : I favor having no man page over having something incomplete : >> : or inadequate like f.e. esp.4 or bus_space.9 as IMO wrong : >> : information can confuse way more and leaves a worse impression : >> : than no information at all. : >> : >> bus_space.9 isn't incomplete. The problem is that it is too complete : >> and general, if anything. It is hard to penetrate. : > : > I mentioned bus_space.9 as an example of a man page that I'd : > describe as inadequate; both the sections about mapping and : > unmapping as well as allocating and freeing bus space are : > still verbatim from the NetBSD rev. 1.9 one AFAICT, which : > describes concepts in these sections that don't really apply : > to FreeBSD. Granted, on some platforms like FreeBSD/i386 : > one can probably succeed in doing actual reads and writes : > by only using the functions mentioned in bus_space.9, but : > it totally fails to give the slightest hint (not even a .Xr) : > on how to obtain the bus space tag and handle the right way : > in FreeBSD, so it will actually work on all platforms, which : > is the whole point of the bus_space interface. The current : > bus_space.9 actually tells that some of its sections "may or : > may not apply to the FreeBSD version" and "many parts of the : > interface are unspecified", but that's essentially telling : > the user that she/he has to figure it out herself/himself, : > which IMO defeats the purpose of having a man page in the : > first place. : > : > Marius : > : : Hate to say it, but these things don't fix themselves. If you're hoping : to shame Warner into fixing it, I think that his free time is quite : spoken for. Mine is too, though I'd be happy to review corrections to : it for technical and grammar correctness. I'm happy to review things as well. I have very little free time these days due to the baby, the merger, and the mad rush to get product out ASAP. I think you overgeneralize about the defects in bus_space. It tells you the basics so you can figure it out yourself. Could it be better? Sure. Is it better than nothing like we had before? Absolutely. Warner From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 01:57:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB15A16A529 for ; Tue, 12 Dec 2006 01:57:19 +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 9740043E0F for ; Tue, 12 Dec 2006 01:55:13 +0000 (GMT) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.13.8/8.13.8/ALCHEMY.FRANKEN.DE) with ESMTP id kBC1uRje068715; Tue, 12 Dec 2006 02:56:27 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.13.8/8.13.8/Submit) id kBC1uRCt068714; Tue, 12 Dec 2006 02:56:27 +0100 (CET) (envelope-from marius) Date: Tue, 12 Dec 2006 02:56:27 +0100 From: Marius Strobl To: Scott Long Message-ID: <20061212015627.GL86517@alchemy.franken.de> References: <20061209185539.GA34399@alchemy.franken.de> <20061209201438.B42195@localhost> <20061209210629.GG86517@alchemy.franken.de> <20061210.231137.-1749707382.imp@bsdimp.com> <20061212005753.GJ86517@alchemy.franken.de> <457E034A.7080103@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457E034A.7080103@samsco.org> User-Agent: Mutt/1.4.2.2i Cc: nick@van-laarhoven.org, "M. Warner Losh" , current@freebsd.org Subject: Re: mk48txx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 01:57:20 -0000 On Mon, Dec 11, 2006 at 06:18:02PM -0700, Scott Long wrote: > Marius Strobl wrote: > >On Sun, Dec 10, 2006 at 11:11:37PM -0700, M. Warner Losh wrote: > >>In message: <20061209210629.GG86517@alchemy.franken.de> > >> Marius Strobl writes: > >>: > >>: I favor having no man page over having something incomplete > >>: or inadequate like f.e. esp.4 or bus_space.9 as IMO wrong > >>: information can confuse way more and leaves a worse impression > >>: than no information at all. > >> > >>bus_space.9 isn't incomplete. The problem is that it is too complete > >>and general, if anything. It is hard to penetrate. > > > >I mentioned bus_space.9 as an example of a man page that I'd > >describe as inadequate; both the sections about mapping and > >unmapping as well as allocating and freeing bus space are > >still verbatim from the NetBSD rev. 1.9 one AFAICT, which > >describes concepts in these sections that don't really apply > >to FreeBSD. Granted, on some platforms like FreeBSD/i386 > >one can probably succeed in doing actual reads and writes > >by only using the functions mentioned in bus_space.9, but > >it totally fails to give the slightest hint (not even a .Xr) > >on how to obtain the bus space tag and handle the right way > >in FreeBSD, so it will actually work on all platforms, which > >is the whole point of the bus_space interface. The current > >bus_space.9 actually tells that some of its sections "may or > >may not apply to the FreeBSD version" and "many parts of the > >interface are unspecified", but that's essentially telling > >the user that she/he has to figure it out herself/himself, > >which IMO defeats the purpose of having a man page in the > >first place. > > > >Marius > > > > Hate to say it, but these things don't fix themselves. If you're hoping > to shame Warner into fixing it, I think that his free time is quite > spoken for. No, that absolutely wasn't my intention. I originally just wanted to express that I prefer to add good man pages from the beginning instead of something that I can't honestly describe as useable and appropriate myself (and judging the notes Warner added to bus_space.9 I think he feels similarly about that man page; if not I apologise). Note that originally this was also about the missing man page for the API of a driver that I did touch but not initially add. That didn't keep me from doing a man page in the past but my time is limited also. Marius From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 02:04:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6EC816A412 for ; Tue, 12 Dec 2006 02:04:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A88043D8C for ; Tue, 12 Dec 2006 02:00:32 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1618499wxc for ; Mon, 11 Dec 2006 18:01:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=YrLwBjx+uCPBQXctpMf0LXMOwX9HqgjCYPqEOGG4ruEbfEmOooqUxRv+utB/c5D8zbvxfxGmXDjYbb2zgJt87L74iPg9/WbQJk26lYTUrws0YCu/8aJcl8UU+3y8aefle37gTcI4U3osFJfL0Q0vTXFFC1gPbxexf4ATg7bM8O4= Received: by 10.70.131.20 with SMTP id e20mr13590425wxd.1165888879170; Mon, 11 Dec 2006 18:01:19 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id g3sm9362004wra.2006.12.11.18.01.16; Mon, 11 Dec 2006 18:01:17 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kBC20NZQ009816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2006 11:00:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kBC20NAO009815; Tue, 12 Dec 2006 11:00:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 12 Dec 2006 11:00:23 +0900 From: Pyun YongHyeon To: "Bruce M. Simpson" Message-ID: <20061212020023.GA9698@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457DF011.9010701@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com 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 Dec 2006 02:04:44 -0000 On Mon, Dec 11, 2006 at 11:56:01PM +0000, Bruce M. Simpson wrote: > Hi, > > I successfully tested this driver under 7-CURRENT as of today on an ASUS > Vintage AH-1 based system. > > lspci has the following to say about it: > > 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E > Gigabit Ethernet Controller (rev 19) > Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit > Ethernet controller PCIe (Asus) > Flags: bus master, fast devsel, latency 0, IRQ 18 > Memory at fe4fc000 (64-bit, non-prefetchable) > I/O ports at c800 > Expansion ROM at fe4c0000 [disabled] > Capabilities: [48] Power Management version 2 > Capabilities: [50] Vital Product Data > Capabilities: [5c] Message Signalled Interrupts: 64bit+ > Queue=0/1 Enable- > Capabilities: [e0] Express Legacy Endpoint IRQ 0 > > A few sample netperf runs between this system (AMD Athlon64 3000+) and > an Intel Dothan 1.8Ghz based Lenovo T43 with bge(4) interconnected via a > 3Com 5-port gigabit workgroup switch reveal the following. > > anglepoise# netperf -t UDP_STREAM -H 192.168.123.18 > UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > 192.168.123.18 (192.168.123.18) port 0 AF_INET > Socket Message Elapsed Messages > Size Size Time Okay Errors Throughput > bytes bytes secs # # 10^6bits/sec > > 9216 9216 10.00 129443 1135712 954.30 > 42080 10.00 128739 949.11 > > > anglepoise# netperf -t UDP_RR -H 192.168.123.18 > UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > 192.168.123.18 (192.168.123.18) port 0 AF_INET > Local /Remote > Socket Size Request Resp. Elapsed Trans. > Send Recv Size Size Time Rate > bytes Bytes bytes bytes secs. per sec > > 9216 42080 1 1 10.00 2804.30 > 9216 42080 > > anglepoise# netperf -t TCP_STREAM -H 192.168.123.18 > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 > (192.168.123.18) port 0 AF_INET > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 65536 32768 32768 10.00 642.80 > > anglepoise# netperf -t TCP_RR -H 192.168.123.18 > TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > 192.168.123.18 (192.168.123.18) port 0 AF_INET > Local /Remote > Socket Size Request Resp. Elapsed Trans. > Send Recv Size Size Time Rate > bytes Bytes bytes bytes secs. per sec > > 32768 65536 1 1 10.00 2790.69 > 32768 65536 > > > anglepoise# netperf -t TCP_CRR -H 192.168.123.18 > TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET > to 192.168.123.18 (192.168.123.18) port 0 AF_INET > Local /Remote > Socket Size Request Resp. Elapsed Trans. > Send Recv Size Size Time Rate > bytes Bytes bytes bytes secs. per sec > > 32768 65536 1 1 10.00 1350.91 > 32768 65536 > > anglepoise# netperf -t TCP_MAERTS -H 192.168.123.18 > TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 > (192.168.123.18) port 0 AF_INET > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 65536 32768 32768 10.00 407.51 > > And a statistically tighter test: > > anglepoise# netperf -t TCP_STREAM -I 99 -i 30,10 -H 192.168.123.18 > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.18 > (192.168.123.18) port 0 AF_INET : +/-49.5% @ 99% conf. > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 65536 32768 32768 10.00 644.98 > > Another test, this time between the same box and a dual PIII 933Mhz > running 6.1-RELEASE with an em(4) card and 66Mhz 64-bit PCI data path on > the same workgroup switch: > > anglepoise# netperf -t TCP_STREAM -I 99 -i 30,10 -H 192.168.123.6 > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.123.6 > (192.168.123.6) port 0 AF_INET : +/-49.5% @ 99% conf. > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 262144 32768 32768 10.00 161.17 > > ...probably harder on the old machine than anything, it is very unlikely > it could saturate at line rate. > > Thank you for all the excellent work on this driver, I hope this data is > useful. > Thanks for testing. The main focus for msk(4) was for getting working native driver. Performance was not heavily tested and highly likely to be lower than that of optimal performance. It seems that myk(4) has several workarounds for better performance but that magic code is hard to verify wihtout errata information from vendor. :-( Btw, I'll commit msk(4) in two days if there is no breakage report for e1000phy(4). > regards, > BMS -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 03:07:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA3C116A47C; Tue, 12 Dec 2006 03:07:33 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B8543CA4; Tue, 12 Dec 2006 03:06:13 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id B0ACB8C99B0; Tue, 12 Dec 2006 11:07:32 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id A6EE38C999B; Tue, 12 Dec 2006 11:07:32 +0800 (CST) Date: Tue, 12 Dec 2006 11:07:32 +0800 (CST) From: Tai-hwa Liang To: Robert Watson In-Reply-To: <20061211140519.Q4227@fledge.watson.org> Message-ID: <06121210363618.51815@www.mmlab.cse.yzu.edu.tw> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> <20061211140519.Q4227@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 03:07:34 -0000 On Mon, 11 Dec 2006, Robert Watson wrote: > On Mon, 11 Dec 2006, Tai-hwa Liang wrote: > >>> WITNESS is available in RELENG_6, and should be used in combination with >>> INVARIANTS, DDB, KDB, and BREAK_TO_DEBUGGER to debug deadlocks. >> >> Would a kernel with WITNESS/[KD]DB/BREAK_TO_DEBUGGER enabled but w/o >> INVARIANTS compiled adequate to dump useful information through remote >> serial console? > > It depends a lot on the deadlock. The warnings you've attached below provide > a lot of information, however. > >>> It sounds like you need to follow the instructions for kernel debugging. >>> Depending on your tolerance of performance loss, downtime, etc, a good >>> starting point is to configure the kernel with INVARIANTS and WITNESS. >>> WITNESS is particularly important, if you can tolerate the performance >>> hit, as it warns of potential deadlocks, not just actual deadlocks. Also, >>> compile >> >> With WITNESS enabled(debug.mpsafenet=0), I got another three pf related >> warnings in the last 8 hours: > > Are you using uid/gid credential rules with pf? I presume that you're talking about "user" and "group" keywords in the rule. If that's the case, then no, we did not use uid/gid credential in pf rules. >>> the kernel with KDB, DDB, and BREAK_TO_DEBUGGER, and user a serial or >>> firewire console. If the hang occurs, see if you can get into the >>> debugger, in which case the logged output from DDB for the following >>> commands would be very useful: >>> >>> show pcpu >>> show allpcpu >>> trace >>> alltrace >>> ps >>> show locks >>> show alllocks >>> show lockedvnods >>> show uma >>> show malloc >>> >>> Please open a PR that describes your configuration, includes your kernel >>> config (since it seems quite customized), any loader.conf settings, a >>> detailed description of the problem, and the output. I'd be quite >>> interested >> >> Okay, I'll file a PR once I can collect more information with the serial >> console(probably weekend). For now our system administrator is pretty >> nervous about my suggestion on turning debug.mpsafenet back to 1. ;) > > Thanks. > >>> in know, once the machine is in a hung state, whether the numlock light >>> goes on and off when you hit the numlock key on the keyboard. >> >> The numlock light doesn't respond to the key when the machine is hanging; >> hence Ctrl-Alt-Esc wouldn't break to debugger. > > Serial break is significantly more reliable for getting into the debugger on > the system as it stands, as syscons requires the Giant lock while the serial > interrupt handler doesn't. As a result, serial break can often get you into > the debugger even when Giant has been leaked. The numlock light not going on > and off is a reasonable test of whether Giant has been leaked and/or > interrupts have been left disabled on all CPUs, as it means that the syscons > interrupt handler is unable to run, hence my inquiring. Thanks for the elaboration. BTW, it appears to me that in order to use a serial console, I have to keep the following in /boot/loader.conf: console="comconsole,vidconsole" I'd be interested to know that if there is any "console mux" like knobs available such that console output can go comconsole and vidconsole at the same time? That is, with aforementioned console order, booting message(after those 'highlighted' text messages generated by kernel printf()) only goes to serial console, not the video one. -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 03:26:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5660016A412 for ; Tue, 12 Dec 2006 03:26:58 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9235543CAB for ; Tue, 12 Dec 2006 03:25:36 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1392988uge for ; Mon, 11 Dec 2006 19:26:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=aEA+EE99/7lEV2AiBi9tZm6NrLC+ZIDMBL7YG7A0e2kdGhR+qBymG/qn1aA/YnOgHLr8TZl1CouM8zB/D/d2+eelHIf4a5rkjTeDUBtfXPUVLeQiwuZy7DRxBi2Wq7M4ut//pv3KPfxqqJFG6Ijvo2w1Gti+kRc3rbVzErvFey4= Received: by 10.78.204.1 with SMTP id b1mr1904230hug.1165894015291; Mon, 11 Dec 2006 19:26:55 -0800 (PST) Received: by 10.78.164.20 with HTTP; Mon, 11 Dec 2006 19:26:55 -0800 (PST) Message-ID: Date: Tue, 12 Dec 2006 06:26:55 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Tai-hwa Liang" In-Reply-To: <06121210363618.51815@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> <20061211140519.Q4227@fledge.watson.org> <06121210363618.51815@www.mmlab.cse.yzu.edu.tw> X-Google-Sender-Auth: 2e42ce30dcc8d454 Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 03:26:58 -0000 On 12/12/06, Tai-hwa Liang wrote: > I'd be interested to know that if there is any "console mux" like knobs > available such that console output can go comconsole and vidconsole > at the same time? Try boot_multicons in loader.conf (or boot -D in loader prompt) From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 03:55:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AA4516A407 for ; Tue, 12 Dec 2006 03:55:34 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B814443CAE for ; Tue, 12 Dec 2006 03:54:13 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.9] (cpe-24-33-245-212.twmi.res.rr.com [24.33.245.212]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id kBC3tSqb024324; Mon, 11 Dec 2006 22:55:28 -0500 (EST) (envelope-from andy@siliconlandmark.com) In-Reply-To: <20061212020023.GA9698@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> <20061212020023.GA9698@cdnetworks.co.kr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> Content-Transfer-Encoding: 7bit From: Andre Guibert de Bruet Date: Mon, 11 Dec 2006 22:56:02 -0500 To: pyunyh@gmail.com X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.88.6/2316/Mon Dec 11 17:50:59 2006 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=0.548, required 6, AWL -0.04, BAYES_00 -2.60, RCVD_IN_SORBS_DUL 2.05, SPF_FAIL 1.14) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 03:55:34 -0000 On Dec 11, 2006, at 9:00 PM, Pyun YongHyeon wrote: > Thanks for testing. The main focus for msk(4) was for getting working > native driver. Performance was not heavily tested and highly likely > to be lower than that of optimal performance. It seems that myk(4) has > several workarounds for better performance but that magic code is hard > to verify wihtout errata information from vendor. :-( > > Btw, I'll commit msk(4) in two days if there is no breakage report > for e1000phy(4). I have been using the msk driver without any problems on an Intel SE7520BD2 server board. We have a few of these at work, and it's nice to see that we will finally be able to use this second NIC on these boards! At this point, are there plans to MFC the e1000phy changes and the msk driver? Thanks for all your hard work! Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 03:56:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 880C216A4AB for ; Tue, 12 Dec 2006 03:56:45 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D28143CBE for ; Tue, 12 Dec 2006 03:55:21 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id kBC3udGB060322; Mon, 11 Dec 2006 21:56:39 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <457E2882.1030109@centtech.com> Date: Mon, 11 Dec 2006 21:56:50 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.7 (X11/20061015) MIME-Version: 1.0 To: Rod Person References: <200612111031.06109.rodperson@comcast.net> In-Reply-To: <200612111031.06109.rodperson@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2316/Mon Dec 11 16:50:59 2006 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: Current Mailing List Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 03:56:45 -0000 On 12/11/06 09:31, Rod Person wrote: > Hi All, > > I'm having a problem with the latest nvidia driver on 7 current. This driver > is causing a few problem with my system. > > 1) When I start X either by using the startx command or using a Graphical > login manager such as gdm or kdm, I can not switch virtual consoles using > ALT+F#. Doing so locks my system. > > 2) Once X is started, trying to kill X or log out of a window manager using > any method, such as CTRL + Backspace or the exit function of a Window Manager > causes my machine to lock. > > In either case, the only thing I can do is hit the power button and reset. > > I was wondering if anyone else is seeing this or has any suggestions on > correcting this behavior. Currently I switched to the nv driver, but that > driver does not support the max resolution of my widescreen monitor > (1680x1050) only the nvidia driver does. > > My graphics card is XFX ndivida 7800 GTX with 256MB Ram. I last rebuilt my > world on Dec 9th. Any suggestion would be helpful. For what it's worth, the nv driver works ok for my laptop running at 1920x1200. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 05:56:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 355AB16A40F for ; Tue, 12 Dec 2006 05:56:09 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D476943CBB for ; Tue, 12 Dec 2006 05:54:44 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1416768uge for ; Mon, 11 Dec 2006 21:56:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h8f+ECuQ98zmjT2BUn2zgLaXo4r/8OQM9to2ALUdRdbgyH5NXeuR/EMKIVOAOlENQlLAv6+d7+zhcPI1crtoQyYBfKjFAhkR6r/+1OgTd/u7w9xiToXVMrJ0SkcP55V3P/3V03II3cn2mkkxmomzcdI2BRZiziIGeQpwQaC2eUs= Received: by 10.67.21.11 with SMTP id y11mr11139166ugi.1165902964454; Mon, 11 Dec 2006 21:56:04 -0800 (PST) Received: by 10.67.86.15 with HTTP; Mon, 11 Dec 2006 21:56:02 -0800 (PST) Message-ID: <790a9fff0612112156s359f1cc3w68c3d4b39661832c@mail.gmail.com> Date: Mon, 11 Dec 2006 23:56:04 -0600 From: "Scot Hetzel" To: FreeBSD-CURRENT , "Bill Paul" In-Reply-To: <790a9fff0611251051md2ef50cja84440ba3cc7942f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0611251051md2ef50cja84440ba3cc7942f@mail.gmail.com> Cc: Subject: Re: Latest Broadcom NDIS driver requires 4 additional functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 05:56:09 -0000 On 11/25/06, Scot Hetzel wrote: > Unimplemented Functions: > memchr - implemented but causes "cast discards qualifiers from pointer target type" : > > Any ideas as to how to fix memchr, ... ? > I was able to fix memchr with the help of one of my college professors, he provided me with two different solutions to get rid of the cast problem. #ifdef BROKEN_MEMCHR static void *ntoskrnl_memchr(const void *, int, size_t); /* * /usr/src/sys/modules/ndis/../../compat/ndis/subr_ntoskrnl.c: In function `ntoskrnl_memchr': * /usr/src/sys/modules/ndis/../../compat/ndis/subr_ntoskrnl.c:465: warning: cast discards qualifiers from pointer target type * *** Error code 1 */ static void * ntoskrnl_memchr(buf, ch, len) const void *buf; unsigned char ch; size_t len; { if (len != 0) { const unsigned char *p = buf; do { if (*p++ == ch) { return ((void *)(p - 1)); /* error occurs here */ } } while (--len != 0); } return (NULL); } #endif #ifdef FIX1_MEMCHR static void *ntoskrnl_memchr(void *, int, size_t); static void * ntoskrnl_memchr(buf, ch, len) void *buf; unsigned char ch; size_t len; { if (len != 0) { unsigned char *p = buf; do { if (*p++ == ch) { return ((void *)(p - 1)); } } while (--len != 0); } return (NULL); } #endif #ifdef FIX2_MEMCHR static const void *ntoskrnl_memchr(const void *, int, size_t); static const void * ntoskrnl_memchr(buf, ch, len) const void *buf; unsigned char ch; size_t len; { if (len != 0) { const unsigned char *p = buf; do { if (*p++ == ch) { return ((const void *)(p - 1)); } } while (--len != 0); } return (NULL); } #endif Which version should I use as a follow up to PR 106131. http://www.freebsd.org/cgi/query-pr.cgi?pr=106131 Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 06:46:32 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F2CA16A407 for ; Tue, 12 Dec 2006 06:46:32 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 933C343CCE for ; Tue, 12 Dec 2006 06:45:10 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.9] (cpe-24-33-245-212.twmi.res.rr.com [24.33.245.212]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id kBC6kMEY027637 for ; Tue, 12 Dec 2006 01:46:22 -0500 (EST) (envelope-from andy@siliconlandmark.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@freebsd.org From: Andre Guibert de Bruet Date: Tue, 12 Dec 2006 01:46:56 -0500 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.88.6/2316/Mon Dec 11 17:50:59 2006 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=0.499, required 6, AWL -0.09, BAYES_00 -2.60, RCVD_IN_SORBS_DUL 2.05, SPF_FAIL 1.14) X-MailScanner-From: andy@siliconlandmark.com Cc: Subject: QUOTA on CURRENT: mount -a -l gives "mount: /dev/amrd0s1a Unable to initialize radix node head: No buffer space available" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 06:46:32 -0000 Hi, On my desktop system, I am getting the following message when trying to do a mount -a -l (As rc.d/mountlate does) when I have QUOTA enabled in my kernel: mount: /dev/amrd0s1a Unable to initialize radix node head: No buffer space available On this system /dev/amrd0s1a is the root (/) directory. My fstab can be found at http://bling.properkernel.com/freebsd/fstab and my kernel config is up at http://bling.properkernel.com/freebsd/BLING . As you can see from the fstab, there are no user or group quotas enabled on the system at this point in time (I have not tested to see if this made a difference). All filesystems have been fsck'ed and confirmed sane as of 5 minutes ago. uname -a: FreeBSD bling.properkernel.com 7.0-CURRENT FreeBSD 7.0- CURRENT #1: Mon Dec 11 03:17:27 EST 2006 root@bling.properkernel.com:/usr/obj/usr/src/sys/BLING i386 Commenting out QUOTA from the config returns the expected behavior. Any ideas? Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 07:12:28 2006 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE74416A403 for ; Tue, 12 Dec 2006 07:12:28 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B83643D5D for ; Tue, 12 Dec 2006 07:10:46 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1Gu1o4-0005Bi-6r for Current@freebsd.org; Tue, 12 Dec 2006 09:12:04 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gu1o0-0000ca-BB for Current@freebsd.org; Tue, 12 Dec 2006 09:12:00 +0200 To: Current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Tue, 12 Dec 2006 09:12:00 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2316/Tue Dec 12 00:50:59 2006) Cc: Subject: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 07:12:28 -0000 Hi Does anyone know how to get this working? none6@pci1:9:0: class=0x070002 card=0x40371409 chip=0x71681409 rev=0x01 hdr=0x00 vendor = 'Timedia Technology Co Ltd' device = 'SUN 1889 / SUN 1699 PCI / ISA Asynchronous UART Signal Chips Solution' class = simple comms Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 07:33:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F41C716A415 for ; Tue, 12 Dec 2006 07:33:58 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from av7-2-sn3.vrr.skanova.net (av7-2-sn3.vrr.skanova.net [81.228.9.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0407643CBA for ; Tue, 12 Dec 2006 07:32:32 +0000 (GMT) (envelope-from joel@FreeBSD.org) Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 589C137FAF; Tue, 12 Dec 2006 08:33:33 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 354DE37F93; Tue, 12 Dec 2006 08:33:33 +0100 (CET) Received: from dude.automatvapen.se (81-234-214-163-no68.tbcn.telia.com [81.234.214.163]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 0724237E74; Tue, 12 Dec 2006 08:33:51 +0100 (CET) From: Joel Dahl To: Rod Person In-Reply-To: <200612111031.06109.rodperson@comcast.net> References: <200612111031.06109.rodperson@comcast.net> Content-Type: text/plain Date: Tue, 12 Dec 2006 08:33:51 +0100 Message-Id: <1165908831.672.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Current Mailing List Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 07:33:59 -0000 On Mon, 2006-12-11 at 10:31 -0500, Rod Person wrote: > Hi All, > > I'm having a problem with the latest nvidia driver on 7 current. This driver > is causing a few problem with my system. Regressions and problems in the Nvidia driver should probably be reported to the dedicated FreeBSD Forum over at nvnews (since this is where the Nvidia developers hang out): http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 -- Joel From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 07:50:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 707BD16A50A for ; Tue, 12 Dec 2006 07:50:21 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-1.orange.nl (smtp-1.orange.nl [193.252.22.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E7A743DBC for ; Tue, 12 Dec 2006 07:48:37 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6006.orange.nl (SMTP Server) with ESMTP id 1F3167000081 for ; Tue, 12 Dec 2006 08:49:55 +0100 (CET) X-ME-UUID: 20061212074956127.1F3167000081@mwinf6006.orange.nl Received: (qmail 78962 invoked from network); 12 Dec 2006 07:49:55 -0000 Received: from 10.66.0.143 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:1(10.66.0.143):. Processed in 0.389399 secs); 12 Dec 2006 07:49:55 -0000 X-Qmail-Scanner-Mail-From: nick@van-laarhoven.org via uitsmijter.van-laarhoven.org X-Qmail-Scanner: 1.25 (Clear:RC:1(10.66.0.143):. Processed in 0.389399 secs) Received: from unknown (HELO van-laarhoven.org) (nick@10.66.0.143) by uitsmijter.van-laarhoven.org with SMTP; 12 Dec 2006 07:49:55 -0000 Received: (nullmailer pid 1308 invoked by uid 1001); Tue, 12 Dec 2006 07:49:53 -0000 Date: Tue, 12 Dec 2006 08:49:53 +0100 (CET) From: Nick Hibma X-X-Sender: nick@localhost To: John Baldwin In-Reply-To: <200612111608.06677.jhb@freebsd.org> Message-ID: <20061212084536.M1171@localhost> References: <20061210110419.H42195@localhost> <200612111608.06677.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Slight interface change on the watchdog fido X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 07:50:21 -0000 > It would be nice to not lose the comments. Might also be nice to reduce the > diff (so it doesn't have to reindent everything) by just adding a simple test > after masking off WD_INTERVAL like so: > > if (cmd == 0 || cmd >= 64) { > ipmi_set_watchdog(sc, 0); > return; > } The code path pretty much requires the if (cmd > 0 && valid(cmd) { wd(set); *error = 0; } else if (wd(active)) { wd(disable); } due to the way *error was defined. I've added back the comments that were more than trivial. Nick From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 09:40:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11C3F16A4A0 for ; Tue, 12 Dec 2006 09:40:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35C4843CA9 for ; Tue, 12 Dec 2006 09:38:52 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 5EDFA20029C; Tue, 12 Dec 2006 10:40:12 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 7164020018A; Tue, 12 Dec 2006 10:40:05 +0100 (CET) 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 DEE79444885; Tue, 12 Dec 2006 09:38:12 +0000 (UTC) Date: Tue, 12 Dec 2006 09:38:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Ian FREISLICH In-Reply-To: Message-ID: <20061212093736.I91892@maildrop.int.zabbadoz.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: FreeBSD current mailing list Subject: Re: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 09:40:22 -0000 On Tue, 12 Dec 2006, Ian FREISLICH wrote: > Does anyone know how to get this working? > > none6@pci1:9:0: class=0x070002 card=0x40371409 chip=0x71681409 rev=0x01 hdr=0x00 > vendor = 'Timedia Technology Co Ltd' > device = 'SUN 1889 / SUN 1699 PCI / ISA Asynchronous UART Signal Chips Solution' > class = simple comms man 4 puc should do it. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 10:55:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 633E616A47C for ; Tue, 12 Dec 2006 10:55:09 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE86343CCC for ; Tue, 12 Dec 2006 10:53:20 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1469107uge for ; Tue, 12 Dec 2006 02:54:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KNYTKDz3Q5/0TLjB+OJmh1MW35EdXcmmvjocS2/Gho99PdKfvctl2hQk5bR08BsaldjSBsH74xTLuO4XP62wRaWBXrtIchr812AO9dNaG8oDSgbzmrW0xPdpDC0ySuj3OUXEDDV4yLosIDfd9OTny4odQX+AwD3HDyMnI8Sg4oc= Received: by 10.78.50.5 with SMTP id x5mr2462581hux.1165920880622; Tue, 12 Dec 2006 02:54:40 -0800 (PST) Received: by 10.78.145.16 with HTTP; Tue, 12 Dec 2006 02:54:40 -0800 (PST) Message-ID: Date: Tue, 12 Dec 2006 11:54:40 +0100 From: "Pascal Hofstee" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: umass intermittently "stalling" ... processes seemingly stuck in "wdrain" 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, 12 Dec 2006 10:55:09 -0000 I recently bought an USB Mass Storage unit (about 300GB) and a 4+1 slot PCI USB2.0 card (since it's an old box that didn't have USB 2 on board yet), and i have noticed that intermittently the device "stalls" any operations that try to access it: - copying data onto the disk - reading data from the disk - running an ls while inside a directory on the disk's mount point Today while trying to scp a fairly large set of files from my office system to my umass disk at home i noticed the similar stalling behaviour and decided to check ps output on my home system. There i noticed that every single time to scp session would begin stalling (lasting up to about 30-40s per stall) ... the scp process on my home-system would have dropped into a wdrain state. As soon as the scp process (after about 30 or more seconds) would finally get out of this wdrain state (usually into an sbwait state) the scp process on my work system would start picking up transfer speed again until the next slip into wdrain. I haven't been able to test this on a non-CURRENT system yet so i am not sure wether or not this is a CURRENT only issue or a more generic problem, but if somebody could give some pointers on where to start looking on fixing this ... i am open for suggestions. -- Pascal From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 12:45:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 543CB16A40F for ; Tue, 12 Dec 2006 12:45:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5450743CA7 for ; Tue, 12 Dec 2006 12:43:58 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so878975wra for ; Tue, 12 Dec 2006 04:45:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=sWGX0fk0HO7yCjgYASa4N2I7CA6pj1VAuRg7fRuZYOvPOF5D/mPT+DXJl9+0WR0b4BOzUOg/cxFGgvfwzHbr8mHzEhwSoNc7FFH6jSLWUMJrazMjmbfD4LcjIx70LoaIwP08mkhDAG+brZcy7P8J4VA59jXrSh+ab/lEciobG4I= Received: by 10.90.86.10 with SMTP id j10mr8224966agb.1165927516039; Tue, 12 Dec 2006 04:45:16 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id g3sm10171023wra.2006.12.12.04.45.13; Tue, 12 Dec 2006 04:45:14 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kBCCiTQt011538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2006 21:44:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kBCCiSls011537; Tue, 12 Dec 2006 21:44:28 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 12 Dec 2006 21:44:28 +0900 From: Pyun YongHyeon To: Andre Guibert de Bruet Message-ID: <20061212124428.GB9698@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> <20061212020023.GA9698@cdnetworks.co.kr> <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com 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 Dec 2006 12:45:22 -0000 On Mon, Dec 11, 2006 at 10:56:02PM -0500, Andre Guibert de Bruet wrote: > On Dec 11, 2006, at 9:00 PM, Pyun YongHyeon wrote: > > >Thanks for testing. The main focus for msk(4) was for getting working > >native driver. Performance was not heavily tested and highly likely > >to be lower than that of optimal performance. It seems that myk(4) has > >several workarounds for better performance but that magic code is hard > >to verify wihtout errata information from vendor. :-( > > > >Btw, I'll commit msk(4) in two days if there is no breakage report > >for e1000phy(4). > > I have been using the msk driver without any problems on an Intel > SE7520BD2 server board. We have a few of these at work, and it's nice I guess it uses 88E8050. Would you post msk(4)/e1000phy(4) attach message in dmesg? > to see that we will finally be able to use this second NIC on these > boards! > > At this point, are there plans to MFC the e1000phy changes and the > msk driver? > The msk(4) requires new APIs in CURRENT to support MSI/TSO. If jhb@ MFC his MSI support code and andre@ MFC his TSO support code it could be done without much trouble. If they don't I have to write a couple of code fragments which disables MSI/TSO which in turn takes a time than that of usual MFC candidate. ATM I think it takes 1 month provided that MSI/TSO code is MFCed. > Thanks for all your hard work! > > Andy > > /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ > /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ > /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 12:47:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A9F516A583 for ; Tue, 12 Dec 2006 12:47:59 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8365543CC3 for ; Tue, 12 Dec 2006 12:46:36 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A7155.dip.t-dialin.net [84.154.113.85]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id kBCClu2X051452; Tue, 12 Dec 2006 13:47:56 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id kBCClnDh006541; Tue, 12 Dec 2006 13:47:50 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id kBCClnAG002515; Tue, 12 Dec 2006 13:47:49 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200612121247.kBCClnAG002515@fire.jhs.private> To: "Pascal Hofstee" In-reply-to: References: Comments: In-reply-to "Pascal Hofstee" message dated "Tue, 12 Dec 2006 11:54:40 +0100." Date: Tue, 12 Dec 2006 13:47:49 +0100 From: "Julian H. Stacey" Cc: FreeBSD Current Subject: Re: umass intermittently "stalling" ... processes seemingly stuck in "wdrain" 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, 12 Dec 2006 12:47:59 -0000 "Pascal Hofstee" wrote: > I recently bought an USB Mass Storage unit (about 300GB) and a 4+1 > slot PCI USB2.0 card (since it's an old box that didn't have USB 2 on > board yet), and i have noticed that intermittently the device "stalls" > any operations that try to access it: > > - copying data onto the disk > - reading data from the disk > - running an ls while inside a directory on the disk's mount point > > Today while trying to scp a fairly large set of files from my office > system to my umass disk at home i noticed the similar stalling > behaviour and decided to check ps output on my home system. There i > noticed that every single time to scp session would begin stalling > (lasting up to about 30-40s per stall) ... the scp process on my > home-system would have dropped into a wdrain state. > > As soon as the scp process (after about 30 or more seconds) would > finally get out of this wdrain state (usually into an sbwait state) > the scp process on my work system would start picking up transfer > speed again until the next slip into wdrain. > > I haven't been able to test this on a non-CURRENT system yet so i am > not sure wether or not this is a CURRENT only issue or a more generic > problem, but if somebody could give some pointers on where to start > looking on fixing this ... i am open for suggestions. I've seen stalling on 1 of 2 x 6.1-RELEASE hosts. I was given an 80 Gig external USB (Freecom) (disc reported to be unstable on XP, but as I don't run XP ... :-). I ran disc for a long time OK via a Zediworks USB2 powered hub, to a Belkin USB2 Cardbus on my laptop with 6.1-RELEASE. No recent problems (OK, various USB2 devices on laptop used to cause crashes, (that didnt crash on the inbuilt USB-1), I assumed it was because Belkin overheating - card got too hot to touch in middle ! (My brother reckons his Belkin may have died in my laptop under FreeBSD, his identical laptop didnt kill his Belkin under XP - my guess was maybe FreeBSD wasn't switching Belkin card into idle state to keep it cool ? but that's another issue)). Moved 80G drive to a direct connection on main 6.1-RELEASE tower. Persistent hangs. umount -f would eventually work, then I did fsck & mount, & repeated. I didnt observe ps states. Moved disc back to laptop, no hangs. I'd assumed hardware problem & thought next to try moving hub too. Now I've read your post I'll look at PS states too. (My 80G drive is a 3.5" with own power supply, not a laptop drive in external unpowered box needing more than the 0.5A delivered by a USB connection.) -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. http://berklix.org/free-software From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 08:45:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3799016A40F; Tue, 12 Dec 2006 08:45:33 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7767143C9E; Tue, 12 Dec 2006 08:44:11 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.100] (c-67-188-127-3.hsd1.ca.comcast.net [67.188.127.3]) by elvis.mu.org (Postfix) with ESMTP id ADDDA1A4D8E; Tue, 12 Dec 2006 00:45:32 -0800 (PST) Message-ID: <457E6C06.1020405@FreeBSD.org> Date: Tue, 12 Dec 2006 00:44:54 -0800 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kostik Belousov References: <456950AF.3090308@sh.cvut.cz> <20061127092146.GA69556@deviant.kiev.zoral.com.ua> In-Reply-To: <20061127092146.GA69556@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Dec 2006 13:00:49 +0000 Cc: freebsd-stable@freebsd.org, V??clav Haisman , tegge@freebsd.org, bde@freebsd.org, freebsd-current@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 08:45:33 -0000 Kostik Belousov wrote: > On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > >>Hi, >>the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6.1 >>with relatively recent kernel, from last week or so. >> >>-- >>VH > > >>+lock order reversal: >>+ 1st 0xc537f300 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547 >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:138 >>+KDB: stack backtrace: >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at kdb_backtrace+0x2f >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at witness_checkorder+0x5fe >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at _mtx_lock_flags+0x32 >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at ufs_itimes+0x6c >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at ufs_getattr+0x20 >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at VOP_GETATTR_APV+0x3a >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at VOP_WRITE_APV+0x148 >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at vn_write+0x201 >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at dofilewrite+0x84 >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = 0xbfbfea1c, ebp = 0xbfbfea48 --- > > > Thank you for the report. The LOR is caused by my commit into > sys/ufs/ufs/ufs_vnops.c, rev. 1.280. Is the mount lock really required, if all we're doing is a single read of a single word (mnt_kern_flags) (v_mount should be read-only for the whole lifetime of the vnode, I believe)? After all, reads of a single word are atomic on all our supported architectures. The only situation I see where there MIGHT be problems are forced unmounts, but I think there are bigger issues with those. Sorry for noticing this email only now. -- Suleiman From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 13:01:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D63116A412 for ; Tue, 12 Dec 2006 13:01:39 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8288F43CAA for ; Tue, 12 Dec 2006 12:59:46 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 12 Dec 2006 05:01:03 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kBCD11u8007466 for ; Tue, 12 Dec 2006 05:01:01 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kBCD11dE008864 for ; Tue, 12 Dec 2006 05:01:01 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 05:01:01 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 05:01:01 -0800 Message-ID: <457EA7E3.2010302@cisco.com> Date: Tue, 12 Dec 2006 08:00:19 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2006 13:01:01.0355 (UTC) FILETIME=[92F84FB0:01C71DED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5109; t=1165928461; x=1166792461; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20curious=20results |Sender:=20; bh=4MZGJN9wQY4BM7pat4aoL610n74LPrScwMpsJupXPpM=; b=taRua4dUtc6sApxQj+8fx1GPs3JtrvHyDtiaFfPNDhsL9gbELh+twVtnyKdJT35a+V2sbcAT Dxi94WUdEcI7nfLJv5xB8LdplIZ51U8kCFI0oMHMs1nMf/psZ9qbPQFO; Authentication-Results: sj-dkim-5; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); Subject: curious results X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 13:01:39 -0000 All: I have two machines I am testing with... a Intel Xeon 2.8 Gig w/hyperthreading... and a Intel P4D dual core. Now I am testing SCTP and how it interacts with SMP.. or that is my intention. I have a snapshot of the MPI code that one of my friends at UBC has been working on with Argonne Labs... This uses SCTP :-) He has written a serious of tests which all now pass (after a LOT of bugs and LOR's.. all kinds of fun :D) Now a seperate test he has written is something called mywaitall. Basically you setup a number of processes, all of them get up and settled in. Then they coordinate (near as I can tell) sharing SCTP port and address info with each other via TCP. Then they switch over and use the SCTP one-2-many model.. sending data to each other setting up implicit connections. This means that running -np 10.. I have 10 endpoints with 90 associations ... I am doing this only on the local host side. I run this in a while true do mpiexec -np 10 ./mywaitall echo "-------" done Now on the xeon machine I see a very curious failure. After about a day of running this. I get two endpoints stuck one has data to be transmitted the other is waiting for it.. (the way the program works is they all send/rcv some info and then say goodbye to each other). Now I am seeing loss because the app version I have is buggy... the author did not handle the sending in non-blocking mode correctly. He thought he got a -1/EAGAIN.. instead of a 0/0 back.. so he ends up in a tight loop doing while (sent > -1) ret = dothesend() if(ret < 0) break // error sent += ret; Which means we peg the CPU sending with full send windows.. He has fixed this.. but I keep testing with the buggy version since it finds somemany unique problems :-) But back to my scenario. Now I have, in the past, fixed many bugs like this that were an SCTP problem :-) but this one I don't think so anymore.. When I find and look at the assoc's in question the sender has some outstanding chunks (4 in the last instance) and its timer is running as far as it is concerned. Here is the actual callout structure: $6 = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xc6dd02a8}}, c_time = 264796819, c_arg = 0xc27201ec, c_func = 0xc0748458 , c_mtx = 0x0, c_flags = 22} Now there is another part to the structure (the c_arg) and if I look in there I see things like it being started 1 second before (which one would excpect... I save the ticks of when it was started). I also have a stopped_from field that gets set any time someone does a stop of the timer and when the callout is called it sets it to various values. The time structure is opaque to the SCTP code so it does not play with these values.. and when you look at the ticks, its long past expiration.. Note that the 22 indicates NO_MTX | PENDING and ACTIVE. And yet the linked lists in c_links is NOT set to anything like I normally see these dudes.. Now I did put a extra global SCTP lock in before starting/stopping the timer. This did make it take 2-3 days to hit this case.. but it still happens.... Has anyone seen this ?? I have looked at the timer code and I do see a mutex spin lock.. but I can't see how SCTP would be causing this... I am stumped .. any suggestions would be welcome ;-) -------------------- My second problem is even more bizzare.. if thats possible...:-D The other p4d runs along fine for a day or so .. and then it will just stop.. and I mean stop.. if you have a top window up (I have x off.. to panic it when I want :-D) you see the time frozen. No updates... it just freezes... If you type in anything.. the machine picks up again and starts running as if nothing had happened. The last time I created this the time had been frozen for at least 12 hours before I got to it :-D I dropped directly into KDB and pulled a crash dump... Looking at all of the SCTP assoc's there was NOTHING happening.. no data in flight.. nothing... Now in the past type any key, change to another set of windows ... and ta-da.. off it runs.. I do see a few TCP timeout alarms in the app (remember the app talks TCP to setup the SCTP stuff)... Very wierd... Any ideas or suggestions would be welcome. I just did an update in prep of doing a patch (currently passed to gnn for approval).. so my cores are invalid.. but I can recreate them pretty easily .. it just takes a day or so :-) I can also let anyone that is interested in when the event occurs of problem one to the machine... and let them puruse the timers or whatever of the running kernel.. or take a crash dump and let you look at that.. If anyone has heard of anything like this I would appreciate some pointers.. it could be something SCTP is doing... at least the timer one.. Thanks for any suggestions.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 10:22:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19A3016A49E; Tue, 12 Dec 2006 10:22:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0487C43EEB; Tue, 12 Dec 2006 10:18:00 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBCAJ4ap092429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2006 12:19:04 +0200 (EET) (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.13.8/8.13.8) with ESMTP id kBCAJ4Gg073302; Tue, 12 Dec 2006 12:19:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBCAJ3md073301; Tue, 12 Dec 2006 12:19:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Dec 2006 12:19:03 +0200 From: Kostik Belousov To: Suleiman Souhlal Message-ID: <20061212101903.GF311@deviant.kiev.zoral.com.ua> References: <456950AF.3090308@sh.cvut.cz> <20061127092146.GA69556@deviant.kiev.zoral.com.ua> <457E6C06.1020405@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J4XPiPrVK1ev6Sgr" Content-Disposition: inline In-Reply-To: <457E6C06.1020405@FreeBSD.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua X-Mailman-Approved-At: Tue, 12 Dec 2006 13:10:27 +0000 Cc: freebsd-stable@freebsd.org, V??clav Haisman , tegge@freebsd.org, bde@freebsd.org, freebsd-current@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 10:22:15 -0000 --J4XPiPrVK1ev6Sgr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > Kostik Belousov wrote: > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > > > >>Hi, > >>the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6= .1 > >>with relatively recent kernel, from last week or so. > >> > >>-- > >>VH > > > > > >>+lock order reversal: > >>+ 1st 0xc537f300 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547 > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @=20 > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > >>+KDB: stack backtrace: > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at=20 > >>kdb_backtrace+0x2f > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at=20 > >>witness_checkorder+0x5fe > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at=20 > >>_mtx_lock_flags+0x32 > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at=20 > >>ufs_itimes+0x6c > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at=20 > >>ufs_getattr+0x20 > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at= =20 > >>VOP_GETATTR_APV+0x3a > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at=20 > >>VOP_WRITE_APV+0x148 > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at vn_write+0x201 > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at=20 > >>dofilewrite+0x84 > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > >>+--- syscall (4, FreeBSD ELF32, write), eip =3D 0x2831d727, esp =3D=20 > >>0xbfbfea1c, ebp =3D 0xbfbfea48 --- > > > > > >Thank you for the report. The LOR is caused by my commit into > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. >=20 > Is the mount lock really required, if all we're doing is a single read of= a=20 > single word (mnt_kern_flags) (v_mount should be read-only for the whole= =20 > lifetime of the vnode, I believe)? After all, reads of a single word are= =20 > atomic on all our supported architectures. > The only situation I see where there MIGHT be problems are forced unmount= s,=20 > but I think there are bigger issues with those. > Sorry for noticing this email only now. The problem is real with snapshotting. Ignoring MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode inactivation time. This was the big trouble with nfsd and snapshots. As such, I think that precise value of mmnt_kern_flag is critical there, and mount interlock is needed. Practically speaking, I agree with claim that reading of m_k_f is surrounded by enough locked operations that would make sure that the read value is not stale. But there is no such guarantee on future/non-i386 arches, isn't it ? As a side note, mount interlock scope could be reduced there. Index: ufs/ufs/ufs_vnops.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 RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v retrieving revision 1.283 diff -u -r1.283 ufs_vnops.c --- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 -0000 1.283 +++ ufs/ufs/ufs_vnops.c 12 Dec 2006 10:18:04 -0000 @@ -133,19 +134,19 @@ { struct inode *ip; struct timespec ts; - int mnt_locked; =20 ip =3D VTOI(vp); - mnt_locked =3D 0; if ((vp->v_mount->mnt_flag & MNT_RDONLY) !=3D 0) { VI_LOCK(vp); goto out; } MNT_ILOCK(vp->v_mount); /* For reading of mnt_kern_flags. */ - mnt_locked =3D 1; VI_LOCK(vp); - if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0) - goto out_unl; + if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0) { + MNT_IUNLOCK(vp->v_mount); + VI_UNLOCK(vp); + return; + } =20 if ((vp->v_type =3D=3D VBLK || vp->v_type =3D=3D VCHR) && !DOINGSOFTDEP(v= p)) ip->i_flag |=3D IN_LAZYMOD; @@ -155,6 +156,7 @@ ip->i_flag |=3D IN_MODIFIED; else if (ip->i_flag & IN_ACCESS) ip->i_flag |=3D IN_LAZYACCESS; + MNT_IUNLOCK(vp->v_mount); vfs_timestamp(&ts); if (ip->i_flag & IN_ACCESS) { DIP_SET(ip, i_atime, ts.tv_sec); @@ -172,10 +174,7 @@ =20 out: ip->i_flag &=3D ~(IN_ACCESS | IN_CHANGE | IN_UPDATE); - out_unl: VI_UNLOCK(vp); - if (mnt_locked) - MNT_IUNLOCK(vp->v_mount); } =20 /* --J4XPiPrVK1ev6Sgr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFfoIWC3+MBN1Mb4gRAmA8AKCrbt+mT1HCNj3VnFFQVu+fb2JzZQCcCr0L n4DVdlGDbEkZAwaaBZhEFo8= =7yaQ -----END PGP SIGNATURE----- --J4XPiPrVK1ev6Sgr-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 12:49:47 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2126016A709; Tue, 12 Dec 2006 12:49:47 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E06FD43CC5; Tue, 12 Dec 2006 12:48:23 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 1373B5A3EFF; Tue, 12 Dec 2006 23:49:45 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 06F1727408; Tue, 12 Dec 2006 23:49:42 +1100 (EST) Date: Tue, 12 Dec 2006 23:49:42 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Kostik Belousov In-Reply-To: <20061212101903.GF311@deviant.kiev.zoral.com.ua> Message-ID: <20061212220705.F57430@delplex.bde.org> References: <456950AF.3090308@sh.cvut.cz> <20061127092146.GA69556@deviant.kiev.zoral.com.ua> <457E6C06.1020405@FreeBSD.org> <20061212101903.GF311@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 12 Dec 2006 13:11:19 +0000 Cc: V??clav Haisman , freebsd-stable@FreeBSD.org, Suleiman Souhlal , freebsd-current@FreeBSD.org, bde@FreeBSD.org, tegge@FreeBSD.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 12:49:47 -0000 On Tue, 12 Dec 2006, Kostik Belousov wrote: > On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: >> Is the mount lock really required, if all we're doing is a single read of a >> single word (mnt_kern_flags) (v_mount should be read-only for the whole >> lifetime of the vnode, I believe)? After all, reads of a single word are >> atomic on all our supported architectures. >> The only situation I see where there MIGHT be problems are forced unmounts, >> but I think there are bigger issues with those. >> Sorry for noticing this email only now. > > The problem is real with snapshotting. Ignoring > MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of > mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > inactivation time. This was the big trouble with nfsd and snapshots. As > such, I think that precise value of mmnt_kern_flag is critical there, > and mount interlock is needed. Locking for just read is almost always bogus, but here (as in most cases) there is also a write based on the contents of the flag, and the lock is held across the write. > Practically speaking, I agree with claim that reading of m_k_f is > surrounded by enough locked operations that would make sure that > the read value is not stale. But there is no such guarantee on > future/non-i386 arches, isn't it ? I think not-very-staleness is implied by acquire/release semantics which are part of the API for most atomic operations. This behaviour doesn't seem to be documented for mutexes, but I don't see how mutexes could work without it (they have to synchronize all memory accesses, not just the memory accessed by the lock). > As a side note, mount interlock scope could be reduced there. > > Index: ufs/ufs/ufs_vnops.c > =================================================================== > RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v > retrieving revision 1.283 > diff -u -r1.283 ufs_vnops.c > --- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 -0000 1.283 > +++ ufs/ufs/ufs_vnops.c 12 Dec 2006 10:18:04 -0000 > @@ -133,19 +134,19 @@ > { > struct inode *ip; > struct timespec ts; > - int mnt_locked; > > ip = VTOI(vp); > - mnt_locked = 0; > if ((vp->v_mount->mnt_flag & MNT_RDONLY) != 0) { > VI_LOCK(vp); > goto out; > } > MNT_ILOCK(vp->v_mount); /* For reading of mnt_kern_flags. */ > - mnt_locked = 1; > VI_LOCK(vp); > - if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) == 0) > - goto out_unl; > + if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) == 0) { > + MNT_IUNLOCK(vp->v_mount); > + VI_UNLOCK(vp); > + return; > + } The version that depends on not-very-staleness would test the flags without acquiring the lock(s) and return immediately in the usual case where none of the flags are set. It would have to acquire the locks and repeat the test to make changes (and the test is already repeated one flag at a time). I think this would be correct enough, but still inefficient and/or even messier. The current organization is usually: acquire vnode interlock in caller release vnode interlock in caller to avoid messes here (inefficient) call acquire mount interlock acquire vnode interlock test the flags; goto cleanup code if none set (usual case) do the work release vnode interlock release mount interlock return acquire vnode interlock (if needed) release vnode interlock (if needed) and it might become: acquire vnode interlock in caller call test the flags; return if none set (usual case) release vnode interlock // check that callers are aware of this acquire mount interlock acquire vnode interlock do the work // Assume no LOR problem for release, as below. // Otherwise need another relese+acquire of vnode interlock. release mount interlock return release vnode interlock > > if ((vp->v_type == VBLK || vp->v_type == VCHR) && !DOINGSOFTDEP(vp)) > ip->i_flag |= IN_LAZYMOD; > @@ -155,6 +156,7 @@ > ip->i_flag |= IN_MODIFIED; > else if (ip->i_flag & IN_ACCESS) > ip->i_flag |= IN_LAZYACCESS; > + MNT_IUNLOCK(vp->v_mount); > vfs_timestamp(&ts); > if (ip->i_flag & IN_ACCESS) { > DIP_SET(ip, i_atime, ts.tv_sec); Is there no LOR problem for release? As I understand it, MNT_ILOCK() is only protecting IN_ACCESS being converted to IN_MODIFED, so after this conversion is done the lock is not needed. Is this correct? > @@ -172,10 +174,7 @@ > > out: > ip->i_flag &= ~(IN_ACCESS | IN_CHANGE | IN_UPDATE); > - out_unl: > VI_UNLOCK(vp); > - if (mnt_locked) > - MNT_IUNLOCK(vp->v_mount); > } > > /* > BTW, vfs.lookup_shared defaults to 0 and decides shared access for all operations including read, so I wonder if there are [m]any bugs preventing shared accesses being the default for the most important cases where they can be (lookup and reads). (As you know, not acquiring the vnode interlock in old versions of the above was one, and since vfs.lookup_shared is global and not all file systems have the fix, it still is one.) Bruce From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 13:29:45 2006 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89C0D16A52F for ; Tue, 12 Dec 2006 13:29:45 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41A2C43CAF for ; Tue, 12 Dec 2006 13:27:45 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1Gu7gY-0001Uk-ED; Tue, 12 Dec 2006 15:28:42 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gu7gU-00010f-W7; Tue, 12 Dec 2006 15:28:39 +0200 To: "Bjoern A. Zeeb" From: Ian FREISLICH In-Reply-To: Message from "Bjoern A. Zeeb" of "Tue, 12 Dec 2006 09:38:12 GMT." <20061212093736.I91892@maildrop.int.zabbadoz.net> X-Attribution: BOFH Date: Tue, 12 Dec 2006 15:28:38 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2316/Tue Dec 12 00:50:59 2006) Cc: FreeBSD current mailing list Subject: Re: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 13:29:46 -0000 "Bjoern A. Zeeb" wrote: > On Tue, 12 Dec 2006, Ian FREISLICH wrote: > > > Does anyone know how to get this working? > > > > none6@pci1:9:0: class=0x070002 card=0x40371409 chip=0x71681409 rev=0x01 hdr =0x00 > > vendor = 'Timedia Technology Co Ltd' > > device = 'SUN 1889 / SUN 1699 PCI / ISA Asynchronous UART Signal Chips Solution' > > class = simple comms > > man 4 puc should do it. Thanks, for some reason I couldn't remember that. I now get: puc0: port 0xc800-0xc81f irq 21 at device 9.0 on pci1 puc0: [FAST] But no more sio devices. Am I still being dumb? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 13:38:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 305F816A4A7 for ; Tue, 12 Dec 2006 13:38:03 +0000 (UTC) (envelope-from michel@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 120CF43CA4 for ; Tue, 12 Dec 2006 13:36:25 +0000 (GMT) (envelope-from michel@lpthe.jussieu.fr) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.13.7/jtpda-5.4) with ESMTP id kBCDbY5f067466 for ; Tue, 12 Dec 2006 14:37:34 +0100 (CET) X-Ids: 164 Received: by parthe.lpthe.jussieu.fr (Postfix, from userid 99) id 17CB3A02C7; Tue, 12 Dec 2006 14:37:33 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on parthe.lpthe.jussieu.fr X-Spam-Level: X-Spam-Status: No, score=-100.0 required=10.0 tests=USER_IN_WHITELIST autolearn=failed version=3.1.7 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id C09CAA0251 for ; Tue, 12 Dec 2006 14:37:30 +0100 (CET) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id B4E4868; Tue, 12 Dec 2006 14:37:30 +0100 (CET) Date: Tue, 12 Dec 2006 14:37:30 +0100 From: Michel Talon To: freebsd-current@freebsd.org Message-ID: <20061212133730.GA18794@lpthe.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.164]); Tue, 12 Dec 2006 14:37:34 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.5/2316/Mon Dec 11 23:50:59 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 457EB09E.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Mailman-Approved-At: Tue, 12 Dec 2006 13:44:36 +0000 Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 13:38:03 -0000 Andre Guibert de Bruet wrote: > I have been using the msk driver without any problems on an Intel > SE7520BD2 server board. We have a few of these at work, and it's nice > to see that we will finally be able to use this second NIC on these > boards! > > At this point, are there plans to MFC the e1000phy changes and the > msk driver? > > Thanks for all your hard work! May i join you hoping that the msk driver is soon MFCed to FreeBSD-6! I have a very nice laptop, a Sony Vaio C1 with Core 2 Duo, unfortunately it is afflicted with the Yukon 2 network chip, plus un unsupported Intel wifi card, and *no* pcmcia slot. Hence it has exactly zero network connectivity in FreeBSD, to be compared to everything fully working with Ubuntu Edgy out of the box. Thank you again for your work. -- Michel TALON From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 13:54:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD3AA16A51C; Tue, 12 Dec 2006 13:54:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDDE743DDA; Tue, 12 Dec 2006 13:51:50 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBCDqsoY000344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2006 15:52:54 +0200 (EET) (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.13.8/8.13.8) with ESMTP id kBCDqrKb019225; Tue, 12 Dec 2006 15:52:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBCDqplF019224; Tue, 12 Dec 2006 15:52:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Dec 2006 15:52:51 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20061212135251.GJ311@deviant.kiev.zoral.com.ua> References: <456950AF.3090308@sh.cvut.cz> <20061127092146.GA69556@deviant.kiev.zoral.com.ua> <457E6C06.1020405@FreeBSD.org> <20061212101903.GF311@deviant.kiev.zoral.com.ua> <20061212220705.F57430@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v2Uk6McLiE8OV1El" Content-Disposition: inline In-Reply-To: <20061212220705.F57430@delplex.bde.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua X-Mailman-Approved-At: Tue, 12 Dec 2006 13:58:43 +0000 Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, Suleiman Souhlal , V??clav Haisman , bde@freebsd.org, tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 13:54:01 -0000 --v2Uk6McLiE8OV1El Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 12, 2006 at 11:49:42PM +1100, Bruce Evans wrote: > On Tue, 12 Dec 2006, Kostik Belousov wrote: >=20 > >On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: >=20 > >>Is the mount lock really required, if all we're doing is a single read = of=20 > >>a > >>single word (mnt_kern_flags) (v_mount should be read-only for the whole > >>lifetime of the vnode, I believe)? After all, reads of a single word are > >>atomic on all our supported architectures. > >>The only situation I see where there MIGHT be problems are forced=20 > >>unmounts, > >>but I think there are bigger issues with those. > >>Sorry for noticing this email only now. > > > >The problem is real with snapshotting. Ignoring > >MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of > >mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > >inactivation time. This was the big trouble with nfsd and snapshots. As > >such, I think that precise value of mmnt_kern_flag is critical there, > >and mount interlock is needed. >=20 > Locking for just read is almost always bogus, but here (as in most > cases) there is also a write based on the contents of the flag, and > the lock is held across the write. >=20 > >Practically speaking, I agree with claim that reading of m_k_f is > >surrounded by enough locked operations that would make sure that > >the read value is not stale. But there is no such guarantee on > >future/non-i386 arches, isn't it ? >=20 > I think not-very-staleness is implied by acquire/release semantics > which are part of the API for most atomic operations. This behaviour > doesn't seem to be documented for mutexes, but I don't see how mutexes > could work without it (they have to synchronize all memory accesses, > not just the memory accessed by the lock). >=20 > >As a side note, mount interlock scope could be reduced there. > > > >Index: ufs/ufs/ufs_vnops.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 > >RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v > >retrieving revision 1.283 > >diff -u -r1.283 ufs_vnops.c > >--- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 -0000 1.283 > >+++ ufs/ufs/ufs_vnops.c 12 Dec 2006 10:18:04 -0000 > >@@ -133,19 +134,19 @@ > >{ > > struct inode *ip; > > struct timespec ts; > >- int mnt_locked; > > > > ip =3D VTOI(vp); > >- mnt_locked =3D 0; > > if ((vp->v_mount->mnt_flag & MNT_RDONLY) !=3D 0) { > > VI_LOCK(vp); > > goto out; > > } > > MNT_ILOCK(vp->v_mount); /* For reading of mnt_kern_flags. */ > >- mnt_locked =3D 1; > > VI_LOCK(vp); > >- if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0) > >- goto out_unl; > >+ if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0) { > >+ MNT_IUNLOCK(vp->v_mount); > >+ VI_UNLOCK(vp); > >+ return; > >+ } >=20 > The version that depends on not-very-staleness would test the flags > without acquiring the lock(s) and return immediately in the usual case > where none of the flags are set. It would have to acquire the locks > and repeat the test to make changes (and the test is already repeated > one flag at a time). I think this would be correct enough, but still > inefficient and/or even messier. The current organization is usually: >=20 > acquire vnode interlock in caller > release vnode interlock in caller to avoid messes here (inefficient) > call > acquire mount interlock > acquire vnode interlock > test the flags; goto cleanup code if none set (usual case) > do the work > release vnode interlock > release mount interlock > return > acquire vnode interlock (if needed) > release vnode interlock (if needed) >=20 > and it might become: >=20 > acquire vnode interlock in caller > call > test the flags; return if none set (usual case) > release vnode interlock // check that callers are aware of=20 > this > acquire mount interlock > acquire vnode interlock > do the work > // Assume no LOR problem for release, as below. > // Otherwise need another relese+acquire of vnode interlock. > release mount interlock > return > release vnode interlock >=20 > > > > if ((vp->v_type =3D=3D VBLK || vp->v_type =3D=3D VCHR) && !DOINGSOFTDEP= (vp)) > > ip->i_flag |=3D IN_LAZYMOD; > >@@ -155,6 +156,7 @@ > > ip->i_flag |=3D IN_MODIFIED; > > else if (ip->i_flag & IN_ACCESS) > > ip->i_flag |=3D IN_LAZYACCESS; > >+ MNT_IUNLOCK(vp->v_mount); > > vfs_timestamp(&ts); > > if (ip->i_flag & IN_ACCESS) { > > DIP_SET(ip, i_atime, ts.tv_sec); >=20 > Is there no LOR problem for release? AFAIK, no. Release is guaranteed to success without blocking. >=20 > As I understand it, MNT_ILOCK() is only protecting IN_ACCESS being > converted to IN_MODIFED, so after this conversion is done the lock > is not needed. Is this correct? The code shall set IN_MODIFIED flag only if MNTK_SUSPEND and MNTK_SUSPENDED are clean. The vfs_write_suspend() that set MNTK_SUSPEND, does VFS_SYNC() after setting the flag. Since VFS_SYNC() tries to interlock the vnode (to test the flags), and then locks the vnode for ffs_syncvnode() call, the loop in ffs_sync() cannot finish before the ufs_itimes released vnode interlock. The MNTK_SUSPENDED is set after the loop. Hmm, may be, since vnode must be interlocked by ffs_sync() after MNTK_SUSPENDED set, and before MNTK_SUSPEND, mount interlock is not needed in ufs_itimes. Tor ? >=20 > >@@ -172,10 +174,7 @@ > > > > out: > > ip->i_flag &=3D ~(IN_ACCESS | IN_CHANGE | IN_UPDATE); > >- out_unl: > > VI_UNLOCK(vp); > >- if (mnt_locked) > >- MNT_IUNLOCK(vp->v_mount); > >} > > > >/* > > >=20 > BTW, vfs.lookup_shared defaults to 0 and decides shared access for all > operations including read, so I wonder if there are [m]any bugs > preventing shared accesses being the default for the most important > cases where they can be (lookup and reads). (As you know, not acquiring > the vnode interlock in old versions of the above was one, and since > vfs.lookup_shared is global and not all file systems have the fix, it > still is one.) Kris Kennaway said that lookup_shared caused deadlocks ? --v2Uk6McLiE8OV1El Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFfrQyC3+MBN1Mb4gRAlPCAJsHQNE3GIdPbTSmxyO75sjugSRqRQCeLkPr TwT9hV93Txg6r3IQD4gMlb8= =NzDM -----END PGP SIGNATURE----- --v2Uk6McLiE8OV1El-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 14:48:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF8AD16A4D4 for ; Tue, 12 Dec 2006 14:48:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55DEE43E14 for ; Tue, 12 Dec 2006 14:42:16 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1520369uge for ; Tue, 12 Dec 2006 06:43:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YHfyy72p0PHk3dAKk/q9h82KsDX5qzSyDQ6qDYpyIQuSyWFg5kwt2S5FHj+7YzcdE++G3ISuUELe/aLpZKi5/PulW0BlqTXkblnL5mfD4/jaj3j5jlDP57JT1qN3/CVexMVeH6CqUew/NMbGJiULw6LYBp4rfjJdu9Ipg680KlI= Received: by 10.82.138.6 with SMTP id l6mr728675bud.1165934608642; Tue, 12 Dec 2006 06:43:28 -0800 (PST) Received: by 10.82.178.4 with HTTP; Tue, 12 Dec 2006 06:43:28 -0800 (PST) Message-ID: <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> Date: Tue, 12 Dec 2006 15:43:28 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Kostik Belousov" In-Reply-To: <20061212101903.GF311@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <20061127092146.GA69556@deviant.kiev.zoral.com.ua> <457E6C06.1020405@FreeBSD.org> <20061212101903.GF311@deviant.kiev.zoral.com.ua> X-Google-Sender-Auth: e347fe8c79b25c11 X-Mailman-Approved-At: Tue, 12 Dec 2006 15:06:40 +0000 Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, Suleiman Souhlal , V.Haisman@sh.cvut.cz, bde@freebsd.org, tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 14:48:36 -0000 2006/12/12, Kostik Belousov : > On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > > Kostik Belousov wrote: > > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > > > > > >>Hi, > > >>the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6.1 > > >>with relatively recent kernel, from last week or so. > > >> > > >>-- > > >>VH > > > > > > > > >>+lock order reversal: > > >>+ 1st 0xc537f300 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547 > > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > > >>+KDB: stack backtrace: > > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at > > >>kdb_backtrace+0x2f > > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > > >>witness_checkorder+0x5fe > > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > > >>_mtx_lock_flags+0x32 > > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at > > >>ufs_itimes+0x6c > > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > > >>ufs_getattr+0x20 > > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > > >>VOP_GETATTR_APV+0x3a > > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at > > >>VOP_WRITE_APV+0x148 > > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at vn_write+0x201 > > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > > >>dofilewrite+0x84 > > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 > > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = > > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > > > > > > > > >Thank you for the report. The LOR is caused by my commit into > > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > > > > Is the mount lock really required, if all we're doing is a single read of a > > single word (mnt_kern_flags) (v_mount should be read-only for the whole > > lifetime of the vnode, I believe)? After all, reads of a single word are > > atomic on all our supported architectures. > > The only situation I see where there MIGHT be problems are forced unmounts, > > but I think there are bigger issues with those. > > Sorry for noticing this email only now. > > The problem is real with snapshotting. Ignoring > MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of > mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > inactivation time. This was the big trouble with nfsd and snapshots. As > such, I think that precise value of mmnt_kern_flag is critical there, > and mount interlock is needed. This can be avoided using a memory barrier when setting flags. Even if memory barriers usage is not encouraged, some critical code should really use them replacing a mutex semantic (if that worths it). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 15:13:02 2006 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0439216A416 for ; Tue, 12 Dec 2006 15:13:02 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E325A43CE9 for ; Tue, 12 Dec 2006 15:11:22 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBCFCccc039895; Tue, 12 Dec 2006 10:12:38 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kBCFCbPm028888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2006 10:12:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200612121512.kBCFCbPm028888@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Dec 2006 10:12:18 -0500 To: Ian FREISLICH From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Status: Clean Cc: FreeBSD current mailing list Subject: Re: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 15:13:02 -0000 At 08:28 AM 12/12/2006, Ian FREISLICH wrote: >"Bjoern A. Zeeb" wrote: > > On Tue, 12 Dec 2006, Ian FREISLICH wrote: > > > > > Does anyone know how to get this working? > > > > > > none6@pci1:9:0: class=0x070002 card=0x40371409 chip=0x71681409 > rev=0x01 hdr >=0x00 > > > vendor = 'Timedia Technology Co Ltd' > > > device = 'SUN 1889 / SUN 1699 PCI / ISA Asynchronous UART > Signal Chips > Solution' > > > class = simple comms > > > > man 4 puc should do it. > >Thanks, for some reason I couldn't remember that. I now get: > >puc0: port 0xc800-0xc81f irq 21 >at device 9.0 on pci1 >puc0: [FAST] > >But no more sio devices. Am I still being dumb? If its current, would you not see it as uart devices ? Also, there used to be an issue of loading puc as a kld. Try statically compiling it in the kernel along with device uart (not sio) and see if /dev/cuau# devices come up. ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 15:18:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8585816A52E; Tue, 12 Dec 2006 15:18:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B686943D82; Tue, 12 Dec 2006 15:16:59 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCFIMNg019048; Tue, 12 Dec 2006 10:18:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCFIMNB013017; Tue, 12 Dec 2006 10:18:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0EDAD73034; Tue, 12 Dec 2006 10:18:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212151822.0EDAD73034@freebsd-current.sentex.ca> Date: Tue, 12 Dec 2006 10:18:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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, 12 Dec 2006 15:18:55 -0000 TB --- 2006-12-12 13:10:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 13:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-12 13:10:00 - cleaning the object tree TB --- 2006-12-12 13:11:43 - checking out the source tree TB --- 2006-12-12 13:11:43 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-12 13:11:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 13:27:38 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 13:27:38 - cd /src TB --- 2006-12-12 13:27:38 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 13:27:40 UTC 2006 >>> 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 Dec 12 15:06:23 UTC 2006 TB --- 2006-12-12 15:06:23 - generating LINT kernel config TB --- 2006-12-12 15:06:23 - cd /src/sys/amd64/conf TB --- 2006-12-12 15:06:23 - /usr/bin/make -B LINT TB --- 2006-12-12 15:06:23 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-12 15:06:23 - cd /src TB --- 2006-12-12 15:06:23 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 12 15:06:23 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_output.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/raw_ip.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_usrreq.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_pcb.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctputil.c /src/sys/netinet/sctputil.c: In function `sctp_print_address': /src/sys/netinet/sctputil.c:3611: warning: passing arg 1 of `ip6_sprintf' from incompatible pointer type /src/sys/netinet/sctputil.c:3611: error: too few arguments to function `ip6_sprintf' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 15:18:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 15:18:21 - ERROR: failed to build lint kernel TB --- 2006-12-12 15:18:21 - tinderbox aborted TB --- 0.74 user 3.55 system 7700.60 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 15:56:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B03D816A561 for ; Tue, 12 Dec 2006 15:56:43 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a6.dreamhost.com (sd-green-bigip-83.dreamhost.com [208.97.132.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63E5243D95 for ; Tue, 12 Dec 2006 15:53:10 +0000 (GMT) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.203.16.34]) by spunkymail-a6.dreamhost.com (Postfix) with ESMTP id 3DA40109F35; Tue, 12 Dec 2006 07:54:17 -0800 (PST) Date: Tue, 12 Dec 2006 13:41:52 -0200 From: Ricardo Nabinger Sanchez To: Randall Stewart Message-Id: <20061212134152.8759b56b.rnsanchez@wait4.org> In-Reply-To: <457EA7E3.2010302@cisco.com> References: <457EA7E3.2010302@cisco.com> Organization: SYS_WAIT4 X-Mailer: Sylpheed version 2.3.0beta6 (GTK+ 2.10.6; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: curious results X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 15:56:44 -0000 On Tue, 12 Dec 2006 08:00:19 -0500 Randall Stewart wrote: > If anyone has heard of anything like this I would appreciate > some pointers.. it could be something SCTP is doing... at > least the timer one.. I'm not sure if it was here (@current) or another list in the hub, but someone reported such behavior: frozen machine until touched. Perhaps in one of the long em(4) threads, but sorry, I don't remember precisely. -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 16:04:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3F0A16A415; Tue, 12 Dec 2006 16:04:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8013943D6A; Tue, 12 Dec 2006 16:02:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBCG3GlW050733; Tue, 12 Dec 2006 11:03:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCG3GOe072103; Tue, 12 Dec 2006 11:03:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D7FC973034; Tue, 12 Dec 2006 11:03:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212160315.D7FC973034@freebsd-current.sentex.ca> Date: Tue, 12 Dec 2006 11:03:15 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner4 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 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, 12 Dec 2006 16:04:19 -0000 TB --- 2006-12-12 14:40:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 14:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-12 14:40:01 - cleaning the object tree TB --- 2006-12-12 14:40:36 - checking out the source tree TB --- 2006-12-12 14:40:36 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-12 14:40:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 14:53:55 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 14:53:55 - cd /src TB --- 2006-12-12 14:53:55 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 14:53:56 UTC 2006 >>> 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 Dec 12 15:52:43 UTC 2006 TB --- 2006-12-12 15:52:43 - generating LINT kernel config TB --- 2006-12-12 15:52:43 - cd /src/sys/i386/conf TB --- 2006-12-12 15:52:43 - /usr/bin/make -B LINT TB --- 2006-12-12 15:52:43 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-12 15:52:43 - cd /src TB --- 2006-12-12 15:52:43 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 12 15:52:43 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_output.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/raw_ip.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_usrreq.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_pcb.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctputil.c /src/sys/netinet/sctputil.c: In function `sctp_print_address': /src/sys/netinet/sctputil.c:3611: warning: passing arg 1 of `ip6_sprintf' from incompatible pointer type /src/sys/netinet/sctputil.c:3611: error: too few arguments to function `ip6_sprintf' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 16:03:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 16:03:15 - ERROR: failed to build lint kernel TB --- 2006-12-12 16:03:15 - tinderbox aborted TB --- 0.83 user 2.66 system 4994.07 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 16:31:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E589016A47B; Tue, 12 Dec 2006 16:31:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFB4743CA2; Tue, 12 Dec 2006 16:29:37 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBCGV0Od056552; Tue, 12 Dec 2006 11:31:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCGV0DC062470; Tue, 12 Dec 2006 11:31:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D47DE73034; Tue, 12 Dec 2006 11:30:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212163059.D47DE73034@freebsd-current.sentex.ca> Date: Tue, 12 Dec 2006 11:30:59 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 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, 12 Dec 2006 16:31:02 -0000 TB --- 2006-12-12 15:18:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 15:18:22 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-12 15:18:22 - cleaning the object tree TB --- 2006-12-12 15:19:58 - checking out the source tree TB --- 2006-12-12 15:19:58 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-12 15:19:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 15:29:14 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 15:29:14 - cd /src TB --- 2006-12-12 15:29:14 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 15:29:15 UTC 2006 >>> 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 Dec 12 16:22:22 UTC 2006 TB --- 2006-12-12 16:22:22 - generating LINT kernel config TB --- 2006-12-12 16:22:22 - cd /src/sys/pc98/conf TB --- 2006-12-12 16:22:22 - /usr/bin/make -B LINT TB --- 2006-12-12 16:22:22 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-12 16:22:22 - cd /src TB --- 2006-12-12 16:22:22 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 12 16:22:22 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_output.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/raw_ip.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_usrreq.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_pcb.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctputil.c /src/sys/netinet/sctputil.c: In function `sctp_print_address': /src/sys/netinet/sctputil.c:3611: warning: passing arg 1 of `ip6_sprintf' from incompatible pointer type /src/sys/netinet/sctputil.c:3611: error: too few arguments to function `ip6_sprintf' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 16:30:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 16:30:59 - ERROR: failed to build lint kernel TB --- 2006-12-12 16:30:59 - tinderbox aborted TB --- 0.74 user 2.70 system 4357.48 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 17:37:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E64416A407 for ; Tue, 12 Dec 2006 17:37:33 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69C4643F0A for ; Tue, 12 Dec 2006 17:32:59 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so385486ana for ; Tue, 12 Dec 2006 09:34:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U7GGRxgNCWxXJEyeDr7HcNVcuDXScwmls8Af5693YZPandQNkDQrN9b/MEK8xU2LXn02T0Aw0IIHta8lqe9dj0VX1Mp7AVJrOgPc50p/BNOnMEP+ukr3cgIAqb1VU5QsB6wLouTpLRii+/2NiJU2CwvzXSSnonrIaqi+9J0Luk0= Received: by 10.100.168.13 with SMTP id q13mr949356ane.1165944853700; Tue, 12 Dec 2006 09:34:13 -0800 (PST) Received: by 10.100.136.16 with HTTP; Tue, 12 Dec 2006 09:34:13 -0800 (PST) Message-ID: <6eb82e0612120934h2920ccddkaeb5b0e0c038cefb@mail.gmail.com> Date: Wed, 13 Dec 2006 01:34:13 +0800 From: "Rong-en Fan" To: "Adam McDougall" In-Reply-To: <20061210002923.GO81923@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061210002923.GO81923@egr.msu.edu> Cc: freebsd-current@freebsd.org Subject: Re: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 17:37:33 -0000 On 12/10/06, Adam McDougall wrote: > src/sys/i386/cpufreq/est.c has many Pentium M cpus but nothing > from the Intel Core and Core 2 families that I can see. I tried > looking up the values myself, but could not find them in: > http://www.intel.com/design/mobile/datashts/314078.htm > > It seems that even the latest version of the Linux kernel does not > list values for at least Yonah (Core 2). Is it a big mystery, or is > this data actually available somewhere? I have a Core 2 Duo > T7600 in my laptop and est won't touch my cpu because it doesn't > recognize it. I did get it to use some other form of speed control > by putting hint.acpi_perf.0.disabled="1" in /boot/loader.conf according > to another post. On my ThinkPad X60 with T5600. est and p4tcc work smoothly. cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 dev.cpu.0.freq_levels: 1833/31000 1603/27125 1374/23250 1333/20000 1166/17500 1000/13000 875/11375 750/9750 625/8125 500/6500 375/4875 250/3250 125/1625 dev.est.0.freq_settings: 1833/31000 1333/20000 1000/13000 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 > Another thing I wish could work is the Enhanced cpu Sleep States; > this Dell Latitude D820 laptop only sees C1 although the document > above indicates it should probably support 4 unique states. Is > there a way I can debug and/or fix this? I can post dumps of the > acpi stuff and/or verbose boot logs if it would be helpful. Well, I have C1 only, too. For the record, I'm running 200611 current amd64 snapshot. Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 17:42:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94FFA16A412; Tue, 12 Dec 2006 17:42:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D51243F31; Tue, 12 Dec 2006 17:37:24 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBCHcjZW077772; Tue, 12 Dec 2006 12:38:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCHcjo5090093; Tue, 12 Dec 2006 12:38:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E84E373034; Tue, 12 Dec 2006 12:38:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212173844.E84E373034@freebsd-current.sentex.ca> Date: Tue, 12 Dec 2006 12:38:44 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 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, 12 Dec 2006 17:42:31 -0000 TB --- 2006-12-12 16:03:15 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 16:03:15 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-12 16:03:16 - cleaning the object tree TB --- 2006-12-12 16:03:46 - checking out the source tree TB --- 2006-12-12 16:03:46 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-12 16:03:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 16:11:43 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 16:11:43 - cd /src TB --- 2006-12-12 16:11:43 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 16:11:44 UTC 2006 >>> 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 Dec 12 17:26:13 UTC 2006 TB --- 2006-12-12 17:26:13 - generating LINT kernel config TB --- 2006-12-12 17:26:13 - cd /src/sys/ia64/conf TB --- 2006-12-12 17:26:13 - /usr/bin/make -B LINT TB --- 2006-12-12 17:26:13 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-12 17:26:13 - cd /src TB --- 2006-12-12 17:26:13 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 12 17:26:14 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netinet/ip_output.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netinet/raw_ip.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netinet/sctp_usrreq.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netinet/sctp_pcb.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netinet/sctputil.c /src/sys/netinet/sctputil.c: In function `sctp_print_address': /src/sys/netinet/sctputil.c:3611: warning: passing arg 1 of `ip6_sprintf' from incompatible pointer type /src/sys/netinet/sctputil.c:3611: error: too few arguments to function `ip6_sprintf' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 17:38:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 17:38:44 - ERROR: failed to build lint kernel TB --- 2006-12-12 17:38:44 - tinderbox aborted TB --- 0.75 user 2.47 system 5728.68 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 17:45:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80F1F16A503; Tue, 12 Dec 2006 17:45:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5417B43DEB; Tue, 12 Dec 2006 17:41:20 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBCHgh20079171; Tue, 12 Dec 2006 12:42:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCHghqb094613; Tue, 12 Dec 2006 12:42:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 235B173034; Tue, 12 Dec 2006 12:42:42 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212174243.235B173034@freebsd-current.sentex.ca> Date: Tue, 12 Dec 2006 12:42:42 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 17:45:46 -0000 TB --- 2006-12-12 16:30:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 16:30:59 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-12-12 16:30:59 - cleaning the object tree TB --- 2006-12-12 16:31:31 - checking out the source tree TB --- 2006-12-12 16:31:31 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-12-12 16:31:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 16:39:11 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 16:39:11 - cd /src TB --- 2006-12-12 16:39:11 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 16:39:12 UTC 2006 >>> 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 Dec 12 17:34:54 UTC 2006 TB --- 2006-12-12 17:34:54 - generating LINT kernel config TB --- 2006-12-12 17:34:54 - cd /src/sys/powerpc/conf TB --- 2006-12-12 17:34:54 - /usr/bin/make -B LINT TB --- 2006-12-12 17:34:54 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-12 17:34:54 - cd /src TB --- 2006-12-12 17:34:54 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 12 17:34:54 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -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 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/ip_output.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 -fformat-extensions -nostdinc -I- -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 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/raw_ip.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 -fformat-extensions -nostdinc -I- -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 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_usrreq.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 -fformat-extensions -nostdinc -I- -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 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_pcb.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 -fformat-extensions -nostdinc -I- -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 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctputil.c /src/sys/netinet/sctputil.c: In function `sctp_print_address': /src/sys/netinet/sctputil.c:3611: warning: passing arg 1 of `ip6_sprintf' from incompatible pointer type /src/sys/netinet/sctputil.c:3611: error: too few arguments to function `ip6_sprintf' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 17:42:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 17:42:42 - ERROR: failed to build lint kernel TB --- 2006-12-12 17:42:42 - tinderbox aborted TB --- 0.76 user 2.46 system 4303.01 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 17:58:38 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A52416A492; Tue, 12 Dec 2006 17:58:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id E033B43DE9; Tue, 12 Dec 2006 17:55:50 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id kBCHvC1L073432; Tue, 12 Dec 2006 09:57:12 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id kBCHvBNk073431; Tue, 12 Dec 2006 09:57:11 -0800 (PST) (envelope-from david) Date: Tue, 12 Dec 2006 09:57:11 -0800 From: David Wolfskill To: Robert Watson , current@freebsd.org Message-ID: <20061212175711.GX29001@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Robert Watson , current@freebsd.org References: <20061211110009.K62822@fledge.watson.org> <20061211191531.GP29001@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lQZUhpxrYmQgHmHV" Content-Disposition: inline In-Reply-To: <20061211191531.GP29001@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: CURRENT freezes on Laitude D520 (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 17:58:38 -0000 --lQZUhpxrYmQgHmHV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 11, 2006 at 11:15:31AM -0800, David Wolfskill wrote: > On Mon, Dec 11, 2006 at 11:00:27AM +0000, Robert Watson wrote: > > ... > > Sam has committed changes to if_wi in the last 24 hours that may fix th= is=20 > > problem with the default net.isr.direct setting. Could you try updatin= g to=20 > > these changes, removing net.isr.direct=3D0, and seeing what happens? >=20 > This appears to have helped so far: I just finished the "make > buildworld" & friends on my laptop (a Dell Inspiron 8200 with a mini-PCI > wireless NIC that the wi driver handles); presently running: >=20 > localhost(7.0-C)[1] uname -a > FreeBSD localhost 7.0-CURRENT FreeBSD 7.0-CURRENT #264: Mon Dec 11 09:47:= 47 PST 2006 root@localhost:/common/S4/obj/usr/src/sys/LAPTOP_30W i386 > localhost(7.0-C)[2]=20 >=20 > .... > The LOR in question no is no longer apparent; it was apparent in all > kernels from 29 Nov through 10 Dec. (I normally update & build daily.) >=20 > I'll plan on givinig it a more strenuous test tomorrow morning -- the > "make buildworld" (while using the wi0 NIC) test. :-} OK; today's CURRENT buildworld (& friends) completed successfully -- while I was using the wi0 NIC: g1-18(7.0-C)[1] uname -a FreeBSD g1-18.catwhisker.org. 7.0-CURRENT FreeBSD 7.0-CURRENT #265: Tue Dec= 12 09:12:51 PST 2006 root@g1-18.catwhisker.org.:/common/S4/obj/usr/src= /sys/LAPTOP_30W i386 g1-18(7.0-C)[2]=20 So -- no magic smoke leakage; no reports of LORs. Looks good. Thanks again, especially to Sam & Robert. Peace, david --=20 David H. Wolfskill david@catwhisker.org Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 19= 99. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --lQZUhpxrYmQgHmHV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkV+7XYACgkQmprOCmdXAD2eSgCbBEC3h/vzYJXrOlXTsANaZwVt jBEAnRPT7hME44EuQFs7ee1Ha/HaIw+S =aUph -----END PGP SIGNATURE----- --lQZUhpxrYmQgHmHV-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 18:56:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE07C16A412; Tue, 12 Dec 2006 18:56:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 682E843EAE; Tue, 12 Dec 2006 18:52:51 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCIsC0R051040; Tue, 12 Dec 2006 13:54:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCIsBiq074166; Tue, 12 Dec 2006 13:54:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D71B273034; Tue, 12 Dec 2006 13:54:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212185411.D71B273034@freebsd-current.sentex.ca> Date: Tue, 12 Dec 2006 13:54:11 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean 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, 12 Dec 2006 18:56:20 -0000 TB --- 2006-12-12 17:38:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 17:38:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-12 17:38:45 - cleaning the object tree TB --- 2006-12-12 17:39:13 - checking out the source tree TB --- 2006-12-12 17:39:13 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-12 17:39:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 17:51:11 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 17:51:11 - cd /src TB --- 2006-12-12 17:51:11 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 17:51:13 UTC 2006 >>> 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 Dec 12 18:44:41 UTC 2006 TB --- 2006-12-12 18:44:41 - generating LINT kernel config TB --- 2006-12-12 18:44:41 - cd /src/sys/sparc64/conf TB --- 2006-12-12 18:44:41 - /usr/bin/make -B LINT TB --- 2006-12-12 18:44:42 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-12 18:44:42 - cd /src TB --- 2006-12-12 18:44:42 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 12 18:44:42 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/ip_output.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/raw_ip.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/sctp_usrreq.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/sctp_pcb.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/sctputil.c /src/sys/netinet/sctputil.c: In function `sctp_print_address': /src/sys/netinet/sctputil.c:3611: warning: passing arg 1 of `ip6_sprintf' from incompatible pointer type /src/sys/netinet/sctputil.c:3611: error: too few arguments to function `ip6_sprintf' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 18:54:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 18:54:11 - ERROR: failed to build lint kernel TB --- 2006-12-12 18:54:11 - tinderbox aborted TB --- 0.66 user 2.35 system 4526.41 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 18:56:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7CB716A505; Tue, 12 Dec 2006 18:56:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ED0C43CAE; Tue, 12 Dec 2006 18:53:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBCIsRUG095817; Tue, 12 Dec 2006 13:54:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBCIsQXd074389; Tue, 12 Dec 2006 13:54:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E40BF73036; Tue, 12 Dec 2006 13:54:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061212185426.E40BF73036@freebsd-current.sentex.ca> Date: Tue, 12 Dec 2006 13:54:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean 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, 12 Dec 2006 18:56:41 -0000 TB --- 2006-12-12 17:42:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-12 17:42:43 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-12 17:42:43 - cleaning the object tree TB --- 2006-12-12 17:43:13 - checking out the source tree TB --- 2006-12-12 17:43:13 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-12 17:43:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-12 17:52:36 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-12 17:52:36 - cd /src TB --- 2006-12-12 17:52:36 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 12 17:52:37 UTC 2006 >>> 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 Dec 12 18:45:19 UTC 2006 TB --- 2006-12-12 18:45:19 - generating LINT kernel config TB --- 2006-12-12 18:45:19 - cd /src/sys/sun4v/conf TB --- 2006-12-12 18:45:19 - /usr/bin/make -B LINT TB --- 2006-12-12 18:45:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-12 18:45:19 - cd /src TB --- 2006-12-12 18:45:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 12 18:45:19 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/ip_output.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/raw_ip.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/sctp_usrreq.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/sctp_pcb.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/netinet/sctputil.c /src/sys/netinet/sctputil.c: In function `sctp_print_address': /src/sys/netinet/sctputil.c:3611: warning: passing arg 1 of `ip6_sprintf' from incompatible pointer type /src/sys/netinet/sctputil.c:3611: error: too few arguments to function `ip6_sprintf' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-12 18:54:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-12 18:54:26 - ERROR: failed to build lint kernel TB --- 2006-12-12 18:54:26 - tinderbox aborted TB --- 0.57 user 2.02 system 4303.77 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 20:23:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C590016A508 for ; Tue, 12 Dec 2006 20:23:37 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CE3D4406B for ; Tue, 12 Dec 2006 20:11:53 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so306881nfc for ; Tue, 12 Dec 2006 12:13:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mKK1+C1ubIm1an9RywrybX4uoXDVulrCz2zHBvf5ffHBHcuPum/4UxqJLhNw4eautZyjM3Jg1i+3PNH5B/5V8M8M75f8a8Fs4ChtVJTdhc2S8iz4i+rXOt5smzspIt8Ul/R46U0oyF0iXbNnEZ5RwaqHIkHEo4D5v16vCQ0wAy4= Received: by 10.82.126.5 with SMTP id y5mr815021buc.1165954388600; Tue, 12 Dec 2006 12:13:08 -0800 (PST) Received: by 10.82.178.4 with HTTP; Tue, 12 Dec 2006 12:13:08 -0800 (PST) Message-ID: <3bbf2fe10612121213s556dda8ds63b167a6f904131@mail.gmail.com> Date: Tue, 12 Dec 2006 21:13:08 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200612121412.13551.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> <457EF835.2020705@FreeBSD.org> <200612121412.13551.jhb@freebsd.org> X-Google-Sender-Auth: 4200d9c4388f4110 Cc: Kostik Belousov , Suleiman Souhlal , freebsd-current@freebsd.org, tegge@freebsd.org, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 20:23:38 -0000 2006/12/12, John Baldwin : > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > > Attilio Rao wrote: > > > 2006/12/12, Kostik Belousov : > > > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > > >> > Kostik Belousov wrote: > > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > > >> > > > > >> > >>Hi, > > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > > >> FreeBSD 6.1 > > >> > >>with relatively recent kernel, from last week or so. > > >> > >> > > >> > >>-- > > >> > >>VH > > >> > > > > >> > > > > >> > >>+lock order reversal: > > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > > >> /usr/src/sys/kern/kern_event.c:1547 > > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > > >> > >>+KDB: stack backtrace: > > >> > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at > > >> > >>kdb_backtrace+0x2f > > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > > >> > >>witness_checkorder+0x5fe > > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > > >> > >>_mtx_lock_flags+0x32 > > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at > > >> > >>ufs_itimes+0x6c > > >> > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > > >> > >>ufs_getattr+0x20 > > >> > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > > >> > >>VOP_GETATTR_APV+0x3a > > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at > > >> > >>VOP_WRITE_APV+0x148 > > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > > >> vn_write+0x201 > > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > > >> > >>dofilewrite+0x84 > > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 > > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = > > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > > >> > > > > >> > > > > >> > >Thank you for the report. The LOR is caused by my commit into > > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > > >> > > > >> > Is the mount lock really required, if all we're doing is a single > > >> read of a > > >> > single word (mnt_kern_flags) (v_mount should be read-only for the whole > > >> > lifetime of the vnode, I believe)? After all, reads of a single word > > >> are > > >> > atomic on all our supported architectures. > > >> > The only situation I see where there MIGHT be problems are forced > > >> unmounts, > > >> > but I think there are bigger issues with those. > > >> > Sorry for noticing this email only now. > > >> > > >> The problem is real with snapshotting. Ignoring > > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of > > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > > >> inactivation time. This was the big trouble with nfsd and snapshots. As > > >> such, I think that precise value of mmnt_kern_flag is critical there, > > >> and mount interlock is needed. > > > > > > > > > This can be avoided using a memory barrier when setting flags. > > > Even if memory barriers usage is not encouraged, some critical code > > > should really use them replacing a mutex semantic (if that worths it). > > > > Why is memory barrier usage not encouraged? As you said, they can be used to > reduce the number of atomic (LOCKed) operations, in some cases. > > > > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), mb() > (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers only > needed on SMP), and barrier() (GCC barrier (__asm __volatile (:::"memory")) > macros that I've personally found very useful. > > Admittedly, they are harder to use than atomic operations, but it might > still worth having something similar. > > Memory barriers just specify ordering, they don't ensure a cache flush so > another CPU reads up to date values. You can use memory barriers in > conjunction with atomic operations on a variable to ensure that you can > safely read other variables (which is what locks do). For example, in this > case IIUC, you have a race that is because there is shared state between two > fields, one in the mount structure, and one in the ufs i-node. Memory > barriers alone won't prevent you from operating on those flags > non-consistently. That is, you have two memory locations in play here, and > atomic ops only work on a single one. There isn't an atomic op to do "read > from memory location A, check flag B, and if it's true write C to memory > location D". Where would you put the membar in this case to ensure that the > action always results in consistent behavior? Ah no, I misunderstood the problem. I was thinking it was about setting the flag A into location B if C is not present. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 21:29:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BFEB16A416; Tue, 12 Dec 2006 21:29:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 605034405F; Tue, 12 Dec 2006 21:25:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBCLQTPc021705; Tue, 12 Dec 2006 16:26:34 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Tue, 12 Dec 2006 16:14:17 -0500 User-Agent: KMail/1.9.1 References: <456950AF.3090308@sh.cvut.cz> <200612121412.13551.jhb@freebsd.org> <3bbf2fe10612121213s556dda8ds63b167a6f904131@mail.gmail.com> In-Reply-To: <3bbf2fe10612121213s556dda8ds63b167a6f904131@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612121614.18502.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 12 Dec 2006 16:26:34 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2319/Tue Dec 12 15:09:22 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , Suleiman Souhlal , freebsd-current@freebsd.org, tegge@freebsd.org, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 21:29:46 -0000 On Tuesday 12 December 2006 15:13, Attilio Rao wrote: > 2006/12/12, John Baldwin : > > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > > > Attilio Rao wrote: > > > > 2006/12/12, Kostik Belousov : > > > > > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > > > >> > Kostik Belousov wrote: > > > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > > > >> > > > > > >> > >>Hi, > > > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > > > >> FreeBSD 6.1 > > > >> > >>with relatively recent kernel, from last week or so. > > > >> > >> > > > >> > >>-- > > > >> > >>VH > > > >> > > > > > >> > > > > > >> > >>+lock order reversal: > > > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > > > >> /usr/src/sys/kern/kern_event.c:1547 > > > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > > > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > > > >> > >>+KDB: stack backtrace: > > > >> > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at > > > >> > >>kdb_backtrace+0x2f > > > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > > > >> > >>witness_checkorder+0x5fe > > > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > > > >> > >>_mtx_lock_flags+0x32 > > > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at > > > >> > >>ufs_itimes+0x6c > > > >> > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > > > >> > >>ufs_getattr+0x20 > > > >> > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > > > >> > >>VOP_GETATTR_APV+0x3a > > > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > > > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > > > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at > > > >> > >>VOP_WRITE_APV+0x148 > > > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > > > >> vn_write+0x201 > > > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > > > >> > >>dofilewrite+0x84 > > > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 > > > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > > > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > > > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = > > > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > > > >> > > > > > >> > > > > > >> > >Thank you for the report. The LOR is caused by my commit into > > > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > > > >> > > > > >> > Is the mount lock really required, if all we're doing is a single > > > >> read of a > > > >> > single word (mnt_kern_flags) (v_mount should be read-only for the whole > > > >> > lifetime of the vnode, I believe)? After all, reads of a single word > > > >> are > > > >> > atomic on all our supported architectures. > > > >> > The only situation I see where there MIGHT be problems are forced > > > >> unmounts, > > > >> > but I think there are bigger issues with those. > > > >> > Sorry for noticing this email only now. > > > >> > > > >> The problem is real with snapshotting. Ignoring > > > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of > > > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > > > >> inactivation time. This was the big trouble with nfsd and snapshots. As > > > >> such, I think that precise value of mmnt_kern_flag is critical there, > > > >> and mount interlock is needed. > > > > > > > > > > > > This can be avoided using a memory barrier when setting flags. > > > > Even if memory barriers usage is not encouraged, some critical code > > > > should really use them replacing a mutex semantic (if that worths it). > > > > > > Why is memory barrier usage not encouraged? As you said, they can be used to > > reduce the number of atomic (LOCKed) operations, in some cases. > > > > > > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), mb() > > (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers only > > needed on SMP), and barrier() (GCC barrier (__asm __volatile (:::"memory")) > > macros that I've personally found very useful. > > > Admittedly, they are harder to use than atomic operations, but it might > > still worth having something similar. > > > > Memory barriers just specify ordering, they don't ensure a cache flush so > > another CPU reads up to date values. You can use memory barriers in > > conjunction with atomic operations on a variable to ensure that you can > > safely read other variables (which is what locks do). For example, in this > > case IIUC, you have a race that is because there is shared state between two > > fields, one in the mount structure, and one in the ufs i-node. Memory > > barriers alone won't prevent you from operating on those flags > > non-consistently. That is, you have two memory locations in play here, and > > atomic ops only work on a single one. There isn't an atomic op to do "read > > from memory location A, check flag B, and if it's true write C to memory > > location D". Where would you put the membar in this case to ensure that the > > action always results in consistent behavior? > > Ah no, I misunderstood the problem. > I was thinking it was about setting the flag A into location B if C is > not present. That's the same problem, setting a flag in one word if a flag is set (or not set) in another word. Either way though you are dealing with two different memory locations that need to be consistent with respect to one another. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 21:44:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EA8316A5F5 for ; Tue, 12 Dec 2006 21:44:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D4E4426A for ; Tue, 12 Dec 2006 21:33:44 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1619131uge for ; Tue, 12 Dec 2006 13:34:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=e9MwFzO8jKDnehEsccrRYgw9isvJgeOzLLJIxzTDsXbkRpnoSh/MSed6UIm3u4Ea30X77tDIOq6zGQwn6fhxxz+vBcb5ZrSgl2IEgUE7cUaLLUQYDJJG4XJPu0rvIId8GZZbkcnMFbsl8PXy9F8p7yBwVcf1mME9AQyU99lMd0Y= Received: by 10.82.139.17 with SMTP id m17mr7423bud.1165959294658; Tue, 12 Dec 2006 13:34:54 -0800 (PST) Received: by 10.82.178.4 with HTTP; Tue, 12 Dec 2006 13:34:54 -0800 (PST) Message-ID: <3bbf2fe10612121334n12459019sb657a226615fc4b6@mail.gmail.com> Date: Tue, 12 Dec 2006 22:34:54 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200612121614.18502.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <200612121412.13551.jhb@freebsd.org> <3bbf2fe10612121213s556dda8ds63b167a6f904131@mail.gmail.com> <200612121614.18502.jhb@freebsd.org> X-Google-Sender-Auth: 85f21f2e62619ff4 Cc: Kostik Belousov , Suleiman Souhlal , freebsd-current@freebsd.org, tegge@freebsd.org, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 21:44:42 -0000 2006/12/12, John Baldwin : > On Tuesday 12 December 2006 15:13, Attilio Rao wrote: > > 2006/12/12, John Baldwin : > > > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > > > > Attilio Rao wrote: > > > > > 2006/12/12, Kostik Belousov : > > > > > > > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > > > > >> > Kostik Belousov wrote: > > > > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > > > > >> > > > > > > >> > >>Hi, > > > > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > > > > >> FreeBSD 6.1 > > > > >> > >>with relatively recent kernel, from last week or so. > > > > >> > >> > > > > >> > >>-- > > > > >> > >>VH > > > > >> > > > > > > >> > > > > > > >> > >>+lock order reversal: > > > > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > > > > >> /usr/src/sys/kern/kern_event.c:1547 > > > > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > > > > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > > > > >> > >>+KDB: stack backtrace: > > > > >> > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) > at > > > > >> > >>kdb_backtrace+0x2f > > > > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > > > > >> > >>witness_checkorder+0x5fe > > > > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > > > > >> > >>_mtx_lock_flags+0x32 > > > > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at > > > > >> > >>ufs_itimes+0x6c > > > > >> > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > > > > >> > >>ufs_getattr+0x20 > > > > >> > > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > > > > >> > >>VOP_GETATTR_APV+0x3a > > > > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > > > > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > > > > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at > > > > >> > >>VOP_WRITE_APV+0x148 > > > > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > > > > >> vn_write+0x201 > > > > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > > > > >> > >>dofilewrite+0x84 > > > > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at > kern_writev+0x65 > > > > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > > > > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > > > > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = > > > > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > > > > >> > > > > > > >> > > > > > > >> > >Thank you for the report. The LOR is caused by my commit into > > > > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > > > > >> > > > > > >> > Is the mount lock really required, if all we're doing is a single > > > > >> read of a > > > > >> > single word (mnt_kern_flags) (v_mount should be read-only for the > whole > > > > >> > lifetime of the vnode, I believe)? After all, reads of a single > word > > > > >> are > > > > >> > atomic on all our supported architectures. > > > > >> > The only situation I see where there MIGHT be problems are forced > > > > >> unmounts, > > > > >> > but I think there are bigger issues with those. > > > > >> > Sorry for noticing this email only now. > > > > >> > > > > >> The problem is real with snapshotting. Ignoring > > > > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value > of > > > > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > > > > >> inactivation time. This was the big trouble with nfsd and snapshots. > As > > > > >> such, I think that precise value of mmnt_kern_flag is critical there, > > > > >> and mount interlock is needed. > > > > > > > > > > > > > > > This can be avoided using a memory barrier when setting flags. > > > > > Even if memory barriers usage is not encouraged, some critical code > > > > > should really use them replacing a mutex semantic (if that worths it). > > > > > > > > Why is memory barrier usage not encouraged? As you said, they can be > used to > > > reduce the number of atomic (LOCKed) operations, in some cases. > > > > > > > > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), > mb() > > > (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers > only > > > needed on SMP), and barrier() (GCC barrier (__asm __volatile > (:::"memory")) > > > macros that I've personally found very useful. > > > > Admittedly, they are harder to use than atomic operations, but it might > > > still worth having something similar. > > > > > > Memory barriers just specify ordering, they don't ensure a cache flush so > > > another CPU reads up to date values. You can use memory barriers in > > > conjunction with atomic operations on a variable to ensure that you can > > > safely read other variables (which is what locks do). For example, in > this > > > case IIUC, you have a race that is because there is shared state between > two > > > fields, one in the mount structure, and one in the ufs i-node. Memory > > > barriers alone won't prevent you from operating on those flags > > > non-consistently. That is, you have two memory locations in play here, > and > > > atomic ops only work on a single one. There isn't an atomic op to > do "read > > > from memory location A, check flag B, and if it's true write C to memory > > > location D". Where would you put the membar in this case to ensure that > the > > > action always results in consistent behavior? > > > > Ah no, I misunderstood the problem. > > I was thinking it was about setting the flag A into location B if C is > > not present. > > That's the same problem, setting a flag in one word if a flag is set (or not > set) in another word. Either way though you are dealing with two different > memory locations that need to be consistent with respect to one another. No, I meant something like: if (!(flag & FLAG1)) flag |= FLAG2; which can be done nicely with a memory barrier. I didn't catch the problem was about 2 different locations...sorry. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 22:19:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22C3916A403 for ; Tue, 12 Dec 2006 22:19:55 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B8F4443C1 for ; Tue, 12 Dec 2006 21:55:29 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id kBCLuVBB062194; Tue, 12 Dec 2006 15:56:31 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <457F259B.1060409@centtech.com> Date: Tue, 12 Dec 2006 15:56:43 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.7 (X11/20061015) MIME-Version: 1.0 To: Rod Person References: <200612111031.06109.rodperson@comcast.net> <457E2882.1030109@centtech.com> <200612121640.57627.rodperson@comcast.net> In-Reply-To: <200612121640.57627.rodperson@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2319/Tue Dec 12 14:09:22 2006 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 22:19:55 -0000 On 12/12/06 15:40, Rod Person wrote: > On Monday 11 December 2006 22:56, Eric Anderson wrote: >> For what it's worth, the nv driver works ok for my laptop running at >> 1920x1200. > > I think my problem with the nv driver has to do with it being a widescreen. > It will do 1280x960 but nothing above that even though it list one resolution > higher 1400 x something but it will not display it... 1920x1200 is a widescreen.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 18:45:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 437DE16A584; Tue, 12 Dec 2006 18:45:04 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3852C43CA8; Tue, 12 Dec 2006 18:42:54 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.100] (c-67-188-127-3.hsd1.ca.comcast.net [67.188.127.3]) by elvis.mu.org (Postfix) with ESMTP id EEE421A3C1C; Tue, 12 Dec 2006 10:43:36 -0800 (PST) Message-ID: <457EF835.2020705@FreeBSD.org> Date: Tue, 12 Dec 2006 10:43:01 -0800 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Attilio Rao References: <456950AF.3090308@sh.cvut.cz> <20061127092146.GA69556@deviant.kiev.zoral.com.ua> <457E6C06.1020405@FreeBSD.org> <20061212101903.GF311@deviant.kiev.zoral.com.ua> <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> In-Reply-To: <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Dec 2006 22:30:59 +0000 Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov , tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 18:45:04 -0000 Attilio Rao wrote: > 2006/12/12, Kostik Belousov : > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: >> > Kostik Belousov wrote: >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: >> > > >> > >>Hi, >> > >>the attached lor.txt contains LOR I got this yesterday. It is >> FreeBSD 6.1 >> > >>with relatively recent kernel, from last week or so. >> > >> >> > >>-- >> > >>VH >> > > >> > > >> > >>+lock order reversal: >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ >> /usr/src/sys/kern/kern_event.c:1547 >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 >> > >>+KDB: stack backtrace: >> > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at >> > >>kdb_backtrace+0x2f >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at >> > >>witness_checkorder+0x5fe >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at >> > >>_mtx_lock_flags+0x32 >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at >> > >>ufs_itimes+0x6c >> > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at >> > >>ufs_getattr+0x20 >> > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at >> > >>VOP_GETATTR_APV+0x3a >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at >> > >>VOP_WRITE_APV+0x148 >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at >> vn_write+0x201 >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at >> > >>dofilewrite+0x84 >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- >> > > >> > > >> > >Thank you for the report. The LOR is caused by my commit into >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. >> > >> > Is the mount lock really required, if all we're doing is a single >> read of a >> > single word (mnt_kern_flags) (v_mount should be read-only for the whole >> > lifetime of the vnode, I believe)? After all, reads of a single word >> are >> > atomic on all our supported architectures. >> > The only situation I see where there MIGHT be problems are forced >> unmounts, >> > but I think there are bigger issues with those. >> > Sorry for noticing this email only now. >> >> The problem is real with snapshotting. Ignoring >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode >> inactivation time. This was the big trouble with nfsd and snapshots. As >> such, I think that precise value of mmnt_kern_flag is critical there, >> and mount interlock is needed. > > > This can be avoided using a memory barrier when setting flags. > Even if memory barriers usage is not encouraged, some critical code > should really use them replacing a mutex semantic (if that worths it). Why is memory barrier usage not encouraged? As you said, they can be used to reduce the number of atomic (LOCKed) operations, in some cases. FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), mb() (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers only needed on SMP), and barrier() (GCC barrier (__asm __volatile (:::"memory")) macros that I've personally found very useful. Admittedly, they are harder to use than atomic operations, but it might still worth having something similar. -- Suleiman From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 19:16:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2A1616A415 for ; Tue, 12 Dec 2006 19:16:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8270E43F8C for ; Tue, 12 Dec 2006 19:05:03 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so292877nfc for ; Tue, 12 Dec 2006 11:06:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=qYtUiqK/k4tdf4aA2RMPta6D1hdpByUpQ7IQb+liq7vRyedMjGMA3R5E1GnsyZit6WNU29u4AJCIobLqXuA4CNdZAtNA07F9+J7btk/DEtGwiD1DK8f9u3Zy6USb1U16WPnDpTyNkZrQUfF/1tX91dazZdHiUF9ldnjb0sbw4F8= Received: by 10.82.153.5 with SMTP id a5mr795689bue.1165950372377; Tue, 12 Dec 2006 11:06:12 -0800 (PST) Received: by 10.82.178.4 with HTTP; Tue, 12 Dec 2006 11:06:12 -0800 (PST) Message-ID: <3bbf2fe10612121106n76244f60k3b6ed4c031e45057@mail.gmail.com> Date: Tue, 12 Dec 2006 20:06:12 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Suleiman Souhlal" In-Reply-To: <457EF835.2020705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <20061127092146.GA69556@deviant.kiev.zoral.com.ua> <457E6C06.1020405@FreeBSD.org> <20061212101903.GF311@deviant.kiev.zoral.com.ua> <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> <457EF835.2020705@FreeBSD.org> X-Google-Sender-Auth: 33cab782b2599903 X-Mailman-Approved-At: Tue, 12 Dec 2006 22:31:17 +0000 Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov , tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 19:16:46 -0000 2006/12/12, Suleiman Souhlal : > Attilio Rao wrote: > > 2006/12/12, Kostik Belousov : > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > >> > Kostik Belousov wrote: > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > >> > > > >> > >>Hi, > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > >> FreeBSD 6.1 > >> > >>with relatively recent kernel, from last week or so. > >> > >> > >> > >>-- > >> > >>VH > >> > > > >> > > > >> > >>+lock order reversal: > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > >> /usr/src/sys/kern/kern_event.c:1547 > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > >> > >>+KDB: stack backtrace: > >> > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at > >> > >>kdb_backtrace+0x2f > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > >> > >>witness_checkorder+0x5fe > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > >> > >>_mtx_lock_flags+0x32 > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at > >> > >>ufs_itimes+0x6c > >> > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > >> > >>ufs_getattr+0x20 > >> > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > >> > >>VOP_GETATTR_APV+0x3a > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at > >> > >>VOP_WRITE_APV+0x148 > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > >> vn_write+0x201 > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > >> > >>dofilewrite+0x84 > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > >> > > > >> > > > >> > >Thank you for the report. The LOR is caused by my commit into > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > >> > > >> > Is the mount lock really required, if all we're doing is a single > >> read of a > >> > single word (mnt_kern_flags) (v_mount should be read-only for the whole > >> > lifetime of the vnode, I believe)? After all, reads of a single word > >> are > >> > atomic on all our supported architectures. > >> > The only situation I see where there MIGHT be problems are forced > >> unmounts, > >> > but I think there are bigger issues with those. > >> > Sorry for noticing this email only now. > >> > >> The problem is real with snapshotting. Ignoring > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > >> inactivation time. This was the big trouble with nfsd and snapshots. As > >> such, I think that precise value of mmnt_kern_flag is critical there, > >> and mount interlock is needed. > > > > > > This can be avoided using a memory barrier when setting flags. > > Even if memory barriers usage is not encouraged, some critical code > > should really use them replacing a mutex semantic (if that worths it). > > Why is memory barrier usage not encouraged? As you said, they can be used to reduce the number of atomic (LOCKed) operations, in some cases. Beacause they can lead to "errors" as it is not so straightforward to understand when a memory barrier is needed more than an atomic instruction and so on (even if it doesn't value, for example, for ia32, for other architectures memory barriers could be more expensive than the atomic instruction, without counting a possible error). > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), mb() (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers only needed on SMP), and barrier() (GCC barrier (__asm __volatile (:::"memory")) macros that I've personally found very useful. I think that our memory barriers reflect the usage we do into the kernel as the base for building syncronizing primitives. From this point of view our atomic operations (meant into the wider possible sense, man 9 atomic) are more suitable than having something like Linux's smp_*(). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 20:06:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DBBB16A510; Tue, 12 Dec 2006 20:06:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70A2A4466D; Tue, 12 Dec 2006 19:33:50 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBCJZBKe020922; Tue, 12 Dec 2006 14:35:11 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Suleiman Souhlal Date: Tue, 12 Dec 2006 14:12:12 -0500 User-Agent: KMail/1.9.1 References: <456950AF.3090308@sh.cvut.cz> <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> <457EF835.2020705@FreeBSD.org> In-Reply-To: <457EF835.2020705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612121412.13551.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 12 Dec 2006 14:35:11 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2318/Tue Dec 12 11:58:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Mailman-Approved-At: Tue, 12 Dec 2006 22:31:50 +0000 Cc: freebsd-stable@freebsd.org, Attilio Rao , freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov , tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 20:06:41 -0000 On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > Attilio Rao wrote: > > 2006/12/12, Kostik Belousov : > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > >> > Kostik Belousov wrote: > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > >> > > > >> > >>Hi, > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > >> FreeBSD 6.1 > >> > >>with relatively recent kernel, from last week or so. > >> > >> > >> > >>-- > >> > >>VH > >> > > > >> > > > >> > >>+lock order reversal: > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > >> /usr/src/sys/kern/kern_event.c:1547 > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > >> > >>+KDB: stack backtrace: > >> > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at > >> > >>kdb_backtrace+0x2f > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > >> > >>witness_checkorder+0x5fe > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > >> > >>_mtx_lock_flags+0x32 > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at > >> > >>ufs_itimes+0x6c > >> > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > >> > >>ufs_getattr+0x20 > >> > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > >> > >>VOP_GETATTR_APV+0x3a > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at > >> > >>VOP_WRITE_APV+0x148 > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > >> vn_write+0x201 > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > >> > >>dofilewrite+0x84 > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > >> > > > >> > > > >> > >Thank you for the report. The LOR is caused by my commit into > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > >> > > >> > Is the mount lock really required, if all we're doing is a single > >> read of a > >> > single word (mnt_kern_flags) (v_mount should be read-only for the whole > >> > lifetime of the vnode, I believe)? After all, reads of a single word > >> are > >> > atomic on all our supported architectures. > >> > The only situation I see where there MIGHT be problems are forced > >> unmounts, > >> > but I think there are bigger issues with those. > >> > Sorry for noticing this email only now. > >> > >> The problem is real with snapshotting. Ignoring > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > >> inactivation time. This was the big trouble with nfsd and snapshots. As > >> such, I think that precise value of mmnt_kern_flag is critical there, > >> and mount interlock is needed. > > > > > > This can be avoided using a memory barrier when setting flags. > > Even if memory barriers usage is not encouraged, some critical code > > should really use them replacing a mutex semantic (if that worths it). > > Why is memory barrier usage not encouraged? As you said, they can be used to reduce the number of atomic (LOCKed) operations, in some cases. > > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), mb() (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers only needed on SMP), and barrier() (GCC barrier (__asm __volatile (:::"memory")) macros that I've personally found very useful. > Admittedly, they are harder to use than atomic operations, but it might still worth having something similar. Memory barriers just specify ordering, they don't ensure a cache flush so another CPU reads up to date values. You can use memory barriers in conjunction with atomic operations on a variable to ensure that you can safely read other variables (which is what locks do). For example, in this case IIUC, you have a race that is because there is shared state between two fields, one in the mount structure, and one in the ufs i-node. Memory barriers alone won't prevent you from operating on those flags non-consistently. That is, you have two memory locations in play here, and atomic ops only work on a single one. There isn't an atomic op to do "read from memory location A, check flag B, and if it's true write C to memory location D". Where would you put the membar in this case to ensure that the action always results in consistent behavior? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 21:53:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3903516A415; Tue, 12 Dec 2006 21:53:44 +0000 (UTC) (envelope-from rodperson@comcast.net) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5F9B43DEC; Tue, 12 Dec 2006 21:42:29 +0000 (GMT) (envelope-from rodperson@comcast.net) Received: from atomizer.opensourcebeef.net (unknown[71.61.11.4]) by comcast.net (rwcrmhc13) with ESMTP id <20061212214354m1300it74ge>; Tue, 12 Dec 2006 21:43:54 +0000 From: Rod Person Organization: Open Source Beef To: freebsd-current@freebsd.org Date: Tue, 12 Dec 2006 16:40:52 -0500 User-Agent: KMail/1.9.4 References: <200612111031.06109.rodperson@comcast.net> <457E2882.1030109@centtech.com> In-Reply-To: <457E2882.1030109@centtech.com> X-Face: $72, ]$Z1y\/nYF:T[d"3TSO@]'dM+)/B@hdK(?fAY@F4IPU, =?utf-8?q?wTha8oQ=5Cish=5D=26GCe=26C=5BvAG=0A=09g=3Bv=7E=60wM?=, 7H'7TW"!3zWJ_o]nb]i>oMCl=g1F$+$v+8i, xRtU(=?utf-8?q?vKPxX=5CoK7/9to!z08=7BJ=25A=0A=09p=23=60?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1221900.l6KA90pdth"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612121640.57627.rodperson@comcast.net> X-Mailman-Approved-At: Tue, 12 Dec 2006 22:53:28 +0000 Cc: Current Mailing List Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 21:53:44 -0000 --nextPart1221900.l6KA90pdth Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 11 December 2006 22:56, Eric Anderson wrote: > For what it's worth, the nv driver works ok for my laptop running at > 1920x1200. I think my problem with the nv driver has to do with it being a widescreen. It will do 1280x960 but nothing above that even though it list one resoluti= on=20 higher 1400 x something but it will not display it... --nextPart1221900.l6KA90pdth Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFfyHp3rDijyy3LEcRAhB2AJ9uto7OfpqIGZMCxDi4+/oqz8/7lQCgrmVR Pq30frbMFbAFLFkYD22DVqc= =CWTx -----END PGP SIGNATURE----- --nextPart1221900.l6KA90pdth-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 21:53:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3903516A415; Tue, 12 Dec 2006 21:53:44 +0000 (UTC) (envelope-from rodperson@comcast.net) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5F9B43DEC; Tue, 12 Dec 2006 21:42:29 +0000 (GMT) (envelope-from rodperson@comcast.net) Received: from atomizer.opensourcebeef.net (unknown[71.61.11.4]) by comcast.net (rwcrmhc13) with ESMTP id <20061212214354m1300it74ge>; Tue, 12 Dec 2006 21:43:54 +0000 From: Rod Person Organization: Open Source Beef To: freebsd-current@freebsd.org Date: Tue, 12 Dec 2006 16:40:52 -0500 User-Agent: KMail/1.9.4 References: <200612111031.06109.rodperson@comcast.net> <457E2882.1030109@centtech.com> In-Reply-To: <457E2882.1030109@centtech.com> X-Face: $72, ]$Z1y\/nYF:T[d"3TSO@]'dM+)/B@hdK(?fAY@F4IPU, =?utf-8?q?wTha8oQ=5Cish=5D=26GCe=26C=5BvAG=0A=09g=3Bv=7E=60wM?=, 7H'7TW"!3zWJ_o]nb]i>oMCl=g1F$+$v+8i, xRtU(=?utf-8?q?vKPxX=5CoK7/9to!z08=7BJ=25A=0A=09p=23=60?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1221900.l6KA90pdth"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612121640.57627.rodperson@comcast.net> X-Mailman-Approved-At: Tue, 12 Dec 2006 22:53:40 +0000 Cc: Current Mailing List Subject: Re: nvidia driver version 9631 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 21:53:44 -0000 --nextPart1221900.l6KA90pdth Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 11 December 2006 22:56, Eric Anderson wrote: > For what it's worth, the nv driver works ok for my laptop running at > 1920x1200. I think my problem with the nv driver has to do with it being a widescreen. It will do 1280x960 but nothing above that even though it list one resoluti= on=20 higher 1400 x something but it will not display it... --nextPart1221900.l6KA90pdth Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFfyHp3rDijyy3LEcRAhB2AJ9uto7OfpqIGZMCxDi4+/oqz8/7lQCgrmVR Pq30frbMFbAFLFkYD22DVqc= =CWTx -----END PGP SIGNATURE----- --nextPart1221900.l6KA90pdth-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 23:03:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4367616A4B3 for ; Tue, 12 Dec 2006 23:03:39 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D988844D01 for ; Tue, 12 Dec 2006 22:29:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 65716 invoked from network); 12 Dec 2006 22:17:51 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Dec 2006 22:17:51 -0000 Message-ID: <457F2D82.6000905@freebsd.org> Date: Tue, 12 Dec 2006 23:30:26 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 23:03:39 -0000 This is a patch adding automatic TCP send and receive socket buffer sizing. Normally the socket buffers are static (either derived from global defaults or set with setsockopt) and do not adapt to real network conditions. Two things happen: a) your socket buffers are too small and you can't reach the full potential of the network between both hosts; b) your socket buffers are too big and you waste a lot of kernel memory for data just sitting around. With automatic TCP send and receive socket buffers we can start with a small buffer and quickly grow it in parallel with the TCP congestion window to match real network conditions. FreeBSD has a default 32K send socket buffer. This supports a maximal transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer auto scaling and the default values below it supports 20Mbit/s at 100ms and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. For the receive side it looks slightly better with a default of 64K buffer size. The automatic send buffer sizing patch is currently running on one half of the FTP.FreeBSD.ORG cluster w/o any problems so far. Against this machine with the automatic receive buffer sizing patch I can download at 5.7MBytes per second. Without patch it maxed out at 1.6MBytes per second as the delay bandwidth product became equal to the static socket buffer size without hitting the limits of the physical link between the machines. My test machine is about 35ms from that FTP.FreeBSD.ORG and connected through a moderately loaded 100Mbit Internet link. New sysctl's are: net.inet.tcp.sendbuf_auto=1 (enabled) net.inet.tcp.sendbuf_inc=8192 (8K, step size) net.inet.tcp.sendbuf_max=262144 (256K, growth limit) net.inet.tcp.recvbuf_auto=1 (enabled) net.inet.tcp.recvbuf_inc=16384 (16K, step size) net.inet.tcp.recvbuf_max=262144 (256K, growth limit) The patch is available here (it may apply with some fuzz): http://people.freebsd.org/~andre/tcp_auto_buf-20061212.diff Any tests and test reports are very welcome. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 23:11:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03CBE16A4AB; Tue, 12 Dec 2006 23:11:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9278451F9; Tue, 12 Dec 2006 22:44:10 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBCMjGM8022238; Tue, 12 Dec 2006 17:45:17 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Tue, 12 Dec 2006 17:45:19 -0500 User-Agent: KMail/1.9.1 References: <456950AF.3090308@sh.cvut.cz> <200612121614.18502.jhb@freebsd.org> <3bbf2fe10612121334n12459019sb657a226615fc4b6@mail.gmail.com> In-Reply-To: <3bbf2fe10612121334n12459019sb657a226615fc4b6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612121745.20915.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 12 Dec 2006 17:45:17 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2319/Tue Dec 12 15:09:22 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , Suleiman Souhlal , freebsd-current@freebsd.org, tegge@freebsd.org, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 23:11:30 -0000 On Tuesday 12 December 2006 16:34, Attilio Rao wrote: > 2006/12/12, John Baldwin : > > On Tuesday 12 December 2006 15:13, Attilio Rao wrote: > > > 2006/12/12, John Baldwin : > > > > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > > > > > Attilio Rao wrote: > > > > > > 2006/12/12, Kostik Belousov : > > > > > > > > > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > > > > > >> > Kostik Belousov wrote: > > > > > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: > > > > > >> > > > > > > > >> > >>Hi, > > > > > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > > > > > >> FreeBSD 6.1 > > > > > >> > >>with relatively recent kernel, from last week or so. > > > > > >> > >> > > > > > >> > >>-- > > > > > >> > >>VH > > > > > >> > > > > > > > >> > > > > > > > >> > >>+lock order reversal: > > > > > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > > > > > >> /usr/src/sys/kern/kern_event.c:1547 > > > > > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > > > > > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > > > > > >> > >>+KDB: stack backtrace: > > > > > >> > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) > > at > > > > > >> > >>kdb_backtrace+0x2f > > > > > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > > > > > >> > >>witness_checkorder+0x5fe > > > > > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > > > > > >> > >>_mtx_lock_flags+0x32 > > > > > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at > > > > > >> > >>ufs_itimes+0x6c > > > > > >> > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > > > > > >> > >>ufs_getattr+0x20 > > > > > >> > > > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > > > > > >> > >>VOP_GETATTR_APV+0x3a > > > > > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 > > > > > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > > > > > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at > > > > > >> > >>VOP_WRITE_APV+0x148 > > > > > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > > > > > >> vn_write+0x201 > > > > > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > > > > > >> > >>dofilewrite+0x84 > > > > > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at > > kern_writev+0x65 > > > > > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > > > > > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > > > > > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > > > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = > > > > > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > > > > > >> > > > > > > > >> > > > > > > > >> > >Thank you for the report. The LOR is caused by my commit into > > > > > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > > > > > >> > > > > > > >> > Is the mount lock really required, if all we're doing is a single > > > > > >> read of a > > > > > >> > single word (mnt_kern_flags) (v_mount should be read-only for the > > whole > > > > > >> > lifetime of the vnode, I believe)? After all, reads of a single > > word > > > > > >> are > > > > > >> > atomic on all our supported architectures. > > > > > >> > The only situation I see where there MIGHT be problems are forced > > > > > >> unmounts, > > > > > >> > but I think there are bigger issues with those. > > > > > >> > Sorry for noticing this email only now. > > > > > >> > > > > > >> The problem is real with snapshotting. Ignoring > > > > > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value > > of > > > > > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode > > > > > >> inactivation time. This was the big trouble with nfsd and snapshots. > > As > > > > > >> such, I think that precise value of mmnt_kern_flag is critical there, > > > > > >> and mount interlock is needed. > > > > > > > > > > > > > > > > > > This can be avoided using a memory barrier when setting flags. > > > > > > Even if memory barriers usage is not encouraged, some critical code > > > > > > should really use them replacing a mutex semantic (if that worths it). > > > > > > > > > > Why is memory barrier usage not encouraged? As you said, they can be > > used to > > > > reduce the number of atomic (LOCKed) operations, in some cases. > > > > > > > > > > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), > > mb() > > > > (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers > > only > > > > needed on SMP), and barrier() (GCC barrier (__asm __volatile > > (:::"memory")) > > > > macros that I've personally found very useful. > > > > > Admittedly, they are harder to use than atomic operations, but it might > > > > still worth having something similar. > > > > > > > > Memory barriers just specify ordering, they don't ensure a cache flush so > > > > another CPU reads up to date values. You can use memory barriers in > > > > conjunction with atomic operations on a variable to ensure that you can > > > > safely read other variables (which is what locks do). For example, in > > this > > > > case IIUC, you have a race that is because there is shared state between > > two > > > > fields, one in the mount structure, and one in the ufs i-node. Memory > > > > barriers alone won't prevent you from operating on those flags > > > > non-consistently. That is, you have two memory locations in play here, > > and > > > > atomic ops only work on a single one. There isn't an atomic op to > > do "read > > > > from memory location A, check flag B, and if it's true write C to memory > > > > location D". Where would you put the membar in this case to ensure that > > the > > > > action always results in consistent behavior? > > > > > > Ah no, I misunderstood the problem. > > > I was thinking it was about setting the flag A into location B if C is > > > not present. > > > > That's the same problem, setting a flag in one word if a flag is set (or not > > set) in another word. Either way though you are dealing with two different > > memory locations that need to be consistent with respect to one another. > > No, I meant something like: > > if (!(flag & FLAG1)) > flag |= FLAG2; > > which can be done nicely with a memory barrier. > I didn't catch the problem was about 2 different locations...sorry. Ah. Even that can't be solved by membars alone. What if you have: if (!(flag & FLAG1)) flag |= FLAG2; in one thread and in another: if (!(flag & FLAG2)) flag |= FLAG1; even if you put membar's in place, you can still get breakage (imagine flag being 0 initially and getting preempted in between test and set). For this case you could use atomic_cmpset() in a loop without membars: do { x = flag; if (x & FLAG1) break; } while (!atomic_cmpset_int(&flag, x, x | FLAG2)); but often you have several variables linked together that need to be in a consistent state relative to each other, so you need to use a lock instead anyways. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 23:31:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A7C016A4FB for ; Tue, 12 Dec 2006 23:31:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2399E44948 for ; Tue, 12 Dec 2006 23:13:53 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so342782nfc for ; Tue, 12 Dec 2006 15:15:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ktXHBR+JbhlbHm3iMk+Dn0PAg/UYdyNIrmFcb7YsHmxeYwb8oJ9NrqTX9i0lJ5swnpvhk4b5abusmCqOIlxMLrb/rMFIjmlWkwlafICkgFxLqZ6zlHyiEYhRZuyzqHhvLAHqxPrEdPhefC8RbeR9YvhiF3hrDLxHDGPX4ydMM94= Received: by 10.82.111.8 with SMTP id j8mr28257buc.1165965311176; Tue, 12 Dec 2006 15:15:11 -0800 (PST) Received: by 10.82.178.4 with HTTP; Tue, 12 Dec 2006 15:15:11 -0800 (PST) Message-ID: <3bbf2fe10612121515pacc3c43u501efd5d5fd1a2bd@mail.gmail.com> Date: Wed, 13 Dec 2006 00:15:11 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200612121745.20915.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <200612121614.18502.jhb@freebsd.org> <3bbf2fe10612121334n12459019sb657a226615fc4b6@mail.gmail.com> <200612121745.20915.jhb@freebsd.org> X-Google-Sender-Auth: 8d76d1ee46cd33eb Cc: Kostik Belousov , Suleiman Souhlal , freebsd-current@freebsd.org, tegge@freebsd.org, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 23:31:35 -0000 2006/12/12, John Baldwin : > On Tuesday 12 December 2006 16:34, Attilio Rao wrote: > > 2006/12/12, John Baldwin : > > > On Tuesday 12 December 2006 15:13, Attilio Rao wrote: > > > > 2006/12/12, John Baldwin : > > > > > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > > > > > > Attilio Rao wrote: > > > > > > > 2006/12/12, Kostik Belousov : > > > > > > > > > > > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > > > > > > >> > Kostik Belousov wrote: > > > > > > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman > wrote: > > > > > > >> > > > > > > > > >> > >>Hi, > > > > > > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > > > > > > >> FreeBSD 6.1 > > > > > > >> > >>with relatively recent kernel, from last week or so. > > > > > > >> > >> > > > > > > >> > >>-- > > > > > > >> > >>VH > > > > > > >> > > > > > > > > >> > > > > > > > > >> > >>+lock order reversal: > > > > > > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > > > > > > >> /usr/src/sys/kern/kern_event.c:1547 > > > > > > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > > > > > > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > > > > > > >> > >>+KDB: stack backtrace: > > > > > > >> > > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) > > > at > > > > > > >> > >>kdb_backtrace+0x2f > > > > > > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > > > > > > >> > >>witness_checkorder+0x5fe > > > > > > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > > > > > > >> > >>_mtx_lock_flags+0x32 > > > > > > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) > at > > > > > > >> > >>ufs_itimes+0x6c > > > > > > >> > > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > > > > > > >> > >>ufs_getattr+0x20 > > > > > > >> > > > > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > > > > > > >> > >>VOP_GETATTR_APV+0x3a > > > > > > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at > filt_vfsread+0x75 > > > > > > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > > > > > > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) > at > > > > > > >> > >>VOP_WRITE_APV+0x148 > > > > > > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > > > > > > >> vn_write+0x201 > > > > > > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > > > > > > >> > >>dofilewrite+0x84 > > > > > > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at > > > kern_writev+0x65 > > > > > > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > > > > > > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > > > > > > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > > > > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp > = > > > > > > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > > > > > > >> > > > > > > > > >> > > > > > > > > >> > >Thank you for the report. The LOR is caused by my commit into > > > > > > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > > > > > > >> > > > > > > > >> > Is the mount lock really required, if all we're doing is a > single > > > > > > >> read of a > > > > > > >> > single word (mnt_kern_flags) (v_mount should be read-only for > the > > > whole > > > > > > >> > lifetime of the vnode, I believe)? After all, reads of a single > > > word > > > > > > >> are > > > > > > >> > atomic on all our supported architectures. > > > > > > >> > The only situation I see where there MIGHT be problems are > forced > > > > > > >> unmounts, > > > > > > >> > but I think there are bigger issues with those. > > > > > > >> > Sorry for noticing this email only now. > > > > > > >> > > > > > > >> The problem is real with snapshotting. Ignoring > > > > > > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale > value > > > of > > > > > > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs > vnode > > > > > > >> inactivation time. This was the big trouble with nfsd and > snapshots. > > > As > > > > > > >> such, I think that precise value of mmnt_kern_flag is critical > there, > > > > > > >> and mount interlock is needed. > > > > > > > > > > > > > > > > > > > > > This can be avoided using a memory barrier when setting flags. > > > > > > > Even if memory barriers usage is not encouraged, some critical > code > > > > > > > should really use them replacing a mutex semantic (if that worths > it). > > > > > > > > > > > > Why is memory barrier usage not encouraged? As you said, they can be > > > used to > > > > > reduce the number of atomic (LOCKed) operations, in some cases. > > > > > > > > > > > > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), > > > mb() > > > > > (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers > > > only > > > > > needed on SMP), and barrier() (GCC barrier (__asm __volatile > > > (:::"memory")) > > > > > macros that I've personally found very useful. > > > > > > Admittedly, they are harder to use than atomic operations, but it > might > > > > > still worth having something similar. > > > > > > > > > > Memory barriers just specify ordering, they don't ensure a cache flush > so > > > > > another CPU reads up to date values. You can use memory barriers in > > > > > conjunction with atomic operations on a variable to ensure that you > can > > > > > safely read other variables (which is what locks do). For example, in > > > this > > > > > case IIUC, you have a race that is because there is shared state > between > > > two > > > > > fields, one in the mount structure, and one in the ufs i-node. Memory > > > > > barriers alone won't prevent you from operating on those flags > > > > > non-consistently. That is, you have two memory locations in play > here, > > > and > > > > > atomic ops only work on a single one. There isn't an atomic op to > > > do "read > > > > > from memory location A, check flag B, and if it's true write C to > memory > > > > > location D". Where would you put the membar in this case to ensure > that > > > the > > > > > action always results in consistent behavior? > > > > > > > > Ah no, I misunderstood the problem. > > > > I was thinking it was about setting the flag A into location B if C is > > > > not present. > > > > > > That's the same problem, setting a flag in one word if a flag is set (or > not > > > set) in another word. Either way though you are dealing with two > different > > > memory locations that need to be consistent with respect to one another. > > > > No, I meant something like: > > > > if (!(flag & FLAG1)) > > flag |= FLAG2; > > > > which can be done nicely with a memory barrier. > > I didn't catch the problem was about 2 different locations...sorry. > > Ah. Even that can't be solved by membars alone. What if you have: > > if (!(flag & FLAG1)) > flag |= FLAG2; > > in one thread and in another: > > if (!(flag & FLAG2)) > flag |= FLAG1; > > even if you put membar's in place, you can still get breakage (imagine flag > being 0 initially and getting preempted in between test and set). For this > case you could use atomic_cmpset() in a loop without membars: > > do { > x = flag; > if (x & FLAG1) > break; > } while (!atomic_cmpset_int(&flag, x, x | FLAG2)); > > but often you have several variables linked together that need to be in a > consistent state relative to each other, so you need to use a lock instead > anyways. yes, this is exactly what I had in mind (and that we do with mutex/rwlocks coding code). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 12 23:34:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D269D16A503 for ; Tue, 12 Dec 2006 23:34:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6979D43FBB for ; Tue, 12 Dec 2006 23:15:29 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so343083nfc for ; Tue, 12 Dec 2006 15:16:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=m4nvQEs0BMuK3xuODQWFZPig/0NVy7yITm0HKy4aiir416wNJ2Oe0qaCKDwZKCHTp5CI5VmvRLlky9VW4ZqspNree1BB6vH6LjD4heNYsis4s3JdMqywUP5D8aivS1uPAwVG/NTWDgT4qVxPJ1z8fSdlo7IKepy5ODNHtdF90/g= Received: by 10.82.120.14 with SMTP id s14mr25580buc.1165965413250; Tue, 12 Dec 2006 15:16:53 -0800 (PST) Received: by 10.82.178.4 with HTTP; Tue, 12 Dec 2006 15:16:53 -0800 (PST) Message-ID: <3bbf2fe10612121516r78426f9bp95401e33c8871fea@mail.gmail.com> Date: Wed, 13 Dec 2006 00:16:53 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <3bbf2fe10612121515pacc3c43u501efd5d5fd1a2bd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <200612121614.18502.jhb@freebsd.org> <3bbf2fe10612121334n12459019sb657a226615fc4b6@mail.gmail.com> <200612121745.20915.jhb@freebsd.org> <3bbf2fe10612121515pacc3c43u501efd5d5fd1a2bd@mail.gmail.com> X-Google-Sender-Auth: fcfcbd8465ea8cf0 Cc: Kostik Belousov , Suleiman Souhlal , freebsd-current@freebsd.org, tegge@freebsd.org, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 23:34:11 -0000 2006/12/13, Attilio Rao : > 2006/12/12, John Baldwin : > > On Tuesday 12 December 2006 16:34, Attilio Rao wrote: > > > 2006/12/12, John Baldwin : > > > > On Tuesday 12 December 2006 15:13, Attilio Rao wrote: > > > > > 2006/12/12, John Baldwin : > > > > > > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > > > > > > > Attilio Rao wrote: > > > > > > > > 2006/12/12, Kostik Belousov : > > > > > > > > > > > > > > > >> On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: > > > > > > > >> > Kostik Belousov wrote: > > > > > > > >> > >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman > > wrote: > > > > > > > >> > > > > > > > > > >> > >>Hi, > > > > > > > >> > >>the attached lor.txt contains LOR I got this yesterday. It is > > > > > > > >> FreeBSD 6.1 > > > > > > > >> > >>with relatively recent kernel, from last week or so. > > > > > > > >> > >> > > > > > > > >> > >>-- > > > > > > > >> > >>VH > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > >>+lock order reversal: > > > > > > > >> > >>+ 1st 0xc537f300 kqueue (kqueue) @ > > > > > > > >> /usr/src/sys/kern/kern_event.c:1547 > > > > > > > >> > >>+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ > > > > > > > >> > >>/usr/src/sys/ufs/ufs/ufs_vnops.c:138 > > > > > > > >> > >>+KDB: stack backtrace: > > > > > > > >> > > > >>+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) > > > > at > > > > > > > >> > >>kdb_backtrace+0x2f > > > > > > > >> > >>+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at > > > > > > > >> > >>witness_checkorder+0x5fe > > > > > > > >> > >>+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at > > > > > > > >> > >>_mtx_lock_flags+0x32 > > > > > > > >> > >>+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) > > at > > > > > > > >> > >>ufs_itimes+0x6c > > > > > > > >> > > > >>+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at > > > > > > > >> > >>ufs_getattr+0x20 > > > > > > > >> > > > > > >>+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at > > > > > > > >> > >>VOP_GETATTR_APV+0x3a > > > > > > > >> > >>+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at > > filt_vfsread+0x75 > > > > > > > >> > >>+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 > > > > > > > >> > >>+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) > > at > > > > > > > >> > >>VOP_WRITE_APV+0x148 > > > > > > > >> > >>+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at > > > > > > > >> vn_write+0x201 > > > > > > > >> > >>+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,ffffffff,...) at > > > > > > > >> > >>dofilewrite+0x84 > > > > > > > >> > >>+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at > > > > kern_writev+0x65 > > > > > > > >> > >>+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f > > > > > > > >> > >>+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 > > > > > > > >> > >>+Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > > > > > >> > >>+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp > > = > > > > > > > >> > >>0xbfbfea1c, ebp = 0xbfbfea48 --- > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > >Thank you for the report. The LOR is caused by my commit into > > > > > > > >> > >sys/ufs/ufs/ufs_vnops.c, rev. 1.280. > > > > > > > >> > > > > > > > > >> > Is the mount lock really required, if all we're doing is a > > single > > > > > > > >> read of a > > > > > > > >> > single word (mnt_kern_flags) (v_mount should be read-only for > > the > > > > whole > > > > > > > >> > lifetime of the vnode, I believe)? After all, reads of a single > > > > word > > > > > > > >> are > > > > > > > >> > atomic on all our supported architectures. > > > > > > > >> > The only situation I see where there MIGHT be problems are > > forced > > > > > > > >> unmounts, > > > > > > > >> > but I think there are bigger issues with those. > > > > > > > >> > Sorry for noticing this email only now. > > > > > > > >> > > > > > > > >> The problem is real with snapshotting. Ignoring > > > > > > > >> MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale > > value > > > > of > > > > > > > >> mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs > > vnode > > > > > > > >> inactivation time. This was the big trouble with nfsd and > > snapshots. > > > > As > > > > > > > >> such, I think that precise value of mmnt_kern_flag is critical > > there, > > > > > > > >> and mount interlock is needed. > > > > > > > > > > > > > > > > > > > > > > > > This can be avoided using a memory barrier when setting flags. > > > > > > > > Even if memory barriers usage is not encouraged, some critical > > code > > > > > > > > should really use them replacing a mutex semantic (if that worths > > it). > > > > > > > > > > > > > > Why is memory barrier usage not encouraged? As you said, they can be > > > > used to > > > > > > reduce the number of atomic (LOCKed) operations, in some cases. > > > > > > > > > > > > > > FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), > > > > mb() > > > > > > (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers > > > > only > > > > > > needed on SMP), and barrier() (GCC barrier (__asm __volatile > > > > (:::"memory")) > > > > > > macros that I've personally found very useful. > > > > > > > Admittedly, they are harder to use than atomic operations, but it > > might > > > > > > still worth having something similar. > > > > > > > > > > > > Memory barriers just specify ordering, they don't ensure a cache flush > > so > > > > > > another CPU reads up to date values. You can use memory barriers in > > > > > > conjunction with atomic operations on a variable to ensure that you > > can > > > > > > safely read other variables (which is what locks do). For example, in > > > > this > > > > > > case IIUC, you have a race that is because there is shared state > > between > > > > two > > > > > > fields, one in the mount structure, and one in the ufs i-node. Memory > > > > > > barriers alone won't prevent you from operating on those flags > > > > > > non-consistently. That is, you have two memory locations in play > > here, > > > > and > > > > > > atomic ops only work on a single one. There isn't an atomic op to > > > > do "read > > > > > > from memory location A, check flag B, and if it's true write C to > > memory > > > > > > location D". Where would you put the membar in this case to ensure > > that > > > > the > > > > > > action always results in consistent behavior? > > > > > > > > > > Ah no, I misunderstood the problem. > > > > > I was thinking it was about setting the flag A into location B if C is > > > > > not present. > > > > > > > > That's the same problem, setting a flag in one word if a flag is set (or > > not > > > > set) in another word. Either way though you are dealing with two > > different > > > > memory locations that need to be consistent with respect to one another. > > > > > > No, I meant something like: > > > > > > if (!(flag & FLAG1)) > > > flag |= FLAG2; > > > > > > which can be done nicely with a memory barrier. > > > I didn't catch the problem was about 2 different locations...sorry. > > > > Ah. Even that can't be solved by membars alone. What if you have: > > > > if (!(flag & FLAG1)) > > flag |= FLAG2; > > > > in one thread and in another: > > > > if (!(flag & FLAG2)) > > flag |= FLAG1; > > > > even if you put membar's in place, you can still get breakage (imagine flag > > being 0 initially and getting preempted in between test and set). For this > > case you could use atomic_cmpset() in a loop without membars: > > > > do { > > x = flag; > > if (x & FLAG1) > > break; > > } while (!atomic_cmpset_int(&flag, x, x | FLAG2)); > > > > but often you have several variables linked together that need to be in a > > consistent state relative to each other, so you need to use a lock instead > > anyways. > > yes, this is exactly what I had in mind (and that we do with > mutex/rwlocks coding code). s/coding/locking Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 00:37:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 793CA16A415 for ; Wed, 13 Dec 2006 00:37:49 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 579C943CC5 for ; Wed, 13 Dec 2006 00:36:19 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 7CB631CE6F; Tue, 12 Dec 2006 19:37:44 -0500 (EST) Date: Tue, 12 Dec 2006 19:37:44 -0500 From: Adam McDougall To: freebsd-current@freebsd.org Message-ID: <20061213003744.GP18799@egr.msu.edu> References: <20061210002923.GO81923@egr.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <20061210002923.GO81923@egr.msu.edu> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 00:37:49 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Dec 09, 2006 at 07:29:23PM -0500, Adam McDougall wrote: src/sys/i386/cpufreq/est.c has many Pentium M cpus but nothing from the Intel Core and Core 2 families that I can see. I tried looking up the values myself, but could not find them in: http://www.intel.com/design/mobile/datashts/314078.htm It seems that even the latest version of the Linux kernel does not list values for at least Yonah (Core 2). Is it a big mystery, or is this data actually available somewhere? I have a Core 2 Duo T7600 in my laptop and est won't touch my cpu because it doesn't recognize it. I did get it to use some other form of speed control by putting hint.acpi_perf.0.disabled="1" in /boot/loader.conf according to another post. Another thing I wish could work is the Enhanced cpu Sleep States; this Dell Latitude D820 laptop only sees C1 although the document above indicates it should probably support 4 unique states. Is there a way I can debug and/or fix this? I can post dumps of the acpi stuff and/or verbose boot logs if it would be helpful. Thanks _______________________________________________ I am attaching my asl and dsdt acpi dumps incase someone knows for something to look for as for why it thinks I only have C1, unless its related to the speed control problem above. --Fba/0zbH8Xs+Fj9o Content-Type: application/octet-stream Content-Disposition: attachment; filename="d820.asl.gz" Content-Transfer-Encoding: base64 H4sICAJLf0UAA2Q4MjAuYXNsAOw9bXPauNafk1/hm0/NDtv6DQOd4YOxTcItBBc7Ie3sDEOJ SXmWQC4hve3d6X+/ko5lybbkF0J3u89c7w4F6ejovOtIlpQ3v5wqyiRwFT+cvFXG3qjresNh Q7EdfzCbRF+62mv1q/JKPT89QVBhV/1qLKO21jHbDWXx+9PzQ1c326fKL29O38SYwrfKMNrc 7z93LQSDUKyeVttNV2sozucImmitTuP0BHU2cOPu0HclnH9aRwoqGqktKEkaq1/11p2lztU7 1M7ZRfP9doch7QC1pb85aEs7PfE2+90qeur+oQDNeltVG/T7kn03VK58wcMsOJjOIvluMBit s1gq3xn7fSS2hH1NsyT8t9Qfzr5ygmgJQF0djbDlMv0ZpqqengyuwtlojCjo2v7AOT3xd9Ey 2u2iu5k/mvm77XK1jrqj7Sf0j/JKRxYQOIMZatTtoK+jwcwZuQjfJz22Fu/K7g09VILYgxJ3 ENAixH5g9gbjYDbx3qOCTgv1F4R26M2cK0xWGxHkj7T5zLsJZ73hO1SkIc38Sv4x4joEyupM qGviOj1VpUMznaCchaMJa9SGRp9OTy58T2UtoFxfohaz4c1Qnw3tsKs1VeX5qaGQIoMU6aTo 9KQ/vA4uZ8HgI+KuocS/wsnARb9PT9zr8MNs3O8HXogVT35OB2542UWcuPaHmT2cjLqa0VBG 4yv4gbA43lV4PfnQbWLd2L4z643H4cyeOJfdP4behe18mLneTaOtmvp3RMF6fo+se9obXN24 DX8ydmaO1oipv/Yb/hSxfR2G46tGMPTp10nozAKz4TrvZo7tp003eHtCPddsKJf/Dlb3SDgq eZZLxOVq9zCbzn+PZjfRIqnBlnSx3n6ar2fD7eL3LqUM1H16chPtwCxZXy4fJXTVakoDhWkm noIMzzTUjK8EH4J+9PXr15zDIB1raWdB7cXeoiMbUi3dZPRd+h6jrynzYg3Ft5purFUPX5gG 5er54VO0wxZlu+4kJfLLKW6BcSKU24fH+W6FsDx1dfzzebOPdkqw+k/URdXD6H6++KYMJu+V 3fZ5v9rcK4v5I6az+0c4ufaQMfnOQLmJNndAF/bGtnV6MlptVg/ztRKukF41nYvzOGCwQKea MhFp+o+NdCYKI8jqEI2YIiWW0jKKYinFTuI7v9rh99PTk/DbY9RlDZBcUZxSHP+6y4AhjrlI KgQnlkdhS62gpUZbDsa0WVyjk/ir9OzAE+h3GS2AA9ocgY6/oOC8uotOT3rXAW6DFNqFMD7B 6Civ2zW2hW/dxXaz3O4ekLobSrhb3d8jS2Jl30tRd2LUnTzq+WK/+hL9+nnFMK+jL9E6I+Kr 0SAt4SHuzF9tOJkV4Yzu7qNClNqBKJkdB/1/JHbc0Xgztv5MO8YjNqVp5PQvWA6ly2jq/HiS kDnMnyLFvrvbRU9PXYWzzyQOBdH9Q7TZKxcotDxSEFS8n+/2Su8Zt8K52B18twzGZzDkYojR ksWQVu0oe7joA35g0nRTRlMzIcl/mETLDE3O47P/kKOK5JkHjki/KAMU0dcKGD6K9tsNlrm9 W3xe7aPF/nkXYSB7NFTc1dP86Sl6QLTslC8w9ioYIcpuMKcYjsF8U7ZL5c3+4fHNfPG4unt+ eHz9fu73Pw5QZoLaudFC0TT0/1u9/VZXMR6LEOVGSzQ27BHu3hoN+sqrMzymv54/rM8aCvmO /kUSO4NRGxfSofqsERsJHqLPT/9AYleUq/kDyjFvvEmAsq354vf5PfqJwIxzUg1A+DlDeen/ IY7fKtgYFFdtktKGwiDc+T56q6jaG/Q/ZjxVibKRtwqa06jo/zNS/B268L5gib7y/hm65xxJ o0HgNJDtLlFmTCjqZCnCzDRqfKYa8hQQQ4h63/ZRfxWt72jf0Ap9V8vAdAKml4EZBMwoAzMJ mFkG1iRgzTIwi4BZZWAtAtYqA2sTsDaAjZ73EZqiohnJLanU4uJo/3l7R8obChLN1XYfRLvV fI2yorusEu3Fv55Xu4hh6aPnPKkOkIOiSnt3j2z6t1nQe43gbFG9yuqdXH1S01DIaKYyiOln MssaIirRp/evZzTWvQIgMIHzcwbM6K6GHI2hEmA7BtYY8CRaRzjqE1HwxSjKbGKaYvAYL3hK cHurpjwF+fe58sf38zSMloJpMwjQ9nS7u4u1DcBg/ui7XgZmEjAjo/1bDQvwKOrPkhKzz7rC 0xOtpKsYF8aSV9Rgs9hFZDh9lataJtZxQUSwY/aBE/3xElRwLjeUnD+ByoCU4FbnessZtbQ6 oSERC4hGLCDthQJCqUjKLUQyPJag0jbGC0orFpS4up6g9CMLyvyBgnLlktKLJSWuricpozy6 E06HKIWlIZyyhwmp4S9Ad4wi7xDI/zFFulpOtFlOdCroyIYLYIoKDFMmHyaQqCgLWXRESPLY I+Hi1qrMxf+DkZMOgBkm8lJp/jwGeWthA2o52VqZQs3yoTJB2oul+xKDJR4uN9jbJg0oRzLY 9k+jmiR2gzDdWJhVFdWqoKiD1GFIOSQjCj/Y5FPHWGvtlNa0l2pN0ypZpam8ytliIt8OJ1+a ImaYwhWSQRKklBoTE8iS2CJulIZ8/rTfzRf7tFtIYHMjpCEMVthEqDxyAjUrZMR/uzRVnDTg hwburGflIjsLZ3mRVbHBv2viWkl02sGi048sup8qla0kO/1g2f08yS3VkIly3KrDlPmXpLnm kdNcs1nDgGPxZFHT5Q/dYMsfMUyyABJTb1K4LA7OoAyJvWgVfE2wvpPB41/57ytMP281NTXk kulPJiWkZXq2jBgnj0sTDt8ScWJOefjU4pTYmRBT7pGZMmoyxRGdJ+7iyMTlyoqJAwP1L7yQ GSjJLgTmCVDp3EOmEQwrYzmoEB3qsKyVsWyYghjJh5I6KgumLyDfKiVVjYk7hDY3eIlo26W0 6S+g7WLkjark8xLiWlWChn6soBGMRr3DidWKJHR8Yi/Gk+ELJNv5c4iFlzXT0SDgX9ZA+JmO 6Guy8xRnqLxKEilTQ7M6Z5iCSmaMANEQbZSQNH6MdnP8lnQS3eP3sK+mU3+Cos+3p330MIoe trtvJJ1ReVngJ87JABwnafZiQeT+e0Pxd9FTtPsSyTIg5GAoNClKm0tskq+itE8jNCAJT2/s YU42uLBBkMoE0Ty2IMwjCWKKl9EVxdDlkuAT/qqiQGhlojAPEcWknk1MDrOJyRFtAtAJq+LX 1QhAJiPr2DISmMtBMpoc2VwAYZGUJnJLalWc+WVmvUAU7J0tXfiGeFuwzsTNyjJLB4KZmZab meU7Jk1RxEhN5iRd4KfC3D8PqqVAM1g5lRJG4xVCx8kuZ/8McrL+SjkJJEYHdpYR5gy3zmYL mgWk37YTs47f43AZgcyWcXLAD+kcudiN+IUNPkOJJ8GYhHzikuMvzk86bUTv2Wi12G2ftsu9 Ml1t7rb/fjrjk5irsCkEUq7CFNx0cDUSwY28t8potV5Hm83q+UHx7sg2q3TTWx+1pHh1VdXS 1cOLdLV1ls6n0JzMKVdT4QpR6FxO8nJjpdlEOpx45T3GqyThJLVJpJlZI0mg9CKo9KtmhFJU pZEqPVf1MdptBWkuVI43Ud5lqJ9nioVhF4ufshn3IXmXkoHXs/CZJUduQODfg2oJdGnMoYrE AiiMm4XLaDm7QCITmsU4GLjliT0fEPDOtZKAwGKyxu9047E5283dJFriFYDfZogIwdscsXwG tAVxwgy4uEmKJE0VkZSRmqiz4UX9zvSCzuS/vPVTVEEK2KOBPJTioLhYn7x4v2J1WfBd4ih7 QJftF3SJA/YBXZp1lSDwH4YgG1fHQfiCOT+3EQO7Yh4mTXmFZZ5gsX3EWypKM/qJM+llM3qU CZiq2o4P5Jkqn47FYxA0I2l4jdR+vFw+RXtwQPIWWFJrFNeaaKqRqb307QBPGvRMOX5weTMP 7+FyraAXrZ3thWLLtvLt0BWVB7LyUU9YfunawnK70xKWp6i1s9ROfFcTtULluqTckJSbkvKm pNwi5ZwrwSefHNnvPNEa05V3U8WT4vWi0QAz36aTBvEbSXuTTsrlL61Qn6vlt3hvkd8LrzB8 WzymijDLN9F4/ww9SXYsQmRKEQ0Hbh1EbSkifzqpgUiTj/Ou864GIl2OqGd/qIHIlCNKqTGo rcZ2QU4zGmRI5NBRE8a6rmDCYLu2lV1fShuhM1Dxh/f6AsmZB810iu2irt+YRqHfDEEuBRv6 UDtZbb/gHX+aCsuVUpFQksdvVMoRY/Jg1h8PrdScq6YQOX2IVigS1tZR9AhvJb12HuR7riSX 5skJ4SXB8ZLy8XIsQpZe3wzcIrakjfSyVkwguueJwfJCEWSBUpLbgs7zwPaFL2sgzPhSGIbp htk3kNNJbc/rtKU2fzvmNs3g40b5OWkqXo13dI4Vf9OpgfOnlfCTDnVanbHQdgpCKMEJlHI7 qvTijuVDJTFzwaw6b84pEnt2CNFbuoCGnwqzqppYpWOJVjKSv5TPKmYsokieEvwZFKWMRVMr GUtB8nE4ydoPMZYSrMWqKciNXsrngcZSkGT9QIo4upKtFM672kHWahKh6oIgm0uT+YOMeUzt VmGilG6aFkA2nLcKlxh5wGyWiZ+URRZ3pOc7yp8/5OEzyV/hCmoCodZSviCblZpBjl0xfqoh afqSV5AcGUG4ut/gDIudQE7TV5vDgmDAYaSGjidBtee/Vq35b8FRjzg7yb3zrmSB6daSc68A 07N5mIwIHC94wdYkLbVv6vANNLktSIP6WV49vVTJxcKPr8PLUb35bMGwIs+qM1ZbnFGLY0xN 2/vfpDB5/jcpPPKk8GV53UEzyHrLejjmHWVZjxHuT147/rUwM88C5TKygxcD83IbuJ76OvAc 9fXIJi9JciNiPZ+soqukz7IBuIjLgtw3vXsouXajHGfB0qIgjbj1BUMp1wkdm5Aaw6DCvvU4 W7BhF4twmPttNrXfVUZlt7KpIx35Un3gJ7u4y8ctbgdZrZV5VXwWKL/Gkl4HSWtQ4+9XSarH QShxx5J1kcoThwr5+t8pD5eNQ3rlIbU0k6/ChmBPVoX3u4WzofRCPUcXo2H67tIXnrrgrlDS ZTpU09cR0SJGp9BRr4ifVj98jMwcv3KTGmpHaqiFe+skiVjFXSEFE9R6CfJLsMpT0nrv2mqN immrFR9MfMFLr2LPOHi6UNXJBdP0IgUBTQLqSpdiS5ffJPYpH2jqWFJxbC4dsvIBCHyM+Wlm M8fswveyHk7jwWyoSs9G52njjGScDl0cUQy11qmOGr/AL0do1UCI5FGKUJWeD8ojLDzqSnoU Tu7EmuN4ah+JBDGDRg2J5ULBddCrxoQqvXqkYjdatW6cF3ajV+tGumRTsRujWjfSzZNVuvEu nUG1bqQHoKt0Y3/Eh2aqdFPD2dNJhCNf78JP2ZCeRy/mBM+LXl8NHNEUILs9tmS8r9rlxFd1 1G+QM7uKfZqH9WniPk1xn+lvqb1VzgS/XuOvAOzoBRf8ATgBQ/+iX5mbG1GJNPiIUs0Ukuza 7gTzUza9zG15BxIxVvKZ3ykOU8h0Fbc3uoieZlV6ciI7Bj01CLWqEuq+lFJyNgXawM7ZArJm avk5Mqx1eFFxzpc1swdeAS69cIAZz55zTsrEx7YQUYhysyJRZitLQDpbBkJzRDUFRJk8Uaky 8bZhRKhe4QAIlV5bID1XQHyOAFTmCMpyDInK0owTy+APoGQDvRtJDyQAPnGppGep0VW4kKW2 2HK6lIjN+PuKrcJFMInYWvnONJGrqAeJzRK0tY4sNktWKulZKrYKN89QEbX48/sQYSGQ5pZV kuvGYIBObZ4SnGhK370TQ8nyMpFy8FPtuFAylOP72nKhP5mN+pOsEPzddoHI3KKsg756oOcG 8T3jGny3cC4iaRPvSitok8p0ULakltxUnlleE/wEtOdptEY52uYBaM1ytK0D0DaPijbRcPgx iyj8HO0e5uuP2w0CCC9HMgNMphPORLqdX9ySEJAYoCc/QDt6Xu9Xj+tvqUTblsNnz+batuCi UfqIrs6gTybfT1gNR/7BrF4MrvpwTEkyeTqQKIxXljYWEJXZW8HK8/fQcG00YZtkz4Um3HPB tddF7bl71Tjl9WzrgDNgPbyILyNA8H65WODpbyUHr8BVL/xB7oB7Yj+kTq4q4cwbBkeM9ryY HjStzJKUOwuGpvHJ7Q6DMaYzv85CL+UjoMnNDlfbagfA4HZfRWnnDkQNXOm9GAI68RFcns52 7hRFQic5nnwAnbaUHjf6slpg2Y+mqjT+Jffr3GYpww9Yw+wSc332y+PmUV1o5pkQ5lq8CYOd 6O59kE3AxKThp/hM+ciXujFcs5GDkESfIJy6hxKXvuHjhxDnTg8lzv3h1DlDrNfagbtsaRs/ kkuHJddVyjsjHSLzS1/zWPT2tiD9ZOIoEE7sElP3gl/esswysaBARsKuSz47sImHfHbIC3qb vP10yaZELXucMUYA7/hIPOxZsLGYNCW5qtfHn02yVNcRnUFVv5qwoTqV4OJPhxyD7MBKM9mx bGejIyAQkyqjTIBATCqiSc9RJkbQIY2ahIJej4nyzxOiy88p4uMMpCkpsYh6W0CNIUTQJuAa kbnbY0IE4ts9hjL3Uh4Q6NA3GBLh1bI4IRpp9YoQaEwG8VbZJkPjku+uViRE0rTPScIGQ4JX +CBW8l0TU2ASpZl9ntS014kGIpRIjnmva2cu+mCQnuMKo0ByOY2H6w8MbRBqcBfy/Lj01oyE Ese261NSv5v3h3TDX88j+GM49MEDBWhHkjunTmgmW63qxHiQPBiA6N09sJ4tqbGJFQ/FtANq 1KaD/muapngkybQgMcPsmG6zlb0xWdKiLUrLJLAOOJN0e281+QjsiF1+dCu3ZvFuCbGhBdjQ xCt89JHbc3o5u6ibEd6/f5TMicQyHSlj2rsWGDeZs+MqAubIxSu9eVx4C5ucSPwkt40NKIlx r0ecOwrlOkOR8a+LE2Q/ojBYuHDUOy7lwvvPFEIkSxZQFx8NsWT14qULjnLpkZEMHuESBqnL hbhCTH95SIlv6Xg/Sg36Koqv5cm2abEEI0429GzaK/hDjAyBpbO8iAePszenFIEJmaqRzRY1 krHBn3mBTBWnmwIEZDNPnI3RHakcC4RBgDHFmWq8bt1vJN8h1dWTd6o0CVTFaR7kxE6bRj46 DsFSB6A0oNYTp7omE5YJQyonPg2GTJsOhlIEfUjoDUaN3ec0ArsTxBSAAqER9GeRRs14Lzyn I4kWiAz6pKlO6IAt/XQvLsmh4z064mQbBGdDFKPComji1S2Ica6YBZifEAocg8vcYcai0uEL 6UKsRh4EZksu+e5A36REI9MOPEUVIABhgfgcAg5TEFBdm6BxbOovAgR9MFPObFqkpNdpJAzq JvVYkTOBnJM+qOWTTXxUpS5VqUgGDrN8YAemWzBbMrnZC95oKNWCZTN12RBWPIYA2OyIZQCA KvTaYZKAyXcTNEJY88TzRqvHOIaQ5vQZMkBjgE2ITRlk3iSS8EAjYNwqYwHs1BQLEYgENJC9 mk3mRvHqQodqRyREwkKryUgFgbomiw1up0CNEH+apCkETxsaQUgjyjRIeU9sSDqAcOsHNpTA WoJOIwFYqwCB4TLvt0hTcHCY+JvcRLwtdud4Ys1FwDaEWYt5Y7yCIQ4oFgE3YJ3GY+5skUUH mMN7Go0WopCms/40jhpQL7gzMOKKA4oBkYD0F+9PdHMRSaWSELFAGlkm53uk7z4p73FLEi1b 7M4mcyZwbVhPActQuaUpQ+wLLoyKBosETY2ZsgG6cKg9imQAfRCzsdrMEnvcIA/BRbKGAvkB DF6wehIT7zA3j+OVmAXIRPqEkRb5hMUxoMNuMQPTxQjA9+IrChJ1US8FQwJfsMS+0OJTC5MZ VafD4kF8/EgcE534Lwcy49G4JUrwTDB3qyWOByCyPrNHAxoRClrEJiCT08SG1HGYIQHxkNzE y2IgA/CLIjuALKgZ7+4kLEC07rDansSZYED1aMigi5BwoxzIAGgyxEG132R8gwMZIA9CR5PQ ASFeYolg821oBEoDNC6z0DjEi7UAzut4TJkgOIc0hT8P2ekXeGOHW/qEQQ2EaKiMe1CyK6YA Rt44CzJZPGiB4MAOCDLJ4OpxK5oADq4D9tFSmWvrkpGJywxit4XoBPYP2gH/FCdZIH8dLABi IpebQJiFdWVJrmxyLECiD2hiEzKYknHUEo0LhO9+ixkSP8lQQb0tKlwRC5ALJX3QJBdCDIQS SD9ciTcazHBV7vVA3+FKVEqTfM7ED6sqIxsCW69NEUtz5SYnf5CEwxkVBLy+WAYQj03SH/yt yXjS1WcC7XgFCCxuxhjfKgmqg2kAICYCbYpZ6HmsbwOyEi5vA9as5A2A1JlgMHHi1ZdGUt7i Ui2JKYPFxQkGN0aAcGEKEo8XYhnA9M7hXg9Avgp0gDe2weHEFEB+ADlS7AXJ9IIm+h64l9gX oBEEVTAeSDMgZ4QoaSW5k8gbYabM5coex07sI0QSPYkd9JgC4+BiMr5BEvD6qCMemcDjwdbi jNShWkfUuFSB4HCikYmLfZCt9AnxnSS55FmTBhSwx/+2d229bSPJ+v38CiNPE0CY5U0XP0qk GGvHGmtNZzJYLBB4EyVjbMbOsZ09CRb73w+b1SSbVFVfyKZEWWxgPI7ZLFZXV3916Ru4Wj7f rJz9HfoIEBpvwlJIdUyzdi+FgA88aTA7Ht4LYng998qxABoKbgboI2EbpyCy7NuxwPa54FpA nXPctPmCewvegCv47FMB8CbEdKEAYHA1xVJAYrBVEFvGOCaOBZlzAwJ9L/AEGZYFYdpgBE5L vQNo9YXs2rLINWF6MCnhA1SIQ8y8VCQPkBHvRkCh2CvbPRPcbPAeIFnl40EXOJqRXyoSyAC6 FLxF8B+JNBB3IWKhIXH5E5AKmjbFe4FnjQQC06DUQd6l81y1FJjIM0gweCf5V4vMBq5IsZg9 nJbaAD5SLLjfIZESBds/Lfsb4mjYuA1PwZOOcQKg+Y4waMA2AgFwPMrgj7SN3K2clQMLcBqC Yehewj9YFMnGPNyNMj3gt25DyJn9jHE94EdbZt8DNwNwGjAKujEO8maSgAIDdlwIC7yBXJ3A yBOQBpKH0GYsGLhACPj8IqODcTApe90XImVAIfDWwUJOZQsYYCyMBRTip11A70Bmj/ATZ2W7 uZsBDQELmQkXguEJkdleCtoOIa6QYYQIGtBihnfjEr6XtRUyVvBSIBh88BZdPOCAFvMQC8J8 wTJxOwkc4KoMQwc8Y3AnuKlZlAgBsiHGwkxQGPgJKy6AbZ7l83NdwRBpXo5GvvID8spiAAa2 SpbVhREPGQzw0kTxAaQRQZcouKWQUY4AJ4TVQETcCJjjgWWKS2LQmaDigJKUkxXsSBuC/Ump DfA74eLAUiFIcoDGhYKZg9HIE2JEMg4kPyu7yxWc/qkQM8W4h8IH72JHGwThgvEhEpKO4MgB CgGwcbMPo6AIfLBc2qSUAUSJSyEMjhfl73OcAMA3eKceZJSFuR4wcDBVMMMTUTAWwB+ESB6s 1BwMKgxzcHuJ4Dv7Hrib4DPOhEmy5bx8OsYjV56pyJgHXxm4mQgpCb4uisgrAwEYdSCPWdkL pY9K5lRB/j4MYXD5wGv1867LGxITcyyQoXFKDYB01EyYX4CfMZFDAQM+LVnlUDIrxySfh8GD LjDsY8GgjoXRCJgNloJw8xwhm83Du/Nc5rnDuywI0zHTvNTBuYCGYPIAM4hu5Im2cdlimBjg 6djzUtEJRIKJCGgIGDXuuQsTBvCRKS6DGAxLVL4KU3YwLs5hcd95rpukaYPcLvfPYIADBgga OiV8pHn5Pe6VZ40SY3geu8myuqA8cyEIBTsJEDOOc2LYLA+4OKCP0F1Toe/BuQHQx3thIUxP cmw4F8YkOH5+3hdYJgugSyDA04EwDgXXn4B1AHGeNQXfJCzZht/5NC4+Gr0iHsrNCLwK6stj 1uynT2SyohIPYNhGwuQZX3AL4wLvRvDMoO8BxEFtAJthgIPtIGzjUogIuGsHE4hCbpEHRMQ6 1WUuoNzIh0Jmb1IMI3KeySnUNDfpwAHYyQk/sSrvI4wAjHshw85zGmDmIKsY5wqNeetB+b05 mBfBwHlCntHHNZFPkPolfCxFWyBYJirwXORKkgc4MOMJxi4WHI9zvAnANkgbsBmilyk/uTUj kDVkTETvQtTmCK4WX1oBfBR+FEZASEJC0k0MQvkZuV6uJdhYACaFNNBUWOo8EZyeiBiNBVwV ZIQBDl0KujnFhQhGo5zHqcbwC775KOMDJ8DnnadlLwCBSREj5KOUCP9BcDAWuGGBpFSxbCLn 5hwfTJx5IZcMQ2cMXhq4OMscYsiZrnMxiwnVhaENhpYI+1xhvtETPGOemAOcBv6IkAfwOC4F 53jl73zSUJYSBdvIFzCABkBnRiXEQFeHOKCAJYQICdJfrmAPIS3JE7RERlOY63SE8Af8RLGB kXTyHvyief6lqirzKUWiG4WcDfQC+EuiDs6K5DDWjVkfg78KKXAIBAMx01ngEt2NAgc8n7Uo waXUCWwwwTfAQ4QMhlcqse+WUiFQORTm2gDEZ2KCXEgTElkccW6Pr4qBfhHgHsYCsZAFXh0L q05CYS2OJ5IhVgNNhF4HjzkqBQeihPzSGNcD7u7DBDrMaIHDOy3/Du43IQPA/6WQhOQ7W5xS lfl8HD6cp4IBh9kcmN0KBO+ZO0DECslFiUU8LSbMto6FaWMfx0RYd8EHMmRSxK1QYK+DvFGk t84XMsIseFDKgKfJQdFxGcyFgA9yOQBg8BIkTCGLMMNlMC4c6cK8OOVL4K3PiqWeWBMgrw8h v5BB5SG4kOclZjzHhQ+Y4zHE8FPB4IBtjAlEAjCLK4+EjUXYzltht3Pt3DNxY+083Kwcx/Hx jbWb8BI9NQEnzArbRI00AQ6mxP7sUm1ipdz3nVyPmp4bkB/fypdKSxao75y8Zvfwg+Rmbt6I /EOs++nd9cWv0HGLVbypdlxU3YlWXKWxkh59UNvxjewfKO5nrV/WQhyDgO0jqO8fWN1/ZBvD oRFO9aRcnfr1A/NU9eun3anq169QUNWvn2ynqj82rF8/5kFVf2pYv35PQll/jNY/N6w/N6y/ MKwf1usje1DyYcZekuIqQzIdZF3ePd2u0hH2avPrxgmd+avXKMLmRxfghx/s4K+rg79aiNoI jPBr7Igbhahn+OakEudcZGeWZPMYBox4kzOwa4q/6cu8BzQ/Rt92TX9MfqiMs3PEZeUZsv2J 2rXFrUTCjLKoXsHufuWMDAEQCZw2vQPQOu/U5ajzDnZQvuqdOlhzsaCb0Iq+Tm40TfriZmP7 6KBdL6vyDO1l3zM+cggRAepQCLhHH+PdHPe848O94kbGk8K9+tjrD+6hzxS457bEPbcB7rkN cM9tgHtuG9zT291+ANzDNaB73LtcRQ1gL6rDXnl2+Ep6EvruVzKuq5FsoIxkDcLTHHKv31XH hMYmZhfP3Dm+FhJvknfmOpS+JJzQITnxe6cj2fUSDXoyJAyYTXkF+5KXzoUiubySZvJaivJC yK4XTdwI1yx8Eo7WTMxHGzvMHcMOdpB3fu2JU2yud87jEDv2pF4b6kFCgLqElbrijYXgug5F flrm1fWl8jSGgse8LSE7UdboDI8dEksgkf3uOeiJMDmL6+Vaft5lcf6veG6aM12G2D1LOxxx wbOTTWT1y0NPNV8QPyC+B4zRpnq9Xkibu0PXEfnRYFwlGaP7Q1nRvEOUFVwZRe0QOZ0RTUIU TDwEOuYFJk4Wjlxb66fZStK5VS1Wk67qWLwMHUHrXbxt9XeWJu8AX8vIU4+unXeCcfnOeKHD Wzyf5d8JdOoHjmNaP+D18TOjduuPDetPDOvPTPh3yvY6vO3oO2OZt82unTDxX8KVeeJxzmZ2 UMs5j6758Lfl3Tj4oklnrOXdrH5dtfWLpbdZsiKE8VePeXfy32BOPTvFCX+ZvLWyehVirbpD 3J6ZVandoJmJhwi4bDsynmCzXUJ7faFOGCO3MrNLROAuA75cJv8/nxiVUI04OvnEt/nR/KkC 6+BdXjtSI2pmFEQrr/RC6mak6h8oNaVuZpEgd8fM+oZmdofFmYJFlZ0tAK52mQIhfFUtLvQ6 Lut4fiI6W2dGBH1NZgpTb5cZxIPQZSjSZAi7jjEvpPem0QREl4pWRWWrAoMWeT1ukeiBzZRe YsDfCvK3xnhEVG3/vBMV23U4NTuk5g63ZaiJY1T5Z5lLULolJjkFoT4xPVHWyOzx9fbp4dvj h+3N9s+vX26ft1ijcD1cXZ39FG0/PHzcupMRWoMV1lFsk55Y/vIX1qGPLENwfXufemfru/u7 P7/92ZLI7XcVkRqJCpH5l7vP9+zQchkBV0Lgcnv/+fkP8m08e6EvxIUNIaqJvGwhsqWAxJf1 hagmohSi67QVoqwXOhbi3IYQ1USOUojXf/v1If5y+/mJOiCWlf84u2fgZm/rdkEQWegCDSJH 2QWaQgTnnfiyrhB1iOxBiJMDCnFmQ4hKImqzNGsrRBkBYyEiM/EmeRBW5GstUiKY01/9F+Fx KldAt/Q4kfTAXj3OOLAwtHWIqLVS5uvoaCWbJyAJdGznZxMLdl5N5GV7nOxQQeLLBm67kkj3 mng4Iab2ob0m6hDZgyYe0t2Z2xCikkj3mjiW+UsdC3Fiw2dUE+neZ6wHsfsU4syGENVEuhdi cEAhhjaEqCbysjWxznwjIaqJvGQhpgPxvL2Lo0Hk2FycHoeAq2S+0IwBizUWboxPRu9c27tZ XbOl6eHqffhw/+nuM3t9wufP9F73dl6fab8eR6uk/nq8c71xXSCbxFvrip8MjmN3Z6FK9R3t 8Jf+OCt6ScaMhuvhmUZEN1kx1U85n1I9zbhAtJfsol8WYese8neXElXfsdVDWtjJChtZrX1K fUIKDAVCLY0R56YFlrJCK7ahcANbwlUS0hKuE7wk4badk9QnpCfcdvE5J9IX4bZNeugT0hOu bJahB8I1sIovxihe37Q3igvHkRvF65v928SpLZuoJrRHm9gi+8eKFeWf4cqfUTHrIlvgrya0 R/BvMZXKCjGm94ks1zcWgOVmfd0aWFwVsNys9w8s9ZRdY61VE9ojsMicyn0BCxFqZlSMuqie 32/cRWpCx95FewWWGyRFkjFhAizJ5pf2yDJTIcth4njXlsOuJKRnENvlQzWI7DMaajuPrk/o BIU7tiVcJaETFO7UlnCVhI5duEcYga8XyKyEoTkjVtUJ7+Qr65BvlbUOYvTYNWliaazdakJ7 jAK7C9RNhBu2XiihT2h/nrDfYqqaFVvCbb2AQp/Q/oTbZkUKK7aMXmALFtSETg4WzluvWtEn tD/NlRLZo3BbbxHTJ3Rywg0XoSXMVRPa42xsd9k3I82tG9bGmqsmtD/NbbPYl5UXE2hsVu2n +pxe5s08W0s01IT2CAr98BUcr+3+PH1CJyhcS+ZMg9DpCdeWOdMgdILCtYW5akInKFxbmKsm dILCtYW5akKnJ9y5LVhQEzpB4dqCBTWhExSuLVhQEzo94S5suWJqQicoXFuYqyZ0gsK1hblq QicoXFuY26tsbifCPcKE43oetU44entKOEbreUrr4c+vt893/7z7cvf8Y3S2+Pa0vn163j6O zm4eb++fPm0fkdOcK/QDW0tYW58/pE/o5CaR2h8foU9oj+uDO9l4wIqhcG2tVlMT2uNqtfN+ CNfWkpP253YAISua2+boCVZsCdfWqoj253kAoReFuee2hKsm9CL245kJ19badjWhPWJuNPjR mR8dXm3a73gJnaCHM/exLVRQE3oRkGuwRd1/MXvULzZLZEeq8V5Sxckt78P8GkUnjJwAubKh rLt4y/St/WBZb/98ePzhe/Hd923K6PX29uPV/ZcfqnFTXimSF0HBFrdPW42o0AmI9ztDVo1L p/MigRfJBZHs4ip6VNA0c7oXm/lSMaqkT1mhL6auFzpTgAwFhDxxmyXxcjfjm40DCwP87fxa +/IacoCPlXtgln9N33n1D3ZL+vuf2U1y7Mfy5zdR+MurfeguvxIrZfZv/Do5+nqYvFTuMCbq qbo8O9CsLfMp1xF1B7UOE1b1LmXmDXohuy43GxvcNLEFcoqsJM+3j8/R9uv2/mPqasT3wi2u Ej1R02Ul9R/Oflp+/Lwdnc0/PN/9e3tx9/mP0Vnyx+0j1fydj/ijYDQZUefCVb6m7QrmJW2j H9uYcDEjqOEaCgTb3RNgQEzDEuelqalh5cQVzrOtcBoEB4U7YYXzl7YRTk1wULgTVjjPtsJp EDxthVvef6yoG02LCJpZ0QmyFFEL83Ld9o5/kl8OPX/8bCPeW11H81bxXrIOY8clVwZ0G7b5 kmuS81IJ2xr2nt2wDblSSYeJbsI27FJnCTfFfexWMtR1a/Drw+bxrnm8pp+TzWhJVohk1IwA 3qo3YdWTsAbqdgBd3jHGQvesnC7KibW/JkwgdjxCx1ZcpShjvuiKlf+4I29EzHiwQj8Z0KAN sZeomAMamBHqIRocHxDohYDmqmktuWU1sXVUqjnggRmhHuLBkXoHHYGCvSkWq9MrR6WfAyiY ERpAgSw9AYUhchhAoSR2PEIfQKHD8MEmKNibNToq/RxAwYzQAApk6QcoDOHDAAoCseMR+pBj HHKMPVXNAQ/MCA14gJV+4MGQSRjwQCB2PEIf8GBIIvRUNQc8MCM04AFW+oEHg39wADywc6CY PrEDCL3lqQus9B0P9PYVKDfiW90W4FvbFrAMN613gQdHtwvcPcpd4A2Z6GY7gfuCthPsC2RY aeAPjEdT2+7A1KY7oCY2uAMpR1ObQtcgdgCht7xTjRXJtr3jhAPFRCYrhpgwoMGABsbEBjTo BRocgXPg2dRMDWIDHKQcTWwKXYPYAAe9gAP7zsGACQMmNCQ2YEIvMOEI4MC3comMPjF9zWx/ mYwGoQNFDDaFrkHspQn9SOHgWFyEARMGTBCIHYfQjxQTrMLBkE08/lBhyCYOOLBTDosDQ8pg SBkIxAYcqJTTwYEhLhjiAoHYcQj9uJYDutaWA95s1q2WAy7CteM6nt6tT7701ifLKwB/dx0Z +iW/+04mS8ltRCkNV0oDVhkmvwdedjuS6sDilJ4no9fiQGOr18shN2a9e7x73mpcmRW0vTJr TL2/v5sew4WlC/M0CO3xGs2wHX42w7193XQn5yJK1qOzwMataMv//Xb7JYXNh8W3T6mvdvZT hsPsGnP4Z3ZBmtrlUtZgxfk+nzDYjBkcfo8AQrOf7iL7PXu6CNjPYDk60yWaveBlP2dAzhlx j935fg5/yUiPfSXJ/za+DI6bhpv36cf/vn18kEuNQ+3Nw+r+efuZC57d7cUIKHwpod/gcwxp JHyreWeluDmg6HnVPRd6dFlJ+zbWEL20iuLyhC8KNNa4lAOTK7VK3Iw0K7l8X7k/O8SeAbGo r/VQNlmfN7Tp1DVpzT7BSu5frFdMvcJz9pnpUsPRqJf5/cfcq8hYjc1JXD2WFKqjUOeqBkXL 5gUFc1K5nqgxJC9qVWFFS11Y0e9PVG2oaxrafYoVa+rDigUVYgVBTeKuQ6qYyYAV2LaW/5zw 343IKLC2UlW7praGsWLWbFTTAgNNM/8kK8LNqYa9qi81Vowkx4p5U1AJjg0l2OzTrFgduwXR P+4+PV/fff7juTKUg5ZUMVZjjQ13slLCjQv02pFDYIe4q0dVmnUnKzgMCX9xGwBTXgwAqnjF +A3jYcdKM4Ghw2/SYPg1Z4GVIkhJ++aVhhdKlSJ8SZ4f7+4/g980Oru63z5BDNNQr1mpiYpx ur2nEnI6pbm4WDH3x7Birpx5aaSkebHT9LRb993yZm81llVzOTULm+3zwUpjtGWlAeJmr3WM 0/q19Wqqa8lryE5g6FOqbZnlvcZBaZv9aZYJ89nPMMy8kHGWaptop9rOM0Ju9nKQkRtnibUo +z32st+zT46jfaTavLapNoVXXzNF3lGk2hz32FJtnuVUGyOfJXK6zV8tONtmrvzBsjUo944x 90bJTl3SHWCu2SCTi1FqWInBZDRtHbedt2bH2ITKY2zewrx1GvejtYYZ6wyYFDTkqiKkjCQ0 NPSW5SQbTJnHw5w5UYY585cwZx5LJs3lf6kNm5y9t+E6BUVfyt4uWxS4FaCGjF14hi90Kp4h Nqp4hnirFECWwOhIgZECRNnSHUqQm+Td6MwzFGT+IdYN4o3x2c+6S0h++drGl139L+d2+22y cFTf4bZ3Hl2Dx+VGDON2RV6Ml6w16vGCjxXe8UwkYISqbh5hk0SHXMikU3N5Gses3X74120K boqpE6Xb5StiU1bF3DMzkQEVlvRKBnTIZyYDA9ZpthUsk840wirCZjlMGNyol6DifDKwAizm 48PEW794Wx/19Ifqox8XZk45vKBq0OKufcHskEXhw8SL2h8m9MTQLAvI6jZCVqQZXSKre6zI GgzIqiODviGrjOU+IisyHOXIirxgB1mp7HrnyOr2Dlm9RsiKsNElsnrHiqzhgKw6MugbsspY 7iOyIm2UIyvygh1k9Q6FrF7vkNVvhKzITFWXyKpa4dxbZFVtCjkFZNWQQd+QVcZyH5EVGY5y ZEVesIOs/qGQ1e8IWYWa5ndqNITl5UW4agTL0102eL3EjahW5jV8skaX0D49VmiPBmjXkUHf oF3Gch+hHRnScmhHXhgSvc0+3DoBQyzo6j4BEzSNT9q2mFio031gNGnqN7RtMTLe9D7ctsWS Y4r25bAkHx6+ph9iH5D5K7W3gLvNKkwRToBzVxmKitiPaDguucw5ilkhkB9cEfQRaxgI7vLX X6h0C2o1/ptW3h//rg7/i/7y7x25/KnZ4wr/lOexD/6XFvR/3l/+e6//Cv57r/8K/nuv/5EF /aeSQj3gX0v/Ze0/MP9a+v+mv/xr6f/FAfkPjxz/Ffz3Hv8V/Pce/xX89x7/Fxb0/4D46XjH PX7Bgd4r/5W/1PJ3EIDON6veB6DSR+6hwx4KduVc72aE+xFsyrn2Dsw1BbFyrndnIPoRWB5Y rxuGkwfW64ZB5IH1umHoeGC9bhgwyrkODsx1M70eH5jrZno9OTDXzfR6emBHvqd43TD8OzBe Nwz6DozXDUO9A+N1wwDvsMjXNKw77GhsGswZc135Sy2EE5Yk3aiWJCGboWEpEkSA1OqjbNVN SvbspzebVYistZEuc4LpTYo2MjtssIE5vtt++QjTrhAdr5J5+tvqOgXCxY/n7fzDByaQlNK/ 0gD3cfu0ffz3Vhnbrq7nbLP9DOmj9NlC8iyUPIuyZ41a47VrzVLCVSx59kby7ELZmnyCnyUs NNfwYQejxNjBKLVDUZAFBLzGRvdIDVyFV9d/Sxuw/ff2y+hs/uH57t/by4f/G50lf9w+Uucg ZMTOR64zcl1kEYFkTaHm0S2KwXY9ly8jrJ2ePJOMzUwC6Iq7GXWSlnrFXdpd543Wu6UvLrTw o7xrYaV1ekVLgYrHkavlycnmLzDyZo3SPJJDttJt8Zbd49D+oJmGoyMjih8MRayEDB+3KYPv Hh4/coiEFoDDi0qQlcZDQnGgeDYkLtm5K+1GxM455rTIeFOgwaqTubKzlS+3n/KjlfNXHI1X Be2UiVYxVFn3mGm15qVUuDB31KPcwsra8DeiEfHd/cdkm0lqcZcKi9WU93y0/fC4ZYf1yI+a 0hzjEtkItlO6noyVlraTXgd/INuJXg++B7u5GOymXbupEGhbu2nYKDt2c3H0dnNRAiMiQVYa D4nBbhZ2kxCt2m4aanWndpNoBGI3FYrS2G6i0pDIRrCbYcd2E9nRcLoxZzjYTru2UyHQtrYz NGuUHdsZHr3tDEtwRCTISuMhMdjOwnYSolXbTkOt7tR2Eo1AbKdCURrbTlQaEtkItjPq2HYi sywHjzlHh7Sf0WA/7dpPhUDb2s/IrFF27Gd09PYzKgESkSArjYfEYD8L+0mIVm0/DbW6U/tJ NAKxnwpFaWw/UWlIZCPYz9q1CNbtJ7K3/LD20x8Fo/FoUlrRkeuN3GDkjg9iTpeDObVrThUC bWtOkWtEujeny6M3p8sSL4mLWBoPicGcFuaUEK3anBpqdafmlGgEYk4VitLYnKLSkMhGMKc1 rbBuTpETUwZzKmCHAgwGc6rHs7ZA25pTBEW7N6fx0ZvTuMRLwg41HhKDOS3MqdnNaII5NdTq Ts0p0QjEnCp6vrE5RaUhkY1gTt90bE7pszcHc/oTLKsezKlNc6oQaFtz+sasUXbM6ZujN6dv SrxEJMhK4yExmNPCnBKiVZtTQ63u1JwSjUDMqUJRGptTVBoS2Qjm9KJjc4qcbjmYUwE7LgZz atecKgTa1pxemDXKjjm9OHpzelHiJSJBVhoPicGcFuaUEK3anBpqdafmlGgEYk4VitLYnKLS kMgmN6eraGl+KW+MX3B29XX7ePt893B/vf2c/kwHRsh80k24eh8+3H+6+zziG7GZ3LAj3blw 4bWIiVtjAy7Oc8bPp09P22em1AG70xetc7OJHbaxljrH4Sbbpy17vlE8jxTPY1fxfcXzjeJ5 pHjONrGfnVEnQrAie57yl8if31wr+FtKnyeK/kkU/ZMo+idR9E+i6J9E0T+Jon8SRf8kLfsn UfRPouifRN4/qfpI6W9WV9LnieL9RPG+MMZn1BhPQrkOpM+lfZCEieL9RPq+wOOc4nET3jht +jl939WU04KWUzseEn0eQoqHss44oGW1kPZH+lzRn/L3E8X7rEj7Yh1Kx9QmkT/P6VPX18ab UMp/+lzKf5wo3k/k72+S1RupHiieC32MhNqIEwcOyJubdQqFi2+fPm0fszMzDY6Ogakm3Z9d EkmD99IL4j91gnhwQSPBBwV5AJUUZhF/SvJOqlvRem72ziz7DuLcS94Js+8YveOm7VnFl0iC KHfm05qr1nH31f32iRLcTjVcVhg1IvapU5NXkwlBEuS8TQmPzvyGcmFRJ4trmuddsBFJsCx8 0PgyGjFjlL7v8V31kgSaNFNQ8u8Te0igDdST5ZenbetPj4kjE+hP438lmaEZWX/78nz39cuP s5+Sb/98frz98AwHc43OmHBfZ0NSsUZJbIusHnbHD6nN6WBaj5gRaTPKWTJQkS8rGp2H0xDc G7/jyt8pxVxmZFRyVclUIr0UIzfNMZIhLJWuE4cfhG/MBjVO1zLYN4INlg4Fl54BJAWTrAh5 KojjhfSWRq7VgDyEEHCyYgfkIQsARyBaI58nL6/W2QfSMIslA15r2ER4B0I/FuC9llk+pi6s u0z1I7+zM7VpZz+BywuOPwuVXstMsjVkZKyzBE5Ty1KKy5HxS/MsMZxM49qK1B3xWIlFj69l foltkUoyxLoidWX80jwrEss4GslxtsV0iTbOJofC2cQQqZKOcTbpFGeTrnE2S8expJ4+zkKK LNHD2aQlzmapAUiQJPvF2aSvOJu0xNksmwI5pWS/OJu8IJxtt3hBmOLXW9Waz49trle639C7 1Ni0PfT31O0i2lZhI+0Ie2ywoCM1Z0ac5JJezxPCPtHf1RN5WfPNTbwRU4jUDbryr7ICGRqw FPV0Hvs5z34uY3rU0F8W+ibW7Rs1x3xEJ8zhcL5PJ1xi6sCeFcNr4PU4YqXUnHgjp0UnYFiR JmHMWJErkpwV3VSNBHGSZYh8XgtyCJB+6ZCT9Bly3l+vf1PVLCSz/Kujs0hFzSUrfKSfO9Si RrHoKT8hz0obDJRMow0V0Jo1AC2NekbQIFlDxYpEQjVCDZxU+V+IFT7zv88vjVf4LBwHY7BY BvuucnsdthiIvMRhLLngY7eFr7Wa+GZj2kK2AIlu4WaV5UaEFiLQirdQcbcF/SIrbOaQnDuE CuRFFqxoXVqY09FVMkpI8ywpeXxCUj5GLgRhxWyttcblIKxIJy9AwsqVorKLQuhvCN8BdZdP 3EjDKoP5iXzM/rZCjnuxElhFV1orPenvsZL3QDYVtF4lhJZmVbmdXcoqqnyi6Cpq7xNVreUk 0raWDdx7vYlNjYGuR5AVjtuudPjWKnsmlV3XhDIBE3mRBHidziUfm8ix626oyp5lkSvig5vf TEdgMZ4BrCx5wYLX6LV1z6NQa7pCj7Gaew5TFIGme66zYEC7VW86a9X5+eFalWhbMnWrUmLC ug5bKfJ8qITXxpF052MF3WOgaE+Fse7Hivcix8pBWtXFWPE6GSuXIXHW4r7HSmN/kZXOU8KM mNs4E8uK3aRw6qo0Twv3AWzcFwk2B2lVF2DjdgI20W/IBKacqRMFG69XYOO1mIPqA9jMXiTY HKRVXYDNrCnYyP9CJOh3kn0aCXoPT9CbpvnkCVZFek+Z2pMeDqGX0pMvWGmZKdfI3mhlbXil QKeST00tGOWHsdwL3tIm5kprepvMtSiTufroqpvMNcit6G3EULRAH0l1W2CQR7HSAn3UpFug lTMxWt2B5kn2rNdkXuRweq2TMei3Xu+tBTb1WprfMNJrNKexZ70O+qfXOsFpv/V6by2wqdfS UNpIr9Hwec967fdPr3XioH7r9d5aYFOvpVFb89istnxLMzhDVvu0D872GlA5r8/+g0YlEo6K jQHhSvfSoXJZ3bK7ZXULelldsNtCiofNKlyOVMuzOlnTxRTK4uK3qNHit/SlLtpmsV1hn9qV 9tns4AsWD9o22RE++16MebQDV70gc3dhMCv9HK7q1ng9VOROFsz2dmge1RJgxRkh1pYAK75j fwlweI1t+dVbA0yt32el6IDVr1rHRNFfZSUPG8Y8fWkiHM514uazndJaPtTyTYWoveweFSJy tSUr3QiRvI2aaKXAdZdCfBOFvxgKETlc3h1jh8uzYncHXnZuFjvaeb1Kxi0Xatei+2l1Vh4J QOqM6NRTz3yn8rj79OPsp9JnYvHVz6xfVJvn8mJn+6YKJwlBqdbWK+poL2mU7D6T8K4WjSqL AVcjtAWB312HOuwEnvtOxiQBSWWdq2QVkZs++adc6ad4b/4eeGk1dSem9DwZPRuZokX0q/Vs naGadrEFJCUSzpx5KFtdI9Fdgi8bx/05kX2+fBt8LVvw1X6sG2xCbqCHqc2SHLrApCqvobXn eT7hSqJTOcgnOqSV392yE/yXf72J4HgHlZGpEj9cX/oW+rIiVImcbPAbHBW/mX/Sll/5wavy d1nJB1mko8fluZiw8klia4Xq6DiWDK9OdrhV26kaf7V2qrBAvP9ELha9Aat9wJNs8jH8JWkc 283oAJnXXf41leSrfzCf+33N6X7VcFbkelNvuMasSIhzunudiMvmM82vE8lem9//qFwm8u7x 7nk7f/r79vHhSVfG5cHl/pI6nJ4Vdvj5hDocfZFID38XDkf3VN9wfaLCZQK3Kmh8hLyRYL6Q 34qQM0Gegh/JT5FXv697q8KYvNHgcp6EejQm5A0xQh2yQzaKWz5KGhF58wErjIZPZSYvNqG0 Uzdr+fOSiSXZEKGOT9V59/s6uxJkN40tO0ftd+wYvab7/ck7AtrNoZ63OJqEFTuZX+YO/CPL 5Rr6EYY7wOXG1vI2ckW+vqyovXlcq5pqjz41Q5GXg0lBhppCNU0puEcqBdlNNEI1TSng8255 6a8UKCtfq6YpBXwuNS+S3KiuQ8tKgxNLTwe9tBcGiHSPVHd1cKwiD2odU43uscpDB9G0F/wI dI9VHjrYpr2wS6CrkEd7lNMNh43XVmbhMOIr74bDXrNw2BvCYfojsnDYaxkOt3w/kb7fs3BY k9cTDoe1A9M+hsNaS4qHcJgohwuHjzUQtBsOH2sgaDccVgSCvZWC3XC4c0eRlSEclpRTCv+M w+EXHv4Zh8N2wr/eysM4HLaTPuo4HAZn9PIiusQ8WHiaXF5upK7qrqCd79kct4OiTPmwylmV aOmP1y8o1AzUEX+6h25v42ugem04rDl8vTLyL7OvOjBqNkCLDNB/xQZe0/hcqKUTkNOfYkUS mPPHY7z58q0JSbiOdG5bljOnu8RbtrgV6sgXxBV1JKPlCNeAX17eLOytAU97NF/RprkInL9Z XG15/3H7PTfNDn35KPZRz9ZHZSvQd3Lil1ebdBQmP56et3+ut38+PP4YpUP6cfvpKjWnSHMk T9Pvaq6WL/2aptB9+XD7MWeekTNdWKlapmplD1e50fDycvv0VOzCGGVhtExaisanSi8bV1ZP Irze1G2jpqOHbCjbnZEJms3IBMOMDP0R2YxM0HJGpuX7ifT9ns3IaPJ6wjMy2icmGF5IBDcA Wjy/r4V/OyyTPKHM6sufC7A7L3SsWUO780LHOkdod17omFJGLxO9Tinvbzwv9MKXjRrPC73w eUPjeaH+pFir/6KC8nGjoBzpg92gfNwsKB8PQTn9EVlQPm4ZlLd8P5G+37OgXJPXEw7KkY3Y x7NMcgiH6dLncPhY3YRh1+Cwa5BXHHYNmhFipdfodUrh37BrsFJx2DVYrfjydw1OGoXDiK+8 Gw5PmoXDkyEcpj8iC4cnLcPhlu8n0vd7Fg5r8nrC4fBkCIe1GBnC4SEQHHYNDrsG84rDrkEz Qqz0Gr1OKfwbdg1WKg67BqsVX+iuwdwRfPfLxUblCCIB8s6NEmzpN+YLE5/dXDX5rLgxoNgF gR1WT7utl9ndHjmR601UbqWoNMb7mQUzxhf+ZJ5xlQ4LRpoaCYQcCxjbqv+7P+6+bHcos7hf TlmPOivJl+32a9ZJczVJyZnPO/QmirHPiqgmdellaQfFdpK8aDZVsSurWpfv0NJoBact3WVV qyvdQVWpm4vTV5zczYpO94gHfBsrrIoCO92pHYVsLGvpzc6nVWebs6KnKChoerJF7mKhDYL8 aSeHxaOSUnWSWkp9UILmvSTvIam0WWknHnXjTFVE5VCwgjYKb0hpEdyYQD9Eq+hmKbbSaZv5 TK+a2ud2CtuuP5spajd3RzRuiL7q6TmDQTtnMMC1JLDkDAZ2ncGgM2cwOAFnMBicQV53b86g jsKqKLCNpe0oNHQG2aexXYz10sIZRCNorPTbGdTppDbezv6UoHkvHdAZ1GncETqDsmYZOoOk mc/0yr4zqKOw7fqzmaLu2RlUNcTKWRTJh4evu+7M7gZ0ctWPcHEXEFhehKufL94upj+HF45T u7xL9fXqy01ZKNpg+PW3ycJhX3cO8nWd40DKy/6S9egsaLEgIR/f7Gyj0dni26dP20fVaUg0 RbE436NsDZefXdAXZpdOLrO7ocd+9vfs9ym7fPp7oDcbcp4dG+RmBJfFi+lfMuJhRjaAn5Ec yBtFJYKsPKUHLBdQPilaClx1SaKOwD3FqggZiJi1fGzjTllJi43OFNIXpvQIM3xqCRFaHUmr v3Em83ENr5cf5kdLJtFNdT2T4OBXuXwVbt46q+Tm7FVtjKRDKF7OPCeuL0lkbWHnQM7qDxgp V0LKn9ZnaTkphx1Ls8tVSJJyl/P6BDgn5YYoVzQpz5nWJ5tzrmblsXJCN4GEw/gNv3zU9YPz 2K0//0fqXGT4lJ/JiVVwpRXSPqycHlrr+feb65+ZlHANuFg5dUeDPwh3HpTrz6JQdrdrVXHC x+3t8zZ69/D4ka+YBZCH1QzXy99qToWkftr7yervtRxMfrxaysNVfl0sfrRaXvPbP58fbz88 V26nnuXvuBg3NUYCdnHqty/Pd1+//OBU3ILKzXK9qdLgY+0mqZg2tXktlh9XflZHfY3bh/sP Kbv36X/5Bxk7vGm1DMH7qyQU0QqztdRaRje7QRjuEZ5Oc5kw/GA/vcwQLpbZ36fkqsfzrMIi Gx/RLCOVERnD75lI/XMw1bvoB7oDGrHbQAGjC7W9Yqt1aS9FQ239vCOYbDXU1s/VNpzXT9GV D4vVKtKvH2T1UcVF68+y+p52/TCr72NK/XYVSf01TKlb6k4LvamPlp0mQ3OgC5YaXVDUD7L6 yi4o6s+y+souKOqHWf1aFwjHDkKQXAmVV9m7WSvS4VH+0eWssr/WX/A4W5UXfP7t1/WDDHc7 twwfJ+VxlRkMEW5q7jOxsSKNT4S2lk6gix9HKeNrbpmvq1TtMynmdnwaQ3kNg37ENio4u/2W vVM6B8oWCKmQ7Gftfe4alP1W4ck5f83/x2pkUsyeF56Du9O3OBd5i8sXUyhMf8fd3J0dNqnP 5yjPIM1cUuBJ8tSjTtWEA0PhS6lzo3ab5V0T17WjeddUusSdUX3hNe0Lz6gvQpO+mEr7Yibv C/jSRX0UKPsCH4NodMN9XJfycfNzfnd83J0Hg4/b0sd19+3juoOP25mPq+NTij6uvg96XD6u +7J8XNfQx3UNfVzX0Md1X4CPm1uSvvm4FvgSfVx318d1Mx/X3e23ffm4ro6Pm53D3sSvch1T H9fV9qsCqV81Vvq4LvNxkSTzwX1cV+rjek37wjPri9CkL+bSvlgofVzWF/VRoOwLuY/73//5 n/8HPNlPt3UjAwA= --Fba/0zbH8Xs+Fj9o Content-Type: application/octet-stream Content-Disposition: attachment; filename="d820.dsdt.gz" Content-Transfer-Encoding: base64 H4sICAJLf0UAA2Q4MjAuZHNkdADdfA14G9WV6J3RSB6PZGckT2yHGKM4IQQagkaSTRJCsP6l xLKFRokNTj9JCQE7oaCGQBJCQHFCEkIoISbdwuNHJlqgW3ZJKd++/vB44acBWhZCobuUvram 9IftsuAA3Xq7++J3zp2RNCP/wPJ9u99+z4nvPefcc8+559xzf2fGQSWY2rSGEObaWHfK63Ep Vyjhjdu3b2dEQoDStcBidvJrQ0nFscxUl9hy/aaNG7YudwZDXV3OoKvdCT+kLpjdunG50yVf BP/dLlc7qVu7cctyp7zE5YL/pJ8NrUoF+XhMCdhtQi0p/RxCikAgdakgC6lbBU2QelSQg9Sr gmZI21XQAmmHCtZAerEKopKl/YwSj/Ux0ioz5Gm2fz6iExO5wXVL0oo/DZgvN1CGA7kKmHnE cWQ4IxA9qQL7sv3noahillf6+lx2zkoYhGS7SeDvREAgkLpVkIPUI81W+mTwQKkJKoMkK30e F5NDOHNjptB25N7MfhR5CBOkKn1uV26Aphlawws1ZK3GlozA6irdqask00qyrpK7UonTVTqo q+SmldxapblQycMWpKOD+wcODQxiG7C1mEtNAHlZsCLziO1oZhA5B8AAKYbGdrBf0MPFSi3p bBDUzhYaDdr7OoRbqP5zAfYSStgJMrAdjqMZ1Yy+djQJW+MEYClbmKOTkaN1dqH7QcwCwC5W q8+h1T1bqI+yWBGlZEFKAGySZVTmVWvvoJ2nsiKQKbQcpb7M5NRsK21JhvrRgyokSL0uUu7n eVP3M61WRLAoEKkD6shE39Pzpu7pcjW5VM1N9H09b+q+LldzY7UWqAa9PdvoK2+5u72G7vaq 3d0GUDuhfBkYAG6Pnc0gK4IZFO2RbOA8N1HHi/SlRHficgZHAkYSuhFSFtMB9LEqCCsUM9J8 4A1W85rKvMglXQY8kWoeUubhE5FQym5We8HrRUyFQQEi0gVQX2Gr6jNafY93cP9gWVVbQulN V1gtJSaXjiWoKDoWvsTirrA4I/FQnJRZakpWu0tWO5V43F9hsE9miPQkuyoMtdUM/UwvTH0M 3xt3gUHSPMjdFfbZZXYsp026ECCPqT/f25tIkgGB6d9tRdAODe3lDw1u6l3r68phggTK3V7h 5srcvR6386CeGwiSF7i9yJ2syE6qspNl2YhQAFYAAGmljkolrlwpqVOBSKkSgDDFQ62L2UKn +ci9g1Yi5tC+DJRmH5l9NDuIrc4MZOl42JIVuCwdyK/C1DGJr8PAVxyQzu9VFw/068REwTas uhYdizoHBvvPw6LiAN+7bKlSFx/csOX6G66/equzd/C6q67fdgPhu1PtU9Cd3SnC98a645OL 4qHlzvjgtdduvO66wRu/4gxdNbh18PrrgLsvka4rVYcFVgZSV8RA6iCSA0I7wMIgTgWiySIm UqdZSSVDLA8pLlIJBNwIwIwPpNwg4jmSyTHZR9qyORSA9EwZdGfWF2qODGfXF8mNmSIjddb2 KLEgKQT4YVygcQ5mEChc2O9Yl4ayTMFOc2xyThBpmUaBFucEJ1JGglxhNrYMC9Lovhxd+z06 KjovR9dzPRX9lqM7Ak8RE5jKe5RUJdAFbB5CWFgafqK/Zh3pzycDST+xkTz51Eo6+3fHzUho AJyHX5HkWTaa8CksMUMWYki0ljAJXwrmIprE/UEmGvQFGd+yi4MMEZKJoMxA4sbEg4kXk3ZM OmAc+laHYByurukOrU3BVAmxJByCibTQsDMjMGSfuuQl/KluIV8QgMYS2CSFKMiRrlhQBXmS 6E2qoEiCgdUq6CR+3xUhKqqzJEqpiMoTUBeSFqBAQjU/KjD71l3EUZWBmAt+QxGQJjBSyIq6 tAYGsIHh2sN0hcZklkr/CtK7a4BgKsw9chR9LIglE0CeQPrbrO+bRjwFeZgW8qDNVCpdGwum BVJFcdM6H7KTGPP6hvoiiXSJSrV1UUQKzkK3aK3+BrTutgzuIrM7M7sEZpfAgrPothJclK14 2xdIQ+WdWCCw6wvnQhlLCrPWa8V+X8ol7B6pN6CFRuDiqrnylMxPIquyRVW2aCyWjbJlTbaz mkuV3TmJLHXzGACa0RuFtgzGB+53Vcp+7CQH4tQZF2dzNBvhKepWUXchymULzZkpo4GMfIlK uksgBSvdSGMIBaeJHBljUGvNPtRdT6OY4ocFZqRWg1TK92EwtAZCim4VbDauYVJXE4atJvHr xrGSujKdisah9wpLaPxPCpvdU4bN7oK/lrZKF8dRy39NHI80TR3J2hBHXxScdIhjCxLJdCCx xqUGuopgKPg4OvJBkrkkCYarSwkFXHGfkhKYwjkVOyraSjxQXkcniRw9ZrUXmun0oG9soi+B G4b6delESmGomw4OSL66dWmYwlT8MQwcCt0/QCeeC4ZhfdZPYWx5JOIAUNcEL87MhpFXiVMt JAuhmYJxUWGh2gtsKSqnjkQ1sLV5juhM610dTRQdFlYgYGDI1g0G4XqFU7PalDugKbgHKNTS I4nAZGnnMBWQVafillIvTFbP0sLOadpGQxiGuE2zBAUb5hfjhIDt4KjyWVmjf2HjAc0WQ7PX pSOJkDQ73QW7AH039kQTkpDukpcRXHEo2EHQZKkJeP30tKMPdZayLKV0qRlYPIawWKP4kQcL vNUFslYQqC5wawWh6gKPVhA0FISigZhW0G4o8F3p64KCqAVKlmlj9ySO3RZtQtC5GsK3OxZI a/3AGgqTCZc70ae4tUKuutALhV6B5QNJBU/zR5g7EbIeZiCTpTpIPegfirVC6mUOIQPi8AvH ZkxvpMXzIW1X609RrPIsgLSDOTiZZwuiAkeZ5gWSaZcJlQn7UKZQizCydQxisklaCBwyRzki NMXmtiNHO3J4N2GyWQoDS9rNUo4DVFIdhVWKjaaE0mk6sGVgMHNTBsFMhTqoivFMFsPoxJg+ pxivKmY/LWgqt0AvpoNSOipiOjIV6qB0IUhpV1u9I4f+ymyFbhPYLB5Qs6rEG2FM78Ay0bkO p9L+PVacWokImwKLisgMRfh1acWVdvAmnCEEgqiHouYS6qVoTQltr6Bi0LIOl6X+21ebcWmC YRZIwk5PuDWzLSMIcAa3PiFk4OQmplPxBMlFYt1hOF0A4UsIlk+v5ROwTFfBgvVoxvqoNQe/ wCs2rSN8JBGDjZlkS0PO5AYQFQ+9blqHgdyfh8GRZISnBLZ/t0hhvFLhIQnyWJh0M7A64wmM wnjHwvcPrd7ui/e66Jmxj+HT0Viw7oLcdTnXBtlL+PQamKmI1KCk/FeY8DgRh638JkyR1hs0 3VlNC/aaDhpoZwW6/Fcw9OJg1tHM/gEUNZDBruHTvcGIPWoRrnrm/zx411988x37ccffto18 lDri8zHktWHz43qa38ew917xgwf1tFOE4Uev3XbsQOvP7d+8kydO2/1X+wMMmec4bL76p2/Y nxojhVcs54vxHobw4OkeOO/k+VAgSJe53lDQBU5EtEgkvjcAagFYbem9HCB62uubmMDmY9WC 7QgsdSSHcHZkJVqKoEBseAFaRjmbE4+CJZQXmDJsw0MprU6Pi33FLChVfD62OCgt6o37faaD m4RFvf414S2YCIth6j9yb1Y9ysbSm7IYMT3mNLR7cuuke7B5p4ZV47RWXlDeYDUaN1iV1meM LeJ7L4/32CO91i3mcE/czxBC1psJOdBCSFAhzFm73kk1//Quwlia/eIssW0e52BGXl5s2ycu XbK3pTPaIq3i9/654eUnyd5688tSJpFXOPunF5x4lAyzi4VTS048RX7BFl9w3DO6SB5d9ODb z9fNfSYh/Z1z1dCPzONhcfv32AU9nfebmxszX85/MC/xzUDnK3PYTeSvuzvHj3bXxsTX+n74 3ubG+Oux1+TfbF/3vm+sU+js286H8r5Ys/VGedNb0Z/lbZe/8/gbpuX/e/6yHxy75AgXvvTR DYuvDfvveqNF2n2y7h1Htv1v3r7m6ndfcJy0t/QNhd/wvvSduntGnf4NV3W+/Mlx882/qf2g 9XLB7v1Vwzcvz3fYfrZ87sDj3z4rYA/uLVxua5yXOjBx272PPyYt2LTR6bdezV19m7jg5H2+ /eYfk3vsvmPZa5hZL3kGb11/1gO1J/cdtvB3LF+aYFfPWfrtS5fc9dGhY/uW/tHzyWXP94/Z 83c/t+fSvfnIy68Ry4s7H/bed+frrGvfrH8YX+RtvWll5r1fj62UHsh92ymQeVf83vTpE3df OPpC53e28f6xttFje+6e2/qnTyzN9TWtX+uZe2Ijt+6d4ee5I//OHW5ufmv3iRrrd4+MJl74 5MVW8cxEZEfbRZaHzmwgh0xDj92YfHbHiuj2RNYxfu+JU+NfNT1x7OQ54uiDC1578nXm/VO5 g7bftI8We155b/Wop+aDHzyXbek6wH/E9Jz97OYVAnfw1M/v2/OQ/5Djn594fkUuePqeF/iP Wp9tWJF/umPZu5abf5d547XFT5FHosd8D9pvOWvs6YfW33Kv6+U5rW/f8PyGfM2rH9as7B5f l99W9/icPx9nfn9q92Xx0VmN46fH739h4QMnPq7ZfdZ9I5f++M2b68YGX+JWXj8+MfH66e0n nhzf6vtQeOjJ15e8enJ74tgYU7PtptP2E9c0jS6745rasVb2lrY7/nTcvOHF7S97/ubm5u/z fb/YZb7xU7bhrc2WDz9lb+m+YuzMxGOLR29dMxqRXJ033bTc/vzOV244cH3vym9wO+oPjN37 w49Ml69vTRQXhW0f7/3tP8VsgRpr08rnlcbM6SO3L9v43C1zx+81f21i4nzruvdu/RF79U8e Zlf+dLy28H6NVXhPaRxd9UuG8V5z3q8abTe9+uxV4/fy+wL7Pkrt//jl09Lo/Ma332sxbV13 2v7jiYn5jSfuMvFn3mL+qVX8+/31o/P+bV7Bc+jcPS+f/N6+r73x66a/+h/+D/a8+9Ru7g/v Xum6PfjGgNey0DXkOcA8aPfvdz9w8BPxDxM9rrfuuuO11z75/f+0P8zbPvjSi/2Wvn2//eGl TMt7sYWP/65vz/17nmSvv2rh2GzbtY/NOfTsJcyi/C3S2K5//Ur+73599GcDK29r2/c1h2er 8OuRS94/9cZLzMNP5J6rT59auO3p8353xfaHvvu9Pf94gNsw9o1X9lwx+hvf6YmHV3Rt73r7 hXmXbt1+1S0PrPy/rg/eXPYXj1xTvOSkp8ny9/N/fzxs3Xni9XnPvjB+4oXMrpuZl05bzwyS FTXi3e+a956T3nrmL/1N5+1wPf6mNPqHTy0PfWvlh4tv/7eJh/8y03Lrrt1/+vKP+JqPF5v/ 5e3XxbPZW77Ojp/+89gOy3Wjb1506s8TD/tP3HZozF6z7W+Zj95oaqnZcOvJE2e/lH/plTnb 7h8Tx8mVD7Yu++MDjg+Xnnhs71yy8MSchsQfJy7bwG44zH8kXP6re+pOH3o198uzWtMP3fPc jpPc+CcTl/1kw/XCcw/783eMexbOvvXk3o6mnp9f05XfOTHhWTh6ycdzGk7dUHz+Qfk512t/ Om/PirvHO0eP2ZSBNx8LH1tb96O3Fr1ZWPvwqrvmXLL8ihevbO/bf+WTnYv/8Y554sREaAfJ fjWed737LceBDXsS317uPGvOIz7uN+LKfN8CcXfDuYW3avmG7zfu7nuoSWys37vKbXrt0938 y8n0PPapnMj868Ss/qEuDo9H6irsCyRiLhfsxXnYo3Y5ZqmrPB4V8IQAe4yEktQ2xLfDPI7b YVwgatNKykeKwizeHwsnHGyd1GUDKF25I2cMew33AeQTCNEhjB5h9YhJj3B6xKxHLHqkRo/w FGlXkVo9IugRqx6xEXqxjXD/UI8NXUBdZPOdsgnqHoVRnVTDUCeBc9AJ2vVOpmDOFIVzwCVS XRqEEJSUFhip05L2628M2ZJ7ZJmHApeD5bSWA1LxECKMHmH1iElrLMDS/LQ/lag43lR2v7v8 AEMzSK42iJ3eIHEag9hpDGJLBsl6g2S9QbLeIFlvkKwzSJ7aILbKoBV4M1e2p05y4FWdFql7 IVKLsPNLJHvxNN4omMCEhNLL4LOVAdi5Dp2Pp9xybZuOlTOwMv1DsxQ9a33/UHRO3C9XVDNa bEidzbAhV/Cs4MEjlcDAro38ey1REQpaCVe+B+Jz+IQlQ0uBEf5X4HpMwD/4FCezNWMjH9SQ bEkOEUl2S1bNVVqWMuTwkY4qg8nQ4i1qQVZ3GWXHuyhVD4rIk622CfgB8PgEPsZjKo0AQlnl iTOQMGVTyKgOR96fnKENLuGJtwA/bq7wPz5hJZ1ljF6Il7BOxMQSljBgGQOWN9QjZAwTPOa1 F/GI2z+032zCg3apawQTn/YFkwIpd69VMEsr07HuGDHcH9GIN17klq+O8KpHd78krW7Q97Jb gD5l8MAKwLgND8qQwX/ofR7JVlJnJZ/gURQaK5CSlxCrI9SHW2hX0Z7eonZbptxfGwp1wxsE E6XnSWYrtRqPnWlvJrul5B+kg290dNVTlP/EGR291I+05BSUFHhd4akzEJ+06CfVRbR/eRqh 2PS3gDOBjO8YpI/qpEP0aCW6Dlplifvdk4YOvQ9J232ccGmEOUKOEJaJME+Rp2juJE4ishGm QAqQtzEkwpziTnFIAleJoiXC8CL843cQyUq7BnWlYcarifs9k3SZVF1hs5AEAZ+ST5mJCLOP 7KO6vkO+QxjILaJFZEGBIAoik4gwGTEjis4IkxfzotgZYU6IJygu4g/ktXwtzzDVDYgdjik+ Pw1B8Mc5pD+fiCVlVsgIHAXdrIBPHfPhYExhhY/VaUlxx0tNntWgtpUXzG1ErJa+ilvtD5TN M2l2LRLOheZCXIhgxlXkKsJBvp6sp+ZdTa4mFqaNJdWyliVTFVFWwidT6bS9WZgdYXIkh14n UHsL2UJYS6UqMkHVVDxZrgrn31S8VLUTRrbItXHQYQkY1iJXqYpM/UMRTkmsTpbq8kS14Fyh LcJkSZZ2xAaygeYbyUaaX0OuIZMd3QNR5Z3U05zW05zgjzBLyBKCPZq35W2iC3rQdsKGPdlN uildrIV/IkRbrZPmz9iesXFchHHVumrFRLXCcG0ipjnMCi1X9dQIWyLMArKAcCBvEVlE88Vk Mc1dxEVzL/HSfClZSvMVZAXNi6RI88fJ4zR/gjxB8+PkOM2fJk/T/LvkuzR/hjwDeXW7Apa4 r7IosqQyri4QwRh8BQqNy+PjRxg3+8l+wtSCM8gJQsOZDqgIc5gcpkNumAwTpq5aiRzoSZR7 zaZ5WRTqIswYGYP6bcQ5KVbN0UQoVY4SmJYDpa7yrwm77Hahfh99S+vUGcIRDM8WuhMpOErP Ggo8PiOFvQi+QqLJxqrQF9Y1vmR5Y2OGzg+tCtbR/cwSXAwwCS3By3EiiVRqDl8OEdhsMSvZ 0jD2CL4AAvuaOlUsvuqBuxwzLBoKURu4UrhENs/vE+0RZtw0buL5MsaOsxXsfdP7urL32feh bOkOtaUgXkkqDL4IIrAD/UOh2bFk0Ke2O35sTDQ0zoR7bF3jTIbGmXA9U+whEZYeVxusHZpi GK4s4Xj+gnoyJZkAuU8sNdrATcnUsknkKWRTMrXus4RMo5JMLZtMLbuaGyOFJ0AG3+rdagK3 +qRQIFEeAtznDgemKhwYg8cZ1ePhOuEnLtDb9l1w7nbTdtqa7TXba3jOBR5oy09BLnGz26lJ 2y3bLRr3VGSN+xnTMyacfp6peaaGq3BXk4GbTK2STC2bTBJS5UIGI7M1lYhrLuS/wrDl0SpL Tuqx8s68vvqlIHUymCM0wnBmcJsAEz+oPG47bhNtxllB6m5KB5U4V/Dbh78+QOwNgvjon39x 6dyOp7uLC+4S+QcbFT6dSrtI7r5NBIFC/TBmAinaOYG5bGRVXYnCFOvkJS4yErUVFqkU7fHg K8KteGKdldmVuW9zaVv1o0ymSEa6agtOlddUxVu018DRBJbQkWhNwarycEWBHYlZCm4VNVeq 3Ixv8JTQ27I7s5AU7QKcZ0ACrGIjnsL5aiULmiPXkdwDmyfQILlgG6aUjdfB5D9iKjIjNdQ0 UoibSy7551Tm4oZXbwwfboms/YeP3/oyynCXXOJWHeDWXMKMnFuYrxKYgm2z2qgfQ2SPWEsw gShXdeBeLAz9XL1qmqXzZuxjeiikB/8w9OJndzVySRetCcSDprLIWfp32jyuTZNeyZu1Bk5f bBFrwVw5iHiyhDMDg/1D8Rp8XFjaWp1NJC/u8EkO+fBZSQb2zXDOoc9iTYKJYoyGlXKiHfRQ 14AADlkUXaPJRMwWiLo0jFExWcVYTb2K2pjJ6hm9es6gnivnRvWMql7Wq5cN6uUq9W5VPTtZ PatXbzOot5Vzo3pWVe/Wq3cb1Lsr6mO1+IBVVW+arN6kV19vUF9fzo3qTf1DQQ70e/T6PRX9 5wFW0j/DhN4/tHoWPuJVm1YDTePTikxvORQPrvDGhtboG1pnaGhdOTc2tAZO/7XQ0Is/V5jo +tBk6EPO4GCzwcEWg/E1BuP5GYwXLZTMw87U5Qg6GxxncXCyP4cYXlDo6l4dEEi5iDEW+XVF 7PS1TMaiYKmodZIun65oOl2t0+tqnV7X2ZN0hXRFVbrCuqIqXRFdUZWuaKmoZXq7Wqa3q2V6 u1qmt2vuJF3lxrPTN4OZqoj3JWIuR1xscNSVIgH+iWWMAcxexvCdFUcZw+fTWr1WQ71WQ71W Q71WQ72z1XpSGcN6s8sY1mssY1ivScVaDPpaDPpaDPpaDPrmqvU0DaxBCqNh0lyYAFIkh57J FGxH8Ml2DgcMbLf7d5+vf58JTu54Wmcg8cGYSvoxCWAS5KdkdSNrCBnCmEQwifIwsdmwO8rL 7KzKTTIsn7WCZT6pb4bl8mxtLwrqcBuSzxR4mI3yRaG2KFilJroxVUt3YWkug7C0iqOrLB5S fKowAsLuRFRggCFdFnh3ptB8FGriFoe+bbQjm8nmssiDxxMfnrhgE3jnANa73Lcbk8xNmh7N Cn+1FWzFigIxWuGf0Qq/zgq/3gq/0Qo/tsafLguc1go/tcJvtMKPVvhLVvg1KwLVVpim74vA jFYEdFYE9FYEjFYEsDWBdFngtFYEqBUBoxUBtCJQsiKgWRGstoLT9UWVFcEZrQjqrAjqrQga rQhia4LpssBprQhSK4JGK4JoRbBkRVCzIlRthblixfgvjVaEZrQipLMipLciZLQihK0JpcsC p7UiRK0IGa0IoRWhkhUhzYpwtRWW6a0Iz2hFWGdFWG9F2GhFGFsTTpcFTmtFmFoRNloRRivC JSvCmhWRaitqprciMqMVEZ0VEb0VEaMVEWxNJF0WOK0VEWpFxGhFBK2IlKyIaFZEq63gp7ci OqMVUZ0VUb0VUaMVUWxNNF0WOK0VUWpF1GhFFK2IlqyI9g91RfBd2tLmnt4aB8IRlj5n6N8d sCNmIp3OVCLsYlKwkEGSwCSISVhGGiYJTIKYJFMsYYGqQJJKIjXEpBSsrWBtBWsrWFvB2grW VrC2grUVtbaCtRWsrUBtEKmwiViPwioIKQiRZiUAkiCRIVEQUmSG2BKBlAskQCZDpqiYomKk k0sE/C4GEqzkx0oAAXc8kGQSCiSECycCLgYSmQkrCCkAJZRYhFUwITY+koqn7E2CNFH1YyeE HMRCgUBbXSrIBeM+DYQVukdWQRtQNVCMhbsi0rkAx0huAivmJrAOhWUKyzmN64I1gJkK5oGi IBXEQQikTQJbFFaMcEXhyhHbtq0Ct4kIrXiZNwdqx9mcUJvZmhmA30F8aY+WrK6L4Pt6qBBO INg7cL7GpuxCh6Ie/N2BXQ0ny12ZMgVdDYc9HQW7Hs5fFUoOtWLXYxRQW5CA3Ye9hwYVzkIt OTQEHY3dgT2GFo+IhXoMK6xDCZRXLvHK2GvYregRjVdGXkqgFqi2KWXbFL1tis42ZbJtSrVt ypS2QWBijJZtw4BUdLYpmm0QOhhgit42pco2RS7xyhiHit42ZZJt5Vcg+of8lkQyltbOhJUC yZoGTmpwon/oUnx/vvRAMpIKJ+yCUCOaIEgLH0lO4AxrDyVvwvsLgZ5FkQ2DCQ6aQQu+X6+d NKfUofQPXabXkU7G10Jz7HBmdDHatxE83p/PUWfAyocUeKczi2qZi29Cl+5V5lYenJrxBBub hx8VlEoZgmdN2TGXcTRz1omJaY4gsqOecVhVhqo9uKzfg8u4Bx8Kz11LH+urnmxMB3sUJjdA H75iax9CSIpxQC8966dPtc9WT+6NnI0wMOcQFhIRIRGgkTlVJc0IORm8BAtxqbXptCSgQlK0 ElZypIMBRZP9NfX9WSBFSqT7VFJdOqgoDH6HKXB4ZcoFkimdGKZKDDtZDFslBp8JrDZ3BYJp CAYUozOvlppnFZkRc9HaXC2cmSycqRLOUOHBtbEZhLMo3FktnJ8snK8SzoNwf2O53+gj7um6 rpX2XFV/EA4T03+//ghxtD/KYrgv5vkQRz1fFmP6Yj6eh1//lC4dwcUW6mIQq7qUBfcFLsQL oVI3tOpffOBwtIYccQs33Z0BXkJMOZLLFxf89FcQ/KSbEG38hxxLOcMpvEE3G2gned5wWufV M79+pgjpZ4oQnSkWB5JBV2Uukurpax3UfUfxMIQXf0S9+DOp3NqFrbmK+8HJ3J2NeKVW3knO xt0ffR55Eb4p0k5fY9JeD1lfmLt+6s+JikKFqzLFSotwV1q5Xjdjqn5DWvUB9sVpf7BbL8JK B6pNfCJvozBL4ToKmyhcjwoupfO9/v2ViwsLMdU+WFI/booJTP+5+LGdlRQ0AraYrhYepvQN Z4niNVB8MP8GVjOF1gHtOylG+9rL8NLMSFPpK6qc/i2a9iJelF4AApRS7/FkxkvdnoZkQrtV BeYW3BHLAaW0I46aEesknecQi+JXYMcYqyV1XbArYIjb50/Q7WQwoGa4I2W6fEqAIecRMYHb XNKzgrRGEwGFgU2ngu+U8L198RBe3yb6FLm8mGoDqVYwSd0CDczC8nUYkkWHm9MvcBqsXlup sHpppcL0ympktaXoiMBQnG7l1AqmuFxUC6a4WlQLJl8sag4szxzUgW6DA90zOdCtOlDNFHeV A92f4UD3ZAdyMzvQrnOgQ+fABp0DxZkd6J/OgYHpHBiczoE4i3VFg12QKV1dCYeNxXew8jSB TZmIn4OVDmstRFqhGtaoGWbY+jhGWovT7pYC2FEhazd9r6TaY2bpAiUQD1b+5INo/KsQhnkD NhFdKT9MHPRpGX57kTmATadvYtInajoarLn5rp5Ekuwp8ewpFRQcw6rh/U7kQFiS6LRZqCu9 loGaYF8o4adtpQdCNL68hvjyzhRfXjW+1EzxVsWXd4b4asSv6Sq7btjuwhTGfP6h2qCLNFEX aXZdpDlmjrTgdJHmmy7S/NNFWqA8VNtVV3KqK9sNrmyfyZXtqivVTGmvcmX7ZwzV9v9v5rqO 0kpPHdhhcGDHTA7sUB2oZkpHlQM7PsOBHf9hB/63m+ukZvyG2fBtLI5t/JzZh1/8kkKwaRia yBa6Gg8P41+jwPYYvn9F9xR66qqo6KZCzFZFRe8+0lxFxI7pbxME+L2qcOFwdRXoLKGyf5LK b4S3CbjDmELBZCouZ5OptOELJ7Eq7ipvgMkj3ZZCwPy5pE6vawqxTVNzjvhq+9usnzKFGD9V m1ebp+mK/7wWaWHAlcLAW63bO2UYeKcMA+9UYeCdMQy8/6Ew8E4ZBl5cdSZTpwoDL65MkwfF VGEwjdTpdU0hdrLTvTOGgVcfBpO74j+vRaJniu/bK5t5dS+Pr2QswZcmluC7EkR06/62BJZh kfoWhbEeyluCAo1V8M0ffFPnM6qs5qqskJap75stHh7AN6tOXfzKb5X2m+P3NP0hPueFQByO UZu0F6nm0YtcM+wl1HelxBC/DrZ/SjDlCJhtdfhtd0xJOYntX5zvX2bbxxKCNFml3TIfaC8S leYKUNq3WoF2ktH4VNpXse7t+CZjIBwJ2k7HGhh+HfSJi24tKShrICiGbZgYnVf5sx18NOZK w0oTDWCGf7gA+JmDAwJJhtYqkHNK7MpQbv9AJrcV/+JHtr9hQOjchn9CJhWK459lUlz2GoHD VylvQASp69M9SgB90/jotk7b+c9GHvpfb+f6vrpMQZkob70UnIM83MHNMPagFuRcwJdwoeJY LIg5B7kMOQ+5G3Ib5B4ezryuqSQfxAKBhLAuBbkQVqcgH0IJFLQB6Cl0HDl8eBjVIDsCMjJT kht5EfAgZ06wHMDmwXa2uLnQcGR4EI+oQoW2ayf19MTExG0E249Yocu8E7sCt74+8+HDFMEe YMgwZRdqiVB7ZCftDYbsUnNM+/PQ9S7cOQMGRRrAws4ZC7CrCjFN+BgpdHMG4arsZqJJZjXJ rCo5oJNcUwJ4kIwF2PvFzfrAkCEwZDUw5C8aGLI+MOQvFBiyFhjy5wkMebrAkCuBIVcCQ64E hvwFA0OeIjDkSmDI5cCQEfuswJD1gSFq3SeWA0Mu9RpXAsxqYMjYVZ8RGHIlMJyaZGc5MMqS hRJgVQNDxt4vbv5/IcPNkGpVAAA= --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 01:34:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B882A16A407; Wed, 13 Dec 2006 01:34:47 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CD9A43CAB; Wed, 13 Dec 2006 01:33:21 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id ED3EA8C9A8F; Wed, 13 Dec 2006 09:34:45 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id E01CD8C99CE; Wed, 13 Dec 2006 09:34:45 +0800 (CST) Date: Wed, 13 Dec 2006 09:34:45 +0800 (CST) From: Tai-hwa Liang To: Andrew Pantyukhin In-Reply-To: Message-ID: <0612130929216.56920@www.mmlab.cse.yzu.edu.tw> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> <20061211140519.Q4227@fledge.watson.org> <06121210363618.51815@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 01:34:47 -0000 On Tue, 12 Dec 2006, Andrew Pantyukhin wrote: > On 12/12/06, Tai-hwa Liang wrote: >> I'd be interested to know that if there is any "console mux" like knobs >> available such that console output can go comconsole and vidconsole >> at the same time? > > Try boot_multicons in loader.conf (or boot -D in > loader prompt) I have the following settings in /boot/loader.conf: console="comconsole,vidconsole" comconsole_speed="38400" userconfig_script_load="YES" autoboot_delay="2" boot_verbose="YES" boot_multicons="YES" Taking following booting message as an example: Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init << last line of 'highlighted' message Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. . . . Serial console can get all messages above w/ or w/o boot_multicons; however, the video console simply didn't print anything that is not 'highlighted.' In aforementioned example, the last line I can see on a video console is "start_init: trying /sbin/init." -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 02:48:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7802216A47C; Wed, 13 Dec 2006 02:48:54 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D255143CA2; Wed, 13 Dec 2006 02:47:27 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 7F5406E04A; Wed, 13 Dec 2006 13:48:24 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 1FB2C8C2C; Wed, 13 Dec 2006 13:48:24 +1100 (EST) Date: Wed, 13 Dec 2006 13:48:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200612121412.13551.jhb@freebsd.org> Message-ID: <20061213133411.S1136@delplex.bde.org> References: <456950AF.3090308@sh.cvut.cz> <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> <457EF835.2020705@FreeBSD.org> <200612121412.13551.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 13 Dec 2006 04:38:53 +0000 Cc: freebsd-stable@freebsd.org, Suleiman Souhlal , Attilio Rao , freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov , tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 02:48:54 -0000 On Tue, 12 Dec 2006, John Baldwin wrote: > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: >> Why is memory barrier usage not encouraged? As you said, they can be used to >> reduce the number of atomic (LOCKed) operations, in some cases. >> ... >> Admittedly, they are harder to use than atomic operations, but it might >> still worth having something similar. How would MI code know when using memory barriers is good? This is already hard to know for atomic ops -- if there would more than a couple of atomic ops then it is probably better to use 1 mutex lock/unlock and no atomic ops, since this reduces the total number of atomic ops in most cases, but it is hard for MI code to know how many "a couple" is. (This also depends on the SMP option -- without SMP, locking is automatic so atomic ops are very fast but mutexes are still slow since they do a lot more than an atomic op.) > Memory barriers just specify ordering, they don't ensure a cache flush so > another CPU reads up to date values. You can use memory barriers in > conjunction with atomic operations on a variable to ensure that you can > safely read other variables (which is what locks do). For example, in this I thought that the acquire/release variants of atomic ops guarantee this. They seem to be documented to do this, while mutexes don't seem to be documented to do this. The MI (?) implementation of mutexes depends on atomic_cmpset_{acq,rel}_ptr() doing this. Bruc From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 04:13:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7CA116A403; Wed, 13 Dec 2006 04:13:52 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from pil.idi.ntnu.no (pil.idi.ntnu.no [129.241.107.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F7543C9F; Wed, 13 Dec 2006 04:12:25 +0000 (GMT) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by pil.idi.ntnu.no (8.13.6/8.13.1) with ESMTP id kBD4DnuW021699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Dec 2006 05:13:49 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.13.4/8.13.4) with ESMTP id kBD4Dljh077282; Wed, 13 Dec 2006 04:13:47 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Wed, 13 Dec 2006 04:12:57 +0000 (UTC) Message-Id: <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> To: kostikbel@gmail.com From: Tor Egge In-Reply-To: <20061212135251.GJ311@deviant.kiev.zoral.com.ua> References: <20061212101903.GF311@deviant.kiev.zoral.com.ua> <20061212220705.F57430@delplex.bde.org> <20061212135251.GJ311@deviant.kiev.zoral.com.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned-By: mimedefang.idi.ntnu.no, using CLAMD X-SMTP-From: Sender=, Relay/Client=c2h5oh.idi.ntnu.no [129.241.103.69], EHLO=cvsup.no.freebsd.org X-Scanned-By: MIMEDefang 2.48 on 129.241.107.38 X-Scanned-By: mimedefang.idi.ntnu.no, using MIMEDefang 2.48 with local filter 16.42-idi X-Filter-Time: 1 seconds X-Mailman-Approved-At: Wed, 13 Dec 2006 04:39:00 +0000 Cc: freebsd-stable@freebsd.org, bde@zeta.org.au, freebsd-current@freebsd.org, ssouhlal@freebsd.org, V.Haisman@sh.cvut.cz, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 04:13:53 -0000 > Hmm, may be, since vnode must be interlocked by ffs_sync() after > MNTK_SUSPENDED set, and before MNTK_SUSPEND, mount interlock is not > needed in ufs_itimes. > > Tor ? If neither IN_CHANGE nor IN_UPDATE is set then it might be unsafe to set IN_MODIFIED in ufs_itimes() since the file system might be suspended or in the process of being suspended with the vnode sync loop in ffs_sync() having iterated past the vnode. I don't think the mount interlock is needed to check for MNTK_SUSPEND being set in ufs_itimes() as long as the vnode interlock is held. If a stale value is read without MNTK_SUSPEND set then the vnode sync loop in ffs_sync() cannot have iterated past the vnode, thus it should still be safe to set IN_MODIFIED. All writes by the CPU performing the vnode sync loop before it released the vnode interlock for the same vnode should be visible to the CPU in ufs_itimes() after it has obtained the vnode interlock. - Tor Egge From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 06:36:41 2006 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 412CD16A415 for ; Wed, 13 Dec 2006 06:36:41 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FE2743CA3 for ; Wed, 13 Dec 2006 06:35:13 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GuNjJ-0004Ik-I8; Wed, 13 Dec 2006 08:36:37 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GuNjJ-0000Yf-Bd; Wed, 13 Dec 2006 08:36:37 +0200 To: Mike Tancsa From: Ian FREISLICH In-Reply-To: Message from Mike Tancsa of "Tue, 12 Dec 2006 10:12:18 EST." <200612121512.kBCFCbPm028888@lava.sentex.ca> X-Attribution: BOFH Date: Wed, 13 Dec 2006 08:36:37 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2319/Tue Dec 12 22:09:22 2006) Cc: FreeBSD current mailing list Subject: Re: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 06:36:41 -0000 Mike Tancsa wrote: > At 08:28 AM 12/12/2006, Ian FREISLICH wrote: > >"Bjoern A. Zeeb" wrote: > > > On Tue, 12 Dec 2006, Ian FREISLICH wrote: > > > > > > > Does anyone know how to get this working? > > > > > > > > none6@pci1:9:0: class=0x070002 card=0x40371409 chip=0x71681409 > > rev=0x01 hdr > >=0x00 > > > > vendor = 'Timedia Technology Co Ltd' > > > > device = 'SUN 1889 / SUN 1699 PCI / ISA Asynchronous UART > > Signal Chips > > Solution' > > > class = simple comms > > > > > > man 4 puc should do it. > > > >Thanks, for some reason I couldn't remember that. I now get: > > > >puc0: port 0xc800-0xc81f irq 21 > >at device 9.0 on pci1 > >puc0: [FAST] > > > >But no more sio devices. Am I still being dumb? > > If its current, would you not see it as uart devices ? Also, there > used to be an issue of loading puc as a kld. Try statically compiling > it in the kernel along with device uart (not sio) and see if > /dev/cuau# devices come up. I've tried compiling puc+scc+uart into the kernel. I've tried this with and without sio and scc in all the permutations. It detects the puc, but I get no cuad devices. puc0: port 0xc800-0xc81f irq 21 at device 9.0 on pci1 puc0: [FAST] Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 07:36:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFC8016A50E for ; Wed, 13 Dec 2006 07:36:02 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41F8E43CAF for ; Wed, 13 Dec 2006 07:34:27 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id kBD7Zigg056993; Wed, 13 Dec 2006 02:35:44 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id kBD7ZhjA056990; Wed, 13 Dec 2006 02:35:44 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Wed, 13 Dec 2006 02:35:43 -0500 (EST) From: Andre Guibert de Bruet To: Pyun YongHyeon In-Reply-To: <20061212124428.GB9698@cdnetworks.co.kr> Message-ID: <20061213023325.P56950@lexi.siliconlandmark.com> References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> <20061212020023.GA9698@cdnetworks.co.kr> <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> <20061212124428.GB9698@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.6/2319/Tue Dec 12 15:09:22 2006 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=-2.534, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60, SPF_HELO_PASS -0.00, SPF_PASS -0.00) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 07:36:03 -0000 On Tue, 12 Dec 2006, Pyun YongHyeon wrote: > On Mon, Dec 11, 2006 at 10:56:02PM -0500, Andre Guibert de Bruet wrote: > > On Dec 11, 2006, at 9:00 PM, Pyun YongHyeon wrote: > > > > >Thanks for testing. The main focus for msk(4) was for getting working > > >native driver. Performance was not heavily tested and highly likely > > >to be lower than that of optimal performance. It seems that myk(4) has > > >several workarounds for better performance but that magic code is hard > > >to verify wihtout errata information from vendor. :-( > > > > > >Btw, I'll commit msk(4) in two days if there is no breakage report > > >for e1000phy(4). > > > > I have been using the msk driver without any problems on an Intel > > SE7520BD2 server board. We have a few of these at work, and it's nice > > I guess it uses 88E8050. Would you post msk(4)/e1000phy(4) attach > message in dmesg? > > > to see that we will finally be able to use this second NIC on these > > boards! > > > > At this point, are there plans to MFC the e1000phy changes and the > > msk driver? > > > > The msk(4) requires new APIs in CURRENT to support MSI/TSO. > If jhb@ MFC his MSI support code and andre@ MFC his TSO support code > it could be done without much trouble. If they don't I have to write > a couple of code fragments which disables MSI/TSO which in turn takes > a time than that of usual MFC candidate. > ATM I think it takes 1 month provided that MSI/TSO code is MFCed. > > > Thanks for all your hard work! > > > > Andy > > > > /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ > > /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ > > /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ > > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ > > -- > Regards, > Pyun YongHyeon > Sorry for the late reply. This is the output, including your latest round of changes (As committed): dmesg: mskc0: port 0xd800-0xd8ff mem 0xfcffc000-0xfcffffff irq 16 at device 0.0 on pci6 mskc0: [FAST] msk0: on mskc0 msk0: Ethernet address: 00:04:23:b0:d2:cf miibus0: on msk0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ifconfig: msk0: flags=8843 mtu 1500 options=19a inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:04:23:b0:d2:cf media: Ethernet autoselect (1000baseTX ) status: active pciconf -vl mskc0@pci6:0:0: class=0x020000 card=0x50218086 chip=0x436111ab rev=0x17 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8036 Marvell Yukon -EC 88E8036 PCI Express Fast Ethernet Controller' class = network subclass = ethernet Thanks again! :) Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 08:13:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA7A316A40F for ; Wed, 13 Dec 2006 08:13:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D124743D31 for ; Wed, 13 Dec 2006 08:11:04 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so92359wxc for ; Wed, 13 Dec 2006 00:12:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=rco+g9l2BZ5JRU9NnYSI0b7gaFo+gCjdVbkvRq41Cs/rmyiY79E3iSzMdPY0x4SPoC9EuZyR6xnJEFGreGAHJ0jpO6iQIxauHwi5Z8X+01Ypab4lD9huxzeiq3mO2ak476vMOwMMWl1lhFOUbHy3LjiYtEQAmYGuw1pA6ECk9Uo= Received: by 10.90.115.9 with SMTP id n9mr301729agc.1165997534480; Wed, 13 Dec 2006 00:12:14 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 3sm676150wrh.2006.12.13.00.12.09; Wed, 13 Dec 2006 00:12:11 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kBD8BZjE017654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 17:11:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kBD8BYHg017653; Wed, 13 Dec 2006 17:11:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 13 Dec 2006 17:11:34 +0900 From: Pyun YongHyeon To: Andre Guibert de Bruet Message-ID: <20061213081134.GB13506@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> <20061212020023.GA9698@cdnetworks.co.kr> <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> <20061212124428.GB9698@cdnetworks.co.kr> <20061213023325.P56950@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061213023325.P56950@lexi.siliconlandmark.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.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, 13 Dec 2006 08:13:04 -0000 On Wed, Dec 13, 2006 at 02:35:43AM -0500, Andre Guibert de Bruet wrote: [...] > > Sorry for the late reply. This is the output, including your latest > round of changes (As committed): > > dmesg: > > mskc0: port 0xd800-0xd8ff mem > 0xfcffc000-0xfcffffff irq 16 at device 0.0 on pci6 > mskc0: [FAST] > msk0: on mskc0 > msk0: Ethernet address: 00:04:23:b0:d2:cf > miibus0: on msk0 > ukphy0: on miibus0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > Hmm, it seems that e1000phy(4) failed to attach your PHY. I'd like to know your PHY model/revision number.(You can set bootverbose option and ukphy(4) will show OUI/model/revision for your PHY.) With ukphy(4) you wouldn't get auto-crossover feature or manual media selection work. > ifconfig: > > msk0: flags=8843 mtu 1500 > options=19a > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:04:23:b0:d2:cf > media: Ethernet autoselect (1000baseTX ) > status: active > > pciconf -vl > > mskc0@pci6:0:0: class=0x020000 card=0x50218086 chip=0x436111ab rev=0x17 > hdr=0x00 > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '88E8036 Marvell Yukon -EC 88E8036 PCI Express Fast Ethernet > Controller' > class = network > subclass = ethernet > > Thanks again! :) > > Andy > > /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ > /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ > /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ > /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 09:24:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29E1A16A416 for ; Wed, 13 Dec 2006 09:24:40 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A826E43CB6 for ; Wed, 13 Dec 2006 09:20:15 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id kBD9LXuf059688; Wed, 13 Dec 2006 04:21:33 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id kBD9LT3I059684; Wed, 13 Dec 2006 04:21:29 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Wed, 13 Dec 2006 04:21:29 -0500 (EST) From: Andre Guibert de Bruet To: Pyun YongHyeon In-Reply-To: <20061213081134.GB13506@cdnetworks.co.kr> Message-ID: <20061213041018.I56950@lexi.siliconlandmark.com> References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> <20061212020023.GA9698@cdnetworks.co.kr> <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> <20061212124428.GB9698@cdnetworks.co.kr> <20061213023325.P56950@lexi.siliconlandmark.com> <20061213081134.GB13506@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.6/2319/Tue Dec 12 15:09:22 2006 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=-2.537, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60, SPF_HELO_PASS -0.00, SPF_PASS -0.00) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 09:24:40 -0000 On Wed, 13 Dec 2006, Pyun YongHyeon wrote: > On Wed, Dec 13, 2006 at 02:35:43AM -0500, Andre Guibert de Bruet wrote: > > > Sorry for the late reply. This is the output, including your latest > > round of changes (As committed): > > > > dmesg: > > > > mskc0: port 0xd800-0xd8ff mem > > 0xfcffc000-0xfcffffff irq 16 at device 0.0 on pci6 > > mskc0: [FAST] > > msk0: on mskc0 > > msk0: Ethernet address: 00:04:23:b0:d2:cf > > miibus0: on msk0 > > ukphy0: on miibus0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > Hmm, it seems that e1000phy(4) failed to attach your PHY. > I'd like to know your PHY model/revision number.(You can set > bootverbose option and ukphy(4) will show OUI/model/revision > for your PHY.) With ukphy(4) you wouldn't get auto-crossover > feature or manual media selection work. I guess it looks better when I enable e1000phy (I was testing a dc-based card for a bit and forgot to re-enable it). mskc0: port 0xd800-0xd8ff mem 0xfcffc000-0xfcffffff irq 16 at device 0.0 on pci6 mskc0: MSI count : 2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfcffc000 mskc0: RAM buffer size : 48KB mskc0: Port 0 : Rx Queue 32KB(0x00000000:0x00007fff) mskc0: Port 0 : Tx Queue 16KB(0x00008000:0x0000bfff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:04:23:b0:d2:cf miibus0: on msk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Do you still need the information for this PHY? boot -v doesn't seem to provide this information when e1000phy is attached (It may be a good idea print this information out for debugging, anyway). Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 11:22:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02FE416A403; Wed, 13 Dec 2006 11:22:14 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6CA343CBA; Wed, 13 Dec 2006 11:20:44 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id kBDBMBbA010338; Wed, 13 Dec 2006 14:22:11 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Wed, 13 Dec 2006 14:22:11 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <457F2D82.6000905@freebsd.org> Message-ID: <20061213141647.J72584@mp2.macomnet.net> References: <457F2D82.6000905@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 11:22:14 -0000 [...] > Any tests and test reports are very welcome. I saw a question asked several times but no answer: what happens with the sockets when you explicitly call setsockopt() to set a socket buffer size? Is automatic buffer sizing enabled for them? -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 12:20:18 2006 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F08016A4AB for ; Wed, 13 Dec 2006 12:20:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C14B343CAF for ; Wed, 13 Dec 2006 12:18:36 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBDCK4sb063867; Wed, 13 Dec 2006 07:20:04 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kBDCK1Sh034054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 07:20:02 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200612131220.kBDCK1Sh034054@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Dec 2006 07:18:44 -0500 To: Ian FREISLICH From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD current mailing list Subject: Re: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 12:20:18 -0000 At 01:36 AM 12/13/2006, Ian FREISLICH wrote: > > used to be an issue of loading puc as a kld. Try statically compiling > > it in the kernel along with device uart (not sio) and see if > > /dev/cuau# devices come up. > >I've tried compiling puc+scc+uart into the kernel. I've tried this >with and without sio and scc in all the permutations. It detects the >puc, but I get no cuad devices. \ It should come up as /dev/cuau# not cuad. With puc and uart in the kernel, what does the dmesg show ? ---Mike From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 12:33:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E126B16A403 for ; Wed, 13 Dec 2006 12:33:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39FF543CA5 for ; Wed, 13 Dec 2006 12:31:42 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so49614wra for ; Wed, 13 Dec 2006 04:33:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=l7/Rs31+mCiYCbMY3daiXwPVivkOfeBD694GwlLtcWLyFbqhJ95q9dWsVFq8EV6o5mb8zTi4xP9sx1/k8p8wq/RuhkrU1oZ7ZQPhLLLWuRpUopUtn4QFs9hl5vccIMpnlXRMGCRswYJnLpIPTz0WqR1YKBz4MT/eOBvIdHYdAH4= Received: by 10.90.119.15 with SMTP id r15mr532964agc.1166013190700; Wed, 13 Dec 2006 04:33:10 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 8sm1026977wrl.2006.12.13.04.33.07; Wed, 13 Dec 2006 04:33:09 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kBDCWaPN018437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 21:32:36 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kBDCWZr5018436; Wed, 13 Dec 2006 21:32:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 13 Dec 2006 21:32:35 +0900 From: Pyun YongHyeon To: Andre Guibert de Bruet Message-ID: <20061213123235.GC13506@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> <20061212020023.GA9698@cdnetworks.co.kr> <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> <20061212124428.GB9698@cdnetworks.co.kr> <20061213023325.P56950@lexi.siliconlandmark.com> <20061213081134.GB13506@cdnetworks.co.kr> <20061213041018.I56950@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061213041018.I56950@lexi.siliconlandmark.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.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, 13 Dec 2006 12:33:26 -0000 On Wed, Dec 13, 2006 at 04:21:29AM -0500, Andre Guibert de Bruet wrote: > > On Wed, 13 Dec 2006, Pyun YongHyeon wrote: > > >On Wed, Dec 13, 2006 at 02:35:43AM -0500, Andre Guibert de Bruet wrote: > > > >> Sorry for the late reply. This is the output, including your latest > >> round of changes (As committed): > >> > >> dmesg: > >> > >> mskc0: port 0xd800-0xd8ff mem > >> 0xfcffc000-0xfcffffff irq 16 at device 0.0 on pci6 > >> mskc0: [FAST] > >> msk0: on mskc0 > >> msk0: Ethernet address: 00:04:23:b0:d2:cf > >> miibus0: on msk0 > >> ukphy0: on miibus0 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >> 1000baseT-FDX, auto > > > >Hmm, it seems that e1000phy(4) failed to attach your PHY. > >I'd like to know your PHY model/revision number.(You can set > >bootverbose option and ukphy(4) will show OUI/model/revision > >for your PHY.) With ukphy(4) you wouldn't get auto-crossover > >feature or manual media selection work. > > I guess it looks better when I enable e1000phy (I was testing a dc-based > card for a bit and forgot to re-enable it). > > mskc0: port 0xd800-0xd8ff mem > 0xfcffc000-0xfcffffff irq 16 at device 0.0 on pci6 > mskc0: MSI count : 2 > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfcffc000 > mskc0: RAM buffer size : 48KB > mskc0: Port 0 : Rx Queue 32KB(0x00000000:0x00007fff) > mskc0: Port 0 : Tx Queue 16KB(0x00008000:0x0000bfff) > msk0: on mskc0 > msk0: bpf attached > msk0: Ethernet address: 00:04:23:b0:d2:cf > miibus0: on msk0 > e1000phy0: on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, > auto Looks good. That 88E1111 was what I want to see. > > Do you still need the information for this PHY? boot -v doesn't seem to No. > provide this information when e1000phy is attached (It may be a good idea Because e1000phy(4) was used for the PHY there is no output for OUI/model/revision(e1000phy(4) already printed it anyway). > print this information out for debugging, anyway). > > Andy -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 12:43:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65BA316A407 for ; Wed, 13 Dec 2006 12:43:14 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 577CA43CB2 for ; Wed, 13 Dec 2006 12:41:42 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 72394 invoked from network); 13 Dec 2006 12:30:28 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Dec 2006 12:30:28 -0000 Message-ID: <457FF561.4060501@freebsd.org> Date: Wed, 13 Dec 2006 13:43:13 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Maxim Konovalov References: <457F2D82.6000905@freebsd.org> <20061213141647.J72584@mp2.macomnet.net> In-Reply-To: <20061213141647.J72584@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 12:43:14 -0000 Maxim Konovalov wrote: > [...] >> Any tests and test reports are very welcome. > > I saw a question asked several times but no answer: what happens with > the sockets when you explicitly call setsockopt() to set a socket > buffer size? Is automatic buffer sizing enabled for them? No. In that case automatic socket buffer sizing gets disabled. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 12:44:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 077B716A416; Wed, 13 Dec 2006 12:44:55 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0698A43CB5; Wed, 13 Dec 2006 12:43:24 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id kBDCip0P016968; Wed, 13 Dec 2006 15:44:52 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Wed, 13 Dec 2006 15:44:51 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <457FF561.4060501@freebsd.org> Message-ID: <20061213154444.S72584@mp2.macomnet.net> References: <457F2D82.6000905@freebsd.org> <20061213141647.J72584@mp2.macomnet.net> <457FF561.4060501@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 12:44:55 -0000 On Wed, 13 Dec 2006, 13:43+0100, Andre Oppermann wrote: > Maxim Konovalov wrote: > > [...] > > > Any tests and test reports are very welcome. > > > > I saw a question asked several times but no answer: what happens with > > the sockets when you explicitly call setsockopt() to set a socket > > buffer size? Is automatic buffer sizing enabled for them? > > No. In that case automatic socket buffer sizing gets disabled. Good, thanks! -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 13:03:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FD5F16A416; Wed, 13 Dec 2006 13:03:33 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id A04B743C9F; Wed, 13 Dec 2006 13:01:46 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id kBDD1ru0031291; Wed, 13 Dec 2006 05:01:54 -0800 (PST) Date: Wed, 13 Dec 2006 22:01:52 +0900 Message-ID: From: gnn@freebsd.org To: Doug Barton In-Reply-To: <457D2655.9050500@FreeBSD.org> References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.90 (i386-apple-darwin8.8.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: re@freebsd.org, freebsd-current@freebsd.org Subject: Re: Socket problems with latest -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: Wed, 13 Dec 2006 13:03:33 -0000 At Mon, 11 Dec 2006 01:35:17 -0800, Doug Barton wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Doug Barton wrote: > > With sources cvsup'ed around 20:35 PST on 8 December everything works > > just fine. With sources cvsup'ed early this morning, 12:42 am PST on > > 10 December, I'm getting a lot of errors related to sockets: > > I found the problem, it's the change made in version 1.4 of > rc.d/auto_linklocal. Reverting only that change, and using otherwise > up to date -current sources allows things to work just fine. Adding > that change on the same exact system causes the breakage I described > in my previous message. > > It's probably worth mentioning that I exactly fit the criteria from > the 1.4 commit message, I have INET6 in my kernel, but at the moment I > have ipv6_enable=no in rc.conf. > > This change should be backed out of HEAD and RELENG_6[_2] until the > cause of this breakage is understood. I'll take a quick look at this too. Best, George From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 14:16:53 2006 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB04716A403 for ; Wed, 13 Dec 2006 14:16:53 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8C6143CA4 for ; Wed, 13 Dec 2006 14:15:23 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GuUug-0000cy-5x; Wed, 13 Dec 2006 16:16:50 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GuUuc-0000dh-Aj; Wed, 13 Dec 2006 16:16:46 +0200 To: Mike Tancsa From: Ian FREISLICH In-Reply-To: Message from Mike Tancsa of "Wed, 13 Dec 2006 07:18:44 EST." <200612131220.kBDCK1Sh034054@lava.sentex.ca> X-Attribution: BOFH Date: Wed, 13 Dec 2006 16:16:46 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2321/Wed Dec 13 15:16:09 2006) Cc: FreeBSD current mailing list Subject: Re: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 14:16:53 -0000 Mike Tancsa wrote: > At 01:36 AM 12/13/2006, Ian FREISLICH wrote: > > > used to be an issue of loading puc as a kld. Try statically compiling > > > it in the kernel along with device uart (not sio) and see if > > > /dev/cuau# devices come up. > > > >I've tried compiling puc+scc+uart into the kernel. I've tried this > >with and without sio and scc in all the permutations. It detects the > >puc, but I get no cuad devices. > > It should come up as /dev/cuau# not cuad. With puc and uart in the > kernel, what does the dmesg show ? With: device puc device uart Copyright (c) 1992-2006 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 7.0-CURRENT #6: Wed Dec 13 08:16:00 SAST 2006 ianf@ipacct1.cpt2.host-h.net:/usr/obj/usr/src/sys/FIREWALL ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz (1861.97-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd,CX16,XTPR,> AMD Features=0x20000000 AMD Features2=0x1 Cores per package: 2 real memory = 1072300032 (1022 MB) avail memory = 1040420864 (992 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x7000-0x7007 mem 0xcfe00000-0xcfe7ffff,0 xd0000000-0xdfffffff,0xcfe80000-0xcfebffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 764k stolen memory agp0: aperture size is 256M pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 em0: port 0xd800-0x d81f mem 0xcffe0000-0xcfffffff irq 17 at device 0.0 on pci2 em0: Ethernet address: 00:17:31:59:67:70 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) pci0: at device 29.7 (no driver attached) pcib3: at device 30.0 on pci0 pci1: on pcib3 puc0: port 0xc800-0xc81f irq 21 at device 9.0 on pci1 puc0: [FAST] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xa000-0xa007,0x9800-0x9803,0x9400 -0x9407,0x9000-0x9003,0x8800-0x880f irq 18 at device 31.1 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0xb800-0xb807,0xb400-0xb403,0xb000 -0xb007,0xa800-0xa803,0xa400-0xa40f irq 17 at device 31.2 on pci0 ata4: on atapci1 ata5: on atapci1 ichsmb0: port 0x400-0x41f at device 31.3 on pci0 device_attach: ichsmb0 attach returned 6 acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi 0 fdc0: [FAST] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, rule-based forwarding enabled, default to de ny, logging unlimited ad8: 305245MB at ata4-master SATA150 ad10: 305245MB at ata5-master SATA150 ar0: 305245MB status: READY ar0: disk0 READY (master) using ad10 at ata5-master ar0: disk1 READY (mirror) using ad8 at ata4-master SMP: AP CPU #1 Launched! [ipacct1.cpt2] ~ $ ls /dev/cu* ls: /dev/cu*: No such file or directory Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 14:40:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A73E016A407; Wed, 13 Dec 2006 14:40:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id A515D43CB5; Wed, 13 Dec 2006 14:38:47 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1GuVHB-000FEe-1o; Wed, 13 Dec 2006 16:40:13 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBDEdxBZ011609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 16:39:59 +0200 (EET) (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.13.8/8.13.8) with ESMTP id kBDEdxmt003633; Wed, 13 Dec 2006 16:39:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBDEdtJu003632; Wed, 13 Dec 2006 16:39:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Dec 2006 16:39:55 +0200 From: Kostik Belousov To: Tor Egge Message-ID: <20061213143955.GM311@deviant.kiev.zoral.com.ua> References: <20061212101903.GF311@deviant.kiev.zoral.com.ua> <20061212220705.F57430@delplex.bde.org> <20061212135251.GJ311@deviant.kiev.zoral.com.ua> <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DfnuYBTqzt7sVGu3" Content-Disposition: inline In-Reply-To: <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua X-Scanner-Signature: c743d2f542030c7d5376417eb66b5b31 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 602 [Dec 13 2006] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-Mailman-Approved-At: Wed, 13 Dec 2006 15:46:28 +0000 Cc: freebsd-stable@freebsd.org, bde@zeta.org.au, freebsd-current@freebsd.org, ssouhlal@freebsd.org, V.Haisman@sh.cvut.cz, bde@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 14:40:20 -0000 --DfnuYBTqzt7sVGu3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 13, 2006 at 04:12:57AM +0000, Tor Egge wrote: > > Hmm, may be, since vnode must be interlocked by ffs_sync() after > > MNTK_SUSPENDED set, and before MNTK_SUSPEND, mount interlock is not > > needed in ufs_itimes. > >=20 > > Tor ? > If neither IN_CHANGE nor IN_UPDATE is set then it might be unsafe > to set IN_MODIFIED in ufs_itimes() since the file system might be > suspended or in the process of being suspended with the vnode sync > loop in ffs_sync() having iterated past the vnode. This was exactly the reason for IN_LAZYACCESS flag introduction. It is set when fs is suspending or suspended, and no IN_CHANGE or IN_UPDATE flags are set. > I don't think the mount interlock is needed to check for MNTK_SUSPEND > being set in ufs_itimes() as long as the vnode interlock is held. If > a stale value is read without MNTK_SUSPEND set then the vnode sync > loop in ffs_sync() cannot have iterated past the vnode, thus it should > still be safe to set IN_MODIFIED. All writes by the CPU performing > the vnode sync loop before it released the vnode interlock for the > same vnode should be visible to the CPU in ufs_itimes() after it has > obtained the vnode interlock. I think that you statement is valid for both MNTK_SUSPEND and MNTK_SUSPENDED flags. In other words, aquision of mount interlock could be safely removed from the ufs_itimes(), as was suggested by ssouhlal@. Index: ufs/ufs/ufs_vnops.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 RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v retrieving revision 1.283 diff -u -r1.283 ufs_vnops.c --- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 -0000 1.283 +++ ufs/ufs/ufs_vnops.c 13 Dec 2006 14:10:31 -0000 @@ -133,19 +133,15 @@ { struct inode *ip; struct timespec ts; - int mnt_locked; =20 ip =3D VTOI(vp); - mnt_locked =3D 0; - if ((vp->v_mount->mnt_flag & MNT_RDONLY) !=3D 0) { - VI_LOCK(vp); + VI_LOCK(vp); + if ((vp->v_mount->mnt_flag & MNT_RDONLY) !=3D 0) goto out; + if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0) { + VI_UNLOCK(vp); + return; } - MNT_ILOCK(vp->v_mount); /* For reading of mnt_kern_flags. */ - mnt_locked =3D 1; - VI_LOCK(vp); - if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0) - goto out_unl; =20 if ((vp->v_type =3D=3D VBLK || vp->v_type =3D=3D VCHR) && !DOINGSOFTDEP(v= p)) ip->i_flag |=3D IN_LAZYMOD; @@ -172,10 +168,7 @@ =20 out: ip->i_flag &=3D ~(IN_ACCESS | IN_CHANGE | IN_UPDATE); - out_unl: VI_UNLOCK(vp); - if (mnt_locked) - MNT_IUNLOCK(vp->v_mount); } =20 /* [ It seems that MNTK_SUSPENDED flag implies MNTK_SUSPEND. ] --DfnuYBTqzt7sVGu3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgBC7C3+MBN1Mb4gRAjh5AKCJMQ5r75BZzdBmSsbTsVP4BKwwDQCdGdbU X7NQQPclVss8dvVKJp6NYQY= =ZWzx -----END PGP SIGNATURE----- --DfnuYBTqzt7sVGu3-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 16:03:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C02616A50C for ; Wed, 13 Dec 2006 16:03:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id B048E43CAE for ; Wed, 13 Dec 2006 16:00:54 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so195415uge for ; Wed, 13 Dec 2006 08:01:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rMRRObXHa1Zvpo2V/el390WvEkNB+W0dJk8nEodQtjfTdEJSD0RVL1rnujeNCSe/R8Kta78kNN5cT9yTdXSBkc+shdumjZI7eJ4BFcyncixy2SUnmlwW1vlaurR8rzQWHaadFm4LbuzSwiyowUKEXIg9woR1Vlcb5wnj88QnTG0= Received: by 10.82.153.5 with SMTP id a5mr186356bue.1166025718754; Wed, 13 Dec 2006 08:01:58 -0800 (PST) Received: by 10.82.178.4 with HTTP; Wed, 13 Dec 2006 08:01:58 -0800 (PST) Message-ID: <3bbf2fe10612130801x1c135390ibb3e1f2bdd17e006@mail.gmail.com> Date: Wed, 13 Dec 2006 17:01:58 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Bruce Evans" In-Reply-To: <20061213133411.S1136@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> <457EF835.2020705@FreeBSD.org> <200612121412.13551.jhb@freebsd.org> <20061213133411.S1136@delplex.bde.org> X-Google-Sender-Auth: 48dd1aecf1ee68a6 Cc: Kostik Belousov , Suleiman Souhlal , freebsd-current@freebsd.org, tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 16:03:52 -0000 2006/12/13, Bruce Evans : > On Tue, 12 Dec 2006, John Baldwin wrote: > > > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: > > >> Why is memory barrier usage not encouraged? As you said, they can be used to > >> reduce the number of atomic (LOCKed) operations, in some cases. > >> ... > >> Admittedly, they are harder to use than atomic operations, but it might > >> still worth having something similar. > > How would MI code know when using memory barriers is good? This is already > hard to know for atomic ops -- if there would more than a couple of atomic > ops then it is probably better to use 1 mutex lock/unlock and no atomic > ops, since this reduces the total number of atomic ops in most cases, but > it is hard for MI code to know how many "a couple" is. (This also depends > on the SMP option -- without SMP, locking is automatic so atomic ops are > very fast but mutexes are still slow since they do a lot more than an > atomic op.) and this could lead to not real SMPSAFE code, due to the fact you can just manipulate (atomically)one memory word per time with memory barrier (so atomic instructions/memory barriers are not suitable for members structure handling, for example). > > Memory barriers just specify ordering, they don't ensure a cache flush so > > another CPU reads up to date values. You can use memory barriers in > > conjunction with atomic operations on a variable to ensure that you can > > safely read other variables (which is what locks do). For example, in this > > I thought that the acquire/release variants of atomic ops guarantee > this. They seem to be documented to do this, while mutexes don't seem > to be documented to do this. The MI (?) implementation of mutexes > depends on atomic_cmpset_{acq,rel}_ptr() doing this. The acquire/release semantic of the atomic istruction really only guarantee ordering of istructions. The fact is that even if cache syncronization is not done, I think that we can assume, for every architecture, a failure on CAS instructions if the CPU cache has stale values. The hard part of our mutex implementation is: 278 while (!_obtain_lock(m, tid)) { 279 lock_profile_obtain_lock_failed(&m->mtx_object, &contested); 280 turnstile_lock(&m->mtx_object); 281 v = m->mtx_lock; 282 283 /* 284 * Check if the lock has been released while spinning for 285 * the turnstile chain lock. 286 */ 287 if (v == MTX_UNOWNED) { 288 turnstile_release(&m->mtx_object); 289 cpu_spinwait(); 290 continue; 291 } 292 293 #ifdef MUTEX_WAKE_ALL 294 MPASS(v != MTX_CONTESTED); 295 #else 296 /* 297 * The mutex was marked contested on release. This means that 298 * there are other threads blocked on it. Grab ownership of 299 * it and propagate its priority to the current thread if 300 * necessary. 301 */ 302 if (v == MTX_CONTESTED) { 303 m->mtx_lock = tid | MTX_CONTESTED; 304 turnstile_claim(&m->mtx_object); 305 break; 306 } 307 #endif 308 309 /* 310 * If the mutex isn't already contested and a failure occurs 311 * setting the contested bit, the mutex was either released 312 * or the state of the MTX_RECURSED bit changed. 313 */ 314 if ((v & MTX_CONTESTED) == 0 && 315 !atomic_cmpset_ptr(&m->mtx_lock, v, v | MTX_CONTESTED)) { 316 turnstile_release(&m->mtx_object); 317 cpu_spinwait(); 318 continue; 319 } ... _obtain_lock is a simple CAS using a casted version of curthread (+ eventual flags) as tracking bitfield. Now, if we assume a cache stale lock bitfield, for example, at line 315, let the CAS fail doesn't hurt too much since the loop is restarted. The failure of CAS for every architecture (if there is a cache datas staling) might be one of the fundamentals of our locking model. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 17:15:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C400416A492 for ; Wed, 13 Dec 2006 17:15:53 +0000 (UTC) (envelope-from sepotvin@videotron.ca) Received: from tomts27-srv.bellnexxia.net (tomts27.bellnexxia.net [209.226.175.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3984B43EE1 for ; Wed, 13 Dec 2006 17:13:33 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from toip39-bus.srvr.bell.ca ([67.69.240.40]) by tomts27-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20061213171457.SFCU12404.tomts27-srv.bellnexxia.net@toip39-bus.srvr.bell.ca> for ; Wed, 13 Dec 2006 12:14:57 -0500 Received: from unknown (HELO mail.telcobridges.com) ([67.70.237.76]) by toip39-bus.srvr.bell.ca with ESMTP; 13 Dec 2006 12:14:57 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGrDf0VDRu1M/2dsb2JhbAA Received: from [10.0.0.213] (yoda.telcobridges.com [10.0.0.213]) (authenticated bits=0) by mail.telcobridges.com (8.13.3/8.13.3) with ESMTP id kBDHEttM048426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Dec 2006 12:14:56 -0500 (EST) (envelope-from sepotvin@videotron.ca) Message-ID: <4580350F.8080904@videotron.ca> Date: Wed, 13 Dec 2006 12:14:55 -0500 From: "Stephane E. Potvin" User-Agent: Thunderbird 1.5.0.8 (X11/20061111) MIME-Version: 1.0 To: Adam McDougall References: <20061210002923.GO81923@egr.msu.edu> <20061213003744.GP18799@egr.msu.edu> In-Reply-To: <20061213003744.GP18799@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 17:15:53 -0000 Adam McDougall wrote: > On Sat, Dec 09, 2006 at 07:29:23PM -0500, Adam McDougall wrote: > > src/sys/i386/cpufreq/est.c has many Pentium M cpus but nothing > from the Intel Core and Core 2 families that I can see. I tried > looking up the values myself, but could not find them in: > http://www.intel.com/design/mobile/datashts/314078.htm > > It seems that even the latest version of the Linux kernel does not > list values for at least Yonah (Core 2). Is it a big mystery, or is > this data actually available somewhere? I have a Core 2 Duo > T7600 in my laptop and est won't touch my cpu because it doesn't > recognize it. I did get it to use some other form of speed control > by putting hint.acpi_perf.0.disabled="1" in /boot/loader.conf according > to another post. > > Another thing I wish could work is the Enhanced cpu Sleep States; > this Dell Latitude D820 laptop only sees C1 although the document > above indicates it should probably support 4 unique states. Is > there a way I can debug and/or fix this? I can post dumps of the > acpi stuff and/or verbose boot logs if it would be helpful. > > Thanks > _______________________________________________ > > I am attaching my asl and dsdt acpi dumps incase someone knows for > something to look for as for why it thinks I only have C1, unless > its related to the speed control problem above. > Hi Adam, It's only finding the C1 state for various reasons that you'll find described in some details in the following email that I send to the acpi mailing list in June this year. The major reason being that the acpi cpu driver does not support well multiprocessor systems. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=116103+0+archive/2006/freebsd-acpi/20060611.freebsd-acpi The email also included a patch to add support for multiprocessor systems to the acpi cpu driver. I've not updated the patch since then so it might or might not apply cleanly to a recent current. Steph From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 17:32:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66DF616A527; Wed, 13 Dec 2006 17:32:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8506543E1B; Wed, 13 Dec 2006 17:29:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBDHUTsF030233; Wed, 13 Dec 2006 12:30:39 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bruce Evans Date: Wed, 13 Dec 2006 12:26:46 -0500 User-Agent: KMail/1.9.1 References: <456950AF.3090308@sh.cvut.cz> <200612121412.13551.jhb@freebsd.org> <20061213133411.S1136@delplex.bde.org> In-Reply-To: <20061213133411.S1136@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612131226.48087.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 13 Dec 2006 12:30:39 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2324/Wed Dec 13 11:04:08 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Mailman-Approved-At: Wed, 13 Dec 2006 17:44:36 +0000 Cc: freebsd-stable@freebsd.org, Suleiman Souhlal , Attilio Rao , freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov , tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 17:32:11 -0000 On Tuesday 12 December 2006 21:48, Bruce Evans wrote: > > Memory barriers just specify ordering, they don't ensure a cache flush so > > another CPU reads up to date values. You can use memory barriers in > > conjunction with atomic operations on a variable to ensure that you can > > safely read other variables (which is what locks do). For example, in this > > I thought that the acquire/release variants of atomic ops guarantee > this. They seem to be documented to do this, while mutexes don't seem > to be documented to do this. The MI (?) implementation of mutexes > depends on atomic_cmpset_{acq,rel}_ptr() doing this. The acq/rel just specify ordering. As Attilio mentioned, we assume that the atomic_cmpset() that sets the contested flag will fail while racing with another CPU (even if the CPU can't see the new value, as long as it fails and keeps spinning mutexes will still work). The 'rel' barrier on CPU A when releasing a lock forces all the other writes to be posted (and eventually become "visible") to other CPUs before the write that releases the lock. The 'acq' barrier on CPU B when acquiring the lock forces the CPU to not reorder any reads before it acquires the lock, so this makes you not read any data until you have the lock. Thus, once CPU B has waited long enough to "see" the write from A to release the lock, we know that 1) it can also "see" all the other writes from that CPU that the lock protected, and 2) B hasn't tried to read any of them yet so it shouldn't have any stale values in registers. None of this requires the OS to do a cache flush. (If you have an SMP system where the cache can still hold stale values after another CPU updates values in memory where it is "visible" to the CPU acquiring the lock, then _acq might need to flush the cache, but that would be a property of that architecture. However, even that would not require cache flushes so long as the stale values were evicted from the cache such that they honor the memory barrier and you don't see the new value of the lock until you see the new values of the earlier data.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 18:39:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E189816A47C for ; Wed, 13 Dec 2006 18:39:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id D328443CB5 for ; Wed, 13 Dec 2006 18:38:02 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 18309 invoked by uid 399); 13 Dec 2006 18:39:26 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 13 Dec 2006 18:39:26 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <458048DB.2020002@FreeBSD.org> Date: Wed, 13 Dec 2006 10:39:23 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061125) MIME-Version: 1.0 To: gnn@freebsd.org References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: re@freebsd.org, freebsd-current@freebsd.org Subject: Re: Socket problems with latest -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: Wed, 13 Dec 2006 18:39:35 -0000 gnn@freebsd.org wrote: > At Mon, 11 Dec 2006 01:35:17 -0800, > Doug Barton wrote: >> Doug Barton wrote: >>> With sources cvsup'ed around 20:35 PST on 8 December everything works >>> just fine. With sources cvsup'ed early this morning, 12:42 am PST on >>> 10 December, I'm getting a lot of errors related to sockets: >> I found the problem, it's the change made in version 1.4 of >> rc.d/auto_linklocal. Reverting only that change, and using otherwise >> up to date -current sources allows things to work just fine. Adding >> that change on the same exact system causes the breakage I described >> in my previous message. >> >> It's probably worth mentioning that I exactly fit the criteria from >> the 1.4 commit message, I have INET6 in my kernel, but at the moment I >> have ipv6_enable=no in rc.conf. >> >> This change should be backed out of HEAD and RELENG_6[_2] until the >> cause of this breakage is understood. > > I'll take a quick look at this too. Thanks. I installed a totally generic RELENG_6 system from scratch yesterday, and confirmed that the problem I had in -current exists in -stable too. This is a serious issue, given that the default installation will have INET6 in the kernel, but ipv6_enable=no in /etc/defaults/rc.conf. It would be preferable of course to fix the actual problem, but between "it works" and "it is fully RFC compliant," I have to pick the former. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 18:46:35 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5F2816A416 for ; Wed, 13 Dec 2006 18:46:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6A8943CA4 for ; Wed, 13 Dec 2006 18:44:44 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id kB9GKjiM047491; Sat, 9 Dec 2006 10:20:45 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id kB9GKiKT047490; Sat, 9 Dec 2006 10:20:44 -0600 (CST) (envelope-from brooks) Date: Sat, 9 Dec 2006 10:20:44 -0600 From: Brooks Davis To: Sam Leffler Message-ID: <20061209162044.GB34146@lor.one-eyed-alien.net> References: <457719CF.3040402@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <457719CF.3040402@errno.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@FreeBSD.ORG Subject: Re: CFT: new ath hal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 18:46:35 -0000 --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 06, 2006 at 11:28:15AM -0800, Sam Leffler wrote: > I've placed a new hal out for testing. I'd like to commit it after more > folks work with it so feedback would be helpful. >=20 > http://people.freebsd.org/~sam/ath_hal-20061205.tgz >=20 > There are numerous small bugs fixed in this version but the main change > is a split of the descriptor state so that s/w state can be placed in > cached memory when h/w state is in uncached memory. This results in > noticeable performance gains on certain architectures. >=20 No obvious regressions here: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xd0230000-0xd023ffff at device 0.0 on cardbus0 ath0: Ethernet address: 00:40:96:a5:b6:15 ath0: mac 5.6 phy 4.1 radio 3.6 -- Brooks --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFeuJbXY6L6fI4GtQRAmaPAKCljr2Ex5rJszK5F9cL6+6veCRmgQCeP01v pornh/sYOd/zbhj5UKuwvh8= =xaFD -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 19:42:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A00116A403; Wed, 13 Dec 2006 19:42:21 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0923543DC2; Wed, 13 Dec 2006 19:38:44 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.8/8.13.8) with ESMTP id kBDJe9iX089972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 14:40:10 -0500 (EST) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: current@freebsd.org, Kris Kennaway Date: Wed, 13 Dec 2006 14:40:03 -0500 User-Agent: KMail/1.9.5 References: <20061213192150.CF83D16A417@hub.freebsd.org> In-Reply-To: <20061213192150.CF83D16A417@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612131440.04076.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88.4/2324/Wed Dec 13 11:04:08 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Wed, 13 Dec 2006 21:50:55 +0000 Cc: Subject: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 19:42:21 -0000 Kris wrote: > Now that X11BASE errors are more or less under control (we're mostly > waiting on a few lagging maintainers to do their part), I've started > another gcc 4.1 test build so that maintainers can start to work on > that in preparation for the gcc 4.x import into 7.0. I move we skip 4.1 and go directly to gcc-4.2. It has one feature, which, in my opinion, is (going to be) extremely important: OpenMP support. http://www.openmp.org/ http://gcc.gnu.org/projects/gomp/ http://developer.amd.com/article_print.jsp?id=79 http://developer.amd.com/article_print.jsp?id=82 Most of the computers on sale now use multi-core processors and the ability to take advantage of them easily -- with compiler's support -- is rather important. The `-fopenmp' flag is only available in gcc-4.2... -mi From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 21:54:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 581B716A403; Wed, 13 Dec 2006 21:54:13 +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 16CC343CA8; Wed, 13 Dec 2006 21:52:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBDLrlsS015243; Wed, 13 Dec 2006 14:53:52 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4580766A.600@samsco.org> Date: Wed, 13 Dec 2006 14:53:46 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mikhail Teterin References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131440.04076.mi+mx@aldan.algebra.com> In-Reply-To: <200612131440.04076.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 21:54:13 -0000 Mikhail Teterin wrote: > Kris wrote: >> Now that X11BASE errors are more or less under control (we're mostly >> waiting on a few lagging maintainers to do their part), I've started >> another gcc 4.1 test build so that maintainers can start to work on >> that in preparation for the gcc 4.x import into 7.0. > > I move we skip 4.1 and go directly to gcc-4.2. It has one feature, which, in > my opinion, is (going to be) extremely important: OpenMP support. > > http://www.openmp.org/ > http://gcc.gnu.org/projects/gomp/ > http://developer.amd.com/article_print.jsp?id=79 > http://developer.amd.com/article_print.jsp?id=82 > > Most of the computers on sale now use multi-core processors and the ability to > take advantage of them easily -- with compiler's support -- is rather > important. > > The `-fopenmp' flag is only available in gcc-4.2... > > -mi And I say that FreeBSD shouldn't be a beta-tester for new, experimental compiler features. I also say that words and opinions are cheaper than actions. Scott From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 21:59:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E56116A40F for ; Wed, 13 Dec 2006 21:59:56 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id A859D43CA1 for ; Wed, 13 Dec 2006 21:58:24 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so265724wxc for ; Wed, 13 Dec 2006 13:59:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=MpRJAVqyjxourSReTS9G2E5rtvZSAO9oCnBVq3UQWmeClyGc739zFoavRMYnk0BTQu0Kdy2VAMqoJorrc1uUeRsnTVDaxfMgt5pSJbYveiCFIjd8ucfzUU1OBMBA/pHCJRHAuh0xXPhSgDx7lfmGkAW0ShjpAvd5ds+aKYpJPJg= Received: by 10.78.47.15 with SMTP id u15mr92606huu.1166047193844; Wed, 13 Dec 2006 13:59:53 -0800 (PST) Received: by 10.78.145.16 with HTTP; Wed, 13 Dec 2006 13:59:53 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 22:59:53 +0100 From: "Pascal Hofstee" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: D-Link DGE-350T and if_sk (no go) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 21:59:56 -0000 I just acquired a new shiny D-Link DGE-350T (which according to sk(4) is supported by FreeBSD) but unfortunately had to come to the conclusion that i cannot get this card to actually send/receive any actual packets. The device probes, attached and comes up perfectly, auto-negotiation (properly) chooses 1000baseTX full-duplex and after that the device is basically dead .. i can't get it to produce any actual traffic. Below is verbose dmesg output with ACPI disabled .. as i was unable to get the desired info with ACPI enabled (because of a ACPI bad write output storm) If anybody has any ideas on how to resolve this problem i am open for suggestions and willing to test patches. ----[dmesg output]-------- Copyright (c) 1992-2006 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 7.0-CURRENT #9: Tue Dec 12 13:42:43 CET 2006 pascal@chekov.ufp.fli4l:/usr/obj/usr/src/sys/CHEKOV Preloaded elf kernel "/boot/kernel/kernel" at 0xc0cde000. Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc0cde158. Preloaded elf module "/boot/kernel/sound.ko" at 0xc0cde208. Preloaded elf module "/boot/kernel/cpufreq.ko" at 0xc0cde2b4. Calibrating clock(s) ... i8254 clock: 1193224 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 902052593 Hz CPU: Intel Pentium III (902.05-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff Instruction TLB: 4 KB pages, 4-way set associative, 32 entries Instruction TLB: 4 MB pages, fully associative, 2 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries 2nd-level cache: 256 KB, 8-way set associative, 32 byte line size 1st-level instruction cache: 16 KB, 4-way set associative, 32 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 16 KB, 4-way set associative, 32 byte line size real memory = 268419072 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000000fb39fff, 246489088 bytes (60178 pages) avail memory = 247922688 (236 MB) bios32: Found BIOS32 Service Directory header at 0xc00f0f40 bios32: Entry = 0xf0700 (c00f0700) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x900 pnpbios: Found PnP BIOS data at 0xc00fbc40 pnpbios: Entry = f0000:bc70 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: Security auditing service present BSM auditing present wlan: <802.11 Link Layer> ath_rate: version 1.2 feeder_register: snd_unit=0 snd_maxautovchans=4 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Dec 12 2006 13:41:29) npx0: INT 16 interface cpu0 on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=06911106) pcibios: BIOS version 2.10 pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Links after initial probe: Link IRQ Rtd Ref IRQs 0x5 255 N 5 3 4 5 7 9 10 11 12 0x1 255 N 5 3 4 5 7 9 10 11 12 0x2 255 N 5 3 4 5 7 9 10 11 12 0x3 255 N 4 3 4 5 7 9 10 11 12 $PIR: Found matching pin for 0.4.INTD at func 2: 12 $PIR: Found matching pin for 0.11.INTA at func 0: 10 $PIR: Found matching pin for 0.11.INTB at func 1: 12 $PIR: Found matching pin for 0.11.INTC at func 2: 5 $PIR: Found matching pin for 0.10.INTA at func 0: 12 $PIR: Found matching pin for 0.9.INTA at func 0: 5 $PIR: Found matching pin for 1.0.INTA at func 0: 11 $PIR: Links after initial IRQ discovery: Link IRQ Rtd Ref IRQs 0x5 5 Y 5 3 4 5 7 9 10 11 12 0x1 11 Y 5 3 4 5 7 9 10 11 12 0x2 10 Y 5 3 4 5 7 9 10 11 12 0x3 12 Y 4 3 4 5 7 9 10 11 12 $PIR: IRQs used by BIOS: 5 10 11 12 $PIR: Interrupt Weights: [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] [ 0 0 0 0 0 5 0 0 0 0 5 5 4 0 0 0 ] pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1106, dev=0x0691, revid=0xc4 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, 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 3, range 32, base 0xfc000000, size 25, enabled found-> vendor=0x1106, dev=0x8598, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D3 current D0 found-> vendor=0x1106, dev=0x0686, revid=0x22 bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0571, revid=0x10 bus=0, slot=4, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0xb800, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x10 bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=12 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0xb400, size 5, enabled $PIR: 0:4 INTD routed to irq 12 found-> vendor=0x1106, dev=0x3038, revid=0x10 bus=0, slot=4, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=12 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0xb000, size 5, enabled $PIR: 0:4 INTD routed to irq 12 found-> vendor=0x1106, dev=0x3057, revid=0x30 bus=0, slot=4, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1186, dev=0x4b01, revid=0x11 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x17 (5750 ns), maxlat=0x1f (7750 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 VPD Ident: DGE-530T Gigabit Ethernet Adapter PN: DGE-530T EC: Rev. 1.1 MN: D-Link SN: DGE530TBCD870 CP: id 1, BAR16, off 0x3cc RV: 0x99 map[10]: type 1, range 32, base 0xde000000, size 14, enabled map[14]: type 4, range 32, base 0xa800, size 8, enabled $PIR: 0:9 INTA routed to irq 5 found-> vendor=0x1102, dev=0x0002, revid=0x07 bus=0, slot=10, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=12 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0xa400, size 5, enabled $PIR: 0:10 INTA routed to irq 12 found-> vendor=0x1102, dev=0x7002, revid=0x07 bus=0, slot=10, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0xa000, size 3, enabled found-> vendor=0x1033, dev=0x0035, revid=0x43 bus=0, slot=11, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xdd800000, size 12, enabled $PIR: 0:11 INTA routed to irq 10 found-> vendor=0x1033, dev=0x0035, revid=0x43 bus=0, slot=11, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=b, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xdd000000, size 12, enabled $PIR: 0:11 INTB routed to irq 12 found-> vendor=0x1033, dev=0x00e0, revid=0x04 bus=0, slot=11, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x22 (8500 ns) intpin=c, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xdc800000, size 8, enabled $PIR: 0:11 INTC routed to irq 5 agp0: on hostb0 hostb0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xfc000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xde800000-0xdfefffff pcib1: prefetched decode 0xe0000000-0xfbffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x5961, revid=0x01 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base 0xf0000000, size 27, enabled pcib1: requested memory range 0xf0000000-0xf7ffffff: good map[14]: type 4, range 32, base 0xd800, size 8, enabled pcib1: requested I/O range 0xd800-0xd8ff: in range map[18]: type 1, range 32, base 0xdf000000, size 16, enabled pcib1: requested memory range 0xdf000000-0xdf00ffff: good $PIR: 1:0 INTA routed to irq 11 found-> vendor=0x1002, dev=0x5941, revid=0x01 bus=1, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base 0xe0000000, size 27, enabled pcib1: requested memory range 0xe0000000-0xe7ffffff: good map[14]: type 1, range 32, base 0xde800000, size 16, enabled pcib1: requested memory range 0xde800000-0xde80ffff: good vgapci0: port 0xd800-0xd8ff mem 0xf0000000-0xf7ffffff,0xdf000000-0xdf00ffff irq 11 at device 0.0 on pci1 vgapci1: mem 0xe0000000-0xe7ffffff,0xde800000-0xde80ffff at device 0.1 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb800-0xb80f at device 4.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb800 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=10 devices=0x9 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=20 ostat1=50 ata1: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=20 stat1=10 devices=0x8 ata1: [MPSAFE] uhci0: port 0xb400-0xb41f irq 12 at device 4.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 12 at device 4.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb000 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered skc0: port 0xa800-0xa8ff mem 0xde000000-0xde003fff irq 5 at device 9.0 on pci0 skc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xde000000 skc0: interrupt moderation is 100 us skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) skc0: chip ver = 0xb1 skc0: chip rev = 0x09 skc0: SK_EPROM0 = 0x10 skc0: SRAM size = 0x010000 sk0: on skc0 sk0: using obsoleted if_watchdog interface sk0: bpf attached sk0: Ethernet address: 00:17:9a:bc:d8:70 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [MPSAFE] pcm0: port 0xa400-0xa41f irq 12 at device 10.0 on pci0 pcm0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xa400 emu: setmap (f207000, 800), nseg=1, error=0 emu: setmap (f206000, 1000), nseg=1, error=0 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features surround DAC pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pcm0: [MPSAFE] emu: setmap (f203000, 1000), nseg=1, error=0 emu: setmap (f201000, 1000), nseg=1, error=0 emu: setmap (f1ff000, 1000), nseg=1, error=0 emu: setmap (f1fd000, 1000), nseg=1, error=0 pcm0: sndbuf_setmap f216000, 1000; 0xc223f000 -> f216000 pcm0: sndbuf_setmap f214000, 1000; 0xc223d000 -> f214000 ohci0: mem 0xdd800000-0xdd800fff irq 10 at device 11.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdd800000 ohci0: [GIANT-LOCKED] usb2: OHCI version 1.0 usb2: on ohci0 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 3 ports with 3 removable, self powered ohci1: mem 0xdd000000-0xdd000fff irq 12 at device 11.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdd000000 ohci1: [GIANT-LOCKED] usb3: OHCI version 1.0 usb3: on ohci1 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xdc800000-0xdc8000ff irq 5 at device 11.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xdc800000 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 3 ports each: usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 5 ports with 5 removable, self powered umass0: on uhub4 umass0:0:0:-1: Attached to scbus0 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it 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 pnpbios: 13 devices, largest 114 bytes PNP0401: adding dma mask 0x8 PNP0401: adding irq mask 0x80 PNP0401: adding io range 0x3bc-0x3be, size=0x3, align=0 PNP0401: adding io range 0x7bc-0x7be, size=0x3, align=0 pnpbios: handle 1 device ID PNP0401 (0104d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 pnpbios: handle 2 device ID PNP0501 (0105d041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 3 device ID PNP0501 (0105d041) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0x100000-0xfffffff, size=0xff00000 PNP0c01: adding fixed memory32 range 0xe8000-0xeffff, size=0x8000 PNP0c01: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 PNP0c01: adding fixed memory32 range 0xcd000-0xcffff, size=0x3000 PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, size=0x20000 pnpbios: handle 6 device ID PNP0c01 (010cd041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 8 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x75, size=0x6, align=0 pnpbios: handle 9 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 10 device ID PNP0303 (0303d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xf0, size=0x1, align=0 pnpbios: handle 11 device ID PNP0c04 (040cd041) PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x80-0x90, size=0x11, align=0 PNP0200: adding io range 0x94-0x9f, size=0xc, align=0 PNP0200: adding io range 0xc0-0xde, size=0x1f, align=0 pnpbios: handle 12 device ID PNP0200 (0002d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 pnpbios: handle 13 device ID PNP0800 (0008d041) PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 pnpbios: handle 14 device ID PNP0a03 (030ad041) PNP0c02: adding io range 0xe400-0xe47f, size=0x80, align=0 PNP0c02: adding io range 0xe800-0xe83f, size=0x40, align=0 pnpbios: handle 15 device ID PNP0c02 (020cd041) sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0067 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x3bc ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] fb: new array size 4 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x1401 0x1411 0x1401 0x1401 sio0: irq maps: 0x1401 0x1411 0x1401 0x1401 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FAST] sio1: irq maps: 0x1401 0x1409 0x1401 0x1401 sio1: irq maps: 0x1401 0x1409 0x1401 0x1401 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: [FAST] sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x3bc-0x3be pnpid PNP0401 on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff pnpid PNP0501 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff pnpid PNP0501 on isa0 unknown: can't assign resources (memory) unknown: at iomem 0-0x9ffff,0x100000-0xfffffff,0xe8000-0xeffff,0xf0000-0xf3fff,0xf4000-0xf7fff,0xf8000-0xfffff,0xcd000-0xcffff pnpid PNP0c01 on isa0 unknown: can't assign resources (port) unknown: at port 0x60 pnpid PNP0303 on isa0 unknown: failed to probe at port 0x61 pnpid PNP0800 on isa0 ums0: on uhub1 ums0: 8 buttons and Z dir. Device configuration finished. procfs registered Timecounter "TSC" frequency 902052593 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on 82C686A chip ad0: setting UDMA66 on 82C686A chip ad0: 57277MB at ata0-master UDMA66 ad0: 117304992 sectors [116374C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on 82C686A chip acd0: setting UDMA33 on 82C686A chip acd0: DVDROM drive at ata0 as slave acd0: 512KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata1-slave: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire acd1: setting PIO4 on 82C686A chip acd1: CDRW drive at ata1 as slave acd1: read 5515KB/s (5515KB/s) write 689KB/s (689KB/s), 2048KB buffer, PIO4 acd1: Reads: CDR, CDRW, CDDA stream, packet acd1: Writes: CDR, CDRW, test write acd1: Audio: play, 2 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc (probe0:umass-sim0:0:0:0): Uninitialized Transport 5:0? pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-4 device pass0: Serial Number UA07ZR7C pass0: 40.000MB/s transfers GEOM: new disk da0 ATA PseudoRAID loaded da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: Serial Number UA07ZR7C da0: 40.000MB/s transfers da0: 305245MB (625142448 512 byte sectors: 255H 63S/T 38913C) Trying to mount root from ufs:/dev/ad0s2a start_init: trying /sbin/init sk0: link state changed to UP -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 22:16:31 2006 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A7E616A509 for ; Wed, 13 Dec 2006 22:16:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15FE043CB0 for ; Wed, 13 Dec 2006 22:14:55 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 175BD53131; Wed, 13 Dec 2006 17:16:27 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Wed, 13 Dec 2006 17:16:27 -0500 X-Sasl-enc: 4755GQWA1uVwnjS9NbzOmDkfEHo6vNkxJ5223w/s2Y9s 1166048186 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id EFB6FCCD9; Wed, 13 Dec 2006 17:16:25 -0500 (EST) Message-ID: <45807BB7.3070508@FreeBSD.org> Date: Wed, 13 Dec 2006 22:16:23 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list , Mike Tancsa Subject: Re: PCI sio card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 22:16:31 -0000 Hi, You may need to add a quirk to src/sys/dev/puc/pucdata.c and rebuild puc, to get the sio or uart drivers to attach correctly to the serial ports which are behind the bridge device on your PCI card. Some cards have their serial ports at different bus offsets/addresses behind the bridge, or use different clock multipliers. See the Dell RAC UART entries at the end of the file for an example. If NetBSD supports your card, then syncing up our pucdata with theirs may be the way to solve this. Regards, BMS From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 22:12:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E3F316A417; Wed, 13 Dec 2006 22:12:08 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id B54DD43CBC; Wed, 13 Dec 2006 22:10:29 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.8/8.13.8) with ESMTP id kBDMBv9B094375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 17:11:58 -0500 (EST) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Scott Long Date: Wed, 13 Dec 2006 17:11:50 -0500 User-Agent: KMail/1.9.5 References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131440.04076.mi+mx@aldan.algebra.com> <4580766A.600@samsco.org> In-Reply-To: <4580766A.600@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200612131711.50921.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88.4/2324/Wed Dec 13 11:04:08 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Thu, 14 Dec 2006 00:03:37 +0000 Cc: current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Dec 2006 22:12:08 -0000 ÓÅÒÅÄÁ 13 ÇÒÕÄÅÎØ 2006 16:53, Scott Long ÎÁÐÉÓÁ×: > And I say that FreeBSD shouldn't be a beta-tester for new, experimental > compiler features. We don't have to start using OpenMP in the base and no port will be _forced_ to use it either. But having a compiler _capable of it_ will be very good. Unless you deem the entire gcc-4.2 to be "new and experimental" (I think, 4.3 is such), your above-quoted argument is not valid. > I also say that words and opinions are cheaper than actions. Thank you very much, Scott, for this timely and uniquely insightful reminder. This important point is almost never raised on the FreeBSD mailing lists, which so often leads participants to think, that actions are cheaper than words and opinions. We are moving from gcc-3.x to gcc-4.1. Compared to _that_ move, the difference between 4.1 and 4.2 is not very large. If you think otherwise -- please say so explicitly. Thank you. -mi From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 00:40:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D09C616A4C8 for ; Thu, 14 Dec 2006 00:40:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F3DC43D3F for ; Thu, 14 Dec 2006 00:38:10 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so117524ana for ; Wed, 13 Dec 2006 16:39:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=PQKylmMLBrNS3piKStLHHXjpftXgYkMbtGtkDkm6OuPoM7NVlfzQTGPiBy7kYMyDTHjWV19LZbfrsqNLBKWhfMTRzNizl/YKcW4qErbd0YZQ4/vlpY8YTGnPi7e9Uzs9OMKHZJ7Y/MaLwVBM5ES/gOtHhluq6HqAwmv1EPgBQfM= Received: by 10.100.139.9 with SMTP id m9mr294606and.1166056781833; Wed, 13 Dec 2006 16:39:41 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 7sm2182108wrh.2006.12.13.16.39.39; Wed, 13 Dec 2006 16:39:40 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kBE0dEsl020634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Dec 2006 09:39:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kBE0dEdm020633; Thu, 14 Dec 2006 09:39:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 14 Dec 2006 09:39:14 +0900 From: Pyun YongHyeon To: Pascal Hofstee Message-ID: <20061214003914.GB20386@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: D-Link DGE-350T and if_sk (no go) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com 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 Dec 2006 00:40:06 -0000 On Wed, Dec 13, 2006 at 10:59:53PM +0100, Pascal Hofstee wrote: > I just acquired a new shiny D-Link DGE-350T (which according to sk(4) > is supported by FreeBSD) but unfortunately had to come to the > conclusion that i cannot get this card to actually send/receive any > actual packets. > > The device probes, attached and comes up perfectly, auto-negotiation > (properly) chooses 1000baseTX full-duplex and after that the device is > basically dead .. i can't get it to produce any actual traffic. > > Below is verbose dmesg output with ACPI disabled .. as i was unable to > get the desired info with ACPI enabled (because of a ACPI bad write > output storm) > > If anybody has any ideas on how to resolve this problem i am open for > suggestions and willing to test patches. > > ----[dmesg output]-------- > Copyright (c) 1992-2006 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 7.0-CURRENT #9: Tue Dec 12 13:42:43 CET 2006 > pascal@chekov.ufp.fli4l:/usr/obj/usr/src/sys/CHEKOV > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0cde000. > Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc0cde158. > Preloaded elf module "/boot/kernel/sound.ko" at 0xc0cde208. > Preloaded elf module "/boot/kernel/cpufreq.ko" at 0xc0cde2b4. > Calibrating clock(s) ... i8254 clock: 1193224 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 902052593 Hz > CPU: Intel Pentium III (902.05-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > Features=0x383f9ff [...] > found-> vendor=0x1186, dev=0x4b01, revid=0x11 It looks like second generation DGE-530T. > bus=0, slot=9, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) > lattimer=0x20 (960 ns), mingnt=0x17 (5750 ns), maxlat=0x1f (7750 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D1 D2 D3 current D0 > VPD Ident: DGE-530T Gigabit Ethernet Adapter > PN: DGE-530T > EC: Rev. 1.1 > MN: D-Link > SN: DGE530TBCD870 > CP: id 1, BAR16, off 0x3cc > RV: 0x99 > map[10]: type 1, range 32, base 0xde000000, size 14, enabled > map[14]: type 4, range 32, base 0xa800, size 8, enabled [...] > skc0: port 0xa800-0xa8ff mem > 0xde000000-0xde003fff irq 5 at device 9.0 on pci0 > skc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xde000000 > skc0: interrupt moderation is 100 us > skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) > skc0: chip ver = 0xb1 > skc0: chip rev = 0x09 > skc0: SK_EPROM0 = 0x10 > skc0: SRAM size = 0x010000 > sk0: on skc0 > sk0: using obsoleted if_watchdog interface > sk0: bpf attached > sk0: Ethernet address: 00:17:9a:bc:d8:70 > miibus0: on sk0 > e1000phy0: on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, > auto > skc0: [MPSAFE] If Tx side doesn't work at all it would show watchdog timeout message. Did you see that? If Rx doesn't work you wouldn't see interrupts on your NIC. Running a ping(8) on the other host to a system with sk(4) and watch interrupts section in "systat -vmstat 1" output. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 01:13:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02D3116A51B for ; Thu, 14 Dec 2006 01:13:53 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 055B543CB9 for ; Thu, 14 Dec 2006 01:11:57 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so646849nfc for ; Wed, 13 Dec 2006 17:13:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=omtauxkiBokEbv9/uM3Jrb+YHNvfVoQ5HNJYvS78W/6AKNicJYTVaockXbcxKKlMH/l7Pl6bYKdPD8XoHQT18EoHsa+S3f8nVbAQv7XFJCC9JWfCh00bjSTsK3UGjEMHnOvyZmHuymbYYV2PcAilrdoWxpXYZkzFelZMtm9l35o= Received: by 10.82.110.14 with SMTP id i14mr151311buc.1166058381277; Wed, 13 Dec 2006 17:06:21 -0800 (PST) Received: by 10.82.134.15 with HTTP; Wed, 13 Dec 2006 17:06:21 -0800 (PST) Message-ID: <3aaaa3a0612131706w5ae75edcvadd7958274a1e2e2@mail.gmail.com> Date: Thu, 14 Dec 2006 01:06:21 +0000 From: Chris To: "Andre Oppermann" In-Reply-To: <457F2D82.6000905@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F2D82.6000905@freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 01:13:53 -0000 On 12/12/06, Andre Oppermann wrote: > This is a patch adding automatic TCP send and receive socket buffer sizing. > Normally the socket buffers are static (either derived from global defaults > or set with setsockopt) and do not adapt to real network conditions. Two > things happen: a) your socket buffers are too small and you can't reach the > full potential of the network between both hosts; b) your socket buffers are > too big and you waste a lot of kernel memory for data just sitting around. > > With automatic TCP send and receive socket buffers we can start with a small > buffer and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > FreeBSD has a default 32K send socket buffer. This supports a maximal > transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > auto scaling and the default values below it supports 20Mbit/s at 100ms > and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > For the receive side it looks slightly better with a default of 64K buffer > size. > > The automatic send buffer sizing patch is currently running on one half of > the FTP.FreeBSD.ORG cluster w/o any problems so far. Against this machine > with the automatic receive buffer sizing patch I can download at 5.7MBytes > per second. Without patch it maxed out at 1.6MBytes per second as the delay > bandwidth product became equal to the static socket buffer size without hitting > the limits of the physical link between the machines. My test machine is about > 35ms from that FTP.FreeBSD.ORG and connected through a moderately loaded 100Mbit > Internet link. > > New sysctl's are: > > net.inet.tcp.sendbuf_auto=1 (enabled) > net.inet.tcp.sendbuf_inc=8192 (8K, step size) > net.inet.tcp.sendbuf_max=262144 (256K, growth limit) > net.inet.tcp.recvbuf_auto=1 (enabled) > net.inet.tcp.recvbuf_inc=16384 (16K, step size) > net.inet.tcp.recvbuf_max=262144 (256K, growth limit) > > The patch is available here (it may apply with some fuzz): > > http://people.freebsd.org/~andre/tcp_auto_buf-20061212.diff > > Any tests and test reports are very welcome. > > -- > Andre Hi does this patch work on 6.x? I used the send patch on 6.x and works great please make a 6.x patch thank you and I will happily test. Chris From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 02:59:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 785A616A415 for ; Thu, 14 Dec 2006 02:59:00 +0000 (UTC) (envelope-from freebsd@alaskaparadise.com) Received: from stargate.alaskaparadise.com (114-103-74-65.gci.net [65.74.103.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA22743CA4 for ; Thu, 14 Dec 2006 02:57:26 +0000 (GMT) (envelope-from freebsd@alaskaparadise.com) Received: by stargate.alaskaparadise.com (Postfix, from userid 0) id 3C02E45B9; Wed, 13 Dec 2006 17:58:58 -0900 (AKST) From: Beech Rintoul Organization: Alaska Paradise Travel To: freebsd-current@freebsd.org User-Agent: KMail/1.9.4 References: <457719CF.3040402@errno.com> <20061209162044.GB34146@lor.one-eyed-alien.net> In-Reply-To: <20061209162044.GB34146@lor.one-eyed-alien.net> MIME-Version: 1.0 Date: Wed, 13 Dec 2006 17:58:40 -0900 Content-Type: multipart/signed; boundary="nextPart1305707.igaQ9VqUri"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612131758.56538.freebsd@alaskaparadise.com> Subject: Re: CFT: new ath hal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 02:59:00 -0000 --nextPart1305707.igaQ9VqUri Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, Dec 06, 2006 at 11:28:15AM -0800, Sam Leffler wrote: > I've placed a new hal out for testing. I'd like to commit it after more > folks work with it so feedback would be helpful. > > http://people.freebsd.org/~sam/ath_hal-20061205.tgz > > There are numerous small bugs fixed in this version but the main change > is a split of the descriptor state so that s/w state can be placed in > cached memory when h/w state is in uncached memory. This results in > noticeable performance gains on certain architectures. Works for me on -CURRENT. ath0: mem 0xfedf0000-0xfedfffff irq 9 at device 12.0 on pci0 ath0: Ethernet address: 00:11:95:bf:c0:33 ath0: mac 5.9 phy 4.3 radio 3.6 Beech =2D-=20 =2D------------------------------------------------------------------------= =2D------------- Beech Rintoul - Sys. Administrator - beech@alaskaparadise.com /"\ ASCII Ribbon Campaign | Alaska Paradise Travel \ / - NO HTML/RTF in e-mail | 201 East 9Th Avenue Ste.310 X - NO Word docs in e-mail | Anchorage, AK 99501 / \ - Please visit Alaska Paradise - http://www.alaskaparadise.com =2D------------------------------------------------------------------------= =2D------------- =2D-=20 =2D------------------------------------------------------------------------= =2D------------- Beech Rintoul - Sys. Administrator - beech@alaskaparadise.com /"\ ASCII Ribbon Campaign | Alaska Paradise Travel \ / - NO HTML/RTF in e-mail | 201 East 9Th Avenue Ste.310 X - NO Word docs in e-mail | Anchorage, AK 99501 / \ - Please visit Alaska Paradise - http://www.alaskaparadise.com =2D------------------------------------------------------------------------= =2D------------- --nextPart1305707.igaQ9VqUri Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFgL3wR5sEeCt9j00RAmzhAKCgHOt5QkNlBRnwFRo7s/3uW7WjDgCgo48M 6q+EHlPzKI08o3mUIUVEdME= =cRCb -----END PGP SIGNATURE----- --nextPart1305707.igaQ9VqUri-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 05:22:56 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DA5516A49E for ; Thu, 14 Dec 2006 05:22:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 413A543CB0 for ; Thu, 14 Dec 2006 05:21:22 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 10155 invoked by uid 399); 14 Dec 2006 05:22:54 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 14 Dec 2006 05:22:54 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4580DFAB.3080601@FreeBSD.org> Date: Wed, 13 Dec 2006 21:22:51 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061125) MIME-Version: 1.0 To: Mikhail Teterin References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131440.04076.mi+mx@aldan.algebra.com> <4580766A.600@samsco.org> <200612131711.50921.mi+mx@aldan.algebra.com> In-Reply-To: <200612131711.50921.mi+mx@aldan.algebra.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 05:22:56 -0000 Mikhail Teterin wrote: > ?????? 13 ??????? 2006 16:53, Scott Long ???????: >> And I say that FreeBSD shouldn't be a beta-tester for new, experimental >> compiler features. > > We don't have to start using OpenMP in the base and no port will be _forced_ > to use it either. But having a compiler _capable of it_ will be very good. > > Unless you deem the entire gcc-4.2 to be "new and experimental" (I think, 4.3 > is such), your above-quoted argument is not valid. Let's start over. I have a core 2 duo box so I'm interested, and I agree with you that at least 2 cores is going to be the "norm" sooner than later. So can you tell us what the benefits and risks are of 4.2 vs. 4.1? I think someone already put forward the idea that if we were to adopt 4.2 that we'd have a longer support cycle, which sounds like a good thing to me; but I'm nowhere near an expert. >> I also say that words and opinions are cheaper than actions. > > Thank you very much, Scott, for this timely and uniquely insightful reminder. > This important point is almost never raised on the FreeBSD mailing lists, > which so often leads participants to think, that actions are cheaper than > words and opinions. I can certainly appreciate your frustration, but the problem we face is that there is no limit to the number of people who are sure that they know what the right thing to do is, as long as someone else is doing the work. As I'm sure you can imagine, that gets tiresome really fast when one is busy actually _doing_ the work. You make a good point in that it's not too late to at least consider moving to 4.2 instead, so why don't you come up with some more concrete evidence to back your claim. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 05:28:04 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED69A16A403; Thu, 14 Dec 2006 05:28:04 +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 F348743CA4; Thu, 14 Dec 2006 05:26:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBE5RlJV018728; Wed, 13 Dec 2006 22:27:52 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4580E0D1.40605@samsco.org> Date: Wed, 13 Dec 2006 22:27:45 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Doug Barton References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131440.04076.mi+mx@aldan.algebra.com> <4580766A.600@samsco.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> In-Reply-To: <4580DFAB.3080601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Mikhail Teterin , current@FreeBSD.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 05:28:05 -0000 Doug Barton wrote: > Mikhail Teterin wrote: >> ?????? 13 ??????? 2006 16:53, Scott Long ???????: >>> And I say that FreeBSD shouldn't be a beta-tester for new, experimental >>> compiler features. >> We don't have to start using OpenMP in the base and no port will be _forced_ >> to use it either. But having a compiler _capable of it_ will be very good. >> >> Unless you deem the entire gcc-4.2 to be "new and experimental" (I think, 4.3 >> is such), your above-quoted argument is not valid. > > Let's start over. I have a core 2 duo box so I'm interested, and I > agree with you that at least 2 cores is going to be the "norm" sooner > than later. So can you tell us what the benefits and risks are of 4.2 > vs. 4.1? I think someone already put forward the idea that if we were > to adopt 4.2 that we'd have a longer support cycle, which sounds like > a good thing to me; but I'm nowhere near an expert. > >>> I also say that words and opinions are cheaper than actions. >> Thank you very much, Scott, for this timely and uniquely insightful reminder. >> This important point is almost never raised on the FreeBSD mailing lists, >> which so often leads participants to think, that actions are cheaper than >> words and opinions. > > I can certainly appreciate your frustration, but the problem we face > is that there is no limit to the number of people who are sure that > they know what the right thing to do is, as long as someone else is > doing the work. As I'm sure you can imagine, that gets tiresome really > fast when one is busy actually _doing_ the work. > > You make a good point in that it's not too late to at least consider > moving to 4.2 instead, so why don't you come up with some more > concrete evidence to back your claim. > > Doug > It should be noted that the final line of my email was a poke at myself as well, since all that I have to provide is an opinion, while others are doing the actual work. Scott From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 07:43:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E43716A407 for ; Thu, 14 Dec 2006 07:43:45 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FE3643CC0 for ; Thu, 14 Dec 2006 07:42:02 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so380415uge for ; Wed, 13 Dec 2006 23:43:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=U+gQ7sJEGbPc8PmZKQ7cBZkn/a8AzOO7dts0NmCPjwtupaK2UVqruz26FREfMOvXUjqYKApA44rZ/smQiI6fEdtdIQX7VFwOP9dNAYIhSncKB4Q2wOgemo/0XMjiWOZUWu3ZxKc2WzMo4o+Hc/4cRjJRXb7wmcWTNmBKLY0HXNw= Received: by 10.66.216.20 with SMTP id o20mr915730ugg.1166082215917; Wed, 13 Dec 2006 23:43:35 -0800 (PST) Received: from ?192.168.0.21? ( [87.166.81.163]) by mx.google.com with ESMTP id i39sm2101427ugd.2006.12.13.23.43.35; Wed, 13 Dec 2006 23:43:35 -0800 (PST) From: Pascal Hofstee To: pyunyh@gmail.com In-Reply-To: <20061214003914.GB20386@cdnetworks.co.kr> References: <20061214003914.GB20386@cdnetworks.co.kr> Content-Type: text/plain Date: Thu, 14 Dec 2006 08:43:33 +0100 Message-Id: <1166082213.1640.10.camel@chekov> Mime-Version: 1.0 X-Mailer: Evolution 2.9.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: D-Link DGE-350T and if_sk (no go) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 07:43:45 -0000 On Thu, 2006-12-14 at 09:39 +0900, Pyun YongHyeon wrote: > If Tx side doesn't work at all it would show watchdog timeout message. > Did you see that? If Rx doesn't work you wouldn't see interrupts on > your NIC. Running a ping(8) on the other host to a system with sk(4) > and watch interrupts section in "systat -vmstat 1" output. I am not seeing any watchdog timeouts occuring so it seems that the Tx side is working ... which would seem to suggest the Rx side isn't working. I'll bug my neighbour for some pings this evening and send the resulting "systat -vmstat 1" output. -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 07:48:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A7FC16A4A0 for ; Thu, 14 Dec 2006 07:48:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F3C43CD5 for ; Thu, 14 Dec 2006 07:46:58 +0000 (GMT) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.62) with esmtp (envelope-from ) id <1GulKK-0004XY-3O>; Thu, 14 Dec 2006 08:48:24 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.62) with esmtpsa (envelope-from ) id <1GulKK-0003pm-2G>; Thu, 14 Dec 2006 08:48:24 +0100 Message-ID: <458101C4.8090106@zedat.fu-berlin.de> Date: Thu, 14 Dec 2006 08:48:20 +0100 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: Mikhail Teterin References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131440.04076.mi+mx@aldan.algebra.com> <4580766A.600@samsco.org> <200612131711.50921.mi+mx@aldan.algebra.com> In-Reply-To: <200612131711.50921.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 130.133.86.198 Cc: current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 07:48:46 -0000 Mikhail Teterin wrote: > =D3=C5=D2=C5=C4=C1 13 =C7=D2=D5=C4=C5=CE=D8 2006 16:53, Scott Long =CE=C1= =D0=C9=D3=C1=D7: >> And I say that FreeBSD shouldn't be a beta-tester for new, experimenta= l >> compiler features. >=20 > We don't have to start using OpenMP in the base and no port will be _fo= rced_=20 > to use it either. But having a compiler _capable of it_ will be very go= od.=20 I would second that. Having a compiler with features aiming modern=20 omputer design wouldn't be a disadvantage and many people, like me,=20 prefere using the systems compiler instead of one out of the ports. >=20 > Unless you deem the entire gcc-4.2 to be "new and experimental" (I thin= k, 4.3=20 > is such), your above-quoted argument is not valid. I'm not very familiar with the compiler development, but it seemed to me = gcc 4.1 was like a interim solution. This arose due to the fast=20 appeareance of it's successor ... >=20 >> I also say that words and opinions are cheaper than actions. >=20 > Thank you very much, Scott, for this timely and uniquely insightful rem= inder.=20 > This important point is almost never raised on the FreeBSD mailing list= s,=20 > which so often leads participants to think, that actions are cheaper th= an=20 > words and opinions. >=20 > We are moving from gcc-3.x to gcc-4.1. Compared to _that_ move, the > difference between 4.1 and 4.2 is not very large. If you think otherwis= e --=20 > please say so explicitly. Thank you. >=20 > -mi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 09:22:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F89B16A416 for ; Thu, 14 Dec 2006 09:22:11 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F9A143CAB for ; Thu, 14 Dec 2006 09:20:34 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so398485uge for ; Thu, 14 Dec 2006 01:22:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=cw3tUb8++JxjPcNPxD1N1BvehxPTbq17qkHG58MkupwPv09PfsigdBHC9OhSysBo3Z/7IpCEglXm15ryaNEqu+gGMfE+T7RO4o60XPUtPESid/fPYwIdVvihxpIZyEw4u8DnxUdlMQDJa0AGld2jkIgKJmrS2cnUt/83ls5lb2k= Received: by 10.66.243.4 with SMTP id q4mr1117026ugh.1166088127931; Thu, 14 Dec 2006 01:22:07 -0800 (PST) Received: from ?192.168.0.21? ( [87.166.81.163]) by mx.google.com with ESMTP id k28sm2195653ugd.2006.12.14.01.22.07; Thu, 14 Dec 2006 01:22:07 -0800 (PST) From: Pascal Hofstee To: "Bruce M. Simpson" In-Reply-To: <45808382.7000802@FreeBSD.org> References: <45807C05.8040703@FreeBSD.org> <1166050020.1640.6.camel@chekov> <45808382.7000802@FreeBSD.org> Content-Type: text/plain Date: Thu, 14 Dec 2006 10:22:06 +0100 Message-Id: <1166088126.1125.12.camel@chekov> Mime-Version: 1.0 X-Mailer: Evolution 2.9.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: D-Link DGE-350T and if_sk (no go) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 09:22:11 -0000 On Wed, 2006-12-13 at 22:49 +0000, Bruce M. Simpson wrote: > Yes. It looks like (from dmesg) that your card is a Yukon 1. I think I > managed to get the sk driver to attach to the PCI-e Yukon in my ASUS > machine and had similar problems, though this was many months ago. The > msk driver might work for you. Well .. i got around to trying the msk driver this morning and unfortunately (after adding the pci-id to the msk driver) the card probes, but doesn't attach because of the msk-driver rejecting device-id's that are't Yukon II chips. (the if-section below in if_msk.c) if (sc->msk_hw_id < CHIP_ID_YUKON_XL || sc->msk_hw_id > CHIP_ID_YUKON_FE) { device_printf(dev, "unknown device: id=0x%02x, rev=0x%02x\n", sc->msk_hw_id, sc->msk_hw_rev); error = ENXIO; goto fail; } My DGE-530T however has id=0xb1, rev=0x09 which seems to be what if_msk considers CHIP_ID_YUKON_LITE. So it looks that without further hacking on the msk driver trying to use if_msk instead of if_sk is an excercise in futility, though it was definitely worth a shot. I'll be watching the interrupts as soon as i can get a hold of my neighbour which should probably be sometime later today. If in the meanwhile people have other suggestions i might try, send them my way and i'll give it a shot :) -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 10:52:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9CD616A412 for ; Thu, 14 Dec 2006 10:52:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A2CB43CA5 for ; Thu, 14 Dec 2006 10:50:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81988 invoked from network); 14 Dec 2006 10:39:18 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2006 10:39:18 -0000 Message-ID: <45812CDE.7000103@freebsd.org> Date: Thu, 14 Dec 2006 11:52:14 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Chris References: <457F2D82.6000905@freebsd.org> <3aaaa3a0612131706w5ae75edcvadd7958274a1e2e2@mail.gmail.com> In-Reply-To: <3aaaa3a0612131706w5ae75edcvadd7958274a1e2e2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 10:52:29 -0000 Chris wrote: > On 12/12/06, Andre Oppermann wrote: >> This is a patch adding automatic TCP send and receive socket buffer >> sizing. >> Normally the socket buffers are static (either derived from global >> defaults >> or set with setsockopt) and do not adapt to real network conditions. Two >> things happen: a) your socket buffers are too small and you can't >> reach the >> full potential of the network between both hosts; b) your socket >> buffers are >> too big and you waste a lot of kernel memory for data just sitting >> around. >> >> With automatic TCP send and receive socket buffers we can start with a >> small >> buffer and quickly grow it in parallel with the TCP congestion window >> to match >> real network conditions. >> >> FreeBSD has a default 32K send socket buffer. This supports a maximal >> transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- >> continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer >> auto scaling and the default values below it supports 20Mbit/s at 100ms >> and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. >> For the receive side it looks slightly better with a default of 64K >> buffer >> size. >> >> The automatic send buffer sizing patch is currently running on one >> half of >> the FTP.FreeBSD.ORG cluster w/o any problems so far. Against this >> machine >> with the automatic receive buffer sizing patch I can download at >> 5.7MBytes >> per second. Without patch it maxed out at 1.6MBytes per second as the >> delay >> bandwidth product became equal to the static socket buffer size >> without hitting >> the limits of the physical link between the machines. My test machine >> is about >> 35ms from that FTP.FreeBSD.ORG and connected through a moderately >> loaded 100Mbit >> Internet link. >> >> New sysctl's are: >> >> net.inet.tcp.sendbuf_auto=1 (enabled) >> net.inet.tcp.sendbuf_inc=8192 (8K, step size) >> net.inet.tcp.sendbuf_max=262144 (256K, growth limit) >> net.inet.tcp.recvbuf_auto=1 (enabled) >> net.inet.tcp.recvbuf_inc=16384 (16K, step size) >> net.inet.tcp.recvbuf_max=262144 (256K, growth limit) >> >> The patch is available here (it may apply with some fuzz): >> >> http://people.freebsd.org/~andre/tcp_auto_buf-20061212.diff >> >> Any tests and test reports are very welcome. >> >> -- >> Andre > > Hi does this patch work on 6.x? I used the send patch on 6.x and works > great please make a 6.x patch thank you and I will happily test. No, this patch doesn't work on 6.x. It makes changes to struct tcpcb to add two additional fields. This requires netstat(1) to be recompiled and is a ABI change. However I've got a number of requests for 6.x patch so I may make one anyway. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 14:29:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C216216A494; Thu, 14 Dec 2006 14:29:04 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E94A43FC8; Thu, 14 Dec 2006 14:15:55 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.8/8.13.7) with ESMTP id kBEEHQ3u022902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Dec 2006 09:17:26 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.8/8.13.7/Submit) id kBEEHPE7022901; Thu, 14 Dec 2006 09:17:25 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Doug Barton Date: Thu, 14 Dec 2006 09:17:24 -0500 User-Agent: KMail/1.9.5 References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> In-Reply-To: <4580DFAB.3080601@FreeBSD.org> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" X-Mailman-Approved-At: Thu, 14 Dec 2006 15:21:31 +0000 Cc: current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 14:29:04 -0000 On Thursday 14 December 2006 00:22, Doug Barton wrote: = Let's start over. I have a core 2 duo box so I'm interested, and I = agree with you that at least 2 cores is going to be the "norm" sooner = than later. So can you tell us what the benefits and risks are of 4.2 = vs. 4.1? If you follow the AMD-links in my original e-mail: > http://www.openmp.org/ > http://gcc.gnu.org/projects/gomp/ > http://developer.amd.com/article_print.jsp?id=79 > http://developer.amd.com/article_print.jsp?id=82 you can see examples of using OpenMP. It makes parallel programming (in C, C++, and Fortran) much easier and more portable -- threads/mutexes/barriers/CPU-accounting is created and managed by the implementation... I, for one, look forward to messing with sort(1) and qsort(3) -- there is ample room for parallization there. Nothing one could not do manually with pthreads, but nicer and more straightforward... Although commercial compilers (like Intel's icc for Windows and Linux, or Sun Studio on Solaris, or Visual Studio on Windows) have supported OpenMP pragmas for a while (icc even allows parallelizing accross multiple machines), gcc-4.2 is the first release of GCC that supports it (with `-fopenmp' flag). I anticipate, "out-of-the-box" OpenMP support will soon be one of the required "check-boxes" for an OS to be considered for many things... Scott may well be right suspecting that _this support_ may be of beta-quality at the moment, but that's not a valid argument for rejecting 4.2 in favor of 4.1. Since we are migrating from 3.x to 4.x _anyway_, may as well target 4.2, unless it is worse than 4.1 in some parts _which we currently use_. Even if OpenMP-support turns out to be subpar in 4.2, it will improve with time, and we'll obtain the improvements via the next move from 4.2.x to 4.2.x+n. Such moves will be easier than going from 4.1.y to 4.2.z. = I think someone already put forward the idea that if we were = to adopt 4.2 that we'd have a longer support cycle, which sounds like = a good thing to me; but I'm nowhere near an expert. Yes, that's another plus -- GCC folks already refuse to do anything about problems with 3.4.x, which is the base compiler in our most recent release :-( -mi From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 15:40:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AEEC16A47B for ; Thu, 14 Dec 2006 15:40:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 719A643E5B for ; Thu, 14 Dec 2006 15:34:27 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Guscm-00027u-76 for freebsd-current@freebsd.org; Thu, 14 Dec 2006 16:35:56 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Dec 2006 16:35:56 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Dec 2006 16:35:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 14 Dec 2006 16:35:41 +0100 Lines: 14 Message-ID: References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <200612140917.25523@aldan> Sender: news Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 15:40:31 -0000 Mikhail Teterin wrote: > Although commercial compilers (like Intel's icc for Windows and Linux, or Sun > Studio on Solaris, or Visual Studio on Windows) have supported OpenMP pragmas > for a while (icc even allows parallelizing accross multiple machines), > gcc-4.2 is the first release of GCC that supports it (with `-fopenmp' flag). > > I anticipate, "out-of-the-box" OpenMP support will soon be one of the > required "check-boxes" for an OS to be considered for many things... For what it's worth: +1. It's going to be practically required even for medium-performance applications as CPU clock rate stagnate and more cores are grown. I've recently seen a 16-cpu x86 server in 1U! (granted, 8 of those are hyperthreaded "CPUs" ;) ) From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 15:50:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9755816A412 for ; Thu, 14 Dec 2006 15:50:00 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7DF243CA7 for ; Thu, 14 Dec 2006 15:48:05 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id kBEFnTes047354; Thu, 14 Dec 2006 07:49:29 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id kBEFnTW9047353; Thu, 14 Dec 2006 07:49:29 -0800 (PST) (envelope-from rizzo) Date: Thu, 14 Dec 2006 07:49:29 -0800 From: Luigi Rizzo To: Ivan Voras Message-ID: <20061214074929.B47100@xorpc.icir.org> References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ivoras@fer.hr on Thu, Dec 14, 2006 at 04:35:41PM +0100 Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 15:50:00 -0000 On Thu, Dec 14, 2006 at 04:35:41PM +0100, Ivan Voras wrote: > Mikhail Teterin wrote: > > > Although commercial compilers (like Intel's icc for Windows and Linux, or Sun > > Studio on Solaris, or Visual Studio on Windows) have supported OpenMP pragmas > > for a while (icc even allows parallelizing accross multiple machines), > > gcc-4.2 is the first release of GCC that supports it (with `-fopenmp' flag). > > > > I anticipate, "out-of-the-box" OpenMP support will soon be one of the > > required "check-boxes" for an OS to be considered for many things... > > For what it's worth: +1. It's going to be practically required even for > medium-performance applications as CPU clock rate stagnate and more > cores are grown. I've recently seen a 16-cpu x86 server in 1U! (granted, > 8 of those are hyperthreaded "CPUs" ;) ) and the other 8 are overheated CPUs ? From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 15:53:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2688E16A403; Thu, 14 Dec 2006 15:53:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CCE43CAB; Thu, 14 Dec 2006 15:51:38 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEFr1hI025126; Thu, 14 Dec 2006 10:53:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEFr1De003215; Thu, 14 Dec 2006 10:53:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 81A6873034; Thu, 14 Dec 2006 10:53:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214155301.81A6873034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 10:53:01 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 15:53:25 -0000 TB --- 2006-12-14 15:29:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 15:29:32 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-14 15:29:32 - cleaning the object tree TB --- 2006-12-14 15:30:02 - checking out the source tree TB --- 2006-12-14 15:30:02 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-14 15:30:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 15:34:41 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 15:34:41 - cd /src TB --- 2006-12-14 15:34:41 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 15:34:43 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 15:53:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 15:53:01 - ERROR: failed to build world TB --- 2006-12-14 15:53:01 - tinderbox aborted TB --- 0.55 user 2.01 system 1408.50 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 15:53:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44EDF16A407; Thu, 14 Dec 2006 15:53:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C4943CAC; Thu, 14 Dec 2006 15:51:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEFr6eP098846; Thu, 14 Dec 2006 10:53:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEFr5Su067634; Thu, 14 Dec 2006 10:53:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C6D1D73036; Thu, 14 Dec 2006 10:53:05 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214155305.C6D1D73036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 10:53:05 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner3 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 15:53:25 -0000 TB --- 2006-12-14 15:24:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 15:24:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-14 15:24:00 - cleaning the object tree TB --- 2006-12-14 15:24:32 - checking out the source tree TB --- 2006-12-14 15:24:32 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-14 15:24:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 15:34:41 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 15:34:41 - cd /src TB --- 2006-12-14 15:34:41 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 15:34:43 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 15:53:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 15:53:05 - ERROR: failed to build world TB --- 2006-12-14 15:53:05 - tinderbox aborted TB --- 0.70 user 2.38 system 1745.19 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 16:24:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBC6716A98D; Thu, 14 Dec 2006 16:24:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B561043D67; Thu, 14 Dec 2006 16:21:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEGMjUN006205; Thu, 14 Dec 2006 11:22:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEGMijL001123; Thu, 14 Dec 2006 11:22:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 52CCA73034; Thu, 14 Dec 2006 11:22:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214162244.52CCA73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 11:22:44 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm 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: Thu, 14 Dec 2006 16:24:12 -0000 TB --- 2006-12-14 15:55:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 15:55:01 - starting HEAD tinderbox run for arm/arm TB --- 2006-12-14 15:55:01 - cleaning the object tree TB --- 2006-12-14 15:55:32 - checking out the source tree TB --- 2006-12-14 15:55:32 - cd /tinderbox/HEAD/arm/arm TB --- 2006-12-14 15:55:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 16:04:48 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 16:04:48 - cd /src TB --- 2006-12-14 16:04:48 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 16:04:50 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 16:22:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 16:22:43 - ERROR: failed to build world TB --- 2006-12-14 16:22:43 - tinderbox aborted TB --- 0.45 user 1.61 system 1662.91 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 16:24:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64C6316AA1E; Thu, 14 Dec 2006 16:24:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 283E843CA6; Thu, 14 Dec 2006 16:21:54 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEGNT9s029015; Thu, 14 Dec 2006 11:23:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEGNTZn089826; Thu, 14 Dec 2006 11:23:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5664F73034; Thu, 14 Dec 2006 11:23:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214162329.5664F73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 11:23:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Thu, 14 Dec 2006 16:24:16 -0000 TB --- 2006-12-14 15:55:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 15:55:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-14 15:55:01 - cleaning the object tree TB --- 2006-12-14 15:55:53 - checking out the source tree TB --- 2006-12-14 15:55:53 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-14 15:55:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 16:04:48 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 16:04:48 - cd /src TB --- 2006-12-14 16:04:48 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 16:04:50 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 16:23:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 16:23:29 - ERROR: failed to build world TB --- 2006-12-14 16:23:29 - tinderbox aborted TB --- 0.88 user 3.44 system 1708.23 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 16:32:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9906016A4D4 for ; Thu, 14 Dec 2006 16:32:25 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4971343DB6 for ; Thu, 14 Dec 2006 16:29:19 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from ls242.t-com.hr (ls242.t-com.hr [195.29.150.134]) by ls405.t-com.hr (Postfix) with ESMTP id C79F0147FB6; Thu, 14 Dec 2006 17:30:10 +0100 (CET) Received: from ls242.t-com.hr (localhost.localdomain [127.0.0.1]) by ls242.t-com.hr (Qmlai) with ESMTP id 9181010F804D; Thu, 14 Dec 2006 17:30:10 +0100 (CET) Received: from ls242.t-com.hr (localhost.localdomain [127.0.0.1]) by ls242.t-com.hr (Qmlai) with ESMTP id 7987110F8056; Thu, 14 Dec 2006 17:30:10 +0100 (CET) X-Envelope-Sender-Info: qNMqIwJL6pMxrLsv6Bv6Q8F59/kSM4ZBdZBv90IK0ovKYW+NL8qJhtwp0O8kWM3b X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.102] (83-131-105-50.adsl.net.t-com.hr [83.131.105.50])by ls242.t-com.hr (Qmali) with ESMTP id 421906C0055; Thu, 14 Dec 2006 17:30:10 +0100 (CET) Message-ID: <45817C16.6060708@fer.hr> Date: Thu, 14 Dec 2006 17:30:14 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Luigi Rizzo References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921 .mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214074929.B47100@xorpc.icir.org> In-Reply-To: <20061214074929.B47100@xorpc.icir.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:P L:N SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:3.6.1039(14872.003) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 16:32:25 -0000 Luigi Rizzo wrote: > On Thu, Dec 14, 2006 at 04:35:41PM +0100, Ivan Voras wrote: >> For what it's worth: +1. It's going to be practically required even for >> medium-performance applications as CPU clock rate stagnate and more >> cores are grown. I've recently seen a 16-cpu x86 server in 1U! (granted, >> 8 of those are hyperthreaded "CPUs" ;) ) > > and the other 8 are overheated CPUs ? I see you're familiar with that product line :) From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 16:54:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD7A416A492; Thu, 14 Dec 2006 16:54:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C8A643DA6; Thu, 14 Dec 2006 16:48:51 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEGoEgH032867; Thu, 14 Dec 2006 11:50:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEGoEIG066853; Thu, 14 Dec 2006 11:50:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 33EB973034; Thu, 14 Dec 2006 11:50:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214165014.33EB973034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 11:50:14 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 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: Thu, 14 Dec 2006 16:54:28 -0000 TB --- 2006-12-14 16:22:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 16:22:44 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-14 16:22:44 - cleaning the object tree TB --- 2006-12-14 16:23:11 - checking out the source tree TB --- 2006-12-14 16:23:11 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-14 16:23:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 16:31:58 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 16:31:58 - cd /src TB --- 2006-12-14 16:31:58 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 16:32:00 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 16:50:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 16:50:13 - ERROR: failed to build world TB --- 2006-12-14 16:50:13 - tinderbox aborted TB --- 0.84 user 2.73 system 1649.49 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 16:54:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDF8B16A4C9; Thu, 14 Dec 2006 16:54:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB74643CF7; Thu, 14 Dec 2006 16:49:04 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEGoLF8032876; Thu, 14 Dec 2006 11:50:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEGoL83066955; Thu, 14 Dec 2006 11:50:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0003373036; Thu, 14 Dec 2006 11:50:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214165021.0003373036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 11:50:20 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 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: Thu, 14 Dec 2006 16:54:34 -0000 TB --- 2006-12-14 16:23:29 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 16:23:29 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-14 16:23:29 - cleaning the object tree TB --- 2006-12-14 16:23:56 - checking out the source tree TB --- 2006-12-14 16:23:56 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-14 16:23:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 16:31:58 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 16:31:58 - cd /src TB --- 2006-12-14 16:31:58 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 16:32:00 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 16:50:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 16:50:20 - ERROR: failed to build world TB --- 2006-12-14 16:50:20 - tinderbox aborted TB --- 0.74 user 2.55 system 1611.27 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 17:38:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83CA116A47B; Thu, 14 Dec 2006 17:38:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EB6F44258; Thu, 14 Dec 2006 17:16:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEHIGtv037976; Thu, 14 Dec 2006 12:18:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEHIGcX067075; Thu, 14 Dec 2006 12:18:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5552873034; Thu, 14 Dec 2006 12:18:16 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214171816.5552873034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 12:18:16 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 17:38:23 -0000 TB --- 2006-12-14 16:50:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 16:50:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-12-14 16:50:21 - cleaning the object tree TB --- 2006-12-14 16:51:02 - checking out the source tree TB --- 2006-12-14 16:51:02 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-12-14 16:51:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 16:59:25 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 16:59:25 - cd /src TB --- 2006-12-14 16:59:25 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 16:59:26 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 17:18:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 17:18:15 - ERROR: failed to build world TB --- 2006-12-14 17:18:15 - tinderbox aborted TB --- 0.66 user 2.40 system 1674.91 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 17:40:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E771B16A562; Thu, 14 Dec 2006 17:40:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B2F44432; Thu, 14 Dec 2006 17:20:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEHLrkT023467; Thu, 14 Dec 2006 12:21:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEHLrri064422; Thu, 14 Dec 2006 12:21:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EC95073034; Thu, 14 Dec 2006 12:21:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214172152.EC95073034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 12:21:52 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 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: Thu, 14 Dec 2006 17:40:01 -0000 TB --- 2006-12-14 16:50:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 16:50:14 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-14 16:50:14 - cleaning the object tree TB --- 2006-12-14 16:50:51 - checking out the source tree TB --- 2006-12-14 16:50:51 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-14 16:50:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 16:59:25 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 16:59:25 - cd /src TB --- 2006-12-14 16:59:25 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 16:59:26 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 17:21:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 17:21:52 - ERROR: failed to build world TB --- 2006-12-14 17:21:52 - tinderbox aborted TB --- 0.66 user 2.73 system 1898.63 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 17:40:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D9D116A5D0; Thu, 14 Dec 2006 17:40:17 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45A774469C; Thu, 14 Dec 2006 17:22:03 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id E80811CC2F; Thu, 14 Dec 2006 12:23:23 -0500 (EST) Date: Thu, 14 Dec 2006 12:23:23 -0500 From: Adam McDougall To: Colin Percival Message-ID: <20061214172323.GP1011@egr.msu.edu> References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> <20061210014924.GU81923@egr.msu.edu> <457B7084.9070409@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457B7084.9070409@freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 17:40:18 -0000 On Sat, Dec 09, 2006 at 06:27:16PM -0800, Colin Percival wrote: Adam McDougall wrote: > I just tested tcp.closed with 3 seconds, down from 15 earlier but both were > unsuccessful. I will look at the other options as well, but do you have any explanation > for why portsnap would use wildly randomish local ports that overlap too quickly > when fetch does not? Is that a kernel controlled behavior that I can adjust? Try setting net.inet.ip.portrange.randomized=0. This shouldn't make any difference, but it might. Colin Percival Actually that did work, I thought I had tried it before but maybe not. What I've found is when randomized=1, portsnap will use random ports for the first portion of connections: # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... using portsnap1.FreeBSD.org. Fetching snapshot tag... done. Fetching snapshot metadata... done. Updating from Sat Mar 25 06:58:08 EST 2006 to Thu Dec 14 09:39:43 EST 2006. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 4 metadata files... done. Then regardless of randomized=0 or 1, the next part will use sequential local port allocations which are likely to conflict with the previous batch of connections: Fetching 8765 patches.....10....20....3(etc) When I have randomized=0, the first portion uses sequential ports and after several runs of re-downloading the same 8765 patches, it seems to work fine every time. I made a backup copy of /var/db/portsnap so I could repeat the fetch over and over for testing. Any idea why portsnap uses sequential ports foe the Fetching stage when the kernel has randomized=1? I am pleased that the workaround functions, but it would be nice to understand if something needs to be fixed so I don't need it. From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 17:46:36 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2B4A16A6B5; Thu, 14 Dec 2006 17:46:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E77043CF3; Thu, 14 Dec 2006 17:44:55 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEHkUlm031142; Thu, 14 Dec 2006 12:46:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEHkUxt001818; Thu, 14 Dec 2006 12:46:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8F4CB73036; Thu, 14 Dec 2006 12:46:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214174630.8F4CB73036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 12:46:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 17:46:36 -0000 TB --- 2006-12-14 17:18:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 17:18:16 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-14 17:18:16 - cleaning the object tree TB --- 2006-12-14 17:18:29 - checking out the source tree TB --- 2006-12-14 17:18:29 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-14 17:18:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 17:28:23 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 17:28:23 - cd /src TB --- 2006-12-14 17:28:23 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 17:28:24 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 17:46:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 17:46:30 - ERROR: failed to build world TB --- 2006-12-14 17:46:30 - tinderbox aborted TB --- 0.30 user 0.54 system 1694.17 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 17:46:36 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55FD616A6BC; Thu, 14 Dec 2006 17:46:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8C8243CF1; Thu, 14 Dec 2006 17:44:54 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEHkUIF042655; Thu, 14 Dec 2006 12:46:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEHkUXC034482; Thu, 14 Dec 2006 12:46:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5BC4973034; Thu, 14 Dec 2006 12:46:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214174630.5BC4973034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 12:46:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 17:46:36 -0000 TB --- 2006-12-14 17:21:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 17:21:53 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-14 17:21:53 - cleaning the object tree TB --- 2006-12-14 17:22:09 - checking out the source tree TB --- 2006-12-14 17:22:09 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-14 17:22:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 17:28:23 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 17:28:23 - cd /src TB --- 2006-12-14 17:28:23 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 17:28:24 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 17:46:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 17:46:30 - ERROR: failed to build world TB --- 2006-12-14 17:46:30 - tinderbox aborted TB --- 0.27 user 0.57 system 1476.95 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 18:08:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2050516A494 for ; Thu, 14 Dec 2006 18:08:37 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5892143F8B for ; Thu, 14 Dec 2006 17:59:02 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2006 10:00:31 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kBEI0VrL008082 for ; Thu, 14 Dec 2006 10:00:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBEI0B7D007580 for ; Thu, 14 Dec 2006 10:00:30 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 10:00:27 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 10:00:27 -0800 Message-ID: <45819115.9060702@cisco.com> Date: Thu, 14 Dec 2006 12:59:49 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <457EA7E3.2010302@cisco.com> In-Reply-To: <457EA7E3.2010302@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2006 18:00:27.0254 (UTC) FILETIME=[BC4E7160:01C71FA9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6244; t=1166119231; x=1166983231; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20curious=20results |Sender:=20; bh=eduQ0N025dEKzrkMH7FZjqqWBmyaiJPvCMrQoCYz/5w=; b=igQpx9RAUvk+DusbJjSd8oQhDNFW4rPiqtNxwtB/sPaSH2dk4tCLce2Mu/BG0WFQRlicRTky 4VSVMbH2OQvPWGOKQnUl3kqEHBpcXAnu163iQ/vpA4YtWUKe0p64ruGN; Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); Subject: Re: curious results X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 18:08:37 -0000 All: Ok, the second problem I noted.. where the system freezes... I can reproduce pretty regularly... the problem is I can't seem to gain any information from it. If I hit ANY key it starts back up again... for example if I leave it on the screen running top.. if I strke Ctl- to do a Ctl-alt-esc to drop to ddb... bam the time updates (jumping an hour in the last instance)... So when I look at the core.. everything looks normal.. I am seeing at the same instance "Limiting closed port RST response from 257 to 200 packets/sec" and some "calcru: runtime went backwards... " messages as well.. Any suggestions on how I can gather any data from this event... Oh one other note.. the machine cannot be pinged when it reaches this state... so a network interupt will not revive it .. Very wierd.. R Randall Stewart wrote: > All: > > I have two machines I am testing with... a Intel Xeon > 2.8 Gig w/hyperthreading... and a Intel P4D dual core. > > Now I am testing SCTP and how it interacts with SMP.. or > that is my intention. I have a snapshot of the MPI code > that one of my friends at UBC has been working on > with Argonne Labs... This uses SCTP :-) > > He has written a serious of tests which all now pass > (after a LOT of bugs and LOR's.. all kinds of fun :D) > > Now a seperate test he has written is something called > mywaitall. Basically you setup a number of processes, > all of them get up and settled in. Then they coordinate > (near as I can tell) sharing SCTP port and address info > with each other via TCP. Then they switch over and > use the SCTP one-2-many model.. sending data to each other > setting up implicit connections. > > This means that running -np 10.. I have 10 endpoints with > 90 associations ... I am doing this only on the local > host side. > > I run this in a > while true > do > mpiexec -np 10 ./mywaitall > echo "-------" > done > > > Now on the xeon machine I see a very curious failure. After > about a day of running this. I get two endpoints stuck > one has data to be transmitted the other is waiting for > it.. (the way the program works is they all send/rcv some > info and then say goodbye to each other). > > Now I am seeing loss because the app version I have is > buggy... the author did not handle the sending in non-blocking > mode correctly. He thought he got a -1/EAGAIN.. instead of > a 0/0 back.. so he ends up in a tight loop doing > while (sent > -1) > ret = dothesend() > if(ret < 0) > break // error > sent += ret; > > > Which means we peg the CPU sending with full send windows.. He > has fixed this.. but I keep testing with the buggy version since > it finds somemany unique problems :-) > > But back to my scenario. Now I have, in the past, fixed many > bugs like this that were an SCTP problem :-) but this one > I don't think so anymore.. > > When I find and look at the assoc's in question the sender > has some outstanding chunks (4 in the last instance) and > its timer is running as far as it is concerned. Here is > the actual callout structure: > > $6 = {c_links = {sle = {sle_next = 0x0}, > tqe = {tqe_next = 0x0, > tqe_prev = 0xc6dd02a8}}, > c_time = 264796819, > c_arg = 0xc27201ec, > c_func = 0xc0748458 , > c_mtx = 0x0, > c_flags = 22} > > Now there is another part to the structure (the c_arg) and if > I look in there I see things like it being started 1 second > before (which one would excpect... I save the ticks of > when it was started). I also have a stopped_from field > that gets set any time someone does a stop of the timer > and when the callout is called it sets it to various > values. The time structure is opaque to the SCTP code so > it does not play with these values.. and when you look at > the ticks, its long past expiration.. > > Note that the 22 indicates NO_MTX | PENDING and ACTIVE. > And yet the linked lists in c_links is NOT set to anything > like I normally see these dudes.. > > Now I did put a extra global SCTP lock in before starting/stopping > the timer. This did make it take 2-3 days to hit this case.. but > it still happens.... > > Has anyone seen this ?? I have looked at the timer code and I > do see a mutex spin lock.. but I can't see how SCTP would be > causing this... I am stumped .. any suggestions would be welcome ;-) > > -------------------- > > My second problem is even more bizzare.. if thats possible...:-D > > The other p4d runs along fine for a day or so .. and then it will > just stop.. and I mean stop.. if you have a top window up (I have > x off.. to panic it when I want :-D) you see the time frozen. No > updates... it just freezes... > > If you type in anything.. the machine picks up again and starts > running as if nothing had happened. The last time I created > this the time had been frozen for at least 12 hours before > I got to it :-D > > I dropped directly into KDB and pulled a crash dump... > > Looking at all of the SCTP assoc's there was NOTHING > happening.. no data in flight.. nothing... > > Now in the past type any key, change to another set > of windows ... and ta-da.. off it runs.. > > I do see a few TCP timeout alarms in the app (remember > the app talks TCP to setup the SCTP stuff)... > > Very wierd... > > Any ideas or suggestions would be welcome. > > I just did an update in prep of doing a patch (currently > passed to gnn for approval).. so my cores are invalid.. but > I can recreate them pretty easily .. it just takes a > day or so :-) > > I can also let anyone that is interested in when the event > occurs of problem one to the machine... and let them > puruse the timers or whatever of the running kernel.. or > take a crash dump and let you look at that.. > > If anyone has heard of anything like this I would appreciate > some pointers.. it could be something SCTP is doing... at > least the timer one.. > > Thanks for any suggestions.. > > R > > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 18:34:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2F6916A407; Thu, 14 Dec 2006 18:34:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00726442C7; Thu, 14 Dec 2006 18:15:58 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEIHSv9038953; Thu, 14 Dec 2006 13:17:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEIHSWj038231; Thu, 14 Dec 2006 13:17:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DE71773034; Thu, 14 Dec 2006 13:17:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214181727.DE71773034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 13:17:27 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm 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: Thu, 14 Dec 2006 18:34:48 -0000 TB --- 2006-12-14 17:50:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 17:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-12-14 17:50:00 - cleaning the object tree TB --- 2006-12-14 17:50:22 - checking out the source tree TB --- 2006-12-14 17:50:22 - cd /tinderbox/HEAD/arm/arm TB --- 2006-12-14 17:50:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 17:59:28 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 17:59:28 - cd /src TB --- 2006-12-14 17:59:28 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 17:59:30 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 18:17:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 18:17:27 - ERROR: failed to build world TB --- 2006-12-14 18:17:27 - tinderbox aborted TB --- 0.24 user 0.62 system 1646.57 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 18:35:49 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CE9016A47B; Thu, 14 Dec 2006 18:35:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F41B43DC3; Thu, 14 Dec 2006 18:17:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEIIEt2039197; Thu, 14 Dec 2006 13:18:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEIIE0U039122; Thu, 14 Dec 2006 13:18:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1F80673034; Thu, 14 Dec 2006 13:18:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214181814.1F80673034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 13:18:14 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Thu, 14 Dec 2006 18:35:49 -0000 TB --- 2006-12-14 17:50:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 17:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-14 17:50:00 - cleaning the object tree TB --- 2006-12-14 17:50:21 - checking out the source tree TB --- 2006-12-14 17:50:21 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-14 17:50:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 17:59:28 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 17:59:28 - cd /src TB --- 2006-12-14 17:59:28 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 17:59:30 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 18:18:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 18:18:13 - ERROR: failed to build world TB --- 2006-12-14 18:18:13 - tinderbox aborted TB --- 0.24 user 0.64 system 1693.21 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 18:42:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E47216A65A for ; Thu, 14 Dec 2006 18:42:07 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 857944425E for ; Thu, 14 Dec 2006 18:29:03 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c58-107-94-118.belrs4.nsw.optusnet.com.au [58.107.94.118]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id kBEIUQMj008037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Dec 2006 05:30:27 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id kBEIUQSG003224 for ; Fri, 15 Dec 2006 05:30:26 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id kBEIUQ04003223 for freebsd-current@freebsd.org; Fri, 15 Dec 2006 05:30:26 +1100 (EST) (envelope-from peter) Date: Fri, 15 Dec 2006 05:30:26 +1100 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20061214183026.GA1532@turion.vk2pj.dyndns.org> References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 18:42:07 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2006-Dec-14 16:35:41 +0100, Ivan Voras wrote: >For what it's worth: +1. It's going to be practically required even for >medium-performance applications as CPU clock rate stagnate and more >cores are grown. Sun have stated that they do not expect SPARC clock speeds to increase significantly. Instead, they will be doubling the number of threads per chip every year or so. (32 now, 64 next year). Intel have announced quad-core x86 chips. AMD will presumably follow suit. Based on the current release engineering guidelines, FreeBSD 7.x will probably be supported until around 2011 (-RELEASE next year, -STABLE for about 18 months, continued support for 2 years after 8-RELEASE). The system toolchain is a critical piece of infrastructure and making a major change within a release is impractical. IMHO, rather than looking at what is mature now, FreeBSD -CURRENT should be looking at a toolchain that is closer to the leading edge (as long as there are no significant regressions in stability) but will mature shortly before 7-RELEASE. This maximises the period of "vendor" support for the toolchain and therefore reduces the amount of FreeBSD developer effort that will be spent supporting the toolchain once the vendor stops doing so. The computing industry moves relatively fast and you can't wait for your supplier's product to be fully mature before you start developing on it or your customers will go elsewhere because their customers won't buy what they see as a product running on an obsolete base. --=20 Peter Jeremy --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgZhC/opHv/APuIcRAnQkAKDBajjY/x7mf3da9gAa7cGYqb8VSwCfe/b0 dQDOgfQUHBsuYIOV7xvUKs4= =mTM+ -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 18:49:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17D6C16A47E; Thu, 14 Dec 2006 18:49:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B75943CD3; Thu, 14 Dec 2006 18:43:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEIij1f048244; Thu, 14 Dec 2006 13:44:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEIijn3070361; Thu, 14 Dec 2006 13:44:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 664B373036; Thu, 14 Dec 2006 13:44:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214184445.664B373036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 13:44:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 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: Thu, 14 Dec 2006 18:49:48 -0000 TB --- 2006-12-14 18:18:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 18:18:14 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-14 18:18:14 - cleaning the object tree TB --- 2006-12-14 18:18:22 - checking out the source tree TB --- 2006-12-14 18:18:22 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-14 18:18:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 18:26:20 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 18:26:20 - cd /src TB --- 2006-12-14 18:26:20 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 18:26:21 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 18:44:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 18:44:45 - ERROR: failed to build world TB --- 2006-12-14 18:44:45 - tinderbox aborted TB --- 0.23 user 0.55 system 1591.21 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 18:49:53 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 445FF16A47B; Thu, 14 Dec 2006 18:49:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28296440AD; Thu, 14 Dec 2006 18:43:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEIif4C048209; Thu, 14 Dec 2006 13:44:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEIifbL070278; Thu, 14 Dec 2006 13:44:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 12BE973034; Thu, 14 Dec 2006 13:44:40 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214184441.12BE973034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 13:44:40 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 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: Thu, 14 Dec 2006 18:49:53 -0000 TB --- 2006-12-14 18:17:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 18:17:28 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-14 18:17:28 - cleaning the object tree TB --- 2006-12-14 18:17:37 - checking out the source tree TB --- 2006-12-14 18:17:37 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-14 18:17:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 18:26:20 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 18:26:20 - cd /src TB --- 2006-12-14 18:26:20 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 18:26:21 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 18:44:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 18:44:40 - ERROR: failed to build world TB --- 2006-12-14 18:44:40 - tinderbox aborted TB --- 0.16 user 0.70 system 1632.72 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 19:13:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 536D816A4CE; Thu, 14 Dec 2006 19:13:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E51443CA5; Thu, 14 Dec 2006 19:10:46 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJCCBV060420; Thu, 14 Dec 2006 14:12:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJCCih003433; Thu, 14 Dec 2006 14:12:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D160D73034; Thu, 14 Dec 2006 14:12:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214191211.D160D73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 14:12:11 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 19:13:00 -0000 TB --- 2006-12-14 18:44:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 18:44:45 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-12-14 18:44:45 - cleaning the object tree TB --- 2006-12-14 18:45:00 - checking out the source tree TB --- 2006-12-14 18:45:00 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-12-14 18:45:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 18:53:23 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 18:53:23 - cd /src TB --- 2006-12-14 18:53:23 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 18:53:24 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 19:12:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 19:12:11 - ERROR: failed to build world TB --- 2006-12-14 19:12:11 - tinderbox aborted TB --- 0.22 user 0.60 system 1646.12 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 19:16:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E89F16A49E; Thu, 14 Dec 2006 19:16:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C1BD43C9D; Thu, 14 Dec 2006 19:14:23 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJFgBp061633; Thu, 14 Dec 2006 14:15:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJFgrD093604; Thu, 14 Dec 2006 14:15:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 50FDA73034; Thu, 14 Dec 2006 14:15:42 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214191542.50FDA73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 14:15:42 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 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: Thu, 14 Dec 2006 19:16:45 -0000 TB --- 2006-12-14 18:44:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 18:44:41 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-14 18:44:41 - cleaning the object tree TB --- 2006-12-14 18:44:53 - checking out the source tree TB --- 2006-12-14 18:44:53 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-14 18:44:53 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 18:53:23 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 18:53:23 - cd /src TB --- 2006-12-14 18:53:23 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 18:53:24 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 19:15:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 19:15:42 - ERROR: failed to build world TB --- 2006-12-14 19:15:42 - tinderbox aborted TB --- 0.26 user 0.59 system 1861.12 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 19:22:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D866916A47B for ; Thu, 14 Dec 2006 19:22:17 +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 8D9D743CCF for ; Thu, 14 Dec 2006 19:18:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBEJK6Ot025359; Thu, 14 Dec 2006 12:20:11 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4581A3E3.9060807@samsco.org> Date: Thu, 14 Dec 2006 12:20:03 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Peter Jeremy References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> In-Reply-To: <20061214183026.GA1532@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 19:22:18 -0000 Peter Jeremy wrote: > On Thu, 2006-Dec-14 16:35:41 +0100, Ivan Voras wrote: >> For what it's worth: +1. It's going to be practically required even for >> medium-performance applications as CPU clock rate stagnate and more >> cores are grown. > > Sun have stated that they do not expect SPARC clock speeds to increase > significantly. Instead, they will be doubling the number of threads > per chip every year or so. (32 now, 64 next year). > > Intel have announced quad-core x86 chips. AMD will presumably follow suit. > > Based on the current release engineering guidelines, FreeBSD 7.x will > probably be supported until around 2011 (-RELEASE next year, -STABLE > for about 18 months, continued support for 2 years after 8-RELEASE). > The system toolchain is a critical piece of infrastructure and making > a major change within a release is impractical. IMHO, rather than > looking at what is mature now, FreeBSD -CURRENT should be looking at a > toolchain that is closer to the leading edge (as long as there are > no significant regressions in stability) but will mature shortly > before 7-RELEASE. This is a valid point. > This maximises the period of "vendor" support for > the toolchain and therefore reduces the amount of FreeBSD developer > effort that will be spent supporting the toolchain once the vendor > stops doing so. "Vendor support" from the FSF is a myth. FreeBSD has been chasing this myth for years, and it never ever turns out to be true. GCC 3.4 was rushed in a fast as possible on the exact argument that 3.4 had vendor support and 3.3 did not. That was 18 months ago (May 18, 2005), which is not very long. In that 18 months, the FSF apparently has stopped supporting 3.4, 4.0, and 4.1. Calling that "vendor support" is insane. The FSF only "supports" the latest and greatest and possibly the previous release for a short period of time. > > The computing industry moves relatively fast and you can't wait for > your supplier's product to be fully mature before you start developing > on it or your customers will go elsewhere because their customers > won't buy what they see as a product running on an obsolete base. > Yes, the industry moves fast, but that's no reason to fool ourselves into thinking that the FSF will support GCC 4.2 a day after they release 4.3 and start working on 4.4. Your point above about the lifespan of FreeBSD 7.x is a valid one, and I agree that it should be a consideration. Vendor support is a myth and should not be a consideration. Scott From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 19:32:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11EAA16A403 for ; Thu, 14 Dec 2006 19:32:32 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76E6743DC0 for ; Thu, 14 Dec 2006 19:28:56 +0000 (GMT) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id kBEJULif089104 for ; Thu, 14 Dec 2006 20:30:21 +0100 (CET) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.13.8/8.13.8/Submit) id kBEJULhc089103 for freebsd-current@freebsd.org; Thu, 14 Dec 2006 14:30:21 -0500 (EST) (envelope-from cracauer) Date: Thu, 14 Dec 2006 14:30:21 -0500 From: Martin Cracauer To: freebsd-current@freebsd.org Message-ID: <20061214193021.GA89046@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Page table walk on TLB miss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 19:32:32 -0000 Can somebody explain how the MMU walks the page table in RAM when there is a TLB miss and where the FreeBSD code is that sets up the tables? Is there actual OS code involved in the walking or does the OS just set up the code and the MMU walks on it's own? Mostly interested in AMD64. Thanks Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 19:41:53 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C8E716A47C; Thu, 14 Dec 2006 19:41:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2904243DA2; Thu, 14 Dec 2006 19:38:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJe2gv067323; Thu, 14 Dec 2006 14:40:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJe2np034964; Thu, 14 Dec 2006 14:40:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D05BD73034; Thu, 14 Dec 2006 14:40:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214194001.D05BD73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 14:40:01 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner3 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 19:41:53 -0000 TB --- 2006-12-14 19:15:42 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 19:15:42 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-14 19:15:42 - cleaning the object tree TB --- 2006-12-14 19:15:57 - checking out the source tree TB --- 2006-12-14 19:15:57 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-14 19:15:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 19:22:13 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 19:22:13 - cd /src TB --- 2006-12-14 19:22:13 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 19:22:14 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 19:40:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 19:40:01 - ERROR: failed to build world TB --- 2006-12-14 19:40:01 - tinderbox aborted TB --- 0.22 user 0.61 system 1458.78 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 19:42:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ABC016A515; Thu, 14 Dec 2006 19:42:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5107D43DC1; Thu, 14 Dec 2006 19:38:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJe3Y9067326; Thu, 14 Dec 2006 14:40:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEJe2wj034988; Thu, 14 Dec 2006 14:40:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B019D73036; Thu, 14 Dec 2006 14:40:02 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214194002.B019D73036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 14:40:02 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 19:42:02 -0000 TB --- 2006-12-14 19:12:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 19:12:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-14 19:12:12 - cleaning the object tree TB --- 2006-12-14 19:12:20 - checking out the source tree TB --- 2006-12-14 19:12:20 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-14 19:12:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 19:22:13 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 19:22:13 - cd /src TB --- 2006-12-14 19:22:13 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 19:22:14 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 19:40:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 19:40:02 - ERROR: failed to build world TB --- 2006-12-14 19:40:02 - tinderbox aborted TB --- 0.21 user 0.62 system 1670.75 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 20:12:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B3D416A47C for ; Thu, 14 Dec 2006 20:12:41 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED2D43CA5 for ; Thu, 14 Dec 2006 20:10:27 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so207859ana for ; Thu, 14 Dec 2006 12:12:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dFhOc6KEZYIy6+hUGH0lW1y2lcZVpKYaCzPsk15EwXWegEcBPYOETKwWE7h4s5KeprDpvmVKZNzoAE8hKFqAYGv8WDmrJy/2vR+RM5LUBqdnPV2HMrRXjocSXLVFNJTnq61l4BqUuCbgnoJWE6z1J/Uvmf8UC75WzbZ7SMTWmQg= Received: by 10.100.112.19 with SMTP id k19mr1212250anc.1166127123348; Thu, 14 Dec 2006 12:12:03 -0800 (PST) Received: by 10.100.136.16 with HTTP; Thu, 14 Dec 2006 12:12:03 -0800 (PST) Message-ID: <6eb82e0612141212t50fb25aeidfbc84435ca2d521@mail.gmail.com> Date: Fri, 15 Dec 2006 04:12:03 +0800 From: "Rong-en Fan" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: SD slot on ThinkPad X60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 20:12:41 -0000 My ThinkPad X60 has a SD card slot. pciconf -lv shows none7@pci21:0:2: class=0x080500 card=0x201d17aa chip=0x08221180 rev=0x18 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'SD Bus Host Adapter' class = base peripheral How to use this slot to read SD cards? In ThinkPad X31, the CF slot is simulated as an ata drive, so I have adX for the CF card. It seems the SD slot here works differently. Any ideas? Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 20:12:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DB0D16A407; Thu, 14 Dec 2006 20:12:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38B8843CE9; Thu, 14 Dec 2006 20:10:38 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEKCEQv079440; Thu, 14 Dec 2006 15:12:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEKCELg074620; Thu, 14 Dec 2006 15:12:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 42AC673034; Thu, 14 Dec 2006 15:12:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214201214.42AC673034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 15:12:14 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm 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: Thu, 14 Dec 2006 20:12:44 -0000 TB --- 2006-12-14 19:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 19:45:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-12-14 19:45:00 - cleaning the object tree TB --- 2006-12-14 19:45:13 - checking out the source tree TB --- 2006-12-14 19:45:13 - cd /tinderbox/HEAD/arm/arm TB --- 2006-12-14 19:45:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 19:54:16 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 19:54:16 - cd /src TB --- 2006-12-14 19:54:16 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 19:54:17 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 20:12:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 20:12:13 - ERROR: failed to build world TB --- 2006-12-14 20:12:13 - tinderbox aborted TB --- 0.24 user 0.58 system 1633.23 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 20:13:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B354216A403; Thu, 14 Dec 2006 20:13:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D49D443CA1; Thu, 14 Dec 2006 20:11:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEKCoUF079549; Thu, 14 Dec 2006 15:12:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEKCoKw013697; Thu, 14 Dec 2006 15:12:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1D04573034; Thu, 14 Dec 2006 15:12:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214201250.1D04573034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 15:12:50 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Thu, 14 Dec 2006 20:13:23 -0000 TB --- 2006-12-14 19:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 19:45:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-14 19:45:00 - cleaning the object tree TB --- 2006-12-14 19:45:14 - checking out the source tree TB --- 2006-12-14 19:45:14 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-14 19:45:14 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 19:54:16 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 19:54:16 - cd /src TB --- 2006-12-14 19:54:16 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 19:54:17 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 20:12:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 20:12:50 - ERROR: failed to build world TB --- 2006-12-14 20:12:50 - tinderbox aborted TB --- 0.25 user 0.59 system 1669.39 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 20:22:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55D4C16A412 for ; Thu, 14 Dec 2006 20:22:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864F243CA8 for ; Thu, 14 Dec 2006 20:20:04 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gux5C-00056r-Sq for freebsd-current@freebsd.org; Thu, 14 Dec 2006 21:21:34 +0100 Received: from ip244.gte215.dsl-acs2.sea.iinet.com ([209.20.215.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Dec 2006 21:21:34 +0100 Received: from atkin901 by ip244.gte215.dsl-acs2.sea.iinet.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Dec 2006 21:21:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Thu, 14 Dec 2006 12:27:16 -0800 Lines: 25 Message-ID: References: <20061214184441.12BE973034@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip244.gte215.dsl-acs2.sea.iinet.com User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) In-Reply-To: <20061214184441.12BE973034@freebsd-current.sentex.ca> Sender: news Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 20:22:00 -0000 Caused by the following commit, can someone pls fix? In various other places, use of thise macro is preceded by: #if defined _SC_PHYS_PAGES && defined _SC_PAGESIZE > pjd 2006-12-14 14:32:59 UTC > > FreeBSD src repository > > Modified files: > lib/libc/gen sysconf.3 sysconf.c > Log: > Add support for _SC_PHYS_PAGES, which is not standard, but can be found in > Solaris and Linux. > > Revision Changes Path > 1.23 +13 -0 src/lib/libc/gen/sysconf.3 > 1.21 +14 -1 src/lib/libc/gen/sysconf.c > _______________________________________________ > cvs-src@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/cvs-src > To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 20:48:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61D2916A417; Thu, 14 Dec 2006 20:48:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0C1843E80; Thu, 14 Dec 2006 20:37:59 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEKdMj9061080; Thu, 14 Dec 2006 15:39:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEKdMvf005096; Thu, 14 Dec 2006 15:39:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 28A4C73036; Thu, 14 Dec 2006 15:39:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214203922.28A4C73036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 15:39:22 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 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: Thu, 14 Dec 2006 20:48:55 -0000 TB --- 2006-12-14 20:12:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 20:12:50 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-14 20:12:51 - cleaning the object tree TB --- 2006-12-14 20:12:57 - checking out the source tree TB --- 2006-12-14 20:12:57 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-14 20:12:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 20:21:05 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 20:21:05 - cd /src TB --- 2006-12-14 20:21:05 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 20:21:06 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 20:39:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 20:39:22 - ERROR: failed to build world TB --- 2006-12-14 20:39:22 - tinderbox aborted TB --- 0.18 user 0.61 system 1591.80 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 20:48:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F8C216A492; Thu, 14 Dec 2006 20:48:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8749E440B5; Thu, 14 Dec 2006 20:37:59 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEKdG5W061073; Thu, 14 Dec 2006 15:39:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEKdGWW091748; Thu, 14 Dec 2006 15:39:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CFE0D73034; Thu, 14 Dec 2006 15:39:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214203915.CFE0D73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 15:39:15 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 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: Thu, 14 Dec 2006 20:48:55 -0000 TB --- 2006-12-14 20:12:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 20:12:14 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-14 20:12:14 - cleaning the object tree TB --- 2006-12-14 20:12:21 - checking out the source tree TB --- 2006-12-14 20:12:21 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-14 20:12:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 20:21:05 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 20:21:05 - cd /src TB --- 2006-12-14 20:21:05 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 20:21:06 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 20:39:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 20:39:15 - ERROR: failed to build world TB --- 2006-12-14 20:39:15 - tinderbox aborted TB --- 0.16 user 0.62 system 1621.33 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 20:56:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5EA316A548 for ; Thu, 14 Dec 2006 20:56:26 +0000 (UTC) (envelope-from lars@heidieker.de) Received: from wp045.webpack.hosteurope.de (wp045.webpack.hosteurope.de [80.237.132.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1DB543DE8 for ; Thu, 14 Dec 2006 20:53:45 +0000 (GMT) (envelope-from lars@heidieker.de) Received: by wp045.webpack.hosteurope.de running Exim 4.43 using esmtpa from dyn-62-56-103-239.dslaccess.co.uk ([62.56.103.239] helo=[192.168.42.9]); authenticated id 1Guxbs-0004yk-6W; Thu, 14 Dec 2006 21:55:20 +0100 In-Reply-To: <20061214193021.GA89046@cons.org> References: <20061214193021.GA89046@cons.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <606F3A60-8DFB-4564-A27E-F0E4F08AD29F@heidieker.de> Content-Transfer-Encoding: quoted-printable From: Lars Heidieker Date: Thu, 14 Dec 2006 20:55:18 +0000 To: Martin Cracauer X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org Subject: Re: Page table walk on TLB miss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 20:56:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14 Dec 2006, at 19:30, Martin Cracauer wrote: > Can somebody explain how the MMU walks the page table in RAM when > there is a TLB miss and where the FreeBSD code is that sets up the > tables? > > Is there actual OS code involved in the walking or does the OS just > set up the code and the MMU walks on it's own? > > Mostly interested in AMD64. > > In case of i386/amd64 the mmu walks the pagetables on it's on =20 (hardware page table walk). The walking is done with physical addresses starting at the physical =20 address stored in the cr3 register of the cpu. Yes other cpus do this completely different UltraSPARC eg has a =20 Software Table walk the cpu traps simply on aTSB miss and the rest is up to the OS. - -- Viele Gr=FC=DFe, Lars Heidieker lars@heidieker.de http://paradoxon.info - ------------------------------------ Mystische Erkl=E4rungen. Die mystischen Erkl=E4rungen gelten f=FCr tief; die Wahrheit ist, dass sie noch nicht einmal oberfl=E4chlich sind. -- Friedrich Nietzsche -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFgbo2cxuYqjT7GRYRAg0TAKCSr/jIUkS/Q2+bfst8LDbGEuZy7wCfVvkT OEJyC8xTCdfoOr1sfeYVEMk=3D =3D5TQh -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 21:08:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C62C16A412; Thu, 14 Dec 2006 21:08:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 602D543D8B; Thu, 14 Dec 2006 21:05:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEL76NM092490; Thu, 14 Dec 2006 16:07:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEL76HY074434; Thu, 14 Dec 2006 16:07:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 786D973034; Thu, 14 Dec 2006 16:07:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214210706.786D973034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 16:07:06 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 21:08:42 -0000 TB --- 2006-12-14 20:39:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 20:39:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-12-14 20:39:22 - cleaning the object tree TB --- 2006-12-14 20:39:36 - checking out the source tree TB --- 2006-12-14 20:39:36 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-12-14 20:39:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 20:48:14 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 20:48:14 - cd /src TB --- 2006-12-14 20:48:14 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 20:48:16 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 21:07:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 21:07:06 - ERROR: failed to build world TB --- 2006-12-14 21:07:06 - tinderbox aborted TB --- 0.24 user 0.59 system 1663.90 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 21:12:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DE0F16A40F; Thu, 14 Dec 2006 21:12:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3E2043CEF; Thu, 14 Dec 2006 21:09:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBELAk78065796; Thu, 14 Dec 2006 16:10:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBELAjFj083702; Thu, 14 Dec 2006 16:10:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 16FD673034; Thu, 14 Dec 2006 16:10:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214211045.16FD673034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 16:10:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 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: Thu, 14 Dec 2006 21:12:14 -0000 TB --- 2006-12-14 20:39:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 20:39:16 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-14 20:39:16 - cleaning the object tree TB --- 2006-12-14 20:39:26 - checking out the source tree TB --- 2006-12-14 20:39:26 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-14 20:39:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 20:48:14 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 20:48:14 - cd /src TB --- 2006-12-14 20:48:14 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 20:48:16 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 21:10:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 21:10:45 - ERROR: failed to build world TB --- 2006-12-14 21:10:45 - tinderbox aborted TB --- 0.19 user 0.66 system 1888.98 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 21:37:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12ACC16A416; Thu, 14 Dec 2006 21:37:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80A5F43D7B; Thu, 14 Dec 2006 21:33:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBELZ7XH068280; Thu, 14 Dec 2006 16:35:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBELZ58Q046520; Thu, 14 Dec 2006 16:35:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8EBB573034; Thu, 14 Dec 2006 16:35:05 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214213505.8EBB573034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 16:35:05 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 21:37:01 -0000 TB --- 2006-12-14 21:07:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 21:07:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-14 21:07:06 - cleaning the object tree TB --- 2006-12-14 21:07:18 - checking out the source tree TB --- 2006-12-14 21:07:18 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-14 21:07:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 21:16:58 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 21:16:58 - cd /src TB --- 2006-12-14 21:16:58 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 21:16:59 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 21:35:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 21:35:05 - ERROR: failed to build world TB --- 2006-12-14 21:35:05 - tinderbox aborted TB --- 0.24 user 0.60 system 1678.75 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 21:37:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80A6016A4C2; Thu, 14 Dec 2006 21:37:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F192743CD4; Thu, 14 Dec 2006 21:33:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBELZ69Q097990; Thu, 14 Dec 2006 16:35:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBELZ6WB046530; Thu, 14 Dec 2006 16:35:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8C11573036; Thu, 14 Dec 2006 16:35:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214213506.8C11573036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 16:35:06 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean 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: Thu, 14 Dec 2006 21:37:02 -0000 TB --- 2006-12-14 21:10:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 21:10:45 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-14 21:10:45 - cleaning the object tree TB --- 2006-12-14 21:10:58 - checking out the source tree TB --- 2006-12-14 21:10:58 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-14 21:10:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 21:16:58 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 21:16:58 - cd /src TB --- 2006-12-14 21:16:58 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 21:16:59 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 21:35:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 21:35:06 - ERROR: failed to build world TB --- 2006-12-14 21:35:06 - tinderbox aborted TB --- 0.23 user 0.60 system 1461.43 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 22:08:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2EE016A47E; Thu, 14 Dec 2006 22:08:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C20C43CC1; Thu, 14 Dec 2006 22:05:52 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEM7URi005768; Thu, 14 Dec 2006 17:07:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEM7TjS037412; Thu, 14 Dec 2006 17:07:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A1EEF73034; Thu, 14 Dec 2006 17:07:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214220729.A1EEF73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 17:07:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm 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: Thu, 14 Dec 2006 22:08:05 -0000 TB --- 2006-12-14 21:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 21:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-12-14 21:40:00 - cleaning the object tree TB --- 2006-12-14 21:40:20 - checking out the source tree TB --- 2006-12-14 21:40:20 - cd /tinderbox/HEAD/arm/arm TB --- 2006-12-14 21:40:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 21:49:26 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 21:49:26 - cd /src TB --- 2006-12-14 21:49:26 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 21:49:28 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 22:07:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 22:07:29 - ERROR: failed to build world TB --- 2006-12-14 22:07:29 - tinderbox aborted TB --- 0.20 user 0.62 system 1648.70 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 22:08:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7D0E16A5B1; Thu, 14 Dec 2006 22:08:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F48143CC0; Thu, 14 Dec 2006 22:06:37 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEM89Rd071997; Thu, 14 Dec 2006 17:08:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEM896g037881; Thu, 14 Dec 2006 17:08:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1B7D773034; Thu, 14 Dec 2006 17:08:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214220809.1B7D773034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 17:08:09 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Thu, 14 Dec 2006 22:08:34 -0000 TB --- 2006-12-14 21:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 21:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-14 21:40:00 - cleaning the object tree TB --- 2006-12-14 21:40:15 - checking out the source tree TB --- 2006-12-14 21:40:15 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-14 21:40:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 21:49:26 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 21:49:26 - cd /src TB --- 2006-12-14 21:49:26 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 21:49:28 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 22:08:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 22:08:09 - ERROR: failed to build world TB --- 2006-12-14 22:08:09 - tinderbox aborted TB --- 0.20 user 0.63 system 1688.33 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 22:39:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75B9516A40F; Thu, 14 Dec 2006 22:39:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 370CA43EFF; Thu, 14 Dec 2006 22:32:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEMYKeY011643; Thu, 14 Dec 2006 17:34:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEMYKxe013100; Thu, 14 Dec 2006 17:34:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 70FBA73034; Thu, 14 Dec 2006 17:34:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214223420.70FBA73034@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 17:34:20 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 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: Thu, 14 Dec 2006 22:39:07 -0000 TB --- 2006-12-14 22:07:29 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 22:07:29 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-14 22:07:29 - cleaning the object tree TB --- 2006-12-14 22:07:36 - checking out the source tree TB --- 2006-12-14 22:07:36 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-14 22:07:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 22:16:08 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 22:16:08 - cd /src TB --- 2006-12-14 22:16:08 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 22:16:10 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 22:34:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 22:34:20 - ERROR: failed to build world TB --- 2006-12-14 22:34:20 - tinderbox aborted TB --- 0.16 user 0.63 system 1610.32 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 22:39:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1F7616A47B; Thu, 14 Dec 2006 22:39:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D50643F11; Thu, 14 Dec 2006 22:33:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBEMYU8s073909; Thu, 14 Dec 2006 17:34:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBEMYUBe004206; Thu, 14 Dec 2006 17:34:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 01DEE73036; Thu, 14 Dec 2006 17:34:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061214223430.01DEE73036@freebsd-current.sentex.ca> Date: Thu, 14 Dec 2006 17:34:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 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: Thu, 14 Dec 2006 22:39:07 -0000 TB --- 2006-12-14 22:08:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-14 22:08:09 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-14 22:08:09 - cleaning the object tree TB --- 2006-12-14 22:08:16 - checking out the source tree TB --- 2006-12-14 22:08:16 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-14 22:08:16 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-14 22:16:08 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-14 22:16:08 - cd /src TB --- 2006-12-14 22:16:08 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 14 22:16:10 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/statvfs.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/stringlist.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/strtofflags.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysconf.c: In function `sysconf': /src/lib/libc/gen/sysconf.c:579: error: `_SC_PHYS_PAGES' undeclared (first use in this function) /src/lib/libc/gen/sysconf.c:579: error: (Each undeclared identifier is reported only once /src/lib/libc/gen/sysconf.c:579: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-14 22:34:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-14 22:34:29 - ERROR: failed to build world TB --- 2006-12-14 22:34:29 - tinderbox aborted TB --- 0.17 user 0.62 system 1580.76 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 23:49:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02CFF16A416 for ; Thu, 14 Dec 2006 23:49:28 +0000 (UTC) (envelope-from redchrom@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8654A43D95 for ; Thu, 14 Dec 2006 23:47:00 +0000 (GMT) (envelope-from redchrom@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so940774nfc for ; Thu, 14 Dec 2006 15:48:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent:x-useless-header; b=EWl+EeRlKFadZf/Z+D4kC2brAOWc2uWzJEA79FvqU93GdGmLNE7jOU3yWKAy3CudUywZYNwXQVBxUIDZTYpaWkfWsBMbUHA4crWev+t5N3i75jPlnGWERzuzqiVE86Cio7dZWPSfuVZILIKabifoPXv8hK9qS06iFuqej+MdtDs= Received: by 10.49.20.14 with SMTP id x14mr1519589nfi.1166140111545; Thu, 14 Dec 2006 15:48:31 -0800 (PST) Received: from localhost ( [82.146.37.133]) by mx.google.com with ESMTP id g1sm9606935nfe.2006.12.14.15.48.30; Thu, 14 Dec 2006 15:48:31 -0800 (PST) Date: Fri, 15 Dec 2006 07:48:49 +0800 From: Stepan Zastupov To: freebsd-current@freebsd.org Message-ID: <20061214234849.GA1062@stepan.ispsystem.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Useless-Header: They killed Kenny! THOSE BASTARDS! X-Mailman-Approved-At: Fri, 15 Dec 2006 00:34:49 +0000 Cc: nate@root.org Subject: cbb hangs during suspend if ath card active X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stepan Zastupov 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 Dec 2006 23:49:28 -0000 Does anyone still work on this problem? (http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064550.html) I incure the same problems. If need testing I can help with it. -- Best regards, Stepan Zastupov aka RedChrom ISPSystem From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 00:55:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D6F716A40F for ; Fri, 15 Dec 2006 00:55:50 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF7A143CA5 for ; Fri, 15 Dec 2006 00:53:53 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so950856nfc for ; Thu, 14 Dec 2006 16:55:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IgZhTrhEMQgre6lM7qKiq1vg9GPuAWR+cVhlsmYlNsuy3QB4NsOkIVuoY3imkQ0sbcFjjGR+woV2167uDbmlpobQFEMn+EKMFfOZV1XH0Yzs3IP/3AGFyHyqXhE++csi/mk0pSfsA4rA6EvM9kBXpQ93WTQGkcazI73eEglkHl0= Received: by 10.82.138.6 with SMTP id l6mr29568bud.1166144114109; Thu, 14 Dec 2006 16:55:14 -0800 (PST) Received: by 10.82.134.15 with HTTP; Thu, 14 Dec 2006 16:55:13 -0800 (PST) Message-ID: <3aaaa3a0612141655x72c1905cw7fc8f415e08d70b8@mail.gmail.com> Date: Fri, 15 Dec 2006 00:55:13 +0000 From: Chris To: "Andre Oppermann" In-Reply-To: <45812CDE.7000103@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F2D82.6000905@freebsd.org> <3aaaa3a0612131706w5ae75edcvadd7958274a1e2e2@mail.gmail.com> <45812CDE.7000103@freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 00:55:50 -0000 On 14/12/06, Andre Oppermann wrote: > Chris wrote: > > On 12/12/06, Andre Oppermann wrote: > >> This is a patch adding automatic TCP send and receive socket buffer > >> sizing. > >> Normally the socket buffers are static (either derived from global > >> defaults > >> or set with setsockopt) and do not adapt to real network conditions. Two > >> things happen: a) your socket buffers are too small and you can't > >> reach the > >> full potential of the network between both hosts; b) your socket > >> buffers are > >> too big and you waste a lot of kernel memory for data just sitting > >> around. > >> > >> With automatic TCP send and receive socket buffers we can start with a > >> small > >> buffer and quickly grow it in parallel with the TCP congestion window > >> to match > >> real network conditions. > >> > >> FreeBSD has a default 32K send socket buffer. This supports a maximal > >> transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > >> continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > >> auto scaling and the default values below it supports 20Mbit/s at 100ms > >> and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > >> For the receive side it looks slightly better with a default of 64K > >> buffer > >> size. > >> > >> The automatic send buffer sizing patch is currently running on one > >> half of > >> the FTP.FreeBSD.ORG cluster w/o any problems so far. Against this > >> machine > >> with the automatic receive buffer sizing patch I can download at > >> 5.7MBytes > >> per second. Without patch it maxed out at 1.6MBytes per second as the > >> delay > >> bandwidth product became equal to the static socket buffer size > >> without hitting > >> the limits of the physical link between the machines. My test machine > >> is about > >> 35ms from that FTP.FreeBSD.ORG and connected through a moderately > >> loaded 100Mbit > >> Internet link. > >> > >> New sysctl's are: > >> > >> net.inet.tcp.sendbuf_auto=1 (enabled) > >> net.inet.tcp.sendbuf_inc=8192 (8K, step size) > >> net.inet.tcp.sendbuf_max=262144 (256K, growth limit) > >> net.inet.tcp.recvbuf_auto=1 (enabled) > >> net.inet.tcp.recvbuf_inc=16384 (16K, step size) > >> net.inet.tcp.recvbuf_max=262144 (256K, growth limit) > >> > >> The patch is available here (it may apply with some fuzz): > >> > >> http://people.freebsd.org/~andre/tcp_auto_buf-20061212.diff > >> > >> Any tests and test reports are very welcome. > >> > >> -- > >> Andre > > > > Hi does this patch work on 6.x? I used the send patch on 6.x and works > > great please make a 6.x patch thank you and I will happily test. > > No, this patch doesn't work on 6.x. It makes changes to struct tcpcb > to add two additional fields. This requires netstat(1) to be recompiled > and is a ABI change. However I've got a number of requests for 6.x > patch so I may make one anyway. > > -- > Andre > > Please that would be great, the send patch works on 6.x flawlessly and has improved performance enormously it would be a shame to have to wait for 7.x to be production ready before I use it. Thanks Chris From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 01:59:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E60716A412 for ; Fri, 15 Dec 2006 01:59:46 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (trang.nuxi.org [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C7B543CC8 for ; Fri, 15 Dec 2006 01:55:37 +0000 (GMT) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.8/8.13.8) with ESMTP id kBF1vEqX034975; Thu, 14 Dec 2006 17:57:14 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.8/8.13.7/Submit) id kBF1vDkD034974; Thu, 14 Dec 2006 17:57:13 -0800 (PST) (envelope-from obrien) Date: Thu, 14 Dec 2006 17:57:13 -0800 From: "David O'Brien" To: Scott Long Message-ID: <20061215015713.GA33730@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Scott Long , Peter Jeremy , freebsd-current@freebsd.org References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4581A3E3.9060807@samsco.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 15 Dec 2006 01:59:46 -0000 On Thu, Dec 14, 2006 at 12:20:03PM -0700, Scott Long wrote: > "Vendor support" from the FSF is a myth. FreeBSD has been chasing this > myth for years, and it never ever turns out to be true. GCC 3.4 was > rushed in a fast as possible on the exact argument that 3.4 had vendor > support and 3.3 did not. That was 18 months ago (May 18, 2005), which > is not very long. In that 18 months, the FSF apparently has stopped > supporting 3.4, 4.0, and 4.1. Calling that "vendor support" is insane. > The FSF only "supports" the latest and greatest and possibly the > previous release for a short period of time. I just love how you're the FreeBSD self-appointed GCC technology expert yet you don't follow GCC development nor attend the GCC Summit... In these 18 months the follow releases happened: 3.4.5 3.4.6 (Mar 06 2006) giving 23 months of support to this branch 4.0.0 (Apr 20 2005) 4.0.1 4.0.2 4.0.3 4.1.0 4.1.1 and 4.1.2 is planned for early 2007 GCC 4.0 quickly led to 4.1 so some things could be done that aren't allowed their stable branch. Most see 4.1 as later 4.0 releases. So that's over your 18 months threshold. The GCC 4.2 branch was created on 20 Oct 2006 and is headed toward release in early 2007. A few things 4.2 has over 4.1 were presented at the 2006 GCC Summit http://www.gccsummit.org/2006/speakers.php A few of the things are: OpenMP for C, C++ and Fortran (gomp) Decimal Floating-Point New tree reassociation pass Load partial redundancy elimination Replace backend dataflow Code Factoring Optimizations Section Anchor Optimisations Remove old loop optimizer Support for IA-64 speculation Sign Extension Removal > Yes, the industry moves fast, but that's no reason to fool ourselves > into thinking that the FSF will support GCC 4.2 a day after they > release 4.3 and start working on 4.4. After GCC 3.4.0 was released there was three 3.3 releases after that. After GCC 4.0.0 was released there was two 3.4 releases after that. After GCC 4.1.0 was released there was one 3.4 release after that. After GCC 4.1.0 was released there was one 4.0 release after that. Just because you don't agree with the conservative stable branch commit rules GCC follows doesn't mean those developers don't support their product. Or rather the case probably is you don't understand the GCC commit rules and branching. The general rule is no new features in a stable branch - only regression and bug fixes. 3.4.0->3.4.6 had plenty of bugs fixed, as did 3.3.0->3.3.6 and 4.0.0->4.0.3. That's not support? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 02:04:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69FED16A415 for ; Fri, 15 Dec 2006 02:04:42 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (trang.nuxi.org [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1671043CB4 for ; Fri, 15 Dec 2006 02:02:59 +0000 (GMT) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.8/8.13.8) with ESMTP id kBF24bdh035071; Thu, 14 Dec 2006 18:04:37 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.8/8.13.7/Submit) id kBF24aEN035070; Thu, 14 Dec 2006 18:04:36 -0800 (PST) (envelope-from obrien) Date: Thu, 14 Dec 2006 18:04:36 -0800 From: "David O'Brien" To: "O. Hartmann" Message-ID: <20061215020436.GB33730@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, "O. Hartmann" References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131440.04076.mi+mx@aldan.algebra.com> <4580766A.600@samsco.org> <200612131711.50921.mi+mx@aldan.algebra.com> <458101C4.8090106@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <458101C4.8090106@zedat.fu-berlin.de> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Fri, 15 Dec 2006 02:04:42 -0000 On Thu, Dec 14, 2006 at 08:48:20AM +0100, O. Hartmann wrote: > I'm not very familiar with the compiler development, but it seemed to > me gcc 4.1 was like a interim solution. This arose due to the fast > appeareance of it's successor ... The goal is more frequent major (ie, X.Y.0 -> X.Y+1.0) releases. Like our 4.0 -> 5.0 experience, GCC when thru similar with its 2.95 -> 3.0.0 release. As much new FreeBSD features are developed in an alternate repository (Perforce) after 5.0, GCC makes heavy use of developement branches which are only merged into the mainline (think our CVS HEAD repository) when they are ready for prime-time. You can read the development methodology and rationale at http://gcc.gnu.org/develop.html -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 02:14:35 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3A2716A492 for ; Fri, 15 Dec 2006 02:14:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id E16A143CB3 for ; Fri, 15 Dec 2006 02:12:46 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so350567wra for ; Thu, 14 Dec 2006 18:14:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=nB0uphOEyaMT5uSCyrbP4gtEDMv6fiDUIXsIHGaw14Khjruu+7VvmNSEWmi20PtZKCjJQ8AYXRULwUJu/EyKWMkJcBBtKySztvSHZ8LF1uEUv9bEPqifBh5lEfkz89kcw9KZJso0EWyrAAYCu/XquqlAFedVXpq2pzomf23QvpE= Received: by 10.90.72.10 with SMTP id u10mr142162aga.1166148864696; Thu, 14 Dec 2006 18:14:24 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 67sm4243551wra.2006.12.14.18.14.22; Thu, 14 Dec 2006 18:14:23 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kBF2EAhx026074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2006 11:14:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kBF2EA9H026073; Fri, 15 Dec 2006 11:14:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 15 Dec 2006 11:14:10 +0900 From: Pyun YongHyeon To: Pascal Hofstee Message-ID: <20061215021410.GA25508@cdnetworks.co.kr> References: <45807C05.8040703@FreeBSD.org> <1166050020.1640.6.camel@chekov> <45808382.7000802@FreeBSD.org> <1166088126.1125.12.camel@chekov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1166088126.1125.12.camel@chekov> User-Agent: Mutt/1.4.2.1i Cc: "Bruce M. Simpson" , current@FreeBSD.org Subject: Re: D-Link DGE-350T and if_sk (no go) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2006 02:14:35 -0000 On Thu, Dec 14, 2006 at 10:22:06AM +0100, Pascal Hofstee wrote: > On Wed, 2006-12-13 at 22:49 +0000, Bruce M. Simpson wrote: > > Yes. It looks like (from dmesg) that your card is a Yukon 1. I think I > > managed to get the sk driver to attach to the PCI-e Yukon in my ASUS > > machine and had similar problems, though this was many months ago. The > > msk driver might work for you. > > Well .. i got around to trying the msk driver this morning and > unfortunately (after adding the pci-id to the msk driver) the card > probes, but doesn't attach because of the msk-driver rejecting > device-id's that are't Yukon II chips. (the if-section below in > if_msk.c) > > if (sc->msk_hw_id < CHIP_ID_YUKON_XL || > sc->msk_hw_id > CHIP_ID_YUKON_FE) { > > device_printf(dev, "unknown device: id=0x%02x, rev=0x%02x\n", > sc->msk_hw_id, sc->msk_hw_rev); > error = ENXIO; > goto fail; > } > > My DGE-530T however has id=0xb1, rev=0x09 which seems to be what if_msk > considers CHIP_ID_YUKON_LITE. So it looks that without further hacking > on the msk driver trying to use if_msk instead of if_sk is an excercise > in futility, though it was definitely worth a shot. > Please don't waste time. The msk(4) does not work for your DGE-530T. Yukon and Yukon II is completly different in hardware. That is main reason why I have to write msk(4) instead of adding Yukon II support code to sk(4). > I'll be watching the interrupts as soon as i can get a hold of my > neighbour which should probably be sometime later today. If in the > meanwhile people have other suggestions i might try, send them my way > and i'll give it a shot :) > It could be related with PHY which is under power down/uninitialized state. I'm still wonder why sk(4) doesn't work at all. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 02:28:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D8FF16A415 for ; Fri, 15 Dec 2006 02:28:34 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951F343CAF for ; Fri, 15 Dec 2006 02:25:45 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id kBF2Qt55020705; Thu, 14 Dec 2006 18:26:55 -0800 (PST) Date: Fri, 15 Dec 2006 10:04:20 +0900 Message-ID: From: "George V. Neville-Neil" To: Scott Long In-Reply-To: <4581A3E3.9060807@samsco.org> References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.90 (i386-apple-darwin8.8.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 02:28:34 -0000 At Thu, 14 Dec 2006 12:20:03 -0700, Scott Long wrote: > "Vendor support" from the FSF is a myth. FreeBSD has been chasing this > myth for years, and it never ever turns out to be true. GCC 3.4 was > rushed in a fast as possible on the exact argument that 3.4 had vendor > support and 3.3 did not. That was 18 months ago (May 18, 2005), which > is not very long. In that 18 months, the FSF apparently has stopped > supporting 3.4, 4.0, and 4.1. Calling that "vendor support" is insane. > The FSF only "supports" the latest and greatest and possibly the > previous release for a short period of time. I think we should focus a bit more on what people in the field are using on various systems. That is to say it's not so much the "vendor", i.e. the FSF, but we should look at other OSs and software projects that use gcc and see where they are going, because it is very likely that it is from them that we will get patches and support. So, what are the other BSDs using, and what are the Linux distros using or planning to use? Does anyone know? Best, George From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 02:58:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3035E16A416; Fri, 15 Dec 2006 02:58:59 +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 F112D43DBD; Fri, 15 Dec 2006 02:56:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBF2w0GD028733; Thu, 14 Dec 2006 19:58:05 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45820F35.50802@samsco.org> Date: Thu, 14 Dec 2006 19:57:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: obrien@freebsd.org, Scott Long , Peter Jeremy , freebsd-current@freebsd.org References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <20061215015713.GA33730@dragon.NUXI.org> In-Reply-To: <20061215015713.GA33730@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 02:58:59 -0000 David O'Brien wrote: > On Thu, Dec 14, 2006 at 12:20:03PM -0700, Scott Long wrote: >> "Vendor support" from the FSF is a myth. FreeBSD has been chasing this >> myth for years, and it never ever turns out to be true. GCC 3.4 was >> rushed in a fast as possible on the exact argument that 3.4 had vendor >> support and 3.3 did not. That was 18 months ago (May 18, 2005), which >> is not very long. In that 18 months, the FSF apparently has stopped >> supporting 3.4, 4.0, and 4.1. Calling that "vendor support" is insane. >> The FSF only "supports" the latest and greatest and possibly the >> previous release for a short period of time. > > I just love how you're the FreeBSD self-appointed GCC technology expert > yet you don't follow GCC development nor attend the GCC Summit... > > In these 18 months the follow releases happened: > 3.4.5 > 3.4.6 (Mar 06 2006) giving 23 months of support to this branch > 4.0.0 (Apr 20 2005) > 4.0.1 > 4.0.2 > 4.0.3 > 4.1.0 > 4.1.1 > and > 4.1.2 is planned for early 2007 > > GCC 4.0 quickly led to 4.1 so some things could be done that aren't > allowed their stable branch. Most see 4.1 as later 4.0 releases. So > that's over your 18 months threshold. > > The GCC 4.2 branch was created on 20 Oct 2006 and is headed toward > release in early 2007. > > A few things 4.2 has over 4.1 were presented at the 2006 GCC Summit > http://www.gccsummit.org/2006/speakers.php > A few of the things are: > OpenMP for C, C++ and Fortran (gomp) > Decimal Floating-Point > New tree reassociation pass > Load partial redundancy elimination > Replace backend dataflow > Code Factoring Optimizations > Section Anchor Optimisations > Remove old loop optimizer > Support for IA-64 speculation > Sign Extension Removal > >> Yes, the industry moves fast, but that's no reason to fool ourselves >> into thinking that the FSF will support GCC 4.2 a day after they >> release 4.3 and start working on 4.4. > > After GCC 3.4.0 was released there was three 3.3 releases after that. > After GCC 4.0.0 was released there was two 3.4 releases after that. > After GCC 4.1.0 was released there was one 3.4 release after that. > After GCC 4.1.0 was released there was one 4.0 release after that. > > Just because you don't agree with the conservative stable branch commit > rules GCC follows doesn't mean those developers don't support their > product. Or rather the case probably is you don't understand the GCC > commit rules and branching. > > The general rule is no new features in a stable branch - only > regression and bug fixes. 3.4.0->3.4.6 had plenty of bugs fixed, > as did 3.3.0->3.3.6 and 4.0.0->4.0.3. That's not support? > Thank you for the explanation. That doesn't match the reason that I was given in May 2005 for needing to get to GCC 3.4, nor does it match comments from others in this thread that GCC 4.2 is needed because there is no support for GCC 4.1. Maybe these people don't understand what 'support' means either. Dunno. Anyways, thanks for the explanation. I still maintain that FreeBSD was on a toolchain treadmill for many years, and it's nice to be off of it and not worrying about a toolchain upgrade hanging over every release. Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 03:09:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C2AB16A515 for ; Fri, 15 Dec 2006 03:09:41 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98C4D43CAD for ; Fri, 15 Dec 2006 03:08:01 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.180.186]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JAA0087TORWHD8D@vms044.mailsrvcs.net> for freebsd-current@freebsd.org; Thu, 14 Dec 2006 21:09:33 -0600 (CST) Date: Thu, 14 Dec 2006 22:09:29 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <6eb82e0612141212t50fb25aeidfbc84435ca2d521@mail.gmail.com> To: Rong-en Fan Message-id: <1166152169.839.4.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <6eb82e0612141212t50fb25aeidfbc84435ca2d521@mail.gmail.com> Cc: FreeBSD Current Subject: Re: SD slot on ThinkPad X60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 03:09:41 -0000 On Fri, 2006-12-15 at 04:12 +0800, Rong-en Fan wrote: > My ThinkPad X60 has a SD card slot. pciconf -lv shows > > none7@pci21:0:2: class=0x080500 card=0x201d17aa chip=0x08221180 > rev=0x18 hdr=0x00 > vendor = 'Ricoh Company, Ltd.' > device = 'SD Bus Host Adapter' > class = base peripheral > > How to use this slot to read SD cards? In ThinkPad X31, the CF slot is > simulated as an ata drive, so I have adX for the CF card. It seems the > SD slot here works differently. > > Any ideas? > > Regards, > Rong-En Fan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I have run across this just today: http://www.nabble.com/SDHCI-Device-Driver-(first-steps)-t2289693.html HTH, -- Alexandre "Sunny" Kovalenko From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 03:15:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 851A616A407 for ; Fri, 15 Dec 2006 03:15:25 +0000 (UTC) (envelope-from juhasaarinen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id C423843CA8 for ; Fri, 15 Dec 2006 03:13:45 +0000 (GMT) (envelope-from juhasaarinen@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so568573wxc for ; Thu, 14 Dec 2006 19:15:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=g9wQ9nPk1gTjA93ZHNqahCnvu969L3sUpJG8+CnLyN4oCcR91QGB65cBXDweKGbmQvkm345Y9zI3zZnt9CU5qHyYndNR5DIotRN/3p6y+g0u5T2RIVwMM1FyzR/NQjSeVHehg80EqvpxRyzl7K6TdV5q5ZOQGXBizAcKOW2H53c= Received: by 10.70.87.11 with SMTP id k11mr76367wxb.1166152523855; Thu, 14 Dec 2006 19:15:23 -0800 (PST) Received: by 10.70.24.18 with HTTP; Thu, 14 Dec 2006 19:15:23 -0800 (PST) Message-ID: Date: Fri, 15 Dec 2006 16:15:23 +1300 From: "Juha Saarinen" To: freebsd-current@freebsd.org In-Reply-To: <45820F35.50802@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <20061215015713.GA33730@dragon.NUXI.org> <45820F35.50802@samsco.org> Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 03:15:25 -0000 So... silly question perhaps, but does -CURRENT (world + kernel) build with gcc 4.2 and -fopenmp? What about -STABLE and -RELEASE? -- Juha http://www.geekzone.co.nz/juha From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 03:42:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC0B616A417 for ; Fri, 15 Dec 2006 03:42:03 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18E9843C9D for ; Fri, 15 Dec 2006 03:40:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id DC90A1A4D93; Thu, 14 Dec 2006 19:42:02 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1BE795138F; Thu, 14 Dec 2006 22:42:02 -0500 (EST) Date: Thu, 14 Dec 2006 22:42:02 -0500 From: Kris Kennaway To: Juha Saarinen Message-ID: <20061215034201.GA4310@xor.obsecurity.org> References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <20061215015713.GA33730@dragon.NUXI.org> <45820F35.50802@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 03:42:03 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Dec 15, 2006 at 04:15:23PM +1300, Juha Saarinen wrote: > So... silly question perhaps, but does -CURRENT (world + kernel) build > with gcc 4.2 and -fopenmp? What about -STABLE and -RELEASE? gcc 4.1 support requires changes to /usr/src (mostly to fix new warnings and error conditions). I don't know if gcc 4.2 is even stricter. Kris --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFghmJWry0BWjoQKURAlb+AKD/MpBxDtlJSldldc60hm98W8O0zgCg7klH IWVlW12pZ6IwauNRtlLjkrE= =rzW+ -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 04:21:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FD3616A416 for ; Fri, 15 Dec 2006 04:21:12 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4438E43CAF for ; Fri, 15 Dec 2006 04:19:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp157-244.lns2.adl2.internode.on.net [121.44.157.244]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id kBF4L20C079670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2006 14:51:07 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 15 Dec 2006 14:50:30 +1030 User-Agent: KMail/1.9.4 References: <20061213192150.CF83D16A417@hub.freebsd.org> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> In-Reply-To: <4581A3E3.9060807@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1402913.g5vAOH2ge4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612151450.39260.doconnor@gsoft.com.au> X-Spam-Score: -1.315 () AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Cc: Peter Jeremy Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 04:21:12 -0000 --nextPart1402913.g5vAOH2ge4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 15 December 2006 05:50, Scott Long wrote: > Yes, the industry moves fast, but that's no reason to fool ourselves > into thinking that the FSF will support GCC 4.2 a day after they release > 4.3 and start working on 4.4. Your point above about the lifespan of > FreeBSD 7.x is a valid one, and I agree that it should be a > consideration. Vendor support is a myth and should not be a > consideration. Not to mention it is *trivial* to install a compiler using ports or package= s. If you are serious about high performance computing installing a new compil= er=20 is about the lowest barrier you'll find. (Unless of course you need all the libraries compiled with OpenMP support=20 before your binary can use it) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1402913.g5vAOH2ge4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFgiKX5ZPcIHs/zowRAujyAJ9HNLHbEwUfZlrE+0Ot2tZRXTbKhQCfbciu 7mdnmIHflWlsC+Kj/d3nAtQ= =MXIn -----END PGP SIGNATURE----- --nextPart1402913.g5vAOH2ge4-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 04:40:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18D5D16A403 for ; Fri, 15 Dec 2006 04:40:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42D7A43CBA for ; Fri, 15 Dec 2006 04:38:12 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id kBF4dnlv009431; Thu, 14 Dec 2006 20:39:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id kBF4dn0Y009430; Thu, 14 Dec 2006 20:39:49 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Dec 2006 20:39:49 -0800 From: Steve Kargl To: Juha Saarinen Message-ID: <20061215043949.GA9381@troutmask.apl.washington.edu> References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <20061215015713.GA33730@dragon.NUXI.org> <45820F35.50802@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 04:40:01 -0000 On Fri, Dec 15, 2006 at 04:15:23PM +1300, Juha Saarinen wrote: > So... silly question perhaps, but does -CURRENT (world + kernel) build > with gcc 4.2 and -fopenmp? What about -STABLE and -RELEASE? > -fopenmp will be a completely useless option for world unless someone starts to sprinkle OpenMP compiler directives throughout /usr/src. I seriously doubt anyone will ever sprinkle OpenMP directives in kernel sources (ie., do you want to link your kernel with libthr or libpthread?). -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 04:44:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68A9C16A415 for ; Fri, 15 Dec 2006 04:44:26 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB05643C9E for ; Fri, 15 Dec 2006 04:42:46 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so368679pyh for ; Thu, 14 Dec 2006 20:44:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hF1fF6InyOLDEENChTjBS9avfpGYXzS1yLk7waBNeDx7uYS4p5lc2Uv2e4UfdzTp3kqjWgUuDkIzdihKuQ9ieIjMxeerITQWeFTcIGS1J9dLZ1PhQ31kOqVFZYSjRBOem64iZt38Vf1UNIwu4eIJ/wUjmI8sBpgCZI13PaDWYeE= Received: by 10.65.122.20 with SMTP id z20mr312100qbm.1166157864617; Thu, 14 Dec 2006 20:44:24 -0800 (PST) Received: by 10.65.61.1 with HTTP; Thu, 14 Dec 2006 20:44:24 -0800 (PST) Message-ID: <790a9fff0612142044o6908b643h2e2988a5a8cfd085@mail.gmail.com> Date: Thu, 14 Dec 2006 22:44:24 -0600 From: "Scot Hetzel" To: "Alexandre Sunny Kovalenko" In-Reply-To: <1166152169.839.4.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612141212t50fb25aeidfbc84435ca2d521@mail.gmail.com> <1166152169.839.4.camel@RabbitsDen.RabbitsLawn.verizon.net> Cc: FreeBSD Current , Rong-en Fan Subject: Re: SD slot on ThinkPad X60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 04:44:26 -0000 On 12/14/06, Alexandre Sunny Kovalenko wrote: > On Fri, 2006-12-15 at 04:12 +0800, Rong-en Fan wrote: > > My ThinkPad X60 has a SD card slot. pciconf -lv shows > > > > none7@pci21:0:2: class=0x080500 card=0x201d17aa chip=0x08221180 > > rev=0x18 hdr=0x00 > > vendor = 'Ricoh Company, Ltd.' > > device = 'SD Bus Host Adapter' > > class = base peripheral > > > > How to use this slot to read SD cards? In ThinkPad X31, the CF slot is > > simulated as an ata drive, so I have adX for the CF card. It seems the > > SD slot here works differently. > > > > Any ideas? > > > > Regards, > > Rong-En Fan > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I have run across this just today: > > http://www.nabble.com/SDHCI-Device-Driver-(first-steps)-t2289693.html > And a web site has been setup by the author of the driver at: http://www.sashi.de/de/freebsd/sdhci/index.html Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 04:44:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9B2016A4D1 for ; Fri, 15 Dec 2006 04:44:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F63B43C9E for ; Fri, 15 Dec 2006 04:43:17 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id kBF4ir4j009474; Thu, 14 Dec 2006 20:44:53 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id kBF4irQq009473; Thu, 14 Dec 2006 20:44:53 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Dec 2006 20:44:53 -0800 From: Steve Kargl To: "Daniel O'Connor" Message-ID: <20061215044453.GB9381@troutmask.apl.washington.edu> References: <20061213192150.CF83D16A417@hub.freebsd.org> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <200612151450.39260.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612151450.39260.doconnor@gsoft.com.au> User-Agent: Mutt/1.4.2.2i Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 04:44:57 -0000 On Fri, Dec 15, 2006 at 02:50:30PM +1030, Daniel O'Connor wrote: > On Friday 15 December 2006 05:50, Scott Long wrote: > > Yes, the industry moves fast, but that's no reason to fool ourselves > > into thinking that the FSF will support GCC 4.2 a day after they release > > 4.3 and start working on 4.4. Your point above about the lifespan of > > FreeBSD 7.x is a valid one, and I agree that it should be a > > consideration. Vendor support is a myth and should not be a > > consideration. > > Not to mention it is *trivial* to install a compiler using ports or packages. > > If you are serious about high performance computing installing a new compiler > is about the lowest barrier you'll find. > Actually, 4.1.x will produce much worse code than 3.4.6. You can search the gcc mail listings for extensive comparison by Clinton Whaley (the author of math/atlas) for details. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 05:08:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1C2CC16A40F; Fri, 15 Dec 2006 05:07:59 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <45822DB2.4020902@freebsd.org> Date: Fri, 15 Dec 2006 13:08:02 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Kargl References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <20061215015713.GA33730@dragon.NUXI.org> <45820F35.50802@samsco.org> <20061215043949.GA9381@troutmask.apl.washington.edu> In-Reply-To: <20061215043949.GA9381@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Juha Saarinen , freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 05:08:01 -0000 Steve Kargl wrote: > On Fri, Dec 15, 2006 at 04:15:23PM +1300, Juha Saarinen wrote: > >>So... silly question perhaps, but does -CURRENT (world + kernel) build >>with gcc 4.2 and -fopenmp? What about -STABLE and -RELEASE? >> > > > -fopenmp will be a completely useless option for world > unless someone starts to sprinkle OpenMP compiler directives > throughout /usr/src. I seriously doubt anyone will ever > sprinkle OpenMP directives in kernel sources (ie., do > you want to link your kernel with libthr or libpthread?). > I think kernel has to implement its own libgomp if -fopenmp will be used for kernel, though I don't have any idea that openmp will be used in kernel. but for application, openmp is worth be to tried. Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 05:43:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F38516A407 for ; Fri, 15 Dec 2006 05:43:17 +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 380B943CA1 for ; Fri, 15 Dec 2006 05:41:36 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBF5h8Bs029837; Thu, 14 Dec 2006 22:43:13 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <458235EC.80300@samsco.org> Date: Thu, 14 Dec 2006 22:43:08 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Kargl References: <20061213192150.CF83D16A417@hub.freebsd.org> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <200612151450.39260.doconnor@gsoft.com.au> <20061215044453.GB9381@troutmask.apl.washington.edu> In-Reply-To: <20061215044453.GB9381@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Peter Jeremy Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 05:43:17 -0000 Steve Kargl wrote: > On Fri, Dec 15, 2006 at 02:50:30PM +1030, Daniel O'Connor wrote: > >>On Friday 15 December 2006 05:50, Scott Long wrote: >> >>>Yes, the industry moves fast, but that's no reason to fool ourselves >>>into thinking that the FSF will support GCC 4.2 a day after they release >>>4.3 and start working on 4.4. Your point above about the lifespan of >>>FreeBSD 7.x is a valid one, and I agree that it should be a >>>consideration. Vendor support is a myth and should not be a >>>consideration. >> >>Not to mention it is *trivial* to install a compiler using ports or packages. >> >>If you are serious about high performance computing installing a new compiler >>is about the lowest barrier you'll find. >> > > > Actually, 4.1.x will produce much worse code than 3.4.6. > You can search the gcc mail listings for extensive comparison > by Clinton Whaley (the author of math/atlas) for details. > Has this been fixed in GCC 4.2? If the FSF claims to have fixed it, has it been actually verified? I thought that gcc 4 was supposed to solve the world's problems with vectorization. Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 06:27:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 944F616A403 for ; Fri, 15 Dec 2006 06:27:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 884F843CA3 for ; Fri, 15 Dec 2006 06:25:38 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id kBF6RDZj010023; Thu, 14 Dec 2006 22:27:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id kBF6RDJM010022; Thu, 14 Dec 2006 22:27:13 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Dec 2006 22:27:13 -0800 From: Steve Kargl To: Scott Long Message-ID: <20061215062713.GA9843@troutmask.apl.washington.edu> References: <20061213192150.CF83D16A417@hub.freebsd.org> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <200612151450.39260.doconnor@gsoft.com.au> <20061215044453.GB9381@troutmask.apl.washington.edu> <458235EC.80300@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <458235EC.80300@samsco.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org, Peter Jeremy Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 06:27:18 -0000 On Thu, Dec 14, 2006 at 10:43:08PM -0700, Scott Long wrote: > Steve Kargl wrote: > > >Actually, 4.1.x will produce much worse code than 3.4.6. > >You can search the gcc mail listings for extensive comparison > >by Clinton Whaley (the author of math/atlas) for details. > > > > Has this been fixed in GCC 4.2? If the FSF claims to have fixed it, > has it been actually verified? I thought that gcc 4 was supposed to > solve the world's problems with vectorization. > I was hoping to avoid participation in this thread, but ... gcc-4.0.0 == freebsd-5.0 gcc-4.1.0 == freebsd-5.5 gcc-4.2.x == freebsd-6.0 Now for the details. gcc-4.0 completely replaced the intermediate representation (IR) of the parsed language with the tree-ssa form. This IR sits between the frontend and the backend code generator. I would call 4.0 the "make it work" stage. gcc 4.1 concentrated on bug fixes, and gcc 4.2 has started to remove the warts (e.g., slow compilation times, bloated generated code, etc.) Pushing to include 4.2 over 4.1, based on OpenMP, is a red herring, IMHO. -fopenmp does not magically include OpenMP directives in code. That is, -fopenmp is useless for the code in the FreeBSD base system, and anyone that needs OpenMP for a port can install 4.2 or even 4.3 (head of gcc tree). For the record, -ftree-vectorize may be more important then -fopenmp for out-of-box compilation. As to stability, 4.2 is fairly good. There are, of course, bugs and some regressions, but these get addressed quickly. Additionally, 4.2 may have better support for ARM and newer processors. Also note that the system compiler on newer versions of Redhat and SuSe is 4.1. The biggest concern is the strictness of the C and C++ frontends. GCC has moved to better adherence to the Standards, which will impact the ports collections. Finally, for the record. I routinely bootstrap GCC 4.1-branch, 4.2-branch, and 4.3 (mainline) on FreeBSD-amd64 6.2-prerelease and 7.0. I've contributed hundreds of patch to the Fortran frontend and runtime library, and I'm listed as a Fortran maintainer. Other than FreeBSD's libm lack of long double function (which I've tried submitting code to rectify), the Fortran compiler works great under FreeBSD. In the end, GCC and FreeBSD development is simply governed by the principle of "Too few developer, too much to do". At some point the development decides that a version is no longer supported. For GCC, it is 3.4.x, and for FreeBSD, it is 4.11. Scott, if you want to discuss other concerns, contact me off-list. PS: Peter Jeremy has had one of the few valid reason for going directly to 4.2. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 10:15:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03F8316A407; Fri, 15 Dec 2006 10:15:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0371143CA0; Fri, 15 Dec 2006 10:13:41 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GvA65-0001oy-5M; Fri, 15 Dec 2006 12:15:21 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 2006 12:15:21 +0200 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Kernel Virtual Machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 10:15:23 -0000 sorry for the cross-posting, but not realy sure where this belongs. Linux just incorporated this, so I was wondering if anything along this lines is being done/concidered for FreeBSD? see: http://aplawrence.com/Linux/kvm_virtualization.html http://osdir.com/Article9554.phtml Cheers, danny PS: I think that the K in kvm is for 'Avi Kivity' From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 11:50:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71D0016A47E for ; Fri, 15 Dec 2006 11:50:19 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A8FD043C9F for ; Fri, 15 Dec 2006 11:48:37 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 15 Dec 2006 11:50:17 -0000 Received: from h081217095052.dyn.cm.kabsi.at (EHLO [192.168.0.1]) [81.217.95.52] by mail.gmx.net (mp023) with SMTP; 15 Dec 2006 12:50:17 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Fri, 15 Dec 2006 12:50:08 +0100 User-Agent: KMail/1.9.4 References: <20061213192150.CF83D16A417@hub.freebsd.org> <20061215044453.GB9381@troutmask.apl.washington.edu> <458235EC.80300@samsco.org> In-Reply-To: <458235EC.80300@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612151250.10033.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Peter Jeremy , Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 11:50:19 -0000 On Friday 15 December 2006 06:43, Scott Long wrote: > Steve Kargl wrote: > > On Fri, Dec 15, 2006 at 02:50:30PM +1030, Daniel O'Connor wrote: > >>On Friday 15 December 2006 05:50, Scott Long wrote: > >>>Yes, the industry moves fast, but that's no reason to fool ourselves > >>>into thinking that the FSF will support GCC 4.2 a day after they release > >>>4.3 and start working on 4.4. Your point above about the lifespan of > >>>FreeBSD 7.x is a valid one, and I agree that it should be a > >>>consideration. Vendor support is a myth and should not be a > >>>consideration. > >> > >>Not to mention it is *trivial* to install a compiler using ports or > >> packages. > >> > >>If you are serious about high performance computing installing a new > >> compiler is about the lowest barrier you'll find. > > > > Actually, 4.1.x will produce much worse code than 3.4.6. > > You can search the gcc mail listings for extensive comparison > > by Clinton Whaley (the author of math/atlas) for details. > > Has this been fixed in GCC 4.2? If the FSF claims to have fixed it, > has it been actually verified? I thought that gcc 4 was supposed to > solve the world's problems with vectorization. I've been playing around with optimizations for a small cpu-intensive program (only integer, no FP) for a course some time ago and tested different gcc versions. gcc-3.4 (with -O3 -march=pentium4) won over gcc-4.0 there. My new test setup: FreeBSD 6.2-RC1 gcc version 3.4.6 [FreeBSD] 20060305 (base system) gcc version 4.1.2 20061013 (prerelease) (lang/gcc41 package) gcc version 4.2.0 20061014 (experimental) (lang/gcc42 package) CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU) Instructions counted with pmcstat -C -p k7-retired-instructions Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 ----------------------------+---------+---------+--------- -O2 | 13.1bn | 13.8bn | 13.5bn -O2 -funroll-loops | 9.6bn | 9.3bn | 9.2bn -O2 -march=athlon-xp -fun.. | 9.7bn | 10.6bn | 10.7bn -O3 | 11.5bn | 9.5bn | 9.6bn -O3 -funroll-loops | 8.4bn | 9.2bn | 9.4bn -O3 -march=athlon-xp -fun.. | 8.8bn | 10.6bn | 11.1bn I'm aware that testing with a single program is not too meaningful, but it might give a hint at least. From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 12:38:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0237316A412 for ; Fri, 15 Dec 2006 12:38:41 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a18.dreamhost.com (sd-green-bigip-207.dreamhost.com [208.97.132.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA79D43CAD for ; Fri, 15 Dec 2006 12:36:54 +0000 (GMT) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.203.29.76]) by spunkymail-a18.dreamhost.com (Postfix) with ESMTP id 9B2BA5B533; Fri, 15 Dec 2006 04:38:32 -0800 (PST) Date: Fri, 15 Dec 2006 10:38:29 -0200 From: Ricardo Nabinger Sanchez To: "George V. Neville-Neil" Message-Id: <20061215103829.ac553aed.rnsanchez@wait4.org> In-Reply-To: References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> Organization: SYS_WAIT4 X-Mailer: Sylpheed version 2.3.0beta6 (GTK+ 2.10.6; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 12:38:41 -0000 On Fri, 15 Dec 2006 10:04:20 +0900 "George V. Neville-Neil" wrote: > So, what are the other BSDs using, and what are the Linux distros > using or planning to use? Does anyone know? Gobolinux, on its latest stable release (013), ships gcc-4.1.1. One of the core developers just started looking at gcc-4.2. Their transition model is smooth, both gcc versions can coexist pacifically, and once the new one is considered stable enough, it becomes the default version. -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 13:40:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CA0E16A49E for ; Fri, 15 Dec 2006 13:40:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABEC143CB3 for ; Fri, 15 Dec 2006 13:38:13 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 8A47F1747B; Fri, 15 Dec 2006 13:39:53 +0000 (UTC) To: Stefan Ehmann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 15 Dec 2006 12:50:08 +0100." <200612151250.10033.shoesoft@gmx.net> Date: Fri, 15 Dec 2006 13:39:48 +0000 Message-ID: <23331.1166189988@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Peter Jeremy , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 13:40:06 -0000 In message <200612151250.10033.shoesoft@gmx.net>, Stefan Ehmann writes: >Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 >----------------------------+---------+---------+--------- >-O2 | 13.1bn | 13.8bn | 13.5bn >-O2 -funroll-loops | 9.6bn | 9.3bn | 9.2bn >-O2 -march=athlon-xp -fun.. | 9.7bn | 10.6bn | 10.7bn >-O3 | 11.5bn | 9.5bn | 9.6bn >-O3 -funroll-loops | 8.4bn | 9.2bn | 9.4bn >-O3 -march=athlon-xp -fun.. | 8.8bn | 10.6bn | 11.1bn I love benchmarks. It's great when people benchmark things. Unfortunately, that is not what you have done, because you have not indicated what the standard deviation on your numbers are, so they are totally worthless. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 14:05:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E23ED16A403 for ; Fri, 15 Dec 2006 14:05:32 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D918543CA6 for ; Fri, 15 Dec 2006 14:03:50 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id kBFE5W5c065421; Fri, 15 Dec 2006 06:05:32 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id kBFE5WbO065420; Fri, 15 Dec 2006 06:05:32 -0800 (PST) (envelope-from rizzo) Date: Fri, 15 Dec 2006 06:05:32 -0800 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20061215060531.B65183@xorpc.icir.org> References: <200612151250.10033.shoesoft@gmx.net> <23331.1166189988@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <23331.1166189988@critter.freebsd.dk>; from phk@phk.freebsd.dk on Fri, Dec 15, 2006 at 01:39:48PM +0000 Cc: Peter Jeremy , freebsd-current@freebsd.org, Steve Kargl , Stefan Ehmann Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 14:05:33 -0000 On Fri, Dec 15, 2006 at 01:39:48PM +0000, Poul-Henning Kamp wrote: > In message <200612151250.10033.shoesoft@gmx.net>, Stefan Ehmann writes: > > >Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 > >----------------------------+---------+---------+--------- > >-O2 | 13.1bn | 13.8bn | 13.5bn > >-O2 -funroll-loops | 9.6bn | 9.3bn | 9.2bn > >-O2 -march=athlon-xp -fun.. | 9.7bn | 10.6bn | 10.7bn > >-O3 | 11.5bn | 9.5bn | 9.6bn > >-O3 -funroll-loops | 8.4bn | 9.2bn | 9.4bn > >-O3 -march=athlon-xp -fun.. | 8.8bn | 10.6bn | 11.1bn > > I love benchmarks. > > It's great when people benchmark things. > > Unfortunately, that is not what you have done, because you have > not indicated what the standard deviation on your numbers are, > so they are totally worthless. in general, you are totally right. but note that in this specific case, these seem to be the numbers of retired instructions, not cycles or times. So they should be rather deterministic (apart from background noise due to races in getting locks, interfering kernel activity etc. - which in truth the SD would help characterising :) cheers luigi > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > 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 Fri Dec 15 14:08:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A24F816A415; Fri, 15 Dec 2006 14:08:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A39C943CAA; Fri, 15 Dec 2006 14:06:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBFE88Ut050791; Fri, 15 Dec 2006 09:08:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFE88gs067145; Fri, 15 Dec 2006 09:08:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3041573036; Fri, 15 Dec 2006 09:08:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215140808.3041573036@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 09:08:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner3 X-Virus-Status: Clean 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: Fri, 15 Dec 2006 14:08:10 -0000 TB --- 2006-12-15 13:39:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 13:39:10 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-15 13:39:10 - cleaning the object tree TB --- 2006-12-15 13:39:40 - checking out the source tree TB --- 2006-12-15 13:39:40 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-15 13:39:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 13:49:51 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 13:49:51 - cd /src TB --- 2006-12-15 13:49:51 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 13:49:52 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 14:08:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 14:08:08 - ERROR: failed to build world TB --- 2006-12-15 14:08:08 - tinderbox aborted TB --- 0.59 user 2.45 system 1737.90 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 14:08:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A73AD16A417; Fri, 15 Dec 2006 14:08:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92F3C43CA8; Fri, 15 Dec 2006 14:06:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBFE881P050790; Fri, 15 Dec 2006 09:08:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFE88D7067138; Fri, 15 Dec 2006 09:08:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0BDC673034; Fri, 15 Dec 2006 09:08:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215140808.0BDC673034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 09:08:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean 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: Fri, 15 Dec 2006 14:08:10 -0000 TB --- 2006-12-15 13:44:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 13:44:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-15 13:44:35 - cleaning the object tree TB --- 2006-12-15 13:45:10 - checking out the source tree TB --- 2006-12-15 13:45:10 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-15 13:45:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 13:49:51 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 13:49:51 - cd /src TB --- 2006-12-15 13:49:51 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 13:49:52 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 14:08:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 14:08:07 - ERROR: failed to build world TB --- 2006-12-15 14:08:07 - tinderbox aborted TB --- 0.59 user 2.01 system 1412.32 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 14:39:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7580216A403; Fri, 15 Dec 2006 14:39:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A49A043CF1; Fri, 15 Dec 2006 14:37:06 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFEclpV033524; Fri, 15 Dec 2006 09:38:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFEcl49001250; Fri, 15 Dec 2006 09:38:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1ED0473034; Fri, 15 Dec 2006 09:38:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215143847.1ED0473034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 09:38:46 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Fri, 15 Dec 2006 14:39:04 -0000 TB --- 2006-12-15 14:10:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 14:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-15 14:10:00 - cleaning the object tree TB --- 2006-12-15 14:10:45 - checking out the source tree TB --- 2006-12-15 14:10:45 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-15 14:10:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 14:19:54 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 14:19:54 - cd /src TB --- 2006-12-15 14:19:54 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 14:19:55 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 14:38:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 14:38:46 - ERROR: failed to build world TB --- 2006-12-15 14:38:46 - tinderbox aborted TB --- 0.84 user 3.43 system 1726.31 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 15:09:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7925116A417 for ; Fri, 15 Dec 2006 15:09:59 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A5A0143CA1 for ; Fri, 15 Dec 2006 15:08:16 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 15 Dec 2006 15:09:54 -0000 Received: from h081217095052.dyn.cm.kabsi.at (EHLO [192.168.0.1]) [81.217.95.52] by mail.gmx.net (mp001) with SMTP; 15 Dec 2006 16:09:54 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: "Poul-Henning Kamp" Date: Fri, 15 Dec 2006 16:09:52 +0100 User-Agent: KMail/1.9.4 References: <23331.1166189988@critter.freebsd.dk> In-Reply-To: <23331.1166189988@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612151609.53750.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Peter Jeremy , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 15:09:59 -0000 On Friday 15 December 2006 14:39, Poul-Henning Kamp wrote: > In message <200612151250.10033.shoesoft@gmx.net>, Stefan Ehmann writes: > >Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 > >----------------------------+---------+---------+--------- > >-O2 | 13.1bn | 13.8bn | 13.5bn > >-O2 -funroll-loops | 9.6bn | 9.3bn | 9.2bn > >-O2 -march=athlon-xp -fun.. | 9.7bn | 10.6bn | 10.7bn > >-O3 | 11.5bn | 9.5bn | 9.6bn > >-O3 -funroll-loops | 8.4bn | 9.2bn | 9.4bn > >-O3 -march=athlon-xp -fun.. | 8.8bn | 10.6bn | 11.1bn > > I love benchmarks. > > It's great when people benchmark things. > > Unfortunately, that is not what you have done, because you have > not indicated what the standard deviation on your numbers are, > so they are totally worthless. I've done 3 runs on an otherwise pretty idle system with a maximum deviation of maybe 1 million instructions. So I figured that accurately calculating the standard deviation would overshoot the mark for this primitive test. IMHO the much weaker point in my benchmark is using a single program and only instruction count. What I wanted to show is whether gcc4 can still be worse than gcc34 in some cases. Sometimes performance counters can vary a lot (I've seen double the instructions on the p4 machine using papiex). So here are the results for the "-O3 -funroll-loops" row (using the output of 100 runs). Going on further seems pretty pointless to me. Using a 99.7 confidence interval, I get these results: -O3 -funroll-loops: gcc-3.4: 8362606323 +/- 440336 gcc-4.1: 9246505378 +/- 531302 gcc-4.2: 9401195544 +/- 784106 From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 15:39:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2297F16A407 for ; Fri, 15 Dec 2006 15:39:44 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19FCA43CAA for ; Fri, 15 Dec 2006 15:38:01 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 4B1AF535B2; Fri, 15 Dec 2006 10:39:42 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Fri, 15 Dec 2006 10:39:42 -0500 X-Sasl-enc: mYONymzkucxYWgbsIh9SbbX8Rq2ooY4Wxn0F1udyQjLM 1166197181 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 8CF131D78F; Fri, 15 Dec 2006 10:39:41 -0500 (EST) Message-ID: <4582C1BC.3090001@FreeBSD.org> Date: Fri, 15 Dec 2006 15:39:40 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel Virtual Machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 15:39:44 -0000 [Dropped crosspost to -current] Danny Braniss wrote: > Linux just incorporated this, so I was wondering if anything > along this lines is being done/concidered for FreeBSD? > see: > http://aplawrence.com/Linux/kvm_virtualization.html > http://osdir.com/Article9554.phtml > Yes please!! Making use of VT/similar is a big reason I'd upgrade to a more recent CPU. I'd certainly offer to test this if I can't dedicate resources to working on it. Regards, BMS From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 15:54:44 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 693DB16A40F for ; Fri, 15 Dec 2006 15:54:44 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [80.253.10.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0CBC43CE7 for ; Fri, 15 Dec 2006 15:52:26 +0000 (GMT) (envelope-from bsam@ipt.ru) Received: from srv.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GvFNv-000845-8t for freebsd-current@FreeBSD.org; Fri, 15 Dec 2006 18:54:07 +0300 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GvFP3-00053U-6W for freebsd-current@FreeBSD.org; Fri, 15 Dec 2006 18:55:17 +0300 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Fri, 15 Dec 2006 18:55:17 +0300 Message-ID: <55973034@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: diskless stations and 7-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: Fri, 15 Dec 2006 15:54:44 -0000 Hello All! I've been testing diskless stations. The server runs 7-current i386 (built at 2006-12-11). PXE loads pxeboot, then the GENERIC kernel is loaded via NFS. / and /usr are NFS mounted from the server. /home is NFS mounted from a workstation. Here are some results. 1. The bootpd daemon sometimes do the work, sometimes -- not. It is loaded via inetd but stays loaded forever (according to bootpd(8) the default value is 15 minutes). I didn't find out when/why it fails. One morning (the daemon survived the whole night) I killed it and the next booting was a success. Then it failed again. net/isc-dhcp3-server works here just fine. 2. While booting, the diskless station logs a note that /var/db/mountdtab cannot be created. After /conf/default/var/db directory is created those messages dissapears. 3. Diskless stations hang forever when "shutdown -p" at "saving entropy". Halt and reboot work as expected. 4. If gdm is started at the diskless station there is no chance to switch to any console, doesn't work. 5. GDM seems to be build by default with IPv6 support and listens only at udp6 *.xdmcp. Rebuilding without IPv6 helps to get it listen at udp4. Other then that works just fine. Thanks for all folks doing the hard work! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 16:44:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DD8D16A412; Fri, 15 Dec 2006 16:44:50 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BC5043D91; Fri, 15 Dec 2006 16:42:14 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBFGhTEN031995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2006 08:43:34 -0800 Message-ID: <4582D0B0.40108@freebsd.org> Date: Fri, 15 Dec 2006 08:43:28 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Doug Barton References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> <458048DB.2020002@FreeBSD.org> In-Reply-To: <458048DB.2020002@FreeBSD.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig983D9876F0D20CE92350335C" Cc: gnn@freebsd.org, freebsd-current@freebsd.org, re@freebsd.org Subject: Re: Socket problems with latest -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: Fri, 15 Dec 2006 16:44:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig983D9876F0D20CE92350335C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Doug Barton wrote: > gnn@freebsd.org wrote: >> At Mon, 11 Dec 2006 01:35:17 -0800, >> Doug Barton wrote: >>> Doug Barton wrote: >>>> With sources cvsup'ed around 20:35 PST on 8 December everything work= s >>>> just fine. With sources cvsup'ed early this morning, 12:42 am PST on= >>>> 10 December, I'm getting a lot of errors related to sockets: >>> I found the problem, it's the change made in version 1.4 of >>> rc.d/auto_linklocal. Reverting only that change, and using otherwise >>> up to date -current sources allows things to work just fine. Adding >>> that change on the same exact system causes the breakage I described >>> in my previous message. >>> >>> It's probably worth mentioning that I exactly fit the criteria from >>> the 1.4 commit message, I have INET6 in my kernel, but at the moment = I >>> have ipv6_enable=3Dno in rc.conf. >>> >>> This change should be backed out of HEAD and RELENG_6[_2] until the >>> cause of this breakage is understood. >> I'll take a quick look at this too. =20 >=20 > Thanks. I installed a totally generic RELENG_6 system from scratch > yesterday, and confirmed that the problem I had in -current exists in > -stable too. This is a serious issue, given that the default > installation will have INET6 in the kernel, but ipv6_enable=3Dno in > /etc/defaults/rc.conf. >=20 > It would be preferable of course to fix the actual problem, but > between "it works" and "it is fully RFC compliant," I have to pick the > former. Hey Doug-- I'm trying to reproduce this problem but without success. I did an install of 6.2-RC1/i386 from CD into a Parallels VM, then manually updated /etc/rc.d/auto_linklocal to version 1.1.2.3.2.1 (same as 1.4 you tested with). I'm running a GENERIC kernel with ipv6_enable=3D"NO" set i= n /etc/rc.conf. I set sshd_enable=3D"YES" and sendmail_enable=3D"YES" and they both seem to be behaving normally. vm2# ifconfig ed0: flags=3D8843 mtu 1500 inet WW.XX.YY.ZZ netmask 0xffffff00 broadcast WW.XX.YY.255 ether 00:5d:54:14:12:1a media: Ethernet autoselect (10baseT/UTP) lo0: flags=3D8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 I also remember lightly testing this change before it was committed, so I'm kind of puzzled by the problems you saw. Do you have any other information that you think might be useful? Thanks! Bruce. --------------enig983D9876F0D20CE92350335C 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgtCw2MoxcVugUsMRAn5ZAJ9lM1hAalUHDTaKewMiVpCEYDLfRwCfX+e+ G+HKUE8Z9jv/qZoFM8ViY6A= =aUA/ -----END PGP SIGNATURE----- --------------enig983D9876F0D20CE92350335C-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 16:54:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2165416A417; Fri, 15 Dec 2006 16:54:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D2F243D6E; Fri, 15 Dec 2006 16:49:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFGpLNg065469; Fri, 15 Dec 2006 11:51:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFGpL7P016017; Fri, 15 Dec 2006 11:51:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D7BA473034; Fri, 15 Dec 2006 11:51:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215165120.D7BA473034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 11:51:20 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 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: Fri, 15 Dec 2006 16:54:31 -0000 TB --- 2006-12-15 16:21:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 16:21:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-15 16:21:05 - cleaning the object tree TB --- 2006-12-15 16:21:34 - checking out the source tree TB --- 2006-12-15 16:21:34 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-15 16:21:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 16:28:46 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 16:28:46 - cd /src TB --- 2006-12-15 16:28:46 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 16:28:47 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 16:51:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 16:51:20 - ERROR: failed to build world TB --- 2006-12-15 16:51:20 - tinderbox aborted TB --- 0.59 user 2.53 system 1814.87 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 17:23:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CF0716A40F; Fri, 15 Dec 2006 17:23:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6925D43F45; Fri, 15 Dec 2006 17:16:31 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFHI1Um070744; Fri, 15 Dec 2006 12:18:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFHI1f3088077; Fri, 15 Dec 2006 12:18:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7355673034; Fri, 15 Dec 2006 12:18:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215171801.7355673034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 12:18:01 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean 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: Fri, 15 Dec 2006 17:23:10 -0000 TB --- 2006-12-15 16:51:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 16:51:21 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-15 16:51:21 - cleaning the object tree TB --- 2006-12-15 16:51:32 - checking out the source tree TB --- 2006-12-15 16:51:32 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-15 16:51:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 17:00:36 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 17:00:36 - cd /src TB --- 2006-12-15 17:00:36 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 17:00:37 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 17:18:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 17:18:01 - ERROR: failed to build world TB --- 2006-12-15 17:18:01 - tinderbox aborted TB --- 0.15 user 0.70 system 1600.05 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 17:36:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 100AB16A50B for ; Fri, 15 Dec 2006 17:36:33 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75AD543DB0 for ; Fri, 15 Dec 2006 17:33:48 +0000 (GMT) (envelope-from freebsd-current@dino.sk) Received: from [192.168.16.241] (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by bsd.dino.sk with esmtp; Fri, 15 Dec 2006 18:37:48 +0100 id 0000008E.4582DD6C.0000138D From: Milan Obuch To: freebsd-current@freebsd.org Date: Fri, 15 Dec 2006 18:34:56 +0100 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612151834.57201.freebsd-current@dino.sk> Subject: kern/58953 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 17:36:33 -0000 Could someone look at this PR and commit? It is a minor modification, tested in production for couple of years. Without this patch, six-port NetMos cards are recognised as four port only. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 17:37:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA2D616A494 for ; Fri, 15 Dec 2006 17:37:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id DED8043CA3 for ; Fri, 15 Dec 2006 17:36:09 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so1134823nfc for ; Fri, 15 Dec 2006 09:37:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=RRaX9Px1l4UqXAJQz5sxY7A9HR2KkgOqADj/g4yoxUHMFTr8GzZaVPVbobZZdE+ZcI6OnddRs/QAVAYZd7Yw4Oa5dfZ/wmbEx2LWJDadIv8olpfQskwPa25HDaIl3b5aDPnCfEH0AFzg63wYyXdFS3jmSCEJjnYDOgE/Wa1QFDc= Received: by 10.48.48.1 with SMTP id v1mr146695nfv.1166204265909; Fri, 15 Dec 2006 09:37:45 -0800 (PST) Received: by 10.82.178.4 with HTTP; Fri, 15 Dec 2006 09:37:45 -0800 (PST) Message-ID: <3bbf2fe10612150937q675213e8tfb646401e95db8ec@mail.gmail.com> Date: Fri, 15 Dec 2006 18:37:45 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200612131226.48087.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456950AF.3090308@sh.cvut.cz> <200612121412.13551.jhb@freebsd.org> <20061213133411.S1136@delplex.bde.org> <200612131226.48087.jhb@freebsd.org> X-Google-Sender-Auth: 3426cf3bf6140c4e Cc: Bruce Evans , Suleiman Souhlal , freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov , tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 17:37:54 -0000 2006/12/13, John Baldwin : > On Tuesday 12 December 2006 21:48, Bruce Evans wrote: > > > Memory barriers just specify ordering, they don't ensure a cache flush so > > > another CPU reads up to date values. You can use memory barriers in > > > conjunction with atomic operations on a variable to ensure that you can > > > safely read other variables (which is what locks do). For example, in > this > > > > I thought that the acquire/release variants of atomic ops guarantee > > this. They seem to be documented to do this, while mutexes don't seem > > to be documented to do this. The MI (?) implementation of mutexes > > depends on atomic_cmpset_{acq,rel}_ptr() doing this. > > The acq/rel just specify ordering. As Attilio mentioned, we assume that the > atomic_cmpset() that sets the contested flag will fail while racing with > another CPU (even if the CPU can't see the new value, as long as it fails and > keeps spinning mutexes will still work). The 'rel' barrier on CPU A when > releasing a lock forces all the other writes to be posted (and eventually > become "visible") to other CPUs before the write that releases the lock. > The 'acq' barrier on CPU B when acquiring the lock forces the CPU to not > reorder any reads before it acquires the lock, so this makes you not read any > data until you have the lock. Thus, once CPU B has waited long enough > to "see" the write from A to release the lock, we know that 1) it can > also "see" all the other writes from that CPU that the lock protected, and 2) > B hasn't tried to read any of them yet so it shouldn't have any stale values > in registers. None of this requires the OS to do a cache flush. (If you > have an SMP system where the cache can still hold stale values after another > CPU updates values in memory where it is "visible" to the CPU acquiring the > lock, then _acq might need to flush the cache, but that would be a property > of that architecture. However, even that would not require cache flushes so > long as the stale values were evicted from the cache such that they honor the > memory barrier and you don't see the new value of the lock until you see the > new values of the earlier data.) just a note: you can have a pratical overview of this with rwlocks implementation (and with the difference between the exclusive case and the shared case). When we have a 'write' case we just apply the mutex semantic (with very few implementation changes details), so we have to use and acquiring memory barrier for locking and a rel memory barrier for unlocking. The thing is very different when acquiring a rwlock into the 'read' case. Even if it is simple to understand that an acq semantic is needed for locking (due to the fact that we might force the CPU to not read any stale value before to acquire the lock), it is also simple to understand that, since no (protected) value is updated due to the semantic of read lock, there is no real necessity to use a release (or whatelse) memory barrier (since that seriality would be assured from the next thread acq barrier again). In a more pratical manner, since we can use it in this way: struct foo_softc { uint32_t sc_flags; uint32_t sc_gooo; struct rwlock sc_lock; }; .. uint32_t fs; rw_rlock(&sc->sc_lock); fs = sc->sc_flags; rw_runlock(&sc->sc_lock); since no writing of the members of struct foo_softc is previewed it is safe to only use an atomic instruction more than a memory barrier. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 17:43:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 146DE16A403; Fri, 15 Dec 2006 17:43:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1D1643C9F; Fri, 15 Dec 2006 17:42:02 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBFHhiaB080323; Fri, 15 Dec 2006 12:43:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFHhieB017219; Fri, 15 Dec 2006 12:43:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6060773034; Fri, 15 Dec 2006 12:43:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215174344.6060773034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 12:43:44 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean 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: Fri, 15 Dec 2006 17:43:46 -0000 TB --- 2006-12-15 17:18:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 17:18:01 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-15 17:18:01 - cleaning the object tree TB --- 2006-12-15 17:18:11 - checking out the source tree TB --- 2006-12-15 17:18:11 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-15 17:18:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 17:26:09 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 17:26:09 - cd /src TB --- 2006-12-15 17:26:09 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 17:26:10 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 17:43:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 17:43:44 - ERROR: failed to build world TB --- 2006-12-15 17:43:44 - tinderbox aborted TB --- 0.22 user 0.59 system 1542.51 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 17:50:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C38BC16A407 for ; Fri, 15 Dec 2006 17:50:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 856F243CAA for ; Fri, 15 Dec 2006 17:48:52 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B416C1747B; Fri, 15 Dec 2006 17:50:33 +0000 (UTC) To: Stefan Ehmann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 15 Dec 2006 16:09:52 +0100." <200612151609.53750.shoesoft@gmx.net> Date: Fri, 15 Dec 2006 17:50:28 +0000 Message-ID: <24131.1166205028@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Peter Jeremy , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 17:50:35 -0000 In message <200612151609.53750.shoesoft@gmx.net>, Stefan Ehmann writes: >On Friday 15 December 2006 14:39, Poul-Henning Kamp wrote: >> Unfortunately, that is not what you have done, because you have >> not indicated what the standard deviation on your numbers are, >> so they are totally worthless. >I've done 3 runs on an otherwise pretty idle system with a maximum deviation >of maybe 1 million instructions. So I figured that accurately calculating the >standard deviation would overshoot the mark for this primitive test. If you had included this information, all would have been fine. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 18:14:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27B6216A500 for ; Fri, 15 Dec 2006 18:14:57 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id AC54043C9D for ; Fri, 15 Dec 2006 18:13:13 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 15 Dec 2006 18:14:54 -0000 Received: from h081217095052.dyn.cm.kabsi.at (EHLO [192.168.0.1]) [81.217.95.52] by mail.gmx.net (mp008) with SMTP; 15 Dec 2006 19:14:54 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Fri, 15 Dec 2006 19:14:53 +0100 User-Agent: KMail/1.9.4 References: <20061213192150.CF83D16A417@hub.freebsd.org> <458235EC.80300@samsco.org> <200612151250.10033.shoesoft@gmx.net> In-Reply-To: <200612151250.10033.shoesoft@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612151914.53705.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Peter Jeremy , Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 18:14:57 -0000 On Friday 15 December 2006 12:50, Stefan Ehmann wrote: > On Friday 15 December 2006 06:43, Scott Long wrote: > > Steve Kargl wrote: > > > On Fri, Dec 15, 2006 at 02:50:30PM +1030, Daniel O'Connor wrote: > > >>On Friday 15 December 2006 05:50, Scott Long wrote: > > >>>Yes, the industry moves fast, but that's no reason to fool ourselves > > >>>into thinking that the FSF will support GCC 4.2 a day after they > > >>> release 4.3 and start working on 4.4. Your point above about the > > >>> lifespan of FreeBSD 7.x is a valid one, and I agree that it should be > > >>> a > > >>>consideration. Vendor support is a myth and should not be a > > >>>consideration. > > >> > > >>Not to mention it is *trivial* to install a compiler using ports or > > >> packages. > > >> > > >>If you are serious about high performance computing installing a new > > >> compiler is about the lowest barrier you'll find. > > > > > > Actually, 4.1.x will produce much worse code than 3.4.6. > > > You can search the gcc mail listings for extensive comparison > > > by Clinton Whaley (the author of math/atlas) for details. > > > > Has this been fixed in GCC 4.2? If the FSF claims to have fixed it, > > has it been actually verified? I thought that gcc 4 was supposed to > > solve the world's problems with vectorization. > > I've been playing around with optimizations for a small cpu-intensive > program (only integer, no FP) for a course some time ago and tested > different gcc versions. gcc-3.4 (with -O3 -march=pentium4) won over gcc-4.0 > there. > > My new test setup: > FreeBSD 6.2-RC1 > gcc version 3.4.6 [FreeBSD] 20060305 (base system) > gcc version 4.1.2 20061013 (prerelease) (lang/gcc41 package) > gcc version 4.2.0 20061014 (experimental) (lang/gcc42 package) > > CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU) > Instructions counted with > pmcstat -C -p k7-retired-instructions > > Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 > ----------------------------+---------+---------+--------- > -O2 | 13.1bn | 13.8bn | 13.5bn > -O2 -funroll-loops | 9.6bn | 9.3bn | 9.2bn > -O2 -march=athlon-xp -fun.. | 9.7bn | 10.6bn | 10.7bn > -O3 | 11.5bn | 9.5bn | 9.6bn > -O3 -funroll-loops | 8.4bn | 9.2bn | 9.4bn > -O3 -march=athlon-xp -fun.. | 8.8bn | 10.6bn | 11.1bn > > > I'm aware that testing with a single program is not too meaningful, but it > might give a hint at least. Ok, forget these numbers. I wanted to measure cycles, not instructions (since less instructions don't necessarily mean less running time). Additonally, I accidently used -march=pentium4 instead of -march=athlon-xp. hwpmc doesn't seem to provide cycle statistics, so I'm falling back to time (using user+sys). 20 runs, standard deviation is <= 0.01 for all values. Ok, another try that makes gcc-4.2 look quite good. Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 ----------------------------+---------+---------+--------- -O2 | 6.46s | 6.67s | 6.38s -O2 -funroll-loops | 4.44s | 4.16s | 4.02s -O2 -march=athlon-xp -fun.. | 4.39s | 4.38s | 4.26s -O3 | 6.14s | 5.23s | 5.16s -O3 -funroll-loops | 4.24s | 4.87s | 4.95s -O3 -march=athlon-xp -fun.. | 4.19s | 4.90s | 5.07s From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 18:19:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62B0F16A4C8 for ; Fri, 15 Dec 2006 18:19:58 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1406F43CCA for ; Fri, 15 Dec 2006 18:18:02 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id D9E5BEB4F15; Sat, 16 Dec 2006 02:19:43 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id K2RV-XO-VeEG; Sat, 16 Dec 2006 02:19:36 +0800 (CST) Received: from [192.168.1.32] (unknown [221.216.128.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 60A68EB4E3F; Sat, 16 Dec 2006 02:19:36 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=E9RY52Hq1j/soR3/bhqk9JZXf+VMQOan173mFq564oqcWBECo9iEWXvYfu92Sz6Mp VsKDYWeVoiMVvSnDk4wZA== Message-ID: <4582E70B.4000508@delphij.net> Date: Sat, 16 Dec 2006 02:18:51 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Milan Obuch References: <200612151834.57201.freebsd-current@dino.sk> In-Reply-To: <200612151834.57201.freebsd-current@dino.sk> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigB1579E7F3A37B189721345EE" Cc: freebsd-current@freebsd.org Subject: Re: kern/58953 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 18:19:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1579E7F3A37B189721345EE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Milan Obuch wrote: > Could someone look at this PR and commit? > It is a minor modification, tested in production for couple of years. W= ithout=20 > this patch, six-port NetMos cards are recognised as four port only. > Regards, It looks like that 7.0-CURRENT would support it? I mean, the patch is only necessary for RELENG_6, and not -HEAD? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigB1579E7F3A37B189721345EE 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.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgucLOfuToMruuMARA3bBAKCHxxTBkvcHmP1g6H7cPPSg9si99QCdHzek 1T4xMZQC0GIkGkiep99XjhM= =xS7A -----END PGP SIGNATURE----- --------------enigB1579E7F3A37B189721345EE-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 18:24:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26D7316A407 for ; Fri, 15 Dec 2006 18:24:54 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5936843C9D for ; Fri, 15 Dec 2006 18:23:09 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id kBFIOhPc098053; Fri, 15 Dec 2006 19:24:44 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id kBFIOhmA015369; Fri, 15 Dec 2006 19:24:43 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id kBFIOh1Q015368; Fri, 15 Dec 2006 19:24:43 +0100 (CET) (envelope-from wb) Date: Fri, 15 Dec 2006 19:24:43 +0100 From: Wilko Bulte To: Milan Obuch Message-ID: <20061215182443.GA15287@freebie.xs4all.nl> References: <200612151834.57201.freebsd-current@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612151834.57201.freebsd-current@dino.sk> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: Re: kern/58953 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 18:24:54 -0000 On Fri, Dec 15, 2006 at 06:34:56PM +0100, Milan Obuch wrote.. > Could someone look at this PR and commit? > It is a minor modification, tested in production for couple of years. Without > this patch, six-port NetMos cards are recognised as four port only. > Regards, > Milan Given that -current now has: { 0x9710, 0x9845, 0x1000, 0x0006, "NetMos NM9845 6 Port UART", DEFAULT_RCLK, PUC_PORT_6S, 0x10, 4, 0, }, are you sure the problem is still there? -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 18:43:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DDEA16A5DE for ; Fri, 15 Dec 2006 18:43:31 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EBCA43C9F for ; Fri, 15 Dec 2006 18:41:44 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so296160ana for ; Fri, 15 Dec 2006 10:43:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=s4wF1ZyBKIZ5fPaJdM0+y+SRSWE8H7UM1PqmwAsvs0kPWCu5+VDRKNf6uqNieAaCuZJWwKPYDctPg1D/hxeRG64ZxXisBARW7WVkL6hhU3AcxRQZUQ4XFveY9cfa6XHl/9okEhyGMvotD+AeIKsvJejqclrSoPfVXGTFAQTDxpI= Received: by 10.100.131.6 with SMTP id e6mr851588and.1166208206824; Fri, 15 Dec 2006 10:43:26 -0800 (PST) Received: by 10.100.136.16 with HTTP; Fri, 15 Dec 2006 10:43:26 -0800 (PST) Message-ID: <6eb82e0612151043p46485043r6a14b93522e60487@mail.gmail.com> Date: Sat, 16 Dec 2006 02:43:26 +0800 From: "Rong-en Fan" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: kib@freebsd.org Subject: vfs_hash_get panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 18:43:31 -0000 I'm running amd64 SMP -current around Dec 14. It seems that I can reproduce this panic by 'mergemaster -iU' at /usr/src reliably. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x68 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff802e0ce3 stack pointer = 0x10:0xffffffffa0019510 frame pointer = 0x10:0xffffffffa0019570 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 786 (mtree) Due to no remote console attached, the console ddb backtrace is available at flickr: http://flickr.com/photos/rafan/323030710/ I put my kernel conf and kgdb output here: http://www.rafan.org/FreeBSD/panic/vfs_hash_get/KERNEL http://www.rafan.org/FreeBSD/panic/vfs_hash_get/kgdb.txt I saw there is another report on @hackers this Oct. But it seems the originator solves the problem by upgrading to latest RELENG_6. Any suggestions? I can provide more information if someone interested. Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 18:49:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DB3616A4CA; Fri, 15 Dec 2006 18:49:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A467E43D70; Fri, 15 Dec 2006 18:46:58 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFImeb2089570; Fri, 15 Dec 2006 13:48:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFImeBD090894; Fri, 15 Dec 2006 13:48:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4F07873034; Fri, 15 Dec 2006 13:48:40 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215184840.4F07873034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 13:48:40 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Fri, 15 Dec 2006 18:49:59 -0000 TB --- 2006-12-15 18:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 18:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-15 18:20:00 - cleaning the object tree TB --- 2006-12-15 18:20:17 - checking out the source tree TB --- 2006-12-15 18:20:17 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-15 18:20:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 18:29:35 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 18:29:35 - cd /src TB --- 2006-12-15 18:29:35 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 18:29:36 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 18:48:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 18:48:39 - ERROR: failed to build world TB --- 2006-12-15 18:48:39 - tinderbox aborted TB --- 0.20 user 0.70 system 1719.12 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 18:53:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B93DE16A540 for ; Fri, 15 Dec 2006 18:53:48 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED2E743CC1 for ; Fri, 15 Dec 2006 18:51:53 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so463963wra for ; Fri, 15 Dec 2006 10:53:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=diGSuLKcV52wEDsaz5PsXK4Nw6MTCWyhWev/hG87sAqWlKOs5O3n+bM4jnn3cXOIpUbRPO8oR8dQdBkwS6qOkDdCbyAYfxH/NeyhNjKHeFtvOj3XtXkJiZ4cZChFIp2b6SN7Oc/k1d/3IVHjkdfdtZbvi26TYboUYKtQxewwCnk= Received: by 10.78.138.6 with SMTP id l6mr366428hud.1166208790048; Fri, 15 Dec 2006 10:53:10 -0800 (PST) Received: by 10.78.198.13 with HTTP; Fri, 15 Dec 2006 10:53:09 -0800 (PST) Message-ID: <7579f7fb0612151053u6a046f34pd595a19e3db148fe@mail.gmail.com> Date: Fri, 15 Dec 2006 10:53:09 -0800 From: "Matthew Jacob" To: "Milan Obuch" In-Reply-To: <200612151834.57201.freebsd-current@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200612151834.57201.freebsd-current@dino.sk> Cc: FreeBSD Current Subject: Re: kern/58953 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 18:53:48 -0000 I took it over to look at it and probably commit it if marcel doesn't say no- thanks On 12/15/06, Milan Obuch wrote: > Could someone look at this PR and commit? > It is a minor modification, tested in production for couple of years. Without > this patch, six-port NetMos cards are recognised as four port only. > Regards, > Milan > > -- > This address is used only for mailing list response. > Do not send any personal messages to it, use milan in > address instead. > _______________________________________________ > 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 Fri Dec 15 18:55:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EF1C16A529 for ; Fri, 15 Dec 2006 18:55:49 +0000 (UTC) (envelope-from bsd@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C0843D8A for ; Fri, 15 Dec 2006 18:53:55 +0000 (GMT) (envelope-from bsd@dino.sk) Received: from [192.168.16.241] (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by bsd.dino.sk with esmtp; Fri, 15 Dec 2006 19:58:09 +0100 id 00000036.4582F041.000016EE From: Milan Obuch To: freebsd-current@freebsd.org Date: Fri, 15 Dec 2006 19:55:18 +0100 User-Agent: KMail/1.9.4 References: <200612151834.57201.freebsd-current@dino.sk> <4582E70B.4000508@delphij.net> In-Reply-To: <4582E70B.4000508@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612151955.18731.bsd@dino.sk> X-Mailman-Approved-At: Fri, 15 Dec 2006 18:58:42 +0000 Subject: Re: kern/58953 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 18:55:49 -0000 On Friday 15 December 2006 19:18, LI Xin wrote: > Milan Obuch wrote: > > Could someone look at this PR and commit? > > It is a minor modification, tested in production for couple of years. > > Without this patch, six-port NetMos cards are recognised as four port > > only. Regards, > > It looks like that 7.0-CURRENT would support it? I mean, the patch is > only necessary for RELENG_6, and not -HEAD? > > Cheers, I will test it later, and report. Probably you are right. I need hardware to test it, can't test it at home now. Regards, Milan From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 19:14:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 372AF16A57E for ; Fri, 15 Dec 2006 19:14:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 1AE4B43DD4 for ; Fri, 15 Dec 2006 19:07:37 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 7363 invoked by uid 399); 15 Dec 2006 19:09:20 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 15 Dec 2006 19:09:20 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4582F2DE.8080806@FreeBSD.org> Date: Fri, 15 Dec 2006 11:09:18 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061125) MIME-Version: 1.0 To: "Bruce A. Mah" References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> <458048DB.2020002@FreeBSD.org> <4582D0B0.40108@freebsd.org> In-Reply-To: <4582D0B0.40108@freebsd.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, freebsd-current@freebsd.org, re@freebsd.org Subject: Re: Socket problems with latest -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: Fri, 15 Dec 2006 19:14:42 -0000 Bruce A. Mah wrote: > If memory serves me right, Doug Barton wrote: >> gnn@freebsd.org wrote: >>> At Mon, 11 Dec 2006 01:35:17 -0800, >>> Doug Barton wrote: >>>> Doug Barton wrote: >>>>> With sources cvsup'ed around 20:35 PST on 8 December everything works >>>>> just fine. With sources cvsup'ed early this morning, 12:42 am PST on >>>>> 10 December, I'm getting a lot of errors related to sockets: >>>> I found the problem, it's the change made in version 1.4 of >>>> rc.d/auto_linklocal. Reverting only that change, and using otherwise >>>> up to date -current sources allows things to work just fine. Adding >>>> that change on the same exact system causes the breakage I described >>>> in my previous message. >>>> >>>> It's probably worth mentioning that I exactly fit the criteria from >>>> the 1.4 commit message, I have INET6 in my kernel, but at the moment I >>>> have ipv6_enable=no in rc.conf. >>>> >>>> This change should be backed out of HEAD and RELENG_6[_2] until the >>>> cause of this breakage is understood. >>> I'll take a quick look at this too. >> Thanks. I installed a totally generic RELENG_6 system from scratch >> yesterday, and confirmed that the problem I had in -current exists in >> -stable too. This is a serious issue, given that the default >> installation will have INET6 in the kernel, but ipv6_enable=no in >> /etc/defaults/rc.conf. >> >> It would be preferable of course to fix the actual problem, but >> between "it works" and "it is fully RFC compliant," I have to pick the >> former. > > Hey Doug-- > > I'm trying to reproduce this problem but without success. I did an > install of 6.2-RC1/i386 from CD into a Parallels VM, then manually > updated /etc/rc.d/auto_linklocal to version 1.1.2.3.2.1 (same as 1.4 you > tested with). I'm not sure if they're relevant or not, but the differences between what you did and what I did are: 1. I installed on a real box 2. I installed 6.1-RELEASE from CD, then cvsup'ed to RELENG_6. One other possible difference, I'm on a Core 2 Duo, running i386 SMP. You might also try enabling named for your testing. The default configuration should give you a simple local resolver which you can then test things like 'dig @127.0.0.1 www.yahoo.com' hth, Doug > I'm running a GENERIC kernel with ipv6_enable="NO" set in > /etc/rc.conf. I set sshd_enable="YES" and sendmail_enable="YES" and > they both seem to be behaving normally. > > vm2# ifconfig > ed0: flags=8843 mtu 1500 > inet WW.XX.YY.ZZ netmask 0xffffff00 broadcast WW.XX.YY.255 > ether 00:5d:54:14:12:1a > media: Ethernet autoselect (10baseT/UTP) > lo0: flags=8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > > I also remember lightly testing this change before it was committed, so > I'm kind of puzzled by the problems you saw. > > Do you have any other information that you think might be useful? > > Thanks! > > Bruce. > -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 20:02:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C19D416A603 for ; Fri, 15 Dec 2006 20:02:18 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF99B43C9D for ; Fri, 15 Dec 2006 20:00:34 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so301704ana for ; Fri, 15 Dec 2006 12:02:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BJgxEYxX0j0/SBJABJvvBiWVYPLoCFikPC7zXmyKfDn9siXwJldFNo6Q9evR8cU6x2gR2XQYGCQ8u2+wpmJzDCXoDh6pZjsqAn7RH6gVl1rw10712ghIjc6Vr9EWBQb7ArQGxLnKCE3QUK7/47n7P7O0BSExfu5GkFQJx3+EeEc= Received: by 10.100.106.5 with SMTP id e5mr941332anc.1166212936743; Fri, 15 Dec 2006 12:02:16 -0800 (PST) Received: by 10.100.136.16 with HTTP; Fri, 15 Dec 2006 12:02:16 -0800 (PST) Message-ID: <6eb82e0612151202m6d283e33h530c91fe0662559a@mail.gmail.com> Date: Sat, 16 Dec 2006 04:02:16 +0800 From: "Rong-en Fan" To: "FreeBSD Current" In-Reply-To: <6eb82e0612151043p46485043r6a14b93522e60487@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612151043p46485043r6a14b93522e60487@mail.gmail.com> Cc: kib@freebsd.org Subject: Re: vfs_hash_get panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 20:02:18 -0000 On 12/16/06, Rong-en Fan wrote: > I'm running amd64 SMP -current around Dec 14. It seems that I can reproduce > this panic by 'mergemaster -iU' at /usr/src reliably. I did nothing but mergemater may not 100% reproduce this. However, it seems that buildworld causes panic at different point each time. I always do 'fsck -fy' each time after panic. Now the host is in ddb again. > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x68 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff802e0ce3 > stack pointer = 0x10:0xffffffffa0019510 > frame pointer = 0x10:0xffffffffa0019570 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 786 (mtree) > > Due to no remote console attached, the console ddb backtrace > is available at flickr: > > http://flickr.com/photos/rafan/323030710/ > > I put my kernel conf and kgdb output here: > > http://www.rafan.org/FreeBSD/panic/vfs_hash_get/KERNEL > http://www.rafan.org/FreeBSD/panic/vfs_hash_get/kgdb.txt > > I saw there is another report on @hackers this Oct. But it seems > the originator solves the problem by upgrading to latest RELENG_6. > > Any suggestions? I can provide more information if someone interested. > > Regards, > Rong-En Fan > From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 20:14:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2C0816A417; Fri, 15 Dec 2006 20:14:39 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93D7443CAF; Fri, 15 Dec 2006 20:12:31 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBFKEEpP008499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2006 12:14:14 -0800 Message-ID: <45830215.9020607@freebsd.org> Date: Fri, 15 Dec 2006 12:14:13 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Doug Barton References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> <458048DB.2020002@FreeBSD.org> <4582D0B0.40108@freebsd.org> <4582F2DE.8080806@FreeBSD.org> In-Reply-To: <4582F2DE.8080806@FreeBSD.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCEB177AAF08B7A52933FFC71" Cc: gnn@freebsd.org, freebsd-current@freebsd.org, re@freebsd.org Subject: Re: Socket problems with latest -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: Fri, 15 Dec 2006 20:14:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEB177AAF08B7A52933FFC71 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Doug Barton wrote: > Bruce A. Mah wrote: >> I'm trying to reproduce this problem but without success. I did an >> install of 6.2-RC1/i386 from CD into a Parallels VM, then manually >> updated /etc/rc.d/auto_linklocal to version 1.1.2.3.2.1 (same as 1.4 y= ou >> tested with).=20 >=20 > I'm not sure if they're relevant or not, but the differences between > what you did and what I did are: >=20 > 1. I installed on a real box > 2. I installed 6.1-RELEASE from CD, then cvsup'ed to RELENG_6. >=20 > One other possible difference, I'm on a Core 2 Duo, running i386 SMP. >=20 > You might also try enabling named for your testing. The default > configuration should give you a simple local resolver which you can > then test things like 'dig @127.0.0.1 www.yahoo.com' Thanks for the info. BIND seems to work OK in this environment too. (What was the failure mode for you?) Part of me is hoping that there's something odd in your environment, especially because I haven't heard any other similar reports of problems so far on current@, stable@, or net@. I figure if sendmail or named can't bind sockets there'd be a pretty loud outcry from a lot of people. BTW, I started looking at this because re@ needs to decide what to do here for 6.2. If a default (or even "normal") configuration is possible to produce the problems you saw, we obviously can't ship this way. Would it be too much to ask for a (possibly slightly sanitized) /etc/rc.conf and kernel configuration file from the machine in question? (Privately obviously.) Oh yeah. Is it possible that the machine has a hostname that only has a AAAA record (no A record) in DNS or some other thing like this? I don't expect that you'd do something so "interesting" but I had to ask. Thanks! Bruce. PS. I'm in the process of updating a physical machine to the tip of RELENG_6 but this takes awhile (it's a UP 1GHz P-III and believe it or not the fastest FreeBSD machine I own). --------------enigCEB177AAF08B7A52933FFC71 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgwIV2MoxcVugUsMRArQzAKDIouYycGunJHFiNkYzRr5jRVnH4gCgorGq ve/EA+U1iSeTRBGNCNrIgSI= =s/6e -----END PGP SIGNATURE----- --------------enigCEB177AAF08B7A52933FFC71-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 20:14:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBE4216A52F for ; Fri, 15 Dec 2006 20:14:59 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3978E43C9E for ; Fri, 15 Dec 2006 20:13:16 +0000 (GMT) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout07/MantshX 4.0) with ESMTP id kBFKEfnR017883; Fri, 15 Dec 2006 12:14:41 -0800 (PST) Received: from [172.24.92.147] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id kBFKEYAw020169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Dec 2006 12:14:39 -0800 (PST) In-Reply-To: <4582E70B.4000508@delphij.net> References: <200612151834.57201.freebsd-current@dino.sk> <4582E70B.4000508@delphij.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AD293F1-9794-437D-8202-DBE964F7654C@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 15 Dec 2006 12:13:56 -0800 To: LI Xin X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-current@freebsd.org, Milan Obuch Subject: Re: kern/58953 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 20:14:59 -0000 On Dec 15, 2006, at 10:18 AM, LI Xin wrote: > Milan Obuch wrote: >> Could someone look at this PR and commit? >> It is a minor modification, tested in production for couple of >> years. Without >> this patch, six-port NetMos cards are recognised as four port only. >> Regards, > > It looks like that 7.0-CURRENT would support it? I mean, the patch is > only necessary for RELENG_6, and not -HEAD? Yes, -CURRENT already detects the 6-port correctly. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 20:43:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48C6216A415 for ; Fri, 15 Dec 2006 20:43:03 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (trang.nuxi.org [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D5D443C9E for ; Fri, 15 Dec 2006 20:41:19 +0000 (GMT) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.8/8.13.8) with ESMTP id kBFKh2J2055419; Fri, 15 Dec 2006 12:43:02 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.8/8.13.7/Submit) id kBFKh1mJ055418; Fri, 15 Dec 2006 12:43:01 -0800 (PST) (envelope-from obrien) Date: Fri, 15 Dec 2006 12:43:01 -0800 From: "David O'Brien" To: Steve Kargl Message-ID: <20061215204301.GA55276@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Steve Kargl References: <20061213192150.CF83D16A417@hub.freebsd.org> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <200612151450.39260.doconnor@gsoft.com.au> <20061215044453.GB9381@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061215044453.GB9381@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Fri, 15 Dec 2006 20:43:03 -0000 On Thu, Dec 14, 2006 at 08:44:53PM -0800, Steve Kargl wrote: > On Fri, Dec 15, 2006 at 02:50:30PM +1030, Daniel O'Connor wrote: > > On Friday 15 December 2006 05:50, Scott Long wrote: > > > Yes, the industry moves fast, but that's no reason to fool ourselves > > > into thinking that the FSF will support GCC 4.2 a day after they release > > > 4.3 and start working on 4.4. Your point above about the lifespan of > > > FreeBSD 7.x is a valid one, and I agree that it should be a > > > consideration. Vendor support is a myth and should not be a > > > consideration. > > > > Not to mention it is *trivial* to install a compiler using ports or packages. > > > > If you are serious about high performance computing installing a new compiler > > is about the lowest barrier you'll find. > > > > Actually, 4.1.x will produce much worse code than 3.4.6. > You can search the gcc mail listings for extensive comparison > by Clinton Whaley (the author of math/atlas) for details. It depends on the type of code and benchmark. Clinton's code is mostly FP. I've seen other benchmarks that show an improvment with 4.1.x over 3.4.6 and 4.2 does even better. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 20:52:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 166D216A403 for ; Fri, 15 Dec 2006 20:52:07 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (trang.nuxi.org [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 366F343CC2 for ; Fri, 15 Dec 2006 20:49:56 +0000 (GMT) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.8/8.13.8) with ESMTP id kBFKpdC0055572; Fri, 15 Dec 2006 12:51:39 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.8/8.13.7/Submit) id kBFKpcGA055571; Fri, 15 Dec 2006 12:51:38 -0800 (PST) (envelope-from obrien) Date: Fri, 15 Dec 2006 12:51:38 -0800 From: "David O'Brien" To: Stefan Ehmann Message-ID: <20061215205138.GB55276@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Stefan Ehmann , freebsd-current@freebsd.org, Peter Jeremy , Steve Kargl References: <20061213192150.CF83D16A417@hub.freebsd.org> <458235EC.80300@samsco.org> <200612151250.10033.shoesoft@gmx.net> <200612151914.53705.shoesoft@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612151914.53705.shoesoft@gmx.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: Peter Jeremy , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 15 Dec 2006 20:52:07 -0000 On Fri, Dec 15, 2006 at 07:14:53PM +0100, Stefan Ehmann wrote: > > CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU) .. > Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 > ----------------------------+---------+---------+--------- > -O2 | 6.46s | 6.67s | 6.38s > -O2 -funroll-loops | 4.44s | 4.16s | 4.02s > -O2 -march=athlon-xp -fun.. | 4.39s | 4.38s | 4.26s > -O3 | 6.14s | 5.23s | 5.16s > -O3 -funroll-loops | 4.24s | 4.87s | 4.95s > -O3 -march=athlon-xp -fun.. | 4.19s | 4.90s | 5.07s A fine example that -O3 isn't always better than -O2. I wonder if you're blowing the L2 cache. IIRC, all Athlon XP 2700+ are the Thoughbread core, which has only 256KB L2. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 21:01:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D543816A509; Fri, 15 Dec 2006 21:01:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F71743CA3; Fri, 15 Dec 2006 20:59:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFL1PUg022518; Fri, 15 Dec 2006 16:01:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFL1PCZ019881; Fri, 15 Dec 2006 16:01:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8338473034; Fri, 15 Dec 2006 16:01:25 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215210125.8338473034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 16:01:25 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 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: Fri, 15 Dec 2006 21:01:48 -0000 TB --- 2006-12-15 20:31:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 20:31:32 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-15 20:31:32 - cleaning the object tree TB --- 2006-12-15 20:31:39 - checking out the source tree TB --- 2006-12-15 20:31:39 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-15 20:31:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 20:38:52 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 20:38:52 - cd /src TB --- 2006-12-15 20:38:52 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 20:38:53 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 21:01:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 21:01:24 - ERROR: failed to build world TB --- 2006-12-15 21:01:24 - tinderbox aborted TB --- 0.24 user 0.62 system 1792.60 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 21:27:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E074216A403 for ; Fri, 15 Dec 2006 21:27:39 +0000 (UTC) (envelope-from rmgls@orange.fr) Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D35F843CB8 for ; Fri, 15 Dec 2006 21:25:55 +0000 (GMT) (envelope-from rmgls@orange.fr) Received: from orange.fr (ARouen-156-1-15-118.w86-221.abo.wanadoo.fr [86.221.230.118]) by mwinf1914.orange.fr (SMTP Server) with ESMTP id 3C2D81C00092 for ; Fri, 15 Dec 2006 22:27:38 +0100 (CET) X-ME-UUID: 20061215212738246.3C2D81C00092@mwinf1914.orange.fr To: freebsd-current@freebsd.org From: rmgls@wanadoo.fr Date: Fri, 15 Dec 2006 22:27:31 +0100 Sender: rmgls@orange.fr Message-Id: <20061215212738.3C2D81C00092@mwinf1914.orange.fr> Subject: two uarts pccard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 21:27:40 -0000 Hi all, I have a pccard with two serial ports, which is not activated properly. the card is recognized as generic by debian. the machine s an s5 vaio. Here is the related content of dmesg on current from 3-12-2007. cbb0: card inserted: event=0x00000006, state=30000910 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 3V pccard0: read_cis pcib2: pccard0 requested memory range 0xb0000000-0xb00fffff: good cis mem map 0xe694e000 (resource: 0xb0010000) pccard0: CIS tuple chain: CISTPL_DEVICE type=null speed=null 01 02 00 ff unhandled CISTPL 3 03 00 CISTPL_END ff cis mem map e694e000 CISTPL_LINKTARGET expected, code ff observed pccard0: check_cis_quirks pccard0: Card has no functions! cbb0: PC Card card activation failed Can you help me to solve this problem please? Tahnks a lot. Raoul rmgls@wanadoo.fr From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 21:28:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2953E16A415; Fri, 15 Dec 2006 21:28:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23F0543C9E; Fri, 15 Dec 2006 21:26:20 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFLS3Z6028909; Fri, 15 Dec 2006 16:28:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFLS2TI055601; Fri, 15 Dec 2006 16:28:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B776473034; Fri, 15 Dec 2006 16:28:02 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215212802.B776473034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 16:28:02 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner2 X-Virus-Status: Clean 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: Fri, 15 Dec 2006 21:28:04 -0000 TB --- 2006-12-15 21:01:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 21:01:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-15 21:01:25 - cleaning the object tree TB --- 2006-12-15 21:01:34 - checking out the source tree TB --- 2006-12-15 21:01:34 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-15 21:01:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 21:10:32 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 21:10:32 - cd /src TB --- 2006-12-15 21:10:32 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 21:10:33 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 21:28:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 21:28:02 - ERROR: failed to build world TB --- 2006-12-15 21:28:02 - tinderbox aborted TB --- 0.20 user 0.62 system 1596.88 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 21:54:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C3C516A40F; Fri, 15 Dec 2006 21:54:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA6243CC4; Fri, 15 Dec 2006 21:52:19 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFLs2OE032340; Fri, 15 Dec 2006 16:54:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFLs2SI078664; Fri, 15 Dec 2006 16:54:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E78E573034; Fri, 15 Dec 2006 16:54:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215215401.E78E573034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 16:54:01 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner3 X-Virus-Status: Clean 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: Fri, 15 Dec 2006 21:54:13 -0000 TB --- 2006-12-15 21:28:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 21:28:02 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-15 21:28:02 - cleaning the object tree TB --- 2006-12-15 21:28:13 - checking out the source tree TB --- 2006-12-15 21:28:13 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-15 21:28:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 21:36:11 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 21:36:11 - cd /src TB --- 2006-12-15 21:36:11 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 21:36:13 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 21:54:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 21:54:01 - ERROR: failed to build world TB --- 2006-12-15 21:54:01 - tinderbox aborted TB --- 0.28 user 0.62 system 1558.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 22:16:22 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 658A116A412 for ; Fri, 15 Dec 2006 22:16:22 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-1.orange.nl (smtp-1.orange.nl [193.252.22.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26CF543C9E for ; Fri, 15 Dec 2006 22:14:37 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6003.orange.nl (SMTP Server) with ESMTP id 99FF9240008C for ; Fri, 15 Dec 2006 23:16:19 +0100 (CET) X-ME-UUID: 20061215221619630.99FF9240008C@mwinf6003.orange.nl Received: (qmail 77821 invoked from network); 15 Dec 2006 22:16:19 -0000 Received: from 10.66.0.143 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:1(10.66.0.143):. Processed in 0.375819 secs); 15 Dec 2006 22:16:19 -0000 X-Qmail-Scanner-Mail-From: nick@van-laarhoven.org via uitsmijter.van-laarhoven.org X-Qmail-Scanner: 1.25 (Clear:RC:1(10.66.0.143):. Processed in 0.375819 secs) Received: from unknown (HELO van-laarhoven.org) (nick@10.66.0.143) by uitsmijter.van-laarhoven.org with SMTP; 15 Dec 2006 22:16:18 -0000 Received: (nullmailer pid 5773 invoked by uid 1001); Fri, 15 Dec 2006 22:16:18 -0000 Date: Fri, 15 Dec 2006 23:16:18 +0100 (CET) From: Nick Hibma X-X-Sender: nick@localhost To: FreeBSD CURRENT Mailing List Message-ID: <20061215230404.E1244@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: WD_PASSIVE kernel based tickling of the watchdog - request for ideas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Dec 2006 22:16:22 -0000 I've got two requests for a clue ... er... ideas today on how to implement the WD_PASSIVE flag in the watchdog(9) interface: - How would I best implement the tickling of the watchdog at specified intervals (e.g. 1/2 the watchdog timeout value)? By using a - timeout - kernel thread sleeping most of the time - hardclock() considering the trade-off between large variance in frequency vs. making sure we notice a (permanent) freeze in the kernel somewhere. For example burning a CD sometimes makes my laptop freeze for a short period. Will the watchdog fire in that case? - What do we consider a 'bad' situation in which the watchdog should not be tickled? What kind of checks would we need to perform? I'd be interested to hear your thoughts. Nick P.S.: I'm personally not interested in passive tickling of the watchdog, so if there is no response, I'll leave the implementation as is (return EOPNOTSUPP at the moment). From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 22:58:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A213916A416; Fri, 15 Dec 2006 22:58:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F88D43CB6; Fri, 15 Dec 2006 22:57:00 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFMwiUH038524; Fri, 15 Dec 2006 17:58:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBFMwivA020189; Fri, 15 Dec 2006 17:58:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1C32973034; Fri, 15 Dec 2006 17:58:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061215225844.1C32973034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 17:58:44 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Fri, 15 Dec 2006 22:58:46 -0000 TB --- 2006-12-15 22:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-15 22:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-15 22:30:00 - cleaning the object tree TB --- 2006-12-15 22:30:15 - checking out the source tree TB --- 2006-12-15 22:30:15 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-15 22:30:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-15 22:39:33 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-15 22:39:33 - cd /src TB --- 2006-12-15 22:39:33 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 15 22:39:34 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-15 22:58:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-15 22:58:43 - ERROR: failed to build world TB --- 2006-12-15 22:58:43 - tinderbox aborted TB --- 0.25 user 0.63 system 1723.63 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 15 23:03:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16AA916A415; Fri, 15 Dec 2006 23:03:36 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34DEB43CA8; Fri, 15 Dec 2006 23:01:51 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBFN3Y6d019315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2006 15:03:34 -0800 Message-ID: <458329C5.1060409@freebsd.org> Date: Fri, 15 Dec 2006 15:03:33 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Doug Barton References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> <458048DB.2020002@FreeBSD.org> <4582D0B0.40108@freebsd.org> <4582F2DE.8080806@FreeBSD.org> <45830215.9020607@freebsd.org> In-Reply-To: <45830215.9020607@freebsd.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6F7901486EAB2CED925EF797" Cc: gnn@freebsd.org, freebsd-current@freebsd.org, re@freebsd.org Subject: Re: Socket problems with latest -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: Fri, 15 Dec 2006 23:03:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F7901486EAB2CED925EF797 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I wrote: > PS. I'm in the process of updating a physical machine to the tip of > RELENG_6 but this takes awhile (it's a UP 1GHz P-III and believe it or > not the fastest FreeBSD machine I own). Update: This finally finished (the machine in question is my secondary desktop system). After commenting out ipv6_enable=3D"YES" in my /etc/rc.conf, everything's working. Specifically, a named instance answers queries as expected, sshd binds listening sockets and accepts connections (IPv4 only of course), and sendmail comes up without any unexpected log messages. ifconfig(8) shows the expected addresses on the various interfaces (IPv4-only on everything except lo0). If anyone out there is having problems similar to what Doug originally described, now would be a great time to speak up. (Recent HEAD, RELENG_6, or RELENG_6_2, with INET6 enabled in the kernel but ipv6_enable *not* enabled in /etc/rc.conf, seeing problems with programs failing to bind listening sockets.) Thanks, Bruce. --------------enig6F7901486EAB2CED925EF797 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgynF2MoxcVugUsMRApXOAJ4zafNoV3Nb3KRh/y82csdNZZDJ9QCgiFkU 100uUOGomugU1jD5I0PQus4= =MAHC -----END PGP SIGNATURE----- --------------enig6F7901486EAB2CED925EF797-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 01:10:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E04A216A403; Sat, 16 Dec 2006 01:10:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF01F43C9D; Sat, 16 Dec 2006 01:08:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBG1ACf5023468; Fri, 15 Dec 2006 20:10:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG1AChP004720; Fri, 15 Dec 2006 20:10:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 296D373034; Fri, 15 Dec 2006 20:10:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216011012.296D373034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 20:10:11 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 01:10:14 -0000 TB --- 2006-12-16 00:40:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 00:40:23 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-16 00:40:23 - cleaning the object tree TB --- 2006-12-16 00:40:30 - checking out the source tree TB --- 2006-12-16 00:40:30 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-16 00:40:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 00:47:56 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 00:47:56 - cd /src TB --- 2006-12-16 00:47:56 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 00:47:57 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 01:10:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 01:10:11 - ERROR: failed to build world TB --- 2006-12-16 01:10:11 - tinderbox aborted TB --- 0.20 user 0.64 system 1787.76 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 01:37:54 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 136E916A412; Sat, 16 Dec 2006 01:37:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFCAE43C9D; Sat, 16 Dec 2006 01:36:08 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG1boPp050383; Fri, 15 Dec 2006 20:37:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG1bo7e008045; Fri, 15 Dec 2006 20:37:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 98F3073034; Fri, 15 Dec 2006 20:37:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216013750.98F3073034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 20:37:50 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean 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: Sat, 16 Dec 2006 01:37:54 -0000 TB --- 2006-12-16 01:10:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 01:10:12 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-16 01:10:12 - cleaning the object tree TB --- 2006-12-16 01:10:24 - checking out the source tree TB --- 2006-12-16 01:10:24 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-16 01:10:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 01:20:20 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 01:20:20 - cd /src TB --- 2006-12-16 01:20:20 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 01:20:21 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 01:37:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 01:37:50 - ERROR: failed to build world TB --- 2006-12-16 01:37:50 - tinderbox aborted TB --- 0.20 user 0.63 system 1658.30 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 02:00:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7C1616A4AB for ; Sat, 16 Dec 2006 02:00:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 0AC8F43CA2 for ; Sat, 16 Dec 2006 01:59:02 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 30360 invoked by uid 399); 16 Dec 2006 02:00:45 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Dec 2006 02:00:45 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4583534A.7010909@FreeBSD.org> Date: Fri, 15 Dec 2006 18:00:42 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061125) MIME-Version: 1.0 To: "Bruce A. Mah" References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> <458048DB.2020002@FreeBSD.org> <4582D0B0.40108@freebsd.org> <4582F2DE.8080806@FreeBSD.org> <45830215.9020607@freebsd.org> In-Reply-To: <45830215.9020607@freebsd.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, freebsd-current@freebsd.org, re@freebsd.org Subject: Re: Socket problems with latest -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: Sat, 16 Dec 2006 02:00:49 -0000 Bruce A. Mah wrote: > BTW, I started looking at this because re@ needs to decide what to do > here for 6.2. If a default (or even "normal") configuration is possible > to produce the problems you saw, we obviously can't ship this way. Good news for you, I found the problem. Bad news for me, I'm apparently an idiot. Well, not quite an idiot, but I have a local script to set up the wired interface if it's connected, and the wireless if it's not. Somewhere in there I forgot about configuring lo0, but it was magically being done for me. With the change that hrs made to rc.d/auto_linklocal, the magic stopped happening, and in focusing on the new fe80::1 address I missed the fact that the IPv4 address wasn't there. Why the change caused lo0 to stop being configured for IPv4 is a new mystery, but that one is more in my area. Sorry about the false alarm. > Oh yeah. Is it possible that the machine has a hostname that only has a > AAAA record (no A record) in DNS or some other thing like this? I don't > expect that you'd do something so "interesting" but I had to ask. Interesting that you asked that question, it's definitely the right track, and it's what made me go back and look harder at what I was doing behind the scenes. Thanks! Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 02:04:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B23116A49E; Sat, 16 Dec 2006 02:04:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8BA643CA0; Sat, 16 Dec 2006 02:02:22 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG247gm051765; Fri, 15 Dec 2006 21:04:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG246Ss035279; Fri, 15 Dec 2006 21:04:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BBD8073034; Fri, 15 Dec 2006 21:04:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216020406.BBD8073034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 21:04:06 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean 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: Sat, 16 Dec 2006 02:04:08 -0000 TB --- 2006-12-16 01:37:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 01:37:50 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-16 01:37:50 - cleaning the object tree TB --- 2006-12-16 01:37:59 - checking out the source tree TB --- 2006-12-16 01:37:59 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-16 01:37:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 01:46:18 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 01:46:18 - cd /src TB --- 2006-12-16 01:46:18 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 01:46:19 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 02:04:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 02:04:06 - ERROR: failed to build world TB --- 2006-12-16 02:04:06 - tinderbox aborted TB --- 0.22 user 0.63 system 1575.84 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 03:08:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACC7916A403; Sat, 16 Dec 2006 03:08:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F58E43C9D; Sat, 16 Dec 2006 03:07:05 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBG38obb026962; Fri, 15 Dec 2006 22:08:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG38obq025465; Fri, 15 Dec 2006 22:08:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EBF2B73034; Fri, 15 Dec 2006 22:08:49 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216030849.EBF2B73034@freebsd-current.sentex.ca> Date: Fri, 15 Dec 2006 22:08:49 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 03:08:51 -0000 TB --- 2006-12-16 02:40:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 02:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-16 02:40:01 - cleaning the object tree TB --- 2006-12-16 02:40:18 - checking out the source tree TB --- 2006-12-16 02:40:18 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-16 02:40:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 02:49:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 02:49:53 - cd /src TB --- 2006-12-16 02:49:53 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 02:49:54 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 03:08:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 03:08:49 - ERROR: failed to build world TB --- 2006-12-16 03:08:49 - tinderbox aborted TB --- 0.19 user 0.69 system 1728.45 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 05:21:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F33516A40F; Sat, 16 Dec 2006 05:21:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9402543C9D; Sat, 16 Dec 2006 05:19:34 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG5LJdg063828; Sat, 16 Dec 2006 00:21:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG5LJR1044053; Sat, 16 Dec 2006 00:21:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 26F0B73034; Sat, 16 Dec 2006 00:21:19 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216052119.26F0B73034@freebsd-current.sentex.ca> Date: Sat, 16 Dec 2006 00:21:19 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 05:21:20 -0000 TB --- 2006-12-16 04:51:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 04:51:38 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-16 04:51:38 - cleaning the object tree TB --- 2006-12-16 04:51:46 - checking out the source tree TB --- 2006-12-16 04:51:46 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-16 04:51:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 04:58:57 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 04:58:57 - cd /src TB --- 2006-12-16 04:58:57 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 04:58:58 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 05:21:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 05:21:18 - ERROR: failed to build world TB --- 2006-12-16 05:21:18 - tinderbox aborted TB --- 0.23 user 0.62 system 1780.17 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 05:48:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DDF516A40F; Sat, 16 Dec 2006 05:48:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFDB143C9E; Sat, 16 Dec 2006 05:46:50 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBG5mZik031010; Sat, 16 Dec 2006 00:48:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG5mZZE006468; Sat, 16 Dec 2006 00:48:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0151D73034; Sat, 16 Dec 2006 00:48:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216054835.0151D73034@freebsd-current.sentex.ca> Date: Sat, 16 Dec 2006 00:48:34 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean 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: Sat, 16 Dec 2006 05:48:37 -0000 TB --- 2006-12-16 05:21:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 05:21:19 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-16 05:21:19 - cleaning the object tree TB --- 2006-12-16 05:21:30 - checking out the source tree TB --- 2006-12-16 05:21:30 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-16 05:21:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 05:30:55 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 05:30:55 - cd /src TB --- 2006-12-16 05:30:55 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 05:30:56 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 05:48:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 05:48:34 - ERROR: failed to build world TB --- 2006-12-16 05:48:34 - tinderbox aborted TB --- 0.19 user 0.66 system 1635.36 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 05:59:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D66816A407; Sat, 16 Dec 2006 05:59:07 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA03B43C9D; Sat, 16 Dec 2006 05:57:20 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBG5x5I6004234; Sat, 16 Dec 2006 08:59:05 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBG5x4FN004233; Sat, 16 Dec 2006 08:59:04 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 08:59:03 +0300 From: Andrey Chernov To: current@freebsd.org, umq@ueo.co.jp, dinoex@freebsd.org Message-ID: <20061216055903.GA2712@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, umq@ueo.co.jp, dinoex@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: sysvshm appearse broken in -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: Sat, 16 Dec 2006 05:59:07 -0000 It seems shm is broken in very recent -current. Trying to build dkim-milter or dk-milter port (from root, of course) I got: ./t-shm shmget: Permission denied ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ shminit failed: Permission denied 1..bad! t-shm.c:260 r == 0 add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 and start over. 0 of 1 tests completed successfully *** 1 error in test! *** 2..bad! t-shm.c:177 cnt <= MAX_CNT add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 and start over. 4 of 5 tests completed successfully *** 1 error in test! *** EPERM is very strange error here. I never saw it here before. Yes, I have sysv* stuff loaded: 12 1 0xc2856000 4000 sysvmsg.ko 13 1 0xc285e000 5000 sysvsem.ko 14 1 0xc2865000 4000 sysvshm.ko -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 06:14:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79B7516A47C; Sat, 16 Dec 2006 06:14:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCD0343CA5; Sat, 16 Dec 2006 06:14:20 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG6EKa7066757; Sat, 16 Dec 2006 01:14:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG6EKPt070478; Sat, 16 Dec 2006 01:14:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E93F973034; Sat, 16 Dec 2006 01:14:19 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216061419.E93F973034@freebsd-current.sentex.ca> Date: Sat, 16 Dec 2006 01:14:19 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner2 X-Virus-Status: Clean 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: Sat, 16 Dec 2006 06:14:21 -0000 TB --- 2006-12-16 05:48:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 05:48:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-16 05:48:35 - cleaning the object tree TB --- 2006-12-16 05:48:46 - checking out the source tree TB --- 2006-12-16 05:48:46 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-16 05:48:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 05:56:46 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 05:56:46 - cd /src TB --- 2006-12-16 05:56:46 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 05:56:47 UTC 2006 >>> 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 [...] /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:317: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:363: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getassocid': /src/lib/libc/net/sctp_sys_calls.c:529: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 06:14:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 06:14:19 - ERROR: failed to build world TB --- 2006-12-16 06:14:19 - tinderbox aborted TB --- 0.16 user 0.70 system 1544.46 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 06:44:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEF1616A40F; Sat, 16 Dec 2006 06:44:21 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26BE143CA2; Sat, 16 Dec 2006 06:44:21 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBG6iKCB024857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2006 22:44:21 -0800 Message-ID: <458395BD.9030106@freebsd.org> Date: Fri, 15 Dec 2006 22:44:13 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Doug Barton References: <457C81E9.7040806@FreeBSD.org> <457D2655.9050500@FreeBSD.org> <458048DB.2020002@FreeBSD.org> <4582D0B0.40108@freebsd.org> <4582F2DE.8080806@FreeBSD.org> <45830215.9020607@freebsd.org> <4583534A.7010909@FreeBSD.org> In-Reply-To: <4583534A.7010909@FreeBSD.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAFA01D9F0F01991A8172471D" Cc: gnn@freebsd.org, freebsd-current@freebsd.org, re@freebsd.org Subject: Re: Socket problems with latest -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: Sat, 16 Dec 2006 06:44:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAFA01D9F0F01991A8172471D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Doug Barton wrote: > Bruce A. Mah wrote: >=20 >> BTW, I started looking at this because re@ needs to decide what to do >> here for 6.2. If a default (or even "normal") configuration is possib= le >> to produce the problems you saw, we obviously can't ship this way. >=20 > Good news for you, I found the problem. Bad news for me, I'm > apparently an idiot. Well, not quite an idiot, but I have a local > script to set up the wired interface if it's connected, and the > wireless if it's not. Somewhere in there I forgot about configuring > lo0, but it was magically being done for me. With the change that hrs > made to rc.d/auto_linklocal, the magic stopped happening, and in > focusing on the new fe80::1 address I missed the fact that the IPv4 > address wasn't there. Why the change caused lo0 to stop being > configured for IPv4 is a new mystery, but that one is more in my area. > Sorry about the false alarm. No worries...I'm glad that everything seems to be working! Cheers, Bruce. --------------enigAFA01D9F0F01991A8172471D 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFg5XE2MoxcVugUsMRAohUAKD5KP9b3bML+p+tzQCtz8DOcnhbzACg8TX0 CQMOzjL7NralT4ohdLobeDk= =ttaG -----END PGP SIGNATURE----- --------------enigAFA01D9F0F01991A8172471D-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 09:12:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DE2716A412; Sat, 16 Dec 2006 09:12:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B31243CA0; Sat, 16 Dec 2006 09:12:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG9C8Cd079146; Sat, 16 Dec 2006 04:12:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kBG9C8kP070884; Sat, 16 Dec 2006 04:12:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5EC9773034; Sat, 16 Dec 2006 04:12:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061216091208.5EC9773034@freebsd-current.sentex.ca> Date: Sat, 16 Dec 2006 04:12:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 09:12:12 -0000 TB --- 2006-12-16 07:55:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-16 07:55:17 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-16 07:55:17 - cleaning the object tree TB --- 2006-12-16 07:55:48 - checking out the source tree TB --- 2006-12-16 07:55:48 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-16 07:55:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-16 08:05:17 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-16 08:05:17 - cd /src TB --- 2006-12-16 08:05:17 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 16 08:05:19 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Dec 16 09:02:57 UTC 2006 TB --- 2006-12-16 09:02:57 - generating LINT kernel config TB --- 2006-12-16 09:02:57 - cd /src/sys/i386/conf TB --- 2006-12-16 09:02:57 - /usr/bin/make -B LINT TB --- 2006-12-16 09:02:57 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-16 09:02:57 - cd /src TB --- 2006-12-16 09:02:57 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 16 09:02:57 UTC 2006 >>> 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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/subr_rman.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/subr_sbuf.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/subr_scanf.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 -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/subr_sleepqueue.c /src/sys/kern/subr_sleepqueue.c: In function `sleepq_add': /src/sys/kern/subr_sleepqueue.c:300: error: `NR_SLEEP_QUEUEUS' undeclared (first use in this function) /src/sys/kern/subr_sleepqueue.c:300: error: (Each undeclared identifier is reported only once /src/sys/kern/subr_sleepqueue.c:300: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-16 09:12:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-16 09:12:08 - ERROR: failed to build lint kernel TB --- 2006-12-16 09:12:08 - tinderbox aborted TB --- 0.88 user 2.65 system 4610.37 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 11:16:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19CF516A4A7; Sat, 16 Dec 2006 11:16:59 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 681FA43C9D; Sat, 16 Dec 2006 11:16:58 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGBGvf3007544; Sat, 16 Dec 2006 14:16:57 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGBGuqV007543; Sat, 16 Dec 2006 14:16:56 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 14:16:56 +0300 From: Andrey Chernov To: current@freebsd.org, rwatson@freebsd.org Message-ID: <20061216111656.GA7501@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, rwatson@freebsd.org, umq@ueo.co.jp, dinoex@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216055903.GA2712@nagual.pp.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: dinoex@freebsd.org, umq@ueo.co.jp Subject: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 11:16:59 -0000 The only place where EACCES may come is ipcperm() which was significally touched last time at: revision 1.30 date: 2006/11/06 13:42:01; author: rwatson; state: Exp; lines: +65 -37 Sweep kernel replacing suser(9) calls with priv(9) calls, assigning specific privilege names to a broad range of privileges. These may require some future tweaking. Sponsored by: nCircle Network Security, Inc. Obtained from: TrustedBSD Project Discussed on: arch@ Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, Alex Lyashkov , Skip Ford , Antoine Brodin On Sat, Dec 16, 2006 at 08:59:03AM +0300, Andrey Chernov wrote: > It seems shm is broken in very recent -current. > Trying to build dkim-milter or dk-milter port (from root, of course) I > got: > > ./t-shm > shmget: Permission denied > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > shminit failed: Permission denied > 1..bad! t-shm.c:260 r == 0 > add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 > and start over. > 0 of 1 tests completed successfully > *** 1 error in test! *** > 2..bad! t-shm.c:177 cnt <= MAX_CNT > add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 > and start over. > 4 of 5 tests completed successfully > *** 1 error in test! *** -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 11:25:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B83AB16A407; Sat, 16 Dec 2006 11:25:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B26A43C9E; Sat, 16 Dec 2006 11:25:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2143C46EA9; Sat, 16 Dec 2006 06:25:55 -0500 (EST) Date: Sat, 16 Dec 2006 11:25:55 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061216111656.GA7501@nagual.pp.ru> Message-ID: <20061216112117.P72986@fledge.watson.org> References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dinoex@freebsd.org, umq@ueo.co.jp, current@freebsd.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 11:25:55 -0000 On Sat, 16 Dec 2006, Andrey Chernov wrote: > The only place where EACCES may come is ipcperm() which was significally > touched last time at: > > revision 1.30 > date: 2006/11/06 13:42:01; author: rwatson; state: Exp; lines: +65 -37 > Sweep kernel replacing suser(9) calls with priv(9) calls, assigning > specific privilege names to a broad range of privileges. These may > require some future tweaking. > > Sponsored by: nCircle Network Security, Inc. > Obtained from: TrustedBSD Project > Discussed on: arch@ > Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, > Alex Lyashkov , > Skip Ford , > Antoine Brodin Yes, you can find the details in kern/106078. The thrust of the problem is that applications apparently pass access mode arguments to shmget() in situations other than file creation, which isn't documented in the spec. I've been doing a bit of on-and-off research on this, but need to do some more before I'm ready to change our implementation to simply ignore the argument. I hope to look at it again this week sometime; it's unclear to me what applications are trying to accomplish with the mode field in the non-IPC_CREAT case, and none of the man pages and documentation I've found on various UNIX systems to date suggest anything in particular. Robert N M Watson Computer Laboratory University of Cambridge > > > On Sat, Dec 16, 2006 at 08:59:03AM +0300, Andrey Chernov wrote: >> It seems shm is broken in very recent -current. >> Trying to build dkim-milter or dk-milter port (from root, of course) I >> got: >> >> ./t-shm >> shmget: Permission denied >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> shminit failed: Permission denied >> 1..bad! t-shm.c:260 r == 0 >> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 >> and start over. >> 0 of 1 tests completed successfully >> *** 1 error in test! *** >> 2..bad! t-shm.c:177 cnt <= MAX_CNT >> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 >> and start over. >> 4 of 5 tests completed successfully >> *** 1 error in test! *** > > > -- > http://ache.pp.ru/ > From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 11:44:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A1B316A40F; Sat, 16 Dec 2006 11:44:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D069E43CA1; Sat, 16 Dec 2006 11:44:24 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7F8C246EBB; Sat, 16 Dec 2006 06:44:24 -0500 (EST) Date: Sat, 16 Dec 2006 11:44:24 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061216111656.GA7501@nagual.pp.ru> Message-ID: <20061216114349.Q72986@fledge.watson.org> References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dinoex@freebsd.org, umq@ueo.co.jp, current@freebsd.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 11:44:25 -0000 On Sat, 16 Dec 2006, Andrey Chernov wrote: > The only place where EACCES may come is ipcperm() which was > significally touched last time at: > > revision 1.30 > date: 2006/11/06 13:42:01; author: rwatson; state: Exp; lines: +65 -37 > Sweep kernel replacing suser(9) calls with priv(9) calls, assigning > specific privilege names to a broad range of privileges. These may > require some future tweaking. > > Sponsored by: nCircle Network Security, Inc. > Obtained from: TrustedBSD Project > Discussed on: arch@ > Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, > Alex Lyashkov , > Skip Ford , > Antoine Brodin I've backed out 1.30 for now (change 1.31), until I have time to revisit this. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > > On Sat, Dec 16, 2006 at 08:59:03AM +0300, Andrey Chernov wrote: >> It seems shm is broken in very recent -current. >> Trying to build dkim-milter or dk-milter port (from root, of course) I >> got: >> >> ./t-shm >> shmget: Permission denied >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> shminit failed: Permission denied >> 1..bad! t-shm.c:260 r == 0 >> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 >> and start over. >> 0 of 1 tests completed successfully >> *** 1 error in test! *** >> 2..bad! t-shm.c:177 cnt <= MAX_CNT >> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 >> and start over. >> 4 of 5 tests completed successfully >> *** 1 error in test! *** > > > -- > http://ache.pp.ru/ > From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 11:44:28 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE2ED16A415; Sat, 16 Dec 2006 11:44:28 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DCCD43C9E; Sat, 16 Dec 2006 11:44:27 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGBiQt7007833; Sat, 16 Dec 2006 14:44:26 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGBiQmX007832; Sat, 16 Dec 2006 14:44:26 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 14:44:26 +0300 From: Andrey Chernov To: Robert Watson Message-ID: <20061216114426.GA7735@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216112117.P72986@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 11:44:29 -0000 On Sat, Dec 16, 2006 at 11:25:55AM +0000, Robert Watson wrote: > Yes, you can find the details in kern/106078. > > The thrust of the problem is that applications apparently pass access mode > arguments to shmget() in situations other than file creation, which isn't > documented in the spec. I've been doing a bit of on-and-off research on > this, but need to do some more before I'm ready to change our > implementation to simply ignore the argument. I hope to look at it again > this week sometime; it's unclear to me what applications are trying to > accomplish with the mode field in the non-IPC_CREAT case, and none of the > man pages and documentation I've found on various UNIX systems to date > suggest anything in particular. See t-shm.c code in either dk-milter or dkim-milter to gather the sample of operation. Those test written in way to be passed in all sysv ipc conformant machines. Which isn't our FreeBSD now :( I think removing that old code is the root of the problem: * Always permit the creator/owner to update the object * protections regardless of whether the object mode * permits it. */ if (mode & IPC_M) return (0); I.e. old code not even check for IPC_W or IPC_R in case of IPC_M presense. Moreover, old code allows _anything_ for suser: if ((mode & perm->mode) != mode) { if (suser(td) != 0) return (EACCES); } > >On Sat, Dec 16, 2006 at 08:59:03AM +0300, Andrey Chernov wrote: > >>It seems shm is broken in very recent -current. > >>Trying to build dkim-milter or dk-milter port (from root, of course) I > >>got: > >> > >>./t-shm > >>shmget: Permission denied > >>^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>shminit failed: Permission denied > >>1..bad! t-shm.c:260 r == 0 > >>add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 > >>and start over. > >>0 of 1 tests completed successfully > >>*** 1 error in test! *** > >>2..bad! t-shm.c:177 cnt <= MAX_CNT > >>add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 > >>and start over. > >>4 of 5 tests completed successfully > >>*** 1 error in test! *** > > > > > >-- > >http://ache.pp.ru/ > > -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 11:51:12 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77F4116A407; Sat, 16 Dec 2006 11:51:12 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D74E43CB9; Sat, 16 Dec 2006 11:51:03 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGBp2mG007956; Sat, 16 Dec 2006 14:51:02 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGBp2Mr007955; Sat, 16 Dec 2006 14:51:02 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 14:51:02 +0300 From: Andrey Chernov To: Robert Watson Message-ID: <20061216115102.GA7922@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216114349.Q72986@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216114349.Q72986@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 11:51:12 -0000 On Sat, Dec 16, 2006 at 11:44:24AM +0000, Robert Watson wrote: > I've backed out 1.30 for now (change 1.31), until I have time to revisit > this. Thanx! See my earlier followup about special treating of IPC_M and allowing anything for suser. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 12:11:05 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E56CC16A403; Sat, 16 Dec 2006 12:11:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9753B43C9D; Sat, 16 Dec 2006 12:11:05 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3324046EA9; Sat, 16 Dec 2006 07:11:05 -0500 (EST) Date: Sat, 16 Dec 2006 12:11:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061216114426.GA7735@nagual.pp.ru> Message-ID: <20061216120746.E72986@fledge.watson.org> References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 12:11:06 -0000 On Sat, 16 Dec 2006, Andrey Chernov wrote: > See t-shm.c code in either dk-milter or dkim-milter to gather the sample of > operation. Those test written in way to be passed in all sysv ipc conformant > machines. Which isn't our FreeBSD now :( > > I think removing that old code is the root of the problem: > > * Always permit the creator/owner to update the object > * protections regardless of whether the object mode > * permits it. > */ > if (mode & IPC_M) > return (0); > > I.e. old code not even check for IPC_W or IPC_R in case of IPC_M presense. Is this conclusion a supposition or the result of testing? Could you test and see if this is true? > Moreover, old code allows _anything_ for suser: The new code should also allow anything, as long as the bits passed into ipcperm() as requested modes are valid. There's certainly a bug here somewhere, but I'm not convinced it's what you think it is. At least part of the bug appears to be improper enforcement in the case of shmget() on an existing object, which is a bug in sysv_shm.c, not sysv_ipc.c. I'll try to take a further look at this while on my way to Oxford today, but will be offline for a day or two so it may take me a bit to get back on this. Robert N M Watson Computer Laboratory University of Cambridge > > if ((mode & perm->mode) != mode) { > if (suser(td) != 0) > return (EACCES); > } > >>> On Sat, Dec 16, 2006 at 08:59:03AM +0300, Andrey Chernov wrote: >>>> It seems shm is broken in very recent -current. >>>> Trying to build dkim-milter or dk-milter port (from root, of course) I >>>> got: >>>> >>>> ./t-shm >>>> shmget: Permission denied >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> shminit failed: Permission denied >>>> 1..bad! t-shm.c:260 r == 0 >>>> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 >>>> and start over. >>>> 0 of 1 tests completed successfully >>>> *** 1 error in test! *** >>>> 2..bad! t-shm.c:177 cnt <= MAX_CNT >>>> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4 >>>> and start over. >>>> 4 of 5 tests completed successfully >>>> *** 1 error in test! *** >>> >>> >>> -- >>> http://ache.pp.ru/ >>> > > > -- > http://ache.pp.ru/ > _______________________________________________ > 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 Sat Dec 16 12:51:39 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1228E16A415; Sat, 16 Dec 2006 12:51:39 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5898843C9F; Sat, 16 Dec 2006 12:51:38 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGCpb4r001171; Sat, 16 Dec 2006 15:51:37 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGCpbpE001170; Sat, 16 Dec 2006 15:51:37 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 15:51:36 +0300 From: Andrey Chernov To: Robert Watson Message-ID: <20061216125136.GA1094@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216120746.E72986@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 12:51:39 -0000 On Sat, Dec 16, 2006 at 12:11:05PM +0000, Robert Watson wrote: > > * Always permit the creator/owner to update the object > > * protections regardless of whether the object mode > > * permits it. > > */ > > if (mode & IPC_M) > > return (0); > > > >I.e. old code not even check for IPC_W or IPC_R in case of IPC_M presense. > > Is this conclusion a supposition or the result of testing? Could you test > and see if this is true? It comes just from code reading. First check for owner and next check for IPC_M bit _only_ (no other bits!) then return (0) i.e. success. > >Moreover, old code allows _anything_ for suser: > The new code should also allow anything, as long as the bits passed into > ipcperm() as requested modes are valid. There's certainly a bug here I mean anything for suser ignoring completely any modes passed. I.e. no EACCES should happen for suser in _any_ mode combination. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 12:57:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3596C16A4CE; Sat, 16 Dec 2006 12:57:50 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id A348F43CA2; Sat, 16 Dec 2006 12:57:37 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 0BCA78C9F93; Sat, 16 Dec 2006 20:57:36 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id E2DE68C9F89; Sat, 16 Dec 2006 20:57:36 +0800 (CST) Date: Sat, 16 Dec 2006 20:57:36 +0800 (CST) From: Tai-hwa Liang To: Robert Watson In-Reply-To: <20061211140519.Q4227@fledge.watson.org> Message-ID: <0612162051509.77059@www.mmlab.cse.yzu.edu.tw> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> <20061211140519.Q4227@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 12:57:50 -0000 On Mon, 11 Dec 2006, Robert Watson wrote: > On Mon, 11 Dec 2006, Tai-hwa Liang wrote: >>> the kernel with KDB, DDB, and BREAK_TO_DEBUGGER, and user a serial or >>> firewire console. If the hang occurs, see if you can get into the >>> debugger, in which case the logged output from DDB for the following >>> commands would be very useful: >>> >>> show pcpu >>> show allpcpu >>> trace >>> alltrace >>> ps >>> show locks >>> show alllocks >>> show lockedvnods >>> show uma >>> show malloc >>> >>> Please open a PR that describes your configuration, includes your kernel >>> config (since it seems quite customized), any loader.conf settings, a >>> detailed description of the problem, and the output. I'd be quite >>> interested >> >> Okay, I'll file a PR once I can collect more information with the serial >> console(probably weekend). For now our system administrator is pretty >> nervous about my suggestion on turning debug.mpsafenet back to 1. ;) > > Thanks. Okay, I filed the collected data as kern/106805. Looks to me that the lockup does related to the WITNESS warning I've observed. db> trace Tracing pid 924 tid 100042 td 0xc653e480 kdb_enter(c0685297) at kdb_enter+0x2b siointr1(c6539400,c071fec0,0,c06850a1,56e,...) at siointr1+0xce siointr(c6539400) at siointr+0x21 intr_execute_handlers(c63ea4c8,e6c308d0,4,e6c30920,c0621693,...) at intr_execute_handlers+0xe1 lapic_handle_intr(38) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc04edf41, esp = 0xe6c30914, ebp = 0xe6c30920 --- _mtx_lock_sleep(c698ce80,c653e480,0,c698a1b6,18f2) at _mtx_lock_sleep+0x115 _mtx_lock_flags(c698ce80,0,c698a1b6,18f2,c698ce80,...) at _mtx_lock_flags+0xa2 pf_test(2,c64bb800,e6c30a78,0,c755d000,...) at pf_test+0x81 pf_check_out(0,e6c30a78,c64bb800,2,c755d000) at pf_check_out+0x3d pfil_run_hooks(c071a420,e6c30af4,c64bb800,2,c755d000,...) at pfil_run_hooks+0xc9 ip_output(c687d700,0,e6c30ac0,0,0,c755d000) at ip_output+0x83a tcp_output(c7558740) at tcp_output+0xe0d tcp_disconnect(c7558740) at tcp_disconnect+0xe0 tcp_usr_disconnect(c72776f4,e6c30bf0,c0531e2c,c72776f4,c6edf480,...) at tcp_usr_disconnect+0x6b sodisconnect(c72776f4) at sodisconnect+0x26 soclose(c72776f4) at soclose+0x48 soo_close(c6edf480,c653e480) at soo_close+0x4b fdrop_locked(c6edf480,c653e480,c63d5084,0,c0667839,...) at fdrop_locked+0x88 fdrop(c6edf480,c653e480,6ac,c06d02e0,0,...) at fdrop+0x24 closef(c6edf480,c653e480,0,0,39,...) at closef+0x367 close(c653e480,e6c30d04) at close+0x1a6 syscall(3b,3b,3b,0,39,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x2830e9af, esp = 0xbfbe88dc, ebp = 0xbfbe88f8 --- -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:01:01 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E744416A403; Sat, 16 Dec 2006 13:01:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D96F43CCB; Sat, 16 Dec 2006 13:00:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 80AFD46E28; Sat, 16 Dec 2006 08:00:56 -0500 (EST) Date: Sat, 16 Dec 2006 13:00:56 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061216125136.GA1094@nagual.pp.ru> Message-ID: <20061216125419.J72986@fledge.watson.org> References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 13:01:02 -0000 On Sat, 16 Dec 2006, Andrey Chernov wrote: > On Sat, Dec 16, 2006 at 12:11:05PM +0000, Robert Watson wrote: >>> * Always permit the creator/owner to update the object >>> * protections regardless of whether the object mode >>> * permits it. >>> */ >>> if (mode & IPC_M) >>> return (0); >>> >>> I.e. old code not even check for IPC_W or IPC_R in case of IPC_M presense. >> >> Is this conclusion a supposition or the result of testing? Could you test >> and see if this is true? > > It comes just from code reading. First check for owner and next check for > IPC_M bit _only_ (no other bits!) then return (0) i.e. success. Only if IPC_M is being requested. Is IPC_M being requested in the case where you are seeing an error? I can read code too, so what I'm asking is how the system is behaving. >>> Moreover, old code allows _anything_ for suser: > >> The new code should also allow anything, as long as the bits passed into >> ipcperm() as requested modes are valid. There's certainly a bug here > > I mean anything for suser ignoring completely any modes passed. I.e. no > EACCES should happen for suser in _any_ mode combination. No, ipcperm() will return an access control error if an invalid access mode is requested. We grant valid rights, not all rights, to the super user. I'm fairly certain there's a bug in my ipcperm(), possibly in the manipulation of read/write bits, etc. However, the question is why the bug is causing a problem at all. The second call to shmget() in the sample code provided by the original submitter shouldn't actually need to call ipcperm(), since we don't authorize access to the name space based on IPC permissions, only access to the IPC objects. This suggests that shmget() is improperly calling ipcperm(), and that the call needs to be removed. As I said, this is something that I hope to revisit in the next few days. However, it would be helpful if you could tell me the arguments and call path to the ipcperm() function instance that's generating the improper failure. It could be that both a bug in ipcperm() and a big in shmget() need to be fixed. The reason I've delayed fixing it so far is that I think the bug in shmget() has to do with poorly defined semantics for shmget(), and I want to make sure I'm fixing the system to use the correct semantics. Unfortunately, that has proven tricky as the specifications re the source of the poorly defined semantics. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:05:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 433DD16A4B3 for ; Sat, 16 Dec 2006 13:05:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EC8A43CED for ; Sat, 16 Dec 2006 13:05:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6B33046E28; Sat, 16 Dec 2006 08:05:03 -0500 (EST) Date: Sat, 16 Dec 2006 13:05:03 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tai-hwa Liang In-Reply-To: <0612162051509.77059@www.mmlab.cse.yzu.edu.tw> Message-ID: <20061216130332.A72986@fledge.watson.org> References: <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org> <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> <20061211140519.Q4227@fledge.watson.org> <0612162051509.77059@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CURRENT freezes on Laitude D520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 13:05:15 -0000 On Sat, 16 Dec 2006, Tai-hwa Liang wrote: >>>> Please open a PR that describes your configuration, includes your kernel >>>> config (since it seems quite customized), any loader.conf settings, a >>>> detailed description of the problem, and the output. I'd be quite >>>> interested >>> >>> Okay, I'll file a PR once I can collect more information with the serial >>> console(probably weekend). For now our system administrator is pretty >>> nervous about my suggestion on turning debug.mpsafenet back to 1. ;) >> >> Thanks. > > Okay, I filed the collected data as kern/106805. Looks to me that the > lockup does related to the WITNESS warning I've observed. Indeed, as you surmise, it looks like pf is holding a lock over entry to the network stack, which is a bad idea as pf locks normally follow most other locks in the network stack in the global lock order. Mark has assigned the PR to freebsd-pf, so hopefully it will be picked up there. If no one has picked it up in a couple of weeks, please ping me and I can investigate myself; since I don't use pf and am unfamiliar with the internals, it's probably better if someone who is an expert in pf internals takes the first cut at this. Thanks for the excellent problem report! Robert N M Watson Computer Laboratory University of Cambridge > > db> trace > Tracing pid 924 tid 100042 td 0xc653e480 > kdb_enter(c0685297) at kdb_enter+0x2b > siointr1(c6539400,c071fec0,0,c06850a1,56e,...) at siointr1+0xce > siointr(c6539400) at siointr+0x21 > intr_execute_handlers(c63ea4c8,e6c308d0,4,e6c30920,c0621693,...) at > intr_execute_handlers+0xe1 > lapic_handle_intr(38) at lapic_handle_intr+0x2e > Xapic_isr1() at Xapic_isr1+0x33 > --- interrupt, eip = 0xc04edf41, esp = 0xe6c30914, ebp = 0xe6c30920 --- > _mtx_lock_sleep(c698ce80,c653e480,0,c698a1b6,18f2) at _mtx_lock_sleep+0x115 > _mtx_lock_flags(c698ce80,0,c698a1b6,18f2,c698ce80,...) at > _mtx_lock_flags+0xa2 > pf_test(2,c64bb800,e6c30a78,0,c755d000,...) at pf_test+0x81 > pf_check_out(0,e6c30a78,c64bb800,2,c755d000) at pf_check_out+0x3d > pfil_run_hooks(c071a420,e6c30af4,c64bb800,2,c755d000,...) at > pfil_run_hooks+0xc9 > ip_output(c687d700,0,e6c30ac0,0,0,c755d000) at ip_output+0x83a > tcp_output(c7558740) at tcp_output+0xe0d > tcp_disconnect(c7558740) at tcp_disconnect+0xe0 > tcp_usr_disconnect(c72776f4,e6c30bf0,c0531e2c,c72776f4,c6edf480,...) at > tcp_usr_disconnect+0x6b > sodisconnect(c72776f4) at sodisconnect+0x26 > soclose(c72776f4) at soclose+0x48 > soo_close(c6edf480,c653e480) at soo_close+0x4b > fdrop_locked(c6edf480,c653e480,c63d5084,0,c0667839,...) at fdrop_locked+0x88 > fdrop(c6edf480,c653e480,6ac,c06d02e0,0,...) at fdrop+0x24 > closef(c6edf480,c653e480,0,0,39,...) at closef+0x367 > close(c653e480,e6c30d04) at close+0x1a6 > syscall(3b,3b,3b,0,39,...) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (6, FreeBSD ELF32, close), eip = 0x2830e9af, esp = 0xbfbe88dc, > ebp = 0xbfbe88f8 --- > > -- > Cheers, > > Tai-hwa Liang > From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:11:40 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FF5016A509; Sat, 16 Dec 2006 13:11:40 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4272443CAA; Sat, 16 Dec 2006 13:11:37 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGDBZiF001534; Sat, 16 Dec 2006 16:11:35 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGDBZHc001533; Sat, 16 Dec 2006 16:11:35 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 16:11:35 +0300 From: Andrey Chernov To: Robert Watson Message-ID: <20061216131135.GA1393@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru> <20061216125419.J72986@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216125419.J72986@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 13:11:40 -0000 On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote: > Only if IPC_M is being requested. Is IPC_M being requested in the case > where you are seeing an error? I can read code too, so what I'm asking is > how the system is behaving. I'll track exact case a bit later. For now I just speak about differences between new code and old code I found. New code check all bits match while old code check IPC_M bit match only at this place. > is requested. We grant valid rights, not all rights, to the super user. This is clearly wrong. Think about files. Even file is read-only, root _can_ write into it while normal user in the same situation can't. root> touch aaa root> chmod 444 aaa root> cat > aaa OK ^D > As I said, this is something that I hope to revisit in the next few days. > However, it would be helpful if you could tell me the arguments and call > path to the ipcperm() function instance that's generating the improper > failure. It could be that both a bug in ipcperm() and a big in shmget() I'll try to make ktrace output, a bit later. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:25:00 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78ABD16A403; Sat, 16 Dec 2006 13:25:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21AE543CB3; Sat, 16 Dec 2006 13:25:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C5F3446E1F; Sat, 16 Dec 2006 08:24:59 -0500 (EST) Date: Sat, 16 Dec 2006 13:24:59 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061216131135.GA1393@nagual.pp.ru> Message-ID: <20061216131715.C72986@fledge.watson.org> References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru> <20061216125419.J72986@fledge.watson.org> <20061216131135.GA1393@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 13:25:00 -0000 On Sat, 16 Dec 2006, Andrey Chernov wrote: > On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote: >> Only if IPC_M is being requested. Is IPC_M being requested in the case >> where you are seeing an error? I can read code too, so what I'm asking is >> how the system is behaving. > > I'll track exact case a bit later. For now I just speak about differences > between new code and old code I found. New code check all bits match while > old code check IPC_M bit match only at this place. As I said, I can read code too. The changes in access control logic are intentional and conservative. There is at least one bug, and possibly two bugs, in play here. The basic situation is that the user application is relying on undefined behavior of the API. Previously, we implemented that undefined behavior by accident: we appear to be improperly checking for access, but due to the flexibility of the checks, we grant them. We need to now implement the undefined behavior on purpose, since the new access control implementation is structured. A bug in the new ipcperm() may well be triggering the appearance of the error, but it appears also to be a product of incorrectly structured code in the existing shared memory implementation. The long-term goal is to have a correct implementation of the new code, not simply revert to the old code. >> is requested. We grant valid rights, not all rights, to the super user. > > This is clearly wrong. Think about files. Even file is read-only, root _can_ > write into it while normal user in the same situation can't. No, it is not wrong. We grant only valid rights, we don't grant invalid rights. One of the possible bugs here is that an invalid request for rights is being made, which would result in an access failure. The existing code might not detect that, the new code will. > root> touch aaa root> chmod 444 aaa root> cat > aaa OK These are all valid rights, so they are accepted. >> As I said, this is something that I hope to revisit in the next few days. >> However, it would be helpful if you could tell me the arguments and call >> path to the ipcperm() function instance that's generating the improper >> failure. It could be that both a bug in ipcperm() and a big in shmget() > > I'll try to make ktrace output, a bit later. That's not what I asked for. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:35:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C10FE16A40F; Sat, 16 Dec 2006 13:35:51 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4C4643C9E; Sat, 16 Dec 2006 13:35:50 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGDZntP001870; Sat, 16 Dec 2006 16:35:49 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGDZnKx001869; Sat, 16 Dec 2006 16:35:49 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 16:35:48 +0300 From: Andrey Chernov To: current@freebsd.org, kmacy@freebsd.org Message-ID: <20061216133547.GA1754@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, kmacy@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Fatal trap at booting after last kmacy@ changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 13:35:51 -0000 Last kernel got immediately fatal trap at boot, right after timer probe. This is what I write by hand from the console: Fatal trap 12: page fault while in kernel mode fault code: supervisor read, page not present stopped at sleepq_add+0xf6: cmpl $0,0(%rax,%eax,8) stack trace: sleepq_add cv_timedwait _sema_timedwait ata_queue_request ... -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:41:39 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 476B916A403; Sat, 16 Dec 2006 13:41:39 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5014543C9E; Sat, 16 Dec 2006 13:41:38 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGDfbNL001955; Sat, 16 Dec 2006 16:41:37 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGDfbl5001954; Sat, 16 Dec 2006 16:41:37 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 16:41:36 +0300 From: Andrey Chernov To: Robert Watson Message-ID: <20061216134136.GB1754@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru> <20061216125419.J72986@fledge.watson.org> <20061216131135.GA1393@nagual.pp.ru> <20061216131715.C72986@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216131715.C72986@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -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: Sat, 16 Dec 2006 13:41:39 -0000 On Sat, Dec 16, 2006 at 01:24:59PM +0000, Robert Watson wrote: > control implementation is structured. A bug in the new ipcperm() may well > be triggering the appearance of the error, but it appears also to be a > product of incorrectly structured code in the existing shared memory > implementation. The long-term goal is to have a correct implementation of > the new code, not simply revert to the old code. Well, in case t-shm tests will pass, any re-structuring will be fine for me. > >>failure. It could be that both a bug in ipcperm() and a big in shmget() > > > >I'll try to make ktrace output, a bit later. > > That's not what I asked for. In that case I'll be delayed for a longer time - right now -current is not bootable - fatal trap due to kmacy@ changes. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:54:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B623716A415 for ; Sat, 16 Dec 2006 13:54:12 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6017143CA4 for ; Sat, 16 Dec 2006 13:54:11 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 16 Dec 2006 13:54:09 -0000 Received: from h081217095052.dyn.cm.kabsi.at (EHLO [192.168.0.1]) [81.217.95.52] by mail.gmx.net (mp046) with SMTP; 16 Dec 2006 14:54:09 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: obrien@freebsd.org Date: Sat, 16 Dec 2006 14:54:06 +0100 User-Agent: KMail/1.9.4 References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612151914.53705.shoesoft@gmx.net> <20061215205138.GB55276@dragon.NUXI.org> In-Reply-To: <20061215205138.GB55276@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612161454.08351.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Peter Jeremy , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 13:54:12 -0000 On Friday 15 December 2006 21:51, David O'Brien wrote: > On Fri, Dec 15, 2006 at 07:14:53PM +0100, Stefan Ehmann wrote: > > > CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU) > > .. > > > Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 > > ----------------------------+---------+---------+--------- > > -O2 | 6.46s | 6.67s | 6.38s > > -O2 -funroll-loops | 4.44s | 4.16s | 4.02s > > -O2 -march=athlon-xp -fun.. | 4.39s | 4.38s | 4.26s > > -O3 | 6.14s | 5.23s | 5.16s > > -O3 -funroll-loops | 4.24s | 4.87s | 4.95s > > -O3 -march=athlon-xp -fun.. | 4.19s | 4.90s | 5.07s > > A fine example that -O3 isn't always better than -O2. > I wonder if you're blowing the L2 cache. IIRC, all Athlon XP 2700+ > are the Thoughbread core, which has only 256KB L2. Yes, only 256KB L2 cache here. Results on a pentium-m with 2MB L2 cache were quite similar. With loop unrolling -O2 was still faster than -O3. Though not as much slower as on the Athlon XP. As a side note: (stripped) gcc42 binaries were up to 200% of the size of the gcc34 binaries. From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 17:30:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBF0316A412; Sat, 16 Dec 2006 17:30:59 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31AD743C9E; Sat, 16 Dec 2006 17:30:59 +0000 (GMT) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5F016.dip.t-dialin.net [84.165.240.22]) by redbull.bpaserver.net (Postfix) with ESMTP id 273462E190; Sat, 16 Dec 2006 18:30:52 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 51A965B480D; Sat, 16 Dec 2006 18:30:49 +0100 (CET) Date: Sat, 16 Dec 2006 18:30:48 +0100 From: Alexander Leidinger To: current@freebsd.org, rodrigc@freebsd.org, maxim@freebsd.org Message-ID: <20061216183048.43ce8a11@Magellan.Leidinger.net> X-Mailer: Claws Mail 2.6.1 (GTK+ 2.10.6; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=MP_Njveitp0Lm8ER9rNuyoiSp_ X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.133, required 6, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, IMPRONONCABLE_2 1.50, TW_EB 0.08, TW_EV 0.08, TW_KD 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Subject: Easy kernel panic as ordinary user with msdosfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 17:30:59 -0000 --MP_Njveitp0Lm8ER9rNuyoiSp_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, attached is a backtrace of a crash when I run "madplay /path/to/fat32/directory/" (yes, this is stupid use of madplay). When I run "madplay /path/to/ufs/directory/" I don't get a panic. When I use a real MP3 on a fat32, I get the panic too. This is: ---snip--- # uname -a FreeBSD luna.leidinger.net 7.0-CURRENT FreeBSD 7.0-CURRENT #43: Fri Dec 15 22:13:50 CET 2006 root@luna.leidinger.net:/usr/src/sys/i386/compile/LUNA i386 $FreeBSD: src/sys/fs/msdosfs/msdosfs_vfsops.c,v 1.155 2006/12/09 01:49:19 rodrigc Exp $ $FreeBSD: src/sys/fs/msdosfs/msdosfs_vnops.c,v 1.166 2006/12/03 19:04:26 maxim Exp $ ---snip--- Bye, Alexander. -- Never make a decision you can get someone else to make. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 --MP_Njveitp0Lm8ER9rNuyoiSp_ Content-Type: text/plain; name=crash.txt Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=crash.txt Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc0850ec7 stack pointer = 0x28:0xcc5c49f4 frame pointer = 0x28:0xcc5c4a3c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1041 (madplay) panic: from debugger Uptime: 15m2s Physical memory: 231 MB Dumping 44 MB: 29 13 (kgdb) bt #0 doadump () at pcpu.h:166 During symbol reading, Incomplete CFI data; unspecified registers at 0xc04c9313. #1 0xc04c98c2 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:411 #2 0xc04c9c97 in panic (fmt=0x234
) at ../../../kern/kern_shutdown.c:567 #3 0xc044b3c7 in db_panic (addr=0xc0850ec7, have_addr=0x0, count=0xffffffff, modif=0xcc5c47e4 "") at ../../../ddb/db_command.c:433 #4 0xc044b7b3 in db_command_loop () at ../../../ddb/db_command.c:401 #5 0xc044d684 in db_trap (type=0x12, code=0x0) at ../../../ddb/db_main.c:222 #6 0xc04eb9d1 in kdb_trap (type=0x0, code=0x0, tf=0x0) at ../../../kern/subr_kdb.c:502 #7 0xc0609e03 in trap_fatal (frame=0xcc5c49b4, eva=0x0) at ../../../i386/i386/trap.c:860 #8 0xc060a3bb in trap (frame= {tf_fs = 0x8, tf_es = 0x28, tf_ds = 0x28, tf_edi = 0x0, tf_esi = 0x0, tf_ebp = 0xcc5c4a3c, tf_isp = 0xcc5c49e0, tf_ebx = 0x9000, tf_edx = 0x0, tf_ecx = 0x0, tf_eax = 0x9000, tf_trapno = 0x12, tf_err = 0x0, tf_eip = 0xc0850ec7, tf_cs = 0x20, tf_eflags = 0x10246, tf_esp = 0xc1e1c600, tf_ss = 0x17700}) at ../../../i386/i386/trap.c:660 #9 0xc05fa71a in calltrap () at ../../../i386/i386/exception.s:138 #10 0xc0850ec7 in chn_sync (c=0xc1e1b800, threshold=0x9000) at /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/channel.c:716 #11 0xc0851154 in chn_flush (c=0xc1e1b800) at /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/channel.c:835 #12 0xc0852f9b in dsp_close (i_dev=0xc1e1c400, flags=0x2, mode=0x2000, td=0xc2057d80) at /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/dsp.c:366 #13 0xc049db1f in giant_close (dev=0xc1e1c400, fflag=0x9000, devtype=0x9000, td=0x9000) at ../../../kern/kern_conf.c:284 #14 0xc048784b in devfs_close (ap=0xcc5c4b2c) at ../../../fs/devfs/devfs_vnops.c:352 #15 0xc0613e66 in VOP_CLOSE_APV (vop=0x9000, a=0x0) at vnode_if.c:424 #16 0xc053932a in vn_close (vp=0xc254396c, flags=0x2, file_cred=0x9000, td=0xc2057d80) at vnode_if.h:227 #17 0xc053a658 in vn_closefile (fp=0xc22fc900, td=0x9000) at ../../../kern/vfs_vnops.c:869 #18 0xc04a3954 in fdrop_locked (fp=0xc22fc900, td=0xc2057d80) at file.h:296 #19 0xc04a3c32 in closef (fp=0xc22fc900, td=0xc2057d80) at ../../../kern/kern_descrip.c:1980 #20 0xc04a456d in kern_close (td=0xc2057d80, fd=0x4) at ../../../kern/kern_descrip.c:1027 #21 0xc060a93a in syscall (frame= {tf_fs = 0x3b, tf_es = 0x3b, tf_ds = 0x3b, tf_edi = 0xbfbfeb14, tf_esi = 0x1, tf_ebp = 0xbfbfe97c, tf_isp = 0xcc5c4d64, tf_ebx = 0xbfbfeb14, tf_edx = 0x4, tf_ecx = 0x0, tf_eax = 0x6, tf_trapno = 0x16, tf_err = 0x2, tf_eip = 0x28296a9b, tf_cs = 0x33, tf_eflags = 0x246, tf_esp = 0xbfbf115c, tf_ss = 0x3b}) at ../../../i386/i386/trap.c:1010 #22 0xc05fa76f in Xint0x80_syscall () at ../../../i386/i386/exception.s:191 --MP_Njveitp0Lm8ER9rNuyoiSp_-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 17:42:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B55D716A403; Sat, 16 Dec 2006 17:42:13 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9609943CAA; Sat, 16 Dec 2006 17:42:11 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from ex.hhp.local by mx.gfk.ru (MDaemon PRO v9.5.3) with ESMTP id md50000781632.msg; Sat, 16 Dec 2006 20:42:08 +0300 Received: from dialup-chibis.gfk.ru ([10.0.6.45]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Dec 2006 20:42:01 +0300 Date: Sat, 16 Dec 2006 20:42:03 +0300 (MSK) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: Andrey Chernov In-Reply-To: <20061216133547.GA1754@nagual.pp.ru> Message-ID: <20061216203900.G599@free.home.local> References: <20061216133547.GA1754@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 16 Dec 2006 17:42:02.0184 (UTC) FILETIME=[7E75A480:01C72139] X-Spam-Processed: mx.gfk.ru, Sat, 16 Dec 2006 20:42:08 +0300 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDAV-Processed: mx.gfk.ru, Sat, 16 Dec 2006 20:42:08 +0300 Cc: current@freebsd.org, kmacy@freebsd.org Subject: Re: Fatal trap at booting after last kmacy@ changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 17:42:13 -0000 > Last kernel got immediately fatal trap at boot, right after timer probe. > This is what I write by hand from the console: > > Fatal trap 12: page fault while in kernel mode > fault code: supervisor read, page not present > stopped at sleepq_add+0xf6: cmpl $0,0(%rax,%eax,8) > > stack trace: > sleepq_add > cv_timedwait > _sema_timedwait > ata_queue_request > ... It seems that with INVARIANTS &sq is referenced while sq is NULL... This should fix it: Index: subr_sleepqueue.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_sleepqueue.c,v retrieving revision 1.32 diff -u -r1.32 subr_sleepqueue.c --- subr_sleepqueue.c 16 Dec 2006 07:50:39 -0000 1.32 +++ subr_sleepqueue.c 16 Dec 2006 17:34:27 -0000 @@ -295,6 +295,7 @@ * into the sleep queue already in use by this wait channel. */ if (sq == NULL) { + sq = td->td_sleepqueue; #ifdef INVARIANTS int i; for (i = 0; i < NR_SLEEPQS; i++) @@ -313,7 +314,6 @@ sleepq_max_depth = sc->sc_max_depth; } #endif - sq = td->td_sleepqueue; LIST_INSERT_HEAD(&sc->sc_queues, sq, sq_hash); sq->sq_wchan = wchan; #ifdef INVARIANTS Yuriy. From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 20:34:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8C3716A407; Sat, 16 Dec 2006 20:34:23 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id C732443CA3; Sat, 16 Dec 2006 20:34:22 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBGKYLeH017402; Sat, 16 Dec 2006 23:34:21 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBGKYLVo017401; Sat, 16 Dec 2006 23:34:21 +0300 (MSK) (envelope-from ache) Date: Sat, 16 Dec 2006 23:34:20 +0300 From: Andrey Chernov To: Yuriy Tsibizov Message-ID: <20061216203420.GA17353@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Yuriy Tsibizov , current@freebsd.org, kmacy@freebsd.org References: <20061216133547.GA1754@nagual.pp.ru> <20061216203900.G599@free.home.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216203900.G599@free.home.local> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org, kmacy@freebsd.org Subject: Re: Fatal trap at booting after last kmacy@ changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 20:34:23 -0000 On Sat, Dec 16, 2006 at 08:42:03PM +0300, Yuriy Tsibizov wrote: > >Last kernel got immediately fatal trap at boot, right after timer probe. > >This is what I write by hand from the console: > > > >Fatal trap 12: page fault while in kernel mode > > It seems that with INVARIANTS &sq is referenced while sq is NULL... Thanx, committed, it fix the problem. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 21:05:20 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A679016A415 for ; Sat, 16 Dec 2006 21:05:20 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E47C43CA1 for ; Sat, 16 Dec 2006 21:05:20 +0000 (GMT) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <45845F8B.3060304@intersonic.se> Date: Sat, 16 Dec 2006 22:05:15 +0100 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 1.5.0.8 (X11/20061206) MIME-Version: 1.0 To: "M. Warner Losh" References: <4579EB08.8080704@intersonic.se> <20061210.230622.-1844001233.imp@bsdimp.com> In-Reply-To: <20061210.230622.-1844001233.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 21:05:20 -0000 M. Warner Losh wrote: > In message: <4579EB08.8080704@intersonic.se> > Per olof Ljungmark writes: > : Am I an idiot or is anyone else out there running -current on production > : systems? I figured if one MX goes haywire at least we've got another > : one... Very interested in your opinion. > > People use -current on production servers. But not just any old > version of -current. Rather, carefully selected versions of -current > that have been validated and tested. The -stable branches are a lot > more likely to be suitabe for a server, but -current can be useful. > > However, be prepared to compile everything yourself. Also be prepared > to do it again when you upgrade. While you may get a stable system > out of it, you are signing up for the "I know what I'm doing club" and > the bar to enter that club is a lot higher than the "I run stable > club." > > It isn't recommended by the project, since at any given moment > -current may be useful or it may have some horrible bug and the waters > are a lot choppier. > > Warner Thank you all for the input. After some consideration I've decided to go ahead so I'm currently preparing and testing a -CURRENT system for production use, after all, there is nothing like real life :-) Also, it should be a nice way to find out if I now what I'm doing... I do watch the list and also keep a backup RELENG-6 system that can go online at any time. Per olof From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 22:18:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF90016A407 for ; Sat, 16 Dec 2006 22:18:35 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9F9643CB4 for ; Sat, 16 Dec 2006 22:18:34 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 1330 invoked from network); 16 Dec 2006 22:17:57 -0000 Received: from ppp-71-139-31-204.dsl.snfc21.pacbell.net (HELO ?10.0.5.59?) (nate-mail@71.139.31.204) by root.org with ESMTPA; 16 Dec 2006 22:17:57 -0000 Message-ID: <4584708B.3020902@root.org> Date: Sat, 16 Dec 2006 14:17:47 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Stepan Zastupov References: <20061214234849.GA1062@stepan.ispsystem.net> In-Reply-To: <20061214234849.GA1062@stepan.ispsystem.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cbb hangs during suspend if ath card active X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 2006 22:18:35 -0000 Stepan Zastupov wrote: > Does anyone still work on this problem? (http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064550.html) > I incure the same problems. If need testing I can help with it. Just comment out this line in ath_stop() in if_ath.c: // ath_hal_setpower(sc->sc_ah, HAL_PM_FULL_SLEEP); -- Nate