From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 05:04:54 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C09106566B for ; Sun, 15 Nov 2009 05:04:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 577CB8FC19 for ; Sun, 15 Nov 2009 05:04:54 +0000 (UTC) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id E81AD55CD9A5; Sun, 15 Nov 2009 13:04:52 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id szGwq23nWvUK; Sun, 15 Nov 2009 13:04:47 +0800 (CST) Received: from delta.delphij.net (c-69-181-136-105.hsd1.ca.comcast.net [69.181.136.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 55DE855CD994; Sun, 15 Nov 2009 13:04:45 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=m9DMNxE21RCel8KH50J+zUivQwlKbzQ7sY1fs5krlcIYobYjjg84PBXbhbzRdvhEE hgTOCZI91+oEt7anKaAFQ== Message-ID: <4AFF8BE9.9000003@delphij.net> Date: Sat, 14 Nov 2009 21:04:41 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Thunderbird 2.0.0.23 (X11/20091022) MIME-Version: 1.0 To: Jilles Tjoelker References: <200911090237.nA92b2m7005471__19254.880565177$1257734275$gmane$org@svn.freebsd.org> <867htvhygy.fsf@gmail.com> <4AFDDEA1.70900@delphij.net> <4AFDE27F.1070406@delphij.net> <4AFDEB70.5080807@delphij.net> <20091114130524.GA35115@stack.nl> In-Reply-To: <20091114130524.GA35115@stack.nl> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anonymous , freebsd-current@FreeBSD.ORG, d@delphij.net, matthew green Subject: Re: svn commit: r199066 - head/usr.bin/gzip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 05:04:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jilles Tjoelker wrote: > On Fri, Nov 13, 2009 at 03:27:44PM -0800, Xin LI wrote: >> The previous fix has introduced an issue that revealed another bug as >> well (gzip -d -c can't decompress large-ish input stream, i.e. something >> like bzip2 -c ObsoleteFiles.inc | gunzip -d -c). The proposed patch: > >> * Set end_of_file flag if we hit a short read. This usually saves one >> read after the actual end of file. > > A short read does not necessarily mean EOF on a pipe or other > non-regular file. Yes you're right, what we really need is to distinguish between an non-existent end of file and a real short read. I'll see if I would have some other alternatives. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr/i+kACgkQi+vbBBjt66BqvQCgokChJF0RLKP/v1R7dNaWbtcP wAMAn29dHIxhGRwqI0IEjZhIIwxbT63X =g18V -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 05:18:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F6241065670 for ; Sun, 15 Nov 2009 05:18:00 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id EF5AD8FC0C for ; Sun, 15 Nov 2009 05:17:59 +0000 (UTC) Received: from asahi-net.jp (b151149.dynamic.ppp.asahi-net.or.jp [202.213.151.149]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 8D4C892950; Sun, 15 Nov 2009 14:17:58 +0900 (JST) Date: Sun, 15 Nov 2009 14:17:57 +0900 From: WATANABE Kazuhiro To: John Baldwin In-Reply-To: <200911061508.22482.jhb@freebsd.org> References: <200911061508.22482.jhb@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.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115051758.8D4C892950@mail1.asahi-net.or.jp> Cc: freebsd-net@freebsd.org, freebsd-current Subject: Re: [PATCH] Remove if_watchdog use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 05:18:00 -0000 Hi, I've tested the following NICs with your patch on CURRENT, and they works fine. Thanks! * Corega FastEther PCI-TX (DEC 21140-AF) de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 12 at device 15.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: Ethernet address: 00:00:f4:xx:xx:xx de0: [ITHREAD] * Acer ALN-201C (Realtek RTL8029AS) ed0: port 0xe000-0xe01f irq 12 at device 15.0 on pci0 ed0: Ethernet address: 00:60:67:xx:xx:xx ed0: [ITHREAD] At Fri, 6 Nov 2009 15:08:22 -0500, John Baldwin wrote: > I have a patchset that converts all the remaining users of if_watchdog to > using a private callout instead. In some cases the the driver already used a > private timer to drive a stats timer and I merely hooked into that timer. In > other cases a new callout needed to be added to the driver. Some drivers > even abused the if_watchdog interface to provide a stats timer that fired > every second. :) For a few drivers I also fixed other things such as busted > locking, order-of-operations issues in detach, or just completely busted > drivers (fea(4) and fpa(4) which share the pdq backend). Please test. > Barring any major screaming and shouting I plan to commit this in a week or > so and after that to work on removing the if_watchdog/if_timer stuff from the > network stack. > > The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch (snip) --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 09:13:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99F151065670 for ; Sun, 15 Nov 2009 09:13:18 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 213518FC0C for ; Sun, 15 Nov 2009 09:13:17 +0000 (UTC) Received: by bwz5 with SMTP id 5so4977924bwz.3 for ; Sun, 15 Nov 2009 01:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=YDcg/k5GoB05sA0rnQ+0p05BzOQJV/nq6/955FDLKm4=; b=iDT3m1ArRMtmtkTJZay4FgkotcxO+AhTz4hIXxGr3lGPNabuAgHd3dkBmd6uW065Zl 5uf+0Zs1H0MLkcUBZyHInwowwaiwExIgk+apKcNakZhSeoxpfZWGgomGY+4CIpzXCAiY qoT8In2sPeo8Br/a7WhoXfquQV2SRpSUqdiWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BXpjlmc8BgnoKhyk+dYrlmvVObrB6TUqgfrm7pQCa+u5B5YQvXujyZ/RuMYFZDZMeR WpBLfE6wfRsF6eep+O921FZk+P7HOHp5fXCMRyHcs6ELWld/uHIdS6MEJ4dBA3RthDke bJSAyRg/2Gh7ZbvK+Wnf6JNnLg6zlmf61VKlo= Received: by 10.204.154.142 with SMTP id o14mr488170bkw.125.1258276396970; Sun, 15 Nov 2009 01:13:16 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id 28sm5348389fkx.29.2009.11.15.01.13.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 01:13:15 -0800 (PST) Date: Sun, 15 Nov 2009 11:13:10 +0200 From: Gleb Kurtsou To: Pyun YongHyeon Message-ID: <20091115091309.GA1539@tops.skynet.lt> References: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> <20091111231426.GF15449@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20091111231426.GF15449@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mel Flynn , freebsd-current@freebsd.org Subject: Re: Possible regression with msk driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 09:13:18 -0000 On (11/11/2009 15:14), Pyun YongHyeon wrote: > On Wed, Nov 11, 2009 at 11:11:51PM +0100, Mel Flynn wrote: > > Hi, > > > > I just booted a box from 7.2-p4 to FreeBSD 8.0-PRERELEASE #0 r199185. It > > didn't ping, even though the interface was marked up and active. No traffic at > > all. > > > > The fix was to ifconfig msk0 down; ifconfig msk0 up. From then on, everything > > worked and still is: > > mskc0: port 0xe800-0xe8ff mem > > 0xf9efc000-0xf9efffff irq 16 at device 0.0 on pci3 > > msk0: on mskc0 > > msk0: Ethernet address: 00:1b:fc:e3:9b:6a > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > mskc0: [FILTER] > > > > mskc0@pci0:3:0:0: class=0x020000 card=0x826e1043 chip=0x436411ab > > rev=0x12 hdr=0x00 > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' > > class = network > > subclass = ethernet > > > > msk0: flags=8843 metric 0 mtu 1500 > > options=11a > > ether 00:1b:fc:xx:xx:xx > > inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.255 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > Now - this machine still had 7.x /etc/rc.d, but since ifconfig down/up fixed > > the problem I don't know if this is a likely suspect. > > > > Most likely it lost link state changes so I guess msk(4) still > think it has no established link. > Because there had been several problems with EC Ultra + 88E1149 I'm > not sure it's newly introduced regression though. There are some > changes in CURRENT. Would you try latest msk(4)/e1000phy(4) in > CURRENT? I think you can download the following files from CURRENT. > sys/dev/msk/if_msk.c > sys/dev/msk/if_mskreg.h > sys/dev/mii/e1000phy.c > sys/dev/mii/e1000phyreg.h I experience similar problem. After boot msk0 status is active, but I'm not able to send anything: % ping 172.21.21.21 PING 172.21.21.21 (172.21.21.21): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available After unplugging cable and putting it back everything works as expected: % ping 172.21.21.21 PING 172.21.21.21 (172.21.21.21): 56 data bytes 64 bytes from 172.21.21.21: icmp_seq=0 ttl=64 time=0.904 ms It is 100% reproducible, running recent current. % uname -a FreeBSD tops 9.0-CURRENT FreeBSD 9.0-CURRENT #17 r199274+c8076f9: Sat Nov 14 22:59:26 EET 2009 root@tops:/usr/obj/usr/freebsd-src/local/sys/TOPS amd64 % ifconfig msk0: flags=8843 metric 0 mtu 1500 options=11a ether * inet 172.21.21.22 netmask 0xfffffff8 broadcast 172.21.21.23 inet6 * prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active My hardware: mskc0@pci0:2:0:0: class=0x020000 card=0x902d104d chip=0x435311ab rev=0x15 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Gigabit (88E8039 - http://www.marvell.com/drivers/driverDis)' class = network subclass = ethernet Thanks. Gleb. > > If that does not work I'll send you a possible patch. > > > My onsite contact is unavailable right now, but if she gets back I will reboot > > the machine with the mergemaster'd rc.d to see if it's reproducible. > > I don't think it's related with rc.d scripts. > > > The machine is a dual core 64-bit running i386 SMP kernel with 4G memory and a > > few ACPI problems: > > ACPI APIC Table: > > ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found > > Package, expected Buffer 20090521 nspredef-1051 > > ACPI Warning: Incorrect checksum in table [OEMB] - 4E, should be 43 20090521 > > tbutils-275 > > > > With release around the door, I figured I'd get this out there, at the risk of > > posting a red herring. > > -- > > Mel > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 10:17:23 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 127E1106566B for ; Sun, 15 Nov 2009 10:17:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 943008FC12 for ; Sun, 15 Nov 2009 10:17:22 +0000 (UTC) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 48BBE55CD9B5; Sun, 15 Nov 2009 18:17:21 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id fICMgfeN5NT4; Sun, 15 Nov 2009 18:17:13 +0800 (CST) Received: from delta.delphij.net (c-69-181-136-105.hsd1.ca.comcast.net [69.181.136.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1ABDC55CD9AB; Sun, 15 Nov 2009 18:17:11 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=pC/Yhz782cth5W7K6CNyCeD1ZPoWiPL1YWOR51JaSk2O9afb/M33obkXk1jguZwak 1eqjy1Zy/WRWTMzB+iUrg== Message-ID: <4AFFD525.9030300@delphij.net> Date: Sun, 15 Nov 2009 02:17:09 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Thunderbird 2.0.0.23 (X11/20091022) MIME-Version: 1.0 To: d@delphij.net References: <200911090237.nA92b2m7005471__19254.880565177$1257734275$gmane$org@svn.freebsd.org> <867htvhygy.fsf@gmail.com> <4AFDDEA1.70900@delphij.net> <4AFDE27F.1070406@delphij.net> <4AFDEB70.5080807@delphij.net> <20091114130524.GA35115@stack.nl> <4AFF8BE9.9000003@delphij.net> In-Reply-To: <4AFF8BE9.9000003@delphij.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------070201060108000702020102" Cc: Anonymous , freebsd-current@FreeBSD.ORG, matthew green , Jilles Tjoelker Subject: Re: svn commit: r199066 - head/usr.bin/gzip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 10:17:23 -0000 This is a multi-part message in MIME format. --------------070201060108000702020102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Here is an updated version of the patch. I believe it fixed all raised issues. This version of patch employs a simple state bit that gets set when we hit a bzip2 end-of-stream symbol, and, if we got BZ_OK && end_of_file in the immediately subsequent cycle, consider it as Ok (turn the state machine back to BZ_STREAM_END so we exit normally). Each successful BZ_STREAM_END || BZ_OK case reset the cold state. Tested against empty bz2 file and pipe case. Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die --------------070201060108000702020102 Content-Type: text/plain; name="gzip.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gzip.diff" Index: unbzip2.c =================================================================== --- unbzip2.c (revision 199284) +++ unbzip2.c (working copy) @@ -36,7 +36,7 @@ static off_t unbzip2(int in, int out, char *pre, size_t prelen, off_t *bytes_in) { - int ret, end_of_file; + int ret, end_of_file, cold = 0; off_t bytes_out = 0; bz_stream bzs; static char *inbuf, *outbuf; @@ -86,8 +86,18 @@ switch (ret) { case BZ_STREAM_END: case BZ_OK: - if (ret == BZ_OK && end_of_file) - maybe_err("read"); + if (ret == BZ_OK && end_of_file) { + /* + * If we hit this after a stream end, consider + * it as the end of the whole file and don't + * bail out. + */ + if (cold == 1) + ret = BZ_STREAM_END; + else + maybe_errx("truncated file"); + } + cold = 0; if (!tflag && bzs.avail_out != BUFLEN) { ssize_t n; @@ -100,6 +110,7 @@ if (BZ2_bzDecompressEnd(&bzs) != BZ_OK || BZ2_bzDecompressInit(&bzs, 0, 0) != BZ_OK) maybe_errx("bzip2 re-init"); + cold = 1; ret = BZ_OK; } break; --------------070201060108000702020102-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 10:30:08 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F25DC106566C for ; Sun, 15 Nov 2009 10:30:08 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 723D48FC18 for ; Sun, 15 Nov 2009 10:30:08 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id nAFAU4Kc007785; Sun, 15 Nov 2009 10:30:04 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N9cMu-0001Or-5r; Sun, 15 Nov 2009 10:30:04 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id nAFAU3Gm084239; Sun, 15 Nov 2009 10:30:03 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id nAFAU3Om084231; Sun, 15 Nov 2009 10:30:03 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 15 Nov 2009 10:30:03 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Randy Bush In-Reply-To: Message-ID: <20091115102729.J81147@ury.york.ac.uk> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: FreeBSD current mailing list Subject: Re: buildworld - X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 10:30:09 -0000 On Sat, 14 Nov 2009, Randy Bush wrote: > amd64, cvsupped Nov 14 07:00 GMT > > ib/file/Magdir/troff,v /usr/src/lib/libmagic/../../contrib/file/Magdir/warc /usr/src/lib/libmagic/../../contrib/file/Magdir/pbm /usr/src/lib/libmagic/../../contrib/file/Magdir/gringotts /usr/src/lib/libmagic/../../contrib/file/Magdir/softquad,v /usr/src/lib/libmagic/../../contrib/file/Magdir/luks,v /usr/src/lib/libmagic/../../contrib/file/Magdir/database /usr/src/lib/libmagic/../../contrib/file/Magdir/spec /usr/src/lib/libmagic/../../contrib/file/Magdir/amigaos /usr/src/lib/libmagic/../../contrib/file/Magdir/pdp /usr/src/lib/libmagic/../../contrib/file/Magdir/ctags /usr/src/lib/libmagic/../../contrib/file/Magdir/pdf,v /usr/src/lib/libmagic/../../contrib/file/Magdir/palm,v /usr/src/lib/libmagic/../../contrib/file/Magdir/smalltalk,v /usr/src/lib/libmagic/../../contrib/file/Magdir/sgml,v /usr/src/lib/libmagic/../../contrib/file/Magdir/pulsar /usr/src/lib/libmagic/../../contrib/file/Magdir/dump,v /usr/src/lib/libmagic/../../contrib/file/Magdir/blender /usr/src/lib/libmagic/../! ../ > contrib/file/Magdir/mathcad /usr/src/lib/libmagic/../../contrib/file/Magdir/fortran,v /usr/src/lib/libmagic/../../contrib/file/Magdir/mime,v /usr/src/lib/libmagic/../../contrib/file/Magdir/linux,v /usr/src/lib/libmagic/../../contrib/file/Magdir/basis /usr/src/lib/libmagic/../../contrib/file/Magdir/vmware,v /usr/src/lib/libmagic/../../contrib/file/Magdir/epoc /usr/src/lib/libmagic/../../contrib/file/Magdir/sequent,v /usr/src/lib/libmagic/../../contrib/file/Magdir/sendmail /usr/src/lib/libmagic/../../contrib/file/Magdir/alliant /usr/src/lib/libmagic/../../contrib/file/Magdir/blit,v /usr/src/lib/libmagic/../../contrib/file/Magdir/zilog,v /usr/src/lib/libmagic/../../contrib/file/Magdir/impulse,v > magic > ./mkmagic magic Somehow you have ended up with the ,v files here, rather than the checked out files. Compare the contents of this directory to what should be in it: http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/file/Magdir/ What is the date on the ,v files there? How did you cvsup this? It could be a problem with the specific cvsup server you have chosen, what happens if you delete /usr/src/contrib/file/Magdir/* and recvsup from the same server? Or a different server? Gavin From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 10:31:35 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 345B21065692; Sun, 15 Nov 2009 10:31:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4638FC1B; Sun, 15 Nov 2009 10:31:35 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N9cOM-0007ZB-OQ; Sun, 15 Nov 2009 10:31:34 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 3F37C2C0E239; Sun, 15 Nov 2009 19:31:34 +0900 (JST) Date: Sun, 15 Nov 2009 19:31:34 +0900 Message-ID: From: Randy Bush To: Gavin Atkinson In-Reply-To: <20091115102729.J81147@ury.york.ac.uk> References: <20091115102729.J81147@ury.york.ac.uk> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD current mailing list Subject: Re: buildworld - X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 10:31:35 -0000 > Somehow you have ended up with the ,v files here, rather than the checked > out files. ack. found it. no tag in cvsup. idiot. randy From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 11:58:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E38FE1065693 for ; Sun, 15 Nov 2009 11:58:05 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 99F5F8FC08 for ; Sun, 15 Nov 2009 11:58:05 +0000 (UTC) Received: from [95.27.65.70] (port=40136 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N9dk2-0001MJ-V7 for current@freebsd.org; Sun, 15 Nov 2009 14:58:02 +0300 Message-ID: <4AFFECCA.5010706@lissyara.su> Date: Sun, 15 Nov 2009 14:58:02 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------020101090400020907090505" X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: Additional features for /etc/rc.d/fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 11:58:06 -0000 This is a multi-part message in MIME format. --------------020101090400020907090505 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit hi! I have many servers with using gjournal. Sometimes, after unexpected reboot, booting OK, but, filesystem have error. If I run fsck -y manually - all OK. But, for some servers I do not have physical access, and check '/' and some another filesystems - impossible. I modify /etc/rc.d/fsck, and add 2 new options to rc.conf HP$ grep fsck /etc/rc.conf force_fsck="YES" force_fsck_list="/" HP$ It's required background_fsck="NO" in rc.conf May be include it in source three? Very useful. --------------020101090400020907090505 Content-Type: text/plain; name="fsck.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fsck.diff" LS0tIC9yb290L2ZzY2sJMjAwOS0xMS0xNSAxNDoxMzoyNS4wMDAwMDAwMDAgKzAzMDAKKysr IC9ldGMvcmMuZC9mc2NrCTIwMDktMTEtMTUgMTQ6NDI6MzIuMDAwMDAwMDAwICswMzAwCkBA IC0yNyw3ICsyNywxNiBAQAogCQlpZiBjaGVja3llc25vIGJhY2tncm91bmRfZnNjazsgdGhl bgogCQkJZnNjayAtRiAtcAogCQllbHNlCi0JCQlmc2NrIC1wCisJCQlpZiBjaGVja3llc25v IGZvcmNlX2ZzY2s7IHRoZW4KKwkJCQllY2hvICJGb3JjZSBmc2NrIGVuYWJsZWQiCisJCQkJ Zm9yIGZpbGVzeXN0ZW0gaW4gJHtmb3JjZV9mc2NrX2xpc3R9CisJCQkJZG8KKwkJCQkJZWNo byAiRm9yY2UgY2hlY2sgJGZpbGVzeXN0ZW0iCisJCQkJCWZzY2sgLXkgJGZpbGVzeXN0ZW0K KwkJCQlkb25lCisJCQllbHNlCisJCQkJZnNjayAtcAorCQkJZmkKIAkJZmkKIAogCQljYXNl ICQ/IGluCg== --------------020101090400020907090505-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 17:34:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 144311065672 for ; Sun, 15 Nov 2009 17:34:38 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CEC408FC08 for ; Sun, 15 Nov 2009 17:34:37 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id A76D1615C for ; Sun, 15 Nov 2009 12:34:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1258306476; bh=PeTyY2HxTgkun+Svf/NBrzRUY65wDBhsFx6jesOOI90=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=UWxL0dOjDs4cYsHWiXZUY9Ov1Tq3WUHTdooUrpKHqO+uV5mmGEg6vYP30nCDr9g+c CkAv9y5GU7C/84jdEC1kIDMeGwySn+YRGovVvFhd6Vkh+DeniuSxzTNGcxPNwNC DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=leY0cyaQREJaZEAoKKgWLPjZ2fQglOr+DaidK9JQBd7YrWn9t2hoQcvR4BptaKNnK BeH2DRkXnkkzujeJWr2waCfVBLEsQshwcB5FtLWfBxibPkVZdEoiGg5Xg/ERdcU Message-ID: <4B003BA6.2020803@protected-networks.net> Date: Sun, 15 Nov 2009 12:34:30 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: freebsd-current X-Enigmail-Version: 0.96.0 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: switching from legacy to ahci on intel ICH-7M? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 17:34:38 -0000 My current laptop has an AHCI-capable disk controller and SATA disk but, it appears, the manufacturer has no interest in implementing AHCI in the BIOS. Is there an example of how one might (re-)initialize the controller to take advantage of AHCI and the disk's NCQ capabilites somewhere? Michael From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 18:44:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1491065672 for ; Sun, 15 Nov 2009 18:44:56 +0000 (UTC) (envelope-from neuhauser@sigpipe.cz) Received: from isis.sigpipe.cz (fw.sigpipe.cz [213.192.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAF58FC16 for ; Sun, 15 Nov 2009 18:44:52 +0000 (UTC) Received: by isis.sigpipe.cz (Postfix, from userid 1001) id 263A8147DF3; Sun, 15 Nov 2009 19:38:11 +0100 (CET) Date: Sun, 15 Nov 2009 19:38:11 +0100 From: Roman Neuhauser To: freebsd-current@freebsd.org Message-ID: <20091115183811.GK54137@isis.sigpipe.cz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sun, 15 Nov 2009 19:19:16 +0000 Subject: wpi(4) panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 18:44:56 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I have an Intel 3945ABG (wpi(4)). The driver has been pretty flaky through 7.x, and is the primary suspect in the two panics I had since update to 9-CURRENT two weeks ago (uname says Sat Oct 31 15:38:29 CET 2009, sources csupped a few hours earlier). when it panicked today, the computer was unattended, doing +/- nothing. core.txt.N files attached, let me know if you need anything else. --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="core.txt.6" sachmet.sigpipe.cz dumped core - see /var/crash/vmcore.6 Mon Nov 2 10:10:41 CET 2009 FreeBSD sachmet.sigpipe.cz 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Sat Oct 31 15:38:29 CET 2009 root@sachmet.sigpipe.cz:/usr/obj/usr/src/sys/SACHMET i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <118>. <118>Writing entropy file: <118>. <118>Terminated <118>. <118>Nov 2 08:12:03 sachmet syslogd: exiting on signal 15 wpi_newstate: RUN -> INIT flags 0x0 <5>wlan0: link state changed to DOWN wpi_newstate: INIT -> INIT flags 0x0 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1934 fault code = supervisor write, page not present instruction pointer = 0x20:0xc09ef954 stack pointer = 0x28:0xe4125bec frame pointer = 0x28:0xe4125c98 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 = 11 (irq16: wpi0 uhci3) trap number = 12 panic: page fault cpuid = 1 Uptime: 16h28m30s Physical memory: 1006 MB Dumping 203 MB:panic: bufwrite: buffer is not busy??? cpuid = 1 panic: bufwrite: buffer is not busy??? cpuid = 1 panic: bufwrite: buffer is not busy??? cpuid = 1 188 172 156 140 124 108 92 76 60 44 28 12 Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from /boot/kernel/if_wpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_wpi.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from /boot/kernel/wpifw.ko.symbols...done. done. Loaded symbols for /boot/kernel/wpifw.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc05cb3d7 in boot (howto=16644) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc05cb6a9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc07c5fac in trap_fatal (frame=0xe4125bac, eva=6452) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc07c6210 in trap_pfault (frame=0xe4125bac, usermode=0, eva=6452) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc07c6bb9 in trap (frame=0xe4125bac) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc07a9ebb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc09ef954 in wpi_intr (arg=0xc3dfd000) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:1582 #8 0xc05a4cfb in intr_event_execute_handlers (p=0xc3d10aa0, ie=0xc3d50300) at /usr/src/sys/kern/kern_intr.c:1220 #9 0xc05a640b in ithread_loop (arg=0xc3e40be0) at /usr/src/sys/kern/kern_intr.c:1233 #10 0xc05a2a81 in fork_exit (callout=0xc05a63a0 , arg=0xc3e40be0, frame=0xe4125d38) at /usr/src/sys/kern/kern_fork.c:843 #11 0xc07a9f30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -68 0 0 0 - DLs ?? -8107895:-35.55 [kernel] 0 1 0 0 96 0 2912 0 - RLs ?? 12707065:28.00 [init] 0 2 0 0 -8 0 0 0 - DL ?? -34491423:-27.55 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? -9153764:-25.55 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 34419684:59.55 [g_down] 0 5 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 6 0 0 44 0 0 0 psleep DL ?? 8189465:32.00 [pagedaemon 0 7 0 0 -64 0 0 0 psleep DL ?? 1739481:06.00 [vmdaemon] 0 8 0 0 76 0 0 0 pgzero DL ?? 210274:10.00 [pagezero] 0 9 0 0 44 0 0 0 psleep DL ?? 34426174:47.55 [bufdaemon] 0 10 0 0 171 0 0 0 - RL ?? 34217768:55.55 [idle] 0 11 0 0 -60 0 0 0 - WL ?? -4151562:-11.55 [intr] 0 12 0 0 -16 0 0 0 - DL ?? 22715422:00.00 [yarrow] 0 13 0 0 -64 0 0 0 - DL ?? 13028256:32.00 [usb] 0 14 0 0 -16 0 0 0 tzpoll DL ?? -25795375:-37.55 [acpi_therm 0 15 0 0 -16 0 0 0 coolin DL ?? 11304225:30.00 [acpi_cooli 0 16 0 0 45 0 0 0 vlruwt DL ?? -18988111:-37.55 [vnlru] 0 17 0 0 44 0 0 0 - RL ?? 3877923:50.00 [syncer] 0 18 0 0 44 0 0 0 - RL ?? 28648949:54.00 [softdepflu 0 19 0 0 -64 0 0 0 flowcl DL ?? 20315016:24.00 [flowcleane ------------------------------------------------------------------------ vmstat -s 48096639 cpu context switches 2785774 device interrupts 10827604 software interrupts 78351877 traps 112978393 system calls 19 kernel threads created 314437 fork() calls 105250 vfork() calls 4 rfork() calls 3481 swap pager pageins 11497 swap pager pages paged in 3714 swap pager pageouts 13570 swap pager pages paged out 25740 vnode pager pageins 131780 vnode pager pages paged in 6 vnode pager pageouts 96 vnode pager pages paged out 198 page daemon wakeups 4021800 pages examined by the page daemon 26840 pages reactivated 8785790 copy-on-write faults 6398 copy-on-write optimized faults 53687580 zero fill pages zeroed 1296766 zero fill pages prezeroed 6962 intransit blocking page faults 73596356 total VM faults taken 0 pages affected by kernel thread creation 59579742 pages affected by fork() 17116341 pages affected by vfork() 548 pages affected by rfork() 1021148 pages cached 70634066 pages freed 0 pages freed by daemon 42373645 pages freed by exiting processes 11503 pages active 124941 pages inactive 7369 pages in VM cache 42989 pages wired down 65977 pages free 4096 bytes per page 87962482 total name lookups cache hits (86% pos + 10% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) sigio 0 0K - 3 32 filedesc_to_leader 0 0K - 6 32 filedesc 20 5K - 419751 16,32,256,512,1024 kenv 84 7K - 92 16,32,64,128,4096 kqueue 0 0K - 1126 128,256,1024 ad_driver 1 1K - 1 32 proc-args 1 1K - 315969 16,32,64,128,256 ar_driver 0 0K - 6 512,2048 ithread 71 6K - 72 16,64,128 acd_driver 1 2K - 1 2048 KTRACE 100 13K - 100 128 linker 125 370K - 236 16,32,256,1024,4096 lockf 2 1K - 4990 32,64 acpisem 59 8K - 59 64,128 temp 35 234K - 3067147 16,32,64,128,256,512,1024,2048,4096 devbuf 3660 5418K - 3679 16,32,64,128,256,512,1024,2048,4096 module 259 17K - 259 64,128 mtx_pool 2 8K - 2 4096 osd 2 1K - 2 16,32 CAM periph 2 1K - 12 16,32,64,128 subproc 285 147K - 419972 256,4096 proc 2 8K - 2 4096 session 1 1K - 368 64 pgrp 1 1K - 422 64 cred 18 2K - 6715484 64,128 uidinfo 3 2K - 319 64,1024 plimit 1 1K - 11068 256 sysctltmp 0 0K - 34738 16,32,64,128,256 sysctloid 3585 110K - 3679 16,32,64,128 sysctl 0 0K - 371520 16,32,64 callout 1 256K - 1 umtx 392 25K - 406 64 p1003.1b 1 1K - 1 16 SWAP 2 277K - 2 64 bus-sc 76 132K - 2692 16,32,64,128,256,512,1024,2048,4096 bus 810 41K - 6082 16,32,64,128,512,1024 devstat 6 13K - 6 16,4096 eventhandler 70 4K - 70 32,64,128 kobj 165 330K - 187 2048 Per-cpu 1 1K - 1 16 CAM dev queue 1 1K - 1 64 acpidev 94 3K - 94 32 rman 161 10K - 565 16,32,64 sbuf 0 0K - 711 16,32,64,128,256,512,1024,2048,4096 entropy 1024 64K - 1024 64 CAM queue 3 1K - 7 16 stack 0 0K - 2 128 taskqueue 13 1K - 13 16,64 Unitno 18 1K - 771 16,64 iov 0 0K - 299249 16,64,128,256,512 select 72 5K - 72 64 ioctlops 0 0K - 8336720 16,32,64,128,256,512,1024,2048,4096 msg 4 25K - 4 1024,4096 sem 4 36K - 4 4096 shm 1 12K - 20 1024 tty 17 9K - 24 512,1024 pts 0 0K - 5 128 mbuf_tag 0 0K - 85 32 ksem 1 4K - 1 4096 shmfd 1 4K - 1 4096 pcb 7 7K - 933 16,512,1024,2048 soname 0 0K - 60891 16,32,64,128 acl 0 0K - 13668 4096 biobuf 7 14K - 11178 2048 vfscache 1 512K - 1 cl_savebuf 0 0K - 17080 32,64 vfs_hash 1 256K - 1 vnodes 2 1K - 6 32,128 USBdev 40 11K - 115 32,128,256,1024 vnodemarker 0 0K - 11492 512 mount 91 4K - 139 16,32,64,128,256 BPF 4 1K - 14 16,64,128,256,4096 ether_multi 11 1K - 32 16,32,64 ifaddr 138 8K - 140 16,32,256,2048 ifnet 5 5K - 5 64,1024 clone 5 20K - 5 4096 arpcom 2 1K - 2 16 lltable 39 6K - 44 128,256 USB 35 6K - 35 16,32,64,1024 CAM SIM 1 1K - 1 128 pci_link 16 2K - 16 64,128 acpi_perf 2 1K - 2 128 DEVFS1 85 22K - 96 256 DEVFS3 105 14K - 117 128 routetbl 44 258K - 166 16,32,64,128,256,512 80211vap 1 4K - 1 4096 80211crypto 0 0K - 4 512 80211com 1 8K - 1 80211nodeie 0 0K - 6 32,64,256 80211node 1 8K - 4 80211scan 2 4K - 4 256,2048 igmp 4 1K - 4 128 DEVFS 14 1K - 15 16,64 DEVFSP 0 0K - 78 32 in_multi 2 1K - 4 128 hostcache 1 16K - 1 syncache 1 72K - 1 NFS FHA 1 1K - 1 1024 rpc 2 5K - 2 128,4096 savedino 0 0K - 48587 256 newdirblk 0 0K - 742 32 dirrem 16 1K - 241220 32 mkdir 0 0K - 22106 32 diradd 2 1K - 193691 64 freefile 15 1K - 222342 32 freeblks 9 3K - 206443 256 freefrag 1 1K - 138699 32 allocindir 0 0K - 311154 64 indirdep 0 0K - 3581 32 allocdirect 3 1K - 495915 128 bmsafemap 1 1K - 3512 64 newblk 1 1K - 807070 64,256 inodedep 39 261K - 373324 128 pagedep 3 33K - 28024 64 ufs_dirhash 398 180K - 28024 16,32,64,128,256,512,1024,4096 ufs_mount 9 27K - 9 256,2048,4096 UMAHash 2 5K - 6 256,512,1024,2048,4096 vm_pgdata 2 65K - 2 64 atkbddev 2 1K - 2 32 pfs_nodes 70 9K - 70 128 pfs_vncache 1 1K - 53 32 apmdev 1 1K - 1 64 GEOM 93 41K - 536 16,32,64,128,512,1024,2048 agp 1 1K - 8 16,64 isadev 9 1K - 9 64 io_apic 1 1K - 1 1024 memdesc 1 4K - 6 32,4096 msi 1 1K - 1 64 nexusdev 4 1K - 4 16 acpica 2182 109K - 591986 16,32,64,128,256,512,1024 acpitask 1 1K - 1 1024 CAM XPT 12 2K - 33 16,32,64,1024 ata_generic 2 2K - 58374 16,64,128,1024 cdev 11 2K - 11 128 mixer 2 8K - 2 4096 feeder 14 1K - 17 16,64 hdac 8 10K - 8 64,256,512,1024,2048,4096 futex wp 0 0K - 137 16 futex 0 0K - 219 64 linux 12 1K - 24 16,32,64 drm_ctxbitmap 1 4K - 1 4096 drm_agplists 1 1K - 1 64 drm_buflists 0 0K - 2 32 drm_files 0 0K - 1 64 drm_maps 1 1K - 8 64 drm_driver 4 5K - 5 16,32,64,256,4096 drm_sarea 1 1K - 1 16 drm_dma 1 1K - 1 16 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 77, 13, 77, 0 UMA Zones: 888, 0, 77, 3, 77, 0 UMA Slabs: 284, 0, 958, 596, 234034, 0 UMA RCntSlabs: 544, 0, 456, 69, 1725, 0 UMA Hash: 128, 0, 1, 29, 3, 0 16 Bucket: 76, 0, 9, 41, 128, 0 32 Bucket: 140, 0, 45, 11, 270, 0 64 Bucket: 268, 0, 67, 3, 309, 20 128 Bucket: 524, 0, 363, 1, 14267, 58446 VM OBJECT: 136, 0, 44612, 10575, 6565086, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 72, 56286, 469, 1280, 532616, 0 MAP ENTRY: 72, 0, 7, 2908, 12408553, 0 DP fakepg: 72, 0, 0, 65720, 65633, 0 SG fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 228, 107, 228, 0 16: 16, 0, 2793, 861, 7806533, 0 32: 32, 0, 2839, 6201, 2686326, 0 64: 64, 0, 4572, 7523, 5243316, 0 128: 128, 0, 2489, 3331, 4357273, 0 256: 256, 0, 789, 2526, 723266, 0 512: 512, 0, 401, 679, 390805, 0 1024: 1024, 0, 41, 199, 1986846, 0 2048: 2048, 0, 207, 387, 40644, 0 4096: 4096, 0, 88, 146, 448208, 0 Files: 56, 0, 0, 737, 10971241, 0 TURNSTILE: 72, 0, 393, 57, 407, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 680, 0, 19, 245, 419710, 0 THREAD: 560, 0, 303, 89, 666, 0 SLEEPQUEUE: 32, 0, 393, 79, 407, 0 VMSPACE: 232, 0, 1, 271, 419689, 0 cpuset: 40, 0, 2, 182, 2, 0 mbuf_packet: 256, 0, 64, 452, 30044, 0 mbuf: 256, 0, 65, 579, 1025545, 0 mbuf_cluster: 2048, 25600, 256, 246, 1280, 0 mbuf_jumbo_page: 4096, 12800, 64, 141, 706850, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 g_bio: 140, 0, 12, 1724, 2334705, 0 ttyinq: 152, 0, 0, 520, 855, 0 ttyoutq: 256, 0, 0, 225, 435, 0 ata_request: 200, 0, 4, 546, 791229, 0 ata_composite: 180, 0, 0, 0, 0, 0 VNODE: 268, 0, 61296, 3244, 1523000, 0 VNODEPOLL: 60, 0, 154, 161, 155, 0 S VFS Cache: 72, 0, 50389, 20366, 2614562, 0 L VFS Cache: 292, 0, 14871, 893, 68058, 0 NAMEI: 1024, 0, 0, 80, 21743391, 0 NFSMOUNT: 520, 0, 0, 0, 0, 0 NFSNODE: 464, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 144, 172, 19567, 0 pipe: 392, 0, 0, 110, 157149, 0 ksiginfo: 80, 0, 248, 40, 254, 0 itimer: 220, 0, 0, 0, 0, 0 KNOTE: 72, 0, 0, 265, 1246, 0 socket: 412, 25605, 0, 171, 41288, 0 ipq: 32, 904, 0, 0, 0, 0 udp_inpcb: 220, 25614, 0, 90, 40308, 0 udpcb: 8, 25781, 0, 406, 40308, 0 tcp_inpcb: 220, 25614, 1, 107, 383, 0 tcpcb: 632, 25602, 0, 60, 383, 0 tcptw: 52, 5184, 1, 143, 55, 0 syncache: 112, 15365, 0, 0, 0, 0 hostcache: 76, 15400, 4, 96, 51, 0 tcpreass: 20, 1690, 0, 338, 4014, 0 sackhole: 20, 0, 0, 0, 0, 0 ripcb: 220, 25614, 0, 54, 4, 0 unpcb: 172, 25622, 0, 115, 582, 0 rtentry: 108, 0, 3, 105, 8, 0 selfd: 28, 0, 71, 437, 25809285, 0 ip4flow: 40, 4140, 5, 271, 853, 0 ip6flow: 64, 4118, 0, 0, 0, 0 SWAPMETA: 276, 121576, 3, 1411, 3357, 0 Mountpoints: 644, 0, 6, 12, 6, 0 FFS inode: 116, 0, 61251, 3272, 1522797, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 61251, 3257, 1522783, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 13557 44 irq9: acpi0 269148 873 irq12: psm0 28164 91 irq14: ata0 466975 1516 irq16: wpi0 uhci3 1424199 4624 irq19: uhci1+ 583703 1895 irq20: fxp0 2 0 cpu0: timer 118617843 385122 irq256: hdac0 18 0 cpu1: timer 118617412 385121 Total 240021021 779289 ------------------------------------------------------------------------ pstat -T 0/12328 files 0M/2003M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ad4s1b 4104080 32 4104048 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics iostat: kvm_getcptime: invalid address (0x0) iostat: disabling CPU time statistics ad4 KB/t tps MB/s 17.28 1892 31.93 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 67108864 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 16384 (max amount of shared memory in pages) seminfo: semmap: 700 (# of entries in semaphore map) semmni: 256 (# of semaphore identifiers) semmns: 700 (# of semaphores in system) semmnu: 30 (# of undo structures in system) semmsl: 60 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 10 (max # of undo entries per process) semusz: 136 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 30708 packets sent 1067 data packets (649764 bytes) 49 data packets (18452 bytes) retransmitted 4 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 17589 ack-only packets (820 delayed) 0 URG only packets 0 window probe packets 11253 window update packets 750 control packets 39987 packets received 1707 acks (for 644762 bytes) 456 duplicate acks 0 acks for unsent data 33790 packets (46880747 bytes) received in-sequence 147 completely duplicate packets (180055 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 4014 out-of-order packets (5692207 bytes) 5 packets (5 bytes) of data after window 5 window probes 0 window update packets 7 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 773 discarded due to memory problems 381 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 380 connections established (including accepts) 382 connections closed (including 16 drops) 215 connections updated cached RTT on close 217 connections updated cached RTT variance on close 65 connections updated cached ssthresh on close 0 embryonic connections dropped 1687 segments updated rtt (of 1757 attempts) 66 retransmit timeouts 2 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 32891 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 11 SACK options (SACK blocks) received 4468 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 1158 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 629 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 529 delivered 541 datagrams output 0 times multicast source filter matched ip: 69140 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 69027 packets for this host 113 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 60452 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 22 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 27882 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 113 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 39 ARP requests sent 44 ARP replies sent 217 ARP requests received 35 ARP replies received 252 ARP packets received 2 total packets dropped due to no ARP entry 37 ARP entrys timed out 0 Duplicate IPs seen ------------------------------------------------------------------------ netstat -m 129/1031/1160 mbufs in use (current/cache/total) 18446744073709551420/698/502/25600 mbuf clusters in use (current/cache/total/max) 64/452 mbuf+clusters out of packet secondary zone in use (current/cache) 64/141/205/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 18014398509481880K/2217K/2114K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop wpi0* 2290 00:19:d2:3b:a7:ca 0 2002 56622 4061 0 0 fxp0 1500 00:16:36:e2:a4:ab 0 0 0 0 0 0 lo0 16384 0 0 0 0 0 0 lo0 16384 your-net localhost 0 - 0 - - - wlan0 1500 00:19:d2:3b:a7:ca 69668 0 60519 2 0 0 wlan0 1500 10.9.9.0 10.9.9.101 6973 - 7003 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.9.9.1 UGS 3 6913 wlan0 127.0.0.1 link#3 UH 0 0 lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c61433a8 tcp4 0 0 10.9.9.101.11786 74.125.87.101.80 TIME_WAIT ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root init 1 root / 2 drwxr-xr-x 512 r root init 1 wd / 2 drwxr-xr-x 512 r root init 1 text / 18284 -r-xr-xr-x 666380 r root kernel 0 root / 2 drwxr-xr-x 512 r root kernel 0 wd / 2 drwxr-xr-x 512 r ------------------------------------------------------------------------ dmesg tem=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^IFNET Testing type=LINK_DOWN against ^ATTACH Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=mdctl' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=mdctl Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.1.0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/0.1.0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen0.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ugen0.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/1.1.0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/1.1.0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ugen1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/2.1.0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/2.1.0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen2.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ugen2.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.1.0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/3.1.0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen3.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ugen3.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/4.1.0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/4.1.0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen4.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ugen4.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/0.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen0.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci0' Pushing table setting device-name=ugen0.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen0.1 against ^ed50 Testing device-name=ugen0.1 against ^ubt[0-9]+ Testing device-name=ugen0.1 against ^ukbd0 Testing device-name=ugen0.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen0.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen0.1 against 0x80 Testing device-name=ugen0.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/1.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/1.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen1.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci1' Pushing table setting device-name=ugen1.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen1.1 against ^ed50 Testing device-name=ugen1.1 against ^ubt[0-9]+ Testing device-name=ugen1.1 against ^ukbd0 Testing device-name=ugen1.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen1.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen1.1 against 0x80 Testing device-name=ugen1.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/2.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/2.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen2.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci2' Pushing table setting device-name=ugen2.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen2.1 against ^ed50 Testing device-name=ugen2.1 against ^ubt[0-9]+ Testing device-name=ugen2.1 against ^ukbd0 Testing device-name=ugen2.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen2.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen2.1 against 0x80 Testing device-name=ugen2.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/3.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen3.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci3' Pushing table setting device-name=ugen3.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen3.1 against ^ed50 Testing device-name=ugen3.1 against ^ubt[0-9]+ Testing device-name=ugen3.1 against ^ukbd0 Testing device-name=ugen3.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen3.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen3.1 against 0x80 Testing device-name=ugen3.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/4.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/4.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen4.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on ehci0' Pushing table setting device-name=ugen4.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen4.1 against ^ed50 Testing device-name=ugen4.1 against ^ubt[0-9]+ Testing device-name=ugen4.1 against ^ukbd0 Testing device-name=ugen4.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen4.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen4.1 against 0x80 Testing device-name=ugen4.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=ACPI subsystem=ACAD type=\\_SB_.ACAD notify=0x01' Pushing table setting system=ACPI setting subsystem=ACAD setting type=\\_SB_.ACAD setting notify=0x01 Processing notify event Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^CMBAT Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^Resume Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^Suspend Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^Thermal Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^ACAD Executing '/etc/rc.d/power_profile 0x01' Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=devstat' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=devstat Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+acd0 at on ata0' Pushing table setting device-name=acd0 Processing attach event Testing device-name=acd0 against ^ed50 Testing device-name=acd0 against ^ubt[0-9]+ Testing device-name=acd0 against ^ukbd0 Testing device-name=acd0 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=acd0 against ^ugen[0-9]+ Testing media type of acd0 against 0x80 Testing device-name=acd0 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=ACPI subsystem=Thermal type=\\_TZ_.TZ00 notify=0x80' Pushing table setting system=ACPI setting subsystem=Thermal setting type=\\_TZ_.TZ00 setting notify=0x80 Processing notify event Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^CMBAT Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^Resume Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^Suspend Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^Thermal Testing notify=0x80 against ^0xcc Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^ACAD Testing system=ACPI against ^IFNET Testing system=ACPI against ^IFNET Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^ASUS Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^ASUS Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^ASUS Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^ASUS-Eee Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^ASUS-Eee Testing system=ACPI against ^ACPI Testing subsystem=Thermal against ^ASUS-Eee Testing system=ACPI against ^IFNET Popping table Processing event '!system=ACPI subsystem=CMBAT type=\\_SB_.BAT1 notify=0x80' Pushing table setting system=ACPI setting subsystem=CMBAT setting type=\\_SB_.BAT1 setting notify=0x80 Processing notify event Testing system=ACPI against ^ACPI Testing subsystem=CMBAT against ^CMBAT Executing 'logger -p kern.info ACPI.CMBAT: 0x80' Popping table Processing event '!system=ACPI subsystem=CMBAT type=\\_SB_.BAT1 notify=0x00' Pushing table setting system=ACPI setting subsystem=CMBAT setting type=\\_SB_.BAT1 setting notify=0x00 Processing notify event Testing system=ACPI against ^ACPI Testing subsystem=CMBAT against ^CMBAT Executing 'logger -p kern.info ACPI.CMBAT: 0x00' Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=acd0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=acd0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+subdisk4 at on ad4' Pushing table setting device-name=subdisk4 Processing attach event Testing device-name=subdisk4 against ^ed50 Testing device-name=subdisk4 against ^ubt[0-9]+ Testing device-name=subdisk4 against ^ukbd0 Testing device-name=subdisk4 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=subdisk4 against ^ugen[0-9]+ Testing media type of subdisk4 against 0x80 Testing device-name=subdisk4 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+ad4 at on ata2' Pushing table setting device-name=ad4 Processing attach event Testing device-name=ad4 against ^ed50 Testing device-name=ad4 against ^ubt[0-9]+ Testing device-name=ad4 against ^ukbd0 Testing device-name=ad4 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=ad4 against ^ugen[0-9]+ Testing media type of ad4 against 0x80 Testing device-name=ad4 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=xpt0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=xpt0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=mixer0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=mixer0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+pcm0 at on hdac0' Pushing table setting device-name=pcm0 Processing attach event Testing device-name=pcm0 against ^ed50 Testing device-name=pcm0 against ^ubt[0-9]+ Testing device-name=pcm0 against ^ukbd0 Testing device-name=pcm0 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=pcm0 against ^ugen[0-9]+ Testing media type of pcm0 against 0x80 Testing device-name=pcm0 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=mixer1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=mixer1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+pcm1 at on hdac0' Pushing table setting device-name=pcm1 Processing attach event Testing device-name=pcm1 against ^ed50 Testing device-name=pcm1 against ^ubt[0-9]+ Testing device-name=pcm1 against ^ukbd0 Testing device-name=pcm1 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=pcm1 against ^ugen[0-9]+ Testing media type of pcm1 against 0x80 Testing device-name=pcm1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub1 at on usbus1' Pushing table setting device-name=uhub1 Processing attach event Testing device-name=uhub1 against ^ed50 Testing device-name=uhub1 against ^ubt[0-9]+ Testing device-name=uhub1 against ^ukbd0 Testing device-name=uhub1 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub1 against ^ugen[0-9]+ Testing media type of uhub1 against 0x80 Testing device-name=uhub1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub0 at on usbus0' Pushing table setting device-name=uhub0 Processing attach event Testing device-name=uhub0 against ^ed50 Testing device-name=uhub0 against ^ubt[0-9]+ Testing device-name=uhub0 against ^ukbd0 Testing device-name=uhub0 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub0 against ^ugen[0-9]+ Testing media type of uhub0 against 0x80 Testing device-name=uhub0 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub2 at on usbus2' Pushing table setting device-name=uhub2 Processing attach event Testing device-name=uhub2 against ^ed50 Testing device-name=uhub2 against ^ubt[0-9]+ Testing device-name=uhub2 against ^ukbd0 Testing device-name=uhub2 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub2 against ^ugen[0-9]+ Testing media type of uhub2 against 0x80 Testing device-name=uhub2 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub3 at on usbus3' Pushing table setting device-name=uhub3 Processing attach event Testing device-name=uhub3 against ^ed50 Testing device-name=uhub3 against ^ubt[0-9]+ Testing device-name=uhub3 against ^ukbd0 Testing device-name=uhub3 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub3 against ^ugen[0-9]+ Testing media type of uhub3 against 0x80 Testing device-name=uhub3 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s2' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s2 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1a' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1a Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1b' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1b Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1d' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1d Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s2d' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s2d Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214f' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214f Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214fd' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214fd Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+uhub4 at on usbus4' Pushing table setting device-name=uhub4 Processing attach event Testing device-name=uhub4 against ^ed50 Testing device-name=uhub4 against ^ubt[0-9]+ Testing device-name=uhub4 against ^ukbd0 Testing device-name=uhub4 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub4 against ^ugen[0-9]+ Testing media type of uhub4 against 0x80 Testing device-name=uhub4 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/46615685b1e3214f' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/46615685b1e3214f Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/46615685b1e3214fd' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/46615685b1e3214fd Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214f' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214f Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214fd' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214fd Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=IFNET subsystem=wlan0 type=ATTACH' Pushing table setting system=IFNET setting subsystem=wlan0 setting type=ATTACH Processing notify event Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^IFNET Testing type=ATTACH against ^LINK_UP Testing system=IFNET against ^IFNET Testing type=ATTACH against ^LINK_UP Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^IFNET Testing type=ATTACH against ^ATTACH Executing '/etc/pccard_ether wlan0 start' Popping table Calling daemon ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat /usr/local/lib/gcc44 /usr/local/lib/gcc45 /usr/local/lib/nss /usr/local/lib/qt4 a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files . Starting syslogd. No core dumps found. Additional ABI support: linux . Clearing /tmp (X related). Updating motd: . Starting powerd. Starting default moused . Starting dbus. Starting hald. Configuring syscons: keymap blanktime . Starting sshd. Starting cron. Starting inetd. Sun Nov 1 15:43:45 CET 2009 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xc0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] pid 43579 (as), uid 0: exited on signal 11 (core dumped) pid 43596 (as), uid 0: exited on signal 11 (core dumped) wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 microcode alive notification version 10e02 alive 1 microcode alive notification version 10e02 alive 1 wpi_newstate: INIT -> SCAN flags 0x0 wpi_newstate: SCAN -> AUTH flags 0x0 config chan 1 flags 8005 cck f ofdm 15 wpi_newstate: AUTH -> ASSOC flags 0x0 wpi_newstate: ASSOC -> RUN flags 0x0 config chan 1 flags 8015 wlan0: link state changed to UP wpi0: need multicast update callback wpi0: need multicast update callback wpi0: need multicast update callback pid 80903 (as), uid 0: exited on signal 11 (core dumped) pid 80944 (as), uid 0: exited on signal 11 (core dumped) pid 5177 (as), uid 0: exited on signal 11 (core dumped) pid 5186 (as), uid 0: exited on signal 11 (core dumped) Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 23 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 wpi_newstate: RUN -> SCAN flags 0x0 wlan0: link state changed to DOWN Beacon miss: 22 >= 7 Beacon miss: 23 >= 7 Beacon miss: 24 >= 7 Beacon miss: 25 >= 7 Beacon miss: 26 >= 7 Beacon miss: 27 >= 7 Beacon miss: 28 >= 7 Beacon miss: 29 >= 7 Beacon miss: 30 >= 7 Beacon miss: 31 >= 7 Beacon miss: 32 >= 7 Beacon miss: 33 >= 7 Beacon miss: 34 >= 7 Beacon miss: 35 >= 7 Beacon miss: 36 >= 7 Beacon miss: 37 >= 7 Beacon miss: 38 >= 7 Beacon miss: 39 >= 7 Beacon miss: 40 >= 7 Beacon miss: 41 >= 7 Beacon miss: 42 >= 7 Beacon miss: 43 >= 7 Beacon miss: 44 >= 7 Beacon miss: 45 >= 7 Beacon miss: 46 >= 7 Beacon miss: 47 >= 7 Beacon miss: 48 >= 7 Beacon miss: 49 >= 7 Beacon miss: 50 >= 7 Beacon miss: 51 >= 7 Beacon miss: 52 >= 7 Beacon miss: 53 >= 7 Beacon miss: 54 >= 7 Beacon miss: 55 >= 7 Beacon miss: 56 >= 7 Beacon miss: 57 >= 7 Beacon miss: 58 >= 7 Beacon miss: 59 >= 7 Beacon miss: 60 >= 7 Beacon miss: 61 >= 7 Beacon miss: 62 >= 7 Beacon miss: 63 >= 7 Beacon miss: 64 >= 7 Beacon miss: 65 >= 7 Beacon miss: 66 >= 7 Beacon miss: 67 >= 7 Beacon miss: 68 >= 7 Beacon miss: 69 >= 7 Beacon miss: 70 >= 7 Beacon miss: 71 >= 7 Beacon miss: 72 >= 7 Beacon miss: 73 >= 7 Beacon miss: 74 >= 7 Beacon miss: 75 >= 7 Beacon miss: 76 >= 7 Beacon miss: 77 >= 7 Beacon miss: 78 >= 7 Beacon miss: 79 >= 7 Beacon miss: 80 >= 7 Beacon miss: 81 >= 7 Beacon miss: 82 >= 7 Beacon miss: 83 >= 7 Beacon miss: 84 >= 7 Beacon miss: 85 >= 7 Beacon miss: 86 >= 7 wpi_newstate: SCAN -> AUTH flags 0x0 config chan 1 flags 8015 cck f ofdm 15 wpi_newstate: AUTH -> ASSOC flags 0x0 wpi_newstate: ASSOC -> RUN flags 0x0 config chan 1 flags 8015 wlan0: link state changed to UP wpi0: need multicast update callback Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 wpi0: need multicast update callback Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 23 >= 7 Beacon miss: 24 >= 7 Beacon miss: 25 >= 7 Beacon miss: 26 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 23 >= 7 Beacon miss: 24 >= 7 Beacon miss: 25 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 23 >= 7 Beacon miss: 24 >= 7 Beacon miss: 25 >= 7 Beacon miss: 26 >= 7 Beacon miss: 27 >= 7 Beacon miss: 28 >= 7 Beacon miss: 29 >= 7 Beacon miss: 30 >= 7 Beacon miss: 31 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 23 >= 7 Beacon miss: 24 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 20 >= 7 Beacon miss: 21 >= 7 Beacon miss: 22 >= 7 Beacon miss: 20 >= 7 Beacon miss: 20 >= 7 Stopping inetd. Waiting for PIDS: 1216 . Stopping cron. Stopping sshd. Waiting for PIDS: 1168 . Stopping moused. Waiting for PIDS: 1092 . Stopping powerd. Waiting for PIDS: 1014 . Stopping devd. Waiting for PIDS: 627 . Writing entropy file: . Terminated . Nov 2 08:12:03 sachmet syslogd: exiting on signal 15 wpi_newstate: RUN -> INIT flags 0x0 wlan0: link state changed to DOWN wpi_newstate: INIT -> INIT flags 0x0 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1934 fault code = supervisor write, page not present instruction pointer = 0x20:0xc09ef954 stack pointer = 0x28:0xe4125bec frame pointer = 0x28:0xe4125c98 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 = 11 (irq16: wpi0 uhci3) trap number = 12 panic: page fault cpuid = 1 Uptime: 16h28m30s Physical memory: 1006 MB Dumping 203 MB:panic: bufwrite: buffer is not busy??? cpuid = 1 panic: bufwrite: buffer is not busy??? cpuid = 1 panic: bufwrite: buffer is not busy??? cpuid = 1 188 172 156 140 124 108 92 76 60 44 28 12 ------------------------------------------------------------------------ kernel config config: File /boot/kernel/kernel doesn't contain configuration file. Either unsupported, or not compiled with INCLUDE_CONFIG_FILE ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="core.txt.7" sachmet.sigpipe.cz dumped core - see /var/crash/vmcore.7 Sun Nov 15 15:46:46 CET 2009 FreeBSD sachmet.sigpipe.cz 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Sat Oct 31 15:38:29 CET 2009 root@sachmet.sigpipe.cz:/usr/obj/usr/src/sys/SACHMET i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc479219f fault code = supervisor read, page not present instruction pointer = 0x20:0xc07c3ff0 stack pointer = 0x28:0xc3bfebc8 frame pointer = 0x28:0xc3bfec68 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 = 0 (wpi0 taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 11m25s Physical memory: 1006 MB Dumping 63 MB: 48 32 16 Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from /boot/kernel/if_wpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_wpi.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from /boot/kernel/wpifw.ko.symbols...done. done. Loaded symbols for /boot/kernel/wpifw.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc05cb3d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc05cb6a9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc07c5fac in trap_fatal (frame=0xc3bfeb88, eva=3296272799) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc07c6210 in trap_pfault (frame=0xc3bfeb88, usermode=0, eva=3296272799) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc07c6bb9 in trap (frame=0xc3bfeb88) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc07a9ebb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc07c3ff0 in memcpy () at /usr/src/sys/i386/i386/support.s:692 Cannot access memory at address 0xc4792008 (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -68 0 0 0 - RLs ?? 2330841:48.00 [kernel] 0 1 0 0 76 0 2912 0 wait DLs ?? 137873:24.00 [init] 0 2 0 0 -8 0 0 0 - DL ?? 7827831:54.00 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? 1799959:14.00 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 1514641:20.00 [g_down] 0 5 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 6 0 0 -32 0 0 0 psleep DL ?? 181707:10.00 [pagedaemon 0 7 0 0 -32 0 0 0 psleep DL ?? 93:20.00 [vmdaemon] 0 8 0 0 76 0 0 0 pgzero DL ?? 3246:50.00 [pagezero] 0 9 0 0 -32 0 0 0 psleep DL ?? 769038:26.00 [bufdaemon] 0 10 0 0 171 0 0 0 - RL ?? 1446995:20.00 [idle] 0 11 0 0 -60 0 0 0 - WL ?? -33106052:-49.55 [intr] 0 12 0 0 -16 0 0 0 - DL ?? 11149898:54.00 [yarrow] 0 13 0 0 -64 0 0 0 - DL ?? 2427167:38.00 [usb] 0 14 0 0 -16 0 0 0 tzpoll DL ?? 10129211:38.00 [acpi_therm 0 15 0 0 -16 0 0 0 coolin DL ?? 75407:44.00 [acpi_cooli 0 16 0 0 -32 0 0 0 - RL ?? 801248:00.00 [vnlru] 0 17 0 0 44 0 0 0 syncer DL ?? 5911825:30.00 [syncer] 0 18 0 0 -32 0 0 0 sdflus DL ?? 1106559:46.00 [softdepflu 0 19 0 0 -32 0 0 0 flowcl DL ?? 241830:24.00 [flowcleane 0 627 1 0 76 0 1888 0 select Ds ?? 274890:56.00 [devd] 0 808 1 0 44 0 3344 0 - Rs ?? 2447746:14.00 [syslogd] 0 1014 1 0 44 0 3344 0 - Rs ?? -15049359:-29.55 [powerd] 0 1092 1 0 76 0 3448 0 select Ds ?? 5207:32.00 [moused] 556 1116 1 0 44 0 3500 0 select Ds ?? 612347:38.00 [dbus-daemo 0 1174 1 0 76 0 6680 0 select Ds ?? 26405:38.00 [sshd] 0 1185 1 0 45 0 3372 0 nanslp Ds ?? 485375:06.00 [cron] 0 1222 1 0 76 0 3404 0 select Ds ?? 17908:48.00 [inetd] 0 1258 1 0 47 0 3808 0 wait Ds ?? 423389:24.00 [login] 0 1259 1 0 76 0 3344 0 ttyin Ds+ ?? 49903:56.00 [getty] 0 1260 1 0 76 0 3344 0 ttyin Ds+ ?? 57029:00.00 [getty] 0 1261 1 0 76 0 3344 0 ttyin Ds+ ?? 49642:22.00 [getty] 0 1262 1 0 76 0 3344 0 ttyin Ds+ ?? 50055:22.00 [getty] 0 1263 1 0 76 0 3344 0 ttyin Ds+ ?? 51209:26.00 [getty] 0 1264 1 0 76 0 3344 0 ttyin Ds+ ?? 49830:54.00 [getty] 0 1265 1 0 76 0 3344 0 ttyin Ds+ ?? 49288:24.00 [getty] 560 1270 1 0 44 0 7048 0 - Rs ?? -32360562:-15.55 [hald] 0 1273 1 0 50 0 12424 0 n Ds ?? 231903:42.00 [console-ki 0 1274 1270 0 76 0 5940 0 select D ?? 630385:14.00 [hald-runne 0 1279 1274 0 76 0 5824 0 kqread D ?? 266478:34.00 [hald-addon 0 1291 1274 0 44 0 3804 0 select D ?? 30180225:50.00 [hald-addon 1001 1304 1258 0 48 0 4180 0 ttyin D+ ?? -16102455:-21.55 [zsh] 0 1321 1 0 44 0 5140 0 - Rs ?? 453502:28.00 [wpa_suppli 0 1345 1 0 76 0 3284 0 select Ds ?? 618636:26.00 [dhclient] 65 1348 1 0 44 0 3284 0 select Ds ?? 405969:12.00 [dhclient] ------------------------------------------------------------------------ vmstat -s 476954 cpu context switches 22187 device interrupts 107860 software interrupts 99800 traps 640574 system calls 19 kernel threads created 1421 fork() calls 7 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 440 vnode pager pageins 3060 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 264 pages reactivated 38295 copy-on-write faults 72 copy-on-write optimized faults 30053 zero fill pages zeroed 1277 zero fill pages prezeroed 32 intransit blocking page faults 98720 total VM faults taken 0 pages affected by kernel thread creation 269326 pages affected by fork() 1468 pages affected by vfork() 0 pages affected by rfork() 287 pages cached 110679 pages freed 0 pages freed by daemon 56858 pages freed by exiting processes 2758 pages active 2331 pages inactive 9 pages in VM cache 8460 pages wired down 239224 pages free 4096 bytes per page 61516 total name lookups cache hits (88% pos + 6% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) sigio 1 1K - 1 32 filedesc 47 12K - 1456 16,256,512 kenv 84 7K - 92 16,32,64,128,4096 kqueue 10 5K - 12 128,256,1024 ad_driver 1 1K - 1 32 proc-args 26 2K - 549 16,32,64,128,256 ar_driver 0 0K - 6 512,2048 ithread 71 6K - 71 16,64,128 acd_driver 1 2K - 1 2048 KTRACE 100 13K - 100 128 linker 110 225K - 194 16,32,256,1024,4096 lockf 20 2K - 24 32,64 acpisem 59 8K - 59 64,128 temp 35 234K - 14857 16,32,64,128,256,512,1024,2048,4096 devbuf 3657 5414K - 3676 16,32,64,128,256,512,1024,2048,4096 module 258 17K - 258 64,128 mtx_pool 2 8K - 2 4096 osd 2 1K - 2 16,32 CAM periph 2 1K - 12 16,32,64,128 subproc 130 202K - 1533 256,4096 proc 2 8K - 2 4096 session 22 2K - 27 64 pgrp 23 2K - 63 64 cred 36 4K - 7478 64,128 uidinfo 6 2K - 31 64,1024 plimit 12 3K - 220 256 sysctltmp 0 0K - 426 16,32,64,128,256 sysctloid 3523 108K - 3616 16,32,64,128 sysctl 0 0K - 1419 16,32,64 callout 1 256K - 1 umtx 161 11K - 161 64 p1003.1b 1 1K - 1 16 SWAP 2 277K - 2 64 bus-sc 75 131K - 2690 16,32,64,128,256,512,1024,2048,4096 bus 807 41K - 5363 16,32,64,128,512,1024 devstat 6 13K - 6 16,4096 eventhandler 70 4K - 70 32,64,128 kobj 164 328K - 186 2048 Per-cpu 1 1K - 1 16 CAM dev queue 1 1K - 1 64 acpidev 94 3K - 94 32 rman 160 10K - 564 16,32,64 sbuf 0 0K - 423 16,32,64,128,256,512,1024,2048,4096 entropy 1024 64K - 1024 64 CAM queue 3 1K - 7 16 stack 0 0K - 2 128 taskqueue 13 1K - 13 16,64 Unitno 12 1K - 24 16,64 iov 0 0K - 4580 16,64,128,256 select 36 3K - 36 64 ioctlops 1 1K - 3944 16,32,64,128,256,512,1024,2048 msg 4 25K - 4 1024,4096 sem 4 36K - 4 4096 shm 1 12K - 1 tty 17 9K - 19 512,1024 mbuf_tag 0 0K - 39 32 ksem 1 4K - 1 4096 shmfd 1 4K - 1 4096 pcb 10 7K - 18 16,512,1024,2048 soname 15 2K - 261 16,32,64,128 biobuf 4 8K - 6 2048 vfscache 1 512K - 1 vfs_hash 1 256K - 1 vnodes 2 1K - 2 128 USBdev 40 11K - 115 32,128,256,1024 vnodemarker 0 0K - 138 512 mount 91 4K - 139 16,32,64,128,256 BPF 13 74K - 14 16,64,128,256,4096 ether_multi 2 1K - 32 16,32,64 ifaddr 138 8K - 140 16,32,256,2048 ifnet 5 5K - 5 64,1024 clone 5 20K - 5 4096 arpcom 2 1K - 2 16 lltable 9 2K - 11 128,256 USB 35 6K - 35 16,32,64,1024 CAM SIM 1 1K - 1 128 pci_link 16 2K - 16 64,128 acpi_perf 2 1K - 2 128 DEVFS1 84 21K - 90 256 DEVFS3 98 13K - 105 128 routetbl 43 258K - 206 16,32,64,128,256,512 80211vap 1 4K - 1 4096 80211crypto 0 0K - 2 512 80211com 1 8K - 1 80211nodeie 4 1K - 10 32,64,128,256 80211node 1 8K - 4 80211scan 4 5K - 4 256,2048 igmp 4 1K - 4 128 DEVFS 14 1K - 15 16,64 DEVFSP 2 1K - 77 32 in_multi 1 1K - 4 128 hostcache 1 16K - 1 syncache 1 72K - 1 NFS FHA 1 1K - 1 1024 rpc 2 5K - 2 128,4096 savedino 0 0K - 13 256 dirrem 0 0K - 36 32 mkdir 0 0K - 12 32 diradd 0 0K - 46 64 freefile 0 0K - 25 32 freeblks 0 0K - 19 256 freefrag 0 0K - 3 32 allocdirect 0 0K - 30 128 bmsafemap 0 0K - 11 64 newblk 1 1K - 31 64,256 inodedep 1 256K - 72 128 pagedep 1 32K - 18 64 ufs_dirhash 66 14K - 66 16,32,64,128,256,512 ufs_mount 9 27K - 9 256,2048,4096 UMAHash 1 1K - 1 256 vm_pgdata 2 65K - 2 64 atkbddev 2 1K - 2 32 pfs_nodes 70 9K - 70 128 pfs_vncache 8 1K - 8 32 apmdev 1 1K - 1 64 GEOM 93 41K - 510 16,32,64,128,512,1024,2048 agp 1 1K - 1 16 isadev 9 1K - 9 64 io_apic 1 1K - 1 1024 memdesc 1 4K - 1 4096 msi 1 1K - 1 64 nexusdev 4 1K - 4 16 acpica 2177 109K - 131625 16,32,64,128,256,512,1024 acpitask 1 1K - 1 1024 CAM XPT 12 2K - 33 16,32,64,1024 ata_generic 2 2K - 674 16,64,128,1024 cdev 11 2K - 11 128 mixer 2 8K - 2 4096 feeder 14 1K - 17 16,64 hdac 8 10K - 8 64,256,512,1024,2048,4096 linux 12 1K - 12 32,64 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 77, 13, 77, 0 UMA Zones: 888, 0, 77, 3, 77, 0 UMA Slabs: 284, 0, 490, 14, 2860, 0 UMA RCntSlabs: 544, 0, 291, 3, 291, 0 UMA Hash: 128, 0, 2, 28, 3, 0 16 Bucket: 76, 0, 48, 2, 73, 0 32 Bucket: 140, 0, 52, 4, 77, 0 64 Bucket: 268, 0, 38, 4, 84, 13 128 Bucket: 524, 0, 48, 1, 811, 112 VM OBJECT: 136, 0, 1208, 184, 19175, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 72, 56286, 39, 226, 7332, 0 MAP ENTRY: 72, 0, 542, 200, 35416, 0 DP fakepg: 72, 0, 0, 106, 17, 0 SG fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 210, 125, 210, 0 16: 16, 0, 2741, 507, 74449, 0 32: 32, 0, 2819, 232, 66599, 0 64: 64, 0, 4357, 304, 15205, 0 128: 128, 0, 2438, 172, 14581, 0 256: 256, 0, 638, 52, 3424, 0 512: 512, 0, 70, 50, 2532, 0 1024: 1024, 0, 44, 208, 5335, 0 2048: 2048, 0, 203, 27, 616, 0 4096: 4096, 0, 110, 29, 4551, 0 Files: 56, 0, 139, 330, 8514, 0 TURNSTILE: 72, 0, 162, 18, 162, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 680, 0, 44, 40, 1447, 0 THREAD: 560, 0, 138, 23, 138, 0 SLEEPQUEUE: 32, 0, 162, 133, 162, 0 VMSPACE: 232, 0, 26, 59, 1430, 0 cpuset: 40, 0, 2, 182, 2, 0 mbuf_packet: 256, 0, 64, 325, 504, 0 mbuf: 256, 0, 67, 194, 7670, 0 mbuf_cluster: 2048, 25600, 384, 18, 384, 0 mbuf_jumbo_page: 4096, 12800, 64, 26, 6658, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 g_bio: 140, 0, 0, 140, 7465, 0 ttyinq: 152, 0, 120, 62, 480, 0 ttyoutq: 256, 0, 64, 11, 256, 0 ata_request: 200, 0, 1, 94, 5221, 0 ata_composite: 180, 0, 0, 0, 0, 0 VNODE: 268, 0, 1505, 63, 1531, 0 VNODEPOLL: 60, 0, 28, 161, 28, 0 S VFS Cache: 72, 0, 1506, 137, 3000, 0 L VFS Cache: 292, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 36, 18972, 0 NFSMOUNT: 520, 0, 0, 0, 0, 0 NFSNODE: 464, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 166, 26, 166, 0 pipe: 392, 0, 5, 35, 968, 0 ksiginfo: 80, 0, 67, 989, 67, 0 itimer: 220, 0, 0, 0, 0, 0 KNOTE: 72, 0, 33, 126, 33, 0 socket: 412, 25605, 34, 29, 767, 0 ipq: 32, 904, 0, 0, 0, 0 udp_inpcb: 220, 25614, 2, 52, 631, 0 udpcb: 8, 25781, 2, 404, 631, 0 tcp_inpcb: 220, 25614, 1, 35, 1, 0 tcpcb: 632, 25602, 1, 11, 1, 0 tcptw: 52, 5184, 0, 0, 0, 0 syncache: 112, 15365, 0, 0, 0, 0 hostcache: 76, 15400, 0, 0, 0, 0 tcpreass: 20, 1690, 0, 0, 0, 0 sackhole: 20, 0, 0, 0, 0, 0 ripcb: 220, 25614, 1, 53, 7, 0 unpcb: 172, 25622, 28, 41, 118, 0 rtentry: 108, 0, 2, 106, 7, 0 selfd: 28, 0, 69, 439, 23005, 0 ip4flow: 40, 4140, 0, 276, 7, 0 ip6flow: 64, 4118, 0, 0, 0, 0 SWAPMETA: 276, 121576, 0, 0, 0, 0 Mountpoints: 644, 0, 6, 12, 6, 0 FFS inode: 116, 0, 1426, 59, 1451, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 1426, 44, 1451, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 1027 3 irq9: acpi0 2799 9 irq14: ata0 5375 18 irq16: wpi0 uhci3 10963 37 irq19: uhci1+ 1994 6 irq20: fxp0 2 0 irq23: uhci0 ehci0 1 0 cpu0: timer 1368655 4623 irq256: hdac0 18 0 cpu1: timer 1367983 4621 Total 2758817 9320 ------------------------------------------------------------------------ pstat -T 139/12328 files 0M/2003M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ad4s1b 4104080 0 4104080 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics iostat: kvm_getcptime: invalid address (0x0) iostat: disabling CPU time statistics ad4 KB/t tps MB/s 14.96 6 0.09 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 67108864 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 16384 (max amount of shared memory in pages) seminfo: semmap: 700 (# of entries in semaphore map) semmni: 256 (# of semaphore identifiers) semmns: 700 (# of semaphores in system) semmnu: 30 (# of undo structures in system) semmsl: 60 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 10 (max # of undo entries per process) semusz: 136 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 0 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 0 delivered 0 datagrams output 0 times multicast source filter matched ip: 7 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 7 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 28 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 7 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 23 ARP requests sent 1 ARP reply sent 1 ARP request received 1 ARP reply received 2 ARP packets received 16 total packets dropped due to no ARP entry 3 ARP entrys timed out 0 Duplicate IPs seen ------------------------------------------------------------------------ netstat -m 131/519/650 mbufs in use (current/cache/total) 59/343/402/25600 mbuf clusters in use (current/cache/total/max) 64/325 mbuf+clusters out of packet secondary zone in use (current/cache) 64/26/90/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 406K/919K/1326K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop wpi0 2290 00:19:d2:3b:a7:ca 0 0 49 4 0 0 fxp0 1500 00:16:36:e2:a4:ab 0 0 0 0 0 0 lo0 16384 0 0 0 0 0 0 lo0 16384 your-net localhost 0 - 0 - - - wlan0 1500 00:19:d2:3b:a7:ca 12 0 43 0 0 0 ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 link#3 UH 0 0 lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c4584000 tcp4 0 0 *.22 *.* LISTEN c4397294 udp4 0 0 *.* *.* c43967bc udp4 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c43a0ec8 stream 0 0 0 c43a1560 0 0 /var/run/dbus/system_bus_socket c43a1560 stream 0 0 0 c43a0ec8 0 0 c43a12b0 stream 0 0 0 c43a135c 0 0 /var/run/hald/dbus-gQGnMC5rzc c43a135c stream 0 0 0 c43a12b0 0 0 c43a0c18 stream 0 0 0 c43a0b6c 0 0 /var/run/hald/dbus-gQGnMC5rzc c43a0b6c stream 0 0 0 c43a0c18 0 0 c43a0810 stream 0 0 0 c43a0764 0 0 /var/run/devd.pipe c43a0764 stream 0 0 0 c43a0810 0 0 c43a0204 stream 0 0 0 c43a0000 0 0 /var/run/hald/dbus-pQCDJQW6rB c43a0000 stream 0 0 0 c43a0204 0 0 c43a1ac0 stream 0 0 c43e9648 0 0 0 /var/run/hald/dbus-pQCDJQW6rB c43a00ac stream 0 0 0 c43a0158 0 0 /var/run/dbus/system_bus_socket c43a0158 stream 0 0 0 c43a00ac 0 0 c43a035c stream 0 0 0 c43a0408 0 0 /var/run/dbus/system_bus_socket c43a0408 stream 0 0 0 c43a035c 0 0 c43a04b4 stream 0 0 c459e10c 0 0 0 /var/run/hald/dbus-gQGnMC5rzc c43a1c18 stream 0 0 0 c43a1cc4 0 0 c43a1cc4 stream 0 0 0 c43a1c18 0 0 c43a0560 stream 0 0 c453aa78 0 0 0 /var/run/dbus/system_bus_socket c43a060c stream 0 0 0 c43a06b8 0 0 /var/run/devd.pipe c43a06b8 stream 0 0 0 c43a060c 0 0 c43a0d70 stream 0 0 c43a3d9c 0 0 0 /var/run/devd.pipe c43a0a14 dgram 0 0 0 c43a1d70 0 c43a0ac0 c43a0e1c dgram 0 0 c472e324 0 0 0 /var/run/wpa_supplicant/wlan0 c43a0ac0 dgram 0 0 0 c43a1d70 0 c43a10ac c43a10ac dgram 0 0 0 c43a1d70 0 0 c43a1d70 dgram 131 0 c43cb10c 0 c43a0a14 0 /var/run/logpriv c43a1e1c dgram 0 0 c43cb218 0 0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 *.ssh unix 0/0/30 /var/run/hald/dbus-pQCDJQW6rB unix 0/0/30 /var/run/hald/dbus-gQGnMC5rzc unix 0/0/30 /var/run/dbus/system_bus_socket unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W _dhcp dhclient 1348 root /usr 6665226 dr-xr-xr-x 512 r _dhcp dhclient 1348 wd /usr 6665226 dr-xr-xr-x 512 r _dhcp dhclient 1348 jail /usr 6665226 dr-xr-xr-x 512 r _dhcp dhclient 1348 text / 18280 -r-xr-xr-x 78316 r _dhcp dhclient 1348 0 /dev 19 crw-rw-rw- null rw _dhcp dhclient 1348 1 /dev 19 crw-rw-rw- null rw _dhcp dhclient 1348 2 /dev 19 crw-rw-rw- null rw _dhcp dhclient 1348 3* local dgram c43a0a14 <-> c43a1d70 _dhcp dhclient 1348 5* local stream c43a0d70 _dhcp dhclient 1348 6 /usr 6665867 -rw------- 3 w _dhcp dhclient 1348 7* local stream c43a060c <-> c43a06b8 _dhcp dhclient 1348 8* local stream c43a0810 <-> c43a0764 _dhcp dhclient 1348 9* route raw 0 c4736000 _dhcp dhclient 1348 10* pipe c4245550 <-> c4245498 0 rw _dhcp dhclient 1348 11 /usr 6667518 ---------- 398 w _dhcp dhclient 1348 12 /dev 21 crw------- bpf rw _dhcp dhclient 1348 13* internet raw ip c4751000 root dhclient 1345 root / 2 drwxr-xr-x 512 r root dhclient 1345 wd / 2 drwxr-xr-x 512 r root dhclient 1345 text / 18280 -r-xr-xr-x 78316 r root dhclient 1345 0 /dev 19 crw-rw-rw- null rw root dhclient 1345 1 /dev 19 crw-rw-rw- null rw root dhclient 1345 2 /dev 19 crw-rw-rw- null rw root dhclient 1345 3* local dgram c43a0a14 <-> c43a1d70 root dhclient 1345 5* local stream c43a0d70 root dhclient 1345 6 /usr 6665867 -rw------- 3 w root dhclient 1345 7* local stream c43a060c <-> c43a06b8 root dhclient 1345 8* local stream c43a0810 <-> c43a0764 root dhclient 1345 9* pipe c4245498 <-> c4245550 0 rw root wpa_supplicant 1321 root / 2 drwxr-xr-x 512 r root wpa_supplicant 1321 wd / 2 drwxr-xr-x 512 r root wpa_supplicant 1321 text /usr 5018524 -r-xr-xr-x 295808 r root wpa_supplicant 1321 0 /dev 19 crw-rw-rw- null rw root wpa_supplicant 1321 1 /dev 19 crw-rw-rw- null rw root wpa_supplicant 1321 2 /dev 19 crw-rw-rw- null rw root wpa_supplicant 1321 3* local dgram c43a0ac0 <-> c43a1d70 root wpa_supplicant 1321 4* internet dgram udp c4397294 root wpa_supplicant 1321 5* route raw 0 c4737000 root wpa_supplicant 1321 6 /dev 21 crw------- bpf rw root wpa_supplicant 1321 7* local dgram c43a0e1c roman zsh 1304 root / 2 drwxr-xr-x 512 r roman zsh 1304 wd /usr 2284545 drwxr-xr-x 4096 r roman zsh 1304 text /usr 5958808 -r-xr-xr-x 1637852 r roman zsh 1304 0 /dev 37 crw------- ttyv0 rw roman zsh 1304 1 /dev 37 crw------- ttyv0 rw roman zsh 1304 2 /dev 37 crw------- ttyv0 rw roman zsh 1304 10 /dev 37 crw------- ttyv0 rw roman zsh 1304 12 /usr 5983546 -rw-r--r-- 127840 r roman zsh 1304 13 /usr 5983530 -rw-r--r-- 175256 r roman zsh 1304 14 /usr 5983543 -rw-r--r-- 186416 r roman zsh 1304 15 /usr 5983533 -rw-r--r-- 246128 r roman zsh 1304 16 /usr 5983541 -rw-r--r-- 2424816 r root hald-addon-storage 1291 root / 2 drwxr-xr-x 512 r root hald-addon-storage 1291 wd /usr 5958678 drwxr-xr-x 1536 r root hald-addon-storage 1291 text /usr 5962392 -r-xr-xr-x 9508 r root hald-addon-storage 1291 0 /dev 19 crw-rw-rw- null r root hald-addon-storage 1291 1 /dev 19 crw-rw-rw- null rw root hald-addon-storage 1291 2 /dev 19 crw-rw-rw- null rw root hald-addon-storage 1291 3* local stream c43a135c <-> c43a12b0 root hald-addon-storage 1291 4* local stream c43a1560 <-> c43a0ec8 root hald-addon-mouse-s 1279 root / 2 drwxr-xr-x 512 r root hald-addon-mouse-s 1279 wd /usr 5958678 drwxr-xr-x 1536 r root hald-addon-mouse-s 1279 text /usr 5962394 -r-xr-xr-x 6868 r root hald-addon-mouse-s 1279 0 /dev 19 crw-rw-rw- null r root hald-addon-mouse-s 1279 1 /dev 19 crw-rw-rw- null rw root hald-addon-mouse-s 1279 2 /dev 19 crw-rw-rw- null rw root hald-addon-mouse-s 1279 3* local stream c43a0b6c <-> c43a0c18 root hald-runner 1274 root / 2 drwxr-xr-x 512 r root hald-runner 1274 wd / 2 drwxr-xr-x 512 r root hald-runner 1274 text /usr 5962400 -r-xr-xr-x 13776 r root hald-runner 1274 0 /dev 19 crw-rw-rw- null r root hald-runner 1274 1 /dev 19 crw-rw-rw- null rw root hald-runner 1274 2 /dev 19 crw-rw-rw- null rw root hald-runner 1274 3* local stream c43a0000 <-> c43a0204 root console-kit-daemon 1273 root / 2 drwxr-xr-x 512 r root console-kit-daemon 1273 wd / 2 drwxr-xr-x 512 r root console-kit-daemon 1273 text /usr 5963527 -r-xr-xr-x 118496 r root console-kit-daemon 1273 0 /dev 19 crw-rw-rw- null rw root console-kit-daemon 1273 1 /dev 19 crw-rw-rw- null rw root console-kit-daemon 1273 2 /dev 19 crw-rw-rw- null rw root console-kit-daemon 1273 3* pipe c43cf498 <-> c43cf550 0 rw root console-kit-daemon 1273 4 /dev 19 crw-rw-rw- null rw root console-kit-daemon 1273 5* pipe c43cf550 <-> c43cf498 0 rw root console-kit-daemon 1273 6 /usr 6009548 drwxr-xr-x 512 r root console-kit-daemon 1273 7* pipe c43cf000 <-> c43cf0b8 0 rw root console-kit-daemon 1273 8* pipe c43cf0b8 <-> c43cf000 0 rw root console-kit-daemon 1273 9* local stream c43a0158 <-> c43a00ac root console-kit-daemon 1273 10 /usr 6688911 -rw-r--r-- 19886 w root console-kit-daemon 1273 11 /usr 7160126 -r--r--r-- 403 r root console-kit-daemon 1273 12 /dev 4 crw------- console r root console-kit-daemon 1273 14 /usr 6010112 drwxr-xr-x 512 r root console-kit-daemon 1273 15 /usr 7160095 -rw-rw-r-- 0 r haldaemo hald 1270 root / 2 drwxr-xr-x 512 r haldaemo hald 1270 wd / 2 drwxr-xr-x 512 r haldaemo hald 1270 text /usr 5962398 -r-xr-xr-x 265952 r haldaemo hald 1270 0 /dev 19 crw-rw-rw- null rw haldaemo hald 1270 1 /dev 19 crw-rw-rw- null rw haldaemo hald 1270 2 /dev 19 crw-rw-rw- null rw haldaemo hald 1270 5* pipe c4214620 <-> c42146d8 0 rw haldaemo hald 1270 6* pipe c42146d8 <-> c4214620 0 rw haldaemo hald 1270 7* local stream c43a04b4 haldaemo hald 1270 8* local stream c43a0408 <-> c43a035c haldaemo hald 1270 9* local stream c43a1ac0 haldaemo hald 1270 10* local stream c43a0204 <-> c43a0000 haldaemo hald 1270 12 /dev 23 crw-r--r-- pci rw haldaemo hald 1270 13 /dev 30 crw------- ata r haldaemo hald 1270 14 /dev 73 crw------- xpt0 rw haldaemo hald 1270 16 /usr 7160126 -r--r--r-- 403 r haldaemo hald 1270 17 /usr 6010112 drwxr-xr-x 512 r haldaemo hald 1270 18 /usr 7160095 -rw-rw-r-- 0 r haldaemo hald 1270 19 /usr 7160203 drwxr-xr-x 512 r haldaemo hald 1270 20 /usr 7160205 drwxr-xr-x 512 r haldaemo hald 1270 21 /usr 7160204 drwxr-xr-x 512 r haldaemo hald 1270 22 /usr 7160206 drwxr-xr-x 512 r haldaemo hald 1270 23 /usr 7160182 drwxr-xr-x 512 r haldaemo hald 1270 24 /usr 7160185 drwxr-xr-x 512 r haldaemo hald 1270 25 /usr 7160183 drwxr-xr-x 512 r haldaemo hald 1270 26 /usr 7160184 -r--r--r-- 1656 r haldaemo hald 1270 27 /usr 7160188 drwxr-xr-x 512 r haldaemo hald 1270 28 /usr 7160189 drwxr-xr-x 512 r haldaemo hald 1270 29 /usr 7160201 drwxr-xr-x 512 r haldaemo hald 1270 30 /usr 7160190 drwxr-xr-x 512 r haldaemo hald 1270 31 /usr 7160200 -r--r--r-- 1609 r haldaemo hald 1270 32 /usr 7160199 -r--r--r-- 19472 r haldaemo hald 1270 33 /usr 7160198 -r--r--r-- 1214 r haldaemo hald 1270 34 /usr 7160197 -r--r--r-- 541 r haldaemo hald 1270 35 /usr 7160196 -r--r--r-- 913 r haldaemo hald 1270 36 /usr 7160195 -r--r--r-- 1153 r haldaemo hald 1270 37 /usr 7160194 -r--r--r-- 4038 r haldaemo hald 1270 38 /usr 7160210 -r--r--r-- 257 r haldaemo hald 1270 39 /usr 7160193 -r--r--r-- 1352 r haldaemo hald 1270 40 /usr 7160191 -r--r--r-- 795 r haldaemo hald 1270 41 /usr 7160192 -r--r--r-- 720 r haldaemo hald 1270 42 /usr 7160202 drwxr-xr-x 512 r haldaemo hald 1270 43* local stream c43a0764 <-> c43a0810 haldaemo hald 1270 44* local stream c43a0c18 <-> c43a0b6c haldaemo hald 1270 45* local stream c43a12b0 <-> c43a135c root getty 1265 root / 2 drwxr-xr-x 512 r root getty 1265 wd / 2 drwxr-xr-x 512 r root getty 1265 text /usr 6900791 -r-xr-xr-x 21832 r root getty 1265 0 /dev 44 crw------- ttyv7 rw root getty 1265 1 /dev 44 crw------- ttyv7 rw root getty 1265 2 /dev 44 crw------- ttyv7 rw root getty 1264 root / 2 drwxr-xr-x 512 r root getty 1264 wd / 2 drwxr-xr-x 512 r root getty 1264 text /usr 6900791 -r-xr-xr-x 21832 r root getty 1264 0 /dev 43 crw------- ttyv6 rw root getty 1264 1 /dev 43 crw------- ttyv6 rw root getty 1264 2 /dev 43 crw------- ttyv6 rw root getty 1263 root / 2 drwxr-xr-x 512 r root getty 1263 wd / 2 drwxr-xr-x 512 r root getty 1263 text /usr 6900791 -r-xr-xr-x 21832 r root getty 1263 0 /dev 42 crw------- ttyv5 rw root getty 1263 1 /dev 42 crw------- ttyv5 rw root getty 1263 2 /dev 42 crw------- ttyv5 rw root getty 1262 root / 2 drwxr-xr-x 512 r root getty 1262 wd / 2 drwxr-xr-x 512 r root getty 1262 text /usr 6900791 -r-xr-xr-x 21832 r root getty 1262 0 /dev 41 crw------- ttyv4 rw root getty 1262 1 /dev 41 crw------- ttyv4 rw root getty 1262 2 /dev 41 crw------- ttyv4 rw root getty 1261 root / 2 drwxr-xr-x 512 r root getty 1261 wd / 2 drwxr-xr-x 512 r root getty 1261 text /usr 6900791 -r-xr-xr-x 21832 r root getty 1261 0 /dev 40 crw------- ttyv3 rw root getty 1261 1 /dev 40 crw------- ttyv3 rw root getty 1261 2 /dev 40 crw------- ttyv3 rw root getty 1260 root / 2 drwxr-xr-x 512 r root getty 1260 wd / 2 drwxr-xr-x 512 r root getty 1260 text /usr 6900791 -r-xr-xr-x 21832 r root getty 1260 0 /dev 39 crw------- ttyv2 rw root getty 1260 1 /dev 39 crw------- ttyv2 rw root getty 1260 2 /dev 39 crw------- ttyv2 rw root getty 1259 root / 2 drwxr-xr-x 512 r root getty 1259 wd / 2 drwxr-xr-x 512 r root getty 1259 text /usr 6900791 -r-xr-xr-x 21832 r root getty 1259 0 /dev 38 crw------- ttyv1 rw root getty 1259 1 /dev 38 crw------- ttyv1 rw root getty 1259 2 /dev 38 crw------- ttyv1 rw root login 1258 root / 2 drwxr-xr-x 512 r root login 1258 wd /usr 2284545 drwxr-xr-x 4096 r root login 1258 text /usr 3984203 -r-sr-xr-x 21712 r root login 1258 0 /dev 37 crw------- ttyv0 rw root login 1258 1 /dev 37 crw------- ttyv0 rw root login 1258 2 /dev 37 crw------- ttyv0 rw root login 1258 3* local dgram c43a10ac <-> c43a1d70 root inetd 1222 root / 2 drwxr-xr-x 512 r root inetd 1222 wd / 2 drwxr-xr-x 512 r root inetd 1222 text /usr 5017099 -r-xr-xr-x 42108 r root inetd 1222 0 /dev 19 crw-rw-rw- null rw root inetd 1222 1 /dev 19 crw-rw-rw- null rw root inetd 1222 2 /dev 19 crw-rw-rw- null rw root inetd 1222 3 /usr 6665906 -rw------- 4 w root inetd 1222 4* pipe c42147a8 <-> c4214860 0 rw root inetd 1222 5* pipe c4214860 <-> c42147a8 0 rw root cron 1185 root / 2 drwxr-xr-x 512 r root cron 1185 wd /usr 6665224 drwxr-x--- 512 r root cron 1185 text /usr 5016646 -r-xr-xr-x 34024 r root cron 1185 0 /dev 19 crw-rw-rw- null rw root cron 1185 1 /dev 19 crw-rw-rw- null rw root cron 1185 2 /dev 19 crw-rw-rw- null rw root cron 1185 3 /usr 6665904 -rw------- 4 w root sshd 1174 root / 2 drwxr-xr-x 512 r root sshd 1174 wd / 2 drwxr-xr-x 512 r root sshd 1174 text /usr 5016598 -r-xr-xr-x 224152 r root sshd 1174 0 /dev 19 crw-rw-rw- null rw root sshd 1174 1 /dev 19 crw-rw-rw- null rw root sshd 1174 2 /dev 19 crw-rw-rw- null rw root sshd 1174 3* internet stream tcp c4584000 messageb dbus-daemon 1116 root / 2 drwxr-xr-x 512 r messageb dbus-daemon 1116 wd / 2 drwxr-xr-x 512 r messageb dbus-daemon 1116 text /usr 5962330 -r-xr-xr-x 313880 r messageb dbus-daemon 1116 0 /dev 19 crw-rw-rw- null rw messageb dbus-daemon 1116 1 /dev 19 crw-rw-rw- null rw messageb dbus-daemon 1116 2 /dev 19 crw-rw-rw- null rw messageb dbus-daemon 1116 3* local stream c43a0560 messageb dbus-daemon 1116 4 /dev 19 crw-rw-rw- null rw messageb dbus-daemon 1116 6 /usr 6009548 drwxr-xr-x 512 r messageb dbus-daemon 1116 7* local stream c43a1cc4 <-> c43a1c18 messageb dbus-daemon 1116 8* local stream c43a1c18 <-> c43a1cc4 messageb dbus-daemon 1116 9* local stream c43a035c <-> c43a0408 messageb dbus-daemon 1116 10* local stream c43a00ac <-> c43a0158 messageb dbus-daemon 1116 11* local stream c43a0ec8 <-> c43a1560 root moused 1092 root / 2 drwxr-xr-x 512 r root moused 1092 wd / 2 drwxr-xr-x 512 r root moused 1092 text /usr 5017143 -r-xr-xr-x 36100 r root moused 1092 0 /dev 19 crw-rw-rw- null rw root moused 1092 1 /dev 19 crw-rw-rw- null rw root moused 1092 2 /dev 19 crw-rw-rw- null rw root moused 1092 3 /dev 35 crw-rw-rw- psm0 rw root moused 1092 4 /dev 53 crw------- consolectl rw root moused 1092 5 /usr 6665891 -rw------- 4 w root powerd 1014 root / 2 drwxr-xr-x 512 r root powerd 1014 wd / 2 drwxr-xr-x 512 r root powerd 1014 text /usr 5017188 -r-xr-xr-x 12764 r root powerd 1014 0 /dev 19 crw-rw-rw- null rw root powerd 1014 1 /dev 19 crw-rw-rw- null rw root powerd 1014 2 /dev 19 crw-rw-rw- null rw root powerd 1014 3 /usr 6665884 -rw------- 4 w root powerd 1014 4* local stream c43a06b8 <-> c43a060c root syslogd 808 root / 2 drwxr-xr-x 512 r root syslogd 808 wd / 2 drwxr-xr-x 512 r root syslogd 808 text /usr 5017508 -r-xr-xr-x 35864 r root syslogd 808 0 /dev 19 crw-rw-rw- null rw root syslogd 808 1 /dev 19 crw-rw-rw- null rw root syslogd 808 2 /dev 19 crw-rw-rw- null rw root syslogd 808 3 /usr 6665872 -rw------- 3 w root syslogd 808 4* local dgram c43a1e1c root syslogd 808 5* local dgram c43a1d70 root syslogd 808 6* internet dgram udp c43967bc root syslogd 808 7 /dev 7 crw------- klog r root syslogd 808 9 - - bad - root syslogd 808 10 /usr 6665681 -rw-r--r-- 35661 w root syslogd 808 11 /usr 6665327 -rw------- 59 w root syslogd 808 12 /usr 6665448 -rw------- 8681 w root syslogd 808 13 /usr 6665498 -rw-r----- 62 w root syslogd 808 14 /usr 6665283 -rw-r--r-- 49942 w root syslogd 808 15 /usr 6665329 -rw------- 59 w root syslogd 808 16 /usr 6665458 -rw------- 63609 w root syslogd 808 17 /usr 6665322 -rw------- 11184 w root syslogd 808 18 /usr 6665326 -rw-r----- 59 w root syslogd 808 19 /usr 6665344 -rw-r--r-- 1168403057 w root devd 627 root / 2 drwxr-xr-x 512 r root devd 627 wd / 2 drwxr-xr-x 512 r root devd 627 text / 18278 -r-xr-xr-x 386944 r root devd 627 0 /dev 19 crw-rw-rw- null rw root devd 627 1 /dev 19 crw-rw-rw- null rw root devd 627 2 /dev 19 crw-rw-rw- null rw root devd 627 3 / 49760 drwxr-xr-x 512 r root devd 627 4 /dev 5 crw------- devctl r root devd 627 5* local stream c43a0d70 root devd 627 6 /usr 6665867 -rw------- 3 w root devd 627 7* local stream c43a060c <-> c43a06b8 root devd 627 8* local stream c43a0810 <-> c43a0764 root init 1 root / 2 drwxr-xr-x 512 r root init 1 wd / 2 drwxr-xr-x 512 r root init 1 text / 18284 -r-xr-xr-x 666380 r root kernel 0 root / 2 drwxr-xr-x 512 r root kernel 0 wd / 2 drwxr-xr-x 512 r ------------------------------------------------------------------------ dmesg table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ugen4.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=devstat' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=devstat Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+acd0 at on ata0' Pushing table setting device-name=acd0 Processing attach event Testing device-name=acd0 against ^ed50 Testing device-name=acd0 against ^ubt[0-9]+ Testing device-name=acd0 against ^ukbd0 Testing device-name=acd0 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=acd0 against ^ugen[0-9]+ Testing media type of acd0 against 0x80 Testing device-name=acd0 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=acd0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=acd0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/0.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen0.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci0' Pushing table setting device-name=ugen0.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen0.1 against ^ed50 Testing device-name=ugen0.1 against ^ubt[0-9]+ Testing device-name=ugen0.1 against ^ukbd0 Testing device-name=ugen0.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen0.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen0.1 against 0x80 Testing device-name=ugen0.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/1.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/1.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen1.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci1' Pushing table setting device-name=ugen1.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen1.1 against ^ed50 Testing device-name=ugen1.1 against ^ubt[0-9]+ Testing device-name=ugen1.1 against ^ukbd0 Testing device-name=ugen1.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen1.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen1.1 against 0x80 Testing device-name=ugen1.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/2.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/2.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen2.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci2' Pushing table setting device-name=ugen2.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen2.1 against ^ed50 Testing device-name=ugen2.1 against ^ubt[0-9]+ Testing device-name=ugen2.1 against ^ukbd0 Testing device-name=ugen2.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen2.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen2.1 against 0x80 Testing device-name=ugen2.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/3.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen3.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on uhci3' Pushing table setting device-name=ugen3.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen3.1 against ^ed50 Testing device-name=ugen3.1 against ^ubt[0-9]+ Testing device-name=ugen3.1 against ^ukbd0 Testing device-name=ugen3.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen3.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen3.1 against 0x80 Testing device-name=ugen3.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/4.1.1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=usb/4.1.1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+ugen4.1 vendor=0x0000 product=0x0000 devclass=0x09 devsubclass=0x00 sernum="" release=0x0100 at port=1 on ehci0' Pushing table setting device-name=ugen4.1 setting vendor=0x0000 setting product=0x0000 setting devclass=0x09 setting devsubclass=0x00 setting sernum= setting release=0x0100 Processing attach event Testing device-name=ugen4.1 against ^ed50 Testing device-name=ugen4.1 against ^ubt[0-9]+ Testing device-name=ugen4.1 against ^ukbd0 Testing device-name=ugen4.1 against ^ums[0-9]+ Testing vendor=0x0000 against ^0x0854 Testing vendor=0x0000 against ^0x1645 Testing device-name=ugen4.1 against ^ugen[0-9]+ Testing vendor=0x0000 against ^0x082d Testing media type of ugen4.1 against 0x80 Testing device-name=ugen4.1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=ACPI subsystem=ACAD type=\\_SB_.ACAD notify=0x01' Pushing table setting system=ACPI setting subsystem=ACAD setting type=\\_SB_.ACAD setting notify=0x01 Processing notify event Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^CMBAT Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^Resume Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^Suspend Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ZFS Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^Thermal Testing system=ACPI against ^ACPI Testing subsystem=ACAD against ^ACAD Executing '/etc/rc.d/power_profile 0x01' Popping table Processing event '!system=ACPI subsystem=CMBAT type=\\_SB_.BAT1 notify=0x80' Pushing table setting system=ACPI setting subsystem=CMBAT setting type=\\_SB_.BAT1 setting notify=0x80 Processing notify event Testing system=ACPI against ^ACPI Testing subsystem=CMBAT against ^CMBAT Executing 'logger -p kern.info ACPI.CMBAT: 0x80' Popping table Processing event '!system=ACPI subsystem=CMBAT type=\\_SB_.BAT1 notify=0x00' Pushing table setting system=ACPI setting subsystem=CMBAT setting type=\\_SB_.BAT1 setting notify=0x00 Processing notify event Testing system=ACPI against ^ACPI Testing subsystem=CMBAT against ^CMBAT Executing 'logger -p kern.info ACPI.CMBAT: 0x00' Popping table Processing event '+subdisk4 at on ad4' Pushing table setting device-name=subdisk4 Processing attach event Testing device-name=subdisk4 against ^ed50 Testing device-name=subdisk4 against ^ubt[0-9]+ Testing device-name=subdisk4 against ^ukbd0 Testing device-name=subdisk4 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=subdisk4 against ^ugen[0-9]+ Testing media type of subdisk4 against 0x80 Testing device-name=subdisk4 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+ad4 at on ata2' Pushing table setting device-name=ad4 Processing attach event Testing device-name=ad4 against ^ed50 Testing device-name=ad4 against ^ubt[0-9]+ Testing device-name=ad4 against ^ukbd0 Testing device-name=ad4 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=ad4 against ^ugen[0-9]+ Testing media type of ad4 against 0x80 Testing device-name=ad4 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=xpt0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=xpt0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=mixer0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=mixer0 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+pcm0 at on hdac0' Pushing table setting device-name=pcm0 Processing attach event Testing device-name=pcm0 against ^ed50 Testing device-name=pcm0 against ^ubt[0-9]+ Testing device-name=pcm0 against ^ukbd0 Testing device-name=pcm0 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=pcm0 against ^ugen[0-9]+ Testing media type of pcm0 against 0x80 Testing device-name=pcm0 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=mixer1' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=mixer1 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+pcm1 at on hdac0' Pushing table setting device-name=pcm1 Processing attach event Testing device-name=pcm1 against ^ed50 Testing device-name=pcm1 against ^ubt[0-9]+ Testing device-name=pcm1 against ^ukbd0 Testing device-name=pcm1 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=pcm1 against ^ugen[0-9]+ Testing media type of pcm1 against 0x80 Testing device-name=pcm1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub0 at on usbus0' Pushing table setting device-name=uhub0 Processing attach event Testing device-name=uhub0 against ^ed50 Testing device-name=uhub0 against ^ubt[0-9]+ Testing device-name=uhub0 against ^ukbd0 Testing device-name=uhub0 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub0 against ^ugen[0-9]+ Testing media type of uhub0 against 0x80 Testing device-name=uhub0 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub1 at on usbus1' Pushing table setting device-name=uhub1 Processing attach event Testing device-name=uhub1 against ^ed50 Testing device-name=uhub1 against ^ubt[0-9]+ Testing device-name=uhub1 against ^ukbd0 Testing device-name=uhub1 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub1 against ^ugen[0-9]+ Testing media type of uhub1 against 0x80 Testing device-name=uhub1 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub2 at on usbus2' Pushing table setting device-name=uhub2 Processing attach event Testing device-name=uhub2 against ^ed50 Testing device-name=uhub2 against ^ubt[0-9]+ Testing device-name=uhub2 against ^ukbd0 Testing device-name=uhub2 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub2 against ^ugen[0-9]+ Testing media type of uhub2 against 0x80 Testing device-name=uhub2 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '+uhub3 at on usbus3' Pushing table setting device-name=uhub3 Processing attach event Testing device-name=uhub3 against ^ed50 Testing device-name=uhub3 against ^ubt[0-9]+ Testing device-name=uhub3 against ^ukbd0 Testing device-name=uhub3 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub3 against ^ugen[0-9]+ Testing media type of uhub3 against 0x80 Testing device-name=uhub3 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s2' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s2 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1a' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1a Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1b' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1b Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s1d' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s1d Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ad4s2d' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ad4s2d Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214f' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214f Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214fd' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214fd Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '+uhub4 at on usbus4' Pushing table setting device-name=uhub4 Processing attach event Testing device-name=uhub4 against ^ed50 Testing device-name=uhub4 against ^ubt[0-9]+ Testing device-name=uhub4 against ^ukbd0 Testing device-name=uhub4 against ^ums[0-9]+ Testing vendor= against ^0x0854 Testing vendor= against ^0x1645 Testing device-name=uhub4 against ^ugen[0-9]+ Testing media type of uhub4 against 0x80 Testing device-name=uhub4 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/46615685b1e3214f' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/46615685b1e3214f Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/46615685b1e3214fd' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/46615685b1e3214fd Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214f' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214f Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/46615685b1e3214fd' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=CREATE setting cdev=ufsid/46615685b1e3214fd Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55abe0457852' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55abe0457852 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ufsid/465d55ab7df6bca7' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=ufsid/465d55ab7df6bca7 Processing notify event Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ZFS Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^IFNET Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^ACPI Testing system=DEVFS against ^IFNET Popping table Processing event '!system=IFNET subsystem=wlan0 type=ATTACH' Pushing table setting system=IFNET setting subsystem=wlan0 setting type=ATTACH Processing notify event Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ZFS Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^IFNET Testing type=ATTACH against ^LINK_UP Testing system=IFNET against ^IFNET Testing type=ATTACH against ^LINK_UP Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^ACPI Testing system=IFNET against ^IFNET Testing type=ATTACH against ^ATTACH Executing '/etc/pccard_ether wlan0 start' Popping table Calling daemon ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat /usr/local/lib/gcc44 /usr/local/lib/gcc45 /usr/local/lib/graphviz /usr/local/lib/nss /usr/local/lib/qt4 a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files . Starting syslogd. No core dumps found. Additional ABI support: linux . Clearing /tmp (X related). Updating motd: . Starting powerd. Starting default moused . Starting dbus. Starting hald. Configuring syscons: keymap blanktime . Starting sshd. Starting cron. Starting inetd. Sun Nov 15 15:29:26 CET 2009 wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 microcode alive notification version 10e02 alive 1 microcode alive notification version 10e02 alive 1 wpi_newstate: INIT -> SCAN flags 0x0 wpi_newstate: SCAN -> AUTH flags 0x0 config chan 1 flags 8005 cck f ofdm 15 wpi_newstate: AUTH -> ASSOC flags 0x0 wpi_newstate: ASSOC -> RUN flags 0x0 config chan 1 flags 8015 wlan0: link state changed to UP wpi0: need multicast update callback wpi0: need multicast update callback wpi0: need multicast update callback wpi0: need multicast update callback wpi0: need multicast update callback wpi_newstate: RUN -> ASSOC flags 0x0 wlan0: link state changed to DOWN wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wpi_newstate: ASSOC -> AUTH flags 0x0 config chan 1 flags 8015 cck f ofdm 15 wpi_newstate: AUTH -> ASSOC flags 0x0 wpi_newstate: ASSOC -> AUTH flags 0x0 wlcano0n: fig chan 1 flags 8015 cck f ofdm 15ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wpi_newstate: AUTH -> RUN flags 0x0 config chan 1 flags 8015 wlan0: link state changed to UP wpi0: need multicast update callback wpi_newstate: RUN -> ASSOC flags 0x0 wlan0: link state changed to DOWN wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost wpi_newstate: ASSOC -> AUTH flags 0x0 config chan 1 flags 8015 cck f ofdm 15 wlan0: ieee80211_new_state_locked: pending ASSOC -> AUTH transition lost Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc479219f fault code = supervisor read, page not present instruction pointer = 0x20:0xc07c3ff0 stack pointer = 0x28:0xc3bfebc8 frame pointer = 0x28:0xc3bfec68 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 = 0 (wpi0 taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 11m25s Physical memory: 1006 MB Dumping 63 MB: 48 32 16 ------------------------------------------------------------------------ kernel config config: File /boot/kernel/kernel doesn't contain configuration file. Either unsupported, or not compiled with INCLUDE_CONFIG_FILE ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 22:40:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E34F510656A3 for ; Sun, 15 Nov 2009 22:40:17 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6861D8FC20 for ; Sun, 15 Nov 2009 22:40:16 +0000 (UTC) Received: by bwz5 with SMTP id 5so5404267bwz.3 for ; Sun, 15 Nov 2009 14:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=79me7eG/BFbX/5+WqZzMLzH4L5IBhh8gm5lWXhLxIsg=; b=b69g/Lde2Yrekc7lYssnhcYMwItkiEMwlMNlg1C3obDTLZ8h9beDpRvDgTFn0Bc81l UBOWBGR0IzoXsicP/hYQIQSzLOTunNVHorRvsvmuAlJhzp2I9u7+1eojqut7TB9AecS9 Yw0odUzZlQzTZNDQSy2pCnBTc62V0OZ4OxnJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lIz1CTMMySDyFxBjlMSpyIMCfMJ5WjPLQXP/tlmaQfo5+W0BUT9oplnEw6X6ANM5RL Uj87SbndGLR8bUNunHTomCP+QgROEp0Klu/WmInkP2ly37713XCdNtJiIA6D9WHRBtPW I+uGUYvjobI/Bm5L5EzAVJwlT55IKdjSSE4bg= Received: by 10.204.34.84 with SMTP id k20mr5288228bkd.199.1258324816035; Sun, 15 Nov 2009 14:40:16 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm1877116fxm.8.2009.11.15.14.40.14 (version=SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 14:40:15 -0800 (PST) Sender: Alexander Motin Message-ID: <4B00834C.5030807@FreeBSD.org> Date: Mon, 16 Nov 2009 00:40:12 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Michael Butler References: <1258320182.00183757.1258306802@10.7.7.3> In-Reply-To: <1258320182.00183757.1258306802@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: switching from legacy to ahci on intel ICH-7M? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2009 22:40:18 -0000 Michael Butler wrote: > My current laptop has an AHCI-capable disk controller and SATA disk but, > it appears, the manufacturer has no interest in implementing AHCI in the > BIOS. > > Is there an example of how one might (re-)initialize the controller to > take advantage of AHCI and the disk's NCQ capabilites somewhere? Intel ICH7 datasheet? AFAIR it was described there. Some other vendors allow enabling AHCI just via one of standard AHCI registers, but Intel doesn't. If SATA is not configured as AHCI or RAID by BIOS via custom register, standard AHCI registers are not available. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Nov 15 22:59:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF20910656A5 for ; Sun, 15 Nov 2009 22:59:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB358FC0A for ; Sun, 15 Nov 2009 22:59:06 +0000 (UTC) Received: (qmail 18624 invoked by uid 399); 15 Nov 2009 22:59:05 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Nov 2009 22:59:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B0087C2.9070508@FreeBSD.org> Date: Sun, 15 Nov 2009 14:59:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Antoine Brodin Subject: wpa_supplicant + wpi0 won't lock in on today's -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, 15 Nov 2009 22:59:06 -0000 I upgraded my -current laptop from r199019 to r199291 and on the newer kernel wpa_supplicant runs but doesn't ever lock in. The only suspect commits in that range are r19918[67] which seem to be minor fixes to sys/net80211. I haven't yet had a chance to test that theory; I thought I'd post sooner than later to see if anyone has a bright idea first. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 00:29:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33E04106566B; Mon, 16 Nov 2009 00:29:34 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 696D58FC12; Mon, 16 Nov 2009 00:29:33 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so1632989eyd.9 for ; Sun, 15 Nov 2009 16:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=kFnUmCdqpL/V9gM45trgYrIK8qowlL0z4rTNDbyhvKs=; b=oQqvo1K4iYqgfHGBlA1u0TNx8vnAWjmFUjG2Wxlslof0Za2qkhDHpj/0w6t1iXeVHs StKuZLW076JXpNJLxvQsML4KkFjprfkOe+sEQmi+3qjTSEy9LAGWHj/bb6IVfYwiN/Qi zeMpD3x7QoPAbwnHKiezNyzivFzg7Y3vxaHWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=aCYKlYItuBH4R6m9s1Xcs2+PPOK4kYER3FnPWevPBfZL+2mpB+rXLmMjFvN9Gg5Hqi JL7pwVCRsq0t9C/CaGhFAJvAfP4eSopeqA72QLt5PsCtJWfGFW6KwDhL37TwJNajUTRS /TAqH71t8Kv+GwiLxKpBiDmJkWlxNN2uzWC3U= Received: by 10.213.8.28 with SMTP id f28mr1428280ebf.39.1258331372351; Sun, 15 Nov 2009 16:29:32 -0800 (PST) Received: from mac-mini.lan (bl6-148-68.dsl.telepac.pt [82.155.148.68]) by mx.google.com with ESMTPS id 7sm4645172eyb.16.2009.11.15.16.29.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 16:29:31 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4B0087C2.9070508@FreeBSD.org> Date: Mon, 16 Nov 2009 00:29:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B0087C2.9070508@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1077) Cc: Antoine Brodin , freebsd-current@freebsd.org Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 00:29:34 -0000 Hi, On 15 Nov 2009, at 22:59, Doug Barton wrote: > I upgraded my -current laptop from r199019 to r199291 and on the newer > kernel wpa_supplicant runs but doesn't ever lock in. >=20 > The only suspect commits in that range are r19918[67] which seem to be > minor fixes to sys/net80211. I haven't yet had a chance to test that > theory; I thought I'd post sooner than later to see if anyone has a > bright idea first. :) The commits you mention couldn't have caused any kind of the malfunction = that you describe. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 00:43:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF7510656B9 for ; Mon, 16 Nov 2009 00:43:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9D89A8FC22 for ; Mon, 16 Nov 2009 00:43:00 +0000 (UTC) Received: (qmail 20804 invoked by uid 399); 16 Nov 2009 00:43:00 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Nov 2009 00:43:00 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B00A01D.9040704@FreeBSD.org> Date: Sun, 15 Nov 2009 16:43:09 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Rui Paulo References: <4B0087C2.9070508@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Antoine Brodin , freebsd-current@freebsd.org Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 00:43:01 -0000 Rui Paulo wrote: > Hi, > > On 15 Nov 2009, at 22:59, Doug Barton wrote: > >> I upgraded my -current laptop from r199019 to r199291 and on the newer >> kernel wpa_supplicant runs but doesn't ever lock in. >> >> The only suspect commits in that range are r19918[67] which seem to be >> minor fixes to sys/net80211. I haven't yet had a chance to test that >> theory; I thought I'd post sooner than later to see if anyone has a >> bright idea first. :) > > The commits you mention couldn't have caused any kind of the malfunction that you describe. Yes, I didn't think it likely, but as I noted those were the only commits that (to my untrained eye) looked like they could be relevant. I'm currently in the process of doing a binary search, r199185 exhibits the problem, so the bug came before that. I'll update again when I'm done. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 00:59:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8816106566B for ; Mon, 16 Nov 2009 00:59:26 +0000 (UTC) (envelope-from wendell@ramenzoni.com.br) Received: from monarco.ramenzoni.com.br (monarco.ramenzoni.com.br [200.178.230.133]) by mx1.freebsd.org (Postfix) with ESMTP id 463B38FC12 for ; Mon, 16 Nov 2009 00:59:25 +0000 (UTC) Received: (qmail 34412 invoked by uid 98); 15 Nov 2009 22:32:44 -0200 Received: from 201.95.12.120 (wendell@201.95.12.120) by monarco.ramenzoni.com.br (envelope-from , uid 82) with qmail-scanner-2.01 (clamdscan: 0.95.1/9278. spamassassin: 3.2.5. Clear:RC:1(201.95.12.120):. Processed in 0.031705 secs); 16 Nov 2009 00:32:44 -0000 Received: from 201-95-12-120.dsl.telesp.net.br (HELO ?10.0.1.5?) (wendell@201.95.12.120) by 0 with ESMTPA; 15 Nov 2009 22:32:44 -0200 From: Wendell Borges Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 22:32:43 -0200 Message-Id: <253062DF-9E44-49C8-BDFB-CB779F41D224@ramenzoni.com.br> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Mon, 16 Nov 2009 01:27:18 +0000 Subject: dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 00:59:27 -0000 Hi, I upgraded to FreeBSD 8.0-RC3 but the message of dmesg shows FreeBSD = 7.2-RELEASE-p4, which may be happening? > %uname -a > FreeBSD nfedevel.ramenzoni.com.br 8.0-RC3 FreeBSD 8.0-RC3 #0: Tue Nov = 10 > 07:50:36 UTC 2009 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > %dmesg | head > Copyright (c) 1992-2009 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.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 > root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz (1596.01-MHz = 686-class > CPU) > Origin =3D "GenuineIntel" Id =3D 0x6fd Stepping =3D 13 > = Features=3D0xbfebfbff --- Atenciosamente, =20 Wendell Martins Borges From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 01:43:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49AA0106566C for ; Mon, 16 Nov 2009 01:43:34 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 16C3B8FC12 for ; Mon, 16 Nov 2009 01:43:33 +0000 (UTC) Received: from [192.168.1.241] (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 123D812543B; Mon, 16 Nov 2009 10:25:44 +0900 (JST) From: Daichi GOTO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Nov 2009 10:25:43 +0900 Message-Id: To: freebsd-emulation@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: current@freebsd.org Subject: JFYI: VirtualBox-3.0.51.r22902_2 bridge networking freeze issue (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 01:43:34 -0000 At last, I have found an issue situation of system freeze led by bridge = networking. With Vimage enable built kernel, bridge networking feature will lead = system freeze.=20 checked environment: FreeBSD 9.0-CURRENT #44: Mon Nov 16 09:51:20 JST 2009 amd64 virtualbox-3.0.51.r22902_2 Core2 Quad Q9550 I have replaced to Q9550 instead of Q8300 to get VT feature, but this = was not relevant (But from this change, I got an ability to use 64bit OS. My = test environment has been extended ;-). Second, I have got rid of some compile options=20 (e.x. CPUTYPE=3Dcore2) and ccache caches, but this was not relevant, = too.=20 Third, I have changed my BIOS settings and update thats version, yes = living up to your expectations, this was not relevant, too. Finally, I have rolled back my kernel to GENERIC and bridge networking = works correctly. Step by step adding kernel options, at last, I have found = that Vimage feature is a cause of this problem. Thanks PS Vimage developer, do you have any ideas? Or with this issue, VirtualBox = side=20 should treat this problem? --=20 Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 01:58:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 601FF106568D for ; Mon, 16 Nov 2009 01:58:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 10AEF8FC15 for ; Mon, 16 Nov 2009 01:58:50 +0000 (UTC) Received: by yxe1 with SMTP id 1so312625yxe.3 for ; Sun, 15 Nov 2009 17:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=GdInOwe+p6Zdc/AtjyEh4Nnbw4+C2x9bTrz1FVoIf3w=; b=Rm/wC3NftxzilGpk53yeZ1EzeORh1fbT9FRt6IVGli7DmkHBwOl+ivgq2KCbd5Hkap Gjbcc4Q92cmoJJBbF+HGAfnvpuFMa8HWZmASQbmXBLM9V5cS2j8u5omw499LjIrxB1WL 0eCtPwUpEaQvltEZyVd8pUD7MCZBMol+dFi/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=wzW+G6pC9BAHjI9y1sQ48/jU7fgVUWxThUEbDErPXZx4DfTJJiomNEk6IHuVYX07aL tieKOFhFgFoq17ha8i52On4o36Vnd8M0nrhWySJaKk3g37p85B4vJB0QXqAwC5cCsuYy hA/QXouZzq1QdCdZV9fNkG127fpu1hDfFZl2U= Received: by 10.150.125.24 with SMTP id x24mr12495152ybc.5.1258336730264; Sun, 15 Nov 2009 17:58:50 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm1191306ywi.42.2009.11.15.17.58.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 17:58:48 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 15 Nov 2009 17:58:16 -0800 From: Pyun YongHyeon Date: Sun, 15 Nov 2009 17:58:16 -0800 To: Gonzalo Nemmi Message-ID: <20091116015816.GB1124@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911121912.44926.gnemmi@gmail.com> <20091112220550.GJ15449@michelle.cdnetworks.com> <200911122039.31431.gnemmi@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <200911122039.31431.gnemmi@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Mon, 16 Nov 2009 01:58:51 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote: > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote: > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon wrote: > > > > > Hi, > > > > > > > > > > I had been working on fixing bus_dma(9) bugs and adding TSO > > > > > capability to bge(4). Now TSO is supported for BCM5755 or newer > > > > > controllers. Actually some pre-BCM5755 controllers also support > > > > > TSO with the help of special firmware but the license issue and > > > > > lower performance of firmware based TSO as well as TSO bug I > > > > > intentionally excluded TSO support for pre-BCM5755 controllers. > > > > > You can get the patch form the following URL. The diff was > > > > > generated against latest HEAD. > > > > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff > > > > > > > > Eh, there was a typo so I regenerated the diff. > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.diff > > > > > > Hi > > > Just wanted to know before getting on to it, will your patch help > > > to resolve kern/136876? > > > > My diff includes a fix for assuming PCIe device control register > > and MSI control registers would be reside in fixed address. And > > from the pciconf output I see the your MSI control register is > > located at different address. However bge(4) does not touch that > > register for BCM5906 so I guess my diff may not fix the resume > > issue. > > > > Thanks a lot for your prompt, clear and straight answer. > Would you try attached patch for BCM5906 resume issue? Not sure whether it help or not though. > Regards > Gonzalo Nemmi --ibTvN161/egqYuK8 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.5906.diff" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 199304) +++ sys/dev/bge/if_bge.c (working copy) @@ -2995,6 +2995,15 @@ } } + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + val = CSR_READ_4(sc, BGE_VCPU_STATUS); + CSR_WRITE_4(sc, BGE_VCPU_STATUS, + val | BGE_VCPU_STATUS_DRV_RESET); + val = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); + CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, + val & ~BGE_VCPU_EXT_CTRL_HALT_CPU); + } + /* * Set GPHY Power Down Override to leave GPHY * powered up in D0 uninitialized. @@ -3005,15 +3014,6 @@ /* Issue global reset */ write_op(sc, BGE_MISC_CFG, reset); - if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { - val = CSR_READ_4(sc, BGE_VCPU_STATUS); - CSR_WRITE_4(sc, BGE_VCPU_STATUS, - val | BGE_VCPU_STATUS_DRV_RESET); - val = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); - CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, - val & ~BGE_VCPU_EXT_CTRL_HALT_CPU); - } - DELAY(1000); /* XXX: Broadcom Linux driver. */ --ibTvN161/egqYuK8-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 02:05:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E7A31065694 for ; Mon, 16 Nov 2009 02:05:25 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 162778FC16 for ; Mon, 16 Nov 2009 02:05:25 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1N9qy3-000PQ6-RO; Sun, 15 Nov 2009 21:05:23 -0500 Date: Sun, 15 Nov 2009 21:05:23 -0500 From: Gary Palmer To: Wendell Borges Message-ID: <20091116020523.GA69348@in-addr.com> References: <253062DF-9E44-49C8-BDFB-CB779F41D224@ramenzoni.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <253062DF-9E44-49C8-BDFB-CB779F41D224@ramenzoni.com.br> Cc: freebsd-current@freebsd.org Subject: Re: dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 02:05:25 -0000 On Sun, Nov 15, 2009 at 10:32:43PM -0200, Wendell Borges wrote: > Hi, > > I upgraded to FreeBSD 8.0-RC3 but the message of dmesg shows FreeBSD 7.2-RELEASE-p4, which may be happening? > > > %uname -a > > FreeBSD nfedevel.ramenzoni.com.br 8.0-RC3 FreeBSD 8.0-RC3 #0: Tue Nov 10 > > 07:50:36 UTC 2009 > > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > %dmesg | head > > Copyright (c) 1992-2009 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.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 > > root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz (1596.01-MHz 686-class > > CPU) > > Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 > > Features=0xbfebfbff > It is possible for dmesg to contain information from boots prior to the current one if the boots were all soft reboots. I bet if you look further down the dmesg, or in /var/run/dmesg.boot, you'll see the right kernel version mentioned. Regards, Gary From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 02:16:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E3781065670; Mon, 16 Nov 2009 02:16:01 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0983D8FC08; Mon, 16 Nov 2009 02:16:00 +0000 (UTC) Received: from [192.168.1.241] (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 446B112543B; Mon, 16 Nov 2009 11:16:00 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Daichi GOTO In-Reply-To: Date: Mon, 16 Nov 2009 11:15:59 +0900 Content-Transfer-Encoding: 7bit Message-Id: <4C41BAAF-50D4-4321-BAB3-48967A049CAE@ongs.co.jp> References: To: Ryan Stone X-Mailer: Apple Mail (2.1077) Cc: freebsd-emulation@freebsd.org, current@freebsd.org Subject: Re: JFYI: VirtualBox-3.0.51.r22902_2 bridge networking freeze issue (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 02:16:01 -0000 On Nov 16, 2009, at 10:57 AM, Ryan Stone wrote: > Can you reproduce the problem with WITNESS and INVARIANTS enabled? Test case: FINE: WITNESS/INVARIANTS Enabled, Vimage Disabled FINE: WITNESS/INVARIANTS Disabled, Vimage Disabled FREEZE: WITNESS/INVARIANTS Disabled, Vimage Enabled NOT TESTED: WITNESS/INVARIANTS Enabled, Vimage Enabled I'll test last case ASAP. > It's probably a deadlock, and WITNESS is quite good at identifying > potential deadlocks. > > WITNESS sends its output to the console, so make sure that you're > watching it as you try to reproduce the freeze. Please tell me how to watch messaging to console in such a freeze situation. > Ryan -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 02:25:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DF03106566B; Mon, 16 Nov 2009 02:25:57 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id A32348FC0A; Mon, 16 Nov 2009 02:25:56 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so1656691eyd.9 for ; Sun, 15 Nov 2009 18:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1hIc68gmHyAf8wt/byzZz+T5g5qAX40KynFI4jtzAgc=; b=JEkh5mzDLIo0Q+3g3cKRK0Scqz1t1/o2UtSuAICSenT3dj4M76lJxjJpT6Wf77epbF yuY+JZ2WUTD6kMJwKT44qge1gNrM44Rnp2YK1XR2Ic+SQHiKfNkK9iqGPiydvUiIbE+8 bRPoECUF9MVY58VkuQYqvWgoZwYPy3YB6ZR/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XEXEfFYVl1sv/7Xbwi1YOc1vhjuy/HBErk8jn6xqDnzO8QZ49hWGnQy574UNc5xnoz pNbl/8/d2UvjuQRbzIwgGt7LWyG3erFKrj1xeIFWYnNHL0XQYG0uoQ/yIsFqnQxGBUUp L6QGTOyC08evh2vYEM2WJwx3NXG4rDzy2HcZU= MIME-Version: 1.0 Received: by 10.213.24.1 with SMTP id t1mr4241865ebb.64.1258336654450; Sun, 15 Nov 2009 17:57:34 -0800 (PST) In-Reply-To: References: Date: Sun, 15 Nov 2009 20:57:34 -0500 Message-ID: From: Ryan Stone To: Daichi GOTO Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-emulation@freebsd.org, current@freebsd.org Subject: Re: JFYI: VirtualBox-3.0.51.r22902_2 bridge networking freeze issue (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 02:25:57 -0000 Can you reproduce the problem with WITNESS and INVARIANTS enabled? It's probably a deadlock, and WITNESS is quite good at identifying potential deadlocks. WITNESS sends its output to the console, so make sure that you're watching it as you try to reproduce the freeze. Ryan From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 02:35:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB6AD1065672; Mon, 16 Nov 2009 02:35:54 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A02088FC1B; Mon, 16 Nov 2009 02:35:54 +0000 (UTC) Received: from [192.168.1.241] (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id BE3E812543B; Mon, 16 Nov 2009 11:35:53 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Daichi GOTO In-Reply-To: <4C41BAAF-50D4-4321-BAB3-48967A049CAE@ongs.co.jp> Date: Mon, 16 Nov 2009 11:35:53 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C41BAAF-50D4-4321-BAB3-48967A049CAE@ongs.co.jp> To: Daichi GOTO X-Mailer: Apple Mail (2.1077) Cc: freebsd-emulation@freebsd.org, Ryan Stone , current@freebsd.org Subject: Re: JFYI: VirtualBox-3.0.51.r22902_2 bridge networking freeze issue (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 02:35:55 -0000 On Nov 16, 2009, at 11:15 AM, Daichi GOTO wrote: > On Nov 16, 2009, at 10:57 AM, Ryan Stone wrote: >> Can you reproduce the problem with WITNESS and INVARIANTS enabled? >=20 > Test case: > FINE: WITNESS/INVARIANTS Enabled, Vimage Disabled > FINE: WITNESS/INVARIANTS Disabled, Vimage Disabled > FREEZE: WITNESS/INVARIANTS Disabled, Vimage Enabled > NOT TESTED: WITNESS/INVARIANTS Enabled, Vimage Enabled FINE: WITNESS/INVARIANTS Enabled, Vimage Disabled FINE: WITNESS/INVARIANTS Disabled, Vimage Disabled FREEZE: WITNESS/INVARIANTS Disabled, Vimage Enabled FREEZE: WITNESS/INVARIANTS Enabled, Vimage Enabled Do you have any ideas? > I'll test last case ASAP. >=20 >> It's probably a deadlock, and WITNESS is quite good at identifying >> potential deadlocks. >>=20 >> WITNESS sends its output to the console, so make sure that you're >> watching it as you try to reproduce the freeze. >=20 > Please tell me how to watch messaging to console in such a freeze > situation. >=20 >> Ryan >=20 > --=20 > Daichi GOTO > CEO | ONGS Inc. > 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp > LinkedIn: http://linkedin.com/in/daichigoto >=20 > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to = "freebsd-emulation-unsubscribe@freebsd.org" --=20 Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 02:36:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4942E10656BE for ; Mon, 16 Nov 2009 02:36:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id CC4378FC1F for ; Mon, 16 Nov 2009 02:36:02 +0000 (UTC) Received: (qmail 30614 invoked by uid 399); 16 Nov 2009 02:36:01 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Nov 2009 02:36:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B00BA99.5000009@FreeBSD.org> Date: Sun, 15 Nov 2009 18:36:09 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4B0087C2.9070508@FreeBSD.org> In-Reply-To: <4B0087C2.9070508@FreeBSD.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rui Paulo Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 02:36:03 -0000 Doug Barton wrote: > I upgraded my -current laptop from r199019 to r199291 and on the newer > kernel wpa_supplicant runs but doesn't ever lock in. And the winner is .... r199076! Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 04:38:44 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A57BA1065670 for ; Mon, 16 Nov 2009 04:38:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 510FA8FC08 for ; Mon, 16 Nov 2009 04:38:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id nAG4baWu014287; Sun, 15 Nov 2009 21:37:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 15 Nov 2009 21:37:36 -0700 (MST) Message-Id: <20091115.213736.74735301.imp@bsdimp.com> To: wendell@ramenzoni.com.br From: Warner Losh In-Reply-To: <253062DF-9E44-49C8-BDFB-CB779F41D224@ramenzoni.com.br> References: <253062DF-9E44-49C8-BDFB-CB779F41D224@ramenzoni.com.br> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 04:38:44 -0000 Is that the last boot in your dmesg buffer? Some systems don't clear memory, so you can accumulate multiple boot buffers... Warner From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 04:44:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B46ED1065676 for ; Mon, 16 Nov 2009 04:44:54 +0000 (UTC) (envelope-from daimler3@googlemail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 482EC8FC16 for ; Mon, 16 Nov 2009 04:44:54 +0000 (UTC) Received: by fxm27 with SMTP id 27so5586149fxm.3 for ; Sun, 15 Nov 2009 20:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4gV61NoS9n12/fTl1ougSPiSNIWIFqo4VmVTOya2TvQ=; b=KbECHFGZnevysoFjVRopDP8zqN7F8Xqk1AwWLRSOeVDvnFlrvcCcCzLs+q26EcpmP/ GVqJJq7QljHGA/XfuyrCdPC1uae/5gDYSNz27V+VaZeaY6dAiNcCPCpssnYfSZQoy8DO gAjDdd9+w8BvFkZETTaLq/89gfcjVxpb3ocfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LKxj0lF0imMJsMx+f3ynQe769pvGgzCaufvnrgkZMUHbYRhY4gll8L7B29CcUJpWIl C1gMh5sueja5fNm8+tWySkfyKowR+RAIy+R5GrwLpAjSlRFgIZ2+JY5nkhFF7ztDbuE5 2J8n30lCmoW1WV+r/b1FN14MC4pzBHfqZDQU4= MIME-Version: 1.0 Received: by 10.239.139.148 with SMTP id t20mr720879hbt.93.1258346692575; Sun, 15 Nov 2009 20:44:52 -0800 (PST) In-Reply-To: <791271c80909130708qb1cc45dsa3ec666b9c04d316@mail.gmail.com> References: <791271c80908151025k344d906ar17cc585ae70927c7@mail.gmail.com> <200908152139.02493.hselasky@c2i.net> <791271c80908151621g4aec8548mc64e7c3f43f666ff@mail.gmail.com> <200908170919.47870.hselasky@c2i.net> <791271c80909130708qb1cc45dsa3ec666b9c04d316@mail.gmail.com> Date: Mon, 16 Nov 2009 05:44:52 +0100 Message-ID: <791271c80911152044u73467ddape8effbe8296d4d82@mail.gmail.com> From: Deniz To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: unable to mount root from USB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 04:44:54 -0000 Are you sure this doesn't have to do with the power management of my hdd? Because my hdd turns itself off if it is not in use at the moment and in the PR dmesg is different from mine. Deniz From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 08:35:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6F6106566C; Mon, 16 Nov 2009 08:35:32 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9105D8FC14; Mon, 16 Nov 2009 08:35:31 +0000 (UTC) Received: by bwz5 with SMTP id 5so5676497bwz.3 for ; Mon, 16 Nov 2009 00:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=z+NN0FfNNBjMnxqs7xgVJSidD6TBOBc22BRgmIUOAo8=; b=GU/f9sW/6WlGuHzJedztuEl9lEuh4KBZHlrY3a9guJ0wDUk9yctb388rzzxHCzE40a l8Gzz2N5wR4AZo3rhXrjl5lSkJ27Xz20JEC6EHcfNvfacQ3NE1mPE2gFxfuZI4kLo6A1 cYWY74HPOpWb5uJd2rgOgdLKWO8yMED1BgRpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ug/05eO36bWjb+leF9zkjbR3c10rpdnwPN0ZAOgvG4y/wExug18M1A0KLCGDWG1kxQ LMimo77u/pCwjhNFqyJ9pUmScKhpK9ZhUo2OPI4Pd36GFCo8sZvfUZ4OQoxfDoUukjgy viQuvaS0fjK6OiR2aX8+RESTlxS1hHsY6Q5Io= MIME-Version: 1.0 Received: by 10.213.26.140 with SMTP id e12mr1694550ebc.0.1258360530503; Mon, 16 Nov 2009 00:35:30 -0800 (PST) In-Reply-To: <4B00BA99.5000009@FreeBSD.org> References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> Date: Mon, 16 Nov 2009 09:35:30 +0100 Message-ID: <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> From: Paul B Mahol To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 08:35:32 -0000 On 11/16/09, Doug Barton wrote: > Doug Barton wrote: >> I upgraded my -current laptop from r199019 to r199291 and on the newer >> kernel wpa_supplicant runs but doesn't ever lock in. > > And the winner is .... r199076! What about connection without wpa_supplicant, does it work? You did rebuild world and kernel with NO_CLEAN undefined? Perhaps driver_freebsd.c from wpa_supplicant is not synced with this change. From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 08:49:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEA91106566B; Mon, 16 Nov 2009 08:49:34 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7948FC13; Mon, 16 Nov 2009 08:49:34 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 8856812543B; Mon, 16 Nov 2009 17:49:33 +0900 (JST) Date: Mon, 16 Nov 2009 17:49:33 +0900 From: Daichi GOTO To: freebsd-emulation@FreeBSD.org Message-Id: <20091116174933.4ab2354d.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 08:49:34 -0000 FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox. Boot will stop and consume 100% cpu power during boot sequence as displaying as follow: Trying to mount rott from ufs:/dev/md0 warning: no time-of-day clock registered, system time will not be set accurately checked environment: FreeBSD 9.0-CURRENT #44: Mon Nov 16 09:51:20 JST 2009 amd64 Core2 Quad Q9550 virtualbox-3.0.51.r22902_2 cpu: Core2 Quad Q9550 1-core mem: 1024MB VT-x: enable nested paging: disable Is there anyone can boot 8.0-RC3/amd64 on VirtualBox? -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 10:33:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35589106568D; Mon, 16 Nov 2009 10:33:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id E3F788FC25; Mon, 16 Nov 2009 10:33:53 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1N9yu7-00018z-QR; Mon, 16 Nov 2009 12:33:51 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Daichi GOTO In-reply-to: <20091116174933.4ab2354d.daichi@ongs.co.jp> References: <20091116174933.4ab2354d.daichi@ongs.co.jp> Comments: In-reply-to Daichi GOTO message dated "Mon, 16 Nov 2009 17:49:33 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Nov 2009 12:33:51 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-emulation@FreeBSD.org, current@freebsd.org Subject: Re: FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 10:33:54 -0000 > FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox. > Boot will stop and consume 100% cpu power during boot sequence > as displaying as follow: > > Trying to mount rott from ufs:/dev/md0 > warning: no time-of-day clock registered, system time will not be set accurately > > checked environment: > > FreeBSD 9.0-CURRENT #44: Mon Nov 16 09:51:20 JST 2009 amd64 > Core2 Quad Q9550 > virtualbox-3.0.51.r22902_2 > cpu: Core2 Quad Q9550 1-core > mem: 1024MB > VT-x: enable > nested paging: disable > > Is there anyone can boot 8.0-RC3/amd64 on VirtualBox? it's running ok, but with slight diffs: Virtualbox-3.0.51r23006 (only mod is that I changed the boot.rom, to get pxe boot to work). and the host is 8.0-PRERELEASE From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 10:48:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 380C81065672 for ; Mon, 16 Nov 2009 10:48:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 722D98FC0A for ; Mon, 16 Nov 2009 10:48:31 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA12345; Mon, 16 Nov 2009 12:48:28 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1N9z8G-0000GO-FI; Mon, 16 Nov 2009 12:48:28 +0200 Message-ID: <4B012DDA.4030801@icyb.net.ua> Date: Mon, 16 Nov 2009 12:47:54 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Mark Atkinson References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> <4AFC14BE.7020106@icyb.net.ua> <4AFD1150.1080205@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 10:48:33 -0000 on 13/11/2009 20:13 Mark Atkinson said the following: > Sorry, I only mentioned the difference in that in my case and > the case you listed as: > > 'superpages and no machine check - works' > > Always ends up in either > > * hardware reset on my machine (watchdog or other), or > * bus error during compilation Mark, I said this earlier, I think that the difference is that on your system machine check may be enabled in some form by bios, while on my system it is not. So I have to enable it on OS level to trigger the condition. This difference may come from the fact that I have a simple "consumer" system, while you seem to have a more advanced machine. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 12:47:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A8641065670 for ; Mon, 16 Nov 2009 12:47:00 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id B7BA58FC17 for ; Mon, 16 Nov 2009 12:46:59 +0000 (UTC) Received: from [195.93.241.18] (port=33915 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NA0yv-0006mg-UK for current@freebsd.org; Mon, 16 Nov 2009 15:46:58 +0300 Message-ID: <4B0149C0.30903@lissyara.su> Date: Mon, 16 Nov 2009 15:46:56 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20090824 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: ILLEGAL REQUEST asc:20,0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 12:47:00 -0000 When I attempt copy my hard drive content to USB hard drive, I have it error in logs: Nov 16 15:39:29 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Nov 16 15:39:29 lissyara kernel: (da4:umass-sim1:1:0:0): CAM Status: SCSI Status Error Nov 16 15:39:29 lissyara kernel: (da4:umass-sim1:1:0:0): SCSI Status: Check Condition Nov 16 15:39:29 lissyara kernel: (da4:umass-sim1:1:0:0): ILLEGAL REQUEST asc:20,0 Nov 16 15:39:29 lissyara kernel: (da4:umass-sim1:1:0:0): Invalid command operation code Nov 16 15:39:29 lissyara kernel: (da4:umass-sim1:1:0:0): Unretryable error And, through 2-3 minutes - my system is freeze. I try it with 3 computers (all - CURRENT, 2 - amd64, 1 - x32) I try another USB рввю It not help. All will be have similar behavior (neither not complete copy) lissyara# mount | grep ootFS rootFS on / (zfs, local) tmpRootFS on /tmpRootFS (zfs, local) lissyara# da4 at umass-sim1 bus 1 scbus4 target 0 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 40.000MB/s transfers da4: 38166MB (78165360 512 byte sectors: 255H 63S/T 4865C) lissyara# uname -a FreeBSD lissyara.moskb.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r199307: Mon Nov 16 08:56:21 MSK 2009 root@lissyara.moskb.local:/usr/obj/usr/src/sys/GENERIC amd64 lissyara# zfs list NAME USED AVAIL REFER MOUNTPOINT rootFS 33,4G 195G 32,4G none rootFS/swap 1G 196G 137M - tmpRootFS 1,20G 35,5G 1,20G /tmpRootFS lissyara# From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 15:18:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAFE0106568F; Mon, 16 Nov 2009 15:18:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 013BA8FC24; Mon, 16 Nov 2009 15:18:26 +0000 (UTC) Received: by fxm27 with SMTP id 27so6115049fxm.3 for ; Mon, 16 Nov 2009 07:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=BeIpS/i+8HFnUDB8gAtPk9tDRQqLUGs1XGAHMEkmfj0=; b=aXtdHsy5i+FXBRAKjRWBrDnpiVvU1yh09wmp4OR0HJygsbZq6tjvXlF2+n3zOCeWXa QIcFCv3ngF2ZznE5+pvl8PPI8AHy/vj5K0R1jbAPq4WkTVCZzdqMLbTiJWW7gdSHM017 MOxmBMcecgzuSRTe61L8LgsBlMrxu3c+1YVqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=kHGgjUL8pZPPzVmdM/moODXAGUnsmOL7D2hHRI+53RtScICj61/Apwcj0H3qcbNwc7 5INa0KBNpegThMZEEixMmXdPx+cdmCBAhA/Ev3wiKAurVxeFcGb+3Zk3wmaV3s3A41dE RhniBCbYioLrgQmJkdJ6mpqKlmi3PPFBIhneU= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.97.132 with SMTP id l4mr1151516fan.100.1258384705627; Mon, 16 Nov 2009 07:18:25 -0800 (PST) Date: Mon, 16 Nov 2009 16:18:25 +0100 X-Google-Sender-Auth: b3fb3e81f439f799 Message-ID: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> From: Attilio Rao To: freebsd-current@freebsd.org, Alexander Kabaev , Alfred Perlstein , Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: Subject: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 15:18:27 -0000 This patch allows gcore to use the ptrace interface rather than procfs: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore.diff The main visible effect of that is that gcore can now work on a per-thread scope, offering a granularity procfs can't reach. A downside, though, is that the process to be targeted is going to be stopped with ptrace. This patch has been contributed back by Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 15:42:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3685106568F for ; Mon, 16 Nov 2009 15:42:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 54C708FC22 for ; Mon, 16 Nov 2009 15:42:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA4CAUuDaFvH/2dsb2JhbADWYYQ8BIFt X-IronPort-AV: E=Sophos;i="4.44,751,1249272000"; d="scan'208";a="54070821" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 16 Nov 2009 10:42:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 9858E1084D8C; Mon, 16 Nov 2009 10:42:25 -0500 (EST) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD8r5caETmR8; Mon, 16 Nov 2009 10:42:24 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 1FE431084F19; Mon, 16 Nov 2009 10:42:24 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id nAGFoGu27797; Mon, 16 Nov 2009 10:50:16 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 16 Nov 2009 10:50:16 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: =?utf-8?B?R2Vycml0IEvDvGhu?= In-Reply-To: <20091116112631.e8733905.gerrit@pmp.uni-hannover.de> Message-ID: References: <20091112182414.cebec1df.gerrit@pmp.uni-hannover.de> <20091113103626.414acdbc.gerrit@pmp.uni-hannover.de> <20091116112631.e8733905.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1258386616=:23864" Cc: freebsd-current@freebsd.org Subject: Re: nfsv4 FreeBSD server vs. Linux client I/O error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 15:42:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-758783491-1258386616=:23864 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 16 Nov 2009, Gerrit K=C3=BChn wrote: > On Fri, 13 Nov 2009 11:10:21 -0500 (EST) Rick Macklem > wrote about Re: nfsv4 FreeBSD server vs. Linux > client I/O error: > > Hello Rick, > > RM> The line "V4: /" in /etc/exports does not export the "/" file system, > RM> it simply sets where the root is for the client mount. Suppose you > RM> have a root file system and then a separate file system mounted at > RM> /export that you have exported, using a /etc/exports that looks like: > RM> > RM> /export -alldirs ha-cluster > RM> V4: / ha-cluster > RM> > RM> Now, this means that ha-cluster can mount and use /export and that th= e > RM> NFSv4 root starts at "/", so it "sees" this as /export at the client. > > Ah, now I finally understand this. Thank you very much! > I did not get it from the manpages that I actually need two lines in > exports to get this going. > OTOH it seems to be a quite nice idea, because then I can probably keep > zfs features for setting nfs exports, because they look just the same and > I have to add only one V4-line. > > RM> The other way to set things up would be to set the NFSv4 root > RM> at /export. For this case, the /etc/exports file might be: > RM> > RM> /export -alldirs ha-cluster > RM> V4: /export ha-cluster > RM> > RM> Then, if on ha-cluster you did: > RM> # mount -t nfs4 nfs:/ /mnt > RM> - it would work, with /export mounted at /mnt > > This is what I am doing here, and it works fine now after adding the > missing exports lines. I can access and list the dirs. > > However, I have one more problem to solve now: All uids/gids appear to be > mapped to nobody although both client and server should use sec=3Dsys by > default: > > pt-ws1 ~ # ls -l /mnt/ > total 11 > drwxr-xr-x 4 nobody nobody 4 Nov 12 11:46 home > drwxr-xr-x 35 nobody nobody 44 Nov 11 23:01 opt > drwxr-xr-x 2 nobody nobody 2 Nov 11 15:26 system > -rw-r--r-- 1 nobody nobody 0 Oct 27 14:13 test > > > Do you know why this happens and what I can do to get uid/gid working lik= e > with nfs3? > Yep, in NFSv4 the user/groups go on the wire as names (although for=20 AUTH_SYS, there are still the numbers in the rpc's authentication header). They look like @, where is a "user domain", which I think is still underdefined by ietf. (There was a plan to add a new resource record type to DNS, but I don't think it has happened yet.) This implies that it can be almost anything, but has to be the same on the client and server. On FreeBSD, it will be the domain part of the server's name by default (for nfsv4-server.cis.uoguelph.ca --> cis.uoguelph.ca) and this can be overridden by setting the "-domain XXX" option for nfsuserd. For linux, it is usually set in /etc/idmapd.conf and is usually set to local.domain the way most distros ship these days. To make it work, either change the Linux client to your dns domain or set nfsuserd_flags=3D"-domain local.domain" in FreeBSD's /etc/rc.conf. > > cu > Gerrit > > P.S.: And one more question comes to my mind: How do I prevent a dir from > being mountable with nfs3? With the extra exports line it will also be > available as nfs3, won't it? > Yep, there is currently no way to say that an exported fs is for nfsv4 only. There are sysctl's that can restrict what versions of nfs the experimental server handles, but they apply to all mounts. If a lot of people need this feature, I can look at adding it, but my nfs todo list is getting pretty long and one of them is to look at a possible mountd replacement. (This might be a part of that?) Have fun with it, rick ps: I hope you didn't mind me adding freebsd-current@ as a cc, since I figured others will need the info someday. ---559023410-758783491-1258386616=:23864-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 16:15:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E265F106566B for ; Mon, 16 Nov 2009 16:15:30 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6BEF48FC22 for ; Mon, 16 Nov 2009 16:15:29 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id nAGGFR0S014946; Mon, 16 Nov 2009 17:15:28 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 30AE924; Mon, 16 Nov 2009 17:15:27 +0100 (CET) Date: Mon, 16 Nov 2009 17:15:27 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Rick Macklem Message-Id: <20091116171527.0b44bae8.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20091112182414.cebec1df.gerrit@pmp.uni-hannover.de> <20091113103626.414acdbc.gerrit@pmp.uni-hannover.de> <20091116112631.e8733905.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.11.16.160325 Cc: freebsd-current@freebsd.org Subject: Re: nfsv4 FreeBSD server vs. Linux client I/O error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 16:15:31 -0000 On Mon, 16 Nov 2009 10:50:16 -0500 (EST) Rick Macklem wrote about Re: nfsv4 FreeBSD server vs. Linux client I/O error: RM> > P.S.: And one more question comes to my mind: How do I prevent a dir RM> > from being mountable with nfs3? With the extra exports line it will RM> > also be available as nfs3, won't it? RM> Yep, there is currently no way to say that an exported fs is for nfsv4 RM> only. There are sysctl's that can restrict what versions of nfs the RM> experimental server handles, but they apply to all mounts. RM> If a lot of people need this feature, I can look at adding it, but RM> my nfs todo list is getting pretty long and one of them is to look RM> at a possible mountd replacement. (This might be a part of that?) Not for me, I do not need the feature. I was only thinking about it because the better security of nfsv4 is easily gotten around when you allow for the old v3 mounts in parallel. RM> ps: I hope you didn't mind me adding freebsd-current@ as a cc, since RM> I figured others will need the info someday. Yes, of course. I also had the plan to cc: the list, but then forgot about it. Thanks for your support. cu Gerrit From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 16:37:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E96B410656A4 for ; Mon, 16 Nov 2009 16:37:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 93F7B8FC25 for ; Mon, 16 Nov 2009 16:37:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPIOAUuDaFvJ/2dsb2JhbADWeIQ8BIFt X-IronPort-AV: E=Sophos;i="4.44,752,1249272000"; d="scan'208";a="54079247" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 16 Nov 2009 11:37:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 0066AFB80A4; Mon, 16 Nov 2009 11:37:25 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb2+lUoj9QXh; Mon, 16 Nov 2009 11:37:25 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 1A0A6FB80A6; Mon, 16 Nov 2009 11:37:25 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id nAGGjHU08426; Mon, 16 Nov 2009 11:45:17 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 16 Nov 2009 11:45:17 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: =?utf-8?B?R2Vycml0IEvDvGhu?= In-Reply-To: <20091116171527.0b44bae8.gerrit@pmp.uni-hannover.de> Message-ID: References: <20091112182414.cebec1df.gerrit@pmp.uni-hannover.de> <20091113103626.414acdbc.gerrit@pmp.uni-hannover.de> <20091116112631.e8733905.gerrit@pmp.uni-hannover.de> <20091116171527.0b44bae8.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1258389917=:7499" Cc: freebsd-current@freebsd.org Subject: Re: nfsv4 FreeBSD server vs. Linux client I/O error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 16:37:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1258389917=:7499 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 16 Nov 2009, Gerrit K=C3=BChn wrote: > > Not for me, I do not need the feature. I was only thinking about it > because the better security of nfsv4 is easily gotten around when you > allow for the old v3 mounts in parallel. > You can use the "sec=3D" export option to restrict mount points to only allowing Kerberos (this works for NFSv3 as well as NFSv4) and is what will give you better security. (It's not an NFSv4 specific feature, it just happens to be required by the NFSv4 RFC.) rick ---559023410-851401618-1258389917=:7499-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 16:43:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420521065672; Mon, 16 Nov 2009 16:43:59 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 97B028FC0A; Mon, 16 Nov 2009 16:43:58 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id D7D7E28; Mon, 16 Nov 2009 17:30:21 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Mon, 16 Nov 2009 17:26:10 +0100 To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 16:43:59 -0000 After installkernel/installworld my machine stops booting with the following error message: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type lld FreeBSD/i386 boot Default: pgpool:/boot/kernel/kernel boot: ZFS: unexpected object set type lld This is 7.2-STABLE, amd64, zpool on single logical device (ciss(4), hardware RAID5), root on ZFS (using zfsboot). After the failure I booted the server from an external device with UFS and then I did rollback of /usr and / datasets. The machine was still not bootable. Scrub went without errors. Then I read this thread and applied Robert Noland's and Matt Reimer's patches -- and they didn't help. Then I grabbed following files from -CURRENT (svn rev. 198420): /sys/boot/i386/zfsboot/zfsboot.c /sys/boot/zfs/zfs.c /sys/boot/zfs/zfsimpl.c /sys/cddl/boot/zfs/zfsimpl.h and I did: # cd /usr/src/sys/boot/ # make obj ; make depend ; make # cd i386/loader # make install # cd /usr/src/sys/boot/i386/zfsboot # make install # sysctl kern.geom.debugflags=16 # dd if=/boot/zfsboot of=/dev/da0 count=1 # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 # reboot (is this procedure of updating zfsboot correct?) After that, an error was slightly different (printf was fixed): ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type 0 FreeBSD/i386 boot Default: pgpool:/boot/kernel/kernel boot: ZFS: unexpected object set type 0 Additional information: # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT pgpool 4.06T 2.17T 1.89T 53% ONLINE - # zpool status pool: pgpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM pgpool ONLINE 0 0 0 da0 ONLINE 0 0 0 errors: No known data errors # zfs list pgpool/ROOTFS NAME USED AVAIL REFER MOUNTPOINT pgpool/ROOTFS 568M 1.80T 55.3M legacy # zpool get all pgpool NAME PROPERTY VALUE SOURCE pgpool size 4.06T - pgpool used 2.17T - pgpool available 1.89T - pgpool capacity 53% - pgpool altroot - default pgpool health ONLINE - pgpool guid 3920915583055727184 - pgpool version 13 default pgpool bootfs pgpool/ROOTFS local pgpool delegation on default pgpool autoreplace off default pgpool cachefile - default pgpool failmode wait default pgpool listsnapshots off default loader.conf: usb_load="YES" uplcom_load="YES" umass_load="YES" ugen_load="YES" ukbd_load="YES" random_load="YES" loader_color="YES" vfs.root.mountfrom="zfs:pgpool/ROOTFS" zfs_load="YES" autoboot_delay="2" FreeBSD 7.2-STABLE #0: Fri Jun 19 13:27:29 CEST 2009 (as I mentioned above, there was the rollback) ciss0: port 0xe800-0xe8ff mem 0xdef00000-0xdeffffff,0xdeeff000-0xdeefffff irq 35 at device 0.0 on pci4 ciss0: [ITHREAD] da0 at ciss0 bus 0 target 0 lun 0 I would rather not to upgrade the whole system to -CURRENT. What should I do in this situation? Is there any other patch that I could apply or any workaround for this issue? Is there possibility to switch from zfsboot to gptzfsboot without loosing data? Or maybe I did something wrong? -- am From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 16:59:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6A2106566B; Mon, 16 Nov 2009 16:59:54 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D748D8FC1E; Mon, 16 Nov 2009 16:59:53 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAGGxnp1081455 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 11:59:50 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Mon, 16 Nov 2009 10:59:44 -0600 Message-Id: <1258390784.2303.42.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 16:59:54 -0000 On Mon, 2009-11-16 at 17:26 +0100, Emil Smolenski wrote: > After installkernel/installworld my machine stops booting with the > following error message: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type lld > > FreeBSD/i386 boot > Default: pgpool:/boot/kernel/kernel > boot: > ZFS: unexpected object set type lld > > This is 7.2-STABLE, amd64, zpool on single logical device (ciss(4), > hardware RAID5), root on ZFS (using zfsboot). After the failure I booted > the server from an external device with UFS and then I did rollback of > /usr and / datasets. The machine was still not bootable. Scrub went > without errors. > Then I read this thread and applied Robert Noland's and Matt Reimer's > patches -- and they didn't help. Then I grabbed following files from > -CURRENT (svn rev. 198420): Matt's patch only effects raidz volumes. > /sys/boot/i386/zfsboot/zfsboot.c > /sys/boot/zfs/zfs.c > /sys/boot/zfs/zfsimpl.c > /sys/cddl/boot/zfs/zfsimpl.h > > and I did: > > # cd /usr/src/sys/boot/ > # make obj ; make depend ; make > # cd i386/loader > # make install > # cd /usr/src/sys/boot/i386/zfsboot > # make install > # sysctl kern.geom.debugflags=16 > # dd if=/boot/zfsboot of=/dev/da0 count=1 > # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > # reboot > > (is this procedure of updating zfsboot correct?) This should be correct for updating the first stage bootstrap code. The loader (boot/loader) is actually updated during installworld. > After that, an error was slightly different (printf was fixed): > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type 0 This has my patch applied, which fixes the printf's so that they work correctly among other things. > FreeBSD/i386 boot > Default: pgpool:/boot/kernel/kernel > boot: > ZFS: unexpected object set type 0 > > Additional information: > > # zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > pgpool 4.06T 2.17T 1.89T 53% ONLINE - > > # zpool status > pool: pgpool > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > pgpool ONLINE 0 0 0 > da0 ONLINE 0 0 0 > > errors: No known data errors > > # zfs list pgpool/ROOTFS > NAME USED AVAIL REFER MOUNTPOINT > pgpool/ROOTFS 568M 1.80T 55.3M legacy > > # zpool get all pgpool > NAME PROPERTY VALUE SOURCE > pgpool size 4.06T - > pgpool used 2.17T - > pgpool available 1.89T - > pgpool capacity 53% - > pgpool altroot - default > pgpool health ONLINE - > pgpool guid 3920915583055727184 - > pgpool version 13 default > pgpool bootfs pgpool/ROOTFS local > pgpool delegation on default > pgpool autoreplace off default > pgpool cachefile - default > pgpool failmode wait default > pgpool listsnapshots off default > > loader.conf: > usb_load="YES" > uplcom_load="YES" > umass_load="YES" > ugen_load="YES" > ukbd_load="YES" > random_load="YES" > loader_color="YES" > vfs.root.mountfrom="zfs:pgpool/ROOTFS" > zfs_load="YES" > autoboot_delay="2" > > FreeBSD 7.2-STABLE #0: Fri Jun 19 13:27:29 CEST 2009 > (as I mentioned above, there was the rollback) > > ciss0: port 0xe800-0xe8ff mem > 0xdef00000-0xdeffffff,0xdeeff000-0xdeefffff irq 35 at device 0.0 on pci4 > ciss0: [ITHREAD] > da0 at ciss0 bus 0 target 0 lun 0 > > I would rather not to upgrade the whole system to -CURRENT. What should I > do in this situation? Is there any other patch that I could apply or any > workaround for this issue? Is there possibility to switch from zfsboot to > gptzfsboot without loosing data? Or maybe I did something wrong? I don't think that you can switch to gptzfsboot as that would require repartitioning the device. A little more context though, was this working before? Or is this a new install? robert. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 17:34:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71817106566C for ; Mon, 16 Nov 2009 17:34:43 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by mx1.freebsd.org (Postfix) with ESMTP id 23E0E8FC1C for ; Mon, 16 Nov 2009 17:34:42 +0000 (UTC) Received: by ywh8 with SMTP id 8so5138519ywh.3 for ; Mon, 16 Nov 2009 09:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=hs9m4M37k1qjnNW8ZiE+eS1uaXQ7THFjQII432am7lc=; b=qY5U+XxmPJjzThc9X3MrUTkZEYfTqDL9I8FeF2DEKuI43UVMBKOnNSJVDho2Z4x94o +vKip8xRZzlqKDrTfAIZslLBgzNa8cJ6pEwo/fud5ERsTt+O9DWP3V9n0xzl1cBJdyBR Lk3wAthVWu9sO8ZuubkNy7oNcJANhIiRH/WnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=AMrpgJcYfN+G7TiJGYz4WOKVbEJa8FwkAAGmUoTjtYU1caq5Z3C1c5Dob/j5m8s1Tr mHW3EsA3pfXsrojTa3ZSyPk3sbTCJ+qDi+P/QbGtVYgv3XGZ0DlDj7grLUH6sXbVyzF1 lFUOSMFNxuAi7U+ZLMxs1KL+yQPt6ZOoovtGc= Received: by 10.100.233.2 with SMTP id f2mr4702180anh.129.1258392878327; Mon, 16 Nov 2009 09:34:38 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 8sm1752969yxg.6.2009.11.16.09.34.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 09:34:37 -0800 (PST) From: Gonzalo Nemmi To: pyunyh@gmail.com Date: Mon, 16 Nov 2009 15:34:33 -0200 User-Agent: KMail/1.9.10 References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911122039.31431.gnemmi@gmail.com> <20091116015816.GB1124@michelle.cdnetworks.com> In-Reply-To: <20091116015816.GB1124@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911161534.34028.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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, 16 Nov 2009 17:34:43 -0000 On Sunday 15 November 2009 11:58:16 pm Pyun YongHyeon wrote: > On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote: > > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote: > > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon wrote: > > > > > > Hi, > > > > > > > > > > > > I had been working on fixing bus_dma(9) bugs and adding TSO > > > > > > capability to bge(4). Now TSO is supported for BCM5755 or > > > > > > newer controllers. Actually some pre-BCM5755 controllers > > > > > > also support TSO with the help of special firmware but the > > > > > > license issue and lower performance of firmware based TSO > > > > > > as well as TSO bug I intentionally excluded TSO support for > > > > > > pre-BCM5755 controllers. You can get the patch form the > > > > > > following URL. The diff was generated against latest HEAD. > > > > > > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff > > > > > > > > > > Eh, there was a typo so I regenerated the diff. > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.diff > > > > > > > > Hi > > > > Just wanted to know before getting on to it, will your patch > > > > help to resolve kern/136876? > > > > > > My diff includes a fix for assuming PCIe device control register > > > and MSI control registers would be reside in fixed address. And > > > from the pciconf output I see the your MSI control register is > > > located at different address. However bge(4) does not touch that > > > register for BCM5906 so I guess my diff may not fix the resume > > > issue. > > > > Thanks a lot for your prompt, clear and straight answer. > > Would you try attached patch for BCM5906 resume issue? Not sure > whether it help or not though. Hi Pyun! Sorry for the delay, I was out of town and just got back. I'm downloading RC3 as of now. Then I will install: edit make.conf edit src.conf buildworld buildkernel installkernel reboot mergemaster -p make installworld reboot cp bge.diff bge.patch cd /usr/src/sys/dev/bge && patch < /path/to/patch make make install clean kldunload if_bge kldload if_bge pciconf -lcvb ifconfig bge0 up acpiconf -s3 ... and hpefully .. resume from S3 .. Is that ok with you or would you like me to do it in another way? try some more stuff? Some test in particular? Best Regards and thanks for the patch Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 17:55:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93E1F1065695 for ; Mon, 16 Nov 2009 17:55:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 47AC88FC1F for ; Mon, 16 Nov 2009 17:55:24 +0000 (UTC) Received: by yxe1 with SMTP id 1so937014yxe.3 for ; Mon, 16 Nov 2009 09:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=6S5o1NPirsWz4eG9U4buK8juiyk+EAX52/Co3mFBo9o=; b=ZlJ/gUpEpYjvr2tRKrx3fyVaap7Z7zqlgUNV6q9+5ngLCMhjAbhcrb2oVCSK6BzIop DEjnafHOwGEcJqZTF+WbybGfezCIyhTzJfrn1FUeXoiT4YPB9OdFG/Yew8blMt3asF93 Ry85y6CANo+lJ733PHRtH/KomHv8zrX+e5RXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=EdRv7F87ZSlXCF8AWX75Gs6wBru/XEbv5t4F4pEzD0V9iHWmOPjZgpfNNr6VzeKoa2 7UTzVF9scKlRzQFUZmsi6luf2+1yfAl1axb1B8MHaZ6FyrAEYBWdyHvWKJf3NOrQKdvh 6gG0zHkyXv91bD7t0K7PYDmoWSwFoVgAI0RRA= Received: by 10.101.197.40 with SMTP id z40mr2834841anp.68.1258394123565; Mon, 16 Nov 2009 09:55:23 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm963966ywf.55.2009.11.16.09.55.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 09:55:22 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 16 Nov 2009 09:54:50 -0800 From: Pyun YongHyeon Date: Mon, 16 Nov 2009 09:54:50 -0800 To: Gonzalo Nemmi Message-ID: <20091116175450.GB1262@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911122039.31431.gnemmi@gmail.com> <20091116015816.GB1124@michelle.cdnetworks.com> <200911161534.34028.gnemmi@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911161534.34028.gnemmi@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Mon, 16 Nov 2009 17:55:24 -0000 On Mon, Nov 16, 2009 at 03:34:33PM -0200, Gonzalo Nemmi wrote: > On Sunday 15 November 2009 11:58:16 pm Pyun YongHyeon wrote: > > On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote: > > > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote: > > > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > > > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I had been working on fixing bus_dma(9) bugs and adding TSO > > > > > > > capability to bge(4). Now TSO is supported for BCM5755 or > > > > > > > newer controllers. Actually some pre-BCM5755 controllers > > > > > > > also support TSO with the help of special firmware but the > > > > > > > license issue and lower performance of firmware based TSO > > > > > > > as well as TSO bug I intentionally excluded TSO support for > > > > > > > pre-BCM5755 controllers. You can get the patch form the > > > > > > > following URL. The diff was generated against latest HEAD. > > > > > > > > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff > > > > > > > > > > > > Eh, there was a typo so I regenerated the diff. > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.diff > > > > > > > > > > Hi > > > > > Just wanted to know before getting on to it, will your patch > > > > > help to resolve kern/136876? > > > > > > > > My diff includes a fix for assuming PCIe device control register > > > > and MSI control registers would be reside in fixed address. And > > > > from the pciconf output I see the your MSI control register is > > > > located at different address. However bge(4) does not touch that > > > > register for BCM5906 so I guess my diff may not fix the resume > > > > issue. > > > > > > Thanks a lot for your prompt, clear and straight answer. > > > > Would you try attached patch for BCM5906 resume issue? Not sure > > whether it help or not though. > > Hi Pyun! > Sorry for the delay, I was out of town and just got back. > I'm downloading RC3 as of now. Then I will install: > edit make.conf > edit src.conf > buildworld > buildkernel > installkernel > reboot > > mergemaster -p > make installworld > reboot > > cp bge.diff bge.patch > cd /usr/src/sys/dev/bge && patch < /path/to/patch > make > make install clean > kldunload if_bge Not sure you removed bge in GENERIC kernel configuration file. > kldload if_bge > pciconf -lcvb > ifconfig bge0 up > acpiconf -s3 > > ... and hpefully .. resume from S3 .. > > Is that ok with you or would you like me to do it in another way? That's ok. At first I wanted to add WOL to wake up bge(4) with magic packet but bge(4) seems to require a lot of workaround for each controller and it's too complex to implement at this time. Just want to know whether bge(4) can resume from suspend. > try some more stuff? > Some test in particular? > > Best Regards and thanks for the patch > Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 18:06:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28491065695 for ; Mon, 16 Nov 2009 18:06:01 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by mx1.freebsd.org (Postfix) with ESMTP id 763388FC1C for ; Mon, 16 Nov 2009 18:06:01 +0000 (UTC) Received: by ywh8 with SMTP id 8so5172526ywh.3 for ; Mon, 16 Nov 2009 10:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=wQaLz8fvvLBFAhjuMj6E0LhykjpbVxRDI3MwXv79Kg4=; b=qpdBFVBWPCo7UzQZSlpm66u0kyNmR+j5Vo/8AW4jplzIjahE+QXbp851ibIVVXyaDj mIX0umAaFu9Oi4aTUY1JlfuxOm9OOCRNQ7nGJ6GjtnUepzS3t7miWpdun34TkpK5zGyt Li/RybBCzBbphjIqRLbi/Ky17CGOPu7yYSp6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=FxMTUhtnfKtnH509P7dry26s3Dv8B2uxQquRyWtnH/2qvGTZtiYdZpyvO9peKm7GLn STBhA/ETW45Z7klj/tEtA842P/X/PLYqfM12nHURSO6d+DCJKBF3P7HyzTK7xgXp8j0V kpmtlEjx3q6urAG/nceTyCdzV7EhQvsn7jTbY= Received: by 10.101.142.31 with SMTP id u31mr893003ann.159.1258394757218; Mon, 16 Nov 2009 10:05:57 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 35sm1743416yxh.33.2009.11.16.10.05.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 10:05:56 -0800 (PST) From: Gonzalo Nemmi To: pyunyh@gmail.com Date: Mon, 16 Nov 2009 16:05:53 -0200 User-Agent: KMail/1.9.10 References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911161534.34028.gnemmi@gmail.com> <20091116175450.GB1262@michelle.cdnetworks.com> In-Reply-To: <20091116175450.GB1262@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911161605.53577.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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, 16 Nov 2009 18:06:01 -0000 On Monday 16 November 2009 3:54:50 pm Pyun YongHyeon wrote: > On Mon, Nov 16, 2009 at 03:34:33PM -0200, Gonzalo Nemmi wrote: > > On Sunday 15 November 2009 11:58:16 pm Pyun YongHyeon wrote: > > > On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote: > > > > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote: > > > > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > > > > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > > > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I had been working on fixing bus_dma(9) bugs and adding > > > > > > > > TSO capability to bge(4). Now TSO is supported for > > > > > > > > BCM5755 or newer controllers. Actually some pre-BCM5755 > > > > > > > > controllers also support TSO with the help of special > > > > > > > > firmware but the license issue and lower performance of > > > > > > > > firmware based TSO as well as TSO bug I intentionally > > > > > > > > excluded TSO support for pre-BCM5755 controllers. You > > > > > > > > can get the patch form the following URL. The diff was > > > > > > > > generated against latest HEAD. > > > > > > > > > > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.dif > > > > > > > >f > > > > > > > > > > > > > > Eh, there was a typo so I regenerated the diff. > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.dif > > > > > > >f > > > > > > > > > > > > Hi > > > > > > Just wanted to know before getting on to it, will your > > > > > > patch help to resolve kern/136876? > > > > > > > > > > My diff includes a fix for assuming PCIe device control > > > > > register and MSI control registers would be reside in fixed > > > > > address. And from the pciconf output I see the your MSI > > > > > control register is located at different address. However > > > > > bge(4) does not touch that register for BCM5906 so I guess my > > > > > diff may not fix the resume issue. > > > > > > > > Thanks a lot for your prompt, clear and straight answer. > > > > > > Would you try attached patch for BCM5906 resume issue? Not sure > > > whether it help or not though. > > > > Hi Pyun! > > Sorry for the delay, I was out of town and just got back. > > I'm downloading RC3 as of now. Then I will install: > > edit make.conf > > edit src.conf > > buildworld > > buildkernel > > installkernel > > reboot > > > > mergemaster -p > > make installworld > > reboot > > > > cp bge.diff bge.patch > > cd /usr/src/sys/dev/bge && patch < /path/to/patch > > make > > make install clean > > kldunload if_bge > > Not sure you removed bge in GENERIC kernel configuration file. Oh! Sorry for not being clear on that point. Due to the problems I've had with bge(4), I do remove it from GENERIC .. Actually .. most of my kernels are named NOBGE ;) > > kldload if_bge > > pciconf -lcvb > > ifconfig bge0 up > > acpiconf -s3 > > > > ... and hpefully .. resume from S3 .. > > > > Is that ok with you or would you like me to do it in another way? > > That's ok. At first I wanted to add WOL to wake up bge(4) with > magic packet but bge(4) seems to require a lot of workaround for > each controller and it's too complex to implement at this time. > Just want to know whether bge(4) can resume from suspend. Perfetc then, I'll proceed as described above and mail you back as soon as I have some results to let you know :) Once Again, thanks for the patch Pyun :) Best Regards Gonzalo Nemmi > > try some more stuff? > > Some test in particular? > > > > Best Regards and thanks for the patch > > Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 18:13:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98B381065670 for ; Mon, 16 Nov 2009 18:13:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 45A6C8FC12 for ; Mon, 16 Nov 2009 18:13:36 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so1088105qwb.7 for ; Mon, 16 Nov 2009 10:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=jffwZkgp1DinzfaHhzIWmIXocXSm19H/pCFmSs6EnwA=; b=pIeCWoXf1WSZQASeXQc+DvEk/7M9W+Ktaqpa5ein98ebIiA86DMx5hVZvO8Vxu19eL +uKW4y24RhNr4dUfUOeC/blzK0fOEEnEKnSetcQRi1UmB0sbEETPV8OB6jJ54OZ8EOVm 9FPjTbdbGbAZHl+dg2M9AN2PhpYAZPe01++v4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YFh6gdvz5QVMq1zbgu+INJmFBskEWvc2hKriH/evm3715jxKYcF8ZA/YAuYu3qX08f /PHfhcR7uZDJFW9xYQojxRSroFzLKTCn7CinBhcLH+hkBtmLM9spKVe9xBvT9cQXfJ5q WAMwWsGFsj1V7MVrfOxAzWh1/oEbpMdsu2MwY= Received: by 10.224.121.203 with SMTP id i11mr4963054qar.199.1258395216574; Mon, 16 Nov 2009 10:13:36 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm2643403qyk.9.2009.11.16.10.13.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 10:13:35 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 16 Nov 2009 10:13:04 -0800 From: Pyun YongHyeon Date: Mon, 16 Nov 2009 10:13:04 -0800 To: Gleb Kurtsou Message-ID: <20091116181304.GC1262@michelle.cdnetworks.com> References: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> <20091111231426.GF15449@michelle.cdnetworks.com> <20091115091309.GA1539@tops.skynet.lt> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20091115091309.GA1539@tops.skynet.lt> User-Agent: Mutt/1.4.2.3i Cc: Mel Flynn , freebsd-current@freebsd.org Subject: Re: Possible regression with msk driver 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: Mon, 16 Nov 2009 18:13:37 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Nov 15, 2009 at 11:13:10AM +0200, Gleb Kurtsou wrote: > On (11/11/2009 15:14), Pyun YongHyeon wrote: > > On Wed, Nov 11, 2009 at 11:11:51PM +0100, Mel Flynn wrote: > > > Hi, > > > > > > I just booted a box from 7.2-p4 to FreeBSD 8.0-PRERELEASE #0 r199185. It > > > didn't ping, even though the interface was marked up and active. No traffic at > > > all. > > > > > > The fix was to ifconfig msk0 down; ifconfig msk0 up. From then on, everything > > > worked and still is: > > > mskc0: port 0xe800-0xe8ff mem > > > 0xf9efc000-0xf9efffff irq 16 at device 0.0 on pci3 > > > msk0: on mskc0 > > > msk0: Ethernet address: 00:1b:fc:e3:9b:6a > > > miibus0: on msk0 > > > e1000phy0: PHY 0 on miibus0 > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > 1000baseT-FDX, auto > > > mskc0: [FILTER] > > > > > > mskc0@pci0:3:0:0: class=0x020000 card=0x826e1043 chip=0x436411ab > > > rev=0x12 hdr=0x00 > > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > > device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' > > > class = network > > > subclass = ethernet > > > > > > msk0: flags=8843 metric 0 mtu 1500 > > > options=11a > > > ether 00:1b:fc:xx:xx:xx > > > inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.255 > > > media: Ethernet autoselect (1000baseT ) > > > status: active > > > > > > Now - this machine still had 7.x /etc/rc.d, but since ifconfig down/up fixed > > > the problem I don't know if this is a likely suspect. > > > > > > > Most likely it lost link state changes so I guess msk(4) still > > think it has no established link. > > Because there had been several problems with EC Ultra + 88E1149 I'm > > not sure it's newly introduced regression though. There are some > > changes in CURRENT. Would you try latest msk(4)/e1000phy(4) in > > CURRENT? I think you can download the following files from CURRENT. > > sys/dev/msk/if_msk.c > > sys/dev/msk/if_mskreg.h > > sys/dev/mii/e1000phy.c > > sys/dev/mii/e1000phyreg.h > I experience similar problem. After boot msk0 status is active, but I'm > not able to send anything: > % ping 172.21.21.21 > PING 172.21.21.21 (172.21.21.21): 56 data bytes > ping: sendto: No buffer space available > ping: sendto: No buffer space available > > After unplugging cable and putting it back everything works as > expected: > % ping 172.21.21.21 > PING 172.21.21.21 (172.21.21.21): 56 data bytes > 64 bytes from 172.21.21.21: icmp_seq=0 ttl=64 time=0.904 ms > > It is 100% reproducible, running recent current. > > % uname -a > FreeBSD tops 9.0-CURRENT FreeBSD 9.0-CURRENT #17 r199274+c8076f9: Sat Nov 14 22:59:26 EET 2009 root@tops:/usr/obj/usr/freebsd-src/local/sys/TOPS amd64 > > % ifconfig > msk0: flags=8843 metric 0 mtu 1500 > options=11a > ether * > inet 172.21.21.22 netmask 0xfffffff8 broadcast 172.21.21.23 > inet6 * prefixlen 64 scopeid 0x1 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > My hardware: > mskc0@pci0:2:0:0: class=0x020000 card=0x902d104d chip=0x435311ab rev=0x15 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = 'Gigabit (88E8039 - http://www.marvell.com/drivers/driverDis)' > class = network > subclass = ethernet > I guess some changes made to reduce unnecessary controller reinitialization seems to cause the issue. Would you try attached patch? --CE+1k2dSO48ffgeK Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.link.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 199322) +++ sys/dev/msk/if_msk.c (working copy) @@ -3198,6 +3198,8 @@ mii = device_get_softc(sc_if->msk_miibus); mii_tick(mii); + if ((sc_if->msk_flags & MSK_FLAG_LINK) == 0) + msk_miibus_statchg(sc_if->msk_if_dev); msk_watchdog(sc_if); callout_reset(&sc_if->msk_tick_ch, hz, msk_tick, sc_if); } --CE+1k2dSO48ffgeK-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 18:33:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B69AA106568D; Mon, 16 Nov 2009 18:33:33 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 525D48FC15; Mon, 16 Nov 2009 18:33:33 +0000 (UTC) Received: from bolt.zol (unknown [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 1E37728; Mon, 16 Nov 2009 19:37:40 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> Date: Mon, 16 Nov 2009 19:33:34 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: <1258390784.2303.42.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 18:33:33 -0000 On Mon, 16 Nov 2009 17:59:44 +0100, Robert Noland wrote: >> [...] >> Then I read this thread and applied Robert Noland's and Matt Reimer's >> patches -- and they didn't help. Then I grabbed following files from >> -CURRENT (svn rev. 198420): > Matt's patch only effects raidz volumes. Oh, I see. Maybe there is similar bug in ZFS on single disk volumes also? >> [cut: update procedure] >> (is this procedure of updating zfsboot correct?) > This should be correct for updating the first stage bootstrap code. The > loader (boot/loader) is actually updated during installworld. I'll try full build/installworld tomorrow. >> [...] >> I would rather not to upgrade the whole system to -CURRENT. What >> should I >> do in this situation? Is there any other patch that I could apply or any >> workaround for this issue? Is there possibility to switch from zfsboot >> to >> gptzfsboot without loosing data? Or maybe I did something wrong? > I don't think that you can switch to gptzfsboot as that would require > repartitioning the device. I thought so. > A little more context though, was this working before? Or is this a new > install? This system has worked stable since Jun, but I've never done full installworld after the initial installation. Now, after the installworld, machine no longer boots. (Rollback did not help). -- am From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 18:53:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AEA106566B for ; Mon, 16 Nov 2009 18:53:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4E48FC08 for ; Mon, 16 Nov 2009 18:53:13 +0000 (UTC) Received: (qmail 25142 invoked by uid 399); 16 Nov 2009 18:53:13 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Nov 2009 18:53:13 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B019F97.6040209@FreeBSD.org> Date: Mon, 16 Nov 2009 10:53:11 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Paul B Mahol References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> In-Reply-To: <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 18:53:14 -0000 Paul B Mahol wrote: > On 11/16/09, Doug Barton wrote: >> Doug Barton wrote: >>> I upgraded my -current laptop from r199019 to r199291 and on the newer >>> kernel wpa_supplicant runs but doesn't ever lock in. >> And the winner is .... r199076! > > What about connection without wpa_supplicant, does it work? Yes. > You did rebuild world and kernel with NO_CLEAN undefined? No, I always build with -DNO_CLEAN, in fact I think most people running -current and upgrading on a regular basis do that. Also, the traditional suggestion for upgrading is to build world and kernel, install kernel, reboot, check to make sure things are working. If a change in the kernel sources requires that something in userland be synced up it's customary to put a note about it in UPDATING. > Perhaps driver_freebsd.c from wpa_supplicant is not synced with this change. The sources were in synch. To give this the best shot at debugging quickly I updated my src tree (including the change in 199076), did 'make kernel' to build a clean one then did a clean build/install in src/usr.sbin/wpa. That didn't work either. Interestingly, the new wpa_supplicant works fine with the old kernel, so I don't think that's the issue, but that's not conclusive. I'm now doing a completely clean buildworld and kernel, I'll post again when I have some results. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 20:30:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B7D51065679 for ; Mon, 16 Nov 2009 20:30: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 ESMTP id 07C7E8FC16 for ; Mon, 16 Nov 2009 20:30:41 +0000 (UTC) Received: (qmail 26655 invoked by uid 399); 16 Nov 2009 20:30:41 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Nov 2009 20:30:41 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B01B66F.1040903@FreeBSD.org> Date: Mon, 16 Nov 2009 12:30:39 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Paul B Mahol References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> In-Reply-To: <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 20:30:42 -0000 Paul B Mahol wrote: > On 11/16/09, Doug Barton wrote: >> Doug Barton wrote: >>> I upgraded my -current laptop from r199019 to r199291 and on the newer >>> kernel wpa_supplicant runs but doesn't ever lock in. >> And the winner is .... r199076! Ok, interestingly a system installed from a clean buildworld works, which is good news. Rui, it would be nice to include a note about this in UPDATING. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 20:32:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E96031065670 for ; Mon, 16 Nov 2009 20:32:39 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 73C7D8FC15 for ; Mon, 16 Nov 2009 20:32:39 +0000 (UTC) Received: by bwz5 with SMTP id 5so6435967bwz.3 for ; Mon, 16 Nov 2009 12:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=LByBMd6EDi3rhXWmn2k9zVEZ/93UKSWf29TgPojUeJ4=; b=xLOV5CIZyjHwbzLw0zvYCTrZGx43f/GvUptC+VZYpGxj6AZEyNHcvNGPw9FcRdxqhG NtZwV1Rs4lEsdwYSLjXWHb4wD8dCxSJ9wbijrLOTbTIZsteNFyRXek5LiojemaRsUfS4 6b1FB+svT+Mq6tMPoJzqdbkHLApXRpfvUcg84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=rl1z+Kk+qu31fY4FUJPpUcUUZHJ3QBA/+LCYAAD43fJD5nv2n3Tf2kwjwUPrjIu73h 1DbZBAPmmOSXTUdJfRjtLAjtc6qb8EizilRgiOeWxcmeHrO33rspuFnnKAkpRjR2Qu9b oOZi+CdJqJqKU+jzRxKhXJRKw7idPyE5+nnyQ= Received: by 10.204.10.143 with SMTP id p15mr4116836bkp.183.1258403558349; Mon, 16 Nov 2009 12:32:38 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id k29sm5036332fkk.25.2009.11.16.12.32.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 12:32:37 -0800 (PST) Date: Mon, 16 Nov 2009 22:32:31 +0200 From: Gleb Kurtsou To: Pyun YongHyeon Message-ID: <20091116203231.GA1597@tops.skynet.lt> References: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> <20091111231426.GF15449@michelle.cdnetworks.com> <20091115091309.GA1539@tops.skynet.lt> <20091116181304.GC1262@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20091116181304.GC1262@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mel Flynn , freebsd-current@freebsd.org Subject: Re: Possible regression with msk driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2009 20:32:40 -0000 On (16/11/2009 10:13), Pyun YongHyeon wrote: > On Sun, Nov 15, 2009 at 11:13:10AM +0200, Gleb Kurtsou wrote: [...] > > I experience similar problem. After boot msk0 status is active, but I'm > > not able to send anything: > > % ping 172.21.21.21 > > PING 172.21.21.21 (172.21.21.21): 56 data bytes > > ping: sendto: No buffer space available > > ping: sendto: No buffer space available > > > > After unplugging cable and putting it back everything works as > > expected: > > % ping 172.21.21.21 > > PING 172.21.21.21 (172.21.21.21): 56 data bytes > > 64 bytes from 172.21.21.21: icmp_seq=0 ttl=64 time=0.904 ms > > > > It is 100% reproducible, running recent current. > > > > % uname -a > > FreeBSD tops 9.0-CURRENT FreeBSD 9.0-CURRENT #17 r199274+c8076f9: Sat Nov 14 22:59:26 EET 2009 root@tops:/usr/obj/usr/freebsd-src/local/sys/TOPS amd64 > > > > % ifconfig > > msk0: flags=8843 metric 0 mtu 1500 > > options=11a > > ether * > > inet 172.21.21.22 netmask 0xfffffff8 broadcast 172.21.21.23 > > inet6 * prefixlen 64 scopeid 0x1 > > nd6 options=29 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > My hardware: > > mskc0@pci0:2:0:0: class=0x020000 card=0x902d104d chip=0x435311ab rev=0x15 hdr=0x00 > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > device = 'Gigabit (88E8039 - http://www.marvell.com/drivers/driverDis)' > > class = network > > subclass = ethernet > > > > I guess some changes made to reduce unnecessary controller > reinitialization seems to cause the issue. > Would you try attached patch? Patch fixes the issue. I tried rebooting several times with connected/disconnected cable. I'll let you know if any problem shows up later. Thanks, Gleb. > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 199322) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -3198,6 +3198,8 @@ > mii = device_get_softc(sc_if->msk_miibus); > > mii_tick(mii); > + if ((sc_if->msk_flags & MSK_FLAG_LINK) == 0) > + msk_miibus_statchg(sc_if->msk_if_dev); > msk_watchdog(sc_if); > callout_reset(&sc_if->msk_tick_ch, hz, msk_tick, sc_if); > } From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 21:27:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADC33106566C for ; Mon, 16 Nov 2009 21:27:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2F18FC0C for ; Mon, 16 Nov 2009 21:27:10 +0000 (UTC) Received: (qmail 7559 invoked by uid 399); 16 Nov 2009 21:27:09 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Nov 2009 21:27:09 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B01C3A6.5060101@FreeBSD.org> Date: Mon, 16 Nov 2009 13:27:02 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Paul B Mahol References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> <4B01B66F.1040903@FreeBSD.org> In-Reply-To: <4B01B66F.1040903@FreeBSD.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 21:27:11 -0000 Doug Barton wrote: > Rui, it would be nice to include a note about this in UPDATING. To be fair someone else drew my attention to the fact that there is an entry in UPDATING about the change, however it doesn't mention wpa_supplicant, and merely recompiling wpa_supplicant wasn't sufficient to fix the problem, so perhaps that entry could be expanded. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 22:30:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 006B01065672; Mon, 16 Nov 2009 22:30:52 +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 B54198FC24; Mon, 16 Nov 2009 22:30:51 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id nAGMUpvf091295; Mon, 16 Nov 2009 14:30:51 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id nAGMUpRW091294; Mon, 16 Nov 2009 14:30:51 -0800 (PST) (envelope-from sgk) Date: Mon, 16 Nov 2009 14:30:51 -0800 From: Steve Kargl To: Doug Barton Message-ID: <20091116223051.GA90683@troutmask.apl.washington.edu> References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> <4B01B66F.1040903@FreeBSD.org> <4B01C3A6.5060101@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B01C3A6.5060101@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Rui Paulo , freebsd-current@freebsd.org Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 22:30:52 -0000 On Mon, Nov 16, 2009 at 01:27:02PM -0800, Doug Barton wrote: > Doug Barton wrote: > > Rui, it would be nice to include a note about this in UPDATING. > > To be fair someone else drew my attention to the fact that there is an > entry in UPDATING about the change, however it doesn't mention > wpa_supplicant, and merely recompiling wpa_supplicant wasn't > sufficient to fix the problem, so perhaps that entry could be expanded. > > Doug > After reviewing this thread and with the speed with which head can change, I'll suggest the following for UPDATING Index: UPDATING =================================================================== --- UPDATING (revision 199277) +++ UPDATING (working copy) @@ -878,12 +878,16 @@ ------------- Avoid using make -j when upgrading. While generally safe, there are sometimes problems using -j to upgrade. If your upgrade fails with - -j, please try again wtihout -j. From time to time in the past there + -j, please try again without -j. From time to time in the past there have been problems using -j with buildworld and/or installworld. This is especially true when upgrading between "distant" versions (eg one that cross a major release boundary or several minor releases, or when several months have passed on the -current branch). + Avoid using make -DNO_CLEAN when upgrading. While generally safe, + there are sometimes problems using -DNO_CLEAN to upgrade. If your + upgrade fails with -DNO_CLEAN, please try again without -DNO_CLEAN. + -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Nov 16 22:40:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C22106566C for ; Mon, 16 Nov 2009 22:40:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id F40778FC15 for ; Mon, 16 Nov 2009 22:40:42 +0000 (UTC) Received: (qmail 13278 invoked by uid 399); 16 Nov 2009 22:40:42 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Nov 2009 22:40:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B01D4E8.5000904@FreeBSD.org> Date: Mon, 16 Nov 2009 14:40:40 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Steve Kargl References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> <4B01B66F.1040903@FreeBSD.org> <4B01C3A6.5060101@FreeBSD.org> <20091116223051.GA90683@troutmask.apl.washington.edu> In-Reply-To: <20091116223051.GA90683@troutmask.apl.washington.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , freebsd-current@freebsd.org Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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, 16 Nov 2009 22:40:43 -0000 Steve Kargl wrote: > After reviewing this thread and with the speed with which head > can change, I'll suggest the following for UPDATING Usually problems that not using NO_CLEAN will fix manifest themselves at build time, so the solution is easy to figure out. More subtle (usually run time) problems get a specific note in UPDATING. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 00:20:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F6B8106566B; Tue, 17 Nov 2009 00:20:38 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0DF8FC13; Tue, 17 Nov 2009 00:20:37 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so1948304eyd.9 for ; Mon, 16 Nov 2009 16:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1VrZBwVEpqmsrhTDeEXzts2pJI8u5LCbtcUTWNboWu4=; b=U4gRH9XpVA4uMEQY6dDo8aRW6Ma+5rXrd4TBhFkv4pEWiRRe8staWQkPJv9TJgcSxs mJcyFcYy6+Q4ATkH4MRA6WGgDoEMQrg/0hKVCKnctHXGC4c06nJiYQJ7oCI50pqwyAUx OiU3OJauqo+uitXVG9O/O2NFt8E9Kw7/nkK/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=uoEZxHOacoSL/Y4eb33lp3gW+bxwQCUV6fqn/HgUaiJQabH/PGGrGRwxAU5LehcHy4 3mLTKi2ohbQE5H3DEJdI7Xbr1EgcA/fecRw3gFY3is+4whsY602o7SaVX0ue+4sb62kp dQEbqbHL6TgaU7izDRUfWR1yImJmqO7IfcsAs= Received: by 10.213.55.205 with SMTP id v13mr4854115ebg.79.1258417236437; Mon, 16 Nov 2009 16:20:36 -0800 (PST) Received: from mac-mini.lan (bl11-193-116.dsl.telepac.pt [85.244.193.116]) by mx.google.com with ESMTPS id 28sm2362769eyg.14.2009.11.16.16.20.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 16:20:35 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4B01C3A6.5060101@FreeBSD.org> Date: Tue, 17 Nov 2009 00:20:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> <4B01B66F.1040903@FreeBSD.org> <4B01C3A6.5060101@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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: Tue, 17 Nov 2009 00:20:38 -0000 On 16 Nov 2009, at 21:27, Doug Barton wrote: > Doug Barton wrote: >> Rui, it would be nice to include a note about this in UPDATING. >=20 > To be fair someone else drew my attention to the fact that there is an > entry in UPDATING about the change, however it doesn't mention > wpa_supplicant, and merely recompiling wpa_supplicant wasn't > sufficient to fix the problem, so perhaps that entry could be = expanded. Well, when I did this change I did build with -DNOCLEAN and it rebuilt a = good wpa_supplicant. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 00:29:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3457C106568F for ; Tue, 17 Nov 2009 00:29:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id AFD128FC12 for ; Tue, 17 Nov 2009 00:29:07 +0000 (UTC) Received: (qmail 9903 invoked by uid 399); 17 Nov 2009 00:29:06 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Nov 2009 00:29:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B01EE51.2040904@FreeBSD.org> Date: Mon, 16 Nov 2009 16:29:05 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Rui Paulo References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> <4B01B66F.1040903@FreeBSD.org> <4B01C3A6.5060101@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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: Tue, 17 Nov 2009 00:29:08 -0000 Rui Paulo wrote: > On 16 Nov 2009, at 21:27, Doug Barton wrote: > >> Doug Barton wrote: >>> Rui, it would be nice to include a note about this in UPDATING. >> To be fair someone else drew my attention to the fact that there is an >> entry in UPDATING about the change, however it doesn't mention >> wpa_supplicant, and merely recompiling wpa_supplicant wasn't >> sufficient to fix the problem, so perhaps that entry could be expanded. > > Well, when I did this change I did build with -DNOCLEAN and it rebuilt a good wpa_supplicant. I'm not in any way implying that you did not test the change thoroughly. Please let me know your intentions regarding the UPDATING entry. I'll be glad to augment it myself if necessary. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 01:03:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 967C4106566B; Tue, 17 Nov 2009 01:03:46 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id F1AAA8FC0C; Tue, 17 Nov 2009 01:03:45 +0000 (UTC) Received: by fxm27 with SMTP id 27so6707817fxm.3 for ; Mon, 16 Nov 2009 17:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Wmwk3Pyk6bmGvnhqHRUmrnf7ava16kMNxiVOnkVnD4w=; b=UXXQ3rLGSFGZBIs0rCtrmuzmtRzwbZ3NGGqtHzS6Ir6cI8WnI2i3GP4GbKP9Tppn1B L2lL7woc6aGO7M54S/6aNgcdwAK9sxGpWy/xChnjGPe64PXhBpy8aAOCbyhZjuBRBDqB 61w5orp8uCJq9a2lUlrX5d2AZhSmrjrMlXTtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=UFfoJbNkUA5Bz6DEwp68WVWXDarNWay73huclcMGKs5Lz1pn0fhziTc+sbpA6/z0Ka gKoRmguXbZ9Rd5L7g2CnmyOn22BTpZVLbJCxlxyFhQsE2MQxnVtfw16ISjrnCKIWaRNK JDYCcDP9R4gvs5Ka4/jQqtTdTNjPkGSNpFvHU= Received: by 10.216.87.81 with SMTP id x59mr818984wee.147.1258419824834; Mon, 16 Nov 2009 17:03:44 -0800 (PST) Received: from mac-mini.lan (bl11-193-116.dsl.telepac.pt [85.244.193.116]) by mx.google.com with ESMTPS id 5sm350746eyf.0.2009.11.16.17.03.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 17:03:44 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4B01EE51.2040904@FreeBSD.org> Date: Tue, 17 Nov 2009 01:03:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <35695A2B-6ADD-4060-9A47-0C9C4C57DFD9@freebsd.org> References: <4B0087C2.9070508@FreeBSD.org> <4B00BA99.5000009@FreeBSD.org> <3a142e750911160035m520819eqdf261c0c493bf3c3@mail.gmail.com> <4B01B66F.1040903@FreeBSD.org> <4B01C3A6.5060101@FreeBSD.org> <4B01EE51.2040904@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant + wpi0 won't lock in on today's -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: Tue, 17 Nov 2009 01:03:46 -0000 On 17 Nov 2009, at 00:29, Doug Barton wrote: > Rui Paulo wrote: >> On 16 Nov 2009, at 21:27, Doug Barton wrote: >>=20 >>> Doug Barton wrote: >>>> Rui, it would be nice to include a note about this in UPDATING. >>> To be fair someone else drew my attention to the fact that there is = an >>> entry in UPDATING about the change, however it doesn't mention >>> wpa_supplicant, and merely recompiling wpa_supplicant wasn't >>> sufficient to fix the problem, so perhaps that entry could be = expanded. >>=20 >> Well, when I did this change I did build with -DNOCLEAN and it = rebuilt a good wpa_supplicant. >=20 > I'm not in any way implying that you did not test the change = thoroughly. >=20 > Please let me know your intentions regarding the UPDATING entry. I'll > be glad to augment it myself if necessary. I'm ok with mentioning that wpa_supplicant must also be rebuilt and/or = mentioning that NOCLEAN must be disabled. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 01:36:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F0671065670; Tue, 17 Nov 2009 01:36:53 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 15ABD8FC13; Tue, 17 Nov 2009 01:36:52 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 706FC12543B; Tue, 17 Nov 2009 10:36:51 +0900 (JST) Date: Tue, 17 Nov 2009 10:36:51 +0900 From: Daichi GOTO To: Daniel Braniss , freebsd-emulation@FreeBSD.org Message-Id: <20091117103651.da7ceeb0.daichi@ongs.co.jp> In-Reply-To: References: <20091116174933.4ab2354d.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 01:36:53 -0000 On Mon, 16 Nov 2009 12:33:51 +0200 Daniel Braniss wrote: > > FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox. > > Boot will stop and consume 100% cpu power during boot sequence > > as displaying as follow: > > > > Trying to mount rott from ufs:/dev/md0 > > warning: no time-of-day clock registered, system time will not be set accurately > > > > checked environment: > > > > FreeBSD 9.0-CURRENT #44: Mon Nov 16 09:51:20 JST 2009 amd64 > > Core2 Quad Q9550 > > virtualbox-3.0.51.r22902_2 > > cpu: Core2 Quad Q9550 1-core > > mem: 1024MB > > VT-x: enable > > nested paging: disable > > > > Is there anyone can boot 8.0-RC3/amd64 on VirtualBox? > > it's running ok, but with slight diffs: > Virtualbox-3.0.51r23006 > (only mod is that I changed the boot.rom, to get pxe > boot to work). > and the host is 8.0-PRERELEASE Enabled both ACPI and IO ACPI gives FreeBSD 8.0-RC3/amd64 on VirtualBox working fine :) checked metrics: ----------------------------------------------------------- | ACPI | IO ACPI || HPET 64 | HPET 32 | HPET Disabled | -----------------------===================================== | Enabled | Enabled || WORK | WORK | WORK | | Enabled | Disabled || FAIL | FAIL | FAIL | | Disabled | Enabled || FAIL | FAIL | FAIL | | Disabled | Disabled || FAIL | FAIL | FAIL | ----------------------------------------------------------- * ACPI/IO ACPI - VirtualBox settings ** HPET - HOST PC BIOS settings > _______________________________________________ > 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" -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 04:31:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC2DC1065676 for ; Tue, 17 Nov 2009 04:31:14 +0000 (UTC) (envelope-from jeremy.thornhill@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 73D0A8FC21 for ; Tue, 17 Nov 2009 04:31:14 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so1998457eyd.9 for ; Mon, 16 Nov 2009 20:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Yw9lBGL3kuoPqDkDWbTtHN4QzrvY3lFTtePJLvYYQI4=; b=x9Z2wxiqcfNeIMmgU9wH9KWsvc4b07Tf57+hX09xXpByO3WAeC24tOo5+5ar3Eln1c L+Hy04wNxIKPQtoJXT3wa3yMRollXIjxuDgwNIg3eSv9+RXTC/QyJsoWmVUGMHXATKHU gvRehpg3bIvh+tj5RHpp0VBBRFPD3jTzkpC6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IxGUWUruJ/5Do+/I3PxoMSbSsmOcESM3UhlN5PdE/D41UJDy7ohuJThZXbzY84XfVf XACSJKDhDzFqFrinWqqsgDP4TTASZRzp4UYF8nyhjllv0+m+jY+g5OyIZhhyz5Cuutiu M/FadRtyfd13s9TzavoNVQOi1quN5A6hfKeZc= MIME-Version: 1.0 Received: by 10.213.23.200 with SMTP id s8mr2151232ebb.52.1258431021647; Mon, 16 Nov 2009 20:10:21 -0800 (PST) Date: Mon, 16 Nov 2009 23:10:21 -0500 Message-ID: From: Jeremy Thornhill To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 04:31:14 -0000 Dear list, I've been trying out 8.0-RC3 on a spare machine. I've been hoping that 8.0 would be a good time to move my ZFS pools from an old Solaris x86 box to FreeBSD. I've been testing the procedure with a USB drive which was allocated as a single pool under Solaris. It's the correct filesystem version (13). I export the pool from the Solaris box, and then attempt to import it on the FreeBSD box. Unfortunately, I get the following error, and the pool is not able to be imported: GEOM: da0: corrupt or invalid GPT detected. GEOM: da0: GPT rejected -- may not be recoverable. I've seen some recent posts on the lists where a helpful developer assisted a user suffering from a similar circumstance, but I wasn't able to determine if there is a general way for users to resolve such issues. If I understand correctly this is an incompatibility in how Solaris partitions disks when they are allocated entirely to a pool. So, before I attempt this full scale on my raidz array, can anybody point me in the right direction to get beyond this error and make my Solaris ZFS pools work in FreeBSD? Thanks, Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 04:40:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D84E106566B for ; Tue, 17 Nov 2009 04:40:18 +0000 (UTC) (envelope-from fbsdq@peterk.org) Received: from poshta.pknet.net (poshta.pknet.net [216.241.167.213]) by mx1.freebsd.org (Postfix) with SMTP id C484A8FC1F for ; Tue, 17 Nov 2009 04:40:17 +0000 (UTC) Received: (qmail 77438 invoked from network); 17 Nov 2009 04:13:35 -0000 Received: from poshta.pknet.net (HELO smtp.pknet.net) (216.241.167.213) by poshta.pknet.net with SMTP; 17 Nov 2009 04:13:35 -0000 Received: from 216.241.167.212 (SquirrelMail authenticated user fbsdq@peterk.org) by webmail.pknet.net with HTTP; Mon, 16 Nov 2009 21:13:35 -0700 (MST) Message-ID: Date: Mon, 16 Nov 2009 21:13:35 -0700 (MST) From: "Peter" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: 8-[stable] buildworld fails - at ja_JP.UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 04:40:18 -0000 iH, SVNed up to latest revision - buildworld fails. commented out: NLS+= ja_JP.UTF-8 NLS+= ja_JP.eucJP from usr/src/lib/libc/nls/Makefile.inc buildworld and installworld work fine. This is with that part commented out during 'buildworld' and then I uncommented it out [after awhile into buildworld] but installworld failed if that was left uncommented with the following snip: ===> csu/i386-elf (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib32 ===> libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib32 gencat ja_JP.UTF-8.cat /denver/usr/src/lib/libc/nls/ja_JP.UTF-8.msg gencat: not found *** Error code 127 :#svn up At revision 199342. looks like this commit broke it: [?] ------------------------------------------------------------------------ r199307 | ume | 2009-11-15 20:52:18 -0700 (Sun, 15 Nov 2009) | 3 lines MFC r199080, r199081, r199082: Add ja_JP.UTF-8 and ja_JP.eucJP catalogs. ------------------------------------------------------------------------ ]Peter[ From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 05:11:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B257106566B for ; Tue, 17 Nov 2009 05:11:03 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id DF5218FC0A for ; Tue, 17 Nov 2009 05:11:02 +0000 (UTC) Received: from ip-149.ish.com.au ([203.29.62.149]:52955) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1NAGTo-000679-10; Tue, 17 Nov 2009 16:19:52 +1100 Message-ID: <4B023061.7070203@ish.com.au> Date: Tue, 17 Nov 2009 16:10:57 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6pre) Gecko/20091108 Shredder/3.0pre MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 05:11:03 -0000 Is it possible that this flag be set to YES in the FreeBSD 8.0 branch before final release? I don't understand if there are any downsides to doing this, but it certainly would help enormously all those following freebsd-update binary updates and trying to boot directly from ZFS. Needless to say this request is borne from the frustration of killing a server going from RC2 to RC3 and having freebsd-update overwrite our /boot/loader file with a non-ZFS aware version. I'm rather concerned that we'll kill it again for every release we forget about this issue. We'll look at hacking rc.shutdown to perform a test of some sort to help remind us in the short term, but even nicer is if this change could be made, or at least for the freebsd-update binary builds. Thanks Ari -- --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 06:57:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A792106566B for ; Tue, 17 Nov 2009 06:57:31 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4078FC12 for ; Tue, 17 Nov 2009 06:57:30 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id nAH6vSHl045392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Nov 2009 07:57:28 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Tue, 17 Nov 2009 07:57:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> References: To: Jeremy Thornhill X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 06:57:31 -0000 Am 17.11.2009 um 05:10 schrieb Jeremy Thornhill: > I've been testing the procedure with a USB drive which was allocated > as a single pool under Solaris. It's the correct filesystem version > (13). I export the pool from the Solaris box, and then attempt to > import it on the FreeBSD box. Unfortunately, I get the following > error, and the pool is not able to be imported: >=20 > GEOM: da0: corrupt or invalid GPT detected. > GEOM: da0: GPT rejected -- may not be recoverable. What error are you getting from zpool import? I believe the GEOM error is due to Solaris adding the GPT partition = table to the start of the device, but not the end. GEOM requires both = copies to be present and identical, IIRC. Since the pool fills the = device, there's no space at the end, so adding the second copy is not an = option. You could try destroying the first GPT copy by zeroing the first 34 = blocks. I'm not sure what Solaris will make of the pool after this, = though: # dd if=3D/dev/zero of=3D/dev/da0 count=3D34 However, I'd expect this to have no effect on zpools ability to import = the pool. HTH, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 07:31:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D847310656A9 for ; Tue, 17 Nov 2009 07:31:06 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 924B78FC15 for ; Tue, 17 Nov 2009 07:31:06 +0000 (UTC) Received: from ip-149.ish.com.au ([203.29.62.149]:53398) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1NAIfM-00033A-2O; Tue, 17 Nov 2009 18:39:56 +1100 Message-ID: <4B025136.3060809@ish.com.au> Date: Tue, 17 Nov 2009 18:31:02 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6pre) Gecko/20091108 Shredder/3.0pre MIME-Version: 1.0 To: Nikolay Denev References: <4B023061.7070203@ish.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 07:31:07 -0000 On 17/11/09 6:21 PM, Nikolay Denev wrote: > I've also thought about that, but I guess one of the issues is that this way > FreeBSD will by default load CDDL-ed code, which may not be desirable. > Probably a compromise would be to build two loaders by default, one with zfs support and the standard one. I don't believe this is the issue since FreeBSD already comes with zfs.ko and opensolaris.ko already built by default. That is, it includes the CDDL code from ZFS itself. The boot loader is a FreeBSD invention (although probably built with pieces of code from the ZFS module). Ari Maniatis -- --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 07:40:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68C9010656C1 for ; Tue, 17 Nov 2009 07:40:38 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id ED1108FC1A for ; Tue, 17 Nov 2009 07:40:37 +0000 (UTC) Received: by fxm10 with SMTP id 10so2504601fxm.14 for ; Mon, 16 Nov 2009 23:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=95Q5UER1HVaHOZ0fTOI0H/GsFZizQZuhTH83jT3iiKc=; b=E97cNK+ih8mmMnED2Y1g3PWv2YI+0/5f6PqKJnJgQom7YZuaUmNK6mQNJ9dd3emEnT QLx8nIx/c7cckRbkELx7nOVoF2D3VnFa7Uu0Jg+IiOBTEO/OariS86RkBMFagk+oHigD 8b37C4VK8Sd7ECbP+TJkTtX/BSCh8HvqcPlqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=n4I+vrKWLa7aXZzYqzbUPhskYRvZ0YRoSDzQcSwCXw9RV9PNwuNyba4/cRLqtF9agK VzrXxiSctr8KC0W8LVun0ESt84nVYcurk/Jd+RR4qPOpG2VTswT3UZ4A5rvAxMOSgaFo GiF2F0GbD4faAu5aJL4EUzT8O2HTr7MWbPUJI= Received: by 10.103.84.10 with SMTP id m10mr4195762mul.60.1258443636541; Mon, 16 Nov 2009 23:40:36 -0800 (PST) Received: from ?10.0.0.10? (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id 7sm16489607mup.12.2009.11.16.23.40.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 23:40:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <4B025136.3060809@ish.com.au> Date: Tue, 17 Nov 2009 09:40:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7DD81D94-82BF-455B-B472-4A7D97830AB0@gmail.com> References: <4B023061.7070203@ish.com.au> <4B025136.3060809@ish.com.au> To: Aristedes Maniatis X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 07:40:38 -0000 On 17 Nov, 2009, at 09:31 , Aristedes Maniatis wrote: > On 17/11/09 6:21 PM, Nikolay Denev wrote: >> I've also thought about that, but I guess one of the issues is that = this way >> FreeBSD will by default load CDDL-ed code, which may not be = desirable. >> Probably a compromise would be to build two loaders by default, one = with zfs support and the standard one. >=20 >=20 > I don't believe this is the issue since FreeBSD already comes with = zfs.ko and opensolaris.ko already built by default. That is, it includes = the CDDL code from ZFS itself. The boot loader is a FreeBSD invention = (although probably built with pieces of code from the ZFS module). >=20 > Ari Maniatis >=20 > --=20 > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A They are built by default, but not loaded in memory by default. That's = the difference. -- Regards, Nikolay Denev From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 07:43:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6C191065693 for ; Tue, 17 Nov 2009 07:43:08 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 572A38FC18 for ; Tue, 17 Nov 2009 07:43:08 +0000 (UTC) Received: by mail-fx0-f218.google.com with SMTP id 10so2506006fxm.14 for ; Mon, 16 Nov 2009 23:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Cb6gLZ25lNJ6zpsduae415LEzCtGAuxRbm5Cn9gOuMI=; b=YpOC20A7Mo6lFnP4WokpuaveOiY6uwH1MV5izehyTGY39vZDVCdxVaiSp5wCvlNQTn Ok04M9nCNGNROCd6IiH24ghk702KUeKrZiZDzFnBOL/Pl0AIXgHIrvBbZtqH3ZxSKkL7 K7oj4RoNGZbL8kkdaidzTrlmduwj59czN01X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=I2nuNaWMmtgKJgCxf5Ini60ra1b4e/vFYhsKyxwC8nASggMoHiE6rhBMT1G77rx8VU 9QJXqECUppkF+QAmkuuRndr0Lfrmatal52OG9Wit8zpPT9mQg80sjfNbseMNJJojyNnu K/lSl0gsqSSN2WgxY0K8Asnat7NwM7hGoYEOA= Received: by 10.102.236.11 with SMTP id j11mr4225389muh.3.1258442518984; Mon, 16 Nov 2009 23:21:58 -0800 (PST) Received: from ?10.0.0.10? (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id w5sm14526344mue.7.2009.11.16.23.21.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 23:21:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <4B023061.7070203@ish.com.au> Date: Tue, 17 Nov 2009 09:21:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B023061.7070203@ish.com.au> To: Aristedes Maniatis X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 07:43:08 -0000 On 17 Nov, 2009, at 07:10 , Aristedes Maniatis wrote: > Is it possible that this flag be set to YES in the FreeBSD 8.0 branch = before final release? I don't understand if there are any downsides to = doing this, but it certainly would help enormously all those following = freebsd-update binary updates and trying to boot directly from ZFS. >=20 > Needless to say this request is borne from the frustration of killing = a server going from RC2 to RC3 and having freebsd-update overwrite our = /boot/loader file with a non-ZFS aware version. >=20 > I'm rather concerned that we'll kill it again for every release we = forget about this issue. We'll look at hacking rc.shutdown to perform a = test of some sort to help remind us in the short term, but even nicer is = if this change could be made, or at least for the freebsd-update binary = builds. >=20 >=20 > Thanks >=20 > Ari >=20 >=20 > --=20 > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A I've also thought about that, but I guess one of the issues is that this = way FreeBSD will by default load CDDL-ed code, which may not be desirable. Probably a compromise would be to build two loaders by default, one with = zfs support and the standard one. P.S.: It may be late for 8.0-REL but I think this should happen some = day. -- Regards, Nikolay Denev From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 08:33:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7EC8106568B; Tue, 17 Nov 2009 08:33:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B2A2A8FC0C; Tue, 17 Nov 2009 08:33:41 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA05675; Tue, 17 Nov 2009 10:33:16 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NAJUy-00041I-EH; Tue, 17 Nov 2009 10:33:16 +0200 Message-ID: <4B025FA9.7020003@icyb.net.ua> Date: Tue, 17 Nov 2009 10:32:41 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Kai Gallasch References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> <4AFD140D.7010407@icyb.net.ua> <20091113144804.2c0fb90f@orwell.free.de> <4AFD655E.5020801@icyb.net.ua> <20091114022121.217dd831@orwell.free.de> <4AFE7A32.7060203@icyb.net.ua> In-Reply-To: <4AFE7A32.7060203@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 08:33:42 -0000 on 14/11/2009 11:36 Andriy Gapon said the following: > on 14/11/2009 03:21 Kai Gallasch said the following: >> Hi. The patch did help for surviving a makeworld. >> >> But now I have another machine check exception with this server. It >> happened with your patch active, and vm.pmap.pg_ps_enabled="1". I >> copied data from a remote server by NFS mount to the instable server. >> Destination was a local ZFS filesystem. >> >> ---------------- >> >> sonnenkraft:~ # MCA: CPU 7 UNCOR PCC OVER DTLB L1 error >> MCA: Address 0xff800d860000 > > It's interesting because the same happened to me too, only in my case it was > zpool scrub that triggered it. > I will try to look into this further. > Kai, the latest patch in the works, it's against a clean tree: diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 44b71f3..ff35eb9 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -2365,6 +2365,9 @@ pmap_demote_pde * the read above and the store below. */ pde_store(pde, newpde); + pmap_invalidate_page(pmap, va); + clflush((vm_offset_t)vtopde(va)); + mfence(); /* * Invalidate a stale recursive mapping of the page table page. @@ -2981,6 +2984,11 @@ setpte: * Map the superpage. */ pde_store(pde, PG_PS | newpde); + pmap_invalidate_range(pmap, va & ~PDRMASK, (va & ~PDRMASK) + NBPDR); + clflush((vm_offset_t)vtopde(va)); + mfence(); + if (va >= VM_MAXUSER_ADDRESS) + pmap_invalidate_page(pmap, (vm_offset_t)vtopte(va)); pmap_pde_promotions++; CTR2(KTR_PMAP, "pmap_promote_pde: success for va %#lx" -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 09:14:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82323106568B for ; Tue, 17 Nov 2009 09:14:43 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 01CAB8FC0C for ; Tue, 17 Nov 2009 09:14:41 +0000 (UTC) Received: by bwz5 with SMTP id 5so6960302bwz.3 for ; Tue, 17 Nov 2009 01:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=c9t8IpLZvO3IpZbUPO4TUF4foa62zUrj7smP3R7TfC8=; b=IPnRE6seC8ycpZnYe5TizQT91GE0RqCOTXQuOxg0GJFxw9gxf2Xf16r52QrUvq2zHN iBuG8GUUFYnMPyhl6YMk9Np663m5gBBvzXB4g055yFQpuZym4EMe5dhjBZNC5yJV11+z 37A1+ddd/rn5Ec34yt2f8jKp77XTxXka+U08M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jgum1SoJJ8UfYPByqj/+O/weMJkvFAW9NN8CnCEds5k9LhVoRwvZ4qx9m8yzf1nDyo 5EOF+6O3D+XYfXc6ZV6GR4N0CyiZLKdL+lXTbJAlP4xawqZub7rHtjB4OSeZQ82NM3/9 SdJ6v02yDUinwzGr1TkeuEFPlu3AMUIQ9MV4o= MIME-Version: 1.0 Received: by 10.239.182.161 with SMTP id q33mr809557hbg.41.1258449279931; Tue, 17 Nov 2009 01:14:39 -0800 (PST) In-Reply-To: <7DD81D94-82BF-455B-B472-4A7D97830AB0@gmail.com> References: <4B023061.7070203@ish.com.au> <4B025136.3060809@ish.com.au> <7DD81D94-82BF-455B-B472-4A7D97830AB0@gmail.com> Date: Tue, 17 Nov 2009 09:14:39 +0000 Message-ID: From: krad To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Aristedes Maniatis Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 09:14:44 -0000 2009/11/17 Nikolay Denev > On 17 Nov, 2009, at 09:31 , Aristedes Maniatis wrote: > > > On 17/11/09 6:21 PM, Nikolay Denev wrote: > >> I've also thought about that, but I guess one of the issues is that this > way > >> FreeBSD will by default load CDDL-ed code, which may not be desirable. > >> Probably a compromise would be to build two loaders by default, one with > zfs support and the standard one. > > > > > > I don't believe this is the issue since FreeBSD already comes with zfs.ko > and opensolaris.ko already built by default. That is, it includes the CDDL > code from ZFS itself. The boot loader is a FreeBSD invention (although > probably built with pieces of code from the ZFS module). > > > > Ari Maniatis > > > > -- > > --------------------------> > > ish > > http://www.ish.com.au > > Level 1, 30 Wilson Street Newtown 2042 Australia > > phone +61 2 9550 5001 fax +61 2 9550 4001 > > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > They are built by default, but not loaded in memory by default. That's the > difference. > > > -- > Regards, > Nikolay Denev > _______________________________________________ > 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" > its the loader thats the issue Nikolay not the kernel modules From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 10:14:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 582311065670 for ; Tue, 17 Nov 2009 10:14:26 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E506F8FC17 for ; Tue, 17 Nov 2009 10:14:25 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NAL4n-00086v-Kz for freebsd-current@freebsd.org; Tue, 17 Nov 2009 11:14:21 +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 ; Tue, 17 Nov 2009 11:14:21 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Nov 2009 11:14:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 17 Nov 2009 11:14:06 +0100 Lines: 5 Message-ID: References: <4B023061.7070203@ish.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <4B023061.7070203@ish.com.au> Sender: news Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 10:14:26 -0000 Aristedes Maniatis wrote: > Is it possible that this flag be set to YES in the FreeBSD 8.0 branch > before final release? Certainly not. The release is around the corner. From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 11:15:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99752106566B for ; Tue, 17 Nov 2009 11:15:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 740B18FC17 for ; Tue, 17 Nov 2009 11:15:09 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id ED45846BA3; Tue, 17 Nov 2009 06:15:08 -0500 (EST) Date: Tue, 17 Nov 2009 11:15:08 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Nikolay Denev In-Reply-To: Message-ID: References: <4B023061.7070203@ish.com.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Aristedes Maniatis Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 11:15:09 -0000 On Tue, 17 Nov 2009, Nikolay Denev wrote: > I've also thought about that, but I guess one of the issues is that this way > FreeBSD will by default load CDDL-ed code, which may not be desirable. > Probably a compromise would be to build two loaders by default, one with zfs > support and the standard one. We already build special ZFS-aware boot blocks, so building a special ZFS-aware loader and teaching the ZFS-aware boot blocks how to find it seems like the right answer to me. That way we can build it by default, but not use CDDL code unless specifically requested. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 11:19:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1179B1065672; Tue, 17 Nov 2009 11:19:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E06818FC13; Tue, 17 Nov 2009 11:19:32 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8D73746BA3; Tue, 17 Nov 2009 06:19:32 -0500 (EST) Date: Tue, 17 Nov 2009 11:19:32 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daichi GOTO In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-emulation@FreeBSD.org, current@freebsd.org Subject: Re: JFYI: VirtualBox-3.0.51.r22902_2 bridge networking freeze issue (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 11:19:33 -0000 On Mon, 16 Nov 2009, Daichi GOTO wrote: > At last, I have found an issue situation of system freeze led by bridge > networking. With Vimage enable built kernel, bridge networking feature will > lead system freeze. This is more likely a VIMAGE bug than a VirtualBox bug, as VIMAGE is not yet well-tested or ready for real-world use. I'm not sure if the bridge code is considered productionable with VIMAGE yet? Robert > > checked environment: > FreeBSD 9.0-CURRENT #44: Mon Nov 16 09:51:20 JST 2009 amd64 > virtualbox-3.0.51.r22902_2 > Core2 Quad Q9550 > > I have replaced to Q9550 instead of Q8300 to get VT feature, but this was not > relevant (But from this change, I got an ability to use 64bit OS. My test environment > has been extended ;-). Second, I have got rid of some compile options > (e.x. CPUTYPE=core2) and ccache caches, but this was not relevant, too. > Third, I have changed my BIOS settings and update thats version, yes living > up to your expectations, this was not relevant, too. > > Finally, I have rolled back my kernel to GENERIC and bridge networking works > correctly. Step by step adding kernel options, at last, I have found that Vimage > feature is a cause of this problem. Thanks > > PS > Vimage developer, do you have any ideas? Or with this issue, VirtualBox side > should treat this problem? > > -- > Daichi GOTO > CEO | ONGS Inc. > 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp > LinkedIn: http://linkedin.com/in/daichigoto > > _______________________________________________ > 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 Nov 17 11:21:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D536106568D; Tue, 17 Nov 2009 11:21:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DDB018FC0C; Tue, 17 Nov 2009 11:21:52 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7296D46B03; Tue, 17 Nov 2009 06:21:52 -0500 (EST) Date: Tue, 17 Nov 2009 11:21:52 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> Message-ID: References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Kabaev , freebsd-current@freebsd.org, Ed Maste , Alfred Perlstein Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 11:21:53 -0000 On Mon, 16 Nov 2009, Attilio Rao wrote: > This patch allows gcore to use the ptrace interface rather than procfs: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore.diff > > The main visible effect of that is that gcore can now work on a per-thread > scope, offering a granularity procfs can't reach. A downside, though, is > that the process to be targeted is going to be stopped with ptrace. This > patch has been contributed back by Sandvine Incorporated. Comments, reviews > and testing are welcome. Am I right in thinking that this may run into a number of other issues that the procfs version didn't: - gcore may no longer work on processes that are actively being debugged with gdb or traced with truss. - gcore may cause interruptible system calls in the target process to return EINTR, and interfere with signal delivery. If so, these aren't show-stoppers, but we should make sure they're documented in the gcore man page. Fixing gcore would be excellent, it got missed in the initial sweep of things broken by disabling procfs by default. Thanks for doing this work, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 12:54:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057AE1065679 for ; Tue, 17 Nov 2009 12:54:50 +0000 (UTC) (envelope-from jeremy.thornhill@gmail.com) Received: from mail-bw0-f220.google.com (mail-bw0-f220.google.com [209.85.218.220]) by mx1.freebsd.org (Postfix) with ESMTP id 88B668FC1A for ; Tue, 17 Nov 2009 12:54:48 +0000 (UTC) Received: by bwz20 with SMTP id 20so6877671bwz.14 for ; Tue, 17 Nov 2009 04:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5WEg+5sMKIFJad927oj1CooatqZi5TzP1cOFeaPfADQ=; b=L8jlQ5lXckOzS93p8B9chMQDavtuPJiPMOWuwDmCnuu+YgMoQJM4k3/YPsc4PppCI2 mYWrrAk05oI3xrJmzemQh7e5XQG9/bD1nWJhfcyp4n1p2IgeweMUR7gL7uK/qDoHx+7f chm/Zy+RLy9lefHxHuF+NDH/vtC4N9N4nKjA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WQ8RvrpEi7CgCb5QQOSG37qyW1ckfIw7WdV5nbhHC0yo0hZtyyx6zp7dJpwQMgBFjl 0zWWyO00RC7gDpOF/BOf1y2gXYnbaGq5DH3+Txb5OvTMBgtnqk44PFg/ScS2B3MADuVb meTjA82MW0l3KERfoxJBa7dWmlZrw2VgAi2Xw= MIME-Version: 1.0 Received: by 10.216.86.129 with SMTP id w1mr1696891wee.145.1258462487441; Tue, 17 Nov 2009 04:54:47 -0800 (PST) In-Reply-To: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> References: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> Date: Tue, 17 Nov 2009 07:54:47 -0500 Message-ID: From: Jeremy Thornhill To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 12:54:50 -0000 On Tue, Nov 17, 2009 at 1:57 AM, Stefan Bethke wrote: > > What error are you getting from zpool import? > Interestingly enough, no error. The pool itself just doesn't seem to exist: $ zpool import freeagent cannot import 'freeagent': no such pool available > I believe the GEOM error is due to Solaris adding the GPT partition table= to the start of the device, but not the end. =A0GEOM requires both copies = to be present and identical, IIRC. =A0Since the pool fills the device, ther= e's no space at the end, so adding the second copy is not an option. > > You could try destroying the first GPT copy by zeroing the first 34 block= s. =A0I'm not sure what Solaris will make of the pool after this, though: > # dd if=3D/dev/zero of=3D/dev/da0 count=3D34 > > However, I'd expect this to have no effect on zpools ability to import th= e pool. > I attempted this and, as you expected, I was still unable to import the pool. It still reports 'no such pool', although the GEOM messages *seem* to be gone. Taking this drive back to my Solaris system now results in the following output in dmesg when it is attached (though it still seems to function): primary label corrupt; using backup Oddly the disk doesn't appear in the Solaris 'format' utility so I can't restore the label from backup (or at least, I don't know how to). Thanks, Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 14:17:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B36106566B; Tue, 17 Nov 2009 14:17:14 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail2.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id AF5288FC21; Tue, 17 Nov 2009 14:17:14 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mail2.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:17:15 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id C64991160C; Tue, 17 Nov 2009 09:17:13 -0500 (EST) Date: Tue, 17 Nov 2009 09:17:13 -0500 From: Ed Maste To: Robert Watson Message-ID: <20091117141713.GA51251@sandvine.com> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 17 Nov 2009 14:17:15.0371 (UTC) FILETIME=[A9B603B0:01CA6790] Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 14:17:15 -0000 On Tue, Nov 17, 2009 at 11:21:52AM +0000, Robert Watson wrote: > On Mon, 16 Nov 2009, Attilio Rao wrote: > > >This patch allows gcore to use the ptrace interface rather than procfs: > >http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore.diff > > > >The main visible effect of that is that gcore can now work on a per-thread > >scope, offering a granularity procfs can't reach. A downside, though, is > >that the process to be targeted is going to be stopped with ptrace. This > >patch has been contributed back by Sandvine Incorporated. Comments, > >reviews and testing are welcome. > > Am I right in thinking that this may run into a number of other issues that > the procfs version didn't: > > - gcore may no longer work on processes that are actively being debugged > with gdb or traced with truss. > > - gcore may cause interruptible system calls in the target process to > return EINTR, and interfere with signal delivery. > > If so, these aren't show-stoppers, but we should make sure they're > documented in the gcore man page. Fixing gcore would be excellent, it got > missed in the initial sweep of things broken by disabling procfs by default. Our original motivation for doing this was to make gcore work with threaded apps, not avoiding procfs, but that's a useful side-effect of the work. Note though that for that purpose it isn't complete; procfs is still used in readmap to read the process' memory map. It looks like we need to find a way to implement readmap without procfs. Thanks, Ed From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 14:30:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320A91065695 for ; Tue, 17 Nov 2009 14:30:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f220.google.com (mail-bw0-f220.google.com [209.85.218.220]) by mx1.freebsd.org (Postfix) with ESMTP id AFC828FC14 for ; Tue, 17 Nov 2009 14:30:34 +0000 (UTC) Received: by bwz20 with SMTP id 20so37767bwz.14 for ; Tue, 17 Nov 2009 06:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Frp74EwDpI4U14bVjImle/9/d+RqdCqh1Hiz2ZV2NGw=; b=oQYqQJQGR81jdf1KACW8o71UBVYExeV3jEE+Ro7VyHo+TFwjCRNCMczE06BmekBQhz 35OYhqcd+AeJtiRcK0H9vCElNggmCAITlxULL+4aOUo5aGzfYiSHposY4m0gEQAPCgu4 4feMwERSau6A56hE11sCYgYF8MXPpX7BA5Xxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SYc3+vIgyrpA5smHqgfkZju6OFmIQkSEPfRyiUCjYml9lN9UvPOGrIi28Axki7mz1i jM7Gs3eSjGzkZ+pFxf5BaRKWbCXT260fb5ZTd77gEpfW4DkMSAbZ68trvHubaDAY/R5G sdfWAiXCwyBgva3XpKD76flcKGGOUpTdYJK/U= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.5.18 with SMTP id 18mr141783fat.58.1258468233489; Tue, 17 Nov 2009 06:30:33 -0800 (PST) In-Reply-To: <4B025FA9.7020003@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> <4AFD140D.7010407@icyb.net.ua> <20091113144804.2c0fb90f@orwell.free.de> <4AFD655E.5020801@icyb.net.ua> <20091114022121.217dd831@orwell.free.de> <4AFE7A32.7060203@icyb.net.ua> <4B025FA9.7020003@icyb.net.ua> Date: Tue, 17 Nov 2009 15:30:32 +0100 X-Google-Sender-Auth: 38d0f611aa54a0cc Message-ID: <3bbf2fe10911170630l5b1ebbbgb9bba7e73b77b04d@mail.gmail.com> From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Kai Gallasch Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 14:30:35 -0000 2009/11/17 Andriy Gapon : > on 14/11/2009 11:36 Andriy Gapon said the following: >> on 14/11/2009 03:21 Kai Gallasch said the following: >>> Hi. The patch did help for surviving a makeworld. >>> >>> But now I have another machine check exception with this server. It >>> happened with your patch active, and vm.pmap.pg_ps_enabled="1". I >>> copied data from a remote server by NFS mount to the instable server. >>> Destination was a local ZFS filesystem. >>> >>> ---------------- >>> >>> sonnenkraft:~ # MCA: CPU 7 UNCOR PCC OVER DTLB L1 error >>> MCA: Address 0xff800d860000 >> >> It's interesting because the same happened to me too, only in my case it was >> zpool scrub that triggered it. >> I will try to look into this further. >> > > Kai, > > the latest patch in the works, it's against a clean tree: > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 44b71f3..ff35eb9 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -2365,6 +2365,9 @@ pmap_demote_pde > * the read above and the store below. > */ > pde_store(pde, newpde); > + pmap_invalidate_page(pmap, va); > + clflush((vm_offset_t)vtopde(va)); > + mfence(); > > /* > * Invalidate a stale recursive mapping of the page table page. > @@ -2981,6 +2984,11 @@ setpte: > * Map the superpage. > */ > pde_store(pde, PG_PS | newpde); > + pmap_invalidate_range(pmap, va & ~PDRMASK, (va & ~PDRMASK) + NBPDR); > + clflush((vm_offset_t)vtopde(va)); > + mfence(); > + if (va >= VM_MAXUSER_ADDRESS) > + pmap_invalidate_page(pmap, (vm_offset_t)vtopte(va)); > > pmap_pde_promotions++; > CTR2(KTR_PMAP, "pmap_promote_pde: success for va %#lx" > I think you should use mb() rather than mfence(). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 14:31:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B9AE1065676; Tue, 17 Nov 2009 14:31:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD428FC30; Tue, 17 Nov 2009 14:31:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C2B3C46B32; Tue, 17 Nov 2009 09:31:28 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 12CA98A020; Tue, 17 Nov 2009 09:31:28 -0500 (EST) From: John Baldwin To: WATANABE Kazuhiro Date: Tue, 17 Nov 2009 09:30:52 -0500 User-Agent: KMail/1.9.7 References: <200911061508.22482.jhb@freebsd.org> <20091115051758.8D4C892950@mail1.asahi-net.or.jp> In-Reply-To: <20091115051758.8D4C892950@mail1.asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911170930.52556.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 17 Nov 2009 09:31:28 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org, freebsd-current Subject: Re: [PATCH] Remove if_watchdog use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 14:31:29 -0000 On Sunday 15 November 2009 12:17:57 am WATANABE Kazuhiro wrote: > Hi, > > I've tested the following NICs with your patch on CURRENT, and they > works fine. Thanks! > > * Corega FastEther PCI-TX (DEC 21140-AF) > > de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 12 at device 15.0 on pci0 > de0: 21140A [10-100Mb/s] pass 2.2 > de0: Ethernet address: 00:00:f4:xx:xx:xx > de0: [ITHREAD] > > * Acer ALN-201C (Realtek RTL8029AS) > > ed0: port 0xe000-0xe01f irq 12 at device 15.0 on pci0 > ed0: Ethernet address: 00:60:67:xx:xx:xx > ed0: [ITHREAD] Great, thanks for testing! -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 14:35:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9279810656A3 for ; Tue, 17 Nov 2009 14:35:45 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 23DB88FC0C for ; Tue, 17 Nov 2009 14:35:44 +0000 (UTC) Received: from [10.29.62.2] (port=54762 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1NAPIM-0007Wu-1O for freebsd-current@freebsd.org; Wed, 18 Nov 2009 01:44:38 +1100 Message-ID: <4B02B4BB.30400@ish.com.au> Date: Wed, 18 Nov 2009 01:35:39 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6pre) Gecko/20091108 Shredder/3.0pre MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4B023061.7070203@ish.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 14:35:45 -0000 On 17/11/09 9:14 PM, Ivan Voras wrote: > Aristedes Maniatis wrote: >> Is it possible that this flag be set to YES in the FreeBSD 8.0 branch >> before final release? > > Certainly not. The release is around the corner. In that case, there are some other options: 1. Build the binaries that freebsd-update uses with this flag set. That isn't the same thing as changing the flag in the ISOs of the official FreeBSD 8.0 release. 2. Build logic into freebsd-update which detects that the user has LOADER_ZFS_SUPPORT in src.conf, or else that it is trying to replace a working /boot/loader with a 'defective' version without ZFS capability. I had previously thought freebsd-update took hashes of all system files so it knew which ones had changed and what to warn the user about, but I must have misunderstood that. 3. Deprecate freebsd-update as the recommended way to upgrade FreeBSD systems and put source updates back to the top recommended choices. I've noticed that all recent release notices recommend freebsd-update. Possibly freebsd-update should be maintained as part of the release process and not by someone at arm's length to the re team. In recent times it has broken rebooting after an update twice: once because of the above issue, and earlier when updating from 7.2 to 8.0-beta it was impossible to install a new kernel, reboot and then install world. This wasn't a freebsd-update specific issue (there is an incompatibility between new ZFS kernel modules and old userland tools), but it will bite everyone using freebsd-update and ZFS. I suggest there will be a fair few unhappy people when 8.0 is released and people using ZFS for system files upgrade from 7.x. Then when 8.1 whips around and people who followed instructions to boot from ZFS without a UFS partition, will suffer a second round of pain. Ari Maniatis -- --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 15:14:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A31A106566C for ; Tue, 17 Nov 2009 15:14:10 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 43DB48FC1D for ; Tue, 17 Nov 2009 15:14:10 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id EEA7919E027; Tue, 17 Nov 2009 16:14:08 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 93D8319E023; Tue, 17 Nov 2009 16:14:06 +0100 (CET) Message-ID: <4B02BDBE.6050307@quip.cz> Date: Tue, 17 Nov 2009 16:14:06 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 MIME-Version: 1.0 To: Aristedes Maniatis References: <4B023061.7070203@ish.com.au> <4B02B4BB.30400@ish.com.au> In-Reply-To: <4B02B4BB.30400@ish.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 15:14:10 -0000 Aristedes Maniatis wrote: > On 17/11/09 9:14 PM, Ivan Voras wrote: [...] > Possibly freebsd-update should be maintained as part of the release > process and not by someone at arm's length to the re team. In recent > times it has broken rebooting after an update twice: once because of the > above issue, and earlier when updating from 7.2 to 8.0-beta it was > impossible to install a new kernel, reboot and then install world. This > wasn't a freebsd-update specific issue (there is an incompatibility > between new ZFS kernel modules and old userland tools), but it will bite > everyone using freebsd-update and ZFS. If we are talking about freebsd-update... It would be nice if freebsd-update leave old kernel available in /boot/ as with source upgrade (/boot/kernel.old) at least until second reboot (in case of upgrade), because if new kernel failed to boot after first reboot, then the machine become unbootable without some kind of LiveFS media. [...] Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 15:18:05 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C542E106568B for ; Tue, 17 Nov 2009 15:18:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 98B468FC15 for ; Tue, 17 Nov 2009 15:18:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4AD3F46B1A for ; Tue, 17 Nov 2009 10:18:05 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9958E8A020 for ; Tue, 17 Nov 2009 10:18:04 -0500 (EST) From: John Baldwin To: current@FreeBSD.org Date: Tue, 17 Nov 2009 10:17:58 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911171017.58140.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 17 Nov 2009 10:18:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: [PATCH] Build a separate ZFS-enabled loader.zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 15:18:05 -0000 This patch is a workaround to enabling ZFS support by default in the boot loader. It enables building a loader.zfs which is a ZFS-enabled loader and changing zfsboot and gptzfsboot to use /boot/loader.zfs instead of /boot/loader. I have only tested that things built ok, I have not boot-tested it as I don't have ZFS setup anywhere. The patch is available at http://www.FreeBSD.org/~jhb/loader.zfs/. You will also need to copy the 'loader.zfs/Makefile' file from that URL into a new sys/boot/i386/loader.zfs directory after applying the patch. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 15:26:59 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39B591065672 for ; Tue, 17 Nov 2009 15:26:59 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id E5EFA8FC0A for ; Tue, 17 Nov 2009 15:26:58 +0000 (UTC) Received: from c83-253-248-99.bredband.comhem.se ([83.253.248.99]:33371 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1NAPx5-0006jF-5o; Tue, 17 Nov 2009 16:26:45 +0100 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 11D4538A38; Tue, 17 Nov 2009 16:26:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Backman In-Reply-To: <200911171017.58140.jhb@freebsd.org> Date: Tue, 17 Nov 2009 16:26:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200911171017.58140.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1077) X-Originating-IP: 83.253.248.99 X-Scan-Result: No virus found in message 1NAPx5-0006jF-5o. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1NAPx5-0006jF-5o 1b037f3d813bf17c492be074bd409bbd Cc: current@FreeBSD.org Subject: Re: [PATCH] Build a separate ZFS-enabled loader.zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 15:26:59 -0000 On Nov 17, 2009, at 4:17 PM, John Baldwin wrote: > This patch is a workaround to enabling ZFS support by default in the = boot=20 > loader. It enables building a loader.zfs which is a ZFS-enabled = loader and=20 > changing zfsboot and gptzfsboot to use /boot/loader.zfs instead=20 > of /boot/loader. I have only tested that things built ok, I have not=20= > boot-tested it as I don't have ZFS setup anywhere. The patch is = available at=20 > http://www.FreeBSD.org/~jhb/loader.zfs/. You will also need to copy=20= > the 'loader.zfs/Makefile' file from that URL into a new=20 > sys/boot/i386/loader.zfs directory after applying the patch. If I may ask (and sorry for my ignorance, but): what problem does this = workaround solve? Isn't the whole problem with ZFS loaders the license, and because of the = licence, that a ZFS-capable loader isn't built by default? In other words: Why not use LOADER_ZFS_SUPPORT as long as you have to = choose between setting an option or using a patch? Neither works out of = the box, so you might as well pick the solution that already exists, no = patching involved. I can only assume I'm missing something vital. :) (Please note: Makefiles aren't my strongest suite; I tried to figure the = answer out by reading the patch, but couldn't. I wrote my first own = Makefile, ~15 lines, this weekend.) Regards, Thomas= From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 15:47:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1DFB106566B for ; Tue, 17 Nov 2009 15:47:10 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8A68FC1A for ; Tue, 17 Nov 2009 15:47:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NAQGp-0006FJ-1N for freebsd-current@freebsd.org; Tue, 17 Nov 2009 16:47:07 +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 ; Tue, 17 Nov 2009 16:47:07 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Nov 2009 16:47:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 17 Nov 2009 16:46:37 +0100 Lines: 25 Message-ID: References: <4B023061.7070203@ish.com.au> <4B02B4BB.30400@ish.com.au> <4B02BDBE.6050307@quip.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <4B02BDBE.6050307@quip.cz> Sender: news Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 15:47:11 -0000 Miroslav Lachman wrote: > > > Aristedes Maniatis wrote: >> On 17/11/09 9:14 PM, Ivan Voras wrote: > > [...] > >> Possibly freebsd-update should be maintained as part of the release >> process and not by someone at arm's length to the re team. In recent >> times it has broken rebooting after an update twice: once because of the >> above issue, and earlier when updating from 7.2 to 8.0-beta it was >> impossible to install a new kernel, reboot and then install world. This >> wasn't a freebsd-update specific issue (there is an incompatibility >> between new ZFS kernel modules and old userland tools), but it will bite >> everyone using freebsd-update and ZFS. > > If we are talking about freebsd-update... It would be nice if > freebsd-update leave old kernel available in /boot/ as with source > upgrade (/boot/kernel.old) at least until second reboot (in case of > upgrade), because if new kernel failed to boot after first reboot, then > the machine become unbootable without some kind of LiveFS media. Are you sure it still doesn't do that? I think I saw a recent patch that leaves kernel.old somewhere... From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 15:53:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C911065695 for ; Tue, 17 Nov 2009 15:53:08 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id C253A8FC19 for ; Tue, 17 Nov 2009 15:53:07 +0000 (UTC) Received: (qmail 25757 invoked from network); 17 Nov 2009 16:53:06 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 17 Nov 2009 16:53:06 +0100 Date: Tue, 17 Nov 2009 16:53:04 +0100 From: Kai Gallasch To: Andriy Gapon Message-ID: <20091117165304.01676555@orwell.free.de> In-Reply-To: <4B025FA9.7020003@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> <4AFD140D.7010407@icyb.net.ua> <20091113144804.2c0fb90f@orwell.free.de> <4AFD655E.5020801@icyb.net.ua> <20091114022121.217dd831@orwell.free.de> <4AFE7A32.7060203@icyb.net.ua> <4B025FA9.7020003@icyb.net.ua> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.18.2; powerpc-apple-darwin9.7.0) X-Face: 7"x0zA5=*cXGZw-xjU<">'+!3(KXTUXZVLD42KVN{'go[UQr"Mc.e(XW92N8plZ(9x.{x; I<|95e+b&GH-36\15F~L$YD*Y +u}o&KV?6.%"mJIkaY3G>BKNt`1|Y+%K1P4t; 47D65&(Y7h5Ll-[ltkhamx.-; ,jggK'}oMpUgEHFG YQ"9oXKAl>!d,J}T{)@uxvfu?YFWC*\~h+,^f Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 15:53:08 -0000 Am Tue, 17 Nov 2009 10:32:41 +0200 schrieb Andriy Gapon : > on 14/11/2009 11:36 Andriy Gapon said the following: > > on 14/11/2009 03:21 Kai Gallasch said the following: > >> Hi. The patch did help for surviving a makeworld. > >> > >> But now I have another machine check exception with this server. It > >> happened with your patch active, and vm.pmap.pg_ps_enabled="1". I > >> copied data from a remote server by NFS mount to the instable > >> server. Destination was a local ZFS filesystem. > >> > >> ---------------- > >> > >> sonnenkraft:~ # MCA: CPU 7 UNCOR PCC OVER DTLB L1 error > >> MCA: Address 0xff800d860000 > > > > It's interesting because the same happened to me too, only in my > > case it was zpool scrub that triggered it. > > I will try to look into this further. > > > > Kai, > > the latest patch in the works, it's against a clean tree: > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 44b71f3..ff35eb9 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c Andriy. I tested this latest patch of yours and until now the server did not panic any more with superpages enabled. It survived several makeworld -j8 and also copying many small files over NFS mount to local ZFS. Also "zfs scrub" did not provoke a panic. I'll notify you, should a machine check exception occur again. --Kai. -- For large values of one, one equals two, for small values of two. From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 15:58:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D204F106568B for ; Tue, 17 Nov 2009 15:58:20 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward6.mail.yandex.net (forward6.mail.yandex.net [77.88.60.125]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDAB8FC17 for ; Tue, 17 Nov 2009 15:58:19 +0000 (UTC) Received: from webmail36.yandex.ru (webmail36.yandex.ru [77.88.60.15]) by forward6.mail.yandex.net (Yandex) with ESMTP id 529A5DC901C; Tue, 17 Nov 2009 18:58:16 +0300 (MSK) Received: from localhost (localhost.localdomain [127.0.0.1]) by webmail36.yandex.ru (Yandex) with ESMTP id 208E74F077A; Tue, 17 Nov 2009 18:58:16 +0300 (MSK) X-Yandex-Spam: 1 X-Yandex-Front: webmail36 X-Yandex-TimeMark: 1258473496 Received: from [89.223.19.70] ([89.223.19.70]) by mail.yandex.ru with HTTP; Tue, 17 Nov 2009 18:58:15 +0300 From: S.N.Grigoriev To: Andriy Gapon In-Reply-To: <4B025FA9.7020003@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> <4AFD140D.7010407@icyb.net.ua> <20091113144804.2c0fb90f@orwell.free.de> <4AFD655E.5020801@icyb.net.ua> <20091114022121.217dd831@orwell.free.de> <4AFE7A32.7060203@icyb.net.ua> <4B025FA9.7020003@icyb.net.ua> MIME-Version: 1.0 Message-Id: <24321258473495@webmail36.yandex.ru> Date: Tue, 17 Nov 2009 18:58:15 +0300 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 15:58:20 -0000 17.11.09, 10:32, "Andriy Gapon" wrote: > Kai, > the latest patch in the works, it's against a clean tree: > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 44b71f3..ff35eb9 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -2365,6 +2365,9 @@ pmap_demote_pde > * the read above and the store below. > */ > pde_store(pde, newpde); > + pmap_invalidate_page(pmap, va); > + clflush((vm_offset_t)vtopde(va)); > + mfence(); > /* > * Invalidate a stale recursive mapping of the page table page. > @@ -2981,6 +2984,11 @@ setpte: > * Map the superpage. > */ > pde_store(pde, PG_PS | newpde); > + pmap_invalidate_range(pmap, va & ~PDRMASK, (va & ~PDRMASK) + NBPDR); > + clflush((vm_offset_t)vtopde(va)); > + mfence(); > + if (va >= VM_MAXUSER_ADDRESS) > + pmap_invalidate_page(pmap, (vm_offset_t)vtopte(va)); > pmap_pde_promotions++; > CTR2(KTR_PMAP, "pmap_promote_pde: success for va %#lx" Andriy, I can confirm your patch works for me. I've done 'make -j8 buildworld && make -j8 buildkernel' without problems. -- Regards, S.Grigoriev. From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 16:01:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7C8106566B for ; Tue, 17 Nov 2009 16:01:39 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by mx1.freebsd.org (Postfix) with ESMTP id 771EC8FC17 for ; Tue, 17 Nov 2009 16:01:39 +0000 (UTC) Received: by ywh8 with SMTP id 8so133294ywh.3 for ; Tue, 17 Nov 2009 08:01:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.179.24 with SMTP id g24mr1602849anp.62.1258471965131; Tue, 17 Nov 2009 07:32:45 -0800 (PST) In-Reply-To: References: <200911171017.58140.jhb@freebsd.org> Date: Tue, 17 Nov 2009 16:32:45 +0100 Message-ID: <367b2c980911170732n2eeac045l572aec6fb869eadc@mail.gmail.com> From: Olivier Smedts To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [PATCH] Build a separate ZFS-enabled loader.zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 16:01:39 -0000 2009/11/17 Thomas Backman : > On Nov 17, 2009, at 4:17 PM, John Baldwin wrote: > >> This patch is a workaround to enabling ZFS support by default in the boo= t >> loader. =A0It enables building a loader.zfs which is a ZFS-enabled loade= r and >> changing zfsboot and gptzfsboot to use /boot/loader.zfs instead >> of /boot/loader. =A0I have only tested that things built ok, I have not >> boot-tested it as I don't have ZFS setup anywhere. =A0The patch is avail= able at >> http://www.FreeBSD.org/~jhb/loader.zfs/. =A0You will also need to copy >> the 'loader.zfs/Makefile' file from that URL into a new >> sys/boot/i386/loader.zfs directory after applying the patch. Great you made it so fast, I'll try it this evening (4PM here). Why not call it "zfsloader" (vs "loader", like "zfsboot" vs "boot") ? Sorry if I'm bikeshedding... > If I may ask (and sorry for my ignorance, but): what problem does this wo= rkaround solve? I think the problem is not about having something built by default (like zfs.ko) but to have it loaded in memory. A separate loader would solve that. Cheers, Olivier > Isn't the whole problem with ZFS loaders the license, and because of the = licence, that a ZFS-capable loader isn't built by default? > In other words: Why not use LOADER_ZFS_SUPPORT as long as you have to cho= ose between setting an option or using a patch? Neither works out of the bo= x, so you might as well pick the solution that already exists, no patching = involved. > I can only assume I'm missing something vital. :) > > (Please note: Makefiles aren't my strongest suite; I tried to figure the = answer out by reading the patch, but couldn't. I wrote my first own Makefil= e, ~15 lines, this weekend.) > > Regards, > Thomas_______________________________________________ > 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= " > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 16:07:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72398106568D for ; Tue, 17 Nov 2009 16:07:20 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 00C358FC20 for ; Tue, 17 Nov 2009 16:07:19 +0000 (UTC) Received: by fxm27 with SMTP id 27so145307fxm.3 for ; Tue, 17 Nov 2009 08:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=aSLi0M0/KEJ4hbivMFcCZSmE0ZYUqRawNFebS09plaY=; b=CLsmQqYuWrOkPbOzB09ZXXaYdEkTpD7O/VPncLWoUfPCcBv3ro9BcK2x/VDqqQuLws UYa0FbweB2XrHit6lUUxIq4Ez6AGYRShORlptXOG3YykXFENgNLkm4i+aqHwD9VXd8ZM BeICI62WxJEf3Q4jbxl7nnAScNkcR2MAdvHGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=g0Cr+o3veHSHGDcYA1jzJpOQtWng5V9h7n9kvrbiZ8uTD/wyesZ8OPm5fRJ/MqHc3t gPBROdRbarCOxTHeYTYV7SYbJ49Wi0g9YY1QRA0ib/JSpYTbYWv9QVDkTBUOdw6h+ErX WLM73tV+UEBJ0972QtbLnTATrfIEcef1Y4AHA= Received: by 10.86.158.7 with SMTP id g7mr129891fge.53.1258472622661; Tue, 17 Nov 2009 07:43:42 -0800 (PST) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id e11sm1444639fga.12.2009.11.17.07.43.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 07:43:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Tue, 17 Nov 2009 17:43:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200911171017.58140.jhb@freebsd.org> To: Thomas Backman X-Mailer: Apple Mail (2.1077) Cc: current@FreeBSD.org Subject: Re: [PATCH] Build a separate ZFS-enabled loader.zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 16:07:20 -0000 On Nov 17, 2009, at 5:26 PM, Thomas Backman wrote: > On Nov 17, 2009, at 4:17 PM, John Baldwin wrote: >=20 >> This patch is a workaround to enabling ZFS support by default in the = boot=20 >> loader. It enables building a loader.zfs which is a ZFS-enabled = loader and=20 >> changing zfsboot and gptzfsboot to use /boot/loader.zfs instead=20 >> of /boot/loader. I have only tested that things built ok, I have not=20= >> boot-tested it as I don't have ZFS setup anywhere. The patch is = available at=20 >> http://www.FreeBSD.org/~jhb/loader.zfs/. You will also need to copy=20= >> the 'loader.zfs/Makefile' file from that URL into a new=20 >> sys/boot/i386/loader.zfs directory after applying the patch. > If I may ask (and sorry for my ignorance, but): what problem does this = workaround solve? > Isn't the whole problem with ZFS loaders the license, and because of = the licence, that a ZFS-capable loader isn't built by default? > In other words: Why not use LOADER_ZFS_SUPPORT as long as you have to = choose between setting an option or using a patch? Neither works out of = the box, so you might as well pick the solution that already exists, no = patching involved. > I can only assume I'm missing something vital. :) >=20 > (Please note: Makefiles aren't my strongest suite; I tried to figure = the answer out by reading the patch, but couldn't. I wrote my first own = Makefile, ~15 lines, this weekend.) >=20 > Regards, > Thomas_______________________________________________ > 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 think that you are missing the fact that "built by default" and = "loaded by default" are two different things. Regards, Niki Denev From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 16:30:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8E61065696; Tue, 17 Nov 2009 16:30:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D92468FC1F; Tue, 17 Nov 2009 16:30:25 +0000 (UTC) Received: from [192.168.14.4] (unknown [62.49.66.13]) by cyrus.watson.org (Postfix) with ESMTPSA id 24D5E46B06; Tue, 17 Nov 2009 11:30:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20091117141713.GA51251@sandvine.com> Date: Tue, 17 Nov 2009 16:30:24 +0000 Content-Transfer-Encoding: 7bit Message-Id: <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1077) Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 16:30:26 -0000 On 17 Nov 2009, at 14:17, Ed Maste wrote: > Our original motivation for doing this was to make gcore work with > threaded apps, not avoiding procfs, but that's a useful side-effect of > the work. Note though that for that purpose it isn't complete; procfs > is still used in readmap to read the process' memory map. It looks like > we need to find a way to implement readmap without procfs. Are the sysctls used for procstat -v sufficient for this purpose? Robert From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 16:44:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 673DC1065670; Tue, 17 Nov 2009 16:44:44 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 652E68FC22; Tue, 17 Nov 2009 16:44:42 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id ECEEC19E019; Tue, 17 Nov 2009 17:44:40 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6A35E19E023; Tue, 17 Nov 2009 17:44:38 +0100 (CET) Message-ID: <4B02D2F5.4090706@quip.cz> Date: Tue, 17 Nov 2009 17:44:37 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 MIME-Version: 1.0 To: Ivan Voras References: <4B023061.7070203@ish.com.au> <4B02B4BB.30400@ish.com.au> <4B02BDBE.6050307@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 16:44:44 -0000 Ivan Voras wrote: > Miroslav Lachman wrote: [...] >> If we are talking about freebsd-update... It would be nice if >> freebsd-update leave old kernel available in /boot/ as with source >> upgrade (/boot/kernel.old) at least until second reboot (in case of >> upgrade), because if new kernel failed to boot after first reboot, >> then the machine become unbootable without some kind of LiveFS media. > > Are you sure it still doesn't do that? I think I saw a recent patch that > leaves kernel.old somewhere... It is nice if it is already patched! I didn't test it with latest releases of 8.0-RCx so I am not sure. I am creating kernel.old by hand copy ;) Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 17:12:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3867F1065672 for ; Tue, 17 Nov 2009 17:12:38 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id DD4A08FC15 for ; Tue, 17 Nov 2009 17:12:37 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAHHCPne010348 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 12:12:35 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Jeremy Thornhill In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Tue, 17 Nov 2009 11:12:17 -0600 Message-Id: <1258477937.2303.51.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 17:12:38 -0000 On Mon, 2009-11-16 at 23:10 -0500, Jeremy Thornhill wrote: > Dear list, > > I've been trying out 8.0-RC3 on a spare machine. I've been hoping that > 8.0 would be a good time to move my ZFS pools from an old Solaris x86 > box to FreeBSD. > > I've been testing the procedure with a USB drive which was allocated > as a single pool under Solaris. It's the correct filesystem version > (13). I export the pool from the Solaris box, and then attempt to > import it on the FreeBSD box. Unfortunately, I get the following > error, and the pool is not able to be imported: > > GEOM: da0: corrupt or invalid GPT detected. > GEOM: da0: GPT rejected -- may not be recoverable. This should be fixed in -CURRENT. The issue seems to be that solaris claims that the GPT header is 512 bytes, where we expected it to always be 92 bytes. The fixes are slated to merge to 7/8 stable within a few days, however they won't make it into 8.0. robert. > I've seen some recent posts on the lists where a helpful developer > assisted a user suffering from a similar circumstance, but I wasn't > able to determine if there is a general way for users to resolve such > issues. If I understand correctly this is an incompatibility in how > Solaris partitions disks when they are allocated entirely to a pool. > > So, before I attempt this full scale on my raidz array, can anybody > point me in the right direction to get beyond this error and make my > Solaris ZFS pools work in FreeBSD? > > Thanks, > Jeremy > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 15:19:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 206CD1065694 for ; Tue, 17 Nov 2009 15:19:38 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0C88FC1F for ; Tue, 17 Nov 2009 15:19:37 +0000 (UTC) Received: from phenom (mary-teresa.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.3) with ESMTP id nAHFJH2j064471; Tue, 17 Nov 2009 17:19:19 +0200 (EET) (envelope-from universite@ukr.net) X-Authentication-Warning: mary-teresa.otrada.od.ua: Host mary-teresa.otrada.od.ua [10.0.0.10] claimed to be phenom X-AntiVirus: Checked by Dr.Web [version: 5.0, engine: 5.00.0.12182, virus records: 797079, updated: 17.11.2009] Message-ID: <4B02BEF3.3090507@ukr.net> Date: Tue, 17 Nov 2009 17:19:15 +0200 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ofsen@enderunix.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 17 Nov 2009 17:19:40 +0000 Cc: Subject: FreeBSD: ports/mail/isoqlog (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:19:38 -0000 Subj does not work on amd64 platform Immediately after the launch of falls in core dump # uname -a FreeBSD mary-teresa.otrada.od.ua 8.0-RC1 FreeBSD 8.0-RC1 #0: Wed Oct 14 00:59:52 EEST 2009 vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.20 amd64 There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Core was generated by `isoqlog'. Program terminated with signal 11, Segmentation fault. #0 0x000000000040ad66 in ?? () (gdb) bt #0 0x000000000040ad66 in ?? () #1 0x0000000800888870 in ?? () #2 0x0000000000000000 in ?? () #3 0x0000000000000000 in ?? () #4 0x0000000000000001 in ?? () #5 0x000000010099c800 in ?? () #6 0x000000000000001c in ?? () #7 0x000000080099c800 in ?? () #8 0x000000080099c800 in ?? () #9 0x0000000800888740 in ?? () #10 0x00000008009a8400 in ?? () #11 0x0000000800888870 in ?? () #12 0x0000000000408bdc in ?? () #13 0x00000000005239e0 in ?? () #14 0x0000000000000010 in ?? () #15 0x0000000800000034 in ?? () #887 0x0000000000000000 in ?? () #888 0x0000000000000000 in ?? () #889 0x0000000000000000 in ?? () #890 0x0000000000000000 in ?? () #891 0x0000000000000000 in ?? () #892 0x0000000000000000 in ?? () #893 0x0000000000000000 in ?? () #894 0x6f6c2f7273752f00 in ?? () #895 0x2f6e69622f6c6163 in ?? () #896 0x00676f6c716f7369 in ?? () ---Type to continue, or q to quit--- #897 0x247c8d48002454ff in ?? () #898 0x01a1c0c748006a10 in ?? () #899 0x66fdebf4050f0000 in ?? () #900 0x9066669066669066 in ?? () #901 0x00007fffffffe6a8 in ?? () #902 0x0000000000000001 in ?? () #903 0x00007fffffffe6b8 in ?? () #904 0x000000000000001d in ?? () Cannot access memory at address 0x800000000000 (gdb) From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 17:20:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B5671065695 for ; Tue, 17 Nov 2009 17:20:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id DEA9B8FC23 for ; Tue, 17 Nov 2009 17:20:01 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAHHJpMZ010375 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 12:19:59 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Stefan Bethke In-Reply-To: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> References: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> Content-Type: text/plain Organization: FreeBSD Date: Tue, 17 Nov 2009 11:19:43 -0600 Message-Id: <1258478383.2303.57.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, Jeremy Thornhill Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 17:20:02 -0000 On Tue, 2009-11-17 at 07:57 +0100, Stefan Bethke wrote: > Am 17.11.2009 um 05:10 schrieb Jeremy Thornhill: > > > I've been testing the procedure with a USB drive which was allocated > > as a single pool under Solaris. It's the correct filesystem version > > (13). I export the pool from the Solaris box, and then attempt to > > import it on the FreeBSD box. Unfortunately, I get the following > > error, and the pool is not able to be imported: > > > > GEOM: da0: corrupt or invalid GPT detected. > > GEOM: da0: GPT rejected -- may not be recoverable. > > What error are you getting from zpool import? zpool import won't do anything until GEOM is able to probe the disks. > I believe the GEOM error is due to Solaris adding the GPT partition table to the start of the device, but not the end. GEOM requires both copies to be present and identical, IIRC. Since the pool fills the device, there's no space at the end, so adding the second copy is not an option. Incorrect, Both primary and secondary headers are present, the above GEOM error is stating that ALL copies of GPT headers have been deemed invalid. > You could try destroying the first GPT copy by zeroing the first 34 blocks. I'm not sure what Solaris will make of the pool after this, though: > # dd if=/dev/zero of=/dev/da0 count=34 Bad advice. This will will destroy your partition table and you likely won't be able to recover the disk. It is possible to hex edit the existing solaris headers to make this work on FreeBSD, though I have committed a proper fix to -CURRENT. > However, I'd expect this to have no effect on zpools ability to import the pool. If GEOM can't figure out the disk structure, zpool / zfs are useless. robert. > > HTH, > Stefan -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 17:30:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECFAB10656C1 for ; Tue, 17 Nov 2009 17:30:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9A42D8FC1A for ; Tue, 17 Nov 2009 17:30:02 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAHHTrOb010428 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 12:29:56 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Jeremy Thornhill In-Reply-To: References: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> Content-Type: text/plain Organization: FreeBSD Date: Tue, 17 Nov 2009 11:29:47 -0600 Message-Id: <1258478987.2303.62.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 17:30:03 -0000 On Tue, 2009-11-17 at 07:54 -0500, Jeremy Thornhill wrote: > On Tue, Nov 17, 2009 at 1:57 AM, Stefan Bethke wrote: > > > > What error are you getting from zpool import? > > > > Interestingly enough, no error. The pool itself just doesn't seem to exist: > > $ zpool import freeagent > cannot import 'freeagent': no such pool available > > > I believe the GEOM error is due to Solaris adding the GPT partition table to the start of the device, but not the end. GEOM requires both copies to be present and identical, IIRC. Since the pool fills the device, there's no space at the end, so adding the second copy is not an option. > > > > You could try destroying the first GPT copy by zeroing the first 34 blocks. I'm not sure what Solaris will make of the pool after this, though: > > # dd if=/dev/zero of=/dev/da0 count=34 > > > > However, I'd expect this to have no effect on zpools ability to import the pool. > > > > I attempted this and, as you expected, I was still unable to import > the pool. It still reports 'no such pool', although the GEOM messages > *seem* to be gone. Taking this drive back to my Solaris system now > results in the following output in dmesg when it is attached (though > it still seems to function): > > primary label corrupt; using backup Sigh, yes... you have now trashed you primary gpt table. PLEASE do not go using dd to write stuff to your disks unless you a) know what your doing or b) don't care if you trash your disks... > Oddly the disk doesn't appear in the Solaris 'format' utility so I > can't restore the label from backup (or at least, I don't know how > to). If is important... I can help you restore the primary header... robert. > Thanks, > Jeremy > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 17:48:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68623106568D for ; Tue, 17 Nov 2009 17:48:14 +0000 (UTC) (envelope-from jeremy.thornhill@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id C45D08FC16 for ; Tue, 17 Nov 2009 17:48:13 +0000 (UTC) Received: by fxm27 with SMTP id 27so256551fxm.3 for ; Tue, 17 Nov 2009 09:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BvHr3iao/vlBTQmxGpxe3KG3suij+L595qj+TgedTAc=; b=BUGSmpyec5M7Ai4TtjBkG6mNAHTlFpRCkYUZta7hLYrrD04tNusJGNjxpxjPxtS9js EeTf+LALhvBaZ/aTt35o6FpCq8LpxDkjVKrSvdVTDoa3rP/3hDnAUJr5/laB1lBHu07L BD1x2DhEwee9Ko9+cejs6WisafHE/3kWOpyzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HTk691gScF5KbryYxWroU/AITmf3z9hZDPdxsBU5qikyxAo6wYMf30OuW9Fn5CVbsr Y+SRtUXrIH25o+fxUJTNMH7EDXl8m62O7I00NVSSQ55uuQmIEbO8931PrQuypq7O16ea 6lHPhnMv0CIMGiOMAgptel6Ny6cpPW9Y0v/FY= MIME-Version: 1.0 Received: by 10.216.86.213 with SMTP id w63mr914782wee.71.1258480092485; Tue, 17 Nov 2009 09:48:12 -0800 (PST) In-Reply-To: <1258478987.2303.62.camel@balrog.2hip.net> References: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> <1258478987.2303.62.camel@balrog.2hip.net> Date: Tue, 17 Nov 2009 12:48:12 -0500 Message-ID: From: Jeremy Thornhill To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 17:48:14 -0000 On Tue, Nov 17, 2009 at 12:29 PM, Robert Noland wrote > This should be fixed in -CURRENT. The issue seems to be that solaris > claims that the GPT header is 512 bytes, where we expected it to always > be 92 bytes. The fixes are slated to merge to 7/8 stable within a few > days, however they won't make it into 8.0. Great news, thanks! > Sigh, yes... you have now trashed you primary gpt table. =A0PLEASE do not > go using dd to write stuff to your disks unless you a) know what your > doing or b) don't care if you trash your disks... > Indeed, I did not really care much about this disk, it's only a backup. I was using it as a dry run to see if I would encounter any issues before moving the 'real' data, and it did this job admirably :) > If is important... I can help you restore the primary header... Thanks, the disk is just fine again. I managed to restore the backup label using the Solaris system (after I RTFM'd on 'format'). Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 18:08:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F4E1065697 for ; Tue, 17 Nov 2009 18:08:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outb.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF3D8FC12 for ; Tue, 17 Nov 2009 18:08:34 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 6208014E096; Tue, 17 Nov 2009 10:08:53 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 5DC472D601C; Tue, 17 Nov 2009 10:08:33 -0800 (PST) Message-ID: <4B02E69E.40008@elischer.org> Date: Tue, 17 Nov 2009 10:08:30 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, Daichi GOTO , current@freebsd.org Subject: Re: JFYI: VirtualBox-3.0.51.r22902_2 bridge networking freeze issue (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 18:08:34 -0000 Robert Watson wrote: > > On Mon, 16 Nov 2009, Daichi GOTO wrote: > >> At last, I have found an issue situation of system freeze led by >> bridge networking. With Vimage enable built kernel, bridge networking >> feature will lead system freeze. > > This is more likely a VIMAGE bug than a VirtualBox bug, as VIMAGE is not > yet well-tested or ready for real-world use. I'm not sure if the bridge > code is considered productionable with VIMAGE yet? I believe not. we use the netgraph bridging because it can act as a reverse bridge (multiple top ends, a single physical interface) So we have not really done much with the standard if_bridge code yet. Certainly it is not well tested if it works at all. > > Robert > >> >> checked environment: >> FreeBSD 9.0-CURRENT #44: Mon Nov 16 09:51:20 JST 2009 amd64 >> virtualbox-3.0.51.r22902_2 >> Core2 Quad Q9550 >> >> I have replaced to Q9550 instead of Q8300 to get VT feature, but this >> was not >> relevant (But from this change, I got an ability to use 64bit OS. My >> test environment >> has been extended ;-). Second, I have got rid of some compile options >> (e.x. CPUTYPE=core2) and ccache caches, but this was not relevant, too. >> Third, I have changed my BIOS settings and update thats version, yes >> living >> up to your expectations, this was not relevant, too. >> >> Finally, I have rolled back my kernel to GENERIC and bridge networking >> works >> correctly. Step by step adding kernel options, at last, I have found >> that Vimage >> feature is a cause of this problem. Thanks >> >> PS >> Vimage developer, do you have any ideas? Or with this issue, >> VirtualBox side >> should treat this problem? >> >> -- >> Daichi GOTO >> CEO | ONGS Inc. >> 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp >> LinkedIn: http://linkedin.com/in/daichigoto >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 18:12:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31B85106566C; Tue, 17 Nov 2009 18:12:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E3E3E8FC1B; Tue, 17 Nov 2009 18:12:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAHICRgr092155; Tue, 17 Nov 2009 13:12:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAHICRRf092151; Tue, 17 Nov 2009 18:12:27 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 Nov 2009 18:12:27 GMT Message-Id: <200911171812.nAHICRRf092151@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:12:29 -0000 TB --- 2009-11-17 17:06:17 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-17 17:06:17 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-11-17 17:06:17 - cleaning the object tree TB --- 2009-11-17 17:06:31 - cvsupping the source tree TB --- 2009-11-17 17:06:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-11-17 17:07:01 - building world TB --- 2009-11-17 17:07:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-17 17:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-17 17:07:01 - TARGET=powerpc TB --- 2009-11-17 17:07:01 - TARGET_ARCH=powerpc TB --- 2009-11-17 17:07:01 - TZ=UTC TB --- 2009-11-17 17:07:01 - __MAKE_CONF=/dev/null TB --- 2009-11-17 17:07:01 - cd /src TB --- 2009-11-17 17:07:01 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 17 17:07:02 UTC 2009 >>> 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 Nov 17 18:06:57 UTC 2009 TB --- 2009-11-17 18:06:57 - generating LINT kernel config TB --- 2009-11-17 18:06:57 - cd /src/sys/powerpc/conf TB --- 2009-11-17 18:06:57 - /usr/bin/make -B LINT TB --- 2009-11-17 18:06:57 - building LINT kernel TB --- 2009-11-17 18:06:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-17 18:06:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-17 18:06:57 - TARGET=powerpc TB --- 2009-11-17 18:06:57 - TARGET_ARCH=powerpc TB --- 2009-11-17 18:06:57 - TZ=UTC TB --- 2009-11-17 18:06:57 - __MAKE_CONF=/dev/null TB --- 2009-11-17 18:06:57 - cd /src TB --- 2009-11-17 18:06:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 17 18:06:57 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/stge/if_stge.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sym/sym_hipd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/syscons/schistory.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/syscons/scmouse.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/syscons/scterm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/syscons/scvidctl.c /src/sys/dev/syscons/scvidctl.c: In function 'sc_set_pixel_mode': /src/sys/dev/syscons/scvidctl.c:462: error: too few arguments to function 'pgsignal' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-17 18:12:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-17 18:12:27 - ERROR: failed to build lint kernel TB --- 2009-11-17 18:12:27 - 2994.20 user 598.76 system 3970.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 18:20:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDC41065696 for ; Tue, 17 Nov 2009 18:20:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id E37878FC2A for ; Tue, 17 Nov 2009 18:20:36 +0000 (UTC) Received: by qyk6 with SMTP id 6so198265qyk.3 for ; Tue, 17 Nov 2009 10:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=C4DgZUz8RpRwcy77z7GEV0deJZEsskEoDOmYeMusVPU=; b=pKr/Sf8mbL2pHefHiJ5l0j83ZnUJ7PbJp7Sg4kOzIHCSnhgWNVW1ZpyhhFdpXW5KsQ uOSTkPG3h2jVPXCc+QDVRItYQs1xRMfW4r2qtLCWLZVMiLTdZnrnlqQW/JfEdYMWKR4d Hs71RGqlVssAsg7Q7k1QmSrdns/OpcnD/xvFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BZWpEmHt/HP1IXxVYuCf6d83KNznzbuNBltU2j9+PBhl104BsbBaNGvZzr6a41wm80 YC0EBnUpXWkSy85+ITtlVT3DRqtpsXmVYbX2OAVASAgG++pXQ1KB0z5K6ggUcPEpgA3I rkSpmHOQbxIzOd+KScIyn9uMtHHvKH2XrdoWY= Received: by 10.224.104.130 with SMTP id p2mr5796356qao.164.1258482036275; Tue, 17 Nov 2009 10:20:36 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm22435021qwg.0.2009.11.17.10.20.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 10:20:35 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Nov 2009 10:20:05 -0800 From: Pyun YongHyeon Date: Tue, 17 Nov 2009 10:20:05 -0800 To: Gleb Kurtsou Message-ID: <20091117182005.GH1262@michelle.cdnetworks.com> References: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> <20091111231426.GF15449@michelle.cdnetworks.com> <20091115091309.GA1539@tops.skynet.lt> <20091116181304.GC1262@michelle.cdnetworks.com> <20091116203231.GA1597@tops.skynet.lt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091116203231.GA1597@tops.skynet.lt> User-Agent: Mutt/1.4.2.3i Cc: Mel Flynn , freebsd-current@freebsd.org Subject: Re: Possible regression with msk driver 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, 17 Nov 2009 18:20:37 -0000 On Mon, Nov 16, 2009 at 10:32:31PM +0200, Gleb Kurtsou wrote: > On (16/11/2009 10:13), Pyun YongHyeon wrote: > > On Sun, Nov 15, 2009 at 11:13:10AM +0200, Gleb Kurtsou wrote: > [...] > > > I experience similar problem. After boot msk0 status is active, but I'm > > > not able to send anything: > > > % ping 172.21.21.21 > > > PING 172.21.21.21 (172.21.21.21): 56 data bytes > > > ping: sendto: No buffer space available > > > ping: sendto: No buffer space available > > > > > > After unplugging cable and putting it back everything works as > > > expected: > > > % ping 172.21.21.21 > > > PING 172.21.21.21 (172.21.21.21): 56 data bytes > > > 64 bytes from 172.21.21.21: icmp_seq=0 ttl=64 time=0.904 ms > > > > > > It is 100% reproducible, running recent current. > > > > > > % uname -a > > > FreeBSD tops 9.0-CURRENT FreeBSD 9.0-CURRENT #17 r199274+c8076f9: Sat Nov 14 22:59:26 EET 2009 root@tops:/usr/obj/usr/freebsd-src/local/sys/TOPS amd64 > > > > > > % ifconfig > > > msk0: flags=8843 metric 0 mtu 1500 > > > options=11a > > > ether * > > > inet 172.21.21.22 netmask 0xfffffff8 broadcast 172.21.21.23 > > > inet6 * prefixlen 64 scopeid 0x1 > > > nd6 options=29 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > > > My hardware: > > > mskc0@pci0:2:0:0: class=0x020000 card=0x902d104d chip=0x435311ab rev=0x15 hdr=0x00 > > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > > device = 'Gigabit (88E8039 - http://www.marvell.com/drivers/driverDis)' > > > class = network > > > subclass = ethernet > > > > > > > I guess some changes made to reduce unnecessary controller > > reinitialization seems to cause the issue. > > Would you try attached patch? > > Patch fixes the issue. I tried rebooting several times with > connected/disconnected cable. I'll let you know if any problem shows up > later. > Patch committed to HEAD(r199413). Thanks for testing! From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 18:50:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 649051065672 for ; Tue, 17 Nov 2009 18:50:15 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 198188FC19 for ; Tue, 17 Nov 2009 18:50:14 +0000 (UTC) Received: by gxk10 with SMTP id 10so311166gxk.3 for ; Tue, 17 Nov 2009 10:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=GaoNq3NLQFEYUGGCJVYcEuLOg3ecL+ibKhQLLGztEEg=; b=jl+o6uLWLHPzKTlTSbxV7R3PYXL2mkmc2zdSyVo1HXVGRWupEBuYyChGbXVqyle39E lqs+0uXfnFeFEZHqNrx+imLAzVPRuznxD02iFJllYtG3zKc6BW8K3E3pGTfPAdja4zW0 eNc8GvCcCnVb1YHJMAGWLwv7bqWfyVDxfDg6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=luk1hzAJZBSm13FrLZBhVkXv24T4jz6XGogBNc2qpinQxQwUW7KMkB9lnlBo8QX/r6 e64+oPGN2IxEnCgWzPVerruNhlTpMMPuRwN4N2DZs5YxxAe75X3oMklb2DPSnKEdyTJt sd8A7ZqUOEidLQiLXyQ/O5io23z48NZfS5qiA= Received: by 10.150.208.10 with SMTP id f10mr662836ybg.55.1258483813414; Tue, 17 Nov 2009 10:50:13 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 15sm548206gxk.8.2009.11.17.10.50.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 10:50:11 -0800 (PST) From: Gonzalo Nemmi To: pyunyh@gmail.com, freebsd-apci@freebsd.org Date: Tue, 17 Nov 2009 16:50:06 -0200 User-Agent: KMail/1.9.10 References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911161534.34028.gnemmi@gmail.com> <20091116175450.GB1262@michelle.cdnetworks.com> In-Reply-To: <20091116175450.GB1262@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911171650.06834.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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, 17 Nov 2009 18:50:15 -0000 On Monday 16 November 2009 3:54:50 pm Pyun YongHyeon wrote: > On Mon, Nov 16, 2009 at 03:34:33PM -0200, Gonzalo Nemmi wrote: > > On Sunday 15 November 2009 11:58:16 pm Pyun YongHyeon wrote: > > > On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote: > > > > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote: > > > > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > > > > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > > > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I had been working on fixing bus_dma(9) bugs and adding > > > > > > > > TSO capability to bge(4). Now TSO is supported for > > > > > > > > BCM5755 or newer controllers. Actually some pre-BCM5755 > > > > > > > > controllers also support TSO with the help of special > > > > > > > > firmware but the license issue and lower performance of > > > > > > > > firmware based TSO as well as TSO bug I intentionally > > > > > > > > excluded TSO support for pre-BCM5755 controllers. You > > > > > > > > can get the patch form the following URL. The diff was > > > > > > > > generated against latest HEAD. > > > > > > > > > > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.dif > > > > > > > >f > > > > > > > > > > > > > > Eh, there was a typo so I regenerated the diff. > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.dif > > > > > > >f > > > > > > > > > > > > Hi > > > > > > Just wanted to know before getting on to it, will your > > > > > > patch help to resolve kern/136876? > > > > > > > > > > My diff includes a fix for assuming PCIe device control > > > > > register and MSI control registers would be reside in fixed > > > > > address. And from the pciconf output I see the your MSI > > > > > control register is located at different address. However > > > > > bge(4) does not touch that register for BCM5906 so I guess my > > > > > diff may not fix the resume issue. > > > > > > > > Thanks a lot for your prompt, clear and straight answer. > > > > > > Would you try attached patch for BCM5906 resume issue? Not sure > > > whether it help or not though. > > > > Hi Pyun! > > Sorry for the delay, I was out of town and just got back. > > I'm downloading RC3 as of now. Then I will install: > > edit make.conf > > edit src.conf > > buildworld > > buildkernel > > installkernel > > reboot > > > > mergemaster -p > > make installworld > > reboot > > > > cp bge.diff bge.patch > > cd /usr/src/sys/dev/bge && patch < /path/to/patch > > make > > make install clean > > kldunload if_bge > > Not sure you removed bge in GENERIC kernel configuration file. > > > kldload if_bge > > pciconf -lcvb > > ifconfig bge0 up > > acpiconf -s3 > > > > ... and hpefully .. resume from S3 .. > > > > Is that ok with you or would you like me to do it in another way? > > That's ok. At first I wanted to add WOL to wake up bge(4) with > magic packet but bge(4) seems to require a lot of workaround for > each controller and it's too complex to implement at this time. > Just want to know whether bge(4) can resume from suspend. Well, I proceeded as I told you I would, applied your patch and even if it didn't solve the problem (bge still doesn't resume) at least it improved the previous situation given that now it doesn't loop timing out once and again as before. You can find a tail from /var/log/messages in here: http://pastebin.com/f643555f7 As you can see, the first 3 lines corresponds to "kldload if_bge" Line number 4 is "acpiconf -s3" At line number 17 bge0 finally fails and let's the machine wake up at line 18. Then, as soon as I could I issued a "ifconfig bge0" to see what I could get .. that's what you can see from line 20 to line 41. (as you can see in there, I found there are problems resuming umass devices as well ... ) Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the way, once unloaded, I could load it again but bge0 never showed on "ifconfig". Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ... which ended with pulling the pendrive out as the system coldn't umount it ... I also found I get wpi0 messages on resume .. it spouts: wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory and then it let's the system resume. All in all .. there's _a_lot_of_problems_on_resume_ Pyun, if you'd like me to try a new patch or to do some tests or whatever, just let me know. I'm here awaiting orders :) Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 19:24:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36B821065772 for ; Tue, 17 Nov 2009 19:24:34 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f190.google.com (mail-iw0-f190.google.com [209.85.223.190]) by mx1.freebsd.org (Postfix) with ESMTP id F1CB68FC0A for ; Tue, 17 Nov 2009 19:24:33 +0000 (UTC) Received: by iwn28 with SMTP id 28so281759iwn.3 for ; Tue, 17 Nov 2009 11:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MRLWLzPS4fa6Xguhyxr9C+ac48LP8Sf3uV1PU9y3XOI=; b=vvSeR8NcEFNZ2R3/hbzB6SVol4BaDmTfGQdFAHCD653+VThxD2s6fXbq1CNWHg0k6P mVMCBi5SRO7EcyHRImGWr06ei2de7Wpy2RyL60ddnzdXi5WbACXAP1wP0MarlDP8UWUn Hf1hdI8KggTFUw9Kslvci/vypHnAq4HmM491k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j20jqVztvf8JNlr+l3zpZcZ/j/kgQ9cQaivSwjabgONShEaJ44TMbnDc5SdvuJeGzX UFhdgFhcLpBK4g9jcQU97i6YKGi0MV33kBN4y2qrkL11888wuIzEey2G4twe+AeEyrtW F6DTbNwXUVTm3Vw+/ywQ7GK69nhI8Hc6xWsOI= MIME-Version: 1.0 Received: by 10.231.83.75 with SMTP id e11mr2167291ibl.11.1258483905318; Tue, 17 Nov 2009 10:51:45 -0800 (PST) In-Reply-To: References: <200911171017.58140.jhb@freebsd.org> Date: Tue, 17 Nov 2009 12:51:45 -0600 Message-ID: <790a9fff0911171051u167c40fpf62deb8102fa0468@mail.gmail.com> From: Scot Hetzel To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [PATCH] Build a separate ZFS-enabled loader.zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 19:24:34 -0000 On Tue, Nov 17, 2009 at 9:26 AM, Thomas Backman wrot= e: > On Nov 17, 2009, at 4:17 PM, John Baldwin wrote: > >> This patch is a workaround to enabling ZFS support by default in the boo= t >> loader. =A0It enables building a loader.zfs which is a ZFS-enabled loade= r and >> changing zfsboot and gptzfsboot to use /boot/loader.zfs instead >> of /boot/loader. =A0I have only tested that things built ok, I have not >> boot-tested it as I don't have ZFS setup anywhere. =A0The patch is avail= able at >> http://www.FreeBSD.org/~jhb/loader.zfs/. =A0You will also need to copy >> the 'loader.zfs/Makefile' file from that URL into a new >> sys/boot/i386/loader.zfs directory after applying the patch. > If I may ask (and sorry for my ignorance, but): what problem does this wo= rkaround solve? This solution fixes boot issues on systems that are using ZFS to boot FreeBSD. Currently, if such a system uses the freebsd-update service to update the system, it receives a /boot/loader that doesn't support booting from a ZFS root and breaks the boot process. It also makes it easier to setup a Root On ZFS system, as you will no longer need to add LOADER_ZFS_SUPPORT to /etc/src.conf and rebuilding the /boot/loader. Scot From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 19:32:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F301065670 for ; Tue, 17 Nov 2009 19:32:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 02FE08FC16 for ; Tue, 17 Nov 2009 19:32:43 +0000 (UTC) Received: by qyk6 with SMTP id 6so237694qyk.3 for ; Tue, 17 Nov 2009 11:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=h7aHeyNXGaMEqDmz6RhOT65cg+J40ITeHOce11v80bw=; b=oDiZBOM8XyVnIlvdOI3PavkA0aaBoQXWS6pQ6KL8vdQ/3+yVUFl6OsWS4boESwx6r2 lRlqBDDE5IQhMXDLUdiDMvd57JE8TSMertOZVHKuI/uvdjrri+5tbDzztGdl58trqMhy RWPDb8HBbm5TtLK8Lj3lIfDM/XmeryD3AHYM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=I7v7ZQ9gUuKcgKwzd+4+5V8oPoQs/0RVnHQcVxjszfQixqKTP3jOPJEtNKNsX0MhAR znkpIbbkrl5Bup6offPzLMvtNcCIfrG/BZzab8jef+aCOX1l8THYhwdAMa3CRkVV+8mf 4JIUig/rL2VXuuBdx5fEoPO50mHN9Zd/2jxwg= Received: by 10.224.66.193 with SMTP id o1mr5831782qai.190.1258486362379; Tue, 17 Nov 2009 11:32:42 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 2sm276086qwi.2.2009.11.17.11.32.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 11:32:38 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Nov 2009 11:32:08 -0800 From: Pyun YongHyeon Date: Tue, 17 Nov 2009 11:32:08 -0800 To: Gonzalo Nemmi Message-ID: <20091117193208.GI1262@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911161534.34028.gnemmi@gmail.com> <20091116175450.GB1262@michelle.cdnetworks.com> <200911171650.06834.gnemmi@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <200911171650.06834.gnemmi@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-apci@freebsd.org, freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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, 17 Nov 2009 19:32:44 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 17, 2009 at 04:50:06PM -0200, Gonzalo Nemmi wrote: [...] > Well, I proceeded as I told you I would, applied your patch and even if > it didn't solve the problem (bge still doesn't resume) at least it > improved the previous situation given that now it doesn't loop timing > out once and again as before. > > You can find a tail from /var/log/messages in here: > http://pastebin.com/f643555f7 > > As you can see, the first 3 lines corresponds to "kldload if_bge" > Line number 4 is "acpiconf -s3" > > At line number 17 bge0 finally fails and let's the machine wake up at > line 18. > > Then, as soon as I could I issued a "ifconfig bge0" to see what I could > get .. that's what you can see from line 20 to line 41. (as you can see Ok, would you try this one? I guess bge(4) register access method could be in uninitialized state after resume. > in there, I found there are problems resuming umass devices as > well ... ) > Probably Hans can help you on USB issues. > Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the way, > once unloaded, I could load it again but bge0 never showed > on "ifconfig". > > Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ... which > ended with pulling the pendrive out as the system coldn't umount it ... > > I also found I get wpi0 messages on resume .. it spouts: > wpi0 could not lock memory > wpi0 could not lock memory > wpi0 could not lock memory > wpi0 could not lock memory > wpi0 could not lock memory > wpi0 could not lock memory > wpi0 could not lock memory > and then it let's the system resume. > Don't know what it really means. You'd be better to ask wpi(4) author Benjamin Close(benjsc@). > All in all .. there's _a_lot_of_problems_on_resume_ > > > Pyun, if you'd like me to try a new patch or to do some tests or > whatever, just let me know. I'm here awaiting orders :) > > Best Regards > Gonzalo Nemmi --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.5906.diff2" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 199411) +++ sys/dev/bge/if_bge.c (working copy) @@ -2995,6 +2995,15 @@ } } + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + val = CSR_READ_4(sc, BGE_VCPU_STATUS); + CSR_WRITE_4(sc, BGE_VCPU_STATUS, + val | BGE_VCPU_STATUS_DRV_RESET); + val = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); + CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, + val & ~BGE_VCPU_EXT_CTRL_HALT_CPU); + } + /* * Set GPHY Power Down Override to leave GPHY * powered up in D0 uninitialized. @@ -3005,15 +3014,6 @@ /* Issue global reset */ write_op(sc, BGE_MISC_CFG, reset); - if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { - val = CSR_READ_4(sc, BGE_VCPU_STATUS); - CSR_WRITE_4(sc, BGE_VCPU_STATUS, - val | BGE_VCPU_STATUS_DRV_RESET); - val = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); - CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, - val & ~BGE_VCPU_EXT_CTRL_HALT_CPU); - } - DELAY(1000); /* XXX: Broadcom Linux driver. */ @@ -4455,6 +4455,7 @@ sc = device_get_softc(dev); BGE_LOCK(sc); + bge_reset(sc); ifp = sc->bge_ifp; if (ifp->if_flags & IFF_UP) { bge_init_locked(sc); --XF85m9dhOBO43t/C-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 21:17:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53FA91065693; Tue, 17 Nov 2009 21:17:48 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id EBDF58FC18; Tue, 17 Nov 2009 21:17:47 +0000 (UTC) Received: by gxk10 with SMTP id 10so466227gxk.3 for ; Tue, 17 Nov 2009 13:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=DBoDvT4DEE7EpXS2ExN6Ef2TrCKeNw5PhunfwW2V3Rc=; b=rPabTv1XeTDiMnTTu8EARJDgUNihk+fjqMukAulLoHK8RjAEjIsy5yOiy2VOQOo65I DD2p3b18x6E9asQ3Wp7pI66Fz/7hvEM0lO81tlBGqfSNM7BJoO+DgkSHbDd3jcajTwkK AlMVJsXnXsBGE2u4DRdCBBRrLMG+gp/JOVNIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=C1WtCZTf5q5KmT26YMiPsAf9PFovUFj9uMaGwJDNL759Da7psY6Sj1yn0LBgbhws8Y gRxA+YkmUojg+JNigOZMaj2LbdLCEsGrdhSUx/z7F18gz5mFmV530nYsnQrSe2Di+kRN +5jUPPe2hxhJo5Zbs1xsciAPWS9smwdSLcNCo= Received: by 10.150.174.36 with SMTP id w36mr915995ybe.144.1258492665421; Tue, 17 Nov 2009 13:17:45 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 5sm68287ywd.8.2009.11.17.13.17.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 13:17:44 -0800 (PST) From: Gonzalo Nemmi To: pyunyh@gmail.com Date: Tue, 17 Nov 2009 19:17:41 -0200 User-Agent: KMail/1.9.10 References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911171650.06834.gnemmi@gmail.com> <20091117193208.GI1262@michelle.cdnetworks.com> In-Reply-To: <20091117193208.GI1262@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200911171917.41906.gnemmi@gmail.com> Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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, 17 Nov 2009 21:17:48 -0000 On Tuesday 17 November 2009 5:32:08 pm Pyun YongHyeon wrote: > On Tue, Nov 17, 2009 at 04:50:06PM -0200, Gonzalo Nemmi wrote: > > [...] > > > Well, I proceeded as I told you I would, applied your patch and > > even if it didn't solve the problem (bge still doesn't resume) at > > least it improved the previous situation given that now it doesn't > > loop timing out once and again as before. > > > > You can find a tail from /var/log/messages in here: > > http://pastebin.com/f643555f7 > > > > As you can see, the first 3 lines corresponds to "kldload if_bge" > > Line number 4 is "acpiconf -s3" > > > > At line number 17 bge0 finally fails and let's the machine wake up > > at line 18. > > > > Then, as soon as I could I issued a "ifconfig bge0" to see what I > > could get .. that's what you can see from line 20 to line 41. (as > > you can see > > Ok, would you try this one? I guess bge(4) register access method > could be in uninitialized state after resume. Just did .. same result .. you=B4ll find the messages here: http://pastebin.com/f38369b3c 1.- root login 2 to 9.- "kldload if_bge" 10.- "acpiconf -s3" 11 to 13.- wpi0 messages before suspending 14 to 23.- bge0 messages upon resume 24.- wakeup BTW: is there an easy way to unroll the patches so I get a pristine copy=20 back and apply the patch over it again? Im asking because the 3rd chunk=20 of your patch ( bge_reset(sc); ) didn't apply cleanly and I had to edit=20 if_bge.c by hand to add that line in the right place. Still willing to keep on trying and awaiting orders :) Best Regards Gonzalo Nemmi > > in there, I found there are problems resuming umass devices as > > well ... ) > > Probably Hans can help you on USB issues. > > > Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the > > way, once unloaded, I could load it again but bge0 never showed on > > "ifconfig". > > > > Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ... > > which ended with pulling the pendrive out as the system coldn't > > umount it ... > > > > I also found I get wpi0 messages on resume .. it spouts: > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > and then it let's the system resume. > > Don't know what it really means. You'd be better to ask wpi(4) > author Benjamin Close(benjsc@). > > > All in all .. there's _a_lot_of_problems_on_resume_ > > > > > > Pyun, if you'd like me to try a new patch or to do some tests or > > whatever, just let me know. I'm here awaiting orders :) > > > > Best Regards > > Gonzalo Nemmi =2D-=20 Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 20:56:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A166E1065780 for ; Tue, 17 Nov 2009 20:56:28 +0000 (UTC) (envelope-from ptr.neutral@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7E18FC1A for ; Tue, 17 Nov 2009 20:56:27 +0000 (UTC) Received: by fxm27 with SMTP id 27so462691fxm.3 for ; Tue, 17 Nov 2009 12:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=pxgWq2AXuvQ481gAMN3N6ZsGbQr6mVECWZYVqSAYPu8=; b=jYwVFv+vTsBNatoiQw7fLs15H5jnhbHWjlEqm8E76k22/IIONXH7ujLbwPFB8Kx333 anl+kOCFVAXa57drf/Aw3aQCaqRBGlS83eudLPKh0cJBHs8RCLw5G0O/zK7LhOS9ZlsD YjrnZRBvaTtBvNj/jGox7Re4CXvu7c88yeZP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wEhrKzlMMLWz6p2ANh3mI6ejtqH/A2/rtDSheExBp647N0H9NM/LErp/tewFHyKoS5 VJCTFUfH3UqTIwSZij/KJzqY0FrTm5N+h9cm3Bv9ne5uaEaYIzl/rtcHVC/z0sE7gpMB qnDahwzBbJ/pQSAJOauFYcJ21TGSrpKP5I1ac= MIME-Version: 1.0 Received: by 10.87.74.30 with SMTP id b30mr494083fgl.15.1258490072899; Tue, 17 Nov 2009 12:34:32 -0800 (PST) Date: Tue, 17 Nov 2009 21:34:32 +0100 Message-ID: <1c0233f80911171234i5b908678lef2327ab7c040c81@mail.gmail.com> From: neutral neutral To: freebsd-current@freebsd.org X-Mailman-Approved-At: Tue, 17 Nov 2009 21:18:02 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: High INTERRUPT rate on CPU 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 20:56:28 -0000 Hello, Yesterday I get a fresh install of FreeBSD 8.0 RC3 Current. However just some hours after the installation the machine began very slow/laggy. $ top -P CC (...) last pid: 1460; load averages: 0.01, 0.08, 0.07 up 0+00:11:00 08:28:59 100 processes: 1 running, 99 sleeping CPU 0: 0.0% user, 0.0% nice, 0.0% system, 81.9% interrupt, 18.1% idle CPU 1: 1.1% user, 0.0% nice, 3.2% system, 0.0% interrupt, 95.7% idle Mem: 160M Active, 141M Inact, 143M Wired, 1512K Cache, 112M Buf, 2525M Free Swap: 4096M Total, 4096M Free $ top -S last pid: 1457; load averages: 0.08, 0.13, 0.08 up 0+00:07:59 08:25:58 177 processes: 4 running, 157 sleeping, 16 waiting CPU: 0.8% user, 0.0% nice, 1.2% system, 37.8% interrupt, 60.2% idle Mem: 158M Active, 127M Inact, 149M Wired, 1484K Cache, 112M Buf, 2534M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 2 171 ki31 0K 16K RUN 0 8:38 112.16% idle 12 root 17 -64 - 0K 136K WAIT 0 5:39 77.29% intr 1405 hender 11 44 0 116M 86380K ucond 1 0:11 1.86% firefox-bin 1259 root 1 44 0 322M 316M select 1 0:10 0.00% Xorg 3 root 1 -8 - 0K 8K - 1 0:02 0.00% g_up 4 root 1 -8 - 0K 8K - 1 0:01 0.00% g_down 1440 hender 1 44 0 136M 14468K select 1 0:01 0.00% npviewer.bin 13 root 1 44 - 0K 8K - 1 0:01 0.00% yarrow 1432 hender 2 44 0 37584K 19268K piperd 1 0:01 0.00% gnome-terminal 1345 hender 1 44 0 19712K 14204K select 1 0:01 0.00% metacity 1348 hender 1 44 0 49048K 25112K select 1 0:01 0.00% nautilus 1390 root 1 48 4 3300K 1084K biord 1 0:01 0.00% fsck_ufs 1347 hender 1 44 0 34164K 20608K select 1 0:00 0.00% gnome-panel 1370 hender 1 44 0 33148K 18024K select 1 0:00 0.00% wnck-applet 1331 hender 1 44 0 8588K 5552K select 1 0:00 0.00% gconfd-2 1337 hender 2 44 0 94612K 15776K piperd 1 0:00 0.00% gnome-settings-daem 1201 haldaemon 1 44 0 7236K 4920K select 1 0:00 0.00% hald 1380 hender 1 44 0 32300K 22552K select 1 0:00 0.00% clock-applet 1342 hender 1 44 0 6308K 3236K select 1 0:00 0.00% gam_server 575 root 1 44 0 3448K 1136K select 1 0:00 0.00% moused 17 root 1 44 - 0K 8K syncer 1 0:00 0.00% syncer 1352 hender 1 44 0 26804K 18844K select 1 0:00 0.00% gnome-power-manager 19 root 1 44 - 0K 8K biord 1 0:00 0.00% softdepflush 1308 hender 2 52 0 21768K 11932K piperd 1 0:00 0.00% gnome-session 958 messagebus 1 44 0 3500K 2176K select 1 0:00 0.00% dbus-daemon 1350 hender 2 46 0 19240K 6896K select 1 0:00 0.00% bonobo-activation-s 1247 root 1 44 0 3804K 1700K ATA re 0 0:00 0.00% hald-addon-storage 14 root 32 -64 - 0K 256K - 0 0:00 0.00% usb 1381 hender 1 44 0 22044K 14568K select 1 0:00 0.00% notification-area-a 1354 hender 1 44 0 87032K 14120K select 1 0:00 0.00% gnome-volume-contro 0 root 9 -68 0 0K 64K - 1 0:00 0.00% kernel 1318 hender 1 44 0 3500K 2056K select 1 0:00 0.00% dbus-daemon 16 root 1 44 - 0K 8K psleep 1 0:00 0.00% bufdaemon 1328 hender 1 44 0 19320K 12456K select 1 0:00 0.00% seahorse-agent 1087 avahi 1 44 0 5092K 2536K select 1 0:00 0.00% avahi-daemon 1258 root 1 45 0 7588K 4312K select 1 0:00 0.00% gdm-simple-slave 1372 hender 2 44 0 7764K 4116K piperd 0 0:00 0.00% gvfs-hal-volume-mon 1368 hender 1 44 0 6688K 4000K select 1 0:00 0.00% gvfsd-trash 1204 root 17 44 0 14532K 4668K waitvt 1 0:00 0.00% console-kit-daemon 1205 root 1 44 0 5928K 2752K select 1 0:00 0.00% hald-runner 1297 root 1 44 0 7696K 3804K select 1 0:00 0.00% gdm-session-worker 1073 root 1 44 0 7504K 3688K select 1 0:00 0.00% gdm-binary 2 root 1 -8 - 0K 8K GEOM t 1 0:00 0.00% g_event 1333 hender 1 44 0 6468K 3268K select 1 0:00 0.00% gvfsd 1374 hender 1 44 0 7304K 3944K select 1 0:00 0.00% gvfs-gphoto2-volume 779 root 1 44 0 3344K 1312K select 1 $ systat -vmstat 2 users Load 0.15 0.22 0.10 Nov 17 18:16 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 182280 25972 743712 36292 2679304 count All 232564 40544 3238872 56908 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 93416 total 94 180k 197 1509 89k 205 19 12 zfod atkbd0 1 ozfod psm0 irq12 0.2%Sys 40.3%Intr 0.5%User 0.0%Nice 58.9%Idle %ozfod fwohci0+ 1 | | | | | | | | | | | daefr 89400 uhci2 ehci ++++++++++++++++++++> prcfr 20 uhci3 ehci 919 dtbuf 292 totfr 1998 cpu0: time Namei Name-cache Dir-cache 100000 desvn react mskc0 256 Calls hits % hits % 8091 numvn pdwak 1998 cpu1: time 1221 1221 100 1082 frevn pdpgs intrn Disks ad4 ad8 146440 wire KB/t 0.00 15.96 135892 act tps 0 141 79928 inact MB/s 0.00 2.21 1988 cache %busy 0 100 2677300 free 2 users Load 0.12 0.21 0.10 Nov 17 18:16 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 183688 25972 746272 36292 2680552 count All 233988 40544 3241432 56908 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 92797 total 94 179k 2877 4010 88k 202 2292 2291 zfod atkbd0 1 ozfod psm0 irq12 1.7%Sys 40.5%Intr 3.7%User 0.0%Nice 54.2%Idle %ozfod fwohci0+ 1 | | | | | | | | | | | daefr 88736 uhci2 ehci =++++++++++++++++++++>> prcfr 63 uhci3 ehci 72 dtbuf 3268 totfr 1999 cpu0: time Namei Name-cache Dir-cache 100000 desvn react mskc0 256 Calls hits % hits % 8091 numvn pdwak 1999 cpu1: time 793 793 100 1083 frevn pdpgs intrn Disks ad4 ad8 139872 wire KB/t 0.00 15.98 137304 act tps 0 142 83820 inact MB/s 0.00 2.22 1592 cache %busy 0 99 2678960 free $ vmstat -i interrupt total rate irq1: atkbd0 201 0 irq12: psm0 9 0 irq16: fwohci0+ 2 0 irq19: uhci2 ehci* 25229879 89151 irq23: uhci3 ehci1 4852 17 cpu0: timer 565386 1997 irq256: mskc0 389 1 cpu1: timer 562755 1988 Total 26363473 93157 $ $ dmesg | grep uhci2 uhci2: port 0x1840-0x185f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0010 usbus2: on uhci2 SB controller> port 0x1840-0x185f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0010 usbus2: on uhci2 From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 21:21:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72FDA10656AB for ; Tue, 17 Nov 2009 21:21:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id E6C458FC3A for ; Tue, 17 Nov 2009 21:21:52 +0000 (UTC) Received: by fxm27 with SMTP id 27so489876fxm.3 for ; Tue, 17 Nov 2009 13:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=jIDjeKcRGk0JKYrU6FNhIUyXV2JzMHlKq804BEYT7P4=; b=pA+U3+8INxtuLV/MsmkrCSv93puQ0uKFc6GUMcfoOh+lUyVOF1nveMkpqKhA75BBWm npedXLS9qSIjexqK9Ua1TzH53jcQKEKnD/Zi0R4EMMbVksDw4oz5gE7vBN3zPNqBZV+5 VezyB0hOCkB/Ry2XQRWghaHKfM64mFOoiVHtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=gWIeAv6aGywf7hW/pboVXgTuAY2EUucWHK6EKVQYNEWimMjiPInoc210c4QMP3Jers shLVSg06XJNZdBwVAfYlYyOHW45g3J7SPBSQfiJCQ5Vky+EcJuGjzFT3HROfKhLH5KON N6Bhdrf0/E+hwRHtW77Rgl6U2oRrQo9jetd0k= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.92.131 with SMTP id r3mr78518fam.40.1258492911523; Tue, 17 Nov 2009 13:21:51 -0800 (PST) In-Reply-To: <1c0233f80911171234i5b908678lef2327ab7c040c81@mail.gmail.com> References: <1c0233f80911171234i5b908678lef2327ab7c040c81@mail.gmail.com> Date: Tue, 17 Nov 2009 22:21:50 +0100 X-Google-Sender-Auth: 06999a893e2a40fb Message-ID: <3bbf2fe10911171321r6391e4fak5971bf8e8fa1ed58@mail.gmail.com> From: Attilio Rao To: neutral neutral Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: High INTERRUPT rate on CPU 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 21:21:53 -0000 2009/11/17 neutral neutral : > Hello, > > Yesterday I get a fresh install of FreeBSD 8.0 RC3 Current. However just > some hours after the installation the machine began very slow/laggy. > > $ top -P CC > (...) > last pid: 1460; load averages: 0.01, 0.08, > 0.07 up 0+00:11:00 08:28:59 > 100 processes: 1 running, 99 sleeping > CPU 0: 0.0% user, 0.0% nice, 0.0% system, 81.9% interrupt, 18.1% idle > CPU 1: 1.1% user, 0.0% nice, 3.2% system, 0.0% interrupt, 95.7% idle > Mem: 160M Active, 141M Inact, 143M Wired, 1512K Cache, 112M Buf, 2525M Free > Swap: 4096M Total, 4096M Free > > $ top -S > > last pid: 1457; load averages: 0.08, 0.13, > 0.08 up 0+00:07:59 08:25:58 > 177 processes: 4 running, 157 sleeping, 16 waiting > CPU: 0.8% user, 0.0% nice, 1.2% system, 37.8% interrupt, 60.2% idle > Mem: 158M Active, 127M Inact, 149M Wired, 1484K Cache, 112M Buf, 2534M Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 2 171 ki31 0K 16K RUN 0 8:38 112.16% idle > 12 root 17 -64 - 0K 136K WAIT 0 5:39 77.29% intr > 1405 hender 11 44 0 116M 86380K ucond 1 0:11 1.86% > firefox-bin > 1259 root 1 44 0 322M 316M select 1 0:10 0.00% Xorg > 3 root 1 -8 - 0K 8K - 1 0:02 0.00% g_up > 4 root 1 -8 - 0K 8K - 1 0:01 0.00% g_down > 1440 hender 1 44 0 136M 14468K select 1 0:01 0.00% > npviewer.bin > 13 root 1 44 - 0K 8K - 1 0:01 0.00% yarrow > 1432 hender 2 44 0 37584K 19268K piperd 1 0:01 0.00% > gnome-terminal > 1345 hender 1 44 0 19712K 14204K select 1 0:01 0.00% > metacity > 1348 hender 1 44 0 49048K 25112K select 1 0:01 0.00% > nautilus > 1390 root 1 48 4 3300K 1084K biord 1 0:01 0.00% > fsck_ufs > 1347 hender 1 44 0 34164K 20608K select 1 0:00 0.00% > gnome-panel > 1370 hender 1 44 0 33148K 18024K select 1 0:00 0.00% > wnck-applet > 1331 hender 1 44 0 8588K 5552K select 1 0:00 0.00% > gconfd-2 > 1337 hender 2 44 0 94612K 15776K piperd 1 0:00 0.00% > gnome-settings-daem > 1201 haldaemon 1 44 0 7236K 4920K select 1 0:00 0.00% hald > 1380 hender 1 44 0 32300K 22552K select 1 0:00 0.00% > clock-applet > 1342 hender 1 44 0 6308K 3236K select 1 0:00 0.00% > gam_server > 575 root 1 44 0 3448K 1136K select 1 0:00 0.00% moused > 17 root 1 44 - 0K 8K syncer 1 0:00 0.00% syncer > 1352 hender 1 44 0 26804K 18844K select 1 0:00 0.00% > gnome-power-manager > 19 root 1 44 - 0K 8K biord 1 0:00 0.00% > softdepflush > 1308 hender 2 52 0 21768K 11932K piperd 1 0:00 0.00% > gnome-session > 958 messagebus 1 44 0 3500K 2176K select 1 0:00 0.00% > dbus-daemon > 1350 hender 2 46 0 19240K 6896K select 1 0:00 0.00% > bonobo-activation-s > 1247 root 1 44 0 3804K 1700K ATA re 0 0:00 0.00% > hald-addon-storage > 14 root 32 -64 - 0K 256K - 0 0:00 0.00% usb > 1381 hender 1 44 0 22044K 14568K select 1 0:00 0.00% > notification-area-a > 1354 hender 1 44 0 87032K 14120K select 1 0:00 0.00% > gnome-volume-contro > 0 root 9 -68 0 0K 64K - 1 0:00 0.00% kernel > 1318 hender 1 44 0 3500K 2056K select 1 0:00 0.00% > dbus-daemon > 16 root 1 44 - 0K 8K psleep 1 0:00 0.00% > bufdaemon > 1328 hender 1 44 0 19320K 12456K select 1 0:00 0.00% > seahorse-agent > 1087 avahi 1 44 0 5092K 2536K select 1 0:00 0.00% > avahi-daemon > 1258 root 1 45 0 7588K 4312K select 1 0:00 0.00% > gdm-simple-slave > 1372 hender 2 44 0 7764K 4116K piperd 0 0:00 0.00% > gvfs-hal-volume-mon > 1368 hender 1 44 0 6688K 4000K select 1 0:00 0.00% > gvfsd-trash > 1204 root 17 44 0 14532K 4668K waitvt 1 0:00 0.00% > console-kit-daemon > 1205 root 1 44 0 5928K 2752K select 1 0:00 0.00% > hald-runner > 1297 root 1 44 0 7696K 3804K select 1 0:00 0.00% > gdm-session-worker > 1073 root 1 44 0 7504K 3688K select 1 0:00 0.00% > gdm-binary > 2 root 1 -8 - 0K 8K GEOM t 1 0:00 0.00% g_event > 1333 hender 1 44 0 6468K 3268K select 1 0:00 0.00% gvfsd > 1374 hender 1 44 0 7304K 3944K select 1 0:00 0.00% > gvfs-gphoto2-volume > 779 root 1 44 0 3344K 1312K select 1 > > $ systat -vmstat > > 2 users Load 0.15 0.22 0.10 Nov 17 18:16 > > Mem:KB REAL VIRTUAL VN PAGER SWAP > PAGER > Tot Share Tot Share Free in out in > out > Act 182280 25972 743712 36292 2679304 count > All 232564 40544 3238872 56908 pages > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt cow 93416 total > 94 180k 197 1509 89k 205 19 12 zfod atkbd0 > 1 > ozfod psm0 > irq12 > 0.2%Sys 40.3%Intr 0.5%User 0.0%Nice 58.9%Idle %ozfod > fwohci0+ 1 > | | | | | | | | | | | daefr 89400 uhci2 > ehci > ++++++++++++++++++++> prcfr 20 uhci3 > ehci > 919 dtbuf 292 totfr 1998 cpu0: > time > Namei Name-cache Dir-cache 100000 desvn react mskc0 > 256 > Calls hits % hits % 8091 numvn pdwak 1998 cpu1: > time > 1221 1221 100 1082 frevn pdpgs > intrn > Disks ad4 ad8 146440 wire > KB/t 0.00 15.96 135892 act > tps 0 141 79928 inact > MB/s 0.00 2.21 1988 cache > %busy 0 100 2677300 free > > 2 users Load 0.12 0.21 0.10 Nov 17 18:16 > > Mem:KB REAL VIRTUAL VN PAGER SWAP > PAGER > Tot Share Tot Share Free in out in > out > Act 183688 25972 746272 36292 2680552 count > All 233988 40544 3241432 56908 pages > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt cow 92797 total > 94 179k 2877 4010 88k 202 2292 2291 zfod atkbd0 > 1 > ozfod psm0 > irq12 > 1.7%Sys 40.5%Intr 3.7%User 0.0%Nice 54.2%Idle %ozfod > fwohci0+ 1 > | | | | | | | | | | | daefr 88736 uhci2 > ehci > =++++++++++++++++++++>> prcfr 63 uhci3 > ehci > 72 dtbuf 3268 totfr 1999 cpu0: > time > Namei Name-cache Dir-cache 100000 desvn react mskc0 > 256 > Calls hits % hits % 8091 numvn pdwak 1999 cpu1: > time > 793 793 100 1083 frevn pdpgs > intrn > Disks ad4 ad8 139872 wire > KB/t 0.00 15.98 137304 act > tps 0 142 83820 inact > MB/s 0.00 2.22 1592 cache > %busy 0 99 2678960 free > > $ vmstat -i > interrupt total rate > irq1: atkbd0 201 0 > irq12: psm0 9 0 > irq16: fwohci0+ 2 0 > irq19: uhci2 ehci* 25229879 89151 > irq23: uhci3 ehci1 4852 17 > cpu0: timer 565386 1997 > irq256: mskc0 389 1 > cpu1: timer 562755 1988 > Total 26363473 93157 > $ > That looks like an interrupt storm on IRQ19. I'm not sure if that is buggy hardware or just one of the usual USB necessary quirks Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 21:43:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FD051065767; Tue, 17 Nov 2009 21:43:51 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7945A8FC1A; Tue, 17 Nov 2009 21:43:50 +0000 (UTC) Received: from bolt.zol (62-121-98-25.home.aster.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 1885250; Tue, 17 Nov 2009 22:47:56 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> Date: Tue, 17 Nov 2009 22:43:46 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 21:43:51 -0000 On Mon, 16 Nov 2009 19:33:34 +0100, Emil Smolenski wrote: >> Matt's patch only effects raidz volumes. > Oh, I see. Maybe there is similar bug in ZFS on single disk volumes > also? >>> (is this procedure of updating zfsboot correct?) >> This should be correct for updating the first stage bootstrap code. The >> loader (boot/loader) is actually updated during installworld. > > I'll try full build/installworld tomorrow. It, unfortunately, didn't solve this issue. Should I file a PR? I would like to help in debugging it (however my skills in low-level C aren't strong enough to do it on my own). -- am From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:21:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FD9A106566C for ; Tue, 17 Nov 2009 22:21:27 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 0863E8FC08 for ; Tue, 17 Nov 2009 22:21:26 +0000 (UTC) Received: by ywh35 with SMTP id 35so515744ywh.7 for ; Tue, 17 Nov 2009 14:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=9zqTG+9zDiMYL0S6SL3uA7L+QqzSnrYaJ+s8RRMsz2o=; b=SYF2ozfsNnQD3BKhakdhzRBP1o+nsjTVCpYPYPwVOnFfidiZ2RBg194FlfIMJ34Jzf 5zm+HRpLHYHwcJPzsFv+qpS8X0BgfvXg9r07GTZhdQ6zUjeVrURsd8SBgqfLZed9eZuZ 5Vc3BZr+/YzxMci0bLOJbAGR7qFT1HSE0jhOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=fnAHv9o+vrnJ0lNc0nlRCm77j/nw8nXkTiS/n154QGx17pMs1Jh2CJDkfg5JZlPxYO SselR150dhbxD+7coBRKCJr/uic0AdWnU0Qs0KTS4zhiU+Bw2g9iDTDhfg+fSBOpXDfi EzakTMhqcut64wzpc0kQvUYoZC818m/gqaNoc= Received: by 10.150.44.21 with SMTP id r21mr1065400ybr.78.1258496480624; Tue, 17 Nov 2009 14:21:20 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 13sm942728gxk.5.2009.11.17.14.21.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 14:21:20 -0800 (PST) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Tue, 17 Nov 2009 20:21:16 -0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911172021.16848.gnemmi@gmail.com> Subject: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:21:27 -0000 I've been playing around with it (RC3, i386) and got it to look like this (/etc/make.conf): WITHOUT_MODULES= dev/firewire dev/bwi dev/bce dev/bfe dev/iwi dev/iwn zfs sound/driver/ad1816 sound/driver/ai2s sound/driver/als4000 sound/driver/atiixp sound/driver/audiocs sound/driver/cmi sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht sound/driver/es137x sound/driver/ess sound/driver/fm801 sound/driver/ich sound/driver/maestro3 sound/driver/mss sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 sound/driver/sbc sound/driver/solo sound/driver/spicds sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 sound/driver/via82c686 sound/driver/vibes Well .. I don't know what's wrong but no matter what, all of those modules and stuff still get built and end up under /boot/kernel ... I just need "sound" and "snd_hda"... What am I doing wrong? Any hint will help BTW: where is Bluetooth located so I can also get rid of it? -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:27:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D614106566C for ; Tue, 17 Nov 2009 22:27:21 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 93CC08FC17 for ; Tue, 17 Nov 2009 22:27:20 +0000 (UTC) Received: by ywh35 with SMTP id 35so519970ywh.7 for ; Tue, 17 Nov 2009 14:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=btLWEE14fE4s3hBw5ttL1DaYTP8vKkACzX1c6nnNPwc=; b=x1NGXH/7s/3LHAmbXL3IgwcqO5pqeUQxUNemBBFCcDJrEXz1GQCXcLFsCtw7peJ2+C 8LUAqP6dQbmAaT0D9rrXqmqeYSv5KJErY46BdOLsjekXHPOqRdJVFQ/Qm/FTaPTHJCO0 iJMS/xS10O+0jmIFWBp+Q2eRMdWKxH9uUyJWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=v7XoI9Ow1+oQa7eHqbn3cMaw5U5kfkHTbPeePY+GvLQ/9ZEIH0gUcN7hZQ25ZNE11A v7+o8M1L0amLlxCIxrEPimwu7d9O6L4S3DVhz9Z/Qd9ejOH/zYsoheO2DCcv1YKA7tC7 jnGB5xE4VPcipKmUe1OCP3sixy6YLJ0PnFP2o= Received: by 10.101.27.12 with SMTP id e12mr2462039anj.134.1258496839818; Tue, 17 Nov 2009 14:27:19 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 21sm199919yxe.37.2009.11.17.14.27.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 14:27:19 -0800 (PST) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Tue, 17 Nov 2009 20:27:15 -0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911172027.15749.gnemmi@gmail.com> Subject: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:27:21 -0000 I've set it up under /etc/src.conf but after make buildworlds and make check-old and make delete-old and so on .. /usr/bin/telnet still lurks in there ... Pretty scary =o Actually, and for the record, here's my almost complete src.conf: WITHOUT_AUTHPF=yes WITHOUT_BIND_DNSSEC=yes WITHOUT_BIND_MTREE=yes WITHOUT_BIND_NAMED=yes WITHOUT_BLUETOOTH=yes WITHOUT_CDDL=yes WITHOUT_DICT=yes WITHOUT_FLOOPY=yes WITHOUT_GAMES=yes WITHOUT_GSSAPI=yes WITHOUT_HTML=yes WITHOUT_INET6=yes WITHOUT_INFO=yes WITHOUT_IPFILTER=yes WITHOUT_IPFW=yes WITHOUT_IPX=yes WITHOUT_JAIL=yes WITHOUT_LOCALES=yes WITHOUT_LPR=yes WITHOUT_NDIS=yes WITHOUT_NIS=yes WITHOUT_RCMDS=yes WITHOUT_SHAREDOCS=yes WITHOUT_TELNET=yes And here is the output of make check-old after make installworld: >>> Checking for old files /usr/sbin/dnssec-keygen /usr/sbin/dnssec-signzone /var/named/etc/namedb/named.root /usr/bin/bthost /usr/bin/btsockstat /usr/bin/rfcomm_sppd /usr/include/netgraph/bluetooth/include/ng_bluetooth.h /usr/include/netgraph/bluetooth/include/ng_bt3c.h /usr/include/netgraph/bluetooth/include/ng_btsocket.h /usr/include/netgraph/bluetooth/include/ng_btsocket_hci_raw.h /usr/include/netgraph/bluetooth/include/ng_btsocket_l2cap.h /usr/include/netgraph/bluetooth/include/ng_btsocket_rfcomm.h /usr/include/netgraph/bluetooth/include/ng_h4.h /usr/include/netgraph/bluetooth/include/ng_hci.h /usr/include/netgraph/bluetooth/include/ng_l2cap.h /usr/include/netgraph/bluetooth/include/ng_ubt.h /usr/include/bluetooth.h /usr/include/sdp.h /usr/lib/libbluetooth.a /usr/lib/libbluetooth.so /usr/lib/libsdp.a /usr/lib/libsdp.so /usr/sbin/bcmfw /usr/sbin/bt3cfw /usr/sbin/hccontrol /usr/sbin/hcsecd /usr/sbin/hcseriald /usr/sbin/l2control /usr/sbin/l2ping /usr/sbin/rfcomm_pppd /usr/sbin/sdpcontrol /usr/sbin/sdpd /usr/share/man/man1/bthost.1.gz /usr/share/man/man1/btsockstat.1.gz /usr/share/man/man1/rfcomm_sppd.1.gz /usr/share/man/man3/bluetooth.3.gz /usr/share/man/man3/bt_gethostbyname.3.gz /usr/share/man/man3/bt_gethostbyaddr.3.gz /usr/share/man/man3/bt_gethostent.3.gz /usr/share/man/man3/bt_sethostent.3.gz /usr/share/man/man3/bt_endhostent.3.gz /usr/share/man/man3/bt_getprotobyname.3.gz /usr/share/man/man3/bt_getprotobynumber.3.gz /usr/share/man/man3/bt_getprotoent.3.gz /usr/share/man/man3/bt_setprotoent.3.gz /usr/share/man/man3/bt_endprotoent.3.gz /usr/share/man/man3/bt_ntoa.3.gz /usr/share/man/man3/bt_aton.3.gz /usr/share/man/man3/sdp.3.gz /usr/share/man/man3/SDP_GET8.3.gz /usr/share/man/man3/SDP_GET16.3.gz /usr/share/man/man3/SDP_GET32.3.gz /usr/share/man/man3/SDP_GET64.3.gz /usr/share/man/man3/SDP_GET128.3.gz /usr/share/man/man3/SDP_PUT8.3.gz /usr/share/man/man3/SDP_PUT16.3.gz /usr/share/man/man3/SDP_PUT32.3.gz /usr/share/man/man3/SDP_PUT64.3.gz /usr/share/man/man3/SDP_PUT128.3.gz /usr/share/man/man3/sdp_open.3.gz /usr/share/man/man3/sdp_open_local.3.gz /usr/share/man/man3/sdp_close.3.gz /usr/share/man/man3/sdp_error.3.gz /usr/share/man/man3/sdp_search.3.gz /usr/share/man/man3/sdp_attr2desc.3.gz /usr/share/man/man3/sdp_uuid2desc.3.gz /usr/share/man/man3/sdp_register_service.3.gz /usr/share/man/man3/sdp_unregister_service.3.gz /usr/share/man/man3/sdp_change_service.3.gz /usr/share/man/man5/hcsecd.conf.5.gz /usr/share/man/man8/bcmfw.8.gz /usr/share/man/man8/bt3cfw.8.gz /usr/share/man/man8/hcsecd.8.gz /usr/share/man/man8/hccontrol.8.gz /usr/share/man/man8/hcseriald.8.gz /usr/share/man/man8/l2control.8.gz /usr/share/man/man8/l2ping.8.gz /usr/share/man/man8/rfcomm_pppd.8.gz /usr/share/man/man8/sdpcontrol.8.gz /usr/share/man/man8/sdpd.8.gz /usr/lib/libavl.a /usr/lib/libavl.so /usr/lib/libnvpair.a /usr/lib/libnvpair.so /usr/lib/libumem.a /usr/lib/libumem.so /usr/lib/libuutil.a /usr/lib/libuutil.so /sbin/zfs /sbin/zpool /usr/lib/libzfs.a /usr/lib/libzfs.so /usr/lib/libzpool.a /usr/lib/libzpool.so /usr/bin/ztest /usr/sbin/zdb /usr/share/man/man8/zdb.8.gz /usr/share/man/man8/zfs.8.gz /usr/share/man/man8/zpool.8.gz /rescue/ping6 /sbin/ping6 /sbin/rtsol /usr/sbin/faithd /usr/sbin/ip6addrctl /usr/sbin/mld6query /usr/sbin/ndp /usr/sbin/rip6query /usr/sbin/route6d /usr/sbin/rrenumd /usr/sbin/rtadvd /usr/sbin/rtsold /usr/sbin/traceroute6 /usr/share/man/man5/rrenumd.conf.5.gz /usr/share/man/man5/rtadvd.conf.5.gz /usr/share/man/man8/ip6addrctl.8.gz /usr/share/man/man8/mld6query.8.gz /usr/share/man/man8/ndp.8.gz /usr/share/man/man8/ping6.8.gz /usr/share/man/man8/rip6query.8.gz /usr/share/man/man8/route6d.8.gz /usr/share/man/man8/rrenumd.8.gz /usr/share/man/man8/rtadvd.8.gz /usr/share/man/man8/rtsol.8.gz /usr/share/man/man8/rtsold.8.gz /usr/share/man/man8/traceroute6.8.gz /rescue/ipf /sbin/ipf /sbin/ipfs /sbin/ipfstat /sbin/ipftest /sbin/ipmon /sbin/ipnat /sbin/ippool /sbin/ipresend /usr/include/netinet/ip_auth.h /usr/include/netinet/ip_compat.h /usr/include/netinet/ip_fil.h /usr/include/netinet/ip_frag.h /usr/include/netinet/ip_htable.h /usr/include/netinet/ip_lookup.h /usr/include/netinet/ip_nat.h /usr/include/netinet/ip_pool.h /usr/include/netinet/ip_proxy.h /usr/include/netinet/ip_rules.h /usr/include/netinet/ip_scan.h /usr/include/netinet/ip_state.h /usr/include/netinet/ip_sync.h /usr/include/netinet/ipl.h /usr/share/examples/ipfilter/README /usr/share/examples/ipfilter/BASIC.NAT /usr/share/examples/ipfilter/BASIC_1.FW /usr/share/examples/ipfilter/BASIC_2.FW /usr/share/examples/ipfilter/example.1 /usr/share/examples/ipfilter/example.2 /usr/share/examples/ipfilter/example.3 /usr/share/examples/ipfilter/example.4 /usr/share/examples/ipfilter/example.5 /usr/share/examples/ipfilter/example.6 /usr/share/examples/ipfilter/example.7 /usr/share/examples/ipfilter/example.8 /usr/share/examples/ipfilter/example.9 /usr/share/examples/ipfilter/example.10 /usr/share/examples/ipfilter/example.11 /usr/share/examples/ipfilter/example.12 /usr/share/examples/ipfilter/example.13 /usr/share/examples/ipfilter/example.sr /usr/share/examples/ipfilter/firewall /usr/share/examples/ipfilter/ftp-proxy /usr/share/examples/ipfilter/ftppxy /usr/share/examples/ipfilter/nat-setup /usr/share/examples/ipfilter/nat.eg /usr/share/examples/ipfilter/server /usr/share/examples/ipfilter/tcpstate /usr/share/examples/ipfilter/example.14 /usr/share/examples/ipfilter/firewall.1 /usr/share/examples/ipfilter/firewall.2 /usr/share/examples/ipfilter/ipf.conf.permissive /usr/share/examples/ipfilter/ipf.conf.restrictive /usr/share/examples/ipfilter/ipf.conf.sample /usr/share/examples/ipfilter/ipnat.conf.sample /usr/share/examples/ipfilter/ipf-howto.txt /usr/share/examples/ipfilter/examples.txt /usr/share/examples/ipfilter/rules.txt /usr/share/man/man1/ipftest.1.gz /usr/share/man/man1/ipresend.1.gz /usr/share/man/man4/ipf.4.gz /usr/share/man/man4/ipl.4.gz /usr/share/man/man4/ipfilter.4.gz /usr/share/man/man4/ipnat.4.gz /usr/share/man/man5/ipf.5.gz /usr/share/man/man5/ipf.conf.5.gz /usr/share/man/man5/ipf6.conf.5.gz /usr/share/man/man5/ipnat.5.gz /usr/share/man/man5/ipnat.conf.5.gz /usr/share/man/man5/ippool.5.gz /usr/share/man/man8/ipf.8.gz /usr/share/man/man8/ipfs.8.gz /usr/share/man/man8/ipfstat.8.gz /usr/share/man/man8/ipmon.8.gz /usr/share/man/man8/ipnat.8.gz /usr/share/man/man8/ippool.8.gz /usr/lib/libipx.a /usr/lib/libipx.so /usr/sbin/IPXrouted /usr/share/man/man3/ipx.3.gz /usr/share/man/man3/ipx_addr.3.gz /usr/share/man/man3/ipx_ntoa.3.gz /usr/share/man/man8/IPXrouted.8.gz /usr/bin/lp /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/libexec/lpr/ru/bjc-240.sh.sample /usr/libexec/lpr/ru/koi2alt /usr/libexec/lpr/ru/koi2855 /usr/libexec/lpr/lpf /usr/sbin/chkprintcap /usr/sbin/lpc /usr/sbin/lpd /usr/sbin/lptest /usr/sbin/pac /usr/share/man/man1/lp.1.gz /usr/share/man/man1/lpq.1.gz /usr/share/man/man1/lpr.1.gz /usr/share/man/man1/lprm.1.gz /usr/share/man/man1/lptest.1.gz /usr/share/man/man5/printcap.5.gz /usr/share/man/man8/chkprintcap.8.gz /usr/share/man/man8/lpc.8.gz /usr/share/man/man8/lpd.8.gz /usr/share/man/man8/pac.8.gz /usr/bin/ncplist /usr/bin/ncplogin /usr/bin/ncplogout /usr/include/fs/nwfs/nwfs.h /usr/include/fs/nwfs/nwfs_mount.h /usr/include/fs/nwfs/nwfs_node.h /usr/include/fs/nwfs/nwfs_subr.h /usr/include/netncp/ncp.h /usr/include/netncp/ncp_cfg.h /usr/include/netncp/ncp_conn.h /usr/include/netncp/ncp_file.h /usr/include/netncp/ncp_lib.h /usr/include/netncp/ncp_ncp.h /usr/include/netncp/ncp_nls.h /usr/include/netncp/ncp_rcfile.h /usr/include/netncp/ncp_rq.h /usr/include/netncp/ncp_sock.h /usr/include/netncp/ncp_subr.h /usr/include/netncp/ncp_user.h /usr/include/netncp/ncpio.h /usr/include/netncp/nwerror.h /usr/lib/libncp.a /usr/lib/libncp.so /usr/sbin/mount_nwfs /usr/share/man/man1/ncplist.1.gz /usr/share/man/man1/ncplogin.1.gz /usr/share/man/man1/ncplogout.1.gz /usr/share/man/man8/mount_nwfs.8.gz /bin/rcp /rescue/rcp /usr/bin/rlogin /usr/bin/rsh /usr/libexec/rlogind /usr/libexec/rshd /usr/share/man/man1/rcp.1.gz /usr/share/man/man1/rlogin.1.gz /usr/share/man/man1/rsh.1.gz /usr/share/man/man8/rlogind.8.gz /usr/share/man/man8/rshd.8.gz >>> Checking for old libraries >>> Checking for old directories /var/named/etc/namedb/slave /var/named/etc/namedb/master /var/named/etc/namedb/dynamic /usr/include/netgraph/bluetooth/include /usr/include/netgraph/bluetooth To remove old files and directories run 'make delete-old'. To remove old libraries run 'make delete-old-libs'. -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:27:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FE291065789 for ; Tue, 17 Nov 2009 22:27:45 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 407B38FC17 for ; Tue, 17 Nov 2009 22:27:44 +0000 (UTC) Received: (qmail 19422 invoked from network); 17 Nov 2009 22:27:44 -0000 Received: from unknown (HELO ?10.0.0.135?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 17 Nov 2009 22:27:44 -0000 Message-ID: <4B032328.3050309@acm.poly.edu> Date: Tue, 17 Nov 2009 17:26:48 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20090910) MIME-Version: 1.0 To: Gonzalo Nemmi References: <200911172021.16848.gnemmi@gmail.com> In-Reply-To: <200911172021.16848.gnemmi@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:27:45 -0000 Gonzalo Nemmi wrote: > I've been playing around with it (RC3, i386) and got it to look like > this (/etc/make.conf): > > WITHOUT_MODULES= dev/firewire dev/bwi dev/bce dev/bfe dev/iwi dev/iwn > zfs sound/driver/ad1816 sound/driver/ai2s sound/driver/als4000 > sound/driver/atiixp sound/driver/audiocs sound/driver/cmi > sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa > sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 > sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht > sound/driver/es137x sound/driver/ess sound/driver/fm801 > sound/driver/ich sound/driver/maestro3 sound/driver/mss > sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 > sound/driver/sbc sound/driver/solo sound/driver/spicds > sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 > sound/driver/via82c686 sound/driver/vibes > > Well .. I don't know what's wrong but no matter what, all of those > modules and stuff still get built and end up under /boot/kernel ... I > just need "sound" and "snd_hda"... > > What am I doing wrong? > Any hint will help > > BTW: where is Bluetooth located so I can also get rid of it? > While the documentation does seem to indicate that what you're doing should work, I think you'd have an easier time just doing this: MODULES_OVERRIDE=sound sound/driver/hda -Boris From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:29:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9E8E1065693 for ; Tue, 17 Nov 2009 22:29:30 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id AAEB58FC19 for ; Tue, 17 Nov 2009 22:29:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 5192B7CA57; Wed, 18 Nov 2009 11:29:29 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6-7fXA9Lpb8; Wed, 18 Nov 2009 11:29:24 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 18 Nov 2009 11:29:24 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 18AC911475; Wed, 18 Nov 2009 11:29:24 +1300 (NZDT) Date: Wed, 18 Nov 2009 11:29:23 +1300 From: Andrew Thompson To: Gonzalo Nemmi Message-ID: <20091117222923.GA63610@citylink.fud.org.nz> References: <200911172021.16848.gnemmi@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911172021.16848.gnemmi@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:29:31 -0000 On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: > I've been playing around with it (RC3, i386) and got it to look like > this (/etc/make.conf): > > WITHOUT_MODULES= dev/firewire dev/bwi dev/bce dev/bfe dev/iwi dev/iwn > zfs sound/driver/ad1816 sound/driver/ai2s sound/driver/als4000 > sound/driver/atiixp sound/driver/audiocs sound/driver/cmi > sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa > sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 > sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht > sound/driver/es137x sound/driver/ess sound/driver/fm801 > sound/driver/ich sound/driver/maestro3 sound/driver/mss > sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 > sound/driver/sbc sound/driver/solo sound/driver/spicds > sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 > sound/driver/via82c686 sound/driver/vibes > > Well .. I don't know what's wrong but no matter what, all of those > modules and stuff still get built and end up under /boot/kernel ... I > just need "sound" and "snd_hda"... > > What am I doing wrong? > Any hint will help I think you are looking for MODULES_OVERRIDE and it can go in your kernel config file or /etc/make.conf # MODULES_OVERRIDE can be used to limit modules built to a specific list makeoptions MODULES_OVERRIDE="sound/sound sound/driver/hda" Andrew From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:30:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C6DE1065693 for ; Tue, 17 Nov 2009 22:30:40 +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 109A58FC1F for ; Tue, 17 Nov 2009 22:30:39 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B70C27E99D; Tue, 17 Nov 2009 22:30:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id nAHMUfAj072515; Tue, 17 Nov 2009 22:30:41 GMT (envelope-from phk@critter.freebsd.dk) To: Gonzalo Nemmi From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Nov 2009 20:27:15 -0200." <200911172027.15749.gnemmi@gmail.com> Date: Tue, 17 Nov 2009 22:30:41 +0000 Message-ID: <72514.1258497041@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:30:40 -0000 Check out the scripts in src/tools/tools/build_option_survey/ The result looked like this on stable-7 some time ago: http://phk.freebsd.dk/misc/stable7_build_options/ -- 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 Tue Nov 17 22:33:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049C9106566B; Tue, 17 Nov 2009 22:33:51 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C10568FC0C; Tue, 17 Nov 2009 22:33:50 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAHMXlVa012182 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 17:33:48 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Tue, 17 Nov 2009 16:33:41 -0600 Message-Id: <1258497221.2303.66.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2009 22:33:51 -0000 On Tue, 2009-11-17 at 22:43 +0100, Emil Smolenski wrote: > On Mon, 16 Nov 2009 19:33:34 +0100, Emil Smolenski > wrote: > > >> Matt's patch only effects raidz volumes. > > Oh, I see. Maybe there is similar bug in ZFS on single disk volumes > > also? > > >>> (is this procedure of updating zfsboot correct?) > >> This should be correct for updating the first stage bootstrap code. The > >> loader (boot/loader) is actually updated during installworld. > > > > I'll try full build/installworld tomorrow. > > It, unfortunately, didn't solve this issue. Should I file a PR? I would > like to help in debugging it (however my skills in low-level C aren't > strong enough to do it on my own). Ok, the first thing I would like to see is "zdb -uuu". I don't see an obvious issue with single disk reads. My own setup uses 2 x 1TB currently. Failing to read the MOS is basically the first read attempt from the pool, in fact it is the read that attempts to mount the pool. robert. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:41:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3298106566C for ; Tue, 17 Nov 2009 22:41:00 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 898CC8FC08 for ; Tue, 17 Nov 2009 22:41:00 +0000 (UTC) Received: by ywh35 with SMTP id 35so530297ywh.7 for ; Tue, 17 Nov 2009 14:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=n9MQmAe5I/5BSIhT9qjd4y4FBrxxMHUsbQNGy1VfDX8=; b=ZW5nt7ZYOo94PQHEShxh4dY2CgALgV3KOFEYsRph3NLILBWorP9dKXEzlK/1dHB4p/ ecz0DjuVD8bGHd0N4pRQO9ZKiLIUfhbWBQl9M+rt4auWRCAyx4p58y2SC9Nx2kNjMApl E/bbHEpuhAWFPO6NRyrhMvMz7Rav4/wP3ogGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=PFbVAhZT0IAmdYOIMlsDfRG1S1aM8zdxPIWJChJy9s/PtzaeNmNCxv6O3X9KlDiSKB fJOASCWkxn0Myx1+KXnaxVD38MBtDU70WPJqh6p6PRxontH5M/Kj4oTodJkXVP620/WG oJTK4FYVJppss1PgplsPwcHOrk7cpt9GNKQL8= Received: by 10.101.167.27 with SMTP id u27mr2509061ano.199.1258497659006; Tue, 17 Nov 2009 14:40:59 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 9sm518959yxf.41.2009.11.17.14.40.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 14:40:58 -0800 (PST) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Tue, 17 Nov 2009 20:40:55 -0200 User-Agent: KMail/1.9.10 References: <200911172021.16848.gnemmi@gmail.com> <4B032328.3050309@acm.poly.edu> In-Reply-To: <4B032328.3050309@acm.poly.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911172040.55421.gnemmi@gmail.com> Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:41:00 -0000 On Tuesday 17 November 2009 8:26:48 pm Boris Kochergin wrote: > Gonzalo Nemmi wrote: > > I've been playing around with it (RC3, i386) and got it to look > > like this (/etc/make.conf): > > > > WITHOUT_MODULES= dev/firewire dev/bwi dev/bce dev/bfe dev/iwi > > dev/iwn zfs sound/driver/ad1816 sound/driver/ai2s > > sound/driver/als4000 sound/driver/atiixp sound/driver/audiocs > > sound/driver/cmi > > sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa > > sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 > > sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht > > sound/driver/es137x sound/driver/ess sound/driver/fm801 > > sound/driver/ich sound/driver/maestro3 sound/driver/mss > > sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 > > sound/driver/sbc sound/driver/solo sound/driver/spicds > > sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 > > sound/driver/via82c686 sound/driver/vibes > > > > Well .. I don't know what's wrong but no matter what, all of those > > modules and stuff still get built and end up under /boot/kernel ... > > I just need "sound" and "snd_hda"... > > > > What am I doing wrong? > > Any hint will help > > > > BTW: where is Bluetooth located so I can also get rid of it? > > While the documentation does seem to indicate that what you're doing > should work, I think you'd have an easier time just doing this: > > MODULES_OVERRIDE=sound sound/driver/hda > > -Boris Hi Boris ! I did that, but the result was that the only moules that got built were those two! wc -l /boot/kernel yielded: 2 ! There was no more modules than those that I had expressly specified in MODULES_OVERRIDE .. that's why I resorted to WITHOUT_MODULES (as awkward as it may be ..). Thanks for your reply Boris ! -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:43:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9E0C106568F for ; Tue, 17 Nov 2009 22:43:34 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 60E178FC17 for ; Tue, 17 Nov 2009 22:43:34 +0000 (UTC) Received: by ywh35 with SMTP id 35so532121ywh.7 for ; Tue, 17 Nov 2009 14:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=Z1PuxG/Oxbut99yW1BC4nlceh4007ZX3x0OcmjwzXYI=; b=bJVfLzer1yNoqSNTblaVV3h5y8E10dtEHXUVL8ZlC1fcCZkSUyvHdxruDIh4OwMNNt T6s0KgVYR5miY0+2E56glQ4PXp5XoHxJ/ViTlpkHp+FcdV4CpnvHwRbLphSWvV/3DqOK GrgCS5ZbXbIUNQgzJceQKD59mqlitoHUViUHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=R0XYJnJeM40qPFEcbHyHH04OnYVCYcarHbVwQPUptjSXoOheL/sh4JRffXsT+Kp9PV NMKxyW0ldz6np9TLie5Uww4GJSRK2WXeANHW/bG/tu4pxlLBDlcJQ6n0WosuO4pLDSue /lY4TLoUY94k/SRchSf5fazRgn9znNgBiRn9A= Received: by 10.91.159.22 with SMTP id l22mr892723ago.9.1258497811715; Tue, 17 Nov 2009 14:43:31 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 23sm552219yxe.0.2009.11.17.14.43.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 14:43:30 -0800 (PST) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Tue, 17 Nov 2009 20:43:27 -0200 User-Agent: KMail/1.9.10 References: <72514.1258497041@critter.freebsd.dk> In-Reply-To: <72514.1258497041@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911172043.28008.gnemmi@gmail.com> Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:43:34 -0000 On Tuesday 17 November 2009 8:30:41 pm Poul-Henning Kamp wrote: > Check out the scripts in src/tools/tools/build_option_survey/ > > The result looked like this on stable-7 some time ago: > > http://phk.freebsd.dk/misc/stable7_build_options/ no effect .. Interesting ... Thanks for the link Mr. Poul-Henning Kamp Best Regards Gonzalo Nemmi -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 22:46:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14B431065698 for ; Tue, 17 Nov 2009 22:46:44 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id BE9E08FC1A for ; Tue, 17 Nov 2009 22:46:42 +0000 (UTC) Received: by gxk10 with SMTP id 10so542909gxk.3 for ; Tue, 17 Nov 2009 14:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=fn9RHZxv+A1AIOsVDFSorRjvifqE0Ji4m4RErw0Bo/4=; b=MHPIAvUqzc4ngf2l5vSHCb6nNA00V5yLBERAo4ZxQPjm6KsVQc+8zIleQPhEiVI50B VAppcDqX/C03FhqYTGqVUb4mdnKvjugOP6XvKAs86cKTNlx2M9LMHnO3MbFbudWNquVZ K6mvuGAVrKrurKWPckGzv6/rPejbBOWDb5UP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=kI67XGSX404IZEM82HakQam6d/sPEp7n+/ptBPMTRvMsDcQrFIkXKWuVv62ck62Eix yiP4+zMrftNQf9BI/59rtxh5y1C3ttiDHAC0hB1t6PygKV92BbxfeF4mUquCr8WQ2jNy WCB6mJZAmKTCxwiVbESxBbwSqdbtHbAhaIsHo= Received: by 10.90.9.1 with SMTP id 1mr899712agi.3.1258498001842; Tue, 17 Nov 2009 14:46:41 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 6sm141989yxg.12.2009.11.17.14.46.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 14:46:41 -0800 (PST) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Tue, 17 Nov 2009 20:46:38 -0200 User-Agent: KMail/1.9.10 References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> In-Reply-To: <20091117222923.GA63610@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911172046.38561.gnemmi@gmail.com> Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:46:44 -0000 On Tuesday 17 November 2009 8:29:23 pm Andrew Thompson wrote: > On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: > > I've been playing around with it (RC3, i386) and got it to look > > like this (/etc/make.conf): > > > > WITHOUT_MODULES= dev/firewire dev/bwi dev/bce dev/bfe dev/iwi > > dev/iwn zfs sound/driver/ad1816 sound/driver/ai2s > > sound/driver/als4000 sound/driver/atiixp sound/driver/audiocs > > sound/driver/cmi > > sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa > > sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 > > sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht > > sound/driver/es137x sound/driver/ess sound/driver/fm801 > > sound/driver/ich sound/driver/maestro3 sound/driver/mss > > sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 > > sound/driver/sbc sound/driver/solo sound/driver/spicds > > sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 > > sound/driver/via82c686 sound/driver/vibes > > > > Well .. I don't know what's wrong but no matter what, all of those > > modules and stuff still get built and end up under /boot/kernel ... > > I just need "sound" and "snd_hda"... > > > > What am I doing wrong? > > Any hint will help > > I think you are looking for MODULES_OVERRIDE and it can go in your > kernel config file or /etc/make.conf > > # MODULES_OVERRIDE can be used to limit modules built to a specific > list makeoptions MODULES_OVERRIDE="sound/sound sound/driver/hda" > > > Andrew Hi Andrew! Well, as I already told Boris, I did try that but it didn't work out quite as expected ... leaving me with only two modules :s There was no if_ modules, no wlan_, no zlib, no nothing .. except sound and snd_hda ... :s -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 23:19:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9345F106566C for ; Tue, 17 Nov 2009 23:19:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outj.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6AE8FC08 for ; Tue, 17 Nov 2009 23:19:05 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id F02A114DDD2; Tue, 17 Nov 2009 15:19:04 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id AD0362D6018; Tue, 17 Nov 2009 15:19:04 -0800 (PST) Message-ID: <4B032F68.30106@elischer.org> Date: Tue, 17 Nov 2009 15:19:04 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Gonzalo Nemmi References: <200911172021.16848.gnemmi@gmail.com> In-Reply-To: <200911172021.16848.gnemmi@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:19:05 -0000 Gonzalo Nemmi wrote: > I've been playing around with it (RC3, i386) and got it to look like > this (/etc/make.conf): > > WITHOUT_MODULES= dev/firewire dev/bwi dev/bce dev/bfe dev/iwi dev/iwn > zfs sound/driver/ad1816 sound/driver/ai2s sound/driver/als4000 > sound/driver/atiixp sound/driver/audiocs sound/driver/cmi > sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa > sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 > sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht > sound/driver/es137x sound/driver/ess sound/driver/fm801 > sound/driver/ich sound/driver/maestro3 sound/driver/mss > sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 > sound/driver/sbc sound/driver/solo sound/driver/spicds > sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 > sound/driver/via82c686 sound/driver/vibes > > Well .. I don't know what's wrong but no matter what, all of those > modules and stuff still get built and end up under /boot/kernel ... I > just need "sound" and "snd_hda"... > > What am I doing wrong? > Any hint will help > > BTW: where is Bluetooth located so I can also get rid of it? I just define what I DO want with MODULES_OVERRIDE From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 23:22:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2FFA1065670 for ; Tue, 17 Nov 2009 23:22:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8BD9C8FC17 for ; Tue, 17 Nov 2009 23:22:27 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 5732014E070; Tue, 17 Nov 2009 15:22:27 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 1EAD32D6023; Tue, 17 Nov 2009 15:22:27 -0800 (PST) Message-ID: <4B033032.5050301@elischer.org> Date: Tue, 17 Nov 2009 15:22:26 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Gonzalo Nemmi References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> In-Reply-To: <200911172046.38561.gnemmi@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:22:27 -0000 Gonzalo Nemmi wrote: > On Tuesday 17 November 2009 8:29:23 pm Andrew Thompson wrote: >> On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: >>> I just need "sound" and "snd_hda"... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> > Hi Andrew! > Well, as I already told Boris, I did try that but it didn't work out > quite as expected ... leaving me with only two modules :s > There was no if_ modules, no wlan_, no zlib, no nothing .. except sound > and snd_hda ... :s well that's what you SAID you wanted... From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 23:25:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11743106566B for ; Tue, 17 Nov 2009 23:25:55 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC2118FC1E for ; Tue, 17 Nov 2009 23:25:54 +0000 (UTC) Received: by pxi12 with SMTP id 12so348931pxi.3 for ; Tue, 17 Nov 2009 15:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bcPQ/zgmdvSH2vo4aR2xaSqB/BYJkoiB5OMjmgXWPlk=; b=k1m6R01jPYVaad50w68xrwm+Qbj6CoZs6bE3u0WbfnRBliPCyP7/R6TJHjCNiyeIPW UnOGHEj46zRldBcYA3qqKcGHzClaqwCqvjG7qSAYbxW022OEH0AqYmGjHcUin0Dj4hVg h+30wp0GWChaQHdXG20tXj4RMfXq5S/xBcVgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=EJHl+1gr6KJvL3u0BTsPfBCIT4Ya+rlSua5C4/JWGC10syGI2J+xNG+hzym5eUhjNd V/aBW+Ut3OQp5k+ug04ovBdtN8etsgYHOQW4/eQuMOgpajtaKV3t13EXXMH0xNKF2QV2 wEuD+OQ10Z0xSLuvWF1gCYA5vToavbMGrGHKo= MIME-Version: 1.0 Received: by 10.142.121.3 with SMTP id t3mr1027259wfc.246.1258500354412; Tue, 17 Nov 2009 15:25:54 -0800 (PST) In-Reply-To: <4B033032.5050301@elischer.org> References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> Date: Tue, 17 Nov 2009 15:25:54 -0800 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:25:55 -0000 On Tue, Nov 17, 2009 at 3:22 PM, Julian Elischer wrot= e: > Gonzalo Nemmi wrote: >> >> On Tuesday 17 November 2009 8:29:23 pm Andrew Thompson wrote: >>> >>> On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: > >>>> I just need "sound" and "snd_hda"... > > =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> > >> Hi Andrew! >> Well, as I already told Boris, I did try that but it didn't work out qui= te >> as expected ... leaving me with only two modules :s >> There was no if_ modules, no wlan_, no zlib, no nothing .. except sound >> and snd_hda ... :s > > > well that's what you SAID you wanted... That might be what he said, but if you look at the list of modules, what he actually meant was "the only sound-related modules I want are sound and snd_hda". :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 23:48:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EA541065693 for ; Tue, 17 Nov 2009 23:48:02 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id C19278FC1E for ; Tue, 17 Nov 2009 23:48:01 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nAHNEKUG047879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Nov 2009 23:14:20 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <200911172021.16848.gnemmi@gmail.com> Date: Tue, 17 Nov 2009 18:14:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> References: <200911172021.16848.gnemmi@gmail.com> To: Gonzalo Nemmi X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:48:02 -0000 On Nov 17, 2009, at 5:21 PM, Gonzalo Nemmi wrote: > I've been playing around with it (RC3, i386) and got it to look like=20= > this (/etc/make.conf): >=20 > WITHOUT_MODULES=3D dev/firewire dev/bwi dev/bce dev/bfe dev/iwi = dev/iwn=20 > zfs sound/driver/ad1816 sound/driver/ai2s sound/driver/als4000=20 > sound/driver/atiixp sound/driver/audiocs sound/driver/cmi=20 > sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa=20 > sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1=20 > sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht=20 > sound/driver/es137x sound/driver/ess sound/driver/fm801=20 > sound/driver/ich sound/driver/maestro3 sound/driver/mss=20 > sound/driver/neomagic sound/driver/sb16 sound/driver/sb8=20 > sound/driver/sbc sound/driver/solo sound/driver/spicds=20 > sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233=20 > sound/driver/via82c686 sound/driver/vibes >=20 > Well .. I don't know what's wrong but no matter what, all of those=20 > modules and stuff still get built and end up under /boot/kernel ... I=20= > just need "sound" and "snd_hda"... >=20 > What am I doing wrong? > Any hint will help I think the contents of WITHOUT_MODULES should be the short names of the = directories in /usrc/src/sys/modules. So iwn instead of dev/iwn. Also, = it looks like you can only exclude modules at this top level directory = granularity. So you can exclude sound, but not a particular device = under sound. Anyway, thats based on a quick read of the Makefile. I could be wrong, = though. I've never actually used this feature. Hope that helps. - Ben= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:05:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2330E1065672 for ; Wed, 18 Nov 2009 00:05:44 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A54FD8FC13 for ; Wed, 18 Nov 2009 00:05:43 +0000 (UTC) Received: by fxm27 with SMTP id 27so650391fxm.3 for ; Tue, 17 Nov 2009 16:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Dw6NBmb3o4+C5U4YkULu+VO8X8NJd7MzrKv5tBLWjVs=; b=iw66kiawtQItkcGGbvzbaMOjjUKq9/KL2pn3zQRl7ptViG9QJybgdymgSzyNVZH3mN ExkVEcJEFM0RGFLI0omwt5uGDMQU5B5CvdvVRm7gDoNZe0qUjnObiUuWz6fPo1tPIgse viXQ7AwUxR57nZ8AxBQs8LZlbLmd8TitAIg20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ByVzd7nPHavn+9IExv2BfqyF+GXrnFu83cyb/gYZGJwdDHcC6+u157tWDw+WnW8kbg EttswaJ/K5JZwsbJ0ZSSGivU45fvS77Uzn1/h69QZzaQUHfI3k4OeIbm1EKxdGRDJQpP a5MMGxOQ+SaOpSieIvru4fxAv9YitRl7Sj8Ys= MIME-Version: 1.0 Received: by 10.103.50.22 with SMTP id c22mr241118muk.54.1258502742489; Tue, 17 Nov 2009 16:05:42 -0800 (PST) In-Reply-To: <4B033032.5050301@elischer.org> References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> Date: Tue, 17 Nov 2009 21:05:42 -0300 Message-ID: <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:05:44 -0000 On Tue, Nov 17, 2009 at 8:22 PM, Julian Elischer wrote: > Gonzalo Nemmi wrote: > >> On Tuesday 17 November 2009 8:29:23 pm Andrew Thompson wrote: >> >>> On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: >>> >> > I just need "sound" and "snd_hda"... >>>> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >>>> > Hi Andrew! >> Well, as I already told Boris, I did try that but it didn't work out quite >> as expected ... leaving me with only two modules :s >> There was no if_ modules, no wlan_, no zlib, no nothing .. except sound >> and snd_hda ... :s >> > > > well that's what you SAID you wanted... > > Oh, sorry ... I should've made it clear that that was what I needed "only" in regards to sound ... I guess I forgot there's people in the list that doesn't have clue, not only about FreeBSD and Unix system administration but also about irony ... See Julian.. as the saying goes, if you want to help a hungry men, don't give him fish .. teach him how to fish .. so in that order of things let's do this, try and do what you are, ironically, advising me to do and tell me how it goes ... how the system works with only those 2 modules. Otherwise, if you have nothing important or relelevant to say, please try to keep it shut ... and please, try _really_hard_, cause you are making me loose my time as well as other's people time. Boris and Andrew were trying to help ... if you are not up to the task, please, take a step aside and do yourself a favor. From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:07:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 046951065695 for ; Wed, 18 Nov 2009 00:07:32 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 890B28FC24 for ; Wed, 18 Nov 2009 00:07:31 +0000 (UTC) Received: by bwz5 with SMTP id 5so728206bwz.3 for ; Tue, 17 Nov 2009 16:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=cXWS+/aZwzS+ox2nqcrLa5fZo5cEUBW44pORkC+dyek=; b=sGLaekfwCW8bVahETL1D3Sf37s+uEJEtLtA0D7CYAMrwVkf6cUe2W/Xknd5ehQLw1h 2FNNMA2rZzyLoshvzuvFjDNPvQQbfDCXY2NK4l/7KxZ+aF56ngm1AxqJ4Kd8nSTDzzzk bsHebm5+DkC76CGREkDzAjChcwL3nXKzZYe90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rIkwyixQ21y+25zE9W36S/kdWaYdcfqSpy1rdvjcRUU2X4zSNy+wqb9YDtHOx/KRU6 XgqgEKXo3o0mMYzmznQCcX0EAvj6hBt/Hq/oyhyZtdLImK96IYV3Lwvl03bF89UasW/v Bevct1ccCjx2Q10efmHV4ChLGXVMBZoGyF8a8= MIME-Version: 1.0 Received: by 10.103.87.26 with SMTP id p26mr32031mul.44.1258502850581; Tue, 17 Nov 2009 16:07:30 -0800 (PST) In-Reply-To: References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> Date: Tue, 17 Nov 2009 21:07:30 -0300 Message-ID: <19e9a5dc0911171607q7265942dv911dfa7dad660c52@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:07:32 -0000 On Tue, Nov 17, 2009 at 8:25 PM, Freddie Cash wrote: > On Tue, Nov 17, 2009 at 3:22 PM, Julian Elischer > wrote: > > Gonzalo Nemmi wrote: > >> > >> On Tuesday 17 November 2009 8:29:23 pm Andrew Thompson wrote: > >>> > >>> On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: > > > >>>> I just need "sound" and "snd_hda"... > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>> > > > >> Hi Andrew! > >> Well, as I already told Boris, I did try that but it didn't work out > quite > >> as expected ... leaving me with only two modules :s > >> There was no if_ modules, no wlan_, no zlib, no nothing .. except sound > >> and snd_hda ... :s > > > > > > well that's what you SAID you wanted... > > That might be what he said, but if you look at the list of modules, > what he actually meant was "the only sound-related modules I want are > sound and snd_hda". :) > Thanks for halping me explain Julian how a message should be read. Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:08:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3728C106566B for ; Wed, 18 Nov 2009 00:08:40 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 03C028FC26 for ; Wed, 18 Nov 2009 00:08:39 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id nAI08c9j007559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 16:08:39 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 60CBC1CC47; Tue, 17 Nov 2009 16:08:38 -0800 (PST) To: Gonzalo Nemmi In-reply-to: Your message of "Tue, 17 Nov 2009 20:43:27 -0200." <200911172043.28008.gnemmi@gmail.com> Date: Tue, 17 Nov 2009 16:08:38 -0800 From: "Kevin Oberman" Message-Id: <20091118000838.60CBC1CC47@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-17_11:2009-11-16, 2009-11-17, 2009-11-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911170230 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:08:40 -0000 > From: Gonzalo Nemmi > Date: Tue, 17 Nov 2009 20:43:27 -0200 > Sender: owner-freebsd-current@freebsd.org > > On Tuesday 17 November 2009 8:30:41 pm Poul-Henning Kamp wrote: > > Check out the scripts in src/tools/tools/build_option_survey/ > > > > The result looked like this on stable-7 some time ago: > > > > http://phk.freebsd.dk/misc/stable7_build_options/ > > > no effect .. > Interesting ... > Thanks for the link Mr. Poul-Henning Kamp I can state that several of the src.conf options in 8.0 don't work and some will break the build. There is an open PR that has a fix to Makefile.inc1 for at least some of the problems. That said, building a new world without telnet does not delete the existing binaries, libs, header files, etc. It just causes them not to be built again. Further, delete-old will not delete them. If you build with some parts of the base system removed in this manner, you really need to go in and remove the old stuff by hand. It won't be created arain. N.B. I have not tried WITHOUT_TELNET=, so I can't swear that ti works. I build WITHOUT_OPENSSH and WITHOUT_BIND as I use the ports with OVERWRITE_BASE. and WITHOUT_BIND works fine. WITHOUT_OPENSSH requires the patches mentions above for Makefile.inc1 (thanks to bf for those). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:14:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366DB1065696 for ; Wed, 18 Nov 2009 00:14:06 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id AFB228FC16 for ; Wed, 18 Nov 2009 00:14:05 +0000 (UTC) Received: by bwz5 with SMTP id 5so733015bwz.3 for ; Tue, 17 Nov 2009 16:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=JvCvH6OjxFPqTLO9Q9sYjld5xY+V8TDhECkXKqIdPCY=; b=Ak1RotoW6oM0xu9Ln50l6rzWq/eIKmDCZTu/P7moZ21uTPz9EXPj3IxV2Q7H0EHEXN fXvIcWtee0v5+0hOMTPAMWaOFxh2QxgSV1Vgu/hB58TGEEwT1oQRo/ZDsxq3xn6RZ5sQ OuZlT5U2UBhgDFsFzEB3dGgi+0bffKh1zZahA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wIjLctAUreiDjw0RSyzSUbsW6jCRaDilvmGiEPFxiVNpFAZ0IhZFSruEX8hWLbPErS 5KS3eZhltJnD9x/ygSYyoYLVkgAFGYa1SLp72KvkTkVsaAYHQKn2CAfIesOYQrnkUkro 0WlHdd8M1bReBkrsU2y1Ho9MBCxQwX2hhZgAU= MIME-Version: 1.0 Received: by 10.103.87.26 with SMTP id p26mr35041mul.44.1258503244529; Tue, 17 Nov 2009 16:14:04 -0800 (PST) In-Reply-To: <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> Date: Tue, 17 Nov 2009 21:14:04 -0300 Message-ID: <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:14:06 -0000 On Tue, Nov 17, 2009 at 8:14 PM, Ben Kelly wrote: > > On Nov 17, 2009, at 5:21 PM, Gonzalo Nemmi wrote: > > > I've been playing around with it (RC3, i386) and got it to look like > > this (/etc/make.conf): > > > > WITHOUT_MODULES= dev/firewire dev/bwi dev/bce dev/bfe dev/iwi dev/iwn > > zfs sound/driver/ad1816 sound/driver/ai2s sound/driver/als4000 > > sound/driver/atiixp sound/driver/audiocs sound/driver/cmi > > sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa > > sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 > > sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht > > sound/driver/es137x sound/driver/ess sound/driver/fm801 > > sound/driver/ich sound/driver/maestro3 sound/driver/mss > > sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 > > sound/driver/sbc sound/driver/solo sound/driver/spicds > > sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 > > sound/driver/via82c686 sound/driver/vibes > > > > Well .. I don't know what's wrong but no matter what, all of those > > modules and stuff still get built and end up under /boot/kernel ... I > > just need "sound" and "snd_hda"... > > > > What am I doing wrong? > > Any hint will help > > I think the contents of WITHOUT_MODULES should be the short names of the > directories in /usrc/src/sys/modules. So iwn instead of dev/iwn. Also, it > looks like you can only exclude modules at this top level directory > granularity. So you can exclude sound, but not a particular device under > sound. > > Anyway, thats based on a quick read of the Makefile. I could be wrong, > though. I've never actually used this feature. > > Hope that helps. > > - Ben Hi Ben! It could be that .. will try as soon as I can .. I didn't try before because most examples I found on google use it like that .. even the FreeBSD handbook: http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html(take a look at the second "tip" in point 8.5). Thanks for your advise Ben ! Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:17:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5DCA1065676; Wed, 18 Nov 2009 00:17:22 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0278FC0A; Wed, 18 Nov 2009 00:17:22 +0000 (UTC) Received: from bolt.zol (62-121-98-25.home.aster.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 10BFE66D; Wed, 18 Nov 2009 01:21:28 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 01:17:20 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: <1258497221.2303.66.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 00:17:22 -0000 On Tue, 17 Nov 2009 23:33:41 +0100, Robert Noland wrote: >> Should I file a PR? I would >> like to help in debugging it (however my skills in low-level C aren't >> strong enough to do it on my own). > Ok, the first thing I would like to see is "zdb -uuu". # zdb -uuu pgpool Segmentation fault: 11 (core dumped) # zdb pgpool version=13 name='pgpool' state=0 txg=439808 pool_guid=3920915583055727184 hostid=1642959122 hostname='unset' vdev_tree type='root' id=0 guid=3920915583055727184 children[0] type='disk' id=0 guid=5859773264564918193 path='/dev/da0' whole_disk=0 metaslab_array=23 metaslab_shift=35 ashift=9 asize=4500799356928 is_log=0 DTL=260 > I don't see an > obvious issue with single disk reads. My own setup uses 2 x 1TB > currently. Failing to read the MOS is basically the first read attempt > from the pool, in fact it is the read that attempts to mount the pool. -- am From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:17:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B27E41065672 for ; Wed, 18 Nov 2009 00:17:52 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 468B98FC13 for ; Wed, 18 Nov 2009 00:17:51 +0000 (UTC) Received: by fxm27 with SMTP id 27so659148fxm.3 for ; Tue, 17 Nov 2009 16:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=gw06+aSbCRf3jcZxO2SuIB92YCANncXn1a8YnWsBv+U=; b=f5iVn+6mns72M/WYccxdiNmRuep0i8UEahLMGBC4JKdvPl2MFbmQNTM2i6nmnhsZmM Y42FEotstXGAwVPXbZa97iIIv1+gng032cbUrHQPSLxKcROw+1ceouZPR4kQ+HW0hNZ5 U+CymSocmXojv2fRb4pZC5Mjc6YF0EXRQcxVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=a7c4Z3B+4P08r07uYDDBa70rQmAmOg3lVoS04Alx2S1Vpw1RbUzFic21YteFojJkH/ IMN0rpVtNNgS4Sd43lGoPKGtcELLckaZLVzV+fjnqBuDW3+IkrgBEDRZ7t3HAg6Wy269 sxAcEIWxLMDeRrz/bMpFeXHJ3onl0XBPn2W/A= MIME-Version: 1.0 Received: by 10.103.81.8 with SMTP id i8mr4532365mul.80.1258503471238; Tue, 17 Nov 2009 16:17:51 -0800 (PST) In-Reply-To: <4B033C61.7090702@quis.cx> References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> <4B033C61.7090702@quis.cx> Date: Tue, 17 Nov 2009 21:17:51 -0300 Message-ID: <19e9a5dc0911171617p5b815b0cm940c5de518be8339@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:17:52 -0000 On Tue, Nov 17, 2009 at 9:14 PM, Jille Timmermans wrote: > Gonzalo Nemmi schreef: > > Otherwise, if you have nothing important or relelevant to say > > > You might want to take a look at your own e-mail.. > > -- Jille > Let it flow Jille .. and let's see if there's something important or relevant that comes out of this thread. And BTW .. I really don't need to .. I wrote it... From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:19:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DB5F10656A3 for ; Wed, 18 Nov 2009 00:19:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 254E28FC13 for ; Wed, 18 Nov 2009 00:19:00 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E317714E054; Tue, 17 Nov 2009 16:18:59 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 902992D6015; Tue, 17 Nov 2009 16:18:59 -0800 (PST) Message-ID: <4B033D73.3040409@elischer.org> Date: Tue, 17 Nov 2009 16:18:59 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Gonzalo Nemmi References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> In-Reply-To: <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:19:00 -0000 Gonzalo Nemmi wrote: > On Tue, Nov 17, 2009 at 8:22 PM, Julian Elischer wrote: > >> Gonzalo Nemmi wrote: >> >>> On Tuesday 17 November 2009 8:29:23 pm Andrew Thompson wrote: >>> >>>> On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: >>>> >> I just need "sound" and "snd_hda"... >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Hi Andrew! >>> Well, as I already told Boris, I did try that but it didn't work out quite >>> as expected ... leaving me with only two modules :s >>> There was no if_ modules, no wlan_, no zlib, no nothing .. except sound >>> and snd_hda ... :s >>> >> >> well that's what you SAID you wanted... >> >> > Oh, sorry ... I should've made it clear that that was what I needed "only" > in regards to sound ... I guess I forgot there's people in the list that > doesn't have clue, not only about FreeBSD and Unix system administration but > also about irony ... > > See Julian.. as the saying goes, if you want to help a hungry men, don't > give him fish .. teach him how to fish .. so in that order of things let's > do this, try and do what you are, ironically, advising me to do and tell me > how it goes ... how the system works with only those 2 modules. > > Otherwise, if you have nothing important or relelevant to say, please try to > keep it shut ... and please, try _really_hard_, cause you are making me > loose my time as well as other's people time. > > Boris and Andrew were trying to help ... if you are not up to the task, > please, take a step aside and do yourself a favor. Sorry you feel that way but if you look in your mailbox you will also find a response from me (I think privately) suggesting that since you only want 2 modules you might do better to use MODULES_OVERRIDE. I was truely taking you at your word and no I didn't read things into your mail that you didn't write. Not being a mind reader it's the best I can do. As for wasting someones time, Sorry I was only trying to help. You can thank me for the original SCSI systen, boot blocks, divert, netgraph, vimage work, Multiple routing tables, original devfs, kernel threads and hundreds of bugfixes another time. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:20:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24AD01065693 for ; Wed, 18 Nov 2009 00:20:45 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id A4E038FC18 for ; Wed, 18 Nov 2009 00:20:44 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so262222fga.13 for ; Tue, 17 Nov 2009 16:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=u78b5EAGd6vVwttFA70KWmR0RIjqDeFZnpFnkgcVvFw=; b=pv8x4S3Qr+6jA1Nr+QEtuPNuUcfUM4S6B8guzv4RYJdy1iltGNLtBX4DBGE8Zyvhd0 WRhfVaCY1ueyAh2YFvrW5no2i90RtgFVWX71tTEFzg7KLI0gVA4PWT9p7qNoK2Wa2fOM oXLgNz9FcY5rXuvPtNiH8MhKivCk1bdVrqMqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kq3gk2xUhMw69bJh++9/TFBtA33XdoQrHsoOLU1VTWrWJanHMbmVH/1+j6/5K4lDL5 HO4buskP0Oq26mFOXH4bN0vAIDu9OJiLthvNNpqnWkvcPOF0KmvOC4X8ONeq9tlKxsme T7jdgu8ytXIWILh8YQNUJ0Q4ok+HICSdPSF78= MIME-Version: 1.0 Received: by 10.103.122.5 with SMTP id z5mr4821484mum.11.1258503643540; Tue, 17 Nov 2009 16:20:43 -0800 (PST) In-Reply-To: <4B033D73.3040409@elischer.org> References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> <4B033D73.3040409@elischer.org> Date: Tue, 17 Nov 2009 21:20:43 -0300 Message-ID: <19e9a5dc0911171620q7c24ba03k3f1c955b8c886cbf@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:20:45 -0000 On Tue, Nov 17, 2009 at 9:18 PM, Julian Elischer wrote: > Gonzalo Nemmi wrote: > >> On Tue, Nov 17, 2009 at 8:22 PM, Julian Elischer > >wrote: >> >> Gonzalo Nemmi wrote: >>> >>> On Tuesday 17 November 2009 8:29:23 pm Andrew Thompson wrote: >>>> >>>> On Tue, Nov 17, 2009 at 08:21:16PM -0200, Gonzalo Nemmi wrote: >>>>> >>>>> I just need "sound" and "snd_hda"... >>> >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> >>>> >>> Hi Andrew! >>> >>>> Well, as I already told Boris, I did try that but it didn't work out >>>> quite >>>> as expected ... leaving me with only two modules :s >>>> There was no if_ modules, no wlan_, no zlib, no nothing .. except sound >>>> and snd_hda ... :s >>>> >>>> >>> well that's what you SAID you wanted... >>> >>> >>> Oh, sorry ... I should've made it clear that that was what I needed >> "only" >> in regards to sound ... I guess I forgot there's people in the list that >> doesn't have clue, not only about FreeBSD and Unix system administration >> but >> also about irony ... >> >> See Julian.. as the saying goes, if you want to help a hungry men, don't >> give him fish .. teach him how to fish .. so in that order of things let's >> do this, try and do what you are, ironically, advising me to do and tell >> me >> how it goes ... how the system works with only those 2 modules. >> >> Otherwise, if you have nothing important or relelevant to say, please try >> to >> keep it shut ... and please, try _really_hard_, cause you are making me >> loose my time as well as other's people time. >> >> Boris and Andrew were trying to help ... if you are not up to the task, >> please, take a step aside and do yourself a favor. >> > > Sorry you feel that way but if you look in your mailbox you will > also find a response from me (I think privately) suggesting that > since you only want 2 modules you might do better to use MODULES_OVERRIDE. > I was truely taking you at your word and no I didn't read things > into your mail that you didn't write. Not being a mind reader it's > the best I can do. > > As for wasting someones time, Sorry I was only trying to help. > You can thank me for the original SCSI systen, boot blocks, divert, > netgraph, vimage work, Multiple routing tables, original devfs, > kernel threads and hundreds of bugfixes another time. > > Thank you From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:21:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 884991065670 for ; Wed, 18 Nov 2009 00:21:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 16BCD8FC24 for ; Wed, 18 Nov 2009 00:21:54 +0000 (UTC) Received: (qmail 6113 invoked by uid 399); 18 Nov 2009 00:21:54 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Nov 2009 00:21:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B033E22.3060700@FreeBSD.org> Date: Tue, 17 Nov 2009 16:21:54 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Gonzalo Nemmi References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> In-Reply-To: <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:21:55 -0000 Gonzalo Nemmi wrote: > I didn't try before because > most examples I found on google use it like that .. even the FreeBSD > handbook: > http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html(take > a look at the second "tip" in point 8.5). There does not seem to be a WITHOUT_MODULES option anymore in 9-current, which leads me to believe that it is gone from RELENG_8 as well. You should file a doc PR and ask to have it looked into. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 00:26:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D222106566B for ; Wed, 18 Nov 2009 00:26: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 ESMTP id C743B8FC08 for ; Wed, 18 Nov 2009 00:26:30 +0000 (UTC) Received: (qmail 13468 invoked by uid 399); 18 Nov 2009 00:26:30 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Nov 2009 00:26:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B033F36.3030906@FreeBSD.org> Date: Tue, 17 Nov 2009 16:26:30 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Gonzalo Nemmi References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> In-Reply-To: <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:26:31 -0000 Gonzalo Nemmi wrote: > Oh, sorry ... I should've made it clear that that was what I needed "only" > in regards to sound FWIW, my original reading of your message was the same as just about everyone else's, that you only wanted 2 modules. In that case MODULES_OVERRIDE was the right answer. The rest of this particular message was exceedingly rude and obnoxious. That kind of message is not appropriate for the FreeBSD mailing lists under any circumstances, please don't do it again. Meanwhile, you should really slow down and think before you post to a public list, especially when you are asking other people to help you. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 01:01:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 176B61065679 for ; Wed, 18 Nov 2009 01:01:09 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id B211D8FC0C for ; Wed, 18 Nov 2009 01:01:08 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nAI1155L048974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 01:01:06 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <4B033E22.3060700@FreeBSD.org> Date: Tue, 17 Nov 2009 20:01:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 01:01:09 -0000 On Nov 17, 2009, at 7:21 PM, Doug Barton wrote: > Gonzalo Nemmi wrote: >> I didn't try before because >> most examples I found on google use it like that .. even the FreeBSD >> handbook: >> = http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html(ta= ke >> a look at the second "tip" in point 8.5). >=20 > There does not seem to be a WITHOUT_MODULES option anymore in > 9-current, which leads me to believe that it is gone from RELENG_8 as > well. You should file a doc PR and ask to have it looked into. It seems there are some left over bits then. I have this in = /usr/src/sys/modules/Makefile: .for reject in ${WITHOUT_MODULES} SUBDIR:=3D ${SUBDIR:N${reject}} .endfor - Ben= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 01:06:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210A81065679 for ; Wed, 18 Nov 2009 01:06: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 ESMTP id A18D98FC1E for ; Wed, 18 Nov 2009 01:06:33 +0000 (UTC) Received: (qmail 23032 invoked by uid 399); 18 Nov 2009 01:06:32 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Nov 2009 01:06:32 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B034899.9090408@FreeBSD.org> Date: Tue, 17 Nov 2009 17:06:33 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Ben Kelly References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> In-Reply-To: <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 01:06:34 -0000 Ben Kelly wrote: > It seems there are some left over bits then. I have this in /usr/src/sys/modules/Makefile: > > .for reject in ${WITHOUT_MODULES} > SUBDIR:= ${SUBDIR:N${reject}} > .endfor Well it seems my search was not exhaustive. My recommendation then would be to file a src PR so that someone can look into it. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 01:47:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94906106566B for ; Wed, 18 Nov 2009 01:47:48 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 345108FC0A for ; Wed, 18 Nov 2009 01:47:47 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nAI1leYI063809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 01:47:41 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> Date: Tue, 17 Nov 2009 20:47:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <70268D94-FB8F-4E24-89F5-7E1718EF4267@wanderview.com> References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> To: Gonzalo Nemmi X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 01:47:48 -0000 On Nov 17, 2009, at 7:14 PM, Gonzalo Nemmi wrote: > On Tue, Nov 17, 2009 at 8:14 PM, Ben Kelly wrote: >=20 >>=20 >> On Nov 17, 2009, at 5:21 PM, Gonzalo Nemmi wrote: >>=20 >>> I've been playing around with it (RC3, i386) and got it to look like >>> this (/etc/make.conf): >>>=20 >>> WITHOUT_MODULES=3D dev/firewire dev/bwi dev/bce dev/bfe dev/iwi = dev/iwn >>> zfs sound/driver/ad1816 sound/driver/ai2s sound/driver/als4000 >>> sound/driver/atiixp sound/driver/audiocs sound/driver/cmi >>> sound/driver/cs4281 sound/driver/cs4281 sound/driver/csa >>> sound/driver/davbus sound/driver/ds1 sound/driver/emu10k1 >>> sound/driver/emu10kx sound/driver/envy24 sound/driver/envy24ht >>> sound/driver/es137x sound/driver/ess sound/driver/fm801 >>> sound/driver/ich sound/driver/maestro3 sound/driver/mss >>> sound/driver/neomagic sound/driver/sb16 sound/driver/sb8 >>> sound/driver/sbc sound/driver/solo sound/driver/spicds >>> sound/driver/t4dwave sound/driver/uaudio sound/driver/via8233 >>> sound/driver/via82c686 sound/driver/vibes >>>=20 >>> Well .. I don't know what's wrong but no matter what, all of those >>> modules and stuff still get built and end up under /boot/kernel ... = I >>> just need "sound" and "snd_hda"... >>>=20 >>> What am I doing wrong? >>> Any hint will help >>=20 >> I think the contents of WITHOUT_MODULES should be the short names of = the >> directories in /usrc/src/sys/modules. So iwn instead of dev/iwn. = Also, it >> looks like you can only exclude modules at this top level directory >> granularity. So you can exclude sound, but not a particular device = under >> sound. >>=20 >> Anyway, thats based on a quick read of the Makefile. I could be = wrong, >> though. I've never actually used this feature. >>=20 >> Hope that helps. >>=20 >> - Ben >=20 >=20 > Hi Ben! > It could be that .. will try as soon as I can .. I didn't try before = because > most examples I found on google use it like that .. even the FreeBSD > handbook: > = http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html(ta= ke > a look at the second "tip" in point 8.5). I've just verified on my machine that WITHOUT_MODULES will only strip = out top level module directories. You cannot pick and choose = subdirectories like the handbook suggests. I'm guessing someone cut & = paste the MODULES_OVERRIDE line to add the WITHOUT_MODULES entry. = Selecting subdirectories works in the MODULES_OVERRIDE case, though, = because you can add a subdirectory even if the original list you are = replacing only contains the top level module directories. Also, the current implementation of WITHOUT_MODULES does not support = being set in your kernel config using makeoptions. This patch fixes = that for me: Index: sys/conf/kern.pre.mk =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 --- sys/conf/kern.pre.mk (revision 254) +++ sys/conf/kern.pre.mk (working copy) @@ -163,6 +163,9 @@ .if defined(MODULES_OVERRIDE) MKMODULESENV+=3D MODULES_OVERRIDE=3D"${MODULES_OVERRIDE}" .endif +.if defined(WITHOUT_MODULES) +MKMODULESENV+=3D WITHOUT_MODULES=3D"${WITHOUT_MODULES}" +.endif .if defined(DEBUG) MKMODULESENV+=3D DEBUG_FLAGS=3D"${DEBUG}" .endif Hope that helps. - Ben= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 02:00:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BD60106566B; Wed, 18 Nov 2009 02:00:02 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id C24518FC0A; Wed, 18 Nov 2009 02:00:01 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nAI1xxE2063927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 01:59:59 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <4B034899.9090408@FreeBSD.org> Date: Tue, 17 Nov 2009 20:59:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> <4B034899.9090408@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 02:00:02 -0000 On Nov 17, 2009, at 8:06 PM, Doug Barton wrote: > Ben Kelly wrote: >> It seems there are some left over bits then. I have this in = /usr/src/sys/modules/Makefile: >>=20 >> .for reject in ${WITHOUT_MODULES} >> SUBDIR:=3D ${SUBDIR:N${reject}} >> .endfor >=20 > Well it seems my search was not exhaustive. >=20 > My recommendation then would be to file a src PR so that someone can > look into it. :) I've opened a doc PR for the bad example in the handbook and a conf PR = for the patch to make WITHOUT_MODULES work from the kernel config file = using makeoptions. I haven't gotten PR numbers back from the system = yet. - Ben= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 02:55:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6DD51065670 for ; Wed, 18 Nov 2009 02:55:45 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 923B08FC12 for ; Wed, 18 Nov 2009 02:55:44 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id nAI2thnO098441 for ; Tue, 17 Nov 2009 19:55:43 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id nAI2th0l098438 for ; Tue, 17 Nov 2009 19:55:43 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 17 Nov 2009 19:55:43 -0700 (MST) From: Warren Block To: current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (wonkity.com [127.0.0.1]); Tue, 17 Nov 2009 19:55:43 -0700 (MST) Cc: Subject: sendmail aliases/Realtek 8111 problem (bin/139870) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 02:55:45 -0000 sendmail was ignoring existing aliases on startup. This is apparently due to a network interface not being ready in time in combination with a not-FQDN hostname. With a hostname of "lightning" (no domain), re0 configured by DHCP, and verbose sendmail logging: 050 WARNING: interface re0 is UP with 0.0.0.0 address 050 WARNING: local host name (lightning) is not qualified; see cf/README: WHO AM I A restart of sendmail after startup works normally because re0 has acquired an address by then. Entering a FQDN as hostname (hostname="lightning.wonkity.com") in rc.conf works also. I would say that this is really a problem with re0 and not with sendmail startup, but don't really know. re0 does a DOWN/UP three times on startup. re0: port 0xe800-0xe8ff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 17 at device 0.0 on pci4 re0@pci0:4:0:0: class=0x020000 card=0x514c1462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' class = network subclass = ethernet -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:06:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FD8E106566B for ; Wed, 18 Nov 2009 03:06:01 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id D04418FC08 for ; Wed, 18 Nov 2009 03:06:00 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so297814fga.13 for ; Tue, 17 Nov 2009 19:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=FYikbbrzIWaHO19VB6o8rtYxfI1rgg9thP/17jyZp0Q=; b=JuoQjW3LKf3pGgXp29BDdR1VJdnpEk2a3q8srPVzOxL5nPiiXAYYZfEVTqhTEcmW3m MEur5u9L4kddY4jnrzjs7+rwB1Iqmc8dzCT+nhoIc1tO7BEDySa0akBFOh9YFStjkNSr oMnOEb8bnzCMgRhVSbRLPl0muItTvK6esu5Ns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vibPcmwSCSvREBJ/7g0wcx2sW7nUtNTT2gh9zs4By5SkBFDL9cxXcwHzT0HouijL8z wyFAdSbomGTRzmxSYLBJLEmQf8HsF/8WMqvFkyA8vCJ2o2cBfl0BERxhFYn5ZJVSeCkx u4awm3Ld5BmAf8iQxJ6UjIXbcQvPyeioBZVqk= MIME-Version: 1.0 Received: by 10.102.235.20 with SMTP id i20mr4869769muh.38.1258513559491; Tue, 17 Nov 2009 19:05:59 -0800 (PST) In-Reply-To: <20091118000838.60CBC1CC47@ptavv.es.net> References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> Date: Wed, 18 Nov 2009 00:05:59 -0300 Message-ID: <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:06:01 -0000 On Tue, Nov 17, 2009 at 9:08 PM, Kevin Oberman wrote: > > From: Gonzalo Nemmi > > Date: Tue, 17 Nov 2009 20:43:27 -0200 > > Sender: owner-freebsd-current@freebsd.org > > > > On Tuesday 17 November 2009 8:30:41 pm Poul-Henning Kamp wrote: > > > Check out the scripts in src/tools/tools/build_option_survey/ > > > > > > The result looked like this on stable-7 some time ago: > > > > > > http://phk.freebsd.dk/misc/stable7_build_options/ > > > > > > no effect .. > > Interesting ... > > Thanks for the link Mr. Poul-Henning Kamp > > I can state that several of the src.conf options in 8.0 don't work and > some will break the build. There is an open PR that has a fix to > Makefile.inc1 for at least some of the problems. > > That said, building a new world without telnet does not delete the > existing binaries, libs, header files, etc. It just causes them not to > be built again. Further, delete-old will not delete them. > I can confirm that. Telnet creation date is predate that of the binaries created by buildworld > If you build with some parts of the base system removed in this manner, > you really need to go in and remove the old stuff by hand. It won't be > created arain. > Thanks for the advise Kevin! > N.B. I have not tried WITHOUT_TELNET=, so I can't swear that ti works. I > build WITHOUT_OPENSSH and WITHOUT_BIND as I use the ports with > OVERWRITE_BASE. and WITHOUT_BIND works fine. WITHOUT_OPENSSH requires > the patches mentions above for Makefile.inc1 (thanks to bf for those). > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:11:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 292A31065670 for ; Wed, 18 Nov 2009 03:11:47 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id A813C8FC25 for ; Wed, 18 Nov 2009 03:11:46 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so1802478fga.13 for ; Tue, 17 Nov 2009 19:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=hWzkSQcx1SBNE6yGsYkrHmr3t8bovrYZhYxjRGE2E20=; b=Vj6C1MxypaY6NalYMBPNaOpLGt/7GGip09T9jGkVu52HcpV7uvIiVBGRdqDN6v1xqM Y+bo8bhUPOps1uX0C6+hIRrsGarwV3FnzM5yvBxcDrVvsUWzvaQVALN0/UgOeYAYbsn0 jOiuW7jg3zpWReQDw1uTm9VocZNqF/cUOHLfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pV0ZYkekngl022pMNKpg07vskVHlDju8kb0AdyeaWN93YYtz9uhGdN6Ixly9CY6DbC 5kYiSwQy+hLAYZXLEm7MzqlOUx0aV7XzC494tEXhxkBrn7ka02eChzCZ2Gvk1ezOe/iW iPAUge1UPWYQzV0inph4SEBcTnyQZw1/cfg3E= MIME-Version: 1.0 Received: by 10.103.48.17 with SMTP id a17mr525628muk.82.1258513905595; Tue, 17 Nov 2009 19:11:45 -0800 (PST) In-Reply-To: <20091117232347.GJ1262@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911171650.06834.gnemmi@gmail.com> <20091117193208.GI1262@michelle.cdnetworks.com> <200911171917.41906.gnemmi@gmail.com> <20091117232347.GJ1262@michelle.cdnetworks.com> Date: Wed, 18 Nov 2009 00:11:45 -0300 Message-ID: <19e9a5dc0911171911l6803c9dbkd8dde1b9f54e701@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Call for bge(4) 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, 18 Nov 2009 03:11:47 -0000 On Tue, Nov 17, 2009 at 8:23 PM, Pyun YongHyeon wrote: > On Tue, Nov 17, 2009 at 07:17:41PM -0200, Gonzalo Nemmi wrote: > > On Tuesday 17 November 2009 5:32:08 pm Pyun YongHyeon wrote: > > > On Tue, Nov 17, 2009 at 04:50:06PM -0200, Gonzalo Nemmi wrote: > > > > > > [...] > > > > > > > Well, I proceeded as I told you I would, applied your patch and > > > > even if it didn't solve the problem (bge still doesn't resume) at > > > > least it improved the previous situation given that now it doesn't > > > > loop timing out once and again as before. > > > > > > > > You can find a tail from /var/log/messages in here: > > > > http://pastebin.com/f643555f7 > > > > > > > > As you can see, the first 3 lines corresponds to "kldload if_bge" > > > > Line number 4 is "acpiconf -s3" > > > > > > > > At line number 17 bge0 finally fails and let's the machine wake up > > > > at line 18. > > > > > > > > Then, as soon as I could I issued a "ifconfig bge0" to see what I > > > > could get .. that's what you can see from line 20 to line 41. (as > > > > you can see > > > > > > Ok, would you try this one? I guess bge(4) register access method > > > could be in uninitialized state after resume. > > > > Just did .. same result .. you=B4ll find the messages here: > > http://pastebin.com/f38369b3c > > > > 1.- root login > > 2 to 9.- "kldload if_bge" > > 10.- "acpiconf -s3" > > 11 to 13.- wpi0 messages before suspending > > 14 to 23.- bge0 messages upon resume > > 24.- wakeup > > > > Can you remove wpi(4) in kernel configuration and try again? > I don't think wpi(4) can interfere bge(4) resume but just want to > clear it. > > Just did .. got rid of wpi, wpifw, firmware, recompile, reinstalled and got the same result: http://pastebin.com/f5933192d > > BTW: is there an easy way to unroll the patches so I get a pristine cop= y > > back and apply the patch over it again? Im asking because the 3rd chunk > > of your patch ( bge_reset(sc); ) didn't apply cleanly and I had to edit > > if_bge.c by hand to add that line in the right place. > > > > There is option -R in patch(1) so I think you can safely undo > applied patches if you have previous patch in your box. > > Did that .. cd /usr/src && patch -R < /path/to/patch It apllied like a charm :) > Still have no clue yet. This kind of debugging really need hardware > access to experiment various things but let's try narrow down > possible cause of problem. > I might be able to fix that if you really care about fixing this bug .. I can set you up a ssh account and give you root acces to this machine if you need to :) Just let me know ;) Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:15:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6CFE106566B for ; Wed, 18 Nov 2009 03:15:40 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3AACD8FC0A for ; Wed, 18 Nov 2009 03:15:39 +0000 (UTC) Received: by fxm27 with SMTP id 27so768938fxm.3 for ; Tue, 17 Nov 2009 19:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=0RhujQQWoEzRV+W3CmPAW2NZe5pWczwOPQQcx288F1E=; b=BiXjuE8oqM3OxDJj/sXRZnNKsom4rQQLNJh+c6eQD/ZMHIJD2sx+Je102EtAMPqBab owdBBE/6++tSiAKa484xPMHYC+oDQjx9/UjqGjS9ZYMdFtpG6pycVZcBcHFo0xT+kp+M 89MG3c4Der3yP+DgneFTWLm0LCsZHZ7CxRH5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vzc0A+SNjo9lNvMYUOGIQcr2LMMepz/ZB53hCmWGkxjzdCp6f87i5VSdp0y0SeWumQ kILChpK3fgBbMyuHWRIAV8bsgps5Kc6IKC1XYLuugUBVnB0okdhBhRFZwQUvoh2/W39v rrtJMq3nseGF3KFO+mTvoxP6h1AoAdRPtzdv0= MIME-Version: 1.0 Received: by 10.103.50.25 with SMTP id c25mr4825090muk.10.1258514139271; Tue, 17 Nov 2009 19:15:39 -0800 (PST) In-Reply-To: <4B033E22.3060700@FreeBSD.org> References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> Date: Wed, 18 Nov 2009 00:15:39 -0300 Message-ID: <19e9a5dc0911171915j28b688a6w1820aae354c4ba7a@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:15:40 -0000 On Tue, Nov 17, 2009 at 9:21 PM, Doug Barton wrote: > Gonzalo Nemmi wrote: > > I didn't try before because > > most examples I found on google use it like that .. even the FreeBSD > > handbook: > > > http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html(take > > a look at the second "tip" in point 8.5). > > There does not seem to be a WITHOUT_MODULES option anymore in > 9-current, which leads me to believe that it is gone from RELENG_8 as > well. You should file a doc PR and ask to have it looked into. > > > Doug > > Thanks for the heads up Doug ! Will file the PR first thing tomorrow morning :) Thanks, really Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:27:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB6721065670; Wed, 18 Nov 2009 03:27:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 920F18FC1B; Wed, 18 Nov 2009 03:27:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAI3RDMC097305; Tue, 17 Nov 2009 22:27:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAI3RDPT097293; Wed, 18 Nov 2009 03:27:13 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Nov 2009 03:27:13 GMT Message-Id: <200911180327.nAI3RDPT097293@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips 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: Wed, 18 Nov 2009 03:27:14 -0000 TB --- 2009-11-18 02:40:23 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-18 02:40:23 - starting HEAD tinderbox run for mips/mips TB --- 2009-11-18 02:40:23 - cleaning the object tree TB --- 2009-11-18 02:40:32 - cvsupping the source tree TB --- 2009-11-18 02:40:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2009-11-18 02:40:57 - building world TB --- 2009-11-18 02:40:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-18 02:40:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-18 02:40:57 - TARGET=mips TB --- 2009-11-18 02:40:57 - TARGET_ARCH=mips TB --- 2009-11-18 02:40:57 - TZ=UTC TB --- 2009-11-18 02:40:57 - __MAKE_CONF=/dev/null TB --- 2009-11-18 02:40:57 - cd /src TB --- 2009-11-18 02:40:57 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 18 02:40:58 UTC 2009 >>> 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 [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_ulink.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwv.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwvb.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntpd-opts.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -c version.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Wl,-EL -o ntpd cmd_args.o ntp_config.o ntp_control.o ntp_crypto.o ntp_filegen.o ntp_intres.o ntp_io.o ntp_loopfilter.o ntp_monitor.o ntp_peer.o ntp_proto.o ntp_refclock.o ntp_request.o ntp_restrict.o ntp_timer.o ntp_util.o ntpd.o refclock_acts.o refclock_arbiter.o refclock_arc.o refclock_as2201.o refclock_atom.o refclock_bancomm.o refclock_chronolog.o refclock_chu.o refclock_conf.o refclock_datum.o refclock_dumbclock.o refclock_fg.o refclock_gpsvme.o refclock_heath.o refclock_hopfpci.o refclock_hopfser.o refclock_hpgps.o refclock_irig.o refclock_jupiter.o refclock_leitch.o refclock_local.o refclock_msfees.o refclock_mx4200.o refclock_neoclock4x.o refclock_nmea.o refclock_oncore.o refclock_palisade.o ! refclock_parse.o refclock_pcf.o refclock_pst.o refclock_ripencc.o refclock_shm.o refclock_tpro.o refclock_trak.o refclock_true.o refclock_ulink.o refclock_wwv.o refclock_wwvb.o ntpd-opts.o version.o /obj/mips/src/usr.sbin/ntp/ntpd/../libparse/libparse.a /obj/mips/src/usr.sbin/ntp/ntpd/../libntp/libntp.a -lm -lmd -lrt /obj/mips/src/usr.sbin/ntp/ntpd/../libopts/libopts.a -lcrypto /obj/mips/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_pop_imp' /obj/mips/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_push_imp' *** Error code 1 Stop in /src/usr.sbin/ntp/ntpd. *** Error code 1 Stop in /src/usr.sbin/ntp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-18 03:27:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-18 03:27:13 - ERROR: failed to build world TB --- 2009-11-18 03:27:13 - 1980.57 user 474.63 system 2809.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:36:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF2BE106568B for ; Wed, 18 Nov 2009 03:36:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7925B8FC15 for ; Wed, 18 Nov 2009 03:36:52 +0000 (UTC) Received: (qmail 12414 invoked by uid 399); 18 Nov 2009 03:36:51 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Nov 2009 03:36:51 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B036BD3.4020900@FreeBSD.org> Date: Tue, 17 Nov 2009 19:36:51 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Ben Kelly References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> <4B034899.9090408@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:36:53 -0000 Ben Kelly wrote: > On Nov 17, 2009, at 8:06 PM, Doug Barton wrote: > >> Ben Kelly wrote: >>> It seems there are some left over bits then. I have this in /usr/src/sys/modules/Makefile: >>> >>> .for reject in ${WITHOUT_MODULES} >>> SUBDIR:= ${SUBDIR:N${reject}} >>> .endfor >> Well it seems my search was not exhaustive. >> >> My recommendation then would be to file a src PR so that someone can >> look into it. :) > > I've opened a doc PR for the bad example in the handbook and a conf PR for the patch to make WITHOUT_MODULES work from the kernel config file using makeoptions. I haven't gotten PR numbers back from the system yet. You can add to the mix the fact that options like modules_override and without_modules are documented in make.conf(5) instead of in src.conf(5) which is where (arguably) they should be. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:44:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5813106566C for ; Wed, 18 Nov 2009 03:44:53 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 757D28FC08 for ; Wed, 18 Nov 2009 03:44:52 +0000 (UTC) Received: by fxm27 with SMTP id 27so784765fxm.3 for ; Tue, 17 Nov 2009 19:44:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Q0VCfqryFmmpwB1Wl0phEx0hMxLKUGhLd0xzcL0Hayk=; b=AyYjDHy9pS+1QzASEvgiWaSHzW9C0qFDHGhsEyhZrQt1LBjWedw5FZmNn3yJIIPegU ttncafpUxmHkAFEFiNtPhwSeeeFC5/fmsajrL3E366xnircHy3ThUX3obE0XbxptN5OQ irXogOdSP1JESOM4hE13eo57eHQy2rORMa7IU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LobD3FDdvZX0VvDcfvwrGHeEW6IWZJFvcrmL4ZJmbdk3gCjO5xbeMk8xawl+EKBqnM 7uqIy/ymuK7GExj+V4R8ZePnAKr63E3S7ymf2HwYSyBIMC8MrfJi5vebjqPPG8zcHNqb KPI9eKdbk0Rjx5yLfP0xWePoUnxnQkkE3iKEE= MIME-Version: 1.0 Received: by 10.103.81.8 with SMTP id i8mr4616227mul.80.1258515892192; Tue, 17 Nov 2009 19:44:52 -0800 (PST) In-Reply-To: References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> <4B034899.9090408@FreeBSD.org> Date: Wed, 18 Nov 2009 00:44:52 -0300 Message-ID: <19e9a5dc0911171944q5d15dc96t83ecd53befb07621@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:44:54 -0000 On Tue, Nov 17, 2009 at 10:59 PM, Ben Kelly wrote: > > On Nov 17, 2009, at 8:06 PM, Doug Barton wrote: > > > Ben Kelly wrote: > >> It seems there are some left over bits then. I have this in > /usr/src/sys/modules/Makefile: > >> > >> .for reject in ${WITHOUT_MODULES} > >> SUBDIR:= ${SUBDIR:N${reject}} > >> .endfor > > > > Well it seems my search was not exhaustive. > > > > My recommendation then would be to file a src PR so that someone can > > look into it. :) > > I've opened a doc PR for the bad example in the handbook and a conf PR for > the patch to make WITHOUT_MODULES work from the kernel config file using > makeoptions. I haven't gotten PR numbers back from the system yet. > > - Ben_______________________________________________ So, basically .. not only man make.conf and the handbook examples are wrong .. WITHOUT_MODULES doesn't actually work :s Thanks a lot for your research, testing, PR and patches Ben ! Please, should you be able to, I would like to know the PR number so I can follow it. Hope your patch makes it in and WITHOUT_MODULES works as expected :) Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:46:32 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6DEF106566B; Wed, 18 Nov 2009 03:46:32 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5058FC0A; Wed, 18 Nov 2009 03:46:31 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nAI3kOSo065128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 03:46:24 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <4B036BD3.4020900@FreeBSD.org> Date: Tue, 17 Nov 2009 22:46:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <568A6428-A2DD-49D4-B043-455273A7902E@wanderview.com> References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> <4B034899.9090408@FreeBSD.org> <4B036BD3.4020900@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-current@FreeBSD.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:46:32 -0000 On Nov 17, 2009, at 10:36 PM, Doug Barton wrote: > Ben Kelly wrote: >> On Nov 17, 2009, at 8:06 PM, Doug Barton wrote: >>=20 >>> Ben Kelly wrote: >>>> It seems there are some left over bits then. I have this in = /usr/src/sys/modules/Makefile: >>>>=20 >>>> .for reject in ${WITHOUT_MODULES} >>>> SUBDIR:=3D ${SUBDIR:N${reject}} >>>> .endfor >>> Well it seems my search was not exhaustive. >>>=20 >>> My recommendation then would be to file a src PR so that someone can >>> look into it. :) >>=20 >> I've opened a doc PR for the bad example in the handbook and a conf = PR for the patch to make WITHOUT_MODULES work from the kernel config = file using makeoptions. I haven't gotten PR numbers back from the = system yet. >=20 > You can add to the mix the fact that options like modules_override and > without_modules are documented in make.conf(5) instead of in > src.conf(5) which is where (arguably) they should be. =46rom the log for r88893 of /usr/src/sys/conf/kern.pre.mk I think its = intended that the module variables are related to ports in some way: Move initialization of the MKMODULESENV envorinoment to kern.pre.mk from kern.post.mk so port makefiles can augment it. So I'm guessing make.conf might be the right place. In any case, here are the PRs I opened: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D140649 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D140650 Thanks. - Ben= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 03:54:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0A96106566B for ; Wed, 18 Nov 2009 03:54:11 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1328FC18 for ; Wed, 18 Nov 2009 03:54:10 +0000 (UTC) Received: by bwz5 with SMTP id 5so864450bwz.3 for ; Tue, 17 Nov 2009 19:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=WPTwWyY/mGeixCH2kREcgYa/3G3oAEu9S6AOjCik98U=; b=YfN8z4D2XTfHuuLwYj+w1tdp+zbj8O4tTXeFG+zr766jxoAqxh9xC4C3mcVxVXdcTC R/ZEVXtKprY7f2G0NpEiddqHlm265t6+0F1QuZT+Rx+ZtBhGR/pIb1/xfoHtQVGOjD5D g/S4IiYLSpN9EnhZfYwtYu+EfAzX11p0ZDylI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ucHcokcYLWED0F1mDLs453Hp1fOw7xtt+0cbLhSne6YUseSB8FnWKjaAadww8ZGdcx q4mGpdO92Jcjd98qvi+k+7q60czsrTH7LlOq0Bq0F86gG2S+amVt8zJC2t6YjA/aP7FV nQb6oHLvPtFN0RALz0ykw40aF1CuIkUnF2nio= MIME-Version: 1.0 Received: by 10.103.87.26 with SMTP id p26mr123518mul.44.1258516449784; Tue, 17 Nov 2009 19:54:09 -0800 (PST) In-Reply-To: <20091118003322.GC1637@albert.catwhisker.org> References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> <4B033F36.3030906@FreeBSD.org> <20091118003322.GC1637@albert.catwhisker.org> Date: Wed, 18 Nov 2009 00:54:09 -0300 Message-ID: <19e9a5dc0911171954o11c25dd7la2ffe1e02448e5f6@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:54:11 -0000 On Tue, Nov 17, 2009 at 9:33 PM, David Wolfskill wrote: > On Tue, Nov 17, 2009 at 04:26:30PM -0800, Doug Barton wrote: > > Gonzalo Nemmi wrote: > > ... > > The rest of this particular message was exceedingly rude and > > obnoxious. That kind of message is not appropriate for the FreeBSD > > mailing lists under any circumstances, please don't do it again. > > > > Meanwhile, you should really slow down and think before you post to a > > public list, especially when you are asking other people to help you. > > ... > > And most especially when the archives of the public list in question > are accessible (and searchable) by anyone with access to a Web > browser and the Internet. (And no, removing posts from the archives is > not feasible -- any more than "un-saying" something.) > The goo thing about free acces to the archives of the public list in question is that they let you know who started a thread, why and what was the outcome of the OP question ... > I doubt I'm the only one who pokes around on the Net before actually > interviewing someone for a position, after all. > You are right .. you are not the only one .. and that's even better than free acces to the archives of the public list in question .. not everyone ponders the same thing when they are looking forward to interviewing someone for a position. Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 04:00:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C2D106568D; Wed, 18 Nov 2009 04:00:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 62FAC8FC08; Wed, 18 Nov 2009 04:00:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAI403UA045020; Tue, 17 Nov 2009 23:00:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAI403bT045019; Wed, 18 Nov 2009 04:00:03 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Nov 2009 04:00:03 GMT Message-Id: <200911180400.nAI403bT045019@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 04:00:04 -0000 TB --- 2009-11-18 03:01:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-18 03:01:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-11-18 03:01:29 - cleaning the object tree TB --- 2009-11-18 03:01:42 - cvsupping the source tree TB --- 2009-11-18 03:01:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-11-18 03:02:04 - building world TB --- 2009-11-18 03:02:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-18 03:02:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-18 03:02:04 - TARGET=powerpc TB --- 2009-11-18 03:02:04 - TARGET_ARCH=powerpc TB --- 2009-11-18 03:02:04 - TZ=UTC TB --- 2009-11-18 03:02:04 - __MAKE_CONF=/dev/null TB --- 2009-11-18 03:02:04 - cd /src TB --- 2009-11-18 03:02:04 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 18 03:02:06 UTC 2009 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_ulink.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwv.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwvb.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntpd-opts.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c version.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -o ntpd cmd_args.o ntp_config.o ntp_control.o ntp_crypto.o ntp_filegen.o ntp_intres.o ntp_io.o ntp_loopfilter.o ntp_monitor.o ntp_peer.o ntp_proto.o ntp_refclock.o ntp_request.o ntp_restrict.o ntp_timer.o ntp_util.o ntpd.o refclock_acts.o refclock_arbiter.o refclock_arc.o refclock_as2201.o refclock_atom.o refclock_bancomm.o refclock_chronolog.o refclock_chu.o refclock_conf.o refclock_datum.o refclock_dumbclock.o refclock_fg.o refclock_gpsvme.o refclock_heath.o refclock_hopfpci.o refclock_hopfser.o refclock_hpgps.o refclock_irig.o refclock_jupiter.o refclock_leitch.o refclock_local.o refclock_msfees.o refclock_mx4200.o refclock_neoclock4x.o refclock_nmea.o refclock_oncore.o refclock_palisade.o refclock_parse.o refclock_pcf.! o refclock_pst.o refclock_ripencc.o refclock_shm.o refclock_tpro.o refclock_trak.o refclock_true.o refclock_ulink.o refclock_wwv.o refclock_wwvb.o ntpd-opts.o version.o /obj/powerpc/src/usr.sbin/ntp/ntpd/../libparse/libparse.a /obj/powerpc/src/usr.sbin/ntp/ntpd/../libntp/libntp.a -lm -lmd -lrt /obj/powerpc/src/usr.sbin/ntp/ntpd/../libopts/libopts.a -lcrypto /obj/powerpc/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_pop_imp' /obj/powerpc/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_push_imp' *** Error code 1 Stop in /src/usr.sbin/ntp/ntpd. *** Error code 1 Stop in /src/usr.sbin/ntp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-18 04:00:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-18 04:00:03 - ERROR: failed to build world TB --- 2009-11-18 04:00:03 - 2625.69 user 525.80 system 3514.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 04:12:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2F34106566C; Wed, 18 Nov 2009 04:12:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8E28FC1B; Wed, 18 Nov 2009 04:12:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAI4Crvg085865; Tue, 17 Nov 2009 23:12:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAI4CrZ1085864; Wed, 18 Nov 2009 04:12:53 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Nov 2009 04:12:53 GMT Message-Id: <200911180412.nAI4CrZ1085864@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 04:12:54 -0000 TB --- 2009-11-18 03:18:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-18 03:18:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-11-18 03:18:45 - cleaning the object tree TB --- 2009-11-18 03:18:59 - cvsupping the source tree TB --- 2009-11-18 03:18:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-11-18 03:19:26 - building world TB --- 2009-11-18 03:19:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-18 03:19:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-18 03:19:26 - TARGET=sparc64 TB --- 2009-11-18 03:19:26 - TARGET_ARCH=sparc64 TB --- 2009-11-18 03:19:26 - TZ=UTC TB --- 2009-11-18 03:19:26 - __MAKE_CONF=/dev/null TB --- 2009-11-18 03:19:26 - cd /src TB --- 2009-11-18 03:19:26 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 18 03:19:26 UTC 2009 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_ulink.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwv.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwvb.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntpd-opts.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c version.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -o ntpd cmd_args.o ntp_config.o ntp_control.o ntp_crypto.o ntp_filegen.o ntp_intres.o ntp_io.o ntp_loopfilter.o ntp_monitor.o ntp_peer.o ntp_proto.o ntp_refclock.o ntp_request.o ntp_restrict.o ntp_timer.o ntp_util.o ntpd.o refclock_acts.o refclock_arbiter.o refclock_arc.o refclock_as2201.o refclock_atom.o refclock_bancomm.o refclock_chronolog.o refclock_chu.o refclock_conf.o refclock_datum.o refclock_dumbclock.o refclock_fg.o refclock_gpsvme.o refclock_heath.o refclock_hopfpci.o refclock_hopfser.o refclock_hpgps.o refclock_irig.o refclock_jupiter.o refclock_leitch.o refclock_local.o refclock_msfees.o refclock_mx4200.o refclock_neoclock4x.o refclock_nmea.o refclock_oncore.o refclock_palisade.o refclock_parse.o refclock_pcf.! o refclock_pst.o refclock_ripencc.o refclock_shm.o refclock_tpro.o refclock_trak.o refclock_true.o refclock_ulink.o refclock_wwv.o refclock_wwvb.o ntpd-opts.o version.o /obj/sparc64/src/usr.sbin/ntp/ntpd/../libparse/libparse.a /obj/sparc64/src/usr.sbin/ntp/ntpd/../libntp/libntp.a -lm -lmd -lrt /obj/sparc64/src/usr.sbin/ntp/ntpd/../libopts/libopts.a -lcrypto /obj/sparc64/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_pop_imp' /obj/sparc64/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_push_imp' *** Error code 1 Stop in /src/usr.sbin/ntp/ntpd. *** Error code 1 Stop in /src/usr.sbin/ntp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-18 04:12:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-18 04:12:53 - ERROR: failed to build world TB --- 2009-11-18 04:12:53 - 2450.71 user 510.34 system 3248.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 04:20:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A978106568D; Wed, 18 Nov 2009 04:20:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 39AFB8FC21; Wed, 18 Nov 2009 04:20:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAI4KM1h000616; Tue, 17 Nov 2009 23:20:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAI4KMjA000615; Wed, 18 Nov 2009 04:20:22 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Nov 2009 04:20:22 GMT Message-Id: <200911180420.nAI4KMjA000615@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 04:20:23 -0000 TB --- 2009-11-18 03:27:13 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-18 03:27:13 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-11-18 03:27:13 - cleaning the object tree TB --- 2009-11-18 03:27:25 - cvsupping the source tree TB --- 2009-11-18 03:27:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-11-18 03:27:49 - building world TB --- 2009-11-18 03:27:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-18 03:27:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-18 03:27:49 - TARGET=sun4v TB --- 2009-11-18 03:27:49 - TARGET_ARCH=sparc64 TB --- 2009-11-18 03:27:49 - TZ=UTC TB --- 2009-11-18 03:27:49 - __MAKE_CONF=/dev/null TB --- 2009-11-18 03:27:49 - cd /src TB --- 2009-11-18 03:27:49 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 18 03:27:49 UTC 2009 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_ulink.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwv.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/refclock_wwvb.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c /src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntpd-opts.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -c version.c cc -O2 -pipe -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/include -I/src/usr.sbin/ntp/ntpd/../ -I/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/libopts -I/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -fstack-protector -o ntpd cmd_args.o ntp_config.o ntp_control.o ntp_crypto.o ntp_filegen.o ntp_intres.o ntp_io.o ntp_loopfilter.o ntp_monitor.o ntp_peer.o ntp_proto.o ntp_refclock.o ntp_request.o ntp_restrict.o ntp_timer.o ntp_util.o ntpd.o refclock_acts.o refclock_arbiter.o refclock_arc.o refclock_as2201.o refclock_atom.o refclock_bancomm.o refclock_chronolog.o refclock_chu.o refclock_conf.o refclock_datum.o refclock_dumbclock.o refclock_fg.o refclock_gpsvme.o refclock_heath.o refclock_hopfpci.o refclock_hopfser.o refclock_hpgps.o refclock_irig.o refclock_jupiter.o refclock_leitch.o refclock_local.o refclock_msfees.o refclock_mx4200.o refclock_neoclock4x.o refclock_nmea.o refclock_oncore.o refclock_palisade.o refclock_parse.o refclock_pcf.! o refclock_pst.o refclock_ripencc.o refclock_shm.o refclock_tpro.o refclock_trak.o refclock_true.o refclock_ulink.o refclock_wwv.o refclock_wwvb.o ntpd-opts.o version.o /obj/sun4v/src/usr.sbin/ntp/ntpd/../libparse/libparse.a /obj/sun4v/src/usr.sbin/ntp/ntpd/../libntp/libntp.a -lm -lmd -lrt /obj/sun4v/src/usr.sbin/ntp/ntpd/../libopts/libopts.a -lcrypto /obj/sun4v/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_pop_imp' /obj/sun4v/src/tmp/usr/lib/librt.so: undefined reference to `__pthread_cleanup_push_imp' *** Error code 1 Stop in /src/usr.sbin/ntp/ntpd. *** Error code 1 Stop in /src/usr.sbin/ntp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-18 04:20:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-18 04:20:22 - ERROR: failed to build world TB --- 2009-11-18 04:20:22 - 2457.84 user 495.07 system 3188.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 10:08:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A9BF106566C for ; Wed, 18 Nov 2009 10:08:50 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A9F518FC12 for ; Wed, 18 Nov 2009 10:08:49 +0000 (UTC) Received: by fxm27 with SMTP id 27so1014948fxm.3 for ; Wed, 18 Nov 2009 02:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vXdjAxzSksQXrbVRenZeMD3xvxXkSKhTH6+KepIt720=; b=WidmqDNDOaFk+hWn5NV2sMGZw49s2mDKomHAkrhytyuMn1K8pWCakhd4NAkaowOavk SNMR+siChRqVteF+gTOqYLsjQi8UXSfqTK2d9I0D2Ol5VYti09hlOL1Vjv0bkBsoa4rh Z9tYT+tVx4cZIAFB5ocycXvAngZp57trM2g3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SP1qY6mvBtWeoQr6U2C28efyHm9DbTS/EEXsOPUMSIY2Ve3+tPLLXxCN+2hHXylWza xE8lDRzBbdf9ZsHnS8CDOj1OKIKCiPU/q12l32iSRt1PSVbbMhuMOrrFJfwFMLYecvxo CSMpdOWru7eAwM1bBmKSR7kDGPFol9WG0Mogs= MIME-Version: 1.0 Received: by 10.239.140.66 with SMTP id w2mr1070566hbw.208.1258538928483; Wed, 18 Nov 2009 02:08:48 -0800 (PST) In-Reply-To: <4B02B4BB.30400@ish.com.au> References: <4B023061.7070203@ish.com.au> <4B02B4BB.30400@ish.com.au> Date: Wed, 18 Nov 2009 10:08:48 +0000 Message-ID: From: krad To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 10:08:50 -0000 2009/11/17 Aristedes Maniatis > On 17/11/09 9:14 PM, Ivan Voras wrote: > >> Aristedes Maniatis wrote: >> >>> Is it possible that this flag be set to YES in the FreeBSD 8.0 branch >>> before final release? >>> >> >> Certainly not. The release is around the corner. >> > > In that case, there are some other options: > > 1. Build the binaries that freebsd-update uses with this flag set. That > isn't the same thing as changing the flag in the ISOs of the official > FreeBSD 8.0 release. > > 2. Build logic into freebsd-update which detects that the user has > LOADER_ZFS_SUPPORT in src.conf, or else that it is trying to replace a > working /boot/loader with a 'defective' version without ZFS capability. I > had previously thought freebsd-update took hashes of all system files so it > knew which ones had changed and what to warn the user about, but I must have > misunderstood that. > > 3. Deprecate freebsd-update as the recommended way to upgrade FreeBSD > systems and put source updates back to the top recommended choices. I've > noticed that all recent release notices recommend freebsd-update. > > Possibly freebsd-update should be maintained as part of the release process > and not by someone at arm's length to the re team. In recent times it has > broken rebooting after an update twice: once because of the above issue, and > earlier when updating from 7.2 to 8.0-beta it was impossible to install a > new kernel, reboot and then install world. This wasn't a freebsd-update > specific issue (there is an incompatibility between new ZFS kernel modules > and old userland tools), but it will bite everyone using freebsd-update and > ZFS. > > I suggest there will be a fair few unhappy people when 8.0 is released and > people using ZFS for system files upgrade from 7.x. Then when 8.1 whips > around and people who followed instructions to boot from ZFS without a UFS > partition, will suffer a second round of pain. > > Ari Maniatis > > > > -- > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > _______________________________________________ > 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" > WHy not just build from source? From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 11:22:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C79BF106568B for ; Wed, 18 Nov 2009 11:22:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 816528FC12 for ; Wed, 18 Nov 2009 11:22:52 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1E7CF6D41C; Wed, 18 Nov 2009 11:22:51 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DD3F4844D2; Wed, 18 Nov 2009 12:22:50 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Daichi GOTO References: <20091116174933.4ab2354d.daichi@ongs.co.jp> <20091117103651.da7ceeb0.daichi@ongs.co.jp> Date: Wed, 18 Nov 2009 12:22:50 +0100 In-Reply-To: <20091117103651.da7ceeb0.daichi@ongs.co.jp> (Daichi GOTO's message of "Tue, 17 Nov 2009 10:36:51 +0900") Message-ID: <861vjwvzzp.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-emulation@FreeBSD.org, current@freebsd.org Subject: Re: FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 11:22:52 -0000 Daichi GOTO writes: > Enabled both ACPI and IO ACPI ITYM "I/O APIC". HTH, HAND! DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 11:30:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1034106566B for ; Wed, 18 Nov 2009 11:30:00 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B1A2B8FC12 for ; Wed, 18 Nov 2009 11:30:00 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 9BBF06D450; Wed, 18 Nov 2009 11:29:59 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 82440844CC; Wed, 18 Nov 2009 12:29:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gonzalo Nemmi References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> Date: Wed, 18 Nov 2009 12:29:59 +0100 In-Reply-To: <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> (Gonzalo Nemmi's message of "Tue, 17 Nov 2009 21:05:42 -0300") Message-ID: <86ws1oul3c.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:30:01 -0000 Gonzalo Nemmi writes: > See Julian.. as the saying goes, if you want to help a hungry men, don't > give him fish .. teach him how to fish .. so in that order of things let's > do this, try and do what you are, ironically, advising me to do and tell= me > how it goes ... how the system works with only those 2 modules. There's another saying: if you want help, don't shit on the people trying to help you. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 11:30:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA0B1065679 for ; Wed, 18 Nov 2009 11:30:29 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by mx1.freebsd.org (Postfix) with ESMTP id E168C8FC08 for ; Wed, 18 Nov 2009 11:30:28 +0000 (UTC) Received: by ywh8 with SMTP id 8so961243ywh.3 for ; Wed, 18 Nov 2009 03:30:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.159.1 with SMTP id l1mr3353368ano.151.1258543828052; Wed, 18 Nov 2009 03:30:28 -0800 (PST) In-Reply-To: <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> Date: Wed, 18 Nov 2009 12:30:28 +0100 Message-ID: <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> From: Olivier Smedts To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:30:29 -0000 2009/11/18 Gonzalo Nemmi : > On Tue, Nov 17, 2009 at 9:08 PM, Kevin Oberman wrote: > >> > From: Gonzalo Nemmi >> > Date: Tue, 17 Nov 2009 20:43:27 -0200 >> > Sender: owner-freebsd-current@freebsd.org >> > >> > On Tuesday 17 November 2009 8:30:41 pm Poul-Henning Kamp wrote: >> > > Check out the scripts in src/tools/tools/build_option_survey/ >> > > >> > > The result looked like this on stable-7 some time ago: >> > > >> > > =A0 =A0 http://phk.freebsd.dk/misc/stable7_build_options/ >> > >> > >> > no effect .. >> > Interesting ... >> > Thanks for the link Mr. Poul-Henning Kamp >> >> I can state that several of the src.conf options in 8.0 don't work and >> some will break the build. There is an open PR that has a fix to >> Makefile.inc1 for at least some of the problems. >> >> That said, building a new world without telnet does not delete the >> existing binaries, libs, header files, etc. It just causes them not to >> be built again. Further, delete-old will not delete them. But someone (you, me...) can file a PR to add them to OLD_FILES when WITHOUT_TELNET is set to yes, like it's done for some other WITHOUT_ options. > > I can confirm that. Telnet creation date is predate that of the binaries > created by buildworld > > >> If you build with some parts of the base system removed in this manner, >> you really need to go in and remove the old stuff by hand. It won't be >> created arain. >> > > Thanks for the advise Kevin! > > >> N.B. I have not tried WITHOUT_TELNET=3D, so I can't swear that ti works.= I >> build WITHOUT_OPENSSH and WITHOUT_BIND as I use the ports with >> OVERWRITE_BASE. and WITHOUT_BIND works fine. WITHOUT_OPENSSH requires >> the patches mentions above for Makefile.inc1 (thanks to bf for those). >> -- >> R. Kevin Oberman, Network Engineer >> Energy Sciences Network (ESnet) >> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >> E-mail: oberman@es.net =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Phone: +1 510 = 486-8634 >> Key fingerprint:059B 2DDF 031C 9BA3 14A4 =A0EADA 927D EBB3 987B 3751 >> > > Best Regards > Gonzalo Nemmi > _______________________________________________ > 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= " > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 11:32:58 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24D851065670; Wed, 18 Nov 2009 11:32:58 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id D657A8FC19; Wed, 18 Nov 2009 11:32:56 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 17F546D450; Wed, 18 Nov 2009 11:32:56 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DFDC1844CC; Wed, 18 Nov 2009 12:32:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ben Kelly References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> <4B034899.9090408@FreeBSD.org> <4B036BD3.4020900@FreeBSD.org> <568A6428-A2DD-49D4-B043-455273A7902E@wanderview.com> Date: Wed, 18 Nov 2009 12:32:55 +0100 In-Reply-To: <568A6428-A2DD-49D4-B043-455273A7902E@wanderview.com> (Ben Kelly's message of "Tue, 17 Nov 2009 22:46:24 -0500") Message-ID: <86skccukyg.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, Doug Barton Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:32:58 -0000 Ben Kelly writes: > From the log for r88893 of /usr/src/sys/conf/kern.pre.mk I think its > intended that the module variables are related to ports in some way: > > Move initialization of the MKMODULESENV envorinoment to kern.pre.mk > from kern.post.mk so port makefiles can augment it. Ports, not ports. I mean, ports as in "I was bored this weekend and ported FreeBSD to MMIX", not as in "I was bored this weekend and created a port for an MMIX virtual machine". DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 12:05:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E26B1065679 for ; Wed, 18 Nov 2009 12:05:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 27AF88FC18 for ; Wed, 18 Nov 2009 12:05:07 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 96FCD46B64; Wed, 18 Nov 2009 07:05:06 -0500 (EST) Date: Wed, 18 Nov 2009 12:05:06 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4B02BDBE.6050307@quip.cz> Message-ID: References: <4B023061.7070203@ish.com.au> <4B02B4BB.30400@ish.com.au> <4B02BDBE.6050307@quip.cz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Aristedes Maniatis Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 12:05:07 -0000 On Tue, 17 Nov 2009, Miroslav Lachman wrote: >> Possibly freebsd-update should be maintained as part of the release process >> and not by someone at arm's length to the re team. In recent times it has >> broken rebooting after an update twice: once because of the above issue, >> and earlier when updating from 7.2 to 8.0-beta it was impossible to install >> a new kernel, reboot and then install world. This wasn't a freebsd-update >> specific issue (there is an incompatibility between new ZFS kernel modules >> and old userland tools), but it will bite everyone using freebsd-update and >> ZFS. > > If we are talking about freebsd-update... It would be nice if freebsd-update > leave old kernel available in /boot/ as with source upgrade > (/boot/kernel.old) at least until second reboot (in case of upgrade), > because if new kernel failed to boot after first reboot, then the machine > become unbootable without some kind of LiveFS media. This change was made in August, and I agree it was a very good idea: r196392 | simon | 2009-08-19 21:47:31 +0100 (Wed, 19 Aug 2009) | 17 lines Add support for backing up the old kernel when installing a new kernel using freebsd-update. This applies to using freebsd-update in "upgrade mode" and normal freebsd-update on a security branch. The backup kernel will be written to /boot/kernel.old, if the directory does not exist, or the directory was created by freebsd-update in a previous backup. Otherwise freebsd-update will generate a new directory name for use by the backup. By default symbol files are not backed up to save diskspace and avoid filling up the root partition. This feature is fully configurable in the freebsd-update config file, but defaults to enabled. MFC after: 1 week (stable/7) Reviewed by: cperciva Approved by: re (kib) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 12:19:28 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928C7106566C for ; Wed, 18 Nov 2009 12:19:28 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD228FC19 for ; Wed, 18 Nov 2009 12:19:27 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nAICJHbI071873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 12:19:17 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Ben Kelly In-Reply-To: <86skccukyg.fsf@ds4.des.no> Date: Wed, 18 Nov 2009 07:19:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2F1FD10F-91BB-41A1-919D-531A342C8113@wanderview.com> References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> <4B034899.9090408@FreeBSD.org> <4B036BD3.4020900@FreeBSD.org> <568A6428-A2DD-49D4-B043-455273A7902E@wanderview.com> <86skccukyg.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-current@FreeBSD.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:19:28 -0000 On Nov 18, 2009, at 6:32 AM, Dag-Erling Sm=F8rgrav wrote: > Ben Kelly writes: >> =46rom the log for r88893 of /usr/src/sys/conf/kern.pre.mk I think = its >> intended that the module variables are related to ports in some way: >>=20 >> Move initialization of the MKMODULESENV envorinoment to kern.pre.mk >> from kern.post.mk so port makefiles can augment it. >=20 > Ports, not ports. I mean, ports as in "I was bored this weekend and > ported FreeBSD to MMIX", not as in "I was bored this weekend and = created > a port for an MMIX virtual machine". Ah. Thanks for the clarification. That does make more sense. For some = reason I was thinking these variables might be relevant to ports like = x11/nvidia-driver, etc. Sorry for the confusion. - Ben= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 12:28:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AB2F106568F for ; Wed, 18 Nov 2009 12:28:43 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id F139D8FC14 for ; Wed, 18 Nov 2009 12:28:42 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nAICSeLw072054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 12:28:40 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <19e9a5dc0911171944q5d15dc96t83ecd53befb07621@mail.gmail.com> Date: Wed, 18 Nov 2009 07:28:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0EB6E028-BA0A-48F1-AE7B-9F5E0A97B432@wanderview.com> References: <200911172021.16848.gnemmi@gmail.com> <41D86F39-D98A-4195-8345-765E0F742FAE@wanderview.com> <19e9a5dc0911171614l42f4c90ci2abce9982727ef61@mail.gmail.com> <4B033E22.3060700@FreeBSD.org> <8727F2A4-B830-43EE-BB9B-A17798374C00@wanderview.com> <4B034899.9090408@FreeBSD.org> <19e9a5dc0911171944q5d15dc96t83ecd53befb07621@mail.gmail.com> To: Gonzalo Nemmi X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:28:43 -0000 On Nov 17, 2009, at 10:44 PM, Gonzalo Nemmi wrote: > On Tue, Nov 17, 2009 at 10:59 PM, Ben Kelly = wrote: >=20 >>=20 >> On Nov 17, 2009, at 8:06 PM, Doug Barton wrote: >>=20 >>> Ben Kelly wrote: >>>> It seems there are some left over bits then. I have this in >> /usr/src/sys/modules/Makefile: >>>>=20 >>>> .for reject in ${WITHOUT_MODULES} >>>> SUBDIR:=3D ${SUBDIR:N${reject}} >>>> .endfor >>>=20 >>> Well it seems my search was not exhaustive. >>>=20 >>> My recommendation then would be to file a src PR so that someone can >>> look into it. :) >>=20 >> I've opened a doc PR for the bad example in the handbook and a conf = PR for >> the patch to make WITHOUT_MODULES work from the kernel config file = using >> makeoptions. I haven't gotten PR numbers back from the system yet. >>=20 >> - Ben_______________________________________________ >=20 >=20 > So, basically .. not only man make.conf and the handbook examples are = wrong > .. WITHOUT_MODULES doesn't actually work :s >=20 > Thanks a lot for your research, testing, PR and patches Ben ! > Please, should you be able to, I would like to know the PR number so I = can > follow it. > Hope your patch makes it in and WITHOUT_MODULES works as expected :) No problem. Just to clarify, though. The content of man make.conf looks correct to = me and the variable did work if you put it in /etc/make.conf. The only = issues I saw were the example in the handbook and the failure of = makeoptions in the kernel config file. I do think you could get a number of the modules in your original list = excluded if you specified them differently: WITHOUT_MODULES=3Dfirewire bwi bce bfe iwi iwn zfs Basically remove the dev/ prefix you have on some of them. Hope that helps. - Ben= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 11:44:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5872A1065698 for ; Wed, 18 Nov 2009 11:44:13 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 18B348FC2B for ; Wed, 18 Nov 2009 11:44:12 +0000 (UTC) Received: by yxe1 with SMTP id 1so935846yxe.3 for ; Wed, 18 Nov 2009 03:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ucuUFQf4aDg8yGkfmEkfsEqbQRLMy9I+1ULmqHW4Aqs=; b=deJfwoovgZqTc7ijTYhNJA21sskEbgieG3eG2WV87Y9kYeBe8pOdMG/+qO0Yw0VvJm +FVwYkN759FHrTzMguZHfwbLZ9HrROfX8osrNnfiorI4G7VSbZg/Fl7B9p4nac1UgHLJ DPrlPhhsG4GvAiVaE+rvfxay6NY6g6lLdWg7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iWlwB5FvWn49jq+oYCF9qFCte1P9gwGmMpiTFdNWK0xBfSDoCwSjGNcc7zBR9Ml1iT jcv6uAHRlGHyKHXZOM82CxnzNwmyLBnOy/gM0vgm+CE9+MKwww3APDYtN32mr1+AtN7y icIMUdZszRjh31Aw9EwU4DbeHKsY0E8efQ9vA= MIME-Version: 1.0 Received: by 10.101.208.31 with SMTP id k31mr2523216anq.70.1258544652291; Wed, 18 Nov 2009 03:44:12 -0800 (PST) Date: Wed, 18 Nov 2009 13:44:12 +0200 Message-ID: From: Dan Naumov To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 18 Nov 2009 12:30:31 +0000 Subject: RE: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 11:44:13 -0000 > WHy not just build from source? Because expecting users to build from source to install or update their systems in the year 2009 is an outdated concept, this is why we have freebsd-update in the first place. Sincerely, Dan Naumov From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 12:31:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7A9C1065693 for ; Wed, 18 Nov 2009 12:31:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7FCF88FC1F for ; Wed, 18 Nov 2009 12:31:14 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1BD7146B65; Wed, 18 Nov 2009 07:31:14 -0500 (EST) Date: Wed, 18 Nov 2009 12:31:12 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Olivier Smedts In-Reply-To: <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> Message-ID: References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Gonzalo Nemmi Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:31:14 -0000 On Wed, 18 Nov 2009, Olivier Smedts wrote: > But someone (you, me...) can file a PR to add them to OLD_FILES when > WITHOUT_TELNET is set to yes, like it's done for some other WITHOUT_ > options. If it's done for other WITHOUT_ options, it's not obvious to me. I thought that, to date, OLD_FILES was used solely for files no longer built at all that were at one time previously built, not for conditional building. I'm not aware of any support in the source tree for scrubbing conditionally built files from the target tree that aren't installable with the current build options. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 12:51:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D15C8106568B for ; Wed, 18 Nov 2009 12:51:30 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6238FC23 for ; Wed, 18 Nov 2009 12:51:30 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mail.0x20.net (Postfix) with ESMTP id BB2B934B55 for ; Wed, 18 Nov 2009 13:34:35 +0100 (CET) Received: from i011-63.fin-nrw.de (i011-63.fin-nrw.de [193.109.238.130]) by 0x20.net (Horde MIME library) with HTTP; Wed, 18 Nov 2009 13:34:35 +0100 Message-ID: <20091118133435.w5j1ooxr4k0cogoo@0x20.net> X-Priority: 3 (Normal) Date: Wed, 18 Nov 2009 13:34:35 +0100 From: Lars Engels To: freebsd-current@freebsd.org References: <20091116174933.4ab2354d.daichi@ongs.co.jp> <20091117103651.da7ceeb0.daichi@ongs.co.jp> <861vjwvzzp.fsf@ds4.des.no> In-Reply-To: <861vjwvzzp.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_5c8fzj5y9og0"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Subject: Re: FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 12:51:30 -0000 This message is in MIME format and has been PGP signed. --=_5c8fzj5y9og0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Dag-Erling Sm=C3=B8rgrav : > Daichi GOTO writes: >> Enabled both ACPI and IO ACPI > > ITYM "I/O APIC". HTH, HAND! > > DES YMMD! --=20 LME --=_5c8fzj5y9og0 Content-Type: application/pgp-signature Content-Description: PGP Digital Signature Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAksD6dsACgkQKc512sD3afhMcQCfSxZ1/6Jb2sDTkcWgcYekFs0j 1n8AmwYhMTiHQB/XrBhpWoU2PWDyjW46 =6dl2 -----END PGP SIGNATURE----- --=_5c8fzj5y9og0-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 12:53:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875891065670 for ; Wed, 18 Nov 2009 12:53:43 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 21F878FC15 for ; Wed, 18 Nov 2009 12:53:43 +0000 (UTC) Received: from [195.4.92.25] (helo=15.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NAk2Y-0005YD-1U; Wed, 18 Nov 2009 13:53:42 +0100 Received: from tfb03.t.pppool.de ([89.55.251.3]:63603 helo=ernst.jennejohn.org) by 15.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NAk2X-0004Zq-Qc; Wed, 18 Nov 2009 13:53:42 +0100 Date: Wed, 18 Nov 2009 13:53:40 +0100 From: Gary Jennejohn To: Dan Naumov Message-ID: <20091118135340.522fa36a@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:53:43 -0000 On Wed, 18 Nov 2009 13:44:12 +0200 Dan Naumov wrote: > > WHy not just build from source? > > Because expecting users to build from source to install or update > their systems in the year 2009 is an outdated concept, this is why we > have freebsd-update in the first place. > This is such a load of BS I could fertilize 100 acres with it. In this day of inexpensive computers with fast mulit-core CPUs and gigabytes of memory this argument is completely lame. Fifteen years ago I would have agreed, because it took days to build world and the kernel. Been there, done that. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 13:10:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C7A106566B for ; Wed, 18 Nov 2009 13:10:25 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3BBB28FC1F for ; Wed, 18 Nov 2009 13:10:24 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 30B3319E023; Wed, 18 Nov 2009 14:10:23 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id D07B019E019; Wed, 18 Nov 2009 14:10:20 +0100 (CET) Message-ID: <4B03F23C.4020308@quip.cz> Date: Wed, 18 Nov 2009 14:10:20 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 MIME-Version: 1.0 To: Robert Watson References: <4B023061.7070203@ish.com.au> <4B02B4BB.30400@ish.com.au> <4B02BDBE.6050307@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Aristedes Maniatis Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 13:10:25 -0000 Robert Watson wrote: > > On Tue, 17 Nov 2009, Miroslav Lachman wrote: [...] >> If we are talking about freebsd-update... It would be nice if >> freebsd-update leave old kernel available in /boot/ as with source >> upgrade (/boot/kernel.old) at least until second reboot (in case of >> upgrade), because if new kernel failed to boot after first reboot, >> then the machine become unbootable without some kind of LiveFS media. > > This change was made in August, and I agree it was a very good idea: > > r196392 | simon | 2009-08-19 21:47:31 +0100 (Wed, 19 Aug 2009) | 17 lines > > Add support for backing up the old kernel when installing a new kernel > using freebsd-update. This applies to using freebsd-update in "upgrade > mode" and normal freebsd-update on a security branch. > > The backup kernel will be written to /boot/kernel.old, if the directory > does not exist, or the directory was created by freebsd-update in a > previous backup. Otherwise freebsd-update will generate a new directory > name for use by the backup. By default symbol files are not backed up > to save diskspace and avoid filling up the root partition. > > This feature is fully configurable in the freebsd-update config file, > but defaults to enabled. > > MFC after: 1 week (stable/7) > Reviewed by: cperciva > Approved by: re (kib) Thank you for the clarification! I am glad it is committed. note: I am looking in to 7-STABLE (one week old) and it seems it was not MFCed yet. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 13:51:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA56106566B; Wed, 18 Nov 2009 13:51:00 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id EE1BE8FC1A; Wed, 18 Nov 2009 13:50:59 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAIDorqT016998 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 08:50:54 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Wed, 18 Nov 2009 07:50:47 -0600 Message-Id: <1258552247.2303.75.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 13:51:00 -0000 On Wed, 2009-11-18 at 01:17 +0100, Emil Smolenski wrote: > On Tue, 17 Nov 2009 23:33:41 +0100, Robert Noland > wrote: > > >> Should I file a PR? I would > >> like to help in debugging it (however my skills in low-level C aren't > >> strong enough to do it on my own). > > > Ok, the first thing I would like to see is "zdb -uuu". > > # zdb -uuu pgpool > Segmentation fault: 11 (core dumped) Ok, this is disturbing... It works fine for me on -CURRENT / amd64 and reports the root block pointer, which is what we need to locate the MOS. robert. > # zdb > pgpool > version=13 > name='pgpool' > state=0 > txg=439808 > pool_guid=3920915583055727184 > hostid=1642959122 > hostname='unset' > vdev_tree > type='root' > id=0 > guid=3920915583055727184 > children[0] > type='disk' > id=0 > guid=5859773264564918193 > path='/dev/da0' > whole_disk=0 > metaslab_array=23 > metaslab_shift=35 > ashift=9 > asize=4500799356928 > is_log=0 > DTL=260 > > > I don't see an > > obvious issue with single disk reads. My own setup uses 2 x 1TB > > currently. Failing to read the MOS is basically the first read attempt > > from the pool, in fact it is the read that attempts to mount the pool. > -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:01:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF696106566C; Wed, 18 Nov 2009 14:01:55 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6DA8FC22; Wed, 18 Nov 2009 14:01:55 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 964A26D41B; Wed, 18 Nov 2009 14:01:54 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 69BC0844E9; Wed, 18 Nov 2009 15:01:54 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> Date: Wed, 18 Nov 2009 15:01:54 +0100 In-Reply-To: (Robert Watson's message of "Wed, 18 Nov 2009 12:31:12 +0000 (GMT)") Message-ID: <866398ue25.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , freebsd-current@freebsd.org, Gonzalo Nemmi Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:01:55 -0000 Robert Watson writes: > Olivier Smedts writes: > > But someone (you, me...) can file a PR to add them to OLD_FILES when > > WITHOUT_TELNET is set to yes, like it's done for some other WITHOUT_ > > options. > If it's done for other WITHOUT_ options, it's not obvious to me. tools/build/mk/OptionalObsoleteFiles.inc Poor placement IMHO, we shouldn't have dependencies from src into tools. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:07:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C76106566C for ; Wed, 18 Nov 2009 14:07:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DEC0C8FC14 for ; Wed, 18 Nov 2009 14:07:34 +0000 (UTC) Received: from [192.168.2.101] (host217-43-176-60.range217-43.btcentralplus.com [217.43.176.60]) by cyrus.watson.org (Postfix) with ESMTPSA id E920A46B5B; Wed, 18 Nov 2009 09:07:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: <866398ue25.fsf@ds4.des.no> Date: Wed, 18 Nov 2009 14:07:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <56A320F3-A099-4DE6-84EE-7F9CCE3A5CB4@FreeBSD.org> References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> <866398ue25.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1077) Cc: Olivier Smedts , freebsd-current@freebsd.org, Gonzalo Nemmi Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:07:35 -0000 On 18 Nov 2009, at 14:01, Dag-Erling Sm=F8rgrav wrote: > Robert Watson writes: >> Olivier Smedts writes: >>> But someone (you, me...) can file a PR to add them to OLD_FILES when >>> WITHOUT_TELNET is set to yes, like it's done for some other WITHOUT_ >>> options. >> If it's done for other WITHOUT_ options, it's not obvious to me. >=20 > tools/build/mk/OptionalObsoleteFiles.inc >=20 > Poor placement IMHO, we shouldn't have dependencies from src into = tools. Its obscure location explains why it doesn't work. :-) Maybe it should = be src/OptionalFiles.inc? That said, it still sounds like a significant = maintenance problem to me: we have a lot of WITHOUT_ options, and they = may have non-trivial interactions... Robert= From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:10:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84632106566B; Wed, 18 Nov 2009 14:10:16 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 40EF78FC1F; Wed, 18 Nov 2009 14:10:16 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 6E2AC6D41B; Wed, 18 Nov 2009 14:10:15 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 4E583844E9; Wed, 18 Nov 2009 15:10:15 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Robert N. M. Watson" References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> <866398ue25.fsf@ds4.des.no> <56A320F3-A099-4DE6-84EE-7F9CCE3A5CB4@FreeBSD.org> Date: Wed, 18 Nov 2009 15:10:15 +0100 In-Reply-To: <56A320F3-A099-4DE6-84EE-7F9CCE3A5CB4@FreeBSD.org> (Robert N. M. Watson's message of "Wed, 18 Nov 2009 14:07:32 +0000") Message-ID: <86y6m3udo8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , freebsd-current@freebsd.org, Gonzalo Nemmi Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:10:16 -0000 "Robert N. M. Watson" writes: > Its obscure location explains why it doesn't work. :-) Maybe it should > be src/OptionalFiles.inc? That said, it still sounds like a > significant maintenance problem to me: we have a lot of WITHOUT_ > options, and they may have non-trivial interactions... Agreed. It's full of stuff like #.if ${MK_OPENSSH} =3D=3D no # to be filled in #.endif (35 to be exact) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:17:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E18106566B for ; Wed, 18 Nov 2009 14:17:12 +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 BDD418FC08 for ; Wed, 18 Nov 2009 14:17:11 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NAlLK-0002sg-FX>; Wed, 18 Nov 2009 15:17:10 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NAlLK-00053V-E0>; Wed, 18 Nov 2009 15:17:10 +0100 Message-ID: <4B04020C.3080000@zedat.fu-berlin.de> Date: Wed, 18 Nov 2009 14:17:48 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <20091118135340.522fa36a@ernst.jennejohn.org> In-Reply-To: <20091118135340.522fa36a@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current , Dan Naumov Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 14:17:12 -0000 Gary Jennejohn wrote: > On Wed, 18 Nov 2009 13:44:12 +0200 > Dan Naumov wrote: > >>> WHy not just build from source? >> Because expecting users to build from source to install or update >> their systems in the year 2009 is an outdated concept, this is why we >> have freebsd-update in the first place. >> > > This is such a load of BS I could fertilize 100 acres with it. > > In this day of inexpensive computers with fast mulit-core CPUs and > gigabytes of memory this argument is completely lame. > > Fifteen years ago I would have agreed, because it took days to build > world and the kernel. Been there, done that. > > --- > Gary Jennejohn Been there, did it, too. Fools, conceptually compromised by Microsofts closed-binary-strategy, often complain about 'why compiling, it is an outdated concept ...'. It is, simply in my opinion, a helpless selfdefense: they do not understand much about operating systems (me, too) and never try to understand the concept behind (me not). But today, having sophisticated binary update facilities, it seems to speed up a worse development: many companies save the computer-scientist to maintain their stuff - because they have a bunch of cheap fools 'fertilizing the acres of foolsness' and pretending being the master of the puppets by hitting an 'update-key' and everythings works magically ... Sorry being off-topic. From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:25:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 501161065676 for ; Wed, 18 Nov 2009 14:25:45 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8270C8FC19 for ; Wed, 18 Nov 2009 14:25:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA09297; Wed, 18 Nov 2009 16:25:20 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B0403D0.3090101@icyb.net.ua> Date: Wed, 18 Nov 2009 16:25:20 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Kai Gallasch , "S.N.Grigoriev" References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> <4AFD140D.7010407@icyb.net.ua> <20091113144804.2c0fb90f@orwell.free.de> <4AFD655E.5020801@icyb.net.ua> <20091114022121.217dd831@orwell.free.de> <4AFE7A32.7060203@icyb.net.ua> <4B025FA9.7020003@icyb.net.ua> <20091117165304.01676555@orwell.free.de> In-Reply-To: <20091117165304.01676555@orwell.free.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 14:25:45 -0000 Kai, Serguey, thank you very much for the testing! This has been an invaluable help. I am now trying to narrow down possible causes of the issue and to come up with the most efficient patch. If/when you have a chance could you please test the following changes? The patches are against mainline source tree (that is, not against previous patch(es)). So, please first try *only* this patch: diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 44b71f3..33b8c2a 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -2981,6 +2981,7 @@ setpte: * Map the superpage. */ pde_store(pde, PG_PS | newpde); + pmap_invalidate_range(pmap, trunc_2mpage(va), trunc_2mpage(va) + NBPDR); pmap_pde_promotions++; CTR2(KTR_PMAP, "pmap_promote_pde: success for va %#lx" Most likely this will fix the buildworld scenario. But I am not sure if it will fix ZFS scenario. If it does - then great, if not, please apply the following patch in addition to the previous one and test again: diff --git a/sys/amd64/amd64/mca.c b/sys/amd64/amd64/mca.c index d291d00..d6547a3 100644 --- a/sys/amd64/amd64/mca.c +++ b/sys/amd64/amd64/mca.c @@ -43,6 +43,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -465,6 +466,8 @@ void mca_init(void) { uint64_t mcg_cap; + uint64_t ctl; + int skip; int i; /* MCE is required. */ @@ -482,14 +485,22 @@ mca_init(void) wrmsr(MSR_MCG_CTL, MCG_CTL_ENABLE); for (i = 0; i < (mcg_cap & MCG_CAP_COUNT); i++) { - /* - * Enable logging of all errors. For P6 - * processors, MC0_CTL is always enabled. - * - * XXX: Better CPU test needed here? - */ - if (!(i == 0 && (cpu_id & 0xf00) == 0x600)) - wrmsr(MSR_MC_CTL(i), 0xffffffffffffffffUL); + /* By default enable logging of all errors. */ + ctl = 0xffffffffffffffffUL; + skip = 0; + if (cpu_vendor_id == CPU_VENDOR_INTEL) { + /* For P6 MC0_CTL is always enabled. */ + if (i == 0 && CPUID_TO_FAMILY(cpu_id) == 0x6) + skip = 1; + } else if (cpu_vendor_id == CPU_VENDOR_AMD) { + /* BKDG for Family 10h: unset GartTblWkEn. */ + if (i == 4 && CPUID_TO_FAMILY(cpu_id) >= 0xf) { + ctl &= ~(1UL << 10); + } + } + + if (!skip) + wrmsr(MSR_MC_CTL(i), ctl); /* Clear all errors. */ wrmsr(MSR_MC_STATUS(i), 0); -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:34:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB220106568F for ; Wed, 18 Nov 2009 14:34:51 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0268FC1A for ; Wed, 18 Nov 2009 14:34:51 +0000 (UTC) Received: by fxm27 with SMTP id 27so1299415fxm.3 for ; Wed, 18 Nov 2009 06:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=x8NfuleJ5rB3/Jpwy1vc/6IFdcRo6OWLlnZYKkiPzw4=; b=KTfYLnE5ZsCN2oQ2HS3SuETr7KVeiXzwUUb+p8u3Y/26CpXjEh62ij5K0QWhh+qY9P uyTbGxH4Y9Oh+4EV9TMjHxUjugpXKM6Qp085fzmm9L3k6gD6hWWTa2BZjjGu5qpki4Ll mzoyveK40IdvgB7ZOSmcsOeyALG/wn/G4R9UY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=m7JEyh4oSFpUwGiu3g21HKRHe94KxGGNgdPKbkhWfvIjmB38x4jTe+45SHqcsAGNCM xXggOYOdRIK5NEcAXkQJyvDfCZCkS6AeFdpTPdcQvxSXtuPX9lhInl6teMwX1ZFoTnjd GxowEuxXZjq3Z18ZwwkgQ110CkT/uvNI8pak8= MIME-Version: 1.0 Received: by 10.102.235.5 with SMTP id i5mr5250726muh.36.1258554890281; Wed, 18 Nov 2009 06:34:50 -0800 (PST) In-Reply-To: References: <200911172027.15749.gnemmi@gmail.com> Date: Wed, 18 Nov 2009 11:34:50 -0300 Message-ID: <19e9a5dc0911180634h2484d4d7seedc1611c7e218f2@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:34:51 -0000 On Wed, Nov 18, 2009 at 7:22 AM, Eitan Adler wrote: > On Wed, Nov 18, 2009 at 12:27 AM, Gonzalo Nemmi wrote: > > WITHOUT_FLOOPY=yes > > Just a note - are you sure this is correct? > Dear Eitan: Up to a second ago I was .. now you are making me have second toughts .. I'm using that line on my notebook, wich doesn't have a floopy drive ... Would you advice me not to use that line, and could you tell me why? (really honest question ... I mean maybe WITHOUT_FLOOPY=yes interferes with something else that I'm not aware of) Thanks for your answer Best Regards From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:35:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80DA51065693 for ; Wed, 18 Nov 2009 14:35:06 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 387A88FC19 for ; Wed, 18 Nov 2009 14:35:05 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 738B819E027; Wed, 18 Nov 2009 15:35:04 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 44F1119E023; Wed, 18 Nov 2009 15:35:00 +0100 (CET) Message-ID: <4B040613.4030705@quip.cz> Date: Wed, 18 Nov 2009 15:34:59 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 MIME-Version: 1.0 To: Olivier Smedts References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> In-Reply-To: <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Gonzalo Nemmi Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:35:06 -0000 Olivier Smedts wrote: > 2009/11/18 Gonzalo Nemmi: >> On Tue, Nov 17, 2009 at 9:08 PM, Kevin Oberman wrote: >> >>>> From: Gonzalo Nemmi >>>> Date: Tue, 17 Nov 2009 20:43:27 -0200 >>>> Sender: owner-freebsd-current@freebsd.org >>>> >>>> On Tuesday 17 November 2009 8:30:41 pm Poul-Henning Kamp wrote: >>>>> Check out the scripts in src/tools/tools/build_option_survey/ >>>>> >>>>> The result looked like this on stable-7 some time ago: >>>>> >>>>> http://phk.freebsd.dk/misc/stable7_build_options/ >>>> >>>> >>>> no effect .. >>>> Interesting ... >>>> Thanks for the link Mr. Poul-Henning Kamp >>> >>> I can state that several of the src.conf options in 8.0 don't work and >>> some will break the build. There is an open PR that has a fix to >>> Makefile.inc1 for at least some of the problems. >>> >>> That said, building a new world without telnet does not delete the >>> existing binaries, libs, header files, etc. It just causes them not to >>> be built again. Further, delete-old will not delete them. > > But someone (you, me...) can file a PR to add them to OLD_FILES when > WITHOUT_TELNET is set to yes, like it's done for some other WITHOUT_ > options. It could be *dangerous* to automatically delete files based on WITHOUT_ settings in src.conf. If somebody set WITHOUT_OPENSSH and have it built and replaced by ssh from ports with OPENSSH_OVERWRITE_BASE, then your proposed magic will delete this ssh as well. So the machine ends without any ssh even if there should be ssh from ports! Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:39:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B27C31065672 for ; Wed, 18 Nov 2009 14:39:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 733E88FC0C for ; Wed, 18 Nov 2009 14:39:26 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 98CD36D41B; Wed, 18 Nov 2009 14:39:25 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 778CF844E9; Wed, 18 Nov 2009 15:39:25 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gonzalo Nemmi References: <200911172027.15749.gnemmi@gmail.com> <19e9a5dc0911180634h2484d4d7seedc1611c7e218f2@mail.gmail.com> Date: Wed, 18 Nov 2009 15:39:25 +0100 In-Reply-To: <19e9a5dc0911180634h2484d4d7seedc1611c7e218f2@mail.gmail.com> (Gonzalo Nemmi's message of "Wed, 18 Nov 2009 11:34:50 -0300") Message-ID: <86lji3ucbm.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:39:26 -0000 Gonzalo Nemmi writes: > Would you advice me not to use that line, and could you tell me why? > (really honest question ... I mean maybe WITHOUT_FLOOPY=3Dyes interferes > with something else that I'm not aware of) I can guarantee you that WITHOUT_FLOOPY will not interfere, nor indeed interact, with anything whatsoever :P DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:47:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0855F1065695 for ; Wed, 18 Nov 2009 14:47:21 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7578FC0A for ; Wed, 18 Nov 2009 14:47:20 +0000 (UTC) Received: by bwz5 with SMTP id 5so1391506bwz.3 for ; Wed, 18 Nov 2009 06:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=pdMhh7qlzufPTkOmS6oODc3GzbWw+EY9LP123zqFQTA=; b=gUtjdQCnM5+rISBCURgSbNaGOSy+Ouv0yEmL/L0tGqw7Abx1FTiM0Aa5+FkXxboZMy VvxAPh8/ins5FKiuUTkG3Ua4Jfbq0EdquYu9mT4ix+xJNwQ4cMsEfRgmG9Eke56q8ZSu ukm3R+su05QKnS/MyHxUCctIBg+UBpmzmOQY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nXnisDwikoH0iPMqxHJNqsRUj8MY9ErHLlzoVHG7SYtoTaGZsKcQhlXu5zVFcXPt0K MJgOpUkIWK79FU9ZDbsFfabO69jl8ikUdaIdvivUfZqQRdo+DQ5l269a0WAve8yhZFNL 8vEsgOrJxDiuj/tveaP7TY+wy3vDAGVZKWJI8= MIME-Version: 1.0 Received: by 10.103.86.9 with SMTP id o9mr802500mul.4.1258555639380; Wed, 18 Nov 2009 06:47:19 -0800 (PST) In-Reply-To: <86ws1oul3c.fsf@ds4.des.no> References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> <86ws1oul3c.fsf@ds4.des.no> Date: Wed, 18 Nov 2009 11:47:19 -0300 Message-ID: <19e9a5dc0911180647g45a62a6do65450535f17b3947@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:47:21 -0000 2009/11/18 Dag-Erling Sm=F8rgrav > Gonzalo Nemmi writes: > > See Julian.. as the saying goes, if you want to help a hungry men, don'= t > > give him fish .. teach him how to fish .. so in that order of things > let's > > do this, try and do what you are, ironically, advising me to do and te= ll > me > > how it goes ... how the system works with only those 2 modules. > > There's another saying: if you want help, don't shit on the people > trying to help you. > > DES > It's funny ... sound a lot like a vulgar version of "don't bite the hand that feeds" .. Anyways .. read all my mails in thread and you'll realize that I never did it. But just in case .. if that very same hand is used to slap me .. I will bit= e it without a second thought .. and given hand will probably be left unsuable. Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 15:02:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2F69106568D for ; Wed, 18 Nov 2009 15:02:33 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2888FC14 for ; Wed, 18 Nov 2009 15:02:33 +0000 (UTC) Received: by fxm27 with SMTP id 27so1330544fxm.3 for ; Wed, 18 Nov 2009 07:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=rZvM9lO36u4cSHDdzcED+zyP9e9OSTU/hNJG9cgihK4=; b=T06AKAJqfnd1LvUs3+LNjwpmqOC04ZZYec+RzqqNQhMKM87MQ/7792Aw0v7uFHceUw D1EJPm48TSotoGOuRrvd+ZE/HlkoXsOSEIXsHg6yeK0Ev/Z8b8VFAmDqzHIw3iJMn2D9 QgguVHknwH9yX7wJxcorDW3mJ3LF2EqAHQ+L4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dlZ4IEfDeJ/fErASassSIXqRpwuthC0eCBPAJp6BZwzpycgWYoh8HXncztQ0O6QpIa upKZMPBu7DjdA9yGr6SnHABA0I5yZAB0v2XRXsZShu8Kq4DxSQhAZBBCeYV+SbdIMFSZ 2tB0ZhtyiPwjqj+liQIMkaCsCcCfVrzlobiTA= MIME-Version: 1.0 Received: by 10.103.126.40 with SMTP id d40mr3454317mun.132.1258556552239; Wed, 18 Nov 2009 07:02:32 -0800 (PST) In-Reply-To: <2e027be00911180637h4da6d4f0ma00ff11d860f901a@mail.gmail.com> References: <200911172027.15749.gnemmi@gmail.com> <19e9a5dc0911180634h2484d4d7seedc1611c7e218f2@mail.gmail.com> <2e027be00911180637h4da6d4f0ma00ff11d860f901a@mail.gmail.com> Date: Wed, 18 Nov 2009 12:02:32 -0300 Message-ID: <19e9a5dc0911180702u5db22affld1dbea591163b240@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:02:33 -0000 On Wed, Nov 18, 2009 at 11:37 AM, Tom Evans wrote: > On Wed, Nov 18, 2009 at 2:34 PM, Gonzalo Nemmi wrote: > >> On Wed, Nov 18, 2009 at 7:22 AM, Eitan Adler > >wrote: >> >> > On Wed, Nov 18, 2009 at 12:27 AM, Gonzalo Nemmi >> wrote: >> > > WITHOUT_FLOOPY=yes >> > >> > Just a note - are you sure this is correct? >> > >> >> Dear Eitan: >> >> Up to a second ago I was .. now you are making me have second toughts .. >> I'm using that line on my notebook, wich doesn't have a floopy drive ... >> Would you advice me not to use that line, and could you tell me why? >> (really >> honest question ... I mean maybe WITHOUT_FLOOPY=yes interferes with >> something else that I'm not aware of) >> >> Thanks for your answer >> Best Regards >> > > I think he was thinking that your laptop doesn't have a FLOPPY drive, so > maybe you should have WITHOUT_FLOPPY=yes . > > Now I want a floopy drive :/ > > Cheers > > Tom > Now I got lost .. I mean, I don't have a floopy drive in my laptop and that's why I added WITHOUT_FLOPPY=yes to my src.conf BTW: last floopy drives I tried would just chew disks in a few reads .. very bad quality floopy drives .. Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 15:16:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D17901065696 for ; Wed, 18 Nov 2009 15:16:21 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 616048FC23 for ; Wed, 18 Nov 2009 15:16:21 +0000 (UTC) Received: by bwz5 with SMTP id 5so1423026bwz.3 for ; Wed, 18 Nov 2009 07:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ZwuYof3G/tvWFZ1QyRhpicssWP4mpFh6shdygi03fGk=; b=F9J8yo7iDJhpogYOS0mpO+wq7OfxXHDHP1xKtPaa1odmAmDXUCgCQQ7hp0WkOVscfL YuZlHPZHe/PE2JlBAxVsEBEv0xuB3Au4qxEM9kpGJHvu3WsTpJGP4hEuVTFCUkhteIKo oq+wcJ47gb1Nsns/WPCj6goCuqYg3ZFPaJcxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NZVepaWCrrodF3JM9wG8pdnGY/v5q3SPyLLlmXbeTo7QYPUw79frDj414Pu+itjnsU /mlN2qXAUyS0B2eM0K3oruagoIHsDhS9wUjd2bOObXvCjaOREYUhw0u6WKcpiuirx8Tw kcHL7zQ1W5FUTMvb959m6/L1OH7D/KbVMmOqQ= MIME-Version: 1.0 Received: by 10.102.235.5 with SMTP id i5mr5276480muh.36.1258557380033; Wed, 18 Nov 2009 07:16:20 -0800 (PST) In-Reply-To: <86lji3ucbm.fsf@ds4.des.no> References: <200911172027.15749.gnemmi@gmail.com> <19e9a5dc0911180634h2484d4d7seedc1611c7e218f2@mail.gmail.com> <86lji3ucbm.fsf@ds4.des.no> Date: Wed, 18 Nov 2009 12:16:19 -0300 Message-ID: <19e9a5dc0911180716x3985e862r52ac376bebe6fb11@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:16:21 -0000 2009/11/18 Dag-Erling Sm=F8rgrav > Gonzalo Nemmi writes: > > Would you advice me not to use that line, and could you tell me why? > > (really honest question ... I mean maybe WITHOUT_FLOOPY=3Dyes interfere= s > > with something else that I'm not aware of) > > I can guarantee you that WITHOUT_FLOOPY will not interfere, nor indeed > interact, with anything whatsoever :P > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > You mean the spelling DES. Thanks for pointing that out. Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 15:46:53 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 92D441065693; Wed, 18 Nov 2009 15:46:52 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Thu, 19 Nov 2009 00:46:51 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20091119004651.7432a6e4.nork@FreeBSD.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: How do I use NCQ of Intel X25-E(SSD) on ahci(4)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 15:46:53 -0000 Hi Alexander! I have a Intel 64GB SSD(X25-E) and a Western Digital Caviar Green 1TB HDD (WD10EADS), and use them on ahci(4). ahci(4) can use NCQ of WD10EADS, but doesn't use NCQ of X25-E. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FreeBSD 9.0-CURRENT #107: Thu Nov 19 00:13:30 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr/src/sys/NADESICO amd64 : ahci0: port 0xa000-0xa007,0x9000-0x9003,0x8000-0x8007,0x7000-0x7003,0x6000-0x600f mem 0xfb8fe400-0xfb8fe7ff irq 22 at device 17.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] : (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 (aprobe0:ahcich1:0:0:0): SIGNATURE: 0000 (aprobe0:ahcich2:0:0:0): SIGNATURE: 0000 (aprobe0:ahcich3:0:0:0): SIGNATURE: 0000 : ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA/ATAPI-7 SATA 2.x device ada0: 300.000MB/s transfers ada0: 61057MB (125045424 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I confirmed X25-E disabled NCQ. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # camcontrol tags ada0 (pass0:ahcich0:0:0:0): device openings: 2 # camcontrol tags ada1 (pass1:ahcich1:0:0:0): device openings: 32 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - According to 'camcontrol identify ada0' and Intel's documentation[*], X25-E supports NCQ. [*] http://www.intel.com/design/flash/nand/extreme/index.htm - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # camcontrol identify ada0 pass0: ATA/ATAPI-7 SATA 2.x device pass0: 300.000MB/s transfers protocol ATA/ATAPI-7 SATA 2.x device model SSDSA2SH064G1GC INTEL firmware revision 045C8790 serial number CVEM9024016B064KGN WWN 500151795879a64e cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 125045424 sectors LBA48 supported 125045424 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 overlap not supported media RPM non-rotating Feature Support Enable Value Vendor read ahead yes yes write cache yes yes flush cache yes yes Native Command Queuing (NCQ) yes 30/0x1E Tagged Command Queuing (TCQ) no no 30/0x1E SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management no no 0/0x00 0/0x00 media status notification no no power-up in Standby no no write-read-verify no no 0/0x0 unload yes yes free-fall no no - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # camcontrol identify ada1 pass1: ATA/ATAPI-8 SATA 2.x device pass1: 300.000MB/s transfers protocol ATA/ATAPI-8 SATA 2.x device model WDC WD10EADS-00L5B1 firmware revision 01.01A01 serial number WD-WCAU45664302 WWN 50014ee257aa350 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 1953525168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 overlap not supported Feature Support Enable Value Vendor read ahead yes yes write cache yes yes flush cache yes yes Native Command Queuing (NCQ) yes 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes yes 254/0xFE 128/0x80 media status notification no no power-up in Standby yes no write-read-verify no no 0/0x0 unload no no free-fall no no - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To use NCQ of X25-E, what should I report to you? From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 16:11:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63614106568B; Wed, 18 Nov 2009 16:11:21 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 037388FC12; Wed, 18 Nov 2009 16:11:20 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 1A0EF244; Wed, 18 Nov 2009 17:15:24 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 17:11:14 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: In-Reply-To: <1258552247.2303.75.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 16:11:21 -0000 On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland wrote: >> >> Should I file a PR? I would >> >> like to help in debugging it (however my skills in low-level C aren't >> >> strong enough to do it on my own). >> > Ok, the first thing I would like to see is "zdb -uuu". >> # zdb -uuu pgpool >> Segmentation fault: 11 (core dumped) > Ok, this is disturbing... It works fine for me on -CURRENT / amd64 and > reports the root block pointer, which is what we need to locate the MOS. Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb -uuu" happy: Fixit# zdb -uuu pgpool Uberblock magic = 0000000000bab10c version = 13 txg = 443448 guid_sum = 9780688847620645377 timestamp = 1258560175 UTC = Wed Nov 18 16:02:55 2009 rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:220000de400:200> DVA[1]=<0:2a80008ee00:200> DVA[2]=<0:330000b9000:200> fletcher4 lzjb LE contiguous birth=443448 fill=298 cksum=8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac -- am From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 13:03:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935B41065672 for ; Wed, 18 Nov 2009 13:03:22 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5CE8FC1A for ; Wed, 18 Nov 2009 13:03:22 +0000 (UTC) Received: by yxe1 with SMTP id 1so985043yxe.3 for ; Wed, 18 Nov 2009 05:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7g+XwKWY1pNkGYGd7TdJkkgeLRHbvlQKFKKgiUHbUA8=; b=V/TXLT2KbCPxIzfP/gbXhVtlWigBAtUYp2l9mM3CrD8ODvMyl+OIhdvOs/pwACoUBJ fg14W8ThpyXqK8qFcmf8BGNqdeuS+yTct8byZYQT497j+G4aXXI8WmLYh69GZPoUGghN feBrVPykdLdzo7AH9pymwGrbgUZkCSD+fHp/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=woWFX9NmnPuunUlKKXAxOUI/A1+frfrkED6xbJpEteajb0hRm1/QxraNY5mQybztHV 2TJg64eL+8mj3f7LOtLl6X0DW3UiMq/snoNC6WNgZ/4djrKOqvtDdepawdg7mSAOnCvC vhNqLv/owrcZvBNa2bGgu3dJJsxfL48iLcHIk= MIME-Version: 1.0 Received: by 10.101.10.6 with SMTP id n6mr2567109ani.17.1258549400483; Wed, 18 Nov 2009 05:03:20 -0800 (PST) In-Reply-To: <20091118135340.522fa36a@ernst.jennejohn.org> References: <20091118135340.522fa36a@ernst.jennejohn.org> Date: Wed, 18 Nov 2009 15:03:20 +0200 Message-ID: From: Dan Naumov To: gary.jennejohn@freenet.de Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 18 Nov 2009 16:17:18 +0000 Cc: freebsd-current Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 13:03:22 -0000 On Wed, Nov 18, 2009 at 2:53 PM, Gary Jennejohn wrote: > On Wed, 18 Nov 2009 13:44:12 +0200 > Dan Naumov wrote: > >> > WHy not just build from source? >> >> Because expecting users to build from source to install or update >> their systems in the year 2009 is an outdated concept, this is why we >> have freebsd-update in the first place. >> > > This is such a load of BS I could fertilize 100 acres with it. > > In this day of inexpensive computers with fast mulit-core CPUs and > gigabytes of memory this argument is completely lame. No it is not. The fact that computers are faster today is not a valid excuse to inconvenience the users whatsoever. It is bad enough that sysinstall doesn't support ZFS so a ZFS-only installation has to be done purely using a commandline, but demanding the user to rebuild the system to be able to boot off a filesystem which is one of the most advertised features of FreeBSD 7.x and 8.x is plain ridiculous. What if the user is a newcomer who doesn't _HAVE_ an existing FreeBSD installation he could use to build a ZFS-boot-capable FreeBSD installation image? If a user goes to www.freebsd.org and downloads the .ISO images of 8.0, it is completely unreasonable to force the user to jump through having to make an installation, rebuild the sources, make a new .ISO for his own use and then reinstall using that. If you don't see WHY, I don't quite know what to tell you. - Sincerely, Dan Naumov From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 16:33:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F501065670 for ; Wed, 18 Nov 2009 16:33:40 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id C4F1A8FC12 for ; Wed, 18 Nov 2009 16:33:39 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so201198eye.9 for ; Wed, 18 Nov 2009 08:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gMbupdZFce3LUHKoWk4N5+0azCeMso7JgI3k5UJZ7EA=; b=iqzBFgQPNLBSLSjHZlboRPVQaXKBSnXNKlZJdnm0GHxr0HntlZKM07Hri/OdFgh6z9 ewUVnWbnIuMW79jQfuCbsxhdP92NdQm9kcW7T/WQ4piaCN5Yy6B+E/dQnUyNdbz8/DSA uiusaULqObNXtipsa0NdSqCqiX0zlsWZtkzAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N/9L8KCHIDPJTi+cLgkD96wLfKmtv4ik99+GY4ORnWm2WbxWN2edy0J3rXzaptMkAj RGihpKBJp6y5FdznLSeCNW02HM57CvQkEQn5h0x2HIhSVhN7Vz4FmcOnwlEhz4NAVk1g dgdZvioJLzOtUOwXqNXqvyJ/qbL9692dVtBvY= MIME-Version: 1.0 Received: by 10.213.102.202 with SMTP id h10mr386011ebo.76.1258562018154; Wed, 18 Nov 2009 08:33:38 -0800 (PST) In-Reply-To: References: <20091118135340.522fa36a@ernst.jennejohn.org> Date: Wed, 18 Nov 2009 16:33:38 +0000 Message-ID: <2e027be00911180833t6a5dbae7kc796db49c7d3b476@mail.gmail.com> From: Tom Evans To: Dan Naumov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 16:33:40 -0000 On Wed, Nov 18, 2009 at 1:03 PM, Dan Naumov wrote: > On Wed, Nov 18, 2009 at 2:53 PM, Gary Jennejohn > wrote: > > On Wed, 18 Nov 2009 13:44:12 +0200 > > Dan Naumov wrote: > > > >> > WHy not just build from source? > >> > >> Because expecting users to build from source to install or update > >> their systems in the year 2009 is an outdated concept, this is why we > >> have freebsd-update in the first place. > >> > > > > This is such a load of BS I could fertilize 100 acres with it. > > > > In this day of inexpensive computers with fast mulit-core CPUs and > > gigabytes of memory this argument is completely lame. > > No it is not. The fact that computers are faster today is not a valid > excuse to inconvenience the users whatsoever. > > It is bad enough that sysinstall doesn't support ZFS so a ZFS-only > installation has to be done purely using a commandline, but demanding > the user to rebuild the system to be able to boot off a filesystem > which is one of the most advertised features of FreeBSD 7.x and 8.x is > plain ridiculous. > > What if the user is a newcomer who doesn't _HAVE_ an existing FreeBSD > installation he could use to build a ZFS-boot-capable FreeBSD > installation image? If a user goes to www.freebsd.org and downloads > the .ISO images of 8.0, it is completely unreasonable to force the > user to jump through having to make an installation, rebuild the > sources, make a new .ISO for his own use and then reinstall using > that. If you don't see WHY, I don't quite know what to tell you. > > > - Sincerely, > Dan Naumov > > Of the hoops that I had to jump through to install FreeBSD 8 on a ZFS raidz, the least inconsequential was rebuilding loader with ZFS support. Truly, truly simple. There is also no need to build a different installation image, everything can be done from the fixit console on the installation media. You also don't rebuild the system, you rebuild one tiny part of it, just the loader. I think you are most miffed that currently the user is required to do it themselves. If an installer compiled it for you, I don't think there would be any fuss that this is unreasonable. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 14:25:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2FC1065697 for ; Wed, 18 Nov 2009 14:25:10 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 361BD8FC0A for ; Wed, 18 Nov 2009 14:25:09 +0000 (UTC) Received: by yxe1 with SMTP id 1so1055052yxe.3 for ; Wed, 18 Nov 2009 06:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JRF7vxNkD2jrur6EGOfHSv3DKz2DPb3n9V6bXQ4HC50=; b=EDN4i7ro0qd4aasDnzJLkGaIcSNKz1dglJ+rTzkrOa4Qp6NAXi2Uob1UingCPxUfxN 7dwOuUdgffjntdXIaMr5TD3I/kxEajB4RrM0CQw63R4r01KOXW0dGzLmYAiP/H44tdqJ hMjjpnVXJ5TkTBPqVqAm1d4gU0DN3G3KFfCW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O2Z70sL7YswA9Z1AAgL8hTCgx6yWdQK1fAUjNOkNQ18VsDXWswJLA5wkTS/2sKaR0f wjNh4TaVnSkFBSZslSVxDXJsErGR+SnMTB6S9Ex1qVSiyWSfz5HX91ATV4Fqrk8A6kND 6HUJdcyw79+qda1GOH3l5FOdVVXfvLhoqDs+E= MIME-Version: 1.0 Received: by 10.101.152.37 with SMTP id e37mr2642491ano.45.1258554309373; Wed, 18 Nov 2009 06:25:09 -0800 (PST) In-Reply-To: <4B04020C.3080000@zedat.fu-berlin.de> References: <20091118135340.522fa36a@ernst.jennejohn.org> <4B04020C.3080000@zedat.fu-berlin.de> Date: Wed, 18 Nov 2009 16:25:09 +0200 Message-ID: From: Dan Naumov To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 18 Nov 2009 16:34:13 +0000 Cc: freebsd-current Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 14:25:10 -0000 2009/11/18 O. Hartmann : > Gary Jennejohn wrote: >> >> On Wed, 18 Nov 2009 13:44:12 +0200 >> Dan Naumov wrote: >> >>>> WHy not just build from source? >>> >>> Because expecting users to build from source to install or update >>> their systems in the year 2009 is an outdated concept, this is why we >>> have freebsd-update in the first place. >>> >> >> This is such a load of BS I could fertilize 100 acres with it. >> >> In this day of inexpensive computers with fast mulit-core CPUs and >> gigabytes of memory this argument is completely lame. >> >> Fifteen years ago I would have agreed, because it took days to build >> world and the kernel. =A0Been there, done that. >> >> --- >> Gary Jennejohn > > Been there, did it, too. > > Fools, conceptually compromised by Microsofts closed-binary-strategy, oft= en > complain about 'why compiling, it is an outdated concept ...'. It is, sim= ply > in my opinion, a helpless selfdefense: they do not understand much about > operating systems (me, too) and never try to understand the concept behin= d > (me not). But today, having sophisticated binary update facilities, it se= ems > to speed up a worse development: many companies save the computer-scienti= st > to maintain their stuff - because they have a bunch of cheap fools > 'fertilizing the acres of foolsness' and pretending being the master of t= he > puppets by hitting an 'update-key' and everythings works magically ... This is unreasonable elitism. Having to jump through hoops, manually adjust Makefiles and spend time compiling just to apply a system update does NOT make you a "guru". It makes you waste time that could be better spent elsewhere. - Sincerely, Dan Naumov From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 16:38:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D01D106566B for ; Wed, 18 Nov 2009 16:38:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id DFD5E8FC12 for ; Wed, 18 Nov 2009 16:38:33 +0000 (UTC) Received: by fxm27 with SMTP id 27so1436893fxm.3 for ; Wed, 18 Nov 2009 08:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=129II1XXZ3wEMUbfZszAacfmeyNx7pYCdFyMZSc48vQ=; b=qljd1nfrKs9phwGO4VN+MtK1XfjdHXfHt9rR8jJe2tdbbQnVxzhedgKFUNS4NWcgqN 3zFK9R/Fgi22K9J2+6rPL25dqQ/7TN9vkF1qlxtKkf+Q5dbhEqcwY34CPZLAJYdXRtS1 5VHA0mHRMiPni8kY738TU6O5w5yNwRGr+312o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=oiSBWgw6kXYKu0OHfjujrDHPbnNt98/3Vh7zApIyS2GcBLmexNIBM9nr4ZBtEwL92O fAeFX3GNUWVYkzCaEOU2lsX4WKj8fwHbNEPKEN4e1mWBuUa35SuQ1ubxIuEWboJB2Vs8 t3J1Syhh4yqSPWJJ2bVEHkpAmy0ZXtw2bsIm8= Received: by 10.204.15.16 with SMTP id i16mr7147287bka.72.1258562312260; Wed, 18 Nov 2009 08:38:32 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm107152fxm.6.2009.11.18.08.38.31 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 08:38:31 -0800 (PST) Sender: Alexander Motin Message-ID: <4B042304.8060807@FreeBSD.org> Date: Wed, 18 Nov 2009 18:38:28 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Norikatsu Shigemura References: <20091119004651.7432a6e4.nork@FreeBSD.org> In-Reply-To: <20091119004651.7432a6e4.nork@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: How do I use NCQ of Intel X25-E(SSD) on ahci(4)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 16:38:34 -0000 Hi. Norikatsu Shigemura wrote: > I have a Intel 64GB SSD(X25-E) and a Western Digital Caviar Green > 1TB HDD (WD10EADS), and use them on ahci(4). ahci(4) can use NCQ > of WD10EADS, but doesn't use NCQ of X25-E. > > # camcontrol identify ada0 > pass0: ATA/ATAPI-7 SATA 2.x device > pass0: 300.000MB/s transfers > > Native Command Queuing (NCQ) yes 30/0x1E Here is the reason ^^^ This drive support less tags (31) then your AHCI controller does (32). Support for such case is not implemented yet. As temporary solution you may limit controller to use only 31 tag, then NCQ will be used. All you need is to go to ahci.c and change line ch->numslots = ...; to ch->numslots = min(31, ...); -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 16:43:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4126106566B; Wed, 18 Nov 2009 16:43:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8912C8FC1B; Wed, 18 Nov 2009 16:43:57 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAIGhs30018338 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 11:43:55 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Wed, 18 Nov 2009 10:43:48 -0600 Message-Id: <1258562628.2303.83.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 16:43:57 -0000 On Wed, 2009-11-18 at 17:11 +0100, Emil Smolenski wrote: > On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland > wrote: > > >> >> Should I file a PR? I would > >> >> like to help in debugging it (however my skills in low-level C aren't > >> >> strong enough to do it on my own). > >> > Ok, the first thing I would like to see is "zdb -uuu". > >> # zdb -uuu pgpool > >> Segmentation fault: 11 (core dumped) > > > Ok, this is disturbing... It works fine for me on -CURRENT / amd64 and > > reports the root block pointer, which is what we need to locate the MOS. > > Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb -uuu" > happy: > > Fixit# zdb -uuu pgpool > Uberblock > > magic = 0000000000bab10c > version = 13 > txg = 443448 > guid_sum = 9780688847620645377 > timestamp = 1258560175 UTC = Wed Nov 18 16:02:55 2009 > rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:220000de400:200> > DVA[1]=<0:2a80008ee00:200> DVA[2]=<0:330000b9000:200> fletcher4 lzjb LE > contiguous birth=443448 fill=298 > cksum=8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac Ok, the offsets are definately up there... What is your normal installation? 8.0 i386? robert. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 16:46:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D71A4106568B; Wed, 18 Nov 2009 16:46:12 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 430148FC18; Wed, 18 Nov 2009 16:46:12 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 0501D244; Wed, 18 Nov 2009 17:50:14 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 17:46:06 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: In-Reply-To: <1258562628.2303.83.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 16:46:12 -0000 On Wed, 18 Nov 2009 17:43:48 +0100, Robert Noland wrote: > On Wed, 2009-11-18 at 17:11 +0100, Emil Smolenski wrote: >> On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland >> wrote: >> >> >> >> Should I file a PR? I would >> >> >> like to help in debugging it (however my skills in low-level C >> aren't >> >> >> strong enough to do it on my own). >> >> > Ok, the first thing I would like to see is "zdb -uuu". >> >> # zdb -uuu pgpool >> >> Segmentation fault: 11 (core dumped) >> >> > Ok, this is disturbing... It works fine for me on -CURRENT / amd64 >> and >> > reports the root block pointer, which is what we need to locate the >> MOS. >> >> Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb >> -uuu" >> happy: >> >> Fixit# zdb -uuu pgpool >> Uberblock >> >> magic = 0000000000bab10c >> version = 13 >> txg = 443448 >> guid_sum = 9780688847620645377 >> timestamp = 1258560175 UTC = Wed Nov 18 16:02:55 2009 >> rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:220000de400:200> >> DVA[1]=<0:2a80008ee00:200> DVA[2]=<0:330000b9000:200> fletcher4 lzjb LE >> contiguous birth=443448 fill=298 >> cksum=8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac > > Ok, the offsets are definately up there... What is your normal > installation? 8.0 i386? 7.2-STABLE, amd64. -- am From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 16:59:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87BC2106566C for ; Wed, 18 Nov 2009 16:59:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 43DE18FC0C for ; Wed, 18 Nov 2009 16:59:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NAnsP-0008VY-3T for freebsd-current@freebsd.org; Wed, 18 Nov 2009 17:59:29 +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 ; Wed, 18 Nov 2009 17:59:29 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Nov 2009 17:59:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 18 Nov 2009 17:59:15 +0100 Lines: 30 Message-ID: References: <20091119004651.7432a6e4.nork@FreeBSD.org> <4B042304.8060807@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <4B042304.8060807@FreeBSD.org> Sender: news Subject: Re: How do I use NCQ of Intel X25-E(SSD) on ahci(4)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 16:59:30 -0000 Alexander Motin wrote: > Hi. > > Norikatsu Shigemura wrote: >> I have a Intel 64GB SSD(X25-E) and a Western Digital Caviar Green >> 1TB HDD (WD10EADS), and use them on ahci(4). ahci(4) can use NCQ >> of WD10EADS, but doesn't use NCQ of X25-E. >> >> # camcontrol identify ada0 >> pass0: ATA/ATAPI-7 SATA 2.x device >> pass0: 300.000MB/s transfers >> >> Native Command Queuing (NCQ) yes 30/0x1E > > Here is the reason ^^^ > > This drive support less tags (31) then your AHCI controller does (32). > Support for such case is not implemented yet. As temporary solution you > may limit controller to use only 31 tag, then NCQ will be used. All you > need is to go to ahci.c and change line > ch->numslots = ...; > to > ch->numslots = min(31, ...); I know next to nothing about AHCI and drivers so this might be obviously wrong but wouldn't a quick (i.e. MFC-able) obvious temporary fix be to say numslots = min(get_minimum_tags_of_all_drives(), ...) ? From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 17:05:02 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EF201065670 for ; Wed, 18 Nov 2009 17:05:02 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id E71638FC16 for ; Wed, 18 Nov 2009 17:05:01 +0000 (UTC) Received: by bwz5 with SMTP id 5so1542598bwz.3 for ; Wed, 18 Nov 2009 09:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=sIrF0lymdUrJ6KcftRSzjH5cob6R/AGoKRKhetA4nTM=; b=ea3NqedK1X//BRewKF8tyQjpXN4/kwj0Zo1u7uGqjI/Hw4VhRN4w8LPqclvGkOdHdn mqKlz+9VQBKqABBYLDX6KEDUxVYYWIw5o5OsO5rXxZV9Yf+eD542piTnmpt3CekBakAZ TZE6D7jKQ/tFRhZL2NdWoBXhJU9VM1QytOsZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=s1YPBTIjSCvP8qDj8zwqqjrD0hVJbytACQm7833R09S9cxkd97OI/GaLJ879GVIUH4 IUtDjteGN+9cA78oH5drysDNnIHqaLveN9lIS956nWeWWwkueF3bgkaOtx7tQwrcqEuV FtMxwf9mMwdxVkxLfL/KoNdMXG2XJs9YetK8Q= MIME-Version: 1.0 Received: by 10.216.90.14 with SMTP id d14mr1056412wef.30.1258563900613; Wed, 18 Nov 2009 09:05:00 -0800 (PST) Date: Wed, 18 Nov 2009 17:05:00 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:05:02 -0000 >On 18 Nov 2009, at 14:01, Dag-Erling Sm=F8rgrav wrote: > >> Robert Watson writes: >>> Olivier Smedts writes: >>>> But someone (you, me...) can file a PR to add them to OLD_FILES when >>>> WITHOUT_TELNET is set to yes, like it's done for some other WITHOUT_ >>>> options. >>> If it's done for other WITHOUT_ options, it's not obvious to me. >> >> tools/build/mk/OptionalObsoleteFiles.inc >> >> Poor placement IMHO, we shouldn't have dependencies from src into tools. > >Its obscure location explains why it doesn't work. :-) Maybe it Not altogether: it works fine, for those knobs that developers have seen fit to support in the file. The problem is that some developers neglect it entirely. >should be src/OptionalFiles.inc? That said, it still sounds like a >signif= icant maintenance problem to me: we have a lot of >WITHOUT_ options, and th= ey may have non-trivial interactions... Being aware of what is built, and what is installed, is part of maintaining the base system, and in that regard maintaining this file is little more than writing down information that developers should already have determined if they are properly supporting the various base system knobs. Along with the knobs, it's very useful to those of us who want to remove unneeded parts of the base system, and I wish it was more conscientiously maintained. Let's not exaggerate the difficulties involved in doing so. For the fellow who was concerned about removing his SSH port: yes, it's something to consider. But you are not obliged to run make delete-old[-libs], and even if you do want to run it, you can do so without defining WITHOUT_SSH. Regards, b. From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 17:14:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B0FDF1065672; Wed, 18 Nov 2009 17:14:46 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Thu, 19 Nov 2009 02:14:40 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20091119021440.560884b2.nork@FreeBSD.org> In-Reply-To: <4B042304.8060807@FreeBSD.org> References: <20091119004651.7432a6e4.nork@FreeBSD.org> <4B042304.8060807@FreeBSD.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Norikatsu Shigemura Subject: Re: How do I use NCQ of Intel X25-E(SSD) on ahci(4)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 17:14:47 -0000 Hi Alexander. On Wed, 18 Nov 2009 18:38:28 +0200 Alexander Motin wrote: > > Native Command Queuing (NCQ) yes 30/0x1E > > Here is the reason ^^^ > This drive support less tags (31) then your AHCI controller does (32). > Support for such case is not implemented yet. As temporary solution you > may limit controller to use only 31 tag, then NCQ will be used. All you > need is to go to ahci.c and change line > ch->numslots = ...; > to > ch->numslots = min(31, ...); Oops, OK! I confirmed following patch: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- sys/dev/ahci/ahci.c.orig 2009-11-17 22:25:07.474418000 +0900 +++ sys/dev/ahci/ahci.c 2009-11-19 02:00:22.193688908 +0900 @@ -779,7 +779,7 @@ ch->caps = ctlr->caps; ch->caps2 = ctlr->caps2; ch->quirks = ctlr->quirks; - ch->numslots = ((ch->caps & AHCI_CAP_NCS) >> AHCI_CAP_NCS_SHIFT) + 1, + ch->numslots = min(31, ((ch->caps & AHCI_CAP_NCS) >> AHCI_CAP_NCS_SHIFT) + 1), mtx_init(&ch->mtx, "AHCI channel lock", NULL, MTX_DEF); resource_int_value(device_get_name(dev), device_get_unit(dev), "pm_level", &ch->pm_level); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ahci(4) can use NCQ of X25-E. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA/ATAPI-7 SATA 2.x device ada0: 300.000MB/s transfers ada0: Command Queueing enabled ada0: 61057MB (125045424 512 byte sectors: 16H 63S/T 16383C) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # camcontrol tags ada0 (pass0:ahcich0:0:0:0): device openings: 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thank you! From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 17:23:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1BF21065693 for ; Wed, 18 Nov 2009 17:23:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id B726D8FC1B for ; Wed, 18 Nov 2009 17:23:06 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1DA0714E02E; Wed, 18 Nov 2009 09:23:07 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 047002D601E; Wed, 18 Nov 2009 09:23:05 -0800 (PST) Message-ID: <4B042D79.9010809@elischer.org> Date: Wed, 18 Nov 2009 09:23:05 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <20091116174933.4ab2354d.daichi@ongs.co.jp> <20091117103651.da7ceeb0.daichi@ongs.co.jp> <861vjwvzzp.fsf@ds4.des.no> In-Reply-To: <861vjwvzzp.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-emulation@FreeBSD.org, Daichi GOTO , current@freebsd.org Subject: Re: FreeBSD 8.0-RC3/amd64 cannot boot on VirtualBox (solved) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 17:23:06 -0000 Dag-Erling Smørgrav wrote: > Daichi GOTO writes: >> Enabled both ACPI and IO ACPI > > ITYM "I/O APIC". HTH, HAND! > > DES OMG !LEET! From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 17:37:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A12E01065694 for ; Wed, 18 Nov 2009 17:37:34 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 17D618FC24 for ; Wed, 18 Nov 2009 17:37:33 +0000 (UTC) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.4/8.13.1) with ESMTP id nAIHNWj6014339; Wed, 18 Nov 2009 18:23:32 +0100 (CET) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.4/8.13.1/Submit) id nAIHNWQZ014338; Wed, 18 Nov 2009 18:23:32 +0100 (CET) (envelope-from hk) Date: Wed, 18 Nov 2009 18:23:32 +0100 From: Holger Kipp To: Dan Naumov Message-ID: <20091118172332.GA8542@intserv.int1.b.intern> References: <20091118135340.522fa36a@ernst.jennejohn.org> <4B04020C.3080000@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 18 Nov 2009 17:40:45 +0000 Cc: freebsd-current , "O. Hartmann" Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 17:37:34 -0000 On Wed, Nov 18, 2009 at 04:25:09PM +0200, Dan Naumov wrote: > 2009/11/18 O. Hartmann : > > Gary Jennejohn wrote: > >> > >> On Wed, 18 Nov 2009 13:44:12 +0200 > >> Dan Naumov wrote: > >> > >>>> WHy not just build from source? > >>> > >>> Because expecting users to build from source to install or update > >>> their systems in the year 2009 is an outdated concept, this is why we > >>> have freebsd-update in the first place. > >>> > >> > >> This is such a load of BS I could fertilize 100 acres with it. > >> > >> In this day of inexpensive computers with fast mulit-core CPUs and > >> gigabytes of memory this argument is completely lame. > >> > >> Fifteen years ago I would have agreed, because it took days to build > >> world and the kernel.  Been there, done that. > >> > >> --- > >> Gary Jennejohn > > > > Been there, did it, too. > > > > Fools, conceptually compromised by Microsofts closed-binary-strategy, often > > complain about 'why compiling, it is an outdated concept ...'. It is, simply > > in my opinion, a helpless selfdefense: they do not understand much about > > operating systems (me, too) and never try to understand the concept behind > > (me not). But today, having sophisticated binary update facilities, it seems > > to speed up a worse development: many companies save the computer-scientist > > to maintain their stuff - because they have a bunch of cheap fools > > 'fertilizing the acres of foolsness' and pretending being the master of the > > puppets by hitting an 'update-key' and everythings works magically ... > > This is unreasonable elitism. Having to jump through hoops, manually Ah no. If someone needs a precompiled system with everything, he can go and use Windows or Linux. I prefer using *BSD _because_ I can compile everything from scratch. And the build-system usually works much better than many 'pre-compiled' binary systems on the market. > adjust Makefiles and spend time compiling just to apply a system > update does NOT make you a "guru". It makes you waste time that could > be better spent elsewhere. Usually adjusting Makefiles is not necessary, because the defaults are fine for most users. If you _need_ to adjust Makefiles, then a precompiled solution is definitely not suited to your needs. Trust me on that ;-) Regards, Holger From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 17:53:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C15B10656C1 for ; Wed, 18 Nov 2009 17:53:59 +0000 (UTC) (envelope-from p.massat@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id B98468FC1D for ; Wed, 18 Nov 2009 17:53:58 +0000 (UTC) Received: by gxk10 with SMTP id 10so1279275gxk.3 for ; Wed, 18 Nov 2009 09:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=D6JLQK4AjOac1A2u0rgNFfX0FnPV/NcLo7FBafnVHeg=; b=kR2LgYrsxkaI9Cg+YZkWzVdaT9GozfNCE5hOJtfkJRjpPo8IYYUbaJ5JsFamHBW/tz 9NyN1gNIIE9Wq/4lYSU67SU21cjFp80I1Flqo95FY/MwskKLQhhihuHSTnIJQg2blL/C rZnvKO42hBxSwOlXHqhs0JR2Jy8W480MMFWuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=MK0LHeijDGiNlyp+H8PO2pfyWnKdPruHRnWH4s/PzFvfbCb+zYC6EEmaWLqpOf3lS9 LP/OkOJE3i/DzagMOwmnCP2jCspjnSKjUo9hstL68oK27dlzhwWLcPYijw05Eylkc1pu rQtRGy4Z41MO82Kauffu3Y0VjTHQNRDHbn4/E= MIME-Version: 1.0 Sender: p.massat@gmail.com Received: by 10.101.74.6 with SMTP id b6mr2653825anl.186.1258565035914; Wed, 18 Nov 2009 09:23:55 -0800 (PST) In-Reply-To: <2e027be00911180833t6a5dbae7kc796db49c7d3b476@mail.gmail.com> References: <20091118135340.522fa36a@ernst.jennejohn.org> <2e027be00911180833t6a5dbae7kc796db49c7d3b476@mail.gmail.com> From: Pierre Massat Date: Wed, 18 Nov 2009 18:23:35 +0100 X-Google-Sender-Auth: b60216fce589137b Message-ID: <4c3c61160911180923h900f44u74a040726f2b42d4@mail.gmail.com> To: Tom Evans Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 17:53:59 -0000 On Wed, Nov 18, 2009 at 5:33 PM, Tom Evans wrote: > Of the hoops that I had to jump through to install FreeBSD 8 on a ZFS raidz, > the least inconsequential was rebuilding loader with ZFS support. Truly, > truly simple. There is also no need to build a different installation image, > everything can be done from the fixit console on the installation media. You > also don't rebuild the system, you rebuild one tiny part of it, just the > loader. This is truly simple, I agree with you. But I have a ZFS-boot mirror and I upgraded to 8.0-RC3 recently and my server didn't reboot because I forgot the loader stuff. Of course, this wasn't a production server and I took some precautions, but it would be more convienient not to worry about such pointless detail. That's why changing the bootloader to be able to have ZFS built-in is, to my mind, a good thing. We can simplify the way ZFS is managed in Freebsd by such simple things. -- Pierre Massat From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 17:59:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E51B106568F for ; Wed, 18 Nov 2009 17:59:36 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward7.mail.yandex.net (forward7.mail.yandex.net [77.88.61.37]) by mx1.freebsd.org (Postfix) with ESMTP id E8C9B8FC12 for ; Wed, 18 Nov 2009 17:59:35 +0000 (UTC) Received: from webmail63.yandex.ru (webmail63.yandex.ru [77.88.61.8]) by forward7.mail.yandex.net (Yandex) with ESMTP id 583D731011E; Wed, 18 Nov 2009 20:59:34 +0300 (MSK) Received: from localhost (localhost.localdomain [127.0.0.1]) by webmail63.yandex.ru (Yandex) with ESMTP id E2101D5402B; Wed, 18 Nov 2009 20:59:33 +0300 (MSK) X-Yandex-Spam: 1 X-Yandex-Front: webmail63 X-Yandex-TimeMark: 1258567173 Received: from [89.223.19.70] ([89.223.19.70]) by mail.yandex.ru with HTTP; Wed, 18 Nov 2009 20:59:33 +0300 From: S.N.Grigoriev To: Andriy Gapon In-Reply-To: <4B0403D0.3090101@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> <4AFD140D.7010407@icyb.net.ua> <20091113144804.2c0fb90f@orwell.free.de> <4AFD655E.5020801@icyb.net.ua> <20091114022121.217dd831@orwell.free.de> <4AFE7A32.7060203@icyb.net.ua> <4B025FA9.7020003@icyb.net.ua> <20091117165304.01676555@orwell.free.de> <4B0403D0.3090101@icyb.net.ua> MIME-Version: 1.0 Message-Id: <9461258567173@webmail63.yandex.ru> Date: Wed, 18 Nov 2009 20:59:33 +0300 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 17:59:36 -0000 18.11.09, 16:25, "Andriy Gapon" wrote: > Kai, Serguey, > thank you very much for the testing! > This has been an invaluable help. > I am now trying to narrow down possible causes of the issue and to come up with > the most efficient patch. > If/when you have a chance could you please test the following changes? > The patches are against mainline source tree (that is, not against previous > patch(es)). > So, please first try *only* this patch: > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 44b71f3..33b8c2a 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -2981,6 +2981,7 @@ setpte: > * Map the superpage. > */ > pde_store(pde, PG_PS | newpde); > + pmap_invalidate_range(pmap, trunc_2mpage(va), trunc_2mpage(va) + NBPDR); > pmap_pde_promotions++; > CTR2(KTR_PMAP, "pmap_promote_pde: success for va %#lx" > Most likely this will fix the buildworld scenario. > But I am not sure if it will fix ZFS scenario. > If it does - then great, if not, please apply the following patch in addition to > the previous one and test again: > diff --git a/sys/amd64/amd64/mca.c b/sys/amd64/amd64/mca.c > index d291d00..d6547a3 100644 > --- a/sys/amd64/amd64/mca.c > +++ b/sys/amd64/amd64/mca.c > @@ -43,6 +43,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -465,6 +466,8 @@ void > mca_init(void) > { > uint64_t mcg_cap; > + uint64_t ctl; > + int skip; > int i; > /* MCE is required. */ > @@ -482,14 +485,22 @@ mca_init(void) > wrmsr(MSR_MCG_CTL, MCG_CTL_ENABLE); > for (i = 0; i < (mcg_cap & MCG_CAP_COUNT); i++) { > - /* > - * Enable logging of all errors. For P6 > - * processors, MC0_CTL is always enabled. > - * > - * XXX: Better CPU test needed here? > - */ > - if (!(i == 0 && (cpu_id & 0xf00) == 0x600)) > - wrmsr(MSR_MC_CTL(i), 0xffffffffffffffffUL); > + /* By default enable logging of all errors. */ > + ctl = 0xffffffffffffffffUL; > + skip = 0; > + if (cpu_vendor_id == CPU_VENDOR_INTEL) { > + /* For P6 MC0_CTL is always enabled. */ > + if (i == 0 && CPUID_TO_FAMILY(cpu_id) == 0x6) > + skip = 1; > + } else if (cpu_vendor_id == CPU_VENDOR_AMD) { > + /* BKDG for Family 10h: unset GartTblWkEn. */ > + if (i == 4 && CPUID_TO_FAMILY(cpu_id) >= 0xf) { > + ctl &= ~(1UL << 10); > + } > + } > + > + if (!skip) > + wrmsr(MSR_MC_CTL(i), ctl); > /* Clear all errors. */ > wrmsr(MSR_MC_STATUS(i), 0); Andriy, I've successfully tested the first patch above with 'make -j8 buildworld'. -- Regards, S.Grigoriev. From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 18:05:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C478E106568D for ; Wed, 18 Nov 2009 18:05:10 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4656C8FC1A for ; Wed, 18 Nov 2009 18:05:09 +0000 (UTC) Received: by bwz5 with SMTP id 5so1607038bwz.3 for ; Wed, 18 Nov 2009 10:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VcZz42jstvRSw2zqPrpE0DQ0k9z57OfQIfoBa4AuS8c=; b=mwN2jJ0d0KRqwR+naqac24M6vEFNlAi15wTnnZI3z5Md+QIshhQ/aVm63f24ghMWC0 z0+xpoq3h5xsZQgCVXgQKi4q7O1tF7wDuXg2fc5Rd83IL2WHJRL3qeDT9Cpai0D5GP5G PwYTWbx+JpQmh/h6kFZ34etGCdzxFvVlkZnd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vANxLk4I/2btGoHqCF8cvo5gwebYNq9y4I4Ffm2Bs7TfC+/EcFrHRD6JyPsR1auUbo VJnCMAOnxk3i2BDH6waX0iGXIf+xch4FBqGIEVo/KXdDJfmtjZiQmH/rLRmpQ94QF48P ymiDYvpg/hE8JQ6REGsJs1OSHCuzQSLy+xZ0w= Received: by 10.204.34.78 with SMTP id k14mr1036219bkd.106.1258567508683; Wed, 18 Nov 2009 10:05:08 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm143891fxm.3.2009.11.18.10.05.07 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 10:05:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4B043751.7080302@FreeBSD.org> Date: Wed, 18 Nov 2009 20:05:05 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Ivan Voras References: <4B042304.8060807@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: How do I use NCQ of Intel X25-E(SSD) on ahci(4)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 18:05:10 -0000 Ivan Voras wrote: > Alexander Motin wrote: >> Norikatsu Shigemura wrote: >>> I have a Intel 64GB SSD(X25-E) and a Western Digital Caviar Green >>> 1TB HDD (WD10EADS), and use them on ahci(4). ahci(4) can use NCQ >>> of WD10EADS, but doesn't use NCQ of X25-E. >>> >>> # camcontrol identify ada0 >>> pass0: ATA/ATAPI-7 SATA 2.x device >>> pass0: 300.000MB/s transfers >>> Native Command Queuing (NCQ) yes 30/0x1E >> >> Here is the reason ^^^ >> >> This drive support less tags (31) then your AHCI controller does (32). >> Support for such case is not implemented yet. As temporary solution you >> may limit controller to use only 31 tag, then NCQ will be used. All you >> need is to go to ahci.c and change line >> ch->numslots = ...; >> to >> ch->numslots = min(31, ...); > > I know next to nothing about AHCI and drivers so this might be obviously > wrong but wouldn't a quick (i.e. MFC-able) obvious temporary fix be to say > > numslots = min(get_minimum_tags_of_all_drives(), ...) > ? Problem is that SIM driver has no idea about devices capabilities, and also doesn't have method to resize queue after attach. In SCSI case, tags are random and only simultaneous number of request is limited, and this is handled fine by CAM. SATA NCQ is more restrictive, allowing to use only tags 0..(N-1). I am planning to make XPT inform SIM about supported tags for each device, to allow SIM to use that information while scheduling requests. I didn't do it yet, just because most of devices able to handle all 32 tags possible on SATA. This Intel SSD is one of rare exceptions. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 18:24:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE6331065670 for ; Wed, 18 Nov 2009 18:24:11 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6E06A8FC15 for ; Wed, 18 Nov 2009 18:24:11 +0000 (UTC) Received: by yxe1 with SMTP id 1so1307211yxe.3 for ; Wed, 18 Nov 2009 10:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=h45v3v50Q54VYQCIlffeAyHLWk7qd2TkdZsfHouXUL4=; b=ErHPG//PC73jeH/Dn5uhOhR+G2GpHP06rE+EYrssrf1Ozw82lSl+tefYgKvnfcJtIZ HmX9dXzh5KjhlVpDcj8EWW+L1r72xXefBNIn359dOFcS8h1Nqixub5bafxCQ6NUZdE6t C9QRLYAbl2EtoShd+ie4VvgqU3xgPaVL3B6Gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=Ty5e+XeXwn7FsIWh01tcTlQppqgrJNQ0EqBKcEYb93Upx6nEVQP/qV5m2tk0DoG2eP KC1VUCUSDLfy94bF7+ueFPEMMITNbxITOocq+4hwMOfL1gC1DFg3XqMlu51UvZFN7A7k cpwowb1+su61iUsR8eFbJ4vGFx0Pz0zbY9vBs= Received: by 10.101.72.10 with SMTP id z10mr1677580ank.122.1258568650342; Wed, 18 Nov 2009 10:24:10 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 9sm94907ywe.41.2009.11.18.10.24.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 10:24:08 -0800 (PST) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Wed, 18 Nov 2009 16:24:05 -0200 User-Agent: KMail/1.9.10 References: <200911172021.16848.gnemmi@gmail.com> <19e9a5dc0911171944q5d15dc96t83ecd53befb07621@mail.gmail.com> <0EB6E028-BA0A-48F1-AE7B-9F5E0A97B432@wanderview.com> In-Reply-To: <0EB6E028-BA0A-48F1-AE7B-9F5E0A97B432@wanderview.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911181624.05520.gnemmi@gmail.com> Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:24:11 -0000 On Wednesday 18 November 2009 10:28:40 am Ben Kelly wrote: > On Nov 17, 2009, at 10:44 PM, Gonzalo Nemmi wrote: > > On Tue, Nov 17, 2009 at 10:59 PM, Ben Kelly wrote: > >> On Nov 17, 2009, at 8:06 PM, Doug Barton wrote: > >>> Ben Kelly wrote: > >>>> It seems there are some left over bits then. I have this in > >> > >> /usr/src/sys/modules/Makefile: > >>>> .for reject in ${WITHOUT_MODULES} > >>>> SUBDIR:= ${SUBDIR:N${reject}} > >>>> .endfor > >>> > >>> Well it seems my search was not exhaustive. > >>> > >>> My recommendation then would be to file a src PR so that someone > >>> can look into it. :) > >> > >> I've opened a doc PR for the bad example in the handbook and a > >> conf PR for the patch to make WITHOUT_MODULES work from the kernel > >> config file using makeoptions. I haven't gotten PR numbers back > >> from the system yet. > >> > >> - Ben_______________________________________________ > > > > So, basically .. not only man make.conf and the handbook examples > > are wrong .. WITHOUT_MODULES doesn't actually work :s > > > > Thanks a lot for your research, testing, PR and patches Ben ! > > Please, should you be able to, I would like to know the PR number > > so I can follow it. > > Hope your patch makes it in and WITHOUT_MODULES works as expected > > :) > > No problem. > > Just to clarify, though. The content of man make.conf looks correct > to me and the variable did work if you put it in /etc/make.conf. The > only issues I saw were the example in the handbook and the failure of > makeoptions in the kernel config file. > > I do think you could get a number of the modules in your original > list excluded if you specified them differently: > > WITHOUT_MODULES=firewire bwi bce bfe iwi iwn zfs > > Basically remove the dev/ prefix you have on some of them. > > Hope that helps. > > - Ben Thank _you_ Ben. By following your good advice, I modified WITHOUT_MODULES and got it to look like this: WITHOUT_MODULES= firewire bwi bce bfe iwi iwn zfs 3dfx 3dfx_linux amdtemp en em ep esp et ex fe fdc ae age ale de ed ida ie if_faith igb nge reiserfs rl s3 ti tl xfs by doing so, I got rid of 70 modules and reduced kernel compile time considerably. I will be playing around with it (most likely trying to get just sound and snd_hda instead of every snd_ module .. and just if_bge instead of all of the if_someethcard modules) and see what I get. Should I get something interesting out of it, I will comment it in here. Once again, thanks a lot for your interest, investigations, work, kind answers, and good advice on this issue. I really appreciate it, and it _did_ help :) My Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 18:38:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4AD4106566C for ; Wed, 18 Nov 2009 18:38:40 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8E98FC0A for ; Wed, 18 Nov 2009 18:38:40 +0000 (UTC) Received: by gxk10 with SMTP id 10so1325128gxk.3 for ; Wed, 18 Nov 2009 10:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=w+PKVFuo8h496PolDvEtYGxDjgw6uJe1Nsda4NL3GZI=; b=IXJuxQ4Es3jlmUjTiU380LARPFbelPs0BpGpyjhkZ+FokBOIwZxV+3GuzDZinStPUt MLhJNfW/awYgOEnhA9q43dDP7a+nx5RZVHKukM1XPHGzSoTtRHMeAVi3f8v4//pRN8Hn h13V3zJBNp3ALEnjNxNol+MIrMhiYywQPk/sQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=ghapI3BPWbFyZw9yQvlj08JWrhd48zB67AGX9Hb7FKMbrYmLv1m8EBASKXsXdSRe/U Far6gQ4eTwhSeZtedT+E/uNJN1vab6VOnjhgSUXvcU7efoaXr7H9spb2vaCBcynpTefF IslFnGrS0oNX2keWRBrbjLW9+T8qdZy8gfWks= Received: by 10.100.233.35 with SMTP id f35mr683679anh.41.1258569518991; Wed, 18 Nov 2009 10:38:38 -0800 (PST) Received: from ?192.168.1.101? ([190.177.192.49]) by mx.google.com with ESMTPS id 9sm97968ywe.41.2009.11.18.10.38.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 10:38:38 -0800 (PST) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Wed, 18 Nov 2009 16:38:35 -0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200911181638.35675.gnemmi@gmail.com> Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:38:40 -0000 On Wednesday 18 November 2009 3:05:00 pm b. f. wrote: > >On 18 Nov 2009, at 14:01, Dag-Erling Sm=F8rgrav wrote: > >> Robert Watson writes: > >>> Olivier Smedts writes: > >>>> But someone (you, me...) can file a PR to add them to OLD_FILES > >>>> when WITHOUT_TELNET is set to yes, like it's done for some other > >>>> WITHOUT_ options. > >>> > >>> If it's done for other WITHOUT_ options, it's not obvious to me. > >> > >> tools/build/mk/OptionalObsoleteFiles.inc > >> > >> Poor placement IMHO, we shouldn't have dependencies from src into > >> tools. > > > >Its obscure location explains why it doesn't work. :-) Maybe it > > Not altogether: it works fine, for those knobs that developers have > seen fit to support in the file. The problem is that some developers > neglect it entirely. > > >should be src/OptionalFiles.inc? That said, it still sounds like a > > >significant maintenance problem to me: we have a lot of >WITHOUT_ > > options, and they may have non-trivial interactions... > > Being aware of what is built, and what is installed, is part of > maintaining the base system > is little more than writing down information that developers should > already have determined if they are properly supporting the various > base system knobs. =20 +10 > Along with the knobs, it's very useful to those=20 > of us who want to remove unneeded parts of the base system, and I > wish it was more conscientiously maintained. Let's not exaggerate > the difficulties involved in doing so. +10 > For the fellow who was concerned about removing his SSH port: yes, > it's something to consider. But you are not obliged to run make > delete-old[-libs], and even if you do want to run it, you can do so > without defining WITHOUT_SSH. > > Regards, > b. Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 19:02:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B020106566B for ; Wed, 18 Nov 2009 19:02:59 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 06B178FC08 for ; Wed, 18 Nov 2009 19:02:58 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 68CAB8C05F; Wed, 18 Nov 2009 13:02:58 -0600 (CST) Date: Wed, 18 Nov 2009 13:02:58 -0600 From: Mark Linimon To: Gonzalo Nemmi Message-ID: <20091118190258.GA17745@lonesome.com> References: <200911172021.16848.gnemmi@gmail.com> <20091117222923.GA63610@citylink.fud.org.nz> <200911172046.38561.gnemmi@gmail.com> <4B033032.5050301@elischer.org> <19e9a5dc0911171605t1032d668s55609e6436f7ab38@mail.gmail.com> <86ws1oul3c.fsf@ds4.des.no> <19e9a5dc0911180647g45a62a6do65450535f17b3947@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19e9a5dc0911180647g45a62a6do65450535f17b3947@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Wed, 18 Nov 2009 19:17:01 +0000 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_MODULES, does it actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:02:59 -0000 On Wed, Nov 18, 2009 at 11:47:19AM -0300, Gonzalo Nemmi wrote: > But just in case .. if that very same hand is used to slap me .. I will bite > it without a second thought .. and given hand will probably be left > unsuable. From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 19:32:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7988A1065670 for ; Wed, 18 Nov 2009 19:32:13 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 330BD8FC1A for ; Wed, 18 Nov 2009 19:32:12 +0000 (UTC) Received: by gxk10 with SMTP id 10so1379426gxk.3 for ; Wed, 18 Nov 2009 11:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=91e7mzcoshBH+KUeVsee/wVY4Q7htAtub2njScqOLJc=; b=xnBpzeiiW5wal2B6WxZW+EpIkKw1E9DUlWiWtvcTnzeOMK1k+vtGZPIHFVY3CrWNvS wtGmdARC2Zweb20bcCCqOp4f63jMViym/V2U3mGD1EO01pFQWgeOWv3SYT5faeJvABkT y8FNhGeNFHsTsAIyAY9qas+zJ2T1LsUzlW1z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fIl0qNGNguddJDCKMM6WqKLQVxYf/7yxE97e87j5KXoovETAiYTiJ+ZPeF+yOo+1gW gkuThM5sTId0Kpc7baZGciXmi2DFAuvu+0yNb5COXkZfiytt9+o2T+oIg32ZpzmeRx4r O0n8lBgYMIPWh5e77YF7Rsvhe7zAR08hHlxKY= MIME-Version: 1.0 Received: by 10.101.34.13 with SMTP id m13mr1816691anj.179.1258572732344; Wed, 18 Nov 2009 11:32:12 -0800 (PST) In-Reply-To: <20091118172332.GA8542@intserv.int1.b.intern> References: <20091118135340.522fa36a@ernst.jennejohn.org> <4B04020C.3080000@zedat.fu-berlin.de> <20091118172332.GA8542@intserv.int1.b.intern> Date: Wed, 18 Nov 2009 21:32:12 +0200 Message-ID: From: Dan Naumov To: Holger Kipp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 18 Nov 2009 19:42:49 +0000 Cc: freebsd-current , "O. Hartmann" Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 19:32:13 -0000 On Wed, Nov 18, 2009 at 7:23 PM, Holger Kipp wrote: > On Wed, Nov 18, 2009 at 04:25:09PM +0200, Dan Naumov wrote: >> 2009/11/18 O. Hartmann : >> > Gary Jennejohn wrote: >> >> >> >> On Wed, 18 Nov 2009 13:44:12 +0200 >> >> Dan Naumov wrote: >> >> >> >>>> WHy not just build from source? >> >>> >> >>> Because expecting users to build from source to install or update >> >>> their systems in the year 2009 is an outdated concept, this is why w= e >> >>> have freebsd-update in the first place. >> >>> >> >> >> >> This is such a load of BS I could fertilize 100 acres with it. >> >> >> >> In this day of inexpensive computers with fast mulit-core CPUs and >> >> gigabytes of memory this argument is completely lame. >> >> >> >> Fifteen years ago I would have agreed, because it took days to build >> >> world and the kernel. =A0Been there, done that. >> >> >> >> --- >> >> Gary Jennejohn >> > >> > Been there, did it, too. >> > >> > Fools, conceptually compromised by Microsofts closed-binary-strategy, = often >> > complain about 'why compiling, it is an outdated concept ...'. It is, = simply >> > in my opinion, a helpless selfdefense: they do not understand much abo= ut >> > operating systems (me, too) and never try to understand the concept be= hind >> > (me not). But today, having sophisticated binary update facilities, it= seems >> > to speed up a worse development: many companies save the computer-scie= ntist >> > to maintain their stuff - because they have a bunch of cheap fools >> > 'fertilizing the acres of foolsness' and pretending being the master o= f the >> > puppets by hitting an 'update-key' and everythings works magically ... >> >> This is unreasonable elitism. Having to jump through hoops, manually > > Ah no. If someone needs a precompiled system with everything, he can go > and use Windows or Linux. I prefer using *BSD _because_ I can compile > everything from scratch. And the build-system usually works much better > than many 'pre-compiled' binary systems on the market. "Can" and "have to" are 2 very different things. >> adjust Makefiles and spend time compiling just to apply a system >> update does NOT make you a "guru". It makes you waste time that could >> be better spent elsewhere. > > Usually adjusting Makefiles is not necessary, because the defaults are fi= ne > for most users. If you _need_ to adjust Makefiles, then a precompiled sol= ution > is definitely not suited to your needs. Trust me on that ;-) Or maybe the defaults are suboptimal? - Sincerely, Dan Naumov From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 19:58:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE4E10656A5 for ; Wed, 18 Nov 2009 19:58:07 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id F1F858FC0A for ; Wed, 18 Nov 2009 19:58:06 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=95yc-vNLuiYe651KPqsA:9 a=tO1Tdnpnr50_n6xx_KQA:7 a=IESemd89OBIrTjo0RNZLMmFoE08A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1148121268 for freebsd-current@freebsd.org; Wed, 18 Nov 2009 20:58:05 +0100 Received-SPF: softfail receiver=mailfe12.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 18 Nov 2009 20:59:33 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911182059.35769.hselasky@freebsd.org> Subject: [PATCH] Panic when inserting 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: Wed, 18 Nov 2009 19:58:07 -0000 Hi, I am sometimes using a PCCARD which panics the FreeBSD 9-current kernel due to generating some interrupts immediately when plugged in. Can someone add the required checks to handle spurious interrupts on non-enabled IRQ vectors? Backtrace: pccard_intr() cbb_func_intr() intr_event_execute_handlers() --HPS sys/dev/pccard/pccard.c static void pccard_intr(void *arg) { struct pccard_function *pf = (struct pccard_function*) arg; + if (pf == NULL || pf->intr_handler == NULL) return; pf->intr_handler(pf->intr_handler_arg); } From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 20:06:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68FEC106568F; Wed, 18 Nov 2009 20:06:13 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f190.google.com (mail-iw0-f190.google.com [209.85.223.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1326C8FC08; Wed, 18 Nov 2009 20:06:12 +0000 (UTC) Received: by iwn28 with SMTP id 28so1160070iwn.3 for ; Wed, 18 Nov 2009 12:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Eo4maJ+AIJRlwdJF1Z2L226gpZWkLfcrJqw1tABdd5U=; b=n3G726MWusmSGcL+47tmQ7wEzuqlB6B8Dsyci9blIr1nrjTrPK3z+b+YoFfKC03Sfu zQC5g6lLEru8SvJDNEDL4vnnKyn6k3LOcxK0X+WiOrGcy0/dw90O2iqUH5NH4kFmt1+Q qADr07i0i9YzaVFlB5p8Ffgu/LIFDkKvJZl6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PNurvBa1vFwUfpKPvEOcX/bv39PKg/LcKhZdMMlbGcSFTjmR+4pU7SrXjd5IreNyQe QSwNOO3jycoTU6fIVhl4YQXXwxmTRbgRX0YNOrdUd0zydHKTIS1CU8Yl4vCaGZ9FtpPI aSDHnxmyHCXFVob6NkO+f2sm8WPGXSewKkbvo= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.157.131 with SMTP id b3mr2592118ibx.19.1258574772303; Wed, 18 Nov 2009 12:06:12 -0800 (PST) In-Reply-To: <20091119021440.560884b2.nork@FreeBSD.org> References: <20091119004651.7432a6e4.nork@FreeBSD.org> <4B042304.8060807@FreeBSD.org> <20091119021440.560884b2.nork@FreeBSD.org> Date: Wed, 18 Nov 2009 12:06:12 -0800 X-Google-Sender-Auth: 97d7cf09ea154b93 Message-ID: From: Artem Belevich To: Norikatsu Shigemura , Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: How do I use NCQ of Intel X25-E(SSD) on ahci(4)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 20:06:13 -0000 > --- sys/dev/ahci/ahci.c.orig =A0 =A02009-11-17 22:25:07.474418000 +0900 > +++ sys/dev/ahci/ahci.c 2009-11-19 02:00:22.193688908 +0900 > @@ -779,7 +779,7 @@ > =A0 =A0 =A0 =A0ch->caps =3D ctlr->caps; > =A0 =A0 =A0 =A0ch->caps2 =3D ctlr->caps2; > =A0 =A0 =A0 =A0ch->quirks =3D ctlr->quirks; > - =A0 =A0 =A0 ch->numslots =3D ((ch->caps & AHCI_CAP_NCS) >> AHCI_CAP_NCS= _SHIFT) + 1, > + =A0 =A0 =A0 ch->numslots =3D min(31, ((ch->caps & AHCI_CAP_NCS) >> AHCI= _CAP_NCS_SHIFT) + 1), > =A0 =A0 =A0 =A0mtx_init(&ch->mtx, "AHCI channel lock", NULL, MTX_DEF); > =A0 =A0 =A0 =A0resource_int_value(device_get_name(dev), > =A0 =A0 =A0 =A0 =A0 =A0device_get_unit(dev), "pm_level", &ch->pm_level); The comma at the end of the "ch->numslots =3D ..." line looks suspicious. Shouldn't it be ';' ? --Artem From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 21:06:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2BB51065672 for ; Wed, 18 Nov 2009 21:06:47 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by mx1.freebsd.org (Postfix) with ESMTP id 6ABB28FC0C for ; Wed, 18 Nov 2009 21:06:47 +0000 (UTC) Received: by gv-out-0910.google.com with SMTP id p33so317792gvf.39 for ; Wed, 18 Nov 2009 13:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6iH1/TG7OF9zt3pUkQvl7kLgw201NOps9BtR9JvWgKw=; b=ebf0eu7Lr2YRgb5tJeToc/6h3Usj2AFGFWlWCVY43zMVl2322LSeKgGR21T8vY72bl bP6rFv3d6+bzG4KNC0od3NtINs7lwKDh3PRiu1SFccH8eMK/kNRbJ1uiXtKZkC/gKrKr ynHyjR8N/9D8yTS2UcaMJoXdBPJUA+3GYq1rs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qMPljhzQxX9tlS6WmCsA+4MAd3jzAFUPvmu9pgDtXtHWL1tq5VvGJAZO/DITB1whpv wLd3kVIa/5RTDsKG9/L4ar9CI9q2g3FhAlIKwi+49v4e+vJ+lTZLzp2XaPIqEGlNa7Qp E/NKEuN7z2s5nBrrHYkjbisbEdc/txr8gCYZQ= MIME-Version: 1.0 Received: by 10.239.139.211 with SMTP id u19mr1173079hbu.97.1258578406133; Wed, 18 Nov 2009 13:06:46 -0800 (PST) In-Reply-To: References: <20091118135340.522fa36a@ernst.jennejohn.org> <4B04020C.3080000@zedat.fu-berlin.de> <20091118172332.GA8542@intserv.int1.b.intern> Date: Wed, 18 Nov 2009 21:06:46 +0000 Message-ID: From: krad To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Holger Kipp , freebsd-current , "O. Hartmann" Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 21:06:48 -0000 2009/11/18 Dan Naumov > On Wed, Nov 18, 2009 at 7:23 PM, Holger Kipp wrote: > > On Wed, Nov 18, 2009 at 04:25:09PM +0200, Dan Naumov wrote: > >> 2009/11/18 O. Hartmann : > >> > Gary Jennejohn wrote: > >> >> > >> >> On Wed, 18 Nov 2009 13:44:12 +0200 > >> >> Dan Naumov wrote: > >> >> > >> >>>> WHy not just build from source? > >> >>> > >> >>> Because expecting users to build from source to install or update > >> >>> their systems in the year 2009 is an outdated concept, this is why > we > >> >>> have freebsd-update in the first place. > >> >>> > >> >> > >> >> This is such a load of BS I could fertilize 100 acres with it. > >> >> > >> >> In this day of inexpensive computers with fast mulit-core CPUs and > >> >> gigabytes of memory this argument is completely lame. > >> >> > >> >> Fifteen years ago I would have agreed, because it took days to build > >> >> world and the kernel. Been there, done that. > >> >> > >> >> --- > >> >> Gary Jennejohn > >> > > >> > Been there, did it, too. > >> > > >> > Fools, conceptually compromised by Microsofts closed-binary-strategy, > often > >> > complain about 'why compiling, it is an outdated concept ...'. It is, > simply > >> > in my opinion, a helpless selfdefense: they do not understand much > about > >> > operating systems (me, too) and never try to understand the concept > behind > >> > (me not). But today, having sophisticated binary update facilities, it > seems > >> > to speed up a worse development: many companies save the > computer-scientist > >> > to maintain their stuff - because they have a bunch of cheap fools > >> > 'fertilizing the acres of foolsness' and pretending being the master > of the > >> > puppets by hitting an 'update-key' and everythings works magically ... > >> > >> This is unreasonable elitism. Having to jump through hoops, manually > > > > Ah no. If someone needs a precompiled system with everything, he can go > > and use Windows or Linux. I prefer using *BSD _because_ I can compile > > everything from scratch. And the build-system usually works much better > > than many 'pre-compiled' binary systems on the market. > > "Can" and "have to" are 2 very different things. > > >> adjust Makefiles and spend time compiling just to apply a system > >> update does NOT make you a "guru". It makes you waste time that could > >> be better spent elsewhere. > > > > Usually adjusting Makefiles is not necessary, because the defaults are > fine > > for most users. If you _need_ to adjust Makefiles, then a precompiled > solution > > is definitely not suited to your needs. Trust me on that ;-) > > Or maybe the defaults are suboptimal? > > > - Sincerely, > Dan Naumov > _______________________________________________ > 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" > if you want upgrades to be more reliable you should really do it from source. Binary updates are fine however they have nowhere near as much run time on them than source updates. This is why I have always used source and always will. The speed argument isn't that valid either, as that is just down to not being organised. I have a build server at work as do i at home, and this builds a new world every night, so I always have one waiting for me to install. If I need to make a small adjustment to compile options I user the DNCLEAN options to speed things up. I also have the option of a full reinstall the next day as well if i need to. I do agree about sysinstall though in that its well outdated. It would be much better to have a livecd installer like opensolaris or ubuntu for novices. A fully functional (geom, zfs etc) install script language as well would be good as well for automated installations, but I can live without that. The biggest issue I have with the bsd loader is that you cant (as far as i can tell) hang it off the back of a pxe grub menu, making it difficult to build a heterogeneous jumpstart environment From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 21:29:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC1610656C1; Wed, 18 Nov 2009 21:29:22 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0428FC22; Wed, 18 Nov 2009 21:29:21 +0000 (UTC) Received: by fxm27 with SMTP id 27so1755962fxm.3 for ; Wed, 18 Nov 2009 13:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=TW2m6wSBJ5wyNoZjc1XKEeAFSIwpMjBJtK64dzVBQqM=; b=oHF4elBO3ZDGgZyXpvT9TygKXe6Gyf4r+m2GhXDE54o/jEmmm8DUgsG+wXyCZ+AZ/Q aB7wMPVA137pOtFZY+wZLV0LuiRTAg63+/Gny/PdhHfYsD2JUWcUgeyHJgDgfkUCuDjx lI+xTRxkFYdYULyDNG8lnn4rHUmsWiTd4RmUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Hcczl61qV9Yb8Dsclt2PatzXd+unsZ+KsOm3XJ1koXAmicu71PGqb7GpK9mLwtDNZc DwixsN7wFGnJYgscepvPklBMiwjy7KbhRD0qjZBHnvpYzzOJQXrizOb7/h3EPC1a5D16 h7kgE9nJTQW4tLxFZQSbMWTjlzFgWGSPMN13g= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.90.209 with SMTP id e59mr1531127wef.193.1258579761276; Wed, 18 Nov 2009 13:29:21 -0800 (PST) In-Reply-To: <4B043751.7080302@FreeBSD.org> References: <4B042304.8060807@FreeBSD.org> <4B043751.7080302@FreeBSD.org> From: Ivan Voras Date: Wed, 18 Nov 2009 22:29:01 +0100 X-Google-Sender-Auth: 058f8ec6105eee43 Message-ID: <9bbcef730911181329l14ca1e79xf18a4c6f3d0b04c0@mail.gmail.com> To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-Current Subject: Re: How do I use NCQ of Intel X25-E(SSD) on ahci(4)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 21:29:22 -0000 2009/11/18 Alexander Motin : > Ivan Voras wrote: >> I know next to nothing about AHCI and drivers so this might be obviously >> wrong but wouldn't a quick (i.e. MFC-able) obvious temporary fix be to say >> >> numslots = min(get_minimum_tags_of_all_drives(), ...) >> ? > > Problem is that SIM driver has no idea about devices capabilities, and > also doesn't have method to resize queue after attach. In SCSI case, > tags are random and only simultaneous number of request is limited, and > this is handled fine by CAM. SATA NCQ is more restrictive, allowing to > use only tags 0..(N-1). I am planning to make XPT inform SIM about > supported tags for each device, to allow SIM to use that information > while scheduling requests. I didn't do it yet, just because most of > devices able to handle all 32 tags possible on SATA. This Intel SSD is > one of rare exceptions. Ok, (still thinking about something that could be MFC-able in an emergency), how about adding a loader tunable integer instead of "32"? From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 22:55:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C6AB1065670 for ; Wed, 18 Nov 2009 22:55:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f204.google.com (mail-qy0-f204.google.com [209.85.221.204]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF678FC13 for ; Wed, 18 Nov 2009 22:55:57 +0000 (UTC) Received: by qyk42 with SMTP id 42so941086qyk.28 for ; Wed, 18 Nov 2009 14:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=STdA1DMjDr+wMWn5Sgey9jDhU1b9wohNDW/+CQsZX7o=; b=wUYk4AIlZf8/ICjt4C3Ze+TnbD54fagcQ1iEVNelrFgbo0/kEQeI0rr5B8HwoRv033 lH0ZhJcImZfXkmWPZ/x5bOHg21E4JU3HdeAZHMMXdkldPKr5dnm81gWZIo8xznKqTe8L Trrb/LENY/0cHh8lQuIQhTXk7L2dB0kMuzaGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=QoXKgY7Paz3P9md/eO48sVhf2aLzhLqxCXD0aE8dgOdk846y9WK41yaEhU9cbrQPF8 6+TUHTCcC8hFkBqXtdBx3l/ef3Dxkvhhp27txFoHyhgPrYxBo0unG65FZkXvI+QrlPnA Vg2OCAmXjD0w+uTwB9XJthEX6hsLTJHEnUbMk= Received: by 10.224.88.93 with SMTP id z29mr6783675qal.54.1258584951199; Wed, 18 Nov 2009 14:55:51 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm789792qwb.2.2009.11.18.14.55.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 14:55:49 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 18 Nov 2009 14:55:21 -0800 From: Pyun YongHyeon Date: Wed, 18 Nov 2009 14:55:21 -0800 To: Warren Block Message-ID: <20091118225521.GO1262@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Pk6IbRAofICFmK5e" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: sendmail aliases/Realtek 8111 problem (bin/139870) 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, 18 Nov 2009 22:55:57 -0000 --Pk6IbRAofICFmK5e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 17, 2009 at 07:55:43PM -0700, Warren Block wrote: > sendmail was ignoring existing aliases on startup. This is apparently > due to a network interface not being ready in time in combination with a > not-FQDN hostname. > > With a hostname of "lightning" (no domain), re0 configured by DHCP, and > verbose sendmail logging: > > 050 WARNING: interface re0 is UP with 0.0.0.0 address > 050 WARNING: local host name (lightning) is not qualified; see cf/README: > WHO AM I > > A restart of sendmail after startup works normally because re0 has > acquired an address by then. Entering a FQDN as hostname > (hostname="lightning.wonkity.com") in rc.conf works also. > > I would say that this is really a problem with re0 and not with sendmail > startup, but don't really know. > > re0 does a DOWN/UP three times on startup. > I'm not sure but this can happen on all systems that have to use DHCP. The problem I can see here is unnecessary re(4) interface reinitialization triggered by dhclient even if it can avoid most of them. Would you try attached patch? It may reduce the number of interface UP/DOWNs during getting an IP address via DHCP. I haven't tested the patch though, I no longer have access to re(4) hardwares. > re0: 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe Gigabit > Ethernet> port 0xe800-0xe8ff mem > 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 17 at device 0.0 on pci4 > > re0@pci0:4:0:0: class=0x020000 card=0x514c1462 chip=0x816810ec > rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' > class = network > subclass = ethernet > > -Warren Block * Rapid City, South Dakota USA --Pk6IbRAofICFmK5e Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.init.patch" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 199490) +++ sys/dev/re/if_re.c (working copy) @@ -753,6 +753,7 @@ ifp->if_flags |= IFF_PROMISC; sc->rl_testmode = 1; + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; re_init_locked(sc); sc->rl_flags |= RL_FLAG_LINK; if (sc->rl_type == RL_8169) @@ -2145,8 +2146,10 @@ * XXX check behaviour on receiver stalls. */ - if (status & RL_ISR_SYSTEM_ERR) + if (status & RL_ISR_SYSTEM_ERR) { + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; re_init_locked(sc); + } } return (rx_npkts); } @@ -2222,8 +2225,10 @@ RL_ISR_TX_ERR|RL_ISR_TX_DESC_UNAVAIL)) re_txeof(sc); - if (status & RL_ISR_SYSTEM_ERR) + if (status & RL_ISR_SYSTEM_ERR) { + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; re_init_locked(sc); + } if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) taskqueue_enqueue_fast(taskqueue_fast, &sc->rl_txtask); @@ -2539,6 +2544,9 @@ mii = device_get_softc(sc->rl_miibus); + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) + return; + /* * Cancel pending I/O and free all RX/TX buffers. */ @@ -2793,7 +2801,8 @@ case SIOCADDMULTI: case SIOCDELMULTI: RL_LOCK(sc); - re_set_rxmode(sc); + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) + re_set_rxmode(sc); RL_UNLOCK(sc); break; case SIOCGIFMEDIA: @@ -2862,8 +2871,10 @@ if ((mask & IFCAP_WOL_MAGIC) != 0) ifp->if_capenable ^= IFCAP_WOL_MAGIC; } - if (reinit && ifp->if_drv_flags & IFF_DRV_RUNNING) + if (reinit && ifp->if_drv_flags & IFF_DRV_RUNNING) { + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; re_init(sc); + } VLAN_CAPABILITIES(ifp); } break; @@ -2899,6 +2910,7 @@ ifp->if_oerrors++; re_rxeof(sc, NULL); + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; re_init_locked(sc); if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) taskqueue_enqueue_fast(taskqueue_fast, &sc->rl_txtask); @@ -3011,15 +3023,16 @@ CSR_READ_1(sc, RL_GPIO) | 0x01); } - /* reinitialize interface if necessary */ - if (ifp->if_flags & IFF_UP) - re_init_locked(sc); - /* * Clear WOL matching such that normal Rx filtering * wouldn't interfere with WOL patterns. */ re_clrwol(sc); + + /* reinitialize interface if necessary */ + if (ifp->if_flags & IFF_UP) + re_init_locked(sc); + sc->suspended = 0; RL_UNLOCK(sc); --Pk6IbRAofICFmK5e-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 18 23:48:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E26A1065697; Wed, 18 Nov 2009 23:48:05 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by mx1.freebsd.org (Postfix) with ESMTP id DA4D08FC12; Wed, 18 Nov 2009 23:48:04 +0000 (UTC) Received: by ywh8 with SMTP id 8so1614197ywh.3 for ; Wed, 18 Nov 2009 15:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/44jw8zlKKtLGe85/WV4F5SWRkjeSOlRfGuQdX9hl2E=; b=iD4mn9Xlim6XA2MyYBpqvHEpcFpajRVQQ3trStZQRB+otwkiWOUNI/qZbSSb+t6CEp v8kEBnd6QaIvoGVTVt6W+4j8TFwkA2hZdZJXBwzixQtMJ2AS0mTMwFsC9OORl46R8vek ejA8j18QHKA4WNH9eL7pYNUBhnCg1HsdnpqZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mDNkwi3o6PVuHqI/pkiJrO5ZQ9EY/NZuSrriDnFpuNhin0SgzLcvpG7ibeiInnfYQl STpR0HnRDncR/L29PYfkJwUEz8oznnijUqOxH8rL74HhIQB9TYTXzDAycrALgJZokMAb IQTFj+gKjAB15e3h2AYQZoxODqnTVk2i8cBZI= MIME-Version: 1.0 Received: by 10.150.130.24 with SMTP id c24mr3474103ybd.168.1258588083989; Wed, 18 Nov 2009 15:48:03 -0800 (PST) In-Reply-To: <1258562628.2303.83.camel@balrog.2hip.net> References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 15:48:03 -0800 Message-ID: From: Matt Reimer To: Emil Smolenski Content-Type: multipart/mixed; boundary=000e0cd5a01aaa2bdf0478addf54 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Robert Noland Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2009 23:48:05 -0000 --000e0cd5a01aaa2bdf0478addf54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 18, 2009 at 8:43 AM, Robert Noland wrote: > On Wed, 2009-11-18 at 17:11 +0100, Emil Smolenski wrote: >> On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland >> wrote: >> >> >> >> Should I file a PR? I would >> >> >> like to help in debugging it (however my skills in low-level C are= n't >> >> >> strong enough to do it on my own). >> >> > Ok, the first thing I would like to see is "zdb -uuu". >> >> # zdb -uuu pgpool >> >> Segmentation fault: 11 (core dumped) >> >> > Ok, this is disturbing... =A0It works fine for me on -CURRENT / amd64 = and >> > reports the root block pointer, which is what we need to locate the MO= S. >> >> =A0 Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb -u= uu" >> happy: >> >> Fixit# zdb -uuu pgpool >> Uberblock >> >> =A0 =A0 =A0 =A0 =A0magic =3D 0000000000bab10c >> =A0 =A0 =A0 =A0 =A0version =3D 13 >> =A0 =A0 =A0 =A0 =A0txg =3D 443448 >> =A0 =A0 =A0 =A0 =A0guid_sum =3D 9780688847620645377 >> =A0 =A0 =A0 =A0 =A0timestamp =3D 1258560175 UTC =3D Wed Nov 18 16:02:55 = 2009 >> =A0 =A0 =A0 =A0 =A0rootbp =3D [L0 DMU objset] 400L/200P DVA[0]=3D<0:2200= 00de400:200> >> DVA[1]=3D<0:2a80008ee00:200> DVA[2]=3D<0:330000b9000:200> fletcher4 lzjb= LE >> contiguous birth=3D443448 fill=3D298 >> cksum=3D8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac > > Ok, the offsets are definately up there... What is your normal > installation? =A08.0 i386? Robert's on to something. It looks like your LBAs are probably overflowing 32 bits. This would affect all vdev regardless of type. Try the attached patch. Matt --000e0cd5a01aaa2bdf0478addf54 Content-Type: application/octet-stream; name="zfsboot.c.patch3" Content-Disposition: attachment; filename="zfsboot.c.patch3" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g26qtvfe0 LS0tIGkzODYvemZzYm9vdC96ZnNib290LmMub3JpZwkyMDA5LTEwLTI0IDE4OjEwOjI5LjAwMDAw MDAwMCAtMDcwMAorKysgaTM4Ni96ZnNib290L3pmc2Jvb3QuYwkyMDA5LTExLTE4IDE1OjM2OjM0 LjAwMDAwMDAwMCAtMDgwMApAQCAtMTYzLDcgKzE2Myw3IEBACiBzdGF0aWMgdm9pZCBwcmludGYo Y29uc3QgY2hhciAqLC4uLik7CiBzdGF0aWMgdm9pZCBwdXRjaGFyKGludCk7CiBzdGF0aWMgdWlu dDMyX3QgbWVtc2l6ZSh2b2lkKTsKLXN0YXRpYyBpbnQgZHJ2cmVhZChzdHJ1Y3QgZHNrICosIHZv aWQgKiwgdW5zaWduZWQsIHVuc2lnbmVkKTsKK3N0YXRpYyBpbnQgZHJ2cmVhZChzdHJ1Y3QgZHNr ICosIHZvaWQgKiwgdWludDY0X3QsIHVuc2lnbmVkKTsKIHN0YXRpYyBpbnQga2V5aGl0KHVuc2ln bmVkKTsKIHN0YXRpYyBpbnQgeHB1dGMoaW50KTsKIHN0YXRpYyBpbnQgeGdldGMoaW50KTsKQEAg LTMxMCw3ICszMTEsOCBAQAogdmRldl9yZWFkKHZkZXZfdCAqdmRldiwgdm9pZCAqcHJpdiwgb2Zm X3Qgb2ZmLCB2b2lkICpidWYsIHNpemVfdCBieXRlcykKIHsKIAljaGFyICpwOwotCXVuc2lnbmVk IGludCBsYmEsIG5iOworCXVpbnQ2NF90IGxiYTsKKwl1bnNpZ25lZCBpbnQgbmI7CiAJc3RydWN0 IGRzayAqZHNrID0gKHN0cnVjdCBkc2sgKikgcHJpdjsKIAogCWlmICgob2ZmICYgKERFVl9CU0la RSAtIDEpKSB8fCAoYnl0ZXMgJiAoREVWX0JTSVpFIC0gMSkpKQpAQCAtOTQ5LDcgKzk1MSw3IEBA CiAjZW5kaWYKIAogc3RhdGljIGludAotZHJ2cmVhZChzdHJ1Y3QgZHNrICpkc2ssIHZvaWQgKmJ1 ZiwgdW5zaWduZWQgbGJhLCB1bnNpZ25lZCBuYmxrKQorZHJ2cmVhZChzdHJ1Y3QgZHNrICpkc2ss IHZvaWQgKmJ1ZiwgdWludDY0X3QgbGJhLCB1bnNpZ25lZCBuYmxrKQogewogI2lmZGVmIEdQVAog ICAgIHN0YXRpYyB1bnNpZ25lZCBjID0gMHgyZDVjN2MyZjsK --000e0cd5a01aaa2bdf0478addf54-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 00:43:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78AEF1065670 for ; Thu, 19 Nov 2009 00:43:39 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1538FC1B for ; Thu, 19 Nov 2009 00:43:38 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id nAJ0hcCq003355; Wed, 18 Nov 2009 17:43:38 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id nAJ0hc37003352; Wed, 18 Nov 2009 17:43:38 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 18 Nov 2009 17:43:38 -0700 (MST) From: Warren Block To: Pyun YongHyeon In-Reply-To: <20091118225521.GO1262@michelle.cdnetworks.com> Message-ID: References: <20091118225521.GO1262@michelle.cdnetworks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Content-Disposition: INLINE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (wonkity.com [127.0.0.1]); Wed, 18 Nov 2009 17:43:38 -0700 (MST) Cc: current@freebsd.org Subject: Re: sendmail aliases/Realtek 8111 problem (bin/139870) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 00:43:40 -0000 On Wed, 18 Nov 2009, Pyun YongHyeon wrote: > On Tue, Nov 17, 2009 at 07:55:43PM -0700, Warren Block wrote: >> sendmail was ignoring existing aliases on startup. This is apparently >> due to a network interface not being ready in time in combination with a >> not-FQDN hostname. >> >> With a hostname of "lightning" (no domain), re0 configured by DHCP, and >> verbose sendmail logging: >> >> 050 WARNING: interface re0 is UP with 0.0.0.0 address >> 050 WARNING: local host name (lightning) is not qualified; see cf/README: >> WHO AM I [...] > I'm not sure but this can happen on all systems that have to use > DHCP. The problem I can see here is unnecessary re(4) interface > reinitialization triggered by dhclient even if it can avoid most of > them. Would you try attached patch? It may reduce the number of > interface UP/DOWNs during getting an IP address via DHCP. I haven't > tested the patch though, I no longer have access to re(4) > hardwares. That solves it, thanks! Only the one "link state changed to UP", and no problem with sendmail when the interface gets an address in time. No unwanted side effects noticed. Too soon to say "please commit"? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 00:58:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A654C1065672 for ; Thu, 19 Nov 2009 00:58:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 57DD58FC19 for ; Thu, 19 Nov 2009 00:58:09 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so386929qwb.7 for ; Wed, 18 Nov 2009 16:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=+AVFSGDXg9N2DTf4rYFVmm05fKwK9GGJNuWxtVNRCXk=; b=f0VIICfV7gB8AeUGByKz0iqt6Wow5giIO6q4LfZCIY6zJDN11byN1Lnwe35X3aMnhX LP8rBYPFpY6OX6Q2czxx13krMQ6/rxxF+y0ZR8TTkvfO2mFNQpPVLBhZO/DWpZXiKg5g d74FhCYlxLE562FfHCSMZRLtIZvEHUEvLS350= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aohc5BjTnuG5oUYdbTdDkfaq+hnng6X/ez2jFXXqf8ERpVX4JEfIjWr6Z6rXCfcpzm us3qYhQKFQ0iZUhwSlhvU6MoxNr4v/21SmdbpSGpehx+9aujyRW9PYNxi3B9UTsp3D+a VPbUNIC2udmFUkCrkzesXizuGeunG0Rk0nBlI= Received: by 10.224.79.37 with SMTP id n37mr6809461qak.194.1258592288686; Wed, 18 Nov 2009 16:58:08 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm48202qyk.4.2009.11.18.16.58.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 16:58:07 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 18 Nov 2009 16:57:39 -0800 From: Pyun YongHyeon Date: Wed, 18 Nov 2009 16:57:39 -0800 To: Warren Block Message-ID: <20091119005739.GQ1262@michelle.cdnetworks.com> References: <20091118225521.GO1262@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: sendmail aliases/Realtek 8111 problem (bin/139870) 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, 19 Nov 2009 00:58:09 -0000 On Wed, Nov 18, 2009 at 05:43:38PM -0700, Warren Block wrote: > On Wed, 18 Nov 2009, Pyun YongHyeon wrote: > > >On Tue, Nov 17, 2009 at 07:55:43PM -0700, Warren Block wrote: > >>sendmail was ignoring existing aliases on startup. This is apparently > >>due to a network interface not being ready in time in combination with a > >>not-FQDN hostname. > >> > >>With a hostname of "lightning" (no domain), re0 configured by DHCP, and > >>verbose sendmail logging: > >> > >>050 WARNING: interface re0 is UP with 0.0.0.0 address > >>050 WARNING: local host name (lightning) is not qualified; see cf/README: > >>WHO AM I > > [...] > > >I'm not sure but this can happen on all systems that have to use > >DHCP. The problem I can see here is unnecessary re(4) interface > >reinitialization triggered by dhclient even if it can avoid most of > >them. Would you try attached patch? It may reduce the number of > >interface UP/DOWNs during getting an IP address via DHCP. I haven't > >tested the patch though, I no longer have access to re(4) > >hardwares. > > That solves it, thanks! Only the one "link state changed to UP", and no This is an expected behavior. > problem with sendmail when the interface gets an address in time. No > unwanted side effects noticed. Too soon to say "please commit"? > Will do it tomorrow. Thanks for testing and quick response! > -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 01:33:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D59111065670; Thu, 19 Nov 2009 01:33:03 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 059CF8FC08; Thu, 19 Nov 2009 01:33:02 +0000 (UTC) Received: by bwz5 with SMTP id 5so2041126bwz.3 for ; Wed, 18 Nov 2009 17:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=d/QeKH7Mrm6ZuT5A6r1EZgXKE//BavuLaFDzom6KVCc=; b=EG/UNoc9zx6k/W4GvAc8+a+YNNRYJmyxFi5JrpijAPAit7lb9V890oT/rxX2BPe0ug MMrUSgXrZo1rxvica1KBcXWdmyDtJrUXnKahtxxn2koiuL/pgQBQJydTXJwIgtUv3x2+ escxuUFbXS8IqZy9voRMLHxWWwNZ8rXq9lyIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=F800/b3AGjSM1DCOjNFoMkGw2nJW6jDVdmP7liy7WHFkZzpwwGz8SKSrnh8BR7UHAu g5GawvaTqVNeP5eQB7lUP4e60djVEJnqhdI+tCfS6ZV8eFUqexsgVprgQu2BLGKS3aaB sj5k+SRUB8q3S+jZ8Q5ulNf8SS14jCCc3QOWo= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.4.193 with SMTP id 1mr2862360fas.12.1258594381951; Wed, 18 Nov 2009 17:33:01 -0800 (PST) In-Reply-To: <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> Date: Thu, 19 Nov 2009 02:33:01 +0100 X-Google-Sender-Auth: 9b6d5f7c7682a6f2 Message-ID: <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 01:33:03 -0000 2009/11/17 Robert N. M. Watson : > > On 17 Nov 2009, at 14:17, Ed Maste wrote: > >> Our original motivation for doing this was to make gcore work with >> threaded apps, not avoiding procfs, but that's a useful side-effect of >> the work. Note though that for that purpose it isn't complete; procfs >> is still used in readmap to read the process' memory map. It looks like >> we need to find a way to implement readmap without procfs. > > Are the sysctls used for procstat -v sufficient for this purpose? This patch should address the arised concerns by both of you: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore2.diff and additively fix elf_getstatus() to not use procfs, so that gcore is completely procfs independent now. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 02:33:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 584B8106566B for ; Thu, 19 Nov 2009 02:33:06 +0000 (UTC) (envelope-from efinley.lists@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id F0E458FC1E for ; Thu, 19 Nov 2009 02:33:05 +0000 (UTC) Received: by pxi12 with SMTP id 12so1224287pxi.3 for ; Wed, 18 Nov 2009 18:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=uVWHYzl9CDh0DQ2ar3HErUd8tdO5LZtd4X7SLl2cVNk=; b=ma3RpYkELIC38V7ljsJw/Mzs52opLP+YK6QjH2b7GaFo5YMgJa8ittf3fQ+AKLgwqL L96wMrC3hIIpGeoU3rQmFj7rdft0XnWjOoi2tA+0fPIQHZsr/cJfKPPoACVgQfF9RtVy KDouS+gg2Ys26WHFqiRSucEVncHYksSm4gWp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HOiygcQ9sMO5tKrICmmi0/IJP28ON7Cfblc2TYgMFuyPEv5wtsGa+Jv0XMJL4OYerw PGLt9xrH0WWdI+lax4TVppIf0xWJ7YH1sqrrJX3e49DGGQ8Dx1OjTfZJf3eqeXrJ203M H+4t27uhKrd0an5wZclHG5+CO3Qk3UvEj5+hg= MIME-Version: 1.0 Received: by 10.142.120.8 with SMTP id s8mr1364614wfc.276.1258596420689; Wed, 18 Nov 2009 18:07:00 -0800 (PST) Date: Wed, 18 Nov 2009 19:07:00 -0700 Message-ID: <54e63c320911181807m4ddb770br1281d1163ae3cf5f@mail.gmail.com> From: Elliot Finley To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 8.0-RC3 network performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 02:33:06 -0000 I have several boxes running 8.0-RC3 with pretty dismal network performance. I also have some 7.2 boxes with great performance. Using iperf I did some tests: server(8.0) <- client (8.0) == 420Mbps server(7.2) <- client (7.2) == 950Mbps server(7.2) <- client (8.0) == 920Mbps server(8.0) <- client (7.2) == 420Mbps so when the server is 7.2, I have good performance regardless of whether the client is 8.0 or 7.2. when the server is 8.0, I have poor performance regardless of whether the client is 8.0 or 7.2. Has anyone else noticed this? Am I missing something simple? TIA Elliot From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 03:57:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B90106566B; Thu, 19 Nov 2009 03:57:55 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA178FC08; Thu, 19 Nov 2009 03:57:54 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-213-186.bna.bellsouth.net [68.19.213.186]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAJ3vgRV022203 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 22:57:45 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Matt Reimer In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Wed, 18 Nov 2009 21:57:37 -0600 Message-Id: <1258603057.2303.92.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Emil Smolenski Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 03:57:55 -0000 On Wed, 2009-11-18 at 15:48 -0800, Matt Reimer wrote: > 220000de400 This divided by 512 byte block size is 33 bits... At a glance, the patch looks ok to me. I'll do a more thorough review of this tomorrow. robert. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 04:27:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EFA51065672 for ; Thu, 19 Nov 2009 04:27:04 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 250228FC19 for ; Thu, 19 Nov 2009 04:27:03 +0000 (UTC) Received: by bwz5 with SMTP id 5so2141646bwz.3 for ; Wed, 18 Nov 2009 20:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=hckNXMdw6nbP8XVtrplQTU+mwooTKgJNevQal6yHuhw=; b=wxkZhpvzoanzOwhWS7bP1SMUmY3lOPMcitek8+UbhOMyI6vZjv05Q+vTNwavxVwCLW Jb13ObXV0GGc9y13sYKSEwtZt+r+MB9VGY8L33qFc8XRjC0fihW6bpNohexVkfxLhir4 Y3iaIlitj/CGF8YjQk0lja30zjoqYyfXU+7IQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LxXVBwq1xEqUK2jVkqVp67kCcJ884GAP9Z8B4jL13ORmkiezvKu6ygnG0KVcTnPCTG /i0q0sa7R3WiOZYMduGHe27nJ0ULePm7eIKSK1vsLVe6PyLm0oEe8QMG0D9RhxTMDg6a sls/lYrfLpYNJaJCOOlVcQZsXHzvfzoae8kiQ= MIME-Version: 1.0 Received: by 10.103.87.26 with SMTP id p26mr809305mul.44.1258604823117; Wed, 18 Nov 2009 20:27:03 -0800 (PST) In-Reply-To: <20091118233225.GP1262@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911171650.06834.gnemmi@gmail.com> <20091117193208.GI1262@michelle.cdnetworks.com> <200911171917.41906.gnemmi@gmail.com> <20091117232347.GJ1262@michelle.cdnetworks.com> <20091118005724.GK1262@michelle.cdnetworks.com> <19e9a5dc0911172040g1107423ck72d30460b030ca27@mail.gmail.com> <20091118233225.GP1262@michelle.cdnetworks.com> Date: Thu, 19 Nov 2009 01:27:03 -0300 Message-ID: <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Call for bge(4) 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: Thu, 19 Nov 2009 04:27:04 -0000 On Wed, Nov 18, 2009 at 8:32 PM, Pyun YongHyeon wrote: > On Wed, Nov 18, 2009 at 01:40:24AM -0300, Gonzalo Nemmi wrote: > > [...] > > > I just tried ... > > echo 'hw.bge.allow_asf="1"' >> /boot/loader.conf > > reboot > > load if_bge > > acpiconf -s3 > > same results :( > > > > Ok, here is new try. > Let's get on to it then ! Well now, the situation has improved .. here's what I got: http://pastebin.com/f2d152f91 lines 2 to 8 == kldload if_bge line 9 == acpiconf -s3 lines 10 to 18 == resume (notice there are only 2 messages now: lines 12 and 13!) lines 19 to 36 == ifconfig bge0 lines 37 to 42 == me mounting the pendrive to get the messages from /var/log/messages =P lines 43 to 46 == kldunload if_bge0 I think you narrowed it down quite a lot this time ! I have to warn you though, that this time, my kernel was compiled using a ... certainly modified /etc/make.conf file ... just in case you need to know how it looks like, you'll fin it in here: http://pastebin.com/f42e356d2 If you think that make.conf config may interfere with your pourposes or tests, just let me know and I'll use a default one. The good thing about that make.conf is that it saves me quite a time on every recompile ;) > im at your service .. tell me what to do and I'll do it :) > > > > Thanks a lot for your patience and continuous support to fixing > bugs. > Thank _YOU_ for keeping the good work up and for trying to solve a really nasty bug that makes every bge(4) user (think of it _as_every_dell_notebook_owner_) unable to get his laptop to resume .. or even use FreeBSD altoghether just because of this. Dear Pyung, rest assured that as long as you remain commited to fix this, or any other bug that I can help you with, you can count on me to do everything that may be within the reach of my hand. As long as you remain commited, I'll be there, commited just as well :) Awaiting further orders Yours Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 08:02:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 662E3106566B; Thu, 19 Nov 2009 08:02:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3C76C8FC1D; Thu, 19 Nov 2009 08:02:57 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C1E6B46B2E; Thu, 19 Nov 2009 03:02:56 -0500 (EST) Date: Thu, 19 Nov 2009 08:02:56 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> Message-ID: References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 08:02:57 -0000 On Thu, 19 Nov 2009, Attilio Rao wrote: > 2009/11/17 Robert N. M. Watson : >> >> On 17 Nov 2009, at 14:17, Ed Maste wrote: >> >>> Our original motivation for doing this was to make gcore work with >>> threaded apps, not avoiding procfs, but that's a useful side-effect of the >>> work. Note though that for that purpose it isn't complete; procfs is >>> still used in readmap to read the process' memory map. It looks like we >>> need to find a way to implement readmap without procfs. >> >> Are the sysctls used for procstat -v sufficient for this purpose? > > This patch should address the arised concerns by both of you: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore2.diff > > and additively fix elf_getstatus() to not use procfs, so that gcore is > completely procfs independent now. Comments, reviews and testing are > welcome. If you add the missing include of sys/wait.h, elfcore.c generates an error instead of a warning on this non-traditional use of wait(2): + wait(); Something like this may be preferred: if (waitpid(pid, NULL, 0) < 0) err(1, "waitpid"); This further persisting reference to procfs can be replaced with a sysctl/kvm interface: gcore.c: asprintf(&binfile, "/proc/%d/file", pid); See the implementation of "procstat -b" which returns the path to the binary using the same underlying mechanism (vn_fullpath on the process image vnode). I think that kills the last of the procfs dependencies, in which case perhaps we can remove the procfs.h include from elfcore.c, which requires defining a local version of a summary data structure borrowed from procfs. It's worth trying with procfs unmounted, however, to make sure they're really all gone (which is how I ran into the above problem). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 09:06:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C769C10656A6; Thu, 19 Nov 2009 09:06:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9CEDB8FC26; Thu, 19 Nov 2009 09:06:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAJ96Req018123; Thu, 19 Nov 2009 04:06:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAJ96R6N018114; Thu, 19 Nov 2009 09:06:27 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 19 Nov 2009 09:06:27 GMT Message-Id: <200911190906.nAJ96R6N018114@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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, 19 Nov 2009 09:06:28 -0000 TB --- 2009-11-19 07:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-19 07:55:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-11-19 07:55:00 - cleaning the object tree TB --- 2009-11-19 07:55:27 - cvsupping the source tree TB --- 2009-11-19 07:55:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-11-19 07:56:55 - building world TB --- 2009-11-19 07:56:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 07:56:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 07:56:55 - TARGET=pc98 TB --- 2009-11-19 07:56:55 - TARGET_ARCH=i386 TB --- 2009-11-19 07:56:55 - TZ=UTC TB --- 2009-11-19 07:56:55 - __MAKE_CONF=/dev/null TB --- 2009-11-19 07:56:55 - cd /src TB --- 2009-11-19 07:56:55 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 19 07:56:55 UTC 2009 >>> 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 Thu Nov 19 08:54:59 UTC 2009 TB --- 2009-11-19 08:54:59 - generating LINT kernel config TB --- 2009-11-19 08:54:59 - cd /src/sys/pc98/conf TB --- 2009-11-19 08:54:59 - /usr/bin/make -B LINT TB --- 2009-11-19 08:54:59 - building LINT kernel TB --- 2009-11-19 08:54:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 08:54:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 08:54:59 - TARGET=pc98 TB --- 2009-11-19 08:54:59 - TARGET_ARCH=i386 TB --- 2009-11-19 08:54:59 - TZ=UTC TB --- 2009-11-19 08:54:59 - __MAKE_CONF=/dev/null TB --- 2009-11-19 08:54:59 - cd /src TB --- 2009-11-19 08:54:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 19 08:54:59 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -pg -mprofiler-epilogue /src/sys/i386/i386/atomic.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/bios.c 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 -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror /src/sys/i386/i386/bioscall.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 -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/bpf_jit_machdep.c cc1: warnings being treated as errors /src/sys/i386/i386/bpf_jit_machdep.c: In function 'bpf_jit_compile': /src/sys/i386/i386/bpf_jit_machdep.c:517: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-19 09:06:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-19 09:06:27 - ERROR: failed to build lint kernel TB --- 2009-11-19 09:06:27 - 3188.58 user 685.15 system 4287.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 09:11:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0429B106566C for ; Thu, 19 Nov 2009 09:11:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D20AC8FC12 for ; Thu, 19 Nov 2009 09:11:19 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6285446B1A; Thu, 19 Nov 2009 04:11:19 -0500 (EST) Date: Thu, 19 Nov 2009 09:11:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Elliot Finley In-Reply-To: <54e63c320911181807m4ddb770br1281d1163ae3cf5f@mail.gmail.com> Message-ID: References: <54e63c320911181807m4ddb770br1281d1163ae3cf5f@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: 8.0-RC3 network performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 09:11:20 -0000 On Wed, 18 Nov 2009, Elliot Finley wrote: > I have several boxes running 8.0-RC3 with pretty dismal network performance. > I also have some 7.2 boxes with great performance. Using iperf I did some > tests: > > server(8.0) <- client (8.0) == 420Mbps > server(7.2) <- client (7.2) == 950Mbps > server(7.2) <- client (8.0) == 920Mbps > server(8.0) <- client (7.2) == 420Mbps > > so when the server is 7.2, I have good performance regardless of whether the > client is 8.0 or 7.2. when the server is 8.0, I have poor performance > regardless of whether the client is 8.0 or 7.2. > > Has anyone else noticed this? Am I missing something simple? I've generally not measured regressions along these lines, but TCP performance can be quite sensitive to specific driver version and hardware configuration. So far, I've generally measured significant TCP scalability improvements in 8, and moderate raw TCP performance improvements over real interfaces. On the other hand, I've seen decreased TCP performance on the loopback due to scheduling interactions with ULE on some systems (but not all -- disabling checksum generate/verify has improved loopback on other systems). The first thing to establish is whether other similar benchmarks give the same result, which might us to narrow the issue down a bit. Could you try using netperf+netserver with the TCP_STREAM test and see if that differs using the otherwise identical configuration? Could you compare the ifconfig link configuration of 7.2 and 8.0 to make sure there's not a problem with the driver negotiating, for example, half duplex instead of full duplex? Also confirm that the same blend ot LRO/TSO/checksum offloading/etc is present. Could you do "procstat -at | grep ifname" (where ifname is your interface name) and send that to me? Another thing to keep an eye of is interrupt rates and pin sharing, which are both sensitive to driver change and ACPI changes. It wouldn't hurt to compare vmstat -i rates not just on your network interface, but also on other devices, to make sure there's not new aliasing. With a new USB stack and plenty of other changes, additional driver code running when your NIC interrupt fires would be highly measurable. Finally, two TCP tweaks to try: (1) Try disabling in-flight bandwidth estimation by setting net.inet.tcp.inflight.enable to 0. This often hurts low-latency, high-bandwidth local ethernet links, and is sensitive to many other issues including time-keeping. It may not be the "cause", but it's a useful thing to try. (2) Try setting net.inet.tcp.read_locking to 0, which disables the read-write locking strategy on global TCP locks. This setting, when enabled, significantly impoves TCP scalability when dealing with multiple NICs or input queues, but is one of the non-trivial functional changes in TCP. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 09:13:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EADB9106566B; Thu, 19 Nov 2009 09:13:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C27418FC29; Thu, 19 Nov 2009 09:13:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAJ9DpDc069475; Thu, 19 Nov 2009 04:13:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAJ9DprH069465; Thu, 19 Nov 2009 09:13:51 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 19 Nov 2009 09:13:51 GMT Message-Id: <200911190913.nAJ9DprH069465@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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, 19 Nov 2009 09:13:52 -0000 TB --- 2009-11-19 07:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-19 07:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-11-19 07:55:00 - cleaning the object tree TB --- 2009-11-19 07:55:29 - cvsupping the source tree TB --- 2009-11-19 07:55:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-11-19 08:01:42 - building world TB --- 2009-11-19 08:01:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 08:01:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 08:01:42 - TARGET=i386 TB --- 2009-11-19 08:01:42 - TARGET_ARCH=i386 TB --- 2009-11-19 08:01:42 - TZ=UTC TB --- 2009-11-19 08:01:42 - __MAKE_CONF=/dev/null TB --- 2009-11-19 08:01:42 - cd /src TB --- 2009-11-19 08:01:42 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 19 08:01:43 UTC 2009 >>> 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 Thu Nov 19 09:00:14 UTC 2009 TB --- 2009-11-19 09:00:14 - generating LINT kernel config TB --- 2009-11-19 09:00:14 - cd /src/sys/i386/conf TB --- 2009-11-19 09:00:14 - /usr/bin/make -B LINT TB --- 2009-11-19 09:00:14 - building LINT kernel TB --- 2009-11-19 09:00:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 09:00:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 09:00:14 - TARGET=i386 TB --- 2009-11-19 09:00:14 - TARGET_ARCH=i386 TB --- 2009-11-19 09:00:14 - TZ=UTC TB --- 2009-11-19 09:00:14 - __MAKE_CONF=/dev/null TB --- 2009-11-19 09:00:14 - cd /src TB --- 2009-11-19 09:00:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 19 09:00:14 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -pg -mprofiler-epilogue /src/sys/i386/i386/atomic.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/bios.c 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 -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror /src/sys/i386/i386/bioscall.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 -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/bpf_jit_machdep.c cc1: warnings being treated as errors /src/sys/i386/i386/bpf_jit_machdep.c: In function 'bpf_jit_compile': /src/sys/i386/i386/bpf_jit_machdep.c:517: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-19 09:13:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-19 09:13:51 - ERROR: failed to build lint kernel TB --- 2009-11-19 09:13:51 - 3317.14 user 679.02 system 4730.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 10:21:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1070B1065676; Thu, 19 Nov 2009 10:21:31 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id A24098FC18; Thu, 19 Nov 2009 10:21:30 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 835091D7; Thu, 19 Nov 2009 11:25:33 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" , "Matt Reimer" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> <1258603057.2303.92.camel@balrog.2hip.net> Date: Thu, 19 Nov 2009 11:21:24 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: In-Reply-To: <1258603057.2303.92.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 10:21:31 -0000 Matt Reimer wrote: > Robert's on to something. It looks like your LBAs are probably > overflowing 32 bits. This would affect all vdev regardless of type. > Try the attached patch. Robert Noland wrote: >> 220000de400 > This divided by 512 byte block size is 33 bits... At a glance, the patch > looks ok to me. I'll do a more thorough review of this tomorrow. Unfortunately it don't work. Error is the same as before: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type 0 ZFS: unexpected object set type 0 FreeBSD/i386 boot Default: pgpool:/boot/kernel/kernel boot: ZFS: unexpected object set type 0 This is 7.2-STABLE, amd64. My test procedure: 1. I fully synchronized these zfsboot-related directories with -CURRENT: src/sys/boot/i386/zfsboot src/sys/boot/zfs src/sys/cddl/boot/zfs 2. I applied Matt Reimer's zfsboot.c.patch3 patch: # cd /usr/src/sys/boot/ # patch < /path/to/zfsboot.c.patch3 3. Then I did: # make clean; make cleandir # make obj ; make depend ; make # cd i386/loader # make install # cd /usr/src/sys/boot/i386/zfsboot # make install # sysctl kern.geom.debugflags=16 # dd if=/boot/zfsboot of=/dev/da0 count=1 # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 # reboot 4. Result: error shown above. Thanks! -- am From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 11:28:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD2F106566B for ; Thu, 19 Nov 2009 11:28:51 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id C60C68FC15 for ; Thu, 19 Nov 2009 11:28:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 05F43803E for ; Thu, 19 Nov 2009 12:28:48 +0100 (CET) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 26E9B803D; Thu, 19 Nov 2009 12:28:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Alban Hertroys In-Reply-To: Date: Thu, 19 Nov 2009 12:28:46 +0100 Content-Transfer-Encoding: 8bit Message-Id: References: <20091118135340.522fa36a@ernst.jennejohn.org> To: Dan Naumov X-Mailer: Apple Mail (2.1077) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 19 12:28:48 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 909,4b052bf011731116417714 X-DSPAM-Factors: 27, could, 0.40000, could, 0.40000, but, 0.40000, From*Alban, 0.40000, users+whatsoever, 0.40000, the+users, 0.40000, Mime-Version*Message, 0.40000, patch+being, 0.40000, images+of, 0.40000, an, 0.40000, an, 0.40000, to+www, 0.40000, org, 0.40000, FreeBSD+>, 0.40000, FreeBSD+>, 0.40000, from, 0.40000, from, 0.40000, to+boot, 0.40000, Date*12, 0.40000, 100+acres, 0.40000, >+It, 0.40000, of, 0.40000, of, 0.40000, sysinstall, 0.40000, In-Reply-To*mail.gmail.com>, 0.40000, is+such, 0.40000, is+that, 0.40000 Cc: freebsd-current Subject: Re: request: LOADER_ZFS_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 11:28:51 -0000 On 18 Nov 2009, at 14:03, Dan Naumov wrote: > On Wed, Nov 18, 2009 at 2:53 PM, Gary Jennejohn > wrote: >> On Wed, 18 Nov 2009 13:44:12 +0200 >> Dan Naumov wrote: ... >> This is such a load of BS I could fertilize 100 acres with it. >> >> In this day of inexpensive computers with fast mulit-core CPUs and >> gigabytes of memory this argument is completely lame. > > No it is not. The fact that computers are faster today is not a valid > excuse to inconvenience the users whatsoever. > > It is bad enough that sysinstall doesn't support ZFS so a ZFS-only > installation has to be done purely using a commandline, but demanding > the user to rebuild the system to be able to boot off a filesystem > which is one of the most advertised features of FreeBSD 7.x and 8.x is > plain ridiculous. > > What if the user is a newcomer who doesn't _HAVE_ an existing FreeBSD > installation he could use to build a ZFS-boot-capable FreeBSD > installation image? If a user goes to www.freebsd.org and downloads > the .ISO images of 8.0, it is completely unreasonable to force the > user to jump through having to make an installation, rebuild the > sources, make a new .ISO for his own use and then reinstall using > that. If you don't see WHY, I don't quite know what to tell you. The lack of ZFS support in the default loader is not a good argument against building from source, it is an exception. The only reason it has anything to do with compiling world is that currently compiling from source is the only way to get ZFS support in the loader, something for which there's currently a patch being tested. Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:909,4b052bf011731116417714! From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 13:45:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA3941065676; Thu, 19 Nov 2009 13:45:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 00DAC8FC1C; Thu, 19 Nov 2009 13:45:05 +0000 (UTC) Received: by mail-bw0-f213.google.com with SMTP id 5so2579666bwz.3 for ; Thu, 19 Nov 2009 05:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=avmufNLLPqdOgmeO+GGGVSATSeu9HvuoZF8JEOEVbSg=; b=WNLhGOo6gU94GQ7Y8mJz+ORkuBwpaPa64CgpG0QZDYGY7Z+aSGI3siiy+KLag0skOq T1l8JW6AfNWM0bj6wCucNYKasMkO0axIrtZKwRIhGHhAkGcKUwxkQRMg55kbK2/nVlDR 8oEt9r1s89UW7rQfYyVFktAqIoyOk08WNr4Yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Qe3ow8vpnWjxtN5qXtdfF/fd9zK9TyyjACc36yduvHknPmo8cdWMcx5sMEY2DkbZJg yhzzfzSQcAYlc7IDA5X5mRvXomSgW7giaF3yQ2il3wFWi4eoODq+Zx2b4x6lAF/0AkF9 FRE5HhUZ3JarwKCwhYaayZBdwD0PMBj0H8/TI= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.18.137 with SMTP id w9mr992035faa.61.1258638305518; Thu, 19 Nov 2009 05:45:05 -0800 (PST) In-Reply-To: References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> Date: Thu, 19 Nov 2009 14:45:05 +0100 X-Google-Sender-Auth: 52fabe9d60638563 Message-ID: <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com> From: Attilio Rao To: Robert Watson Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 13:45:07 -0000 2009/11/19 Robert Watson : > > On Thu, 19 Nov 2009, Attilio Rao wrote: > >> 2009/11/17 Robert N. M. Watson : >>> >>> On 17 Nov 2009, at 14:17, Ed Maste wrote: >>> >>>> Our original motivation for doing this was to make gcore work with >>>> threaded apps, not avoiding procfs, but that's a useful side-effect of the >>>> work. Note though that for that purpose it isn't complete; procfs is still >>>> used in readmap to read the process' memory map. It looks like we need to >>>> find a way to implement readmap without procfs. >>> >>> Are the sysctls used for procstat -v sufficient for this purpose? >> >> This patch should address the arised concerns by both of you: >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore2.diff >> >> and additively fix elf_getstatus() to not use procfs, so that gcore is >> completely procfs independent now. Comments, reviews and testing are >> welcome. > > If you add the missing include of sys/wait.h, elfcore.c generates an error > instead of a warning on this non-traditional use of wait(2): > > + wait(); > > Something like this may be preferred: > > if (waitpid(pid, NULL, 0) < 0) > err(1, "waitpid"); I didn't get a warning neither an error but yes, the waitpid() is preferred and should be used. > This further persisting reference to procfs can be replaced with a > sysctl/kvm interface: > > gcore.c: asprintf(&binfile, "/proc/%d/file", pid); Right, I just modified elfcore so I missed it. > See the implementation of "procstat -b" which returns the path to the binary > using the same underlying mechanism (vn_fullpath on the process image > vnode). > > I think that kills the last of the procfs dependencies, in which case > perhaps we can remove the procfs.h include from elfcore.c, which requires > defining a local version of a summary data structure borrowed from procfs. > It's worth trying with procfs unmounted, however, to make sure they're > really all gone (which is how I ran into the above problem). I don't like the idea to replicate the structures because of code maintence. IMHO is ok to have procfs header. I will provide ASAP a new patch which addresses this concerns and testing without procfs mounted. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 14:40:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DEE41065694; Thu, 19 Nov 2009 14:40:04 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 241808FC22; Thu, 19 Nov 2009 14:40:04 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id 4C11C46B06; Thu, 19 Nov 2009 09:40:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com> Date: Thu, 19 Nov 2009 14:40:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <645CAAD7-A3BE-44B3-97D5-F4E4786943A4@freebsd.org> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com> To: Attilio Rao X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 14:40:04 -0000 On 19 Nov 2009, at 13:45, Attilio Rao wrote: >> If you add the missing include of sys/wait.h, elfcore.c generates an = error >> instead of a warning on this non-traditional use of wait(2): >>=20 >> + wait(); >>=20 >> Something like this may be preferred: >>=20 >> if (waitpid(pid, NULL, 0) < 0) >> err(1, "waitpid"); >=20 > I didn't get a warning neither an error but yes, the waitpid() is > preferred and should be used. This warning was on i386 9.x, FYI, and was a property of failing to call = wait(2) with an argument. >> I think that kills the last of the procfs dependencies, in which case >> perhaps we can remove the procfs.h include from elfcore.c, which = requires >> defining a local version of a summary data structure borrowed from = procfs. >> It's worth trying with procfs unmounted, however, to make sure = they're >> really all gone (which is how I ran into the above problem). >=20 > I don't like the idea to replicate the structures because of code > maintence. IMHO is ok to have procfs header. I'm not sure I agree; looking at the elfcore code, it looks like it goes = to some amount of inconvenience to stuff things into the structure in = the first place, primarily because that was how procfs exported it. With = your excellent change, there's no need for gcore(1) to depend on = procfs-specific data structures that may change, or more ideally, be = removed in the future. Robert= From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 14:55:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 257DD1065672; Thu, 19 Nov 2009 14:55:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EE5DB8FC18; Thu, 19 Nov 2009 14:55:18 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9CCF246B2E; Thu, 19 Nov 2009 09:55:18 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CB77F8A021; Thu, 19 Nov 2009 09:55:17 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 19 Nov 2009 09:42:19 -0500 User-Agent: KMail/1.9.7 References: <200911182059.35769.hselasky@freebsd.org> In-Reply-To: <200911182059.35769.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911190942.19645.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 09:55:17 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Hans Petter Selasky Subject: Re: [PATCH] Panic when inserting 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: Thu, 19 Nov 2009 14:55:19 -0000 On Wednesday 18 November 2009 2:59:33 pm Hans Petter Selasky wrote: > Hi, > > I am sometimes using a PCCARD which panics the FreeBSD 9-current kernel due to > generating some interrupts immediately when plugged in. Can someone add the > required checks to handle spurious interrupts on non-enabled IRQ vectors? > > Backtrace: > > pccard_intr() > cbb_func_intr() > intr_event_execute_handlers() > > --HPS > > sys/dev/pccard/pccard.c > > static void > pccard_intr(void *arg) > { > struct pccard_function *pf = (struct pccard_function*) arg; > > + if (pf == NULL || pf->intr_handler == NULL) return; > pf->intr_handler(pf->intr_handler_arg); > } I don't think 'pf' can ever be NULL here. However, the second check might be valid. Perhaps Warner (imp@) has a comment though? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 15:07:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E791D106566B; Thu, 19 Nov 2009 15:07:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 293BF8FC15; Thu, 19 Nov 2009 15:07:39 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so971255fga.13 for ; Thu, 19 Nov 2009 07:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Ld7HO7o63PvcOCMMw0unLLAZCopEIOMq1V3pVQK/LFI=; b=IDYhul34LLOzKRvgmnyhWTS67incXxdQR9U8ANkMZUJwC/Rbh+0wPJOeEDKio9UneX sb0tHzSc3wjoIPd2CnUXUxYIuJFMRPf43hRyYuA+QM+x7zJTQRnHOboUPy8KfzDFIyoN 5EvnHXqbrD0bWsZ/4Cdp35Q5HZDOuPzcbx7sI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vAaO8er/0KDPlfqUVCHVUooV44IIkfF4mhX+8+8Y7L+K0KZNw53ZSQ5u18kRa+XIoQ FJ6FhRKG6e8a+RP8o3f1ge2LsFitEwbWq9fSaxCc4kYJGZEgnDPfAVPMG6EqjHPBEzte HoNIhdix2W9KqnDupYhEwtOYhXxG+SaAAmeD8= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.161.205 with SMTP id s13mr16589fax.27.1258643258907; Thu, 19 Nov 2009 07:07:38 -0800 (PST) In-Reply-To: <645CAAD7-A3BE-44B3-97D5-F4E4786943A4@freebsd.org> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com> <645CAAD7-A3BE-44B3-97D5-F4E4786943A4@freebsd.org> Date: Thu, 19 Nov 2009 16:07:38 +0100 X-Google-Sender-Auth: d40fecae5ace554d Message-ID: <3bbf2fe10911190707w63d1ab66pa2014c526342f68e@mail.gmail.com> From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 15:07:41 -0000 2009/11/19 Robert N. M. Watson : > > On 19 Nov 2009, at 13:45, Attilio Rao wrote: > >>> If you add the missing include of sys/wait.h, elfcore.c generates an er= ror >>> instead of a warning on this non-traditional use of wait(2): >>> >>> + wait(); >>> >>> Something like this may be preferred: >>> >>> if (waitpid(pid, NULL, 0) < 0) >>> err(1, "waitpid"); >> >> I didn't get a warning neither an error but yes, the waitpid() is >> preferred and should be used. > > This warning was on i386 9.x, FYI, and was a property of failing to call = wait(2) with an argument. > >>> I think that kills the last of the procfs dependencies, in which case >>> perhaps we can remove the procfs.h include from elfcore.c, which requir= es >>> defining a local version of a summary data structure borrowed from proc= fs. >>> It's worth trying with procfs unmounted, however, to make sure they're >>> really all gone (which is how I ran into the above problem). >> >> I don't like the idea to replicate the structures because of code >> maintence. IMHO is ok to have procfs header. > > > I'm not sure I agree; looking at the elfcore code, it looks like it goes = to some amount of inconvenience to stuff things into the structure in the f= irst place, primarily because that was how procfs exported it. With your ex= cellent change, there's no need for gcore(1) to depend on procfs-specific d= ata structures that may change, or more ideally, be removed in the future. Yeah, I had the same feeling as the interfaces should be more lifted in order to less fit procfs (example: probabilly readmap could export directly the list of objects from libutil rather then transforming it) but let's get there in a second round of changes probabilly. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 15:27:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F3B106566C for ; Thu, 19 Nov 2009 15:27:17 +0000 (UTC) (envelope-from almorel@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 74C7F8FC13 for ; Thu, 19 Nov 2009 15:27:17 +0000 (UTC) Received: by fxm27 with SMTP id 27so2624778fxm.3 for ; Thu, 19 Nov 2009 07:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=zgYdqbADcDk4Sce4ht1KqTMMUjUAkoajkkT4cohurdg=; b=Nf1dVsjLCEnCoGLBtyWaMj7DmL+aqTPTftr0bVLnF6BOg47f9ibrMcseTZa8YuV5nP ixcWSq79bYFj+HNtXOTm6zAW6IpCvSUloYp8ljkbC902Qh0rKjxSWepTBRMD4+XUN9QN pByBTcHsXRlOWnPQ2m8b+joJa3o269W+mCpw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NjOz0lriXQzpiQkEaQowiF9mOw5cfePJWodYruHD6cNUn6/FyeTuLbPdRHedrNQR+4 2+S/g8MdWn+t5lm+5A22H7k8DDHIbwJ/9tSFbry0vI7FnhO7VXzXU8rCJ45/jafq67Sn vlYJaUhmu1mpZ/wNoNpzXmWwjQ4blcoT+bOOw= MIME-Version: 1.0 Received: by 10.216.90.138 with SMTP id e10mr19601wef.150.1258642662907; Thu, 19 Nov 2009 06:57:42 -0800 (PST) Date: Thu, 19 Nov 2009 15:57:42 +0100 Message-ID: From: Alexandre MOREL To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: portupgrade problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 15:27:18 -0000 Hello, I've got some ports that they need to be updated. /usr/sbin/pkg_version -vIL= bash-4.0.33_2 < needs updating (index has 4.0.35) ezm3-1.1_2 < needs updating (index has 1.2_1) libpthread-stubs-0.1 < needs updating (index has 0.3) lsof-4.83B,4 < needs updating (index has 4.83C,4) tmux-1.0_1 < needs updating (index has 1.1) vim-7.2.239 < needs updating (index has 7.2.299) I try to use portupgrade in order to update my packages with: portupgrade -rR vim-7.2.239 (for example) But nothing happen and I've got the folowing return: portupgrade -rR vim-7.2.239 [Gathering depends for editors/vim ......................................................................................................... done] [Exclude up-to-date packages ........................................ done] It's really strange because for the package "bash" I use the way: make deinstall && make install in the directory /usr/ports/shell/bash and all works great ! and this confirm that my second update process was successfull : bash -version GNU bash, version 4.0.33(2)-release (amd64-portbld-freebsd8.0) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. The last version of bash is present on my system. It's seems that the INDEX is corrupted but I try to ran pkgdb -F and it did nothing. I try to make some search on the mailling list or google, there is some idea (like ) but nothing solve my problem. Someone have an idea to help me ? or some tips to check the consitency of my index ? Thanks in advance for yours helps (My FreeBSD version: FreeBSD 8.0-RC1) Alexandre From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 15:39:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DAB21065679 for ; Thu, 19 Nov 2009 15:39:17 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id ADD7C8FC21 for ; Thu, 19 Nov 2009 15:39:16 +0000 (UTC) Received: (qmail 89251 invoked from network); 19 Nov 2009 16:39:15 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 19 Nov 2009 16:39:15 +0100 Date: Thu, 19 Nov 2009 16:39:13 +0100 From: Kai Gallasch To: Andriy Gapon Message-ID: <20091119163913.6ee9ee56@orwell.free.de> In-Reply-To: <4B0403D0.3090101@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> <4AFD140D.7010407@icyb.net.ua> <20091113144804.2c0fb90f@orwell.free.de> <4AFD655E.5020801@icyb.net.ua> <20091114022121.217dd831@orwell.free.de> <4AFE7A32.7060203@icyb.net.ua> <4B025FA9.7020003@icyb.net.ua> <20091117165304.01676555@orwell.free.de> <4B0403D0.3090101@icyb.net.ua> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.18.2; powerpc-apple-darwin9.7.0) X-Face: 7"x0zA5=*cXGZw-xjU<">'+!3(KXTUXZVLD42KVN{'go[UQr"Mc.e(XW92N8plZ(9x.{x; I<|95e+b&GH-36\15F~L$YD*Y +u}o&KV?6.%"mJIkaY3G>BKNt`1|Y+%K1P4t; 47D65&(Y7h5Ll-[ltkhamx.-; ,jggK'}oMpUgEHFG YQ"9oXKAl>!d,J}T{)@uxvfu?YFWC*\~h+,^f Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 15:39:17 -0000 Am Wed, 18 Nov 2009 16:25:20 +0200 schrieb Andriy Gapon : > thank you very much for the testing! > This has been an invaluable help. > > I am now trying to narrow down possible causes of the issue and to > come up with the most efficient patch. > > If/when you have a chance could you please test the following changes? > The patches are against mainline source tree (that is, not against > previous patch(es)). > > So, please first try *only* this patch: > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 44b71f3..33b8c2a 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c Hi. I tested the patch. - 3 x "make -j8 buildworld" : no machine check exception - mount nfs filesystem on the server an copied 10G of small files to local zfs: no machine check exception > Most likely this will fix the buildworld scenario. > But I am not sure if it will fix ZFS scenario. > If it does - then great, if not, please apply the following patch in > addition to the previous one and test again: If related zfs issues come up in the next weeks, I'll contact you. Server now runs stable with superpages set active. Nice! --Kai. From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 15:43:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D346E106566C for ; Thu, 19 Nov 2009 15:43:29 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 58DE88FC18 for ; Thu, 19 Nov 2009 15:43:29 +0000 (UTC) Received: from significant-gravitas-shortfall.thebunker.net (gateway.ash.thebunker.net [213.129.64.4]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.3/8.14.3) with ESMTP id nAJFhO2C084794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 15:43:25 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk nAJFhO2C084794 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1258645405; bh=rczYLqlGtW812HTBbNnCQSOJ/np/utoRv2BXDP0yBKk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4B05679C.6080509@infracaninophile.co.uk>|Date:=20T hu,=2019=20Nov=202009=2015:43:24=20+0000|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Thunderbird=202.0.0.23=20(X11/20090824)|MIME-Vers ion:=201.0|To:=20Alexandre=20MOREL=20|CC:=20fre ebsd-current@freebsd.org|Subject:=20Re:=20portupgrade=20problem|Re ferences:=20|In-Reply-To:=20|X-Enigmail-Version:=200.95.7|OpenPGP:=20id=3D60 AE908C|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha1=3B= 0D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20boundary =3D"------------enig858EC46DFA3D5F32CE21E28C"; b=liF7EhL9k8CIl50UjOmqcOH9PF7EdOrGR2lPRHX8jnsUJDDgbEstWi3V8yIqMsJ2y oGSp/VHl2flEj/N+eQH8d3vBIPmlYbKUZDY65M17HkPmFiYgYh0bYCAGoy6H3mBE0J F3nYEzNJchW3zan2vIxo7xPh+H2ae1LT3Vv5kabg= X-Authentication-Warning: happy-idiot-talk.infracaninophile.co.uk: Host gateway.ash.thebunker.net [213.129.64.4] claimed to be significant-gravitas-shortfall.thebunker.net Message-ID: <4B05679C.6080509@infracaninophile.co.uk> Date: Thu, 19 Nov 2009 15:43:24 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Alexandre MOREL References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig858EC46DFA3D5F32CE21E28C" X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,SPF_FAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-current@freebsd.org Subject: Re: portupgrade problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 15:43:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig858EC46DFA3D5F32CE21E28C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alexandre MOREL wrote: > Hello, >=20 > I've got some ports that they need to be updated. > /usr/sbin/pkg_version -vIL=3D > bash-4.0.33_2 < needs updating (index has 4.0.3= 5) > ezm3-1.1_2 < needs updating (index has 1.2_1= ) > libpthread-stubs-0.1 < needs updating (index has 0.3) > lsof-4.83B,4 < needs updating (index has 4.83C= ,4) > tmux-1.0_1 < needs updating (index has 1.1) > vim-7.2.239 < needs updating (index has 7.2.2= 99) >=20 >=20 > I try to use portupgrade in order to update my packages with: > portupgrade -rR vim-7.2.239 (for example) >=20 > But nothing happen and I've got the folowing return: > portupgrade -rR vim-7.2.239 > [Gathering depends for editors/vim > .......................................................................= =2E................................. > done] > [Exclude up-to-date packages ........................................ d= one] >=20 > It's really strange because for the package "bash" I use the way: make > deinstall && make install in the directory /usr/ports/shell/bash and al= l > works great ! and this confirm that my second update process was succes= sfull > : >=20 > bash -version > GNU bash, version 4.0.33(2)-release (amd64-portbld-freebsd8.0) > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later =20 Uh -- you may have reinstalled bash, but it seems you haven't ended up wi= th version 4.0.35. Have you perhaps downloaded an updated INDEX (by 'mak= e fetchindex') but not updated the actual ports tree? Try running: pkg_version -vL=3D which will take slightly longer, but will skip reading the INDEX and comp= are port versions directly with what is available on your filesystem. If tha= t doesn't show any upgrades available, then you need a bit of csup(1) or portsnap(8) action to grab an up-to-date ports tree. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. Flat 3 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW, UK --------------enig858EC46DFA3D5F32CE21E28C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksFZ5wACgkQ3jDkPpsZ+VbLQgCglLjUdGx9edPRYDVXTV8KOuLT 6O0AoL++Q7S1K1odxewXkxl6dmNbtEaR =RuAP -----END PGP SIGNATURE----- --------------enig858EC46DFA3D5F32CE21E28C-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 16:20:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 947BA106566B for ; Thu, 19 Nov 2009 16:20:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 64D0E8FC1C for ; Thu, 19 Nov 2009 16:20:59 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id nAJGKuKG096490; Thu, 19 Nov 2009 11:20:56 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200911191620.nAJGKuKG096490@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Nov 2009 11:21:05 -0500 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: arp -na output sort order ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 16:20:59 -0000 Is there any reason why the output of arp is no longer sorted by IP addr ? Is this just the fallout of the arp fixes/changes in RELENG_8 ? e.g. RELENG_7 and below ? (192.168.43.1) at 00:13:20:c3:7d:22 on em1 [ethernet] ? (192.168.43.19) at 00:01:80:3c:5e:c9 on em1 [ethernet] ? (192.168.43.24) at 00:16:cb:91:fd:4e on em1 [ethernet] ? (192.168.43.27) at 00:14:2a:9b:1c:2e on em1 [ethernet] ? (192.168.43.28) at 00:50:fc:24:24:9f on em1 [ethernet] ? (192.168.43.34) at 00:01:80:54:b3:b8 on em1 [ethernet] ? (192.168.43.50) at 00:90:c2:d4:0b:8a on em1 [ethernet] ? (192.168.43.88) at 00:04:00:79:d5:44 on em1 [ethernet] ? (192.168.43.96) at 00:0d:ed:89:2e:80 on em1 [ethernet] ? (192.168.43.97) at 00:15:17:1e:94:0b on em1 [ethernet] ? (192.168.43.99) at 00:c0:05:02:0a:c3 on em1 [ethernet] ? (192.168.43.121) at 00:0e:84:1a:e2:e7 on em1 [ethernet] ? (192.168.43.122) at 00:0e:84:1a:e3:c8 on em1 [ethernet] and on RELENG_8 ? (192.168.43.99) at 00:c0:05:02:0a:c3 on em0 [ethernet] ? (192.168.43.34) at 00:01:80:54:b3:b8 on em0 [ethernet] ? (192.168.43.1) at 00:13:20:c3:7d:22 on em0 [ethernet] ? (192.168.43.27) at 00:14:2a:9b:1c:2e on em0 [ethernet] ? (192.168.43.219) at 00:1c:c0:95:0d:0d on em0 permanent [ethernet] ? (10.255.255.110) at 00:03:1d:03:52:06 on igb1 [ethernet] ? (10.255.255.3) at 00:15:17:1e:94:0c on igb1 [ethernet] ? (10.255.255.1) at 00:30:48:94:88:21 on igb1 permanent [ethernet] ? (10.255.255.114) at 00:02:b3:5d:ca:ce on igb1 [ethernet] ? (10.255.255.113) at 00:24:8c:60:56:a4 on igb1 [ethernet] ? (3.3.3.1) at 00:30:48:94:88:20 on igb0 permanent [ethernet] ? (10.177.194.17) at 00:15:17:cf:26:df on igb0 [ethernet] ? (10.177.194.18) at 00:30:48:94:88:20 on igb0 permanent [ethernet] ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 16:24:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21272106568B; Thu, 19 Nov 2009 16:24:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D403C8FC16; Thu, 19 Nov 2009 16:24:03 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-218-170.ard.bellsouth.net [72.154.218.170]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAJGO0MG026150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 11:24:01 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> <1258603057.2303.92.camel@balrog.2hip.net> Content-Type: multipart/mixed; boundary="=-BDiV+OcYAkHUcmXfsTdc" Organization: FreeBSD Date: Thu, 19 Nov 2009 10:23:55 -0600 Message-Id: <1258647835.2303.105.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Matt Reimer Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 16:24:04 -0000 --=-BDiV+OcYAkHUcmXfsTdc Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2009-11-19 at 11:21 +0100, Emil Smolenski wrote: > Matt Reimer wrote: > > Robert's on to something. It looks like your LBAs are probably > > overflowing 32 bits. This would affect all vdev regardless of type. > > Try the attached patch. > > Robert Noland wrote: > >> 220000de400 > > This divided by 512 byte block size is 33 bits... At a glance, the patch > > looks ok to me. I'll do a more thorough review of this tomorrow. > > Unfortunately it don't work. Error is the same as before: Ok, I was concerned about the assembly code... So, I've been chatting with jhb@ this morning. Please try this patch that jhb@ came up with instead of Matt's latest patch. robert. > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type 0 > ZFS: unexpected object set type 0 > > FreeBSD/i386 boot > Default: pgpool:/boot/kernel/kernel > boot: > ZFS: unexpected object set type 0 > > > This is 7.2-STABLE, amd64. My test procedure: > > 1. I fully synchronized these zfsboot-related directories with -CURRENT: > > src/sys/boot/i386/zfsboot > src/sys/boot/zfs > src/sys/cddl/boot/zfs > > 2. I applied Matt Reimer's zfsboot.c.patch3 patch: > > # cd /usr/src/sys/boot/ > # patch < /path/to/zfsboot.c.patch3 > > 3. Then I did: > > # make clean; make cleandir > # make obj ; make depend ; make > # cd i386/loader > # make install > # cd /usr/src/sys/boot/i386/zfsboot > # make install > # sysctl kern.geom.debugflags=16 > # dd if=/boot/zfsboot of=/dev/da0 count=1 > # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > # reboot > > 4. Result: error shown above. > > Thanks! > -- Robert Noland FreeBSD --=-BDiV+OcYAkHUcmXfsTdc Content-Disposition: attachment; filename="zfsboot_64.patch" Content-Type: text/x-patch; name="zfsboot_64.patch"; charset="us-ascii" Content-Transfer-Encoding: 7bit --- //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsboot.c +++ /home/jhb/work/p4/boot/sys/boot/i386/zfsboot/zfsboot.c @@ -138,8 +138,8 @@ unsigned unit; unsigned slice; unsigned part; - unsigned start; int init; + daddr_t start; }; static char cmd[512]; static char kname[1024]; @@ -163,7 +163,7 @@ static void printf(const char *,...); static void putchar(int); static uint32_t memsize(void); -static int drvread(struct dsk *, void *, unsigned, unsigned); +static int drvread(struct dsk *, void *, daddr_t, unsigned); static int keyhit(unsigned); static int xputc(int); static int xgetc(int); @@ -310,7 +310,8 @@ vdev_read(vdev_t *vdev, void *priv, off_t off, void *buf, size_t bytes) { char *p; - unsigned int lba, nb; + daddr_t lba; + unsigned int nb; struct dsk *dsk = (struct dsk *) priv; if ((off & (DEV_BSIZE - 1)) || (bytes & (DEV_BSIZE - 1))) @@ -964,7 +965,7 @@ #endif static int -drvread(struct dsk *dsk, void *buf, unsigned lba, unsigned nblk) +drvread(struct dsk *dsk, void *buf, daddr_t lba, unsigned nblk) { #ifdef GPT static unsigned c = 0x2d5c7c2f; @@ -999,7 +1000,7 @@ v86.es = VTOPSEG(buf); v86.eax = lba; v86.ebx = VTOPOFF(buf); - v86.ecx = lba >> 16; + v86.ecx = lba >> 32; v86.edx = nblk << 8 | dsk->drive; v86int(); v86.ctl = V86_FLAGS; --- //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsldr.S +++ /home/jhb/work/p4/boot/sys/boot/i386/zfsboot/zfsldr.S @@ -80,10 +80,10 @@ .org 0x25,0x90 /* - * Trampoline used by boot2 to call read to read data from the disk via + * Trampoline used by zfsboot to call read to read data from the disk via * the BIOS. Call with: * - * %cx:%ax - long - LBA to read in + * %ecx:%eax - long - LBA to read in * %es:(%bx) - caddr_t - buffer to read data into * %dl - byte - drive to read from * %dh - byte - num sectors to read @@ -94,10 +94,8 @@ /* * Setup an EDD disk packet and pass it to read */ -xread.1: # Starting - pushl $0x0 # absolute - push %cx # block - push %ax # number +xread.1: pushl %ecx # Starting absolute block + pushl %eax # block number push %es # Address of push %bx # transfer buffer xor %ax,%ax # Number of @@ -245,10 +243,11 @@ /* * Trampoline used to call read from within boot1. */ -nread: xor %ax,%ax # Sector offset in partition +nread: xor %eax,%eax # Sector offset in partition nread.1: mov $MEM_BUF,%bx # Transfer buffer - add 0x8(%si),%ax # Get - mov 0xa(%si),%cx # LBA + xor %ecx,%ecx # Get + addl 0x8(%si),%eax # LBA + adc $0,%ecx push %cs # Read from callw xread.1 # disk jnc return # If success, return --=-BDiV+OcYAkHUcmXfsTdc-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 16:42:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C09106568B for ; Thu, 19 Nov 2009 16:42:47 +0000 (UTC) (envelope-from efinley.lists@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 663738FC08 for ; Thu, 19 Nov 2009 16:42:47 +0000 (UTC) Received: by pwj15 with SMTP id 15so1639657pwj.3 for ; Thu, 19 Nov 2009 08:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=0sbmjXUsm7bK5gmDqSDlnSpSZqPcHZZT2Qr8G2M/nPw=; b=tZEVqnPCA2tdoE1NInJV5MtmXhprflqN6hNWY3sTyiBv7QfH8st9+NV6mMBEGLFYtW 4nscgdsylA0Hjuvi2DnVTiqMnQcTiNxudOhBWtc0OJUJgvwp/BTcLpt21d4JtR88KGKc M0lUnJEOpr9APF4u5sKoo5ppVv+Z/y/up0gG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hBPlTRXGpUz8JZ+51awyY6wlyTCAe18+U7uU7f3BGeENZooZUXyn6h4nHVtJ+b5nFy wKZjkvESliG+SJwcN+oAea63PmE5hq2HpyDtfBRhKuyZPNR7G65Yfgp1TFosx6t93MxQ 9tP2+G+vQa644eChkRge1pCHcR2BAAvEe6Xsg= MIME-Version: 1.0 Received: by 10.143.27.31 with SMTP id e31mr21003wfj.173.1258648966861; Thu, 19 Nov 2009 08:42:46 -0800 (PST) In-Reply-To: References: <54e63c320911181807m4ddb770br1281d1163ae3cf5f@mail.gmail.com> Date: Thu, 19 Nov 2009 09:42:46 -0700 Message-ID: <54e63c320911190842n352cd860q460684376065cd3a@mail.gmail.com> From: Elliot Finley To: Robert Watson , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: 8.0-RC3 network performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 16:42:47 -0000 On Thu, Nov 19, 2009 at 2:11 AM, Robert Watson wrote: > > On Wed, 18 Nov 2009, Elliot Finley wrote: > > I have several boxes running 8.0-RC3 with pretty dismal network >> performance. I also have some 7.2 boxes with great performance. Using iperf >> I did some tests: >> >> server(8.0) <- client (8.0) == 420Mbps >> server(7.2) <- client (7.2) == 950Mbps >> server(7.2) <- client (8.0) == 920Mbps >> server(8.0) <- client (7.2) == 420Mbps >> >> so when the server is 7.2, I have good performance regardless of whether >> the client is 8.0 or 7.2. when the server is 8.0, I have poor performance >> regardless of whether the client is 8.0 or 7.2. >> >> Has anyone else noticed this? Am I missing something simple? >> > > I've generally not measured regressions along these lines, but TCP > performance can be quite sensitive to specific driver version and hardware > configuration. So far, I've generally measured significant TCP scalability > improvements in 8, and moderate raw TCP performance improvements over real > interfaces. On the other hand, I've seen decreased TCP performance on the > loopback due to scheduling interactions with ULE on some systems (but not > all -- disabling checksum generate/verify has improved loopback on other > systems). > > The first thing to establish is whether other similar benchmarks give the > same result, which might us to narrow the issue down a bit. Could you try > using netperf+netserver with the TCP_STREAM test and see if that differs > using the otherwise identical configuration? > > Could you compare the ifconfig link configuration of 7.2 and 8.0 to make > sure there's not a problem with the driver negotiating, for example, half > duplex instead of full duplex? Also confirm that the same blend ot > LRO/TSO/checksum offloading/etc is present. > > Could you do "procstat -at | grep ifname" (where ifname is your interface > name) and send that to me? > > Another thing to keep an eye of is interrupt rates and pin sharing, which > are both sensitive to driver change and ACPI changes. It wouldn't hurt to > compare vmstat -i rates not just on your network interface, but also on > other devices, to make sure there's not new aliasing. With a new USB stack > and plenty of other changes, additional driver code running when your NIC > interrupt fires would be highly measurable. > > Finally, two TCP tweaks to try: > > (1) Try disabling in-flight bandwidth estimation by setting > net.inet.tcp.inflight.enable to 0. This often hurts low-latency, > high-bandwidth local ethernet links, and is sensitive to many other > issues > including time-keeping. It may not be the "cause", but it's a useful > thing to try. > > (2) Try setting net.inet.tcp.read_locking to 0, which disables the > read-write > locking strategy on global TCP locks. This setting, when enabled, > significantly impoves TCP scalability when dealing with multiple NICs or > input queues, but is one of the non-trivial functional changes in TCP. Thanks for the reply. Here is some more info: netperf results: storage-price-3 root:~#>netperf -H 10.20.10.20 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.20.10.20 (10.20.10.20) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 4194304 4194304 4194304 10.04 460.10 The interface on both boxes is em1. Both boxes (8.0RC3) have two 4-port PCIe NICs in them.Trying the two TCP tweaks didn't change anything. While running iperf I did the procstat and vmstat: SERVER: storage-price-2 root:~#>ifconfig em1 em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:b2:31:3d inet 10.20.10.20 netmask 0xffffff00 broadcast 10.20.10.255 media: Ethernet autoselect (1000baseT ) status: active storage-price-2 root:~#>procstat -at | grep em1 0 100040 kernel em1 taskq 3 16 run - storage-price-2 root:~#>vmstat -i interrupt total rate irq14: ata0 22979 0 irq15: ata1 23157 0 irq16: aac0 uhci0* 1552 0 irq17: uhci2+ 37 0 irq18: ehci0 uhci+ 43 0 cpu0: timer 108455076 2000 irq257: em1 2039287 37 cpu2: timer 108446955 1999 cpu1: timer 108447018 1999 cpu3: timer 108447039 1999 cpu7: timer 108447061 1999 cpu5: timer 108447061 1999 cpu6: timer 108447054 1999 cpu4: timer 108447061 1999 Total 869671380 16037 CLIENT: storage-price-3 root:~#>ifconfig em1 em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:b2:31:49 inet 10.20.10.30 netmask 0xffffff00 broadcast 10.20.10.255 media: Ethernet autoselect (1000baseT ) status: active storage-price-3 root:~#>procstat -at | grep em1 0 100040 kernel em1 taskq 3 16 run - storage-price-3 root:~#>vmstat -i interrupt total rate irq1: atkbd0 2 0 irq14: ata0 22501 0 irq15: ata1 22395 0 irq16: aac0 uhci0* 5091 0 irq17: uhci2+ 125 0 irq18: ehci0 uhci+ 43 0 cpu0: timer 108421132 1999 irq257: em1 1100465 20 cpu3: timer 108412973 1999 cpu1: timer 108412987 1999 cpu2: timer 108413010 1999 cpu7: timer 108413048 1999 cpu6: timer 108413048 1999 cpu5: timer 108413031 1999 cpu4: timer 108413045 1999 Total 868462896 16020 7.2 BOX: dns1 root:~#>ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:13:72:5a:ff:48 inet X.Y.Z.7 netmask 0xffffffc0 broadcast X.Y.Z.63 media: Ethernet autoselect (1000baseTX ) status: active The 8.0RC3 boxes are being used for testing right now (production 2nd week of December). If you want access to them, that wouldn't be a problem. TIA Elliot From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 17:02:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AEB91065695; Thu, 19 Nov 2009 17:02:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D94808FC29; Thu, 19 Nov 2009 17:02:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7709B46B2C; Thu, 19 Nov 2009 12:02:38 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id BA4928A020; Thu, 19 Nov 2009 12:02:37 -0500 (EST) From: John Baldwin To: freebsd-fs@freebsd.org Date: Thu, 19 Nov 2009 11:55:10 -0500 User-Agent: KMail/1.9.7 References: <1258647835.2303.105.camel@balrog.2hip.net> In-Reply-To: <1258647835.2303.105.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_uhXBLdyw4w+BTUK" Message-Id: <200911191155.10490.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 12:02:37 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Emil Smolenski , Robert Noland Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 17:02:39 -0000 --Boundary-00=_uhXBLdyw4w+BTUK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 19 November 2009 11:23:55 am Robert Noland wrote: > On Thu, 2009-11-19 at 11:21 +0100, Emil Smolenski wrote: > > Matt Reimer wrote: > > > Robert's on to something. It looks like your LBAs are probably > > > overflowing 32 bits. This would affect all vdev regardless of type. > > > Try the attached patch. > > > > Robert Noland wrote: > > >> 220000de400 > > > This divided by 512 byte block size is 33 bits... At a glance, the patch > > > looks ok to me. I'll do a more thorough review of this tomorrow. > > > > Unfortunately it don't work. Error is the same as before: > > Ok, I was concerned about the assembly code... So, I've been chatting > with jhb@ this morning. Please try this patch that jhb@ came up with > instead of Matt's latest patch. Actually, I had missed updating one place, please use this instead. Also, I think that this will fix using > 2TB volumes even in the GPT case as zfsboot.c was always using 32-bit LBAs even for the GPT case. -- John Baldwin --Boundary-00=_uhXBLdyw4w+BTUK Content-Type: text/x-diff; charset="iso-8859-1"; name="zfsboot_64.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfsboot_64.patch" --- //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsboot.c +++ /home/jhb/work/p4/boot/sys/boot/i386/zfsboot/zfsboot.c @@ -138,8 +138,8 @@ unsigned unit; unsigned slice; unsigned part; - unsigned start; int init; + daddr_t start; }; static char cmd[512]; static char kname[1024]; @@ -163,7 +163,7 @@ static void printf(const char *,...); static void putchar(int); static uint32_t memsize(void); -static int drvread(struct dsk *, void *, unsigned, unsigned); +static int drvread(struct dsk *, void *, daddr_t, unsigned); static int keyhit(unsigned); static int xputc(int); static int xgetc(int); @@ -310,7 +310,8 @@ vdev_read(vdev_t *vdev, void *priv, off_t off, void *buf, size_t bytes) { char *p; - unsigned int lba, nb; + daddr_t lba; + unsigned int nb; struct dsk *dsk = (struct dsk *) priv; if ((off & (DEV_BSIZE - 1)) || (bytes & (DEV_BSIZE - 1))) @@ -964,7 +965,7 @@ #endif static int -drvread(struct dsk *dsk, void *buf, unsigned lba, unsigned nblk) +drvread(struct dsk *dsk, void *buf, daddr_t lba, unsigned nblk) { #ifdef GPT static unsigned c = 0x2d5c7c2f; @@ -999,7 +1000,7 @@ v86.es = VTOPSEG(buf); v86.eax = lba; v86.ebx = VTOPOFF(buf); - v86.ecx = lba >> 16; + v86.ecx = lba >> 32; v86.edx = nblk << 8 | dsk->drive; v86int(); v86.ctl = V86_FLAGS; --- //depot/vendor/freebsd/src/sys/boot/i386/zfsboot/zfsldr.S 2008/11/17 20:55:47 +++ //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsldr.S 2009/11/19 16:53:18 @@ -83,7 +83,7 @@ * Trampoline used by boot2 to call read to read data from the disk via * the BIOS. Call with: * - * %cx:%ax - long - LBA to read in + * %ecx:%eax - long - LBA to read in * %es:(%bx) - caddr_t - buffer to read data into * %dl - byte - drive to read from * %dh - byte - num sectors to read @@ -94,10 +94,8 @@ /* * Setup an EDD disk packet and pass it to read */ -xread.1: # Starting - pushl $0x0 # absolute - push %cx # block - push %ax # number +xread.1: pushl %ecx # Starting absolute block + pushl %eax # block number push %es # Address of push %bx # transfer buffer xor %ax,%ax # Number of @@ -195,7 +193,7 @@ */ main.5: mov %dx,MEM_ARG # Save args movb $NSECT,%dh # Sector count - movw $1024,%ax # Offset to boot2 + movl $1024,%eax # Offset to boot2 callw nread.1 # Read disk main.6: mov $MEM_BUF,%si # BTX (before reloc) mov 0xa(%si),%bx # Get BTX length and set @@ -245,10 +243,11 @@ /* * Trampoline used to call read from within boot1. */ -nread: xor %ax,%ax # Sector offset in partition +nread: xor %eax,%eax # Sector offset in partition nread.1: mov $MEM_BUF,%bx # Transfer buffer - add 0x8(%si),%ax # Get - mov 0xa(%si),%cx # LBA + xor %ecx,%ecx # Get + addl 0x8(%si),%eax # LBA + adc $0,%ecx push %cs # Read from callw xread.1 # disk jnc return # If success, return --Boundary-00=_uhXBLdyw4w+BTUK-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 19:13:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B70ED10656A3 for ; Thu, 19 Nov 2009 19:13:36 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 863F18FC23 for ; Thu, 19 Nov 2009 19:13:36 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nAJJDZdZ002065; Thu, 19 Nov 2009 11:13:35 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 11:13:30 -0800 Message-ID: In-Reply-To: <200911191620.nAJGKuKG096490@lava.sentex.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: arp -na output sort order ? Thread-Index: AcppNEeRiUiWIz8DTjeBThY2xGkGFQAF3pVg References: <200911191620.nAJGKuKG096490@lava.sentex.ca> From: "Li, Qing" To: "Mike Tancsa" , Cc: Subject: RE: arp -na output sort order ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 19:13:36 -0000 >=20 > Is there any reason why the output of arp is no longer sorted by IP > addr ? Is this just the fallout of the arp fixes/changes in RELENG_8 ? >=20 Backend implementation of the ARP table is completely different=20 between pre-8 and REL_8. This is a known issue and I had other=20 big fishes to fry for the 8.0 release and this item is low on the=20 priority list. In the meantime you could do "arp -an | sort" as a temporary workaround. -- Qing > e.g. RELENG_7 and below >=20 > ? (192.168.43.1) at 00:13:20:c3:7d:22 on em1 [ethernet] > ? (192.168.43.19) at 00:01:80:3c:5e:c9 on em1 [ethernet] > ? (192.168.43.24) at 00:16:cb:91:fd:4e on em1 [ethernet] > ? (192.168.43.27) at 00:14:2a:9b:1c:2e on em1 [ethernet] > ? (192.168.43.28) at 00:50:fc:24:24:9f on em1 [ethernet] > ? (192.168.43.34) at 00:01:80:54:b3:b8 on em1 [ethernet] > ? (192.168.43.50) at 00:90:c2:d4:0b:8a on em1 [ethernet] > ? (192.168.43.88) at 00:04:00:79:d5:44 on em1 [ethernet] > ? (192.168.43.96) at 00:0d:ed:89:2e:80 on em1 [ethernet] > ? (192.168.43.97) at 00:15:17:1e:94:0b on em1 [ethernet] > ? (192.168.43.99) at 00:c0:05:02:0a:c3 on em1 [ethernet] > ? (192.168.43.121) at 00:0e:84:1a:e2:e7 on em1 [ethernet] > ? (192.168.43.122) at 00:0e:84:1a:e3:c8 on em1 [ethernet] >=20 >=20 > and on RELENG_8 >=20 >=20 > ? (192.168.43.99) at 00:c0:05:02:0a:c3 on em0 [ethernet] > ? (192.168.43.34) at 00:01:80:54:b3:b8 on em0 [ethernet] > ? (192.168.43.1) at 00:13:20:c3:7d:22 on em0 [ethernet] > ? (192.168.43.27) at 00:14:2a:9b:1c:2e on em0 [ethernet] > ? (192.168.43.219) at 00:1c:c0:95:0d:0d on em0 permanent [ethernet] > ? (10.255.255.110) at 00:03:1d:03:52:06 on igb1 [ethernet] > ? (10.255.255.3) at 00:15:17:1e:94:0c on igb1 [ethernet] > ? (10.255.255.1) at 00:30:48:94:88:21 on igb1 permanent [ethernet] > ? (10.255.255.114) at 00:02:b3:5d:ca:ce on igb1 [ethernet] > ? (10.255.255.113) at 00:24:8c:60:56:a4 on igb1 [ethernet] > ? (3.3.3.1) at 00:30:48:94:88:20 on igb0 permanent [ethernet] > ? (10.177.194.17) at 00:15:17:cf:26:df on igb0 [ethernet] > ? (10.177.194.18) at 00:30:48:94:88:20 on igb0 permanent [ethernet] >=20 >=20 > ---Mike >=20 > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 20:37:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0EC106566C for ; Thu, 19 Nov 2009 20:37:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 150FF8FC19 for ; Thu, 19 Nov 2009 20:37:49 +0000 (UTC) Received: by qyk6 with SMTP id 6so1440542qyk.3 for ; Thu, 19 Nov 2009 12:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=iDVBa4NmCmEYWcoInWnDfSC18RGxicRqkKmoI7cbZ14=; b=PDAU/C88Hk31E7bxyE4GBM+I1GdVgYJ6JrLTkcD8M4INoQgS3Tuqw4I0JeZO0xKCSx BrZ8w/P1m9uTQT/gKCebi/Gzw4vitSfMzSiOOPSyEyc5s8wObzimUX6FvIYDW3HOr7cU KSD/fEU5a7YVpg+M+1BCIo7VzFuO5T5cOdFis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Rz7+l/MiCSFHBWiOItuXrbW+2D3QIFAkp6IHZslfQGQuP+Tcgr7KMKcB/pGZpBk3uV WfGmgcYDUFIySQf0kd2pCbH0fI+5mDGSgXSp5WR3adkUw+QbPKJZNUqgDnKNy8Ln19wK f01E6Zq/9pCZuzbfprsXFDDVJrKdl3PEhZtLc= Received: by 10.224.50.130 with SMTP id z2mr345506qaf.206.1258663069247; Thu, 19 Nov 2009 12:37:49 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm2550410qwj.13.2009.11.19.12.37.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:37:48 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 19 Nov 2009 12:37:20 -0800 From: Pyun YongHyeon Date: Thu, 19 Nov 2009 12:37:20 -0800 To: Gonzalo Nemmi Message-ID: <20091119203720.GT1262@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911171650.06834.gnemmi@gmail.com> <20091117193208.GI1262@michelle.cdnetworks.com> <200911171917.41906.gnemmi@gmail.com> <20091117232347.GJ1262@michelle.cdnetworks.com> <20091118005724.GK1262@michelle.cdnetworks.com> <19e9a5dc0911172040g1107423ck72d30460b030ca27@mail.gmail.com> <20091118233225.GP1262@michelle.cdnetworks.com> <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ey/N+yb7u/X9mFhi" Content-Disposition: inline In-Reply-To: <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Thu, 19 Nov 2009 20:37:50 -0000 --ey/N+yb7u/X9mFhi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 19, 2009 at 01:27:03AM -0300, Gonzalo Nemmi wrote: > On Wed, Nov 18, 2009 at 8:32 PM, Pyun YongHyeon wrote: > > > On Wed, Nov 18, 2009 at 01:40:24AM -0300, Gonzalo Nemmi wrote: > > > > [...] > > > > > I just tried ... > > > echo 'hw.bge.allow_asf="1"' >> /boot/loader.conf > > > reboot > > > load if_bge > > > acpiconf -s3 > > > same results :( > > > > > > > Ok, here is new try. > > > > Let's get on to it then ! > > Well now, the situation has improved .. here's what I got: > http://pastebin.com/f2d152f91 > > lines 2 to 8 == kldload if_bge > line 9 == acpiconf -s3 > lines 10 to 18 == resume (notice there are only 2 messages now: lines 12 and > 13!) > lines 19 to 36 == ifconfig bge0 > lines 37 to 42 == me mounting the pendrive to get the messages from > /var/log/messages =P > lines 43 to 46 == kldunload if_bge0 > > I think you narrowed it down quite a lot this time ! > Hmm, not actually. I guess it just removed unnecessary operation for PHY but it still failed to get functional state. :-( > I have to warn you though, that this time, my kernel was compiled using a > ... certainly modified /etc/make.conf file ... just in case you need to know > how it looks like, you'll fin it in here: > http://pastebin.com/f42e356d2 > > If you think that make.conf config may interfere with your pourposes or > tests, just let me know and I'll use a default one. I think that's ok. > The good thing about that make.conf is that it saves me quite a time on > every recompile ;) > > > im at your service .. tell me what to do and I'll do it :) > > > > > > > Thanks a lot for your patience and continuous support to fixing > > bugs. > > > > Thank _YOU_ for keeping the good work up and for trying to solve a really > nasty bug that makes every bge(4) user (think of it > _as_every_dell_notebook_owner_) unable to get his laptop to resume .. or > even use FreeBSD altoghether just because of this. > > Dear Pyung, rest assured that as long as you remain commited to fix this, or > any other bug that I can help you with, you can count on me to do everything > that may be within the reach of my hand. As long as you remain commited, > I'll be there, commited just as well :) > Thanks a lot! This really helps me a lot to fix the bug. Here is 4-th try. I added a couple of debug messages to see what register contents it have after resume. Thanks in advance. --ey/N+yb7u/X9mFhi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.5906.diff4" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 199499) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -1732,7 +1732,8 @@ #define BGE_MODE_CTL 0x6800 #define BGE_MISC_CFG 0x6804 #define BGE_MISC_LOCAL_CTL 0x6808 -#define BGE_CPU_EVENT 0x6810 +#define BGE_RX_CPU_EVENT 0x6810 +#define BGE_TX_CPU_EVENT 0x6820 #define BGE_EE_ADDR 0x6838 #define BGE_EE_DATA 0x683C #define BGE_EE_CTL 0x6840 @@ -1853,6 +1854,9 @@ #define BGE_SSRAMSIZE_8MB 0x00140000 #define BGE_SSRAMSIZE_16M 0x00180000 +/* RX CPU event register */ +#define BGE_RX_CPU_EVENT_SW7 0x00004000 + /* EEPROM address register */ #define BGE_EEADDR_ADDRESS 0x0000FFFC #define BGE_EEADDR_HALFCLK 0x01FF0000 Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 199499) +++ sys/dev/bge/if_bge.c (working copy) @@ -1320,11 +1320,12 @@ if (sc->bge_asf_mode) { bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_PAUSE); - CSR_WRITE_4(sc, BGE_CPU_EVENT, - CSR_READ_4(sc, BGE_CPU_EVENT) | (1 << 14)); + CSR_WRITE_4(sc, BGE_RX_CPU_EVENT, + CSR_READ_4(sc, BGE_RX_CPU_EVENT) | BGE_RX_CPU_EVENT_SW7); for (i = 0; i < 100; i++ ) { - if (!(CSR_READ_4(sc, BGE_CPU_EVENT) & (1 << 14))) + if (!(CSR_READ_4(sc, BGE_RX_CPU_EVENT) & + BGE_RX_CPU_EVENT_SW7)) break; DELAY(10); } @@ -1540,12 +1541,13 @@ /* Wait until queue initialization is complete */ for (i = 0; i < BGE_TIMEOUT; i++) { DELAY(10); - if (CSR_READ_4(sc, BGE_FTQ_RESET) == 0) + if ((val = CSR_READ_4(sc, BGE_FTQ_RESET)) == 0) break; } if (i == BGE_TIMEOUT) { - device_printf(sc->bge_dev, "flow-through queue init failed\n"); + device_printf(sc->bge_dev, + "flow-through queue init failed(0x%08x)\n", val); return (ENXIO); } @@ -2995,6 +2997,15 @@ } } + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + val = CSR_READ_4(sc, BGE_VCPU_STATUS); + CSR_WRITE_4(sc, BGE_VCPU_STATUS, + val | BGE_VCPU_STATUS_DRV_RESET); + val = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); + CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, + val & ~BGE_VCPU_EXT_CTRL_HALT_CPU); + } + /* * Set GPHY Power Down Override to leave GPHY * powered up in D0 uninitialized. @@ -3005,15 +3016,6 @@ /* Issue global reset */ write_op(sc, BGE_MISC_CFG, reset); - if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { - val = CSR_READ_4(sc, BGE_VCPU_STATUS); - CSR_WRITE_4(sc, BGE_VCPU_STATUS, - val | BGE_VCPU_STATUS_DRV_RESET); - val = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); - CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, - val & ~BGE_VCPU_EXT_CTRL_HALT_CPU); - } - DELAY(1000); /* XXX: Broadcom Linux driver. */ @@ -3491,8 +3493,9 @@ BGE_FW_DRV_ALIVE); bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_LEN, 4); bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_DATA, 3); - CSR_WRITE_4(sc, BGE_CPU_EVENT, - CSR_READ_4(sc, BGE_CPU_EVENT) | (1 << 14)); + CSR_WRITE_4(sc, BGE_RX_CPU_EVENT, + CSR_READ_4(sc, BGE_RX_CPU_EVENT) | + BGE_RX_CPU_EVENT_SW7); } } } @@ -3919,6 +3922,7 @@ /* Init RX ring. */ if (bge_init_rx_ring_std(sc) != 0) { device_printf(sc->bge_dev, "no memory for std Rx buffers.\n"); + ifp->if_drv_flags |= IFF_DRV_RUNNING; bge_stop(sc); return; } @@ -3946,6 +3950,7 @@ (MCLBYTES - ETHER_ALIGN)) { if (bge_init_rx_ring_jumbo(sc) != 0) { device_printf(sc->bge_dev, "no memory for std Rx buffers.\n"); + ifp->if_drv_flags |= IFF_DRV_RUNNING; bge_stop(sc); return; } @@ -4181,11 +4186,8 @@ bge_setmulti(sc); } else bge_init_locked(sc); - } else { - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - bge_stop(sc); - } - } + } else + bge_stop(sc); sc->bge_if_flags = ifp->if_flags; BGE_UNLOCK(sc); error = 0; @@ -4301,17 +4303,15 @@ bge_stop(struct bge_softc *sc) { struct ifnet *ifp; - struct ifmedia_entry *ifm; - struct mii_data *mii = NULL; - int mtmp, itmp; + uint32_t val; + int i; BGE_LOCK_ASSERT(sc); ifp = sc->bge_ifp; + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + return; - if ((sc->bge_flags & BGE_FLAG_TBI) == 0) - mii = device_get_softc(sc->bge_miibus); - callout_stop(&sc->bge_stat_ch); /* Disable host interrupts. */ @@ -4328,6 +4328,7 @@ * Disable all of the receiver blocks. */ BGE_CLRBIT(sc, BGE_RX_MODE, BGE_RXMODE_ENABLE); + DELAY(10); BGE_CLRBIT(sc, BGE_RBDI_MODE, BGE_RBDIMODE_ENABLE); BGE_CLRBIT(sc, BGE_RXLP_MODE, BGE_RXLPMODE_ENABLE); if (!(BGE_IS_5705_PLUS(sc))) @@ -4347,6 +4348,18 @@ if (!(BGE_IS_5705_PLUS(sc))) BGE_CLRBIT(sc, BGE_DMAC_MODE, BGE_DMACMODE_ENABLE); BGE_CLRBIT(sc, BGE_SBDC_MODE, BGE_SBDCMODE_ENABLE); + BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_TXDMA_ENB); + DELAY(40); + BGE_CLRBIT(sc, BGE_TX_MODE, BGE_TXMODE_ENABLE); + for (i = 1000; i > 0; i--) { + val = CSR_READ_4(sc, BGE_TX_MODE); + if ((val & BGE_TXMODE_ENABLE) == 0) + break; + DELAY(10); + } + if (i == 0) + device_printf(sc->bge_dev, "Disabling TX mode failed(0x%08x)", + val); /* * Shut down all of the memory managers and related @@ -4385,27 +4398,6 @@ /* Free TX buffers. */ bge_free_tx_ring(sc); - /* - * Isolate/power down the PHY, but leave the media selection - * unchanged so that things will be put back to normal when - * we bring the interface back up. - */ - if ((sc->bge_flags & BGE_FLAG_TBI) == 0) { - itmp = ifp->if_flags; - ifp->if_flags |= IFF_UP; - /* - * If we are called from bge_detach(), mii is already NULL. - */ - if (mii != NULL) { - ifm = mii->mii_media.ifm_cur; - mtmp = ifm->ifm_media; - ifm->ifm_media = IFM_ETHER | IFM_NONE; - mii_mediachg(mii); - ifm->ifm_media = mtmp; - } - ifp->if_flags = itmp; - } - sc->bge_tx_saved_considx = BGE_TXCONS_UNSET; /* Clear MAC's link state (PHY may still have link UP). */ @@ -4452,9 +4444,18 @@ { struct bge_softc *sc; struct ifnet *ifp; + uint16_t pmstat; + int pmc; sc = device_get_softc(dev); BGE_LOCK(sc); + if (pci_find_extcap(dev, PCIY_PMG, &pmc) != 0) { + pmstat = pci_read_config(dev, pmc + PCIR_POWER_STATUS, 2); + device_printf(dev, "pmstat = 0x%04x\n", pmstat); + pmstat &= ~PCIM_PSTAT_PMEENABLE; + pmstat &= ~PCIM_PSTAT_DMASK; + pci_write_config(dev, pmc + PCIR_POWER_STATUS, pmstat, 2); + } ifp = sc->bge_ifp; if (ifp->if_flags & IFF_UP) { bge_init_locked(sc); --ey/N+yb7u/X9mFhi-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 21:11:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CCAC106568D; Thu, 19 Nov 2009 21:11:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF1628FC13; Thu, 19 Nov 2009 21:11:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAJLBcYE040080; Thu, 19 Nov 2009 16:11:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAJLBceX040079; Thu, 19 Nov 2009 21:11:38 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 19 Nov 2009 21:11:38 GMT Message-Id: <200911192111.nAJLBceX040079@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:11:39 -0000 TB --- 2009-11-19 20:06:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-19 20:06:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-11-19 20:06:19 - cleaning the object tree TB --- 2009-11-19 20:06:41 - cvsupping the source tree TB --- 2009-11-19 20:06:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-11-19 20:07:06 - building world TB --- 2009-11-19 20:07:06 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 20:07:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 20:07:06 - TARGET=powerpc TB --- 2009-11-19 20:07:06 - TARGET_ARCH=powerpc TB --- 2009-11-19 20:07:06 - TZ=UTC TB --- 2009-11-19 20:07:06 - __MAKE_CONF=/dev/null TB --- 2009-11-19 20:07:06 - cd /src TB --- 2009-11-19 20:07:06 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 19 20:07:06 UTC 2009 >>> 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 Thu Nov 19 21:07:00 UTC 2009 TB --- 2009-11-19 21:07:00 - generating LINT kernel config TB --- 2009-11-19 21:07:00 - cd /src/sys/powerpc/conf TB --- 2009-11-19 21:07:00 - /usr/bin/make -B LINT TB --- 2009-11-19 21:07:00 - building LINT kernel TB --- 2009-11-19 21:07:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 21:07:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 21:07:00 - TARGET=powerpc TB --- 2009-11-19 21:07:00 - TARGET_ARCH=powerpc TB --- 2009-11-19 21:07:00 - TZ=UTC TB --- 2009-11-19 21:07:00 - __MAKE_CONF=/dev/null TB --- 2009-11-19 21:07:00 - cd /src TB --- 2009-11-19 21:07:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 19 21:07:00 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/nge/if_nge.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/nxge/if_nxge.c cc1: warnings being treated as errors /src/sys/dev/nxge/if_nxge.c: In function 'xge_flush_txds': /src/sys/dev/nxge/if_nxge.c:2946: warning: unused variable 'ifnetp' /src/sys/dev/nxge/if_nxge.c: In function 'xge_send_locked': /src/sys/dev/nxge/if_nxge.c:3107: error: label at end of compound statement *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-19 21:11:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-19 21:11:38 - ERROR: failed to build lint kernel TB --- 2009-11-19 21:11:38 - 2944.98 user 592.30 system 3918.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 21:25:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DCFC106566B; Thu, 19 Nov 2009 21:25:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AD9F28FC16; Thu, 19 Nov 2009 21:25:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAJLPGUo094338; Thu, 19 Nov 2009 16:25:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAJLPG7l094334; Thu, 19 Nov 2009 21:25:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 19 Nov 2009 21:25:16 GMT Message-Id: <200911192125.nAJLPG7l094334@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:25:21 -0000 TB --- 2009-11-19 20:24:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-19 20:24:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-11-19 20:24:04 - cleaning the object tree TB --- 2009-11-19 20:24:20 - cvsupping the source tree TB --- 2009-11-19 20:24:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-11-19 20:25:00 - building world TB --- 2009-11-19 20:25:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 20:25:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 20:25:00 - TARGET=sparc64 TB --- 2009-11-19 20:25:00 - TARGET_ARCH=sparc64 TB --- 2009-11-19 20:25:00 - TZ=UTC TB --- 2009-11-19 20:25:00 - __MAKE_CONF=/dev/null TB --- 2009-11-19 20:25:00 - cd /src TB --- 2009-11-19 20:25:00 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 19 20:25:00 UTC 2009 >>> 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 Thu Nov 19 21:20:28 UTC 2009 TB --- 2009-11-19 21:20:28 - generating LINT kernel config TB --- 2009-11-19 21:20:28 - cd /src/sys/sparc64/conf TB --- 2009-11-19 21:20:28 - /usr/bin/make -B LINT TB --- 2009-11-19 21:20:28 - building LINT kernel TB --- 2009-11-19 21:20:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 21:20:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 21:20:28 - TARGET=sparc64 TB --- 2009-11-19 21:20:28 - TARGET_ARCH=sparc64 TB --- 2009-11-19 21:20:28 - TZ=UTC TB --- 2009-11-19 21:20:28 - __MAKE_CONF=/dev/null TB --- 2009-11-19 21:20:28 - cd /src TB --- 2009-11-19 21:20:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 19 21:20:28 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/nge/if_nge.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/nxge/if_nxge.c cc1: warnings being treated as errors /src/sys/dev/nxge/if_nxge.c: In function 'xge_flush_txds': /src/sys/dev/nxge/if_nxge.c:2946: warning: unused variable 'ifnetp' /src/sys/dev/nxge/if_nxge.c: In function 'xge_send_locked': /src/sys/dev/nxge/if_nxge.c:3107: error: label at end of compound statement *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-19 21:25:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-19 21:25:16 - ERROR: failed to build lint kernel TB --- 2009-11-19 21:25:16 - 2787.52 user 572.00 system 3672.00 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 21:33:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14BA4106566B; Thu, 19 Nov 2009 21:33:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B2E868FC22; Thu, 19 Nov 2009 21:33:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAJLXUcH015571; Thu, 19 Nov 2009 16:33:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAJLXU0l015570; Thu, 19 Nov 2009 21:33:30 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 19 Nov 2009 21:33:30 GMT Message-Id: <200911192133.nAJLXU0l015570@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:33:32 -0000 TB --- 2009-11-19 20:33:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-19 20:33:29 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-11-19 20:33:29 - cleaning the object tree TB --- 2009-11-19 20:33:41 - cvsupping the source tree TB --- 2009-11-19 20:33:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-11-19 20:34:04 - building world TB --- 2009-11-19 20:34:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 20:34:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 20:34:04 - TARGET=sun4v TB --- 2009-11-19 20:34:04 - TARGET_ARCH=sparc64 TB --- 2009-11-19 20:34:04 - TZ=UTC TB --- 2009-11-19 20:34:04 - __MAKE_CONF=/dev/null TB --- 2009-11-19 20:34:04 - cd /src TB --- 2009-11-19 20:34:04 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 19 20:34:05 UTC 2009 >>> 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 Thu Nov 19 21:28:39 UTC 2009 TB --- 2009-11-19 21:28:39 - generating LINT kernel config TB --- 2009-11-19 21:28:39 - cd /src/sys/sun4v/conf TB --- 2009-11-19 21:28:39 - /usr/bin/make -B LINT TB --- 2009-11-19 21:28:39 - building LINT kernel TB --- 2009-11-19 21:28:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-19 21:28:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-19 21:28:39 - TARGET=sun4v TB --- 2009-11-19 21:28:39 - TARGET_ARCH=sparc64 TB --- 2009-11-19 21:28:39 - TZ=UTC TB --- 2009-11-19 21:28:39 - __MAKE_CONF=/dev/null TB --- 2009-11-19 21:28:39 - cd /src TB --- 2009-11-19 21:28:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 19 21:28:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/nge/if_nge.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/nxge/if_nxge.c cc1: warnings being treated as errors /src/sys/dev/nxge/if_nxge.c: In function 'xge_flush_txds': /src/sys/dev/nxge/if_nxge.c:2946: warning: unused variable 'ifnetp' /src/sys/dev/nxge/if_nxge.c: In function 'xge_send_locked': /src/sys/dev/nxge/if_nxge.c:3107: error: label at end of compound statement *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-19 21:33:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-19 21:33:30 - ERROR: failed to build lint kernel TB --- 2009-11-19 21:33:30 - 2788.72 user 565.26 system 3601.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 22:32:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9BCA106566B for ; Thu, 19 Nov 2009 22:32:29 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0748FC08 for ; Thu, 19 Nov 2009 22:32:28 +0000 (UTC) Received: by bwz5 with SMTP id 5so3147852bwz.3 for ; Thu, 19 Nov 2009 14:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qzfbWVp9WSKp7pEyg++48h0MedCN/J/ZHJDLRjjPqxg=; b=PIRlYafC16QY+K3CawtiGe5KnEhFCX+GBo2I66uXg57hpn0FZeaxSyh8CvXSn23RAP 1JQ1wb/bDpRG0uoihrh4msctm6BvPQ/IA3qVaQU3tF2OKdh4UOsasD6qLhLKqHYaFLBT NH6CObwHRCjA1IrfFYeYq1cmc0yrBWgKB0XcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HfM9PG8IgOGNfcBCJ6qAcFQfsx/0F8sidHWAfEuRdsUqAVHRJ8OqRlIUv+nbyv2AER DLi73ClKomzZpFwILrkz/YteYr597mNcHQgVy3AIHOQccDU9HGkjyuhD7I2yb0CASMXt kQmZ4vkkMYiBW69vC8vkWJJRfJZtKKV87jv24= MIME-Version: 1.0 Received: by 10.103.87.27 with SMTP id p27mr262022mul.125.1258669947972; Thu, 19 Nov 2009 14:32:27 -0800 (PST) In-Reply-To: <20091119203720.GT1262@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911171650.06834.gnemmi@gmail.com> <20091117193208.GI1262@michelle.cdnetworks.com> <200911171917.41906.gnemmi@gmail.com> <20091117232347.GJ1262@michelle.cdnetworks.com> <20091118005724.GK1262@michelle.cdnetworks.com> <19e9a5dc0911172040g1107423ck72d30460b030ca27@mail.gmail.com> <20091118233225.GP1262@michelle.cdnetworks.com> <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> <20091119203720.GT1262@michelle.cdnetworks.com> Date: Thu, 19 Nov 2009 19:32:27 -0300 Message-ID: <19e9a5dc0911191432r749296ebkeb4be431d43e5c5f@mail.gmail.com> From: Gonzalo Nemmi To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Thu, 19 Nov 2009 22:32:29 -0000 On Thu, Nov 19, 2009 at 5:37 PM, Pyun YongHyeon wrote: > On Thu, Nov 19, 2009 at 01:27:03AM -0300, Gonzalo Nemmi wrote: > > On Wed, Nov 18, 2009 at 8:32 PM, Pyun YongHyeon > wrote: > > > > > On Wed, Nov 18, 2009 at 01:40:24AM -0300, Gonzalo Nemmi wrote: > > > > > > [...] > > > > > > > I just tried ... > > > > echo 'hw.bge.allow_asf="1"' >> /boot/loader.conf > > > > reboot > > > > load if_bge > > > > acpiconf -s3 > > > > same results :( > > > > > > > > > > Ok, here is new try. > > > > > > > Let's get on to it then ! > > > > Well now, the situation has improved .. here's what I got: > > http://pastebin.com/f2d152f91 > > > > lines 2 to 8 == kldload if_bge > > line 9 == acpiconf -s3 > > lines 10 to 18 == resume (notice there are only 2 messages now: lines 12 > and > > 13!) > > lines 19 to 36 == ifconfig bge0 > > lines 37 to 42 == me mounting the pendrive to get the messages from > > /var/log/messages =P > > lines 43 to 46 == kldunload if_bge0 > > > > I think you narrowed it down quite a lot this time ! > > > > Hmm, not actually. I guess it just removed unnecessary operation > for PHY but it still failed to get functional state. :-( > > > I have to warn you though, that this time, my kernel was compiled using a > > ... certainly modified /etc/make.conf file ... just in case you need to > know > > how it looks like, you'll fin it in here: > > http://pastebin.com/f42e356d2 > > > > If you think that make.conf config may interfere with your pourposes or > > tests, just let me know and I'll use a default one. > > I think that's ok. > > > The good thing about that make.conf is that it saves me quite a time on > > every recompile ;) > > > > > im at your service .. tell me what to do and I'll do it :) > > > > > > > > > > Thanks a lot for your patience and continuous support to fixing > > > bugs. > > > > > > > Thank _YOU_ for keeping the good work up and for trying to solve a really > > nasty bug that makes every bge(4) user (think of it > > _as_every_dell_notebook_owner_) unable to get his laptop to resume .. or > > even use FreeBSD altoghether just because of this. > > > > Dear Pyung, rest assured that as long as you remain commited to fix this, > or > > any other bug that I can help you with, you can count on me to do > everything > > that may be within the reach of my hand. As long as you remain commited, > > I'll be there, commited just as well :) > > > > Thanks a lot! This really helps me a lot to fix the bug. > Here is 4-th try. I added a couple of debug messages to see what > register contents it have after resume. > > Thanks in advance. > Pyung, I have problems applying your patch. 4 out 13 hunks fail. Take a look in here. http://pastebin.com/f7eab233f I tried to recompile anyways but buildkernel failed at bge ... Can you tell me what to do to apply it cleanly and recompile? Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 22:57:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0817B106566B for ; Thu, 19 Nov 2009 22:57:11 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3F88FC13 for ; Thu, 19 Nov 2009 22:57:10 +0000 (UTC) Received: (qmail 27002 invoked by uid 399); 19 Nov 2009 22:30:30 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Nov 2009 22:30:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B05C709.2090005@dougbarton.us> Date: Thu, 19 Nov 2009 14:30:33 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 Nov 2009 23:03:34 +0000 Subject: multimedia/vlc causes a panic if media files are on 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: Thu, 19 Nov 2009 22:57:11 -0000 Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=140648 for more information, including a trace. There is also some evidence that the same problem is triggered by accessing files on an NTFS partition. The VLC folks have suggested that the problem may be related to threading. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 23:04:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACEB01065697; Thu, 19 Nov 2009 23:04:14 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 3B08C8FC14; Thu, 19 Nov 2009 23:04:14 +0000 (UTC) Received: from bolt.zol (62-121-98-25.home.aster.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id C95E628; Fri, 20 Nov 2009 00:08:16 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" , "John Baldwin" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> <1258603057.2303.92.camel@balrog.2hip.net> <1258647835.2303.105.camel@balrog.2hip.net> Date: Fri, 20 Nov 2009 00:04:16 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: <1258647835.2303.105.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Matt Reimer Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 23:04:14 -0000 On Thu, 19 Nov 2009 17:23:55 +0100, Robert Noland wrote: > Ok, I was concerned about the assembly code... So, I've been chatting > with jhb@ this morning. Please try this patch that jhb@ came up with > instead of Matt's latest patch. On Thu, 19 Nov 2009 17:55:10 +0100, John Baldwin wrote: > Actually, I had missed updating one place, please use this instead. > Also, I > think that this will fix using > 2TB volumes even in the GPT case as > zfsboot.c was always using 32-bit LBAs even for the GPT case. Thanks a million! Both patches works for me. Great work! I know that we have missed the boat but maybe there is opportunity to catch it up by swimming and commit these patches to 8-STABLE before 8.0-RELEASE? Thanks! -- am From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 23:27:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04D31106566B for ; Thu, 19 Nov 2009 23:27:25 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id B3A498FC0C for ; Thu, 19 Nov 2009 23:27:24 +0000 (UTC) Received: by gxk10 with SMTP id 10so356071gxk.3 for ; Thu, 19 Nov 2009 15:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V/tJi0IDiX1zdZLl+txQIar0nN5bk0fk7vyw0QD5xXI=; b=fdWAdY/ri1hSMHbikZA3puQFLtTtQ0CV7geTUCeKpq40EDbGi5uA13ViQAWkemtUqG CbeI3vpZeWTcT4TUPMOxP2GzIXgsLFUFq9GThRp6M4iPPVUk2LK8QCE9YBp5RdPXsAv6 Rk16awX27mPI9T/sf/XgYG3wRtYgA48BFEj+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ARhzfFVbCFzbVeooY3l61L2ePwNAorSRDivWil1TOgFtIiKtSSrJV52fb9EHRC5pQy fOdTyyAzPW/NUGlluqHsZHk+LELDfEEqh3FlJFyHMV1+smqmNqo9luz3bVpGdIbM/Y0c T9WFgEgupw34rbp9Z1JDGJ2E9GovqP/0Wb66g= MIME-Version: 1.0 Received: by 10.90.16.14 with SMTP id 14mr1010874agp.102.1258673243682; Thu, 19 Nov 2009 15:27:23 -0800 (PST) In-Reply-To: <1c0233f80911171234i5b908678lef2327ab7c040c81@mail.gmail.com> References: <1c0233f80911171234i5b908678lef2327ab7c040c81@mail.gmail.com> Date: Thu, 19 Nov 2009 18:27:23 -0500 Message-ID: From: "illoai@gmail.com" To: neutral neutral Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: High INTERRUPT rate on CPU 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2009 23:27:25 -0000 2009/11/17 neutral neutral : > Hello, > > Yesterday I get a fresh install of FreeBSD 8.0 RC3 Current. However just > some hours after the installation the machine began very slow/laggy. . . . > $ vmstat -i > interrupt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 = =A0 =A0 rate > irq1: atkbd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 201 =A0 =A0 = =A0 =A0 =A00 > irq12: psm0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A09 =A0 = =A0 =A0 =A0 =A00 > irq16: fwohci0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 = =A0 =A0 =A00 > irq19: uhci2 ehci* =A0 =A0 =A0 =A0 =A0 =A0 =A025229879 =A0 =A0 =A089151 > irq23: uhci3 ehci1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04852 =A0 =A0 =A0 = =A0 17 > cpu0: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 565386 =A0 =A0 = =A0 1997 > irq256: mskc0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0389 =A0 =A0 = =A0 =A0 =A01 > cpu1: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 562755 =A0 =A0 = =A0 1988 > Total =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 26363473 =A0 = =A0 =A093157 > $ > > > $ dmesg | grep uhci2 > uhci2: uhci2: port 0x1840-0x185f irq 19 at > device 26.2 on pci0 > uhci2: [ITHREAD] > uhci2: LegSup =3D 0x0010 > usbus2: on uhci2 > SB controller> port 0x1840-0x185f irq 19 at device 26.2 on pci0 > uhci2: [ITHREAD] > uhci2: LegSup =3D 0x0010 > usbus2: on uhci2 Umm, IRQ19 looks a bit suspect. My noisiest non-CPU IRQ is running 31, so you're only 3 orders of magnitude higher. What usb devices do you have attached to those controllers? --=20 -- From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 23:35:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78DEA106566B for ; Thu, 19 Nov 2009 23:35:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 263738FC14 for ; Thu, 19 Nov 2009 23:35:45 +0000 (UTC) Received: by qyk6 with SMTP id 6so1504012qyk.3 for ; Thu, 19 Nov 2009 15:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=srG41NkkgQURw9E9cV0iMwB9XfIj3hz/Wwt2vSi65As=; b=A6eyDAWwPB5d4WbGERxbow6brT+mzX+Ut9DC6C+iUSS+jeRfiPuWXPIIexqnps6Uqu wmrbqFzEbze83YUHF/7xL/hiohgAkp+yvmBvUMVcylUNbbXYqG4u+i88qYJienIATqZ9 tjp0JUzS7Of8M0nnern7jQR8GOEA3Iw+EwQNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=R/aKcWHNgM2leqD+2hiID82bRhcLfNxnsVmwaTF07BpR5ldX36OqYTc03ohVD68TX2 hEUCFoOQj3nU+S2KWsv8SiJmwy/5PjKniRj9Syr+5iVPC5GP0k4kEVprwOkZQhU6H9Qt A0m3VBmyVE0u09S2EPVDffjSU7WhLrRaRTl+I= Received: by 10.224.79.234 with SMTP id q42mr433006qak.364.1258673745177; Thu, 19 Nov 2009 15:35:45 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm1166803qwe.15.2009.11.19.15.35.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 15:35:43 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 19 Nov 2009 15:35:12 -0800 From: Pyun YongHyeon Date: Thu, 19 Nov 2009 15:35:12 -0800 To: Gonzalo Nemmi Message-ID: <20091119233512.GV1262@michelle.cdnetworks.com> References: <200911171650.06834.gnemmi@gmail.com> <20091117193208.GI1262@michelle.cdnetworks.com> <200911171917.41906.gnemmi@gmail.com> <20091117232347.GJ1262@michelle.cdnetworks.com> <20091118005724.GK1262@michelle.cdnetworks.com> <19e9a5dc0911172040g1107423ck72d30460b030ca27@mail.gmail.com> <20091118233225.GP1262@michelle.cdnetworks.com> <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> <20091119203720.GT1262@michelle.cdnetworks.com> <19e9a5dc0911191432r749296ebkeb4be431d43e5c5f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19e9a5dc0911191432r749296ebkeb4be431d43e5c5f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Thu, 19 Nov 2009 23:35:46 -0000 On Thu, Nov 19, 2009 at 07:32:27PM -0300, Gonzalo Nemmi wrote: > On Thu, Nov 19, 2009 at 5:37 PM, Pyun YongHyeon wrote: > > > On Thu, Nov 19, 2009 at 01:27:03AM -0300, Gonzalo Nemmi wrote: > > > On Wed, Nov 18, 2009 at 8:32 PM, Pyun YongHyeon > > wrote: > > > > > > > On Wed, Nov 18, 2009 at 01:40:24AM -0300, Gonzalo Nemmi wrote: > > > > > > > > [...] > > > > > > > > > I just tried ... > > > > > echo 'hw.bge.allow_asf="1"' >> /boot/loader.conf > > > > > reboot > > > > > load if_bge > > > > > acpiconf -s3 > > > > > same results :( > > > > > > > > > > > > > Ok, here is new try. > > > > > > > > > > Let's get on to it then ! > > > > > > Well now, the situation has improved .. here's what I got: > > > http://pastebin.com/f2d152f91 > > > > > > lines 2 to 8 == kldload if_bge > > > line 9 == acpiconf -s3 > > > lines 10 to 18 == resume (notice there are only 2 messages now: lines 12 > > and > > > 13!) > > > lines 19 to 36 == ifconfig bge0 > > > lines 37 to 42 == me mounting the pendrive to get the messages from > > > /var/log/messages =P > > > lines 43 to 46 == kldunload if_bge0 > > > > > > I think you narrowed it down quite a lot this time ! > > > > > > > Hmm, not actually. I guess it just removed unnecessary operation > > for PHY but it still failed to get functional state. :-( > > > > > I have to warn you though, that this time, my kernel was compiled using a > > > ... certainly modified /etc/make.conf file ... just in case you need to > > know > > > how it looks like, you'll fin it in here: > > > http://pastebin.com/f42e356d2 > > > > > > If you think that make.conf config may interfere with your pourposes or > > > tests, just let me know and I'll use a default one. > > > > I think that's ok. > > > > > The good thing about that make.conf is that it saves me quite a time on > > > every recompile ;) > > > > > > > im at your service .. tell me what to do and I'll do it :) > > > > > > > > > > > > > Thanks a lot for your patience and continuous support to fixing > > > > bugs. > > > > > > > > > > Thank _YOU_ for keeping the good work up and for trying to solve a really > > > nasty bug that makes every bge(4) user (think of it > > > _as_every_dell_notebook_owner_) unable to get his laptop to resume .. or > > > even use FreeBSD altoghether just because of this. > > > > > > Dear Pyung, rest assured that as long as you remain commited to fix this, > > or > > > any other bug that I can help you with, you can count on me to do > > everything > > > that may be within the reach of my hand. As long as you remain commited, > > > I'll be there, commited just as well :) > > > > > > > Thanks a lot! This really helps me a lot to fix the bug. > > Here is 4-th try. I added a couple of debug messages to see what > > register contents it have after resume. > > > > Thanks in advance. > > > > Pyung, I have problems applying your patch. 4 out 13 hunks fail. > Take a look in here. > http://pastebin.com/f7eab233f > > I tried to recompile anyways but buildkernel failed at bge ... > > Can you tell me what to do to apply it cleanly and recompile? > Hmm, I guess it was caused by the difference between HEAD and 8.0. I've uploaded complete bge(4) files to the following URL. http://people.freebsd.org/~yongari/bge/resume/if_bge.c http://people.freebsd.org/~yongari/bge/resume/if_bgereg.h Save your original bge(4) files in sys/dev/bge directory and download above files and then rebuild. Hope this helps. > Best Regards > Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 00:00:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E391065670 for ; Fri, 20 Nov 2009 00:00:57 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id EAFAC8FC0A for ; Fri, 20 Nov 2009 00:00:56 +0000 (UTC) Received: by fxm27 with SMTP id 27so3175640fxm.3 for ; Thu, 19 Nov 2009 16:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=BbRKt4d9GZLY3wr98uBJM7UGcAO2VdkfEWxJ2pxn6FM=; b=Gppe5Xz2HIDefvByR+T2aCFDmh8kedcZ44yXN2Q4an82uA7d985/2bBCl6wC0Cy5Fi bkhhZkFZPpKJL5Ijh9j9xtu0XroImZ0Nm3XCwuVd0mYr4ivU/AdNv2vifhCDLInlw0Qn RC/WttgZ4y29VEzaeuAVr98d4A2keIlQJ59C0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=LlmKW95oKqDGWpaeVccroAlJs7BukDgT65DKDro4PkN1ElIU2URFRHbMC8Jj24Gri+ MHE7nHERkfTiJ0Dd8ID0fu1EAtbP3iS3sahhPgnQHEqQANhWB5rXugouOfSPv0CKnK5z bU8Ux8/3G+BYm+2qwAymHq3FZLYEggkFiSgtI= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.57.22 with SMTP id a22mr112943fah.4.1258675255653; Thu, 19 Nov 2009 16:00:55 -0800 (PST) In-Reply-To: <1244373651.4a2ba2931774f@imp.free.fr> References: <4A2A878D.30203@free.fr> <20090607044802.GB51551@michelle.cdnetworks.co.kr> <1244373651.4a2ba2931774f@imp.free.fr> Date: Fri, 20 Nov 2009 01:00:55 +0100 X-Google-Sender-Auth: 5202d65213394301 Message-ID: <3bbf2fe10911191600r3b922910oa780b35f9cfce47b@mail.gmail.com> From: Attilio Rao To: francklarchange@free.fr Content-Type: text/plain; charset=UTF-8 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: Attansic L1e Gigabit Ethernet driver support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2009 00:00:57 -0000 2009/6/7 : > > I'm sorry, I actually have the same problem than in thread "ACPI problem with > new acer aspire 6930G", I misread the logs and didn't realized that acpi was the > problem, here is my dmesg : > > ale0: irq 17 at device 0.0 on pci9 > ale0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). > ale0: cannot allocate memory resources. > device_attach: ale0 attach returned 6 The problem is that some some buggy BIOS do force ACPI to clobber the start/ending memory regions of some PCI bridges to 0/0 then the PCI bridges cannot request 0/0xfff... memory ranges. I would bet ale is the only device linked to this specific PCI bridge. A way to solve this would be jhb's multipass mechanism to be completed with resources discovering&allocation mechanism. Shortly: I don't expect this fixed in the near term. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 04:05:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9F94106568B for ; Fri, 20 Nov 2009 04:05:00 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF2E8FC1B for ; Fri, 20 Nov 2009 04:04:59 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so2742810fga.13 for ; Thu, 19 Nov 2009 20:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iZRPJRPJCR3Wq5r4RoKbedlckSGUc1AJtr/5AL19tcg=; b=IXpDLIdK4p9XlvQjDzNyouU2BNWvlX7bazfks6/40of7aWrmrgtVAg7LtcYzlMcwlw YUmxoaD3qmms3clL02+Ae+dWQUBWi+Kc3U65GYuK4BVbIMXpnWoMLlMccH5iTXBt2iX4 1Wy937QMaNG3A09RtFhmvZnOqJSonHsskvIRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yBtQNMXve7A3TRf72vINa0/IsU9kZtUMXFXIm249OxCysxN8Fj7/ihDS1nyL5fsR2S vhDzkmuXwhfXcJCGIglCwtf0Vfm4eeZs6L44AI/AQAWzG+auK/2F9T3Ca699/1hiac7i Q7gXRrrO2rHC2vqDlyKv6YI32RymDST2KSdMg= MIME-Version: 1.0 Received: by 10.103.81.35 with SMTP id i35mr413707mul.43.1258689898987; Thu, 19 Nov 2009 20:04:58 -0800 (PST) In-Reply-To: <20091119233512.GV1262@michelle.cdnetworks.com> References: <200911171650.06834.gnemmi@gmail.com> <200911171917.41906.gnemmi@gmail.com> <20091117232347.GJ1262@michelle.cdnetworks.com> <20091118005724.GK1262@michelle.cdnetworks.com> <19e9a5dc0911172040g1107423ck72d30460b030ca27@mail.gmail.com> <20091118233225.GP1262@michelle.cdnetworks.com> <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> <20091119203720.GT1262@michelle.cdnetworks.com> <19e9a5dc0911191432r749296ebkeb4be431d43e5c5f@mail.gmail.com> <20091119233512.GV1262@michelle.cdnetworks.com> Date: Fri, 20 Nov 2009 01:04:58 -0300 Message-ID: <19e9a5dc0911192004w5788a02ema959fa218b7d345b@mail.gmail.com> From: Gonzalo Nemmi To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Fri, 20 Nov 2009 04:05:00 -0000 On Thu, Nov 19, 2009 at 8:35 PM, Pyun YongHyeon wrote: > On Thu, Nov 19, 2009 at 07:32:27PM -0300, Gonzalo Nemmi wrote: > > On Thu, Nov 19, 2009 at 5:37 PM, Pyun YongHyeon > wrote: > > > > > On Thu, Nov 19, 2009 at 01:27:03AM -0300, Gonzalo Nemmi wrote: > > > > On Wed, Nov 18, 2009 at 8:32 PM, Pyun YongHyeon > > > wrote: > > > > > > > > > On Wed, Nov 18, 2009 at 01:40:24AM -0300, Gonzalo Nemmi wrote: > > > > > > > > > > [...] > > > > > > > > > > > I just tried ... > > > > > > echo 'hw.bge.allow_asf="1"' >> /boot/loader.conf > > > > > > reboot > > > > > > load if_bge > > > > > > acpiconf -s3 > > > > > > same results :( > > > > > > > > > > > > > > > > Ok, here is new try. > > > > > > > > > > > > > Let's get on to it then ! > > > > > > > > Well now, the situation has improved .. here's what I got: > > > > http://pastebin.com/f2d152f91 > > > > > > > > lines 2 to 8 == kldload if_bge > > > > line 9 == acpiconf -s3 > > > > lines 10 to 18 == resume (notice there are only 2 messages now: lines > 12 > > > and > > > > 13!) > > > > lines 19 to 36 == ifconfig bge0 > > > > lines 37 to 42 == me mounting the pendrive to get the messages from > > > > /var/log/messages =P > > > > lines 43 to 46 == kldunload if_bge0 > > > > > > > > I think you narrowed it down quite a lot this time ! > > > > > > > > > > Hmm, not actually. I guess it just removed unnecessary operation > > > for PHY but it still failed to get functional state. :-( > > > > > > > I have to warn you though, that this time, my kernel was compiled > using a > > > > ... certainly modified /etc/make.conf file ... just in case you need > to > > > know > > > > how it looks like, you'll fin it in here: > > > > http://pastebin.com/f42e356d2 > > > > > > > > If you think that make.conf config may interfere with your pourposes > or > > > > tests, just let me know and I'll use a default one. > > > > > > I think that's ok. > > > > > > > The good thing about that make.conf is that it saves me quite a time > on > > > > every recompile ;) > > > > > > > > > im at your service .. tell me what to do and I'll do it :) > > > > > > > > > > > > > > > > Thanks a lot for your patience and continuous support to fixing > > > > > bugs. > > > > > > > > > > > > > Thank _YOU_ for keeping the good work up and for trying to solve a > really > > > > nasty bug that makes every bge(4) user (think of it > > > > _as_every_dell_notebook_owner_) unable to get his laptop to resume .. > or > > > > even use FreeBSD altoghether just because of this. > > > > > > > > Dear Pyung, rest assured that as long as you remain commited to fix > this, > > > or > > > > any other bug that I can help you with, you can count on me to do > > > everything > > > > that may be within the reach of my hand. As long as you remain > commited, > > > > I'll be there, commited just as well :) > > > > > > > > > > Thanks a lot! This really helps me a lot to fix the bug. > > > Here is 4-th try. I added a couple of debug messages to see what > > > register contents it have after resume. > > > > > > Thanks in advance. > > > > > > > Pyung, I have problems applying your patch. 4 out 13 hunks fail. > > Take a look in here. > > http://pastebin.com/f7eab233f > > > > I tried to recompile anyways but buildkernel failed at bge ... > > > > Can you tell me what to do to apply it cleanly and recompile? > > > > Hmm, I guess it was caused by the difference between HEAD and 8.0. > I've uploaded complete bge(4) files to the following URL. > http://people.freebsd.org/~yongari/bge/resume/if_bge.c > http://people.freebsd.org/~yongari/bge/resume/if_bgereg.h > > Save your original bge(4) files in sys/dev/bge directory and > download above files and then rebuild. > > Hope this helps. > Dear Pyung: Did as instructed but the result was negative .. so much so that now the system doesn't even wake up .. upon resume it just shows the usb messages ( mouse ) and then it freezes .. no more messages ( bge(4) or anything else ), no coredumps, no nothing .. it just stays there. The only way to get the system back is to do a hard reset :( As usuall, awaiting further instructions :) Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 06:41:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0626106566C; Fri, 20 Nov 2009 06:41:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C8DE18FC08; Fri, 20 Nov 2009 06:41:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nAK6fghM060987; Fri, 20 Nov 2009 01:41:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nAK6fgtD060956; Fri, 20 Nov 2009 06:41:42 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 20 Nov 2009 06:41:42 GMT Message-Id: <200911200641.nAK6fgtD060956@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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, 20 Nov 2009 06:41:43 -0000 TB --- 2009-11-20 05:08:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-20 05:08:32 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-11-20 05:08:32 - cleaning the object tree TB --- 2009-11-20 05:08:53 - cvsupping the source tree TB --- 2009-11-20 05:08:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-11-20 05:09:20 - building world TB --- 2009-11-20 05:09:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-20 05:09:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-20 05:09:20 - TARGET=ia64 TB --- 2009-11-20 05:09:20 - TARGET_ARCH=ia64 TB --- 2009-11-20 05:09:20 - TZ=UTC TB --- 2009-11-20 05:09:20 - __MAKE_CONF=/dev/null TB --- 2009-11-20 05:09:20 - cd /src TB --- 2009-11-20 05:09:20 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 20 05:09:20 UTC 2009 >>> 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 Fri Nov 20 06:25:47 UTC 2009 TB --- 2009-11-20 06:25:47 - generating LINT kernel config TB --- 2009-11-20 06:25:47 - cd /src/sys/ia64/conf TB --- 2009-11-20 06:25:47 - /usr/bin/make -B LINT TB --- 2009-11-20 06:25:47 - building LINT kernel TB --- 2009-11-20 06:25:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-20 06:25:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-20 06:25:47 - TARGET=ia64 TB --- 2009-11-20 06:25:47 - TARGET_ARCH=ia64 TB --- 2009-11-20 06:25:47 - TZ=UTC TB --- 2009-11-20 06:25:47 - __MAKE_CONF=/dev/null TB --- 2009-11-20 06:25:47 - cd /src TB --- 2009-11-20 06:25:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 20 06:25:47 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/efi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/elf_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/emulate.c cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/exception.S In file included from /src/sys/ia64/ia64/exception.S:35: ./assym.s:13:1: error: "KSTACK_PAGES" redefined In file included from /src/sys/ia64/ia64/exception.S:31: ./opt_kstack_pages.h:1:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-20 06:41:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-20 06:41:41 - ERROR: failed to build lint kernel TB --- 2009-11-20 06:41:42 - 4435.35 user 664.91 system 5589.31 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 07:12:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEA501065693 for ; Fri, 20 Nov 2009 07:12:55 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 365A88FC1C for ; Fri, 20 Nov 2009 07:12:54 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-83.belrs3.nsw.optusnet.com.au [122.106.232.83]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nAK7Cj8k010067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 18:12:47 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id nAK7CjNi050598; Fri, 20 Nov 2009 18:12:45 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id nAK7CiHb050597; Fri, 20 Nov 2009 18:12:44 +1100 (EST) (envelope-from peter) Date: Fri, 20 Nov 2009 18:12:44 +1100 From: Peter Jeremy To: "Robert N. M. Watson" Message-ID: <20091120071244.GD49534@server.vk2pj.dyndns.org> References: <200911172043.28008.gnemmi@gmail.com> <20091118000838.60CBC1CC47@ptavv.es.net> <19e9a5dc0911171905r67f4e9c4q8513782cce8f5f82@mail.gmail.com> <367b2c980911180330x32407537qa6468d230936cb85@mail.gmail.com> <866398ue25.fsf@ds4.des.no> <56A320F3-A099-4DE6-84EE-7F9CCE3A5CB4@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cQXOx3fnlpmgJsTP" Content-Disposition: inline In-Reply-To: <56A320F3-A099-4DE6-84EE-7F9CCE3A5CB4@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-current@FreeBSD.org Subject: Re: WITHOUT_TELNET=yes .. does it work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 07:12:55 -0000 --cQXOx3fnlpmgJsTP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Nov-18 14:07:32 +0000, "Robert N. M. Watson" = wrote: >On 18 Nov 2009, at 14:01, Dag-Erling Sm=F8rgrav wrote: >> tools/build/mk/OptionalObsoleteFiles.inc >>=20 >> Poor placement IMHO, we shouldn't have dependencies from src into tools. > >Its obscure location explains why it doesn't work. :-) Maybe it >should be src/OptionalFiles.inc? That said, it still sounds like a >significant maintenance problem to me: we have a lot of WITHOUT_ >options, and they may have non-trivial interactions... I suggest closer to a maintenance nightmare - expecting developers to track files that might be installed with different combinations of something like 35 build options is unrealistic. Such a file is only practical if the contents can be build mostly automatically. --=20 Peter Jeremy --cQXOx3fnlpmgJsTP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksGQWwACgkQ/opHv/APuIccjwCdFYkBAyB2kf0aqtBzpmtaMBwW umkAnjmPOCyFEk8kk006ZsLjneyXh6iH =YTQ5 -----END PGP SIGNATURE----- --cQXOx3fnlpmgJsTP-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 11:01:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95BB106566B; Fri, 20 Nov 2009 11:01:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3D77D8FC08; Fri, 20 Nov 2009 11:01:30 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nAKB1Ong059946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 13:01:24 +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.14.3/8.14.3) with ESMTP id nAKB1OE0025783; Fri, 20 Nov 2009 13:01:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nAKB1NG1025782; Fri, 20 Nov 2009 13:01:23 +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: Fri, 20 Nov 2009 13:01:23 +0200 From: Kostik Belousov To: Doug Barton Message-ID: <20091120110123.GG2331@deviant.kiev.zoral.com.ua> References: <4B05C709.2090005@dougbarton.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3aDvBnBjnpP7iyLb" Content-Disposition: inline In-Reply-To: <4B05C709.2090005@dougbarton.us> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: multimedia/vlc causes a panic if media files are on 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: Fri, 20 Nov 2009 11:01:32 -0000 --3aDvBnBjnpP7iyLb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 19, 2009 at 02:30:33PM -0800, Doug Barton wrote: > Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=3D140648 for more > information, including a trace. >=20 > There is also some evidence that the same problem is triggered by > accessing files on an NTFS partition. The VLC folks have suggested > that the problem may be related to threading. This is because msdosfs and ntfs are not mpsafe, and it seems that VLC using recently added F_RDAHEAD/F_READAHEAD fcntls. Please try this. diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 434f54a..676de65 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -718,14 +718,15 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr= _t arg) do { new =3D old =3D fp->f_flag; new |=3D FRDAHEAD; - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) =3D=3D 0); + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); readahead_vnlock_fail: VFS_UNLOCK_GIANT(vfslocked); + vfslocked =3D 0; } else { do { new =3D old =3D fp->f_flag; new &=3D ~FRDAHEAD; - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) =3D=3D 0); + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); } fdrop(fp, td); break; --3aDvBnBjnpP7iyLb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksGdwEACgkQC3+MBN1Mb4j1gQCg0gTFmpVjn8mwWfsiLGnvKSB0 cdMAoLUn7PzHF9d132OX3+jiVWZplzRQ =aSIm -----END PGP SIGNATURE----- --3aDvBnBjnpP7iyLb-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 14:16:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C2F106568B; Fri, 20 Nov 2009 14:16:59 +0000 (UTC) (envelope-from sarawgi.aditya@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2948FC0A; Fri, 20 Nov 2009 14:16:59 +0000 (UTC) Received: by pzk15 with SMTP id 15so2290670pzk.3 for ; Fri, 20 Nov 2009 06:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=YYkTAc2sEMojcEd1tn2pmgC+SHP9MkrYIH9O8p5dLTo=; b=jeG6zuph0g72qStpf+LYDDnnadA2hHa/cz12nBqUCMAA8y1v6wRjvX/MAPWcxVJbaK 5cb+tFOD2lm7M/xmltgbHixsNUlaEoFS6PB6AmQlM2gjeEUJ0vPN0rQigUONTdVrPK7r 811cHwlxfSDebQWPbSQDYAc9E8axfpJc1jEKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tJ6DMGJ7jiqiK30nPp8IFRXC7Cjk0rZNtCmsudAJZ4PhpG4VNuRl/teNmlCkHIFfDO i6tSlQgUrBDZZ/uFphgmKNXu715rcTxWONfUZh4M8Y9e1JLzndkZTIVfh6AnR9waubs/ o586qrPjw6fMq6BDEJ53IDUl3vMKb+PUzmZvo= Received: by 10.115.114.9 with SMTP id r9mr2048380wam.19.1258725358028; Fri, 20 Nov 2009 05:55:58 -0800 (PST) Received: from ([111.125.238.138]) by mx.google.com with ESMTPS id 20sm985481pxi.11.2009.11.20.05.55.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 05:55:56 -0800 (PST) Date: Fri, 20 Nov 2009 19:26:11 +0000 From: Aditya Sarawgi To: Kostik Belousov , dougb@dougbartion.us Message-ID: <4b069fec.141bf30a.7f54.ffff8735@mx.google.com> References: <4B05C709.2090005@dougbarton.us> <20091120110123.GG2331@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091120110123.GG2331@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: multimedia/vlc causes a panic if media files are on 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: Fri, 20 Nov 2009 14:16:59 -0000 On Fri, Nov 20, 2009 at 01:01:23PM +0200, Kostik Belousov wrote: > On Thu, Nov 19, 2009 at 02:30:33PM -0800, Doug Barton wrote: > > Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=140648 for more > > information, including a trace. > > > > There is also some evidence that the same problem is triggered by > > accessing files on an NTFS partition. The VLC folks have suggested > > that the problem may be related to threading. > > This is because msdosfs and ntfs are not mpsafe, and it seems that > VLC using recently added F_RDAHEAD/F_READAHEAD fcntls. > > Please try this. > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 434f54a..676de65 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -718,14 +718,15 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) > do { > new = old = fp->f_flag; > new |= FRDAHEAD; > - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == 0); > + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > readahead_vnlock_fail: > VFS_UNLOCK_GIANT(vfslocked); > + vfslocked = 0; > } else { > do { > new = old = fp->f_flag; > new &= ~FRDAHEAD; > - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == 0); > + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > } > fdrop(fp, td); > break; I have been getting panics with VLC on UFS filesytem too, Although the frequency of panics on a UFS filesystem is pretty low as compared to msdosfs and ntfs systems and they are very abrupt. I will try getting a trace. -- Aditya Sarawgi From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 14:41:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7767B106566B; Fri, 20 Nov 2009 14:41:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 47D908FC0A; Fri, 20 Nov 2009 14:41:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0569046B0D; Fri, 20 Nov 2009 09:41:38 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 364398A01D; Fri, 20 Nov 2009 09:41:37 -0500 (EST) From: John Baldwin To: "Emil Smolenski" Date: Fri, 20 Nov 2009 07:43:51 -0500 User-Agent: KMail/1.9.7 References: <1258647835.2303.105.camel@balrog.2hip.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911200743.52233.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 20 Nov 2009 09:41:37 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Matt Reimer , Robert Noland Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2009 14:41:38 -0000 On Thursday 19 November 2009 6:04:16 pm Emil Smolenski wrote: > On Thu, 19 Nov 2009 17:23:55 +0100, Robert Noland > wrote: > > Ok, I was concerned about the assembly code... So, I've been chatting > > with jhb@ this morning. Please try this patch that jhb@ came up with > > instead of Matt's latest patch. > > On Thu, 19 Nov 2009 17:55:10 +0100, John Baldwin wrote: > > Actually, I had missed updating one place, please use this instead. > > Also, I > > think that this will fix using > 2TB volumes even in the GPT case as > > zfsboot.c was always using 32-bit LBAs even for the GPT case. > > Thanks a million! Both patches works for me. Great work! > I know that we have missed the boat but maybe there is opportunity to > catch it up by swimming and commit these patches to 8-STABLE before > 8.0-RELEASE? Thanks! It is too late for 8.0 I'm afraid. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 15:59:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5332A106566C for ; Fri, 20 Nov 2009 15:59:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id D573C8FC0A for ; Fri, 20 Nov 2009 15:59:11 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NBVt5-0007cH-Em; Fri, 20 Nov 2009 16:59:07 +0100 Message-ID: <4B06BCC5.1000806@gwdg.de> Date: Fri, 20 Nov 2009 16:59:01 +0100 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: dougb@dougbarton.us References: <4B05C709.2090005@dougbarton.us> <20091120110123.GG2331@deviant.kiev.zoral.com.ua> <4b069fec.141bf30a.7f54.ffff8735@mx.google.com> In-Reply-To: <4b069fec.141bf30a.7f54.ffff8735@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Kostik Belousov , Aditya Sarawgi , freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: multimedia/vlc causes a panic if media files are on 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: Fri, 20 Nov 2009 15:59:12 -0000 On 20.11.2009 20:26 (UTC+1), Aditya Sarawgi wrote: > On Fri, Nov 20, 2009 at 01:01:23PM +0200, Kostik Belousov wrote: >> On Thu, Nov 19, 2009 at 02:30:33PM -0800, Doug Barton wrote: >>> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=140648 for more >>> information, including a trace. >>> >>> There is also some evidence that the same problem is triggered by >>> accessing files on an NTFS partition. The VLC folks have suggested >>> that the problem may be related to threading. >> This is because msdosfs and ntfs are not mpsafe, and it seems that >> VLC using recently added F_RDAHEAD/F_READAHEAD fcntls. >> >> Please try this. >> >> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c >> index 434f54a..676de65 100644 >> --- a/sys/kern/kern_descrip.c >> +++ b/sys/kern/kern_descrip.c >> @@ -718,14 +718,15 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) >> do { >> new = old = fp->f_flag; >> new |= FRDAHEAD; >> - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == 0); >> + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); >> readahead_vnlock_fail: >> VFS_UNLOCK_GIANT(vfslocked); >> + vfslocked = 0; >> } else { >> do { >> new = old = fp->f_flag; >> new &= ~FRDAHEAD; >> - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == 0); >> + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); >> } >> fdrop(fp, td); >> break; > > I have been getting panics with VLC on UFS filesytem too, Although the > frequency of panics on a UFS filesystem is pretty low as compared to > msdosfs and ntfs systems and they are very abrupt. I will try getting a > trace. I am observing panics also with newest vlc port on ufs2. System panics whenever playing .flv files. From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 16:49:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88E61106566B for ; Fri, 20 Nov 2009 16:49:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 42A028FC18 for ; Fri, 20 Nov 2009 16:49:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CF5F446B46; Fri, 20 Nov 2009 11:49:15 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9BDA18A01B; Fri, 20 Nov 2009 11:49:14 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 20 Nov 2009 11:04:05 -0500 User-Agent: KMail/1.9.7 References: <20090928185634.GI4858@sysmon.tcworks.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911201104.05669.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 20 Nov 2009 11:49:14 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Mark Atkinson Subject: Re: cvsup17.freebsd.org having issues with RELENG_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2009 16:49:16 -0000 On Monday 28 September 2009 4:19:43 pm Mark Atkinson wrote: > Scott Lambert wrote: > > I've been using SUPHOST=cvsup17.freebsd.org on my P3 RELENG_8 box. > > Yes, I noticed that about a month ago when my buildworld started > failing. cvsup17 is (seemingly) sponsored by the weather channel > (weather.com). Wasn't sure to send a heads up too. The best place to e-mail for this sort of thing is hubs@FreeBSD.org. I believe cvsup17 should be good to go now. > > World built successfully, in 6 hours. "make buildkernel" kept blowing up > > in the if_re driver, 28 minutes in. When I commented out all references > > to "RL_HWREV_8168DP" it broke later in the build. I blew away /usr/obj > > and /usr/src and tried again, same issues. I did make delete-old > > delete-old-lib, just in case. Blew away /usr/[src|obj]. Same issue. > > > > My other RELENG_8 boxes weren't having this issue, so I was beginning to > > suspect hardware. Finally I tried a different cvsup server and got a > > lot of changes from 2009.08.03. Unfortunately, I didn't use my normal > > scripts so didn't get a log of what all it checked out. > > > > Just a heads-up. > > > > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 21:25:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB30B106568D for ; Fri, 20 Nov 2009 21:25:42 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 322888FC0C for ; Fri, 20 Nov 2009 21:25:41 +0000 (UTC) Received: by bwz5 with SMTP id 5so4040749bwz.3 for ; Fri, 20 Nov 2009 13:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=28oOk0jQ5SN347yhkyMh/RtSE55Qp+v9skcPmIxqCOA=; b=u7uYoGs3ejNuprqd8AJhiTgSY+eNh6kMTX4RhnM0xBIyd0rnT5PsKjRZ1bcPbczqcr 3vgzGuP2n9LWvLhtUNEyLJnVtWwHD81yqN6lwUsmtTP9ZfIgJbl2DWG2tl2k1bsJ/N5h 08HIOn/ZYfruTq7XV5EvGgC+sJepqg03vcMJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WrsgnqY4o5EbMzi264tHLM6FqJzPgAAhLwQILfE6UgyCWsQF07Ifs75WJpCVYIwAOz aCDfMDMFToMYMHsk1JLj7IkYIS82U1IpXALkvgytkQluK/KI7Q6gfj9cjvwmh9KbTKqG l9fPq2GxceHN/LWBgol38vt9k+2DlLn8RDbbQ= MIME-Version: 1.0 Received: by 10.204.3.219 with SMTP id 27mr1870709bko.127.1258750583950; Fri, 20 Nov 2009 12:56:23 -0800 (PST) Date: Fri, 20 Nov 2009 20:56:23 +0000 Message-ID: <3f2022cd0911201256j63d05687na3775e647f89a8fc@mail.gmail.com> From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2009 21:25:42 -0000 Robert Noland wrote: > Ok, try this one... It should address all of the copyin/copyout paths in > radeon. the r300_cmdbuf.c bits worry me a little, but I'm running this > way now.... > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch Well, patched worked well, my system was stable ...until this day. I ran startx, which loaded up Enlightenment. Ran a 3D application (Tremulous) (2 of them actually). Then, I opened up so much xterm windows that Enlightenment didn't respond. I switched to the virtual terminals and CTRL+C'd the startx script/whatever. I ran startx again (Enlightenment, ...). But I noticed that Tremulous was not shut down (with the CTRL+C) and was still running in the background (somehow without a window), eating CPU. I ran "killall tremulous.x86". Panic! #kgdb kernel.debug /var/crash/vmcore.5 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xc369b860) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:791 KDB: stack backtrace: db_trace_self_wrapper(c0c72e66,d679aa1c,c08c0d35,c3f19970,317,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c3f19970,317,ffffffff,c0f02dc4,d679aa54,...) at kdb_backtrace+0x29 _witness_debugger(c0c752de,d679aa68,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0ca9363,c0c68062,c41ead48,...) at witness_warn+0x1fd trap(d679aaf4) at trap+0x173 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc3eb693b, esp = 0xd679ab34, ebp = 0xd679ab90 --- radeon_cp_cmdbuf(c369b800,c38f33b0,c38c9940,317,c0c69ae0,...) at radeon_cp_cmdbuf+0xcb drm_ioctl(c38ccb00,80106450,c38f33b0,3,c396a900,...) at drm_ioctl+0x356 devfs_ioctl_f(c44ba508,80106450,c38f33b0,c419cb00,c396a900,...) at devfs_ioctl_f+0xf8 kern_ioctl(c396a900,5e,80106450,c38f33b0,8ba670,...) at kern_ioctl+0x1fd ioctl(c396a900,d679acf8,c,c0c76875,c0d55288,...) at ioctl+0x134 syscall(d679ad38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x283d755f, esp = 0xbfbfd6ec, ebp = 0xbfbfd708 --- Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x148 fault code = supervisor read, page not present instruction pointer = 0x20:0xc3eb693b stack pointer = 0x28:0xd679ab34 frame pointer = 0x28:0xd679ab90 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 = 1075 (initial thread) trap number = 12 panic: page fault cpuid = 1 Uptime: 3m1s Physical memory: 494 MB Dumping 102 MB: 87 71 55 39 23 7 Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/snd_es137x.ko...Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/snd_es137x.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/snd_es137x.ko Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/sound.ko...Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/sound.ko Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/ntfs.ko...Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/ntfs.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/ntfs.ko Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/linprocfs.ko...Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/linprocfs.ko Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/linux.ko...Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/linux.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/radeon.ko...Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/radeon.ko Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/drm.ko...Reading symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/drm.ko #0 doadump () at pcpu.h:246 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) up #1 0xc087fa1e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 419 doadump(); (kgdb) #2 0xc087fcf2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 575 boot(bootopt); (kgdb) #3 0xc0baeac3 in trap_fatal (frame=0xd679aaf4, eva=328) at /usr/src/sys/i386/i386/trap.c:933 933 panic("%s", trap_msg[type]); (kgdb) #4 0xc0baf3e1 in trap (frame=0xd679aaf4) at /usr/src/sys/i386/i386/trap.c:325 325 trap_fatal(frame, eva); (kgdb) #5 0xc0b918ab in calltrap () at /usr/src/sys/i386/i386/exception.s:165 165 call trap Current language: auto; currently asm (kgdb) #6 0xc3eb693b in radeon_cp_cmdbuf (dev=0xc369b800, data=0xc38f33b0, file_priv=0xc38c9940) at /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_state.c:2879 2879 VB_AGE_TEST_WITH_RETURN(dev_priv); Current language: auto; currently c (kgdb) #7 0xc3f13ad6 in drm_ioctl (kdev=0xc38ccb00, cmd=2148557904, data=0xc38f33b0 "\200\002", flags=3, p=0xc396a900) at /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:793 793 retcode = -func(dev, data, file_priv); (kgdb) #8 0xc08034a8 in devfs_ioctl_f (fp=0xc44ba508, com=2148557904, data=0xc38f33b0, cred=0xc419cb00, td=0xc396a900) at /usr/src/sys/fs/devfs/devfs_vnops.c:659 659 error = dsw->d_ioctl(dev, com, data, fp->f_flag, td); (kgdb) #9 0xc08c43ad in kern_ioctl (td=0xc396a900, fd=94, com=2148557904, data=0xc38f33b0 "\200\002") at file.h:262 262 return ((*fp->f_ops->fo_ioctl)(fp, com, data, active_cred, td)); (kgdb) #10 0xc08c4534 in ioctl (td=0xc396a900, uap=0xd679acf8) at /usr/src/sys/kern/sys_generic.c:678 678 error = kern_ioctl(td, uap->fd, com, data); (kgdb) #11 0xc0baef83 in syscall (frame=0xd679ad38) at /usr/src/sys/i386/i386/trap.c:1073 1073 error = (*callp->sy_call)(td, args); (kgdb) #12 0xc0b91910 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 261 call syscall Current language: auto; currently asm (kgdb) #13 0x00000033 in ?? () (kgdb) Previous frame inner to this frame (corrupt stack?) (kgdb) Initial frame selected; you cannot go up. (kgdb) quit #uname -a FreeBSD 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r196195M: Fri Nov 20 17:17:00 UTC 2009 devhc@:/usr/obj/usr/src/sys/GENERIC i386 From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 21:53:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F01DF106566B for ; Fri, 20 Nov 2009 21:53:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1E68FC14 for ; Fri, 20 Nov 2009 21:53:31 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so830502qwb.7 for ; Fri, 20 Nov 2009 13:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Al4ZP7kxuS+izH0HXwTt+NIMHtVKxFkJsUd6B5O0fSg=; b=XN7hBI3pYsaInk3aAg/BUqNTcEsOOIHYb6DLKo3XhzHqw4+/aka4qtmVyE1G1QMCiJ emwsvxDiUATOYfm+vwcaNthSCuPElAt4wM2JKG3FvbEh1DmXjmQsfr7pGP4OtVzaDURu B5YIq8D9aVyQU49Xoa/IlNTg3IBth6ovz157k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=o1GTmyB9kKxCiDMVnnekmy+pgmDuLZ0BC2SFL6H1YBn2orcgDrDjrkkXxr+40qzYYc ifbW0oquYh8iOo0Nqr2f9AU0N4N3rX3HEc2b35tCqXRf0w9f/7sKdv7fWcEtyNVFnAme SFA30EG+EXbnet4JEVZDkKHxUjBEmyuETft1g= Received: by 10.224.83.136 with SMTP id f8mr1102572qal.86.1258754011054; Fri, 20 Nov 2009 13:53:31 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm5256863qwj.33.2009.11.20.13.53.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 13:53:29 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 20 Nov 2009 13:52:59 -0800 From: Pyun YongHyeon Date: Fri, 20 Nov 2009 13:52:59 -0800 To: Gonzalo Nemmi Message-ID: <20091120215259.GW1262@michelle.cdnetworks.com> References: <200911171917.41906.gnemmi@gmail.com> <20091117232347.GJ1262@michelle.cdnetworks.com> <20091118005724.GK1262@michelle.cdnetworks.com> <19e9a5dc0911172040g1107423ck72d30460b030ca27@mail.gmail.com> <20091118233225.GP1262@michelle.cdnetworks.com> <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> <20091119203720.GT1262@michelle.cdnetworks.com> <19e9a5dc0911191432r749296ebkeb4be431d43e5c5f@mail.gmail.com> <20091119233512.GV1262@michelle.cdnetworks.com> <19e9a5dc0911192004w5788a02ema959fa218b7d345b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19e9a5dc0911192004w5788a02ema959fa218b7d345b@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Fri, 20 Nov 2009 21:53:32 -0000 On Fri, Nov 20, 2009 at 01:04:58AM -0300, Gonzalo Nemmi wrote: > On Thu, Nov 19, 2009 at 8:35 PM, Pyun YongHyeon wrote: > > > On Thu, Nov 19, 2009 at 07:32:27PM -0300, Gonzalo Nemmi wrote: > > > On Thu, Nov 19, 2009 at 5:37 PM, Pyun YongHyeon > > wrote: > > > > > > > On Thu, Nov 19, 2009 at 01:27:03AM -0300, Gonzalo Nemmi wrote: > > > > > On Wed, Nov 18, 2009 at 8:32 PM, Pyun YongHyeon > > > > wrote: > > > > > > > > > > > On Wed, Nov 18, 2009 at 01:40:24AM -0300, Gonzalo Nemmi wrote: > > > > > > > > > > > > [...] > > > > > > > > > > > > > I just tried ... > > > > > > > echo 'hw.bge.allow_asf="1"' >> /boot/loader.conf > > > > > > > reboot > > > > > > > load if_bge > > > > > > > acpiconf -s3 > > > > > > > same results :( > > > > > > > > > > > > > > > > > > > Ok, here is new try. > > > > > > > > > > > > > > > > Let's get on to it then ! > > > > > > > > > > Well now, the situation has improved .. here's what I got: > > > > > http://pastebin.com/f2d152f91 > > > > > > > > > > lines 2 to 8 == kldload if_bge > > > > > line 9 == acpiconf -s3 > > > > > lines 10 to 18 == resume (notice there are only 2 messages now: lines > > 12 > > > > and > > > > > 13!) > > > > > lines 19 to 36 == ifconfig bge0 > > > > > lines 37 to 42 == me mounting the pendrive to get the messages from > > > > > /var/log/messages =P > > > > > lines 43 to 46 == kldunload if_bge0 > > > > > > > > > > I think you narrowed it down quite a lot this time ! > > > > > > > > > > > > > Hmm, not actually. I guess it just removed unnecessary operation > > > > for PHY but it still failed to get functional state. :-( > > > > > > > > > I have to warn you though, that this time, my kernel was compiled > > using a > > > > > ... certainly modified /etc/make.conf file ... just in case you need > > to > > > > know > > > > > how it looks like, you'll fin it in here: > > > > > http://pastebin.com/f42e356d2 > > > > > > > > > > If you think that make.conf config may interfere with your pourposes > > or > > > > > tests, just let me know and I'll use a default one. > > > > > > > > I think that's ok. > > > > > > > > > The good thing about that make.conf is that it saves me quite a time > > on > > > > > every recompile ;) > > > > > > > > > > > im at your service .. tell me what to do and I'll do it :) > > > > > > > > > > > > > > > > > > > Thanks a lot for your patience and continuous support to fixing > > > > > > bugs. > > > > > > > > > > > > > > > > Thank _YOU_ for keeping the good work up and for trying to solve a > > really > > > > > nasty bug that makes every bge(4) user (think of it > > > > > _as_every_dell_notebook_owner_) unable to get his laptop to resume .. > > or > > > > > even use FreeBSD altoghether just because of this. > > > > > > > > > > Dear Pyung, rest assured that as long as you remain commited to fix > > this, > > > > or > > > > > any other bug that I can help you with, you can count on me to do > > > > everything > > > > > that may be within the reach of my hand. As long as you remain > > commited, > > > > > I'll be there, commited just as well :) > > > > > > > > > > > > > Thanks a lot! This really helps me a lot to fix the bug. > > > > Here is 4-th try. I added a couple of debug messages to see what > > > > register contents it have after resume. > > > > > > > > Thanks in advance. > > > > > > > > > > Pyung, I have problems applying your patch. 4 out 13 hunks fail. > > > Take a look in here. > > > http://pastebin.com/f7eab233f > > > > > > I tried to recompile anyways but buildkernel failed at bge ... > > > > > > Can you tell me what to do to apply it cleanly and recompile? > > > > > > > Hmm, I guess it was caused by the difference between HEAD and 8.0. > > I've uploaded complete bge(4) files to the following URL. > > http://people.freebsd.org/~yongari/bge/resume/if_bge.c > > http://people.freebsd.org/~yongari/bge/resume/if_bgereg.h > > > > Save your original bge(4) files in sys/dev/bge directory and > > download above files and then rebuild. > > > > Hope this helps. > > > > Dear Pyung: > > Did as instructed but the result was negative .. so much so that now the > system doesn't even wake up .. upon resume it just shows the usb messages ( > mouse ) and then it freezes .. no more messages ( bge(4) or anything else ), > no coredumps, no nothing .. it just stays there. > The only way to get the system back is to do a hard reset :( > > As usuall, awaiting further instructions :) > Sorry, I didn't expect such a regression. Here is updated one, hope this one wouldn't freeze your box. http://people.freebsd.org/~yongari/bge/resume/if_bge.c http://people.freebsd.org/~yongari/bge/resume/if_bgereg.h > Best Regards > Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 21:55:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50AE01065695 for ; Fri, 20 Nov 2009 21:55:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id EDA758FC19 for ; Fri, 20 Nov 2009 21:55:12 +0000 (UTC) Received: (qmail 7387 invoked by uid 399); 20 Nov 2009 21:55:11 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Nov 2009 21:55:11 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B071044.2030708@FreeBSD.org> Date: Fri, 20 Nov 2009 13:55:16 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Kostik Belousov References: <4B05C709.2090005@dougbarton.us> <20091120110123.GG2331@deviant.kiev.zoral.com.ua> In-Reply-To: <20091120110123.GG2331@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, delphij@freebsd.org, bug-followup@freebsd.org Subject: Re: ports/140648 multimedia/vlc causes a panic if media files are on 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: Fri, 20 Nov 2009 21:55:13 -0000 Kostik Belousov wrote: > On Thu, Nov 19, 2009 at 02:30:33PM -0800, Doug Barton wrote: >> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=140648 for more >> information, including a trace. >> >> There is also some evidence that the same problem is triggered by >> accessing files on an NTFS partition. The VLC folks have suggested >> that the problem may be related to threading. > > This is because msdosfs and ntfs are not mpsafe, and it seems that > VLC using recently added F_RDAHEAD/F_READAHEAD fcntls. > > Please try this. > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 434f54a..676de65 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -718,14 +718,15 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) > do { > new = old = fp->f_flag; > new |= FRDAHEAD; > - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == 0); > + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > readahead_vnlock_fail: > VFS_UNLOCK_GIANT(vfslocked); > + vfslocked = 0; > } else { > do { > new = old = fp->f_flag; > new &= ~FRDAHEAD; > - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == 0); > + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > } > fdrop(fp, td); > break; Voila! Thanks. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 20 23:28:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75B96106568B for ; Fri, 20 Nov 2009 23:28:52 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 447EA8FC13 for ; Fri, 20 Nov 2009 23:28:52 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-218-170.ard.bellsouth.net [72.154.218.170]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAKNSiaS037638 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 18:28:48 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "deeptech71@gmail.com" In-Reply-To: <3f2022cd0911201256j63d05687na3775e647f89a8fc@mail.gmail.com> References: <3f2022cd0911201256j63d05687na3775e647f89a8fc@mail.gmail.com> Content-Type: text/plain Organization: FreeBSD Date: Fri, 20 Nov 2009 17:28:39 -0600 Message-Id: <1258759719.31202.8.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2009 23:28:52 -0000 On Fri, 2009-11-20 at 20:56 +0000, deeptech71@gmail.com wrote: > Robert Noland wrote: > > Ok, try this one... It should address all of the copyin/copyout paths in > > radeon. the r300_cmdbuf.c bits worry me a little, but I'm running this > > way now.... > > > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch > > Well, patched worked well, my system was stable I"m not sure that I even have that patch in my repo now... I need to re-examine all of the copyin/copyout stuff for a more correct fix. Just dropping the lock isn't always appropriate. robert. > ...until this day. I ran startx, which loaded up Enlightenment. Ran a > 3D application (Tremulous) (2 of them actually). Then, I opened up so > much xterm windows that Enlightenment didn't respond. I switched to > the virtual terminals and CTRL+C'd the startx script/whatever. I ran > startx again (Enlightenment, ...). But I noticed that Tremulous was > not shut down (with the CTRL+C) and was still running in the > background (somehow without a window), eating CPU. I ran "killall > tremulous.x86". Panic! > > #kgdb kernel.debug /var/crash/vmcore.5 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex drmdev (drmdev) r = 0 (0xc369b860) locked @ > /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:791 > KDB: stack backtrace: > db_trace_self_wrapper(c0c72e66,d679aa1c,c08c0d35,c3f19970,317,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c3f19970,317,ffffffff,c0f02dc4,d679aa54,...) at kdb_backtrace+0x29 > _witness_debugger(c0c752de,d679aa68,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0ca9363,c0c68062,c41ead48,...) at witness_warn+0x1fd > trap(d679aaf4) at trap+0x173 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc3eb693b, esp = 0xd679ab34, ebp = 0xd679ab90 --- > radeon_cp_cmdbuf(c369b800,c38f33b0,c38c9940,317,c0c69ae0,...) at > radeon_cp_cmdbuf+0xcb > drm_ioctl(c38ccb00,80106450,c38f33b0,3,c396a900,...) at drm_ioctl+0x356 > devfs_ioctl_f(c44ba508,80106450,c38f33b0,c419cb00,c396a900,...) at > devfs_ioctl_f+0xf8 > kern_ioctl(c396a900,5e,80106450,c38f33b0,8ba670,...) at kern_ioctl+0x1fd > ioctl(c396a900,d679acf8,c,c0c76875,c0d55288,...) at ioctl+0x134 > syscall(d679ad38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x283d755f, esp = > 0xbfbfd6ec, ebp = 0xbfbfd708 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x148 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc3eb693b > stack pointer = 0x28:0xd679ab34 > frame pointer = 0x28:0xd679ab90 > 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 = 1075 (initial thread) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 3m1s > Physical memory: 494 MB > Dumping 102 MB: 87 71 55 39 23 7 > > Reading symbols from > /boot/kernel.GENERIC.r196193.copyin2.debug/snd_es137x.ko...Reading > symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/snd_es137x.ko.symbols...done. > done. > Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/snd_es137x.ko > Reading symbols from > /boot/kernel.GENERIC.r196193.copyin2.debug/sound.ko...Reading symbols > from /boot/kernel.GENERIC.r196193.copyin2.debug/sound.ko.symbols...done. > done. > Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/sound.ko > Reading symbols from > /boot/kernel.GENERIC.r196193.copyin2.debug/ntfs.ko...Reading symbols > from /boot/kernel.GENERIC.r196193.copyin2.debug/ntfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/ntfs.ko > Reading symbols from > /boot/kernel.GENERIC.r196193.copyin2.debug/linprocfs.ko...Reading > symbols from /boot/kernel.GENERIC.r196193.copyin2.debug/linprocfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/linprocfs.ko > Reading symbols from > /boot/kernel.GENERIC.r196193.copyin2.debug/linux.ko...Reading symbols > from /boot/kernel.GENERIC.r196193.copyin2.debug/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/linux.ko > Reading symbols from /usr/local/modules/rtc.ko...done. > Loaded symbols for /usr/local/modules/rtc.ko > Reading symbols from > /boot/kernel.GENERIC.r196193.copyin2.debug/radeon.ko...Reading symbols > from /boot/kernel.GENERIC.r196193.copyin2.debug/radeon.ko.symbols...done. > done. > Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/radeon.ko > Reading symbols from > /boot/kernel.GENERIC.r196193.copyin2.debug/drm.ko...Reading symbols > from /boot/kernel.GENERIC.r196193.copyin2.debug/drm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel.GENERIC.r196193.copyin2.debug/drm.ko > #0 doadump () at pcpu.h:246 > 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) up > #1 0xc087fa1e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 > 419 doadump(); > (kgdb) > #2 0xc087fcf2 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > 575 boot(bootopt); > (kgdb) > #3 0xc0baeac3 in trap_fatal (frame=0xd679aaf4, eva=328) > at /usr/src/sys/i386/i386/trap.c:933 > 933 panic("%s", trap_msg[type]); > (kgdb) > #4 0xc0baf3e1 in trap (frame=0xd679aaf4) at /usr/src/sys/i386/i386/trap.c:325 > 325 trap_fatal(frame, eva); > (kgdb) > #5 0xc0b918ab in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > 165 call trap > Current language: auto; currently asm > (kgdb) > #6 0xc3eb693b in radeon_cp_cmdbuf (dev=0xc369b800, data=0xc38f33b0, > file_priv=0xc38c9940) > at /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_state.c:2879 > 2879 VB_AGE_TEST_WITH_RETURN(dev_priv); > Current language: auto; currently c > (kgdb) > #7 0xc3f13ad6 in drm_ioctl (kdev=0xc38ccb00, cmd=2148557904, > data=0xc38f33b0 "\200\002", flags=3, p=0xc396a900) > at /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:793 > 793 retcode = -func(dev, data, file_priv); > (kgdb) > #8 0xc08034a8 in devfs_ioctl_f (fp=0xc44ba508, com=2148557904, > data=0xc38f33b0, cred=0xc419cb00, td=0xc396a900) > at /usr/src/sys/fs/devfs/devfs_vnops.c:659 > 659 error = dsw->d_ioctl(dev, com, data, fp->f_flag, td); > (kgdb) > #9 0xc08c43ad in kern_ioctl (td=0xc396a900, fd=94, com=2148557904, > data=0xc38f33b0 "\200\002") at file.h:262 > 262 return ((*fp->f_ops->fo_ioctl)(fp, com, data, active_cred, td)); > (kgdb) > #10 0xc08c4534 in ioctl (td=0xc396a900, uap=0xd679acf8) > at /usr/src/sys/kern/sys_generic.c:678 > 678 error = kern_ioctl(td, uap->fd, com, data); > (kgdb) > #11 0xc0baef83 in syscall (frame=0xd679ad38) > at /usr/src/sys/i386/i386/trap.c:1073 > 1073 error = (*callp->sy_call)(td, args); > (kgdb) > #12 0xc0b91910 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > 261 call syscall > Current language: auto; currently asm > (kgdb) > #13 0x00000033 in ?? () > (kgdb) > Previous frame inner to this frame (corrupt stack?) > (kgdb) > Initial frame selected; you cannot go up. > (kgdb) quit > > #uname -a > FreeBSD 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r196195M: Fri Nov 20 17:17:00 > UTC 2009 devhc@:/usr/obj/usr/src/sys/GENERIC i386 > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 01:01:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D0B1065676 for ; Sat, 21 Nov 2009 01:01:38 +0000 (UTC) (envelope-from rjy@cmu.edu) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.61]) by mx1.freebsd.org (Postfix) with ESMTP id 036AB8FC12 for ; Sat, 21 Nov 2009 01:01:37 +0000 (UTC) Received: from WHITE (pool-74-111-104-106.pitbpa.fios.verizon.net [74.111.104.106]) (user=rjy mech=LOGIN (0 bits)) by smtp.andrew.cmu.edu (8.14.3/8.14.3) with ESMTP id nAL0Ua7H005507 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 20 Nov 2009 19:30:36 -0500 From: "Russell J. Yount" To: Date: Fri, 20 Nov 2009 19:30:32 -0500 Message-ID: <000001ca6a41$da3a41f0$8eaec5d0$@edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpqQcmTlJIBNGIyQ5eLh9oKiayhdA== Content-Language: en-us x-cr-hashedpuzzle: Av6d DMQ1 EVfM EaW3 EjnB Ev+2 E3BM FH7x FJwf FLRA FM38 Jqwp LP7w L0Gh MAJy MQkv; 1; ZgByAGUAZQBiAHMAZAAtAGMAdQByAHIAZQBuAHQAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {9AB316A3-8388-45DF-8DAA-61FA89B3722A}; cgBqAHkAQABjAG0AdQAuAGUAZAB1AA==; Sat, 21 Nov 2009 00:30:29 GMT; RgByAGUAZQBCAFMARAAgADgALgAwAC0AUgBDADMAIABuAHQAcABkACAAYwBvAHIAZQAgAGQAdQBtAHAAIAB3AGgAZQBuACAAbwBuAGMAbwByAGUAIABjAGwAbwBjAGsAIABpAHMAIABpAG4AIAB1AHMAZQA= x-cr-puzzleid: {9AB316A3-8388-45DF-8DAA-61FA89B3722A} X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.11.21.2122 X-SMTP-Spam-Clean: 8% ( HTML_50_70 0.1, FORGED_MUA_OUTLOOK 0, FROM_EDU_TLD 0, INVALID_MSGID_NO_FQDN 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, TO_NO_NAME 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __MIME_HTML 0, __MIME_VERSION 0, __OUTLOOK_MUA 0, __OUTLOOK_MUA_1 0, __RDNS_POOLED_9 0, __SANE_MSGID 0, __STYLE_RATWARE_2 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __USER_AGENT_MS_GENERIC 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 X-Mailman-Approved-At: Sat, 21 Nov 2009 03:37:10 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 8.0-RC3 ntpd core dump when oncore clock is in use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 01:01:38 -0000 In FreeBSD 8.0-RC3 the ntpd core dumps with stack corruption due to a buffer overflow. The exists in both FreeBSD-8.0-RC3 and ntp-4.2.4p7. I am submitting this to both groups. In ntp/ntpd/relclock_oncore.c: FILE *fd; char *cp, *cc, *ca, line[100], units[2], device[20], Msg[160], **cpp; char *dirs[] = { "/etc/ntp", "/etc", 0 }; int i, sign, lat_flg, long_flg, ht_flg, mode, mask; double f1, f2, f3; fd = NULL; /* just to shutup gcc complaint */ for (cpp=dirs; *cpp; cpp++) { cp = *cpp; sprintf(device, "%s/ntp.oncore.%d", cp, instance->unit); /* try "ntp.oncore.0 */ if ((fd=fopen(device, "r"))) break; sprintf(device, "%s/ntp.oncore%d", cp, instance->unit); /* try "ntp.oncore0" */ if ((fd=fopen(device, "r"))) break; sprintf(device, "%s/ntp.oncore", cp); /* and finally "ntp.oncore" */ if ((fd=fopen(device, "r"))) break; } In the first interation of the for loop the first assigned value of device is "/etc/ntp/ntp.oncore.0" (assuming unit number 0) which including the null charactor takes 22 bytes to represent. The size of device is 20 bytes. The follow patch increases the size of device to 32 charactors which corrects the problem. --- ntp-4.2.4p7/ntpd/refclock_oncore.c.orig 2008-08-22 11:58:00.000000000 -0400 +++ ntp-4.2.4p7/ntpd/refclock_oncore.c 2009-11-20 17:25:26.000000000 -0500 @@ -1127,7 +1127,7 @@ */ FILE *fd; - char *cp, *cc, *ca, line[100], units[2], device[20], Msg[160], **cpp; + char *cp, *cc, *ca, line[100], units[2], device[32], Msg[160], **cpp; char *dirs[] = { "/etc/ntp", "/etc", 0 }; int i, sign, lat_flg, long_flg, ht_flg, mode, mask; double f1, f2, f3; From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 04:33:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF50106566B for ; Sat, 21 Nov 2009 04:33:59 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 1752E8FC1B for ; Sat, 21 Nov 2009 04:33:58 +0000 (UTC) Received: by fxm27 with SMTP id 27so4472858fxm.3 for ; Fri, 20 Nov 2009 20:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mENGcbElQVoWbkDt+Z1zuviNPltZBo/U7AezfB8c6+8=; b=vIg57IzqpSNIU+I0HLWL3XAT7mS7Ek6fg4st1JcTrTnQ2tLXsh9lBBzSFt1h8si7CH TQQf0xyQVPEbI2+aNlMRY08xynw2L5Avbf2hvVF+oLS8QUkHLHYf4JtMalXaDsS21VbZ CxrftH+bKMhq90g1Wb2QFs2P1HMRO4YDnG02o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yb7IlMZUKtE5b0BBLx2/Pl3FzF8AtCOANrtvFDgK8sow0yPjWFd7O9Yeh6TIgUjeOH FSBlWYO+sxa1pYl73MrwoPjH6WT2HRDsd+MzTTd5U6XxafNw9axztAvgCgiJrUqJWj1e YegYJEHHippeobTPOeL4pt3Qsa4W0WVUy4C5s= MIME-Version: 1.0 Received: by 10.103.184.5 with SMTP id l5mr54761mup.34.1258778038083; Fri, 20 Nov 2009 20:33:58 -0800 (PST) In-Reply-To: <20091120215259.GW1262@michelle.cdnetworks.com> References: <200911171917.41906.gnemmi@gmail.com> <20091118005724.GK1262@michelle.cdnetworks.com> <19e9a5dc0911172040g1107423ck72d30460b030ca27@mail.gmail.com> <20091118233225.GP1262@michelle.cdnetworks.com> <19e9a5dc0911182027y3a326763s25d4bc200aa2a8ab@mail.gmail.com> <20091119203720.GT1262@michelle.cdnetworks.com> <19e9a5dc0911191432r749296ebkeb4be431d43e5c5f@mail.gmail.com> <20091119233512.GV1262@michelle.cdnetworks.com> <19e9a5dc0911192004w5788a02ema959fa218b7d345b@mail.gmail.com> <20091120215259.GW1262@michelle.cdnetworks.com> Date: Sat, 21 Nov 2009 01:33:58 -0300 Message-ID: <19e9a5dc0911202033w2fd52bc8r708bc852d345e940@mail.gmail.com> From: Gonzalo Nemmi To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Call for bge(4) 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: Sat, 21 Nov 2009 04:33:59 -0000 On Fri, Nov 20, 2009 at 6:52 PM, Pyun YongHyeon wrote: > On Fri, Nov 20, 2009 at 01:04:58AM -0300, Gonzalo Nemmi wrote: > > On Thu, Nov 19, 2009 at 8:35 PM, Pyun YongHyeon > wrote: > > > > > On Thu, Nov 19, 2009 at 07:32:27PM -0300, Gonzalo Nemmi wrote: > > > > On Thu, Nov 19, 2009 at 5:37 PM, Pyun YongHyeon > > > wrote: > > > > > > > > > On Thu, Nov 19, 2009 at 01:27:03AM -0300, Gonzalo Nemmi wrote: > > > > > > On Wed, Nov 18, 2009 at 8:32 PM, Pyun YongHyeon < > pyunyh@gmail.com> > > > > > wrote: > > > > > > > > > > > > > On Wed, Nov 18, 2009 at 01:40:24AM -0300, Gonzalo Nemmi wrote: > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > I just tried ... > > > > > > > > echo 'hw.bge.allow_asf="1"' >> /boot/loader.conf > > > > > > > > reboot > > > > > > > > load if_bge > > > > > > > > acpiconf -s3 > > > > > > > > same results :( > > > > > > > > > > > > > > > > > > > > > > Ok, here is new try. > > > > > > > > > > > > > > > > > > > Let's get on to it then ! > > > > > > > > > > > > Well now, the situation has improved .. here's what I got: > > > > > > http://pastebin.com/f2d152f91 > > > > > > > > > > > > lines 2 to 8 == kldload if_bge > > > > > > line 9 == acpiconf -s3 > > > > > > lines 10 to 18 == resume (notice there are only 2 messages now: > lines > > > 12 > > > > > and > > > > > > 13!) > > > > > > lines 19 to 36 == ifconfig bge0 > > > > > > lines 37 to 42 == me mounting the pendrive to get the messages > from > > > > > > /var/log/messages =P > > > > > > lines 43 to 46 == kldunload if_bge0 > > > > > > > > > > > > I think you narrowed it down quite a lot this time ! > > > > > > > > > > > > > > > > Hmm, not actually. I guess it just removed unnecessary operation > > > > > for PHY but it still failed to get functional state. :-( > > > > > > > > > > > I have to warn you though, that this time, my kernel was compiled > > > using a > > > > > > ... certainly modified /etc/make.conf file ... just in case you > need > > > to > > > > > know > > > > > > how it looks like, you'll fin it in here: > > > > > > http://pastebin.com/f42e356d2 > > > > > > > > > > > > If you think that make.conf config may interfere with your > pourposes > > > or > > > > > > tests, just let me know and I'll use a default one. > > > > > > > > > > I think that's ok. > > > > > > > > > > > The good thing about that make.conf is that it saves me quite a > time > > > on > > > > > > every recompile ;) > > > > > > > > > > > > > im at your service .. tell me what to do and I'll do it :) > > > > > > > > > > > > > > > > > > > > > > Thanks a lot for your patience and continuous support to fixing > > > > > > > bugs. > > > > > > > > > > > > > > > > > > > Thank _YOU_ for keeping the good work up and for trying to solve > a > > > really > > > > > > nasty bug that makes every bge(4) user (think of it > > > > > > _as_every_dell_notebook_owner_) unable to get his laptop to > resume .. > > > or > > > > > > even use FreeBSD altoghether just because of this. > > > > > > > > > > > > Dear Pyung, rest assured that as long as you remain commited to > fix > > > this, > > > > > or > > > > > > any other bug that I can help you with, you can count on me to do > > > > > everything > > > > > > that may be within the reach of my hand. As long as you remain > > > commited, > > > > > > I'll be there, commited just as well :) > > > > > > > > > > > > > > > > Thanks a lot! This really helps me a lot to fix the bug. > > > > > Here is 4-th try. I added a couple of debug messages to see what > > > > > register contents it have after resume. > > > > > > > > > > Thanks in advance. > > > > > > > > > > > > > Pyung, I have problems applying your patch. 4 out 13 hunks fail. > > > > Take a look in here. > > > > http://pastebin.com/f7eab233f > > > > > > > > I tried to recompile anyways but buildkernel failed at bge ... > > > > > > > > Can you tell me what to do to apply it cleanly and recompile? > > > > > > > > > > Hmm, I guess it was caused by the difference between HEAD and 8.0. > > > I've uploaded complete bge(4) files to the following URL. > > > http://people.freebsd.org/~yongari/bge/resume/if_bge.c > > > > http://people.freebsd.org/~yongari/bge/resume/if_bgereg.h > > > > > > > Save your original bge(4) files in sys/dev/bge directory and > > > download above files and then rebuild. > > > > > > Hope this helps. > > > > > > > Dear Pyung: > > > > Did as instructed but the result was negative .. so much so that now the > > system doesn't even wake up .. upon resume it just shows the usb messages > ( > > mouse ) and then it freezes .. no more messages ( bge(4) or anything else > ), > > no coredumps, no nothing .. it just stays there. > > The only way to get the system back is to do a hard reset :( > > > > As usuall, awaiting further instructions :) > > > > Sorry, I didn't expect such a regression. Here is updated one, hope > this one wouldn't freeze your box. > http://people.freebsd.org/~yongari/bge/resume/if_bge.c > http://people.freebsd.org/~yongari/bge/resume/if_bgereg.h > > Don't worry ! No harm done ! I just recompiled with the files you sent me and here's the output: http://pastebin.com/f414aa4c7 Hope that info is more usefull Awaiting further orders :D Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 12:07:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BAED106566B for ; Sat, 21 Nov 2009 12:07:59 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id D693B8FC12 for ; Sat, 21 Nov 2009 12:07:58 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id nALC7sbL006281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 Nov 2009 23:07:56 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1258805276; bh=l9mG6UYTCJQzhMmrL8pdnXfsLAXXdfe9hdm3eV6rfyc=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=IKvVlK4UIXA7sx4pZl35ET3SbcQbRszR+1+WxWa1PwAzbkGbmFKrNSdTW7k+6M11i nTY2CiHzqBsZkFyvCgLGa8ceU1D8ZqzIefv/KsRWeQSmgQ4hc+9RCjOodHEJUkMVKZ qK+aSLmu61snFam6Dw06pIPWb38iDBYWKNsn9b0U= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id nALC7s43030764 for ; Sat, 21 Nov 2009 23:07:54 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id nALC7sWu030763 for freebsd-current@freebsd.org; Sat, 21 Nov 2009 23:07:54 +1100 (AEDT) (envelope-from john) Date: Sat, 21 Nov 2009 23:07:54 +1100 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20091121120754.GA30495@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: 8.0 can't find/read label on da3 (7.2 OK) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 12:07:59 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This morning I source-upgraded our main server (i386) from 7.2-RELEASE to this morning's RELENG_8_0. FreeBSD 8.0 seems unable to discover the filesystem on /dev/da3. The earlier discs (da0, da1, da2) on that controller are fine. If I boot 7.2-RELEASE from a live CD, bsdlabel happily reads the /da3s1 label, I can fsck the da3s1d UFS filesystem, and I can mount the filesystem. If I boot 8.0, I lose the disc again. -------------------------------- Hardware (from 8.0 dmesg) -------------------------------- ahd2: port 0xc800-0xc8ff,0xc400-0xc4= ff mem 0xfc8fe000-0xfc8fffff irq 24 at device 1.0 on pci4 ahd2: [ITHREAD] da3 at ahd2 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device=20 da3: 40.000MB/s transfers (20.000MHz, offset 63, 16bit) da3: Command Queueing enabled da3: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) -------------------------------- Works - FreeBSD 7.2 -------------------------------- Fixit# uname -a FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 = root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Fixit# ls -l /dev/da3* crw-r----- 1 root operator 0, 113 Nov 21 20:54 /dev/da3 crw-r----- 1 root operator 0, 122 Nov 21 20:54 /dev/da3c crw-r----- 1 root operator 0, 147 Nov 21 20:54 /dev/da3cs1 crw-r----- 1 root operator 0, 167 Nov 21 20:54 /dev/da3cs1c crw-r----- 1 root operator 0, 168 Nov 21 20:54 /dev/da3cs1d crw-r----- 1 root operator 0, 123 Nov 21 20:54 /dev/da3d crw-r----- 1 root operator 0, 121 Nov 21 20:54 /dev/da3s1 crw-r----- 1 root operator 0, 145 Nov 21 20:54 /dev/da3s1c crw-r----- 1 root operator 0, 146 Nov 21 20:54 /dev/da3s1d Fixit# fdisk /dev/da3 ******* Working on device /dev/da3 ******* parameters extracted from in-core disklabel are: cylinders=3D8924 heads=3D255 sectors/track=3D63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3D8924 heads=3D255 sectors/track=3D63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 143363997 (70001 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 731/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Fixit# bsdlabel /dev/da3s1 # /dev/da3s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 143363997 0 unused 0 0 # "raw" part, don'= t edit d: 143363981 16 4.2BSD 2048 16384 28552=20 Fixit# fsck -pt ufs /dev/da3s1d fstab: /etc/fstab:0: No such file or directory fstab: /etc/fstab:0: No such file or directory /dev/da3s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da3s1d: clean, 17904497 free (8193 frags, 2237038 blocks, 0.0% fragmen= tation) -------------------------------- Broken - FreeBSD 8.0 -------------------------------- rwsrv03# uname -a FreeBSD rwsrv03.mby.riverwillow.net.au 8.0-RELEASE FreeBSD 8.0-RELEASE #2: = Sat Nov 21 13:32:10 AEDT 2009 root@rwsrv03.mby.riverwillow.net.au:/buil= d/obj/usr/src/sys/RWSRV03 i386 rwsrv03# ls -l /dev/da3* crw-r----- 1 root operator 0, 110 Nov 21 21:07 /dev/da3 crw-r----- 1 root operator 0, 118 Nov 21 21:07 /dev/da3d rwsrv03# fdisk /dev/da3 ******* Working on device /dev/da3 ******* parameters extracted from in-core disklabel are: cylinders=3D8924 heads=3D255 sectors/track=3D63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3D8924 heads=3D255 sectors/track=3D63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 143363997 (70001 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 731/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: rwsrv03# bsdlabel /dev/da3s1 bsdlabel: unable to get correct path for /dev/da3s1: No such file or direct= ory rwsrv03# bsdlabel /dev/da3 # /dev/da3: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 143374744 0 unused 0 0 # "raw" part, don'= t edit d: 143374728 16 unused 0 0 =20 -------------------------------- --=20 John Marshall --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksH2BoACgkQw/tAaKKahKKlbwCgspfrGv+8x5ibi1mTby4VlDYh Sk8AnR3rr9Aj9NEEhxmsos0zrzMU70NV =+K04 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 09:10:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B4A4106566C; Sat, 21 Nov 2009 09:10:29 +0000 (UTC) (envelope-from ohartman@mail.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 35BDA8FC1F; Sat, 21 Nov 2009 09:10:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NBlzA-0004Jo-3y>; Sat, 21 Nov 2009 10:10:28 +0100 Received: from e178041202.adsl.alicedsl.de ([85.178.41.202] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NBlzA-0003d5-1t>; Sat, 21 Nov 2009 10:10:28 +0100 Message-ID: <4B07AE83.7000409@mail.zedat.fu-berlin.de> Date: Sat, 21 Nov 2009 10:10:27 +0100 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.23 (X11/20091114) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.41.202 X-Mailman-Approved-At: Sat, 21 Nov 2009 12:27:46 +0000 Cc: Subject: ukbd_set_leds_callback:700: error=USB_ERR_STALLED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 09:10:29 -0000 My personal workstation runs FreeBSD 8.0-PRE/amd64 on an oldish hardware (AMD socket 939 platform). Since I replaced my good old but broken IBM Model-M keyboard with a high-quality keyboard 'DASkeyboard', I receive this error message on the console: ukbd_set_leds_callback:700: error=USB_ERR_STALLED What does it means? Greatings, Oliver From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 17:46:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADECE106566B; Sat, 21 Nov 2009 17:46:13 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2738FC15; Sat, 21 Nov 2009 17:46:12 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NBu2C-00005R-VE; Sat, 21 Nov 2009 18:46:09 +0100 Message-ID: <4B08275A.3070209@gwdg.de> Date: Sat, 21 Nov 2009 18:46:02 +0100 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: dougb@dougbarton.us References: <4B05C709.2090005@dougbarton.us> <20091120110123.GG2331@deviant.kiev.zoral.com.ua> <4b069fec.141bf30a.7f54.ffff8735@mx.google.com> <4B06BCC5.1000806@gwdg.de> In-Reply-To: <4B06BCC5.1000806@gwdg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Kostik Belousov , Aditya Sarawgi , freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: multimedia/vlc causes a panic if media files are on 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, 21 Nov 2009 17:46:13 -0000 On 20.11.2009 16:59 (UTC+1), Rainer Hurling wrote: > On 20.11.2009 20:26 (UTC+1), Aditya Sarawgi wrote: >> On Fri, Nov 20, 2009 at 01:01:23PM +0200, Kostik Belousov wrote: >>> On Thu, Nov 19, 2009 at 02:30:33PM -0800, Doug Barton wrote: >>>> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=140648 for more >>>> information, including a trace. >>>> >>>> There is also some evidence that the same problem is triggered by >>>> accessing files on an NTFS partition. The VLC folks have suggested >>>> that the problem may be related to threading. >>> This is because msdosfs and ntfs are not mpsafe, and it seems that >>> VLC using recently added F_RDAHEAD/F_READAHEAD fcntls. >>> >>> Please try this. >>> >>> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c >>> index 434f54a..676de65 100644 >>> --- a/sys/kern/kern_descrip.c >>> +++ b/sys/kern/kern_descrip.c >>> @@ -718,14 +718,15 @@ kern_fcntl(struct thread *td, int fd, int cmd, >>> intptr_t arg) >>> do { >>> new = old = fp->f_flag; >>> new |= FRDAHEAD; >>> - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == >>> 0); >>> + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); >>> readahead_vnlock_fail: >>> VFS_UNLOCK_GIANT(vfslocked); >>> + vfslocked = 0; >>> } else { >>> do { >>> new = old = fp->f_flag; >>> new &= ~FRDAHEAD; >>> - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == >>> 0); >>> + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); >>> } >>> fdrop(fp, td); >>> break; >> >> I have been getting panics with VLC on UFS filesytem too, Although the >> frequency of panics on a UFS filesystem is pretty low as compared to >> msdosfs and ntfs systems and they are very abrupt. I will try getting >> a trace. > > I am observing panics also with newest vlc port on ufs2. System panics > whenever playing .flv files. With this patch even my panics went away :-) Thank you very much, Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 19:14:17 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33E79106566C for ; Sat, 21 Nov 2009 19:14:17 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.freebsd.org (Postfix) with ESMTP id C3B618FC18 for ; Sat, 21 Nov 2009 19:14:16 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id nALJE91u081297; Sat, 21 Nov 2009 20:14:15 +0100 (CET) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 21 Nov 2009 20:14:11 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA5722F@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0 can't find/read label on da3 (7.2 OK) Thread-Index: Acpqo/DK5OqfdlzVQm6MFDXvAqYUvgAOjbfQ References: <20091121120754.GA30495@rwpc12.mby.riverwillow.net.au> From: "Johan Hendriks" To: "John Marshall" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.org Subject: RE: 8.0 can't find/read label on da3 (7.2 OK) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 19:14:17 -0000 >This morning I source-upgraded our main server (i386) from 7.2-RELEASE to this morning's RELENG_8_0. FreeBSD 8.0 >seems unable to discover the filesystem on /dev/da3. The earlier discs (da0, da1, da2) on that controller are fine. >If I boot 7.2-RELEASE from a live CD, bsdlabel happily reads the /da3s1 label, I can fsck the da3s1d UFS filesystem, >and I can mount the filesystem. If I boot 8.0, I lose the disc again. This is probably a dangerous dedicated disk made on 7.x I had this issue also and some member of the list gave me this hint: !!!!!!!!!!!!!!DO MAKE A BACKUP OF YOUR DATA BEFORE DOING THIS FROM YOUR 7.2 INSTALL !!!!!!!!!!!!!!!!!!! Is your disk in "dangerously dedicated" mode? If yes, this is what I did (advised by marcel@) dd if=3D/dev/zero of=3D/dev/ad1 oseek=3D1 bs=3D512 count=3D1 where /dev/ad1 is my device. You should see some messages from GEOM_LABEL removing and assigning new labels. This worked for me, i do not know if it will work for you. Regards, Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 20:09:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2397106566C for ; Sat, 21 Nov 2009 20:09:16 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id B79948FC16 for ; Sat, 21 Nov 2009 20:09:16 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id nALK9FNo063095 for ; Sat, 21 Nov 2009 14:09:15 -0600 (CST) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=fA0IxWRJV5hIOveJ/ok5HFhkPjr/zFXA74hO7P0ocMh7WHIsYjjJkj4l33d5G0dPw Y1ekr+zdE5P4Wmu+uOX9gCVQ+fxWlR45Hnmo3n+Eb28KdImaJRkhcjCqwuM6VlKW4my yFKrINPg4ae/KY7ILRm/XgNZPjHevQbzGPShoSg= Message-ID: <4B0848EB.4070002@jrv.org> Date: Sat, 21 Nov 2009 14:09:15 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: kldstat bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 20:09:17 -0000 amd64, svn 199260, November 13, 2009 Is this behavior of kldstat a bug? Some modules found, some not, and the Id field differs even in success. # kldstat Id Refs Address Size Name 1 19 0xffffffff80100000 f15ee8 kernel 2 1 0xffffffff81016000 194220 zfs.ko 3 2 0xffffffff811ab000 3928 opensolaris.ko 4 1 0xffffffff811af000 24560 geom_mirror.ko 5 1 0xffffffff811d4000 9ac0 siis.ko 6 1 0xffffffff811de000 d0a8 ahci.ko # kldstat -m zfs Id Refs Name 3 1 zfs # kldstat -m opensolaris Id Refs Name 1 1 opensolaris # kldstat -m geom_mirror kldstat: can't find module geom_mirror: No such file or directory # kldstat -m siis kldstat: can't find module siis: No such file or directory # kldstat -m ahci kldstat: can't find module ahci: No such file or directory # From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 22:01:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C75761065693; Sat, 21 Nov 2009 22:01:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id E66858FC14; Sat, 21 Nov 2009 22:01:46 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=txWT70YGK-oA:10 a=RERtC8nhXGhYvIZhK0yWrQ==:17 a=VouFGC_AppAAgmket8gA:9 a=QYgsHDWuPq7tOJ13oX9iZ0ESFXgA:4 Received: from [90.149.203.35] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1330078764; Sat, 21 Nov 2009 23:01:44 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 21 Nov 2009 23:03:19 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4B07AE83.7000409@mail.zedat.fu-berlin.de> In-Reply-To: <4B07AE83.7000409@mail.zedat.fu-berlin.de> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911212303.21028.hselasky@c2i.net> Cc: "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: ukbd_set_leds_callback:700: error=USB_ERR_STALLED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 22:01:47 -0000 On Saturday 21 November 2009 10:10:27 O. Hartmann wrote: > My personal workstation runs FreeBSD 8.0-PRE/amd64 on an oldish hardware > (AMD socket 939 platform). Since I replaced my good old but broken IBM > Model-M keyboard with a high-quality keyboard 'DASkeyboard', I receive > this error message on the console: > > > ukbd_set_leds_callback:700: error=USB_ERR_STALLED > > What does it means? Hi, It means that there was an error updating the LED information on your keyboard. Does the NUM-lock LED work for example? There is a sysctl to disable this feature: sysctl hw.usb.ukbd.no_leds=1 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 22:54:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 429AE106566B; Sat, 21 Nov 2009 22:54:07 +0000 (UTC) (envelope-from jeremy.thornhill@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB2F8FC0C; Sat, 21 Nov 2009 22:54:06 +0000 (UTC) Received: by ewy26 with SMTP id 26so810673ewy.3 for ; Sat, 21 Nov 2009 14:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CEqElpYBJ0MB/NEzOQCkp/r7GbsrtYLywaJx7NPwF9Y=; b=cY4pIbm/kFVWOMIFufEiDTK9kQTXbJmHLkcdfbBYKoOrASKmDi5pPZSvHKaBkvRyIv YFDmhVQuXi2rRwFqdDSSdFjor/PgcfkcmoQ8Fa162OsJyodIzr5PiWbM6EM2d970P4N5 Xl5ySAeQJ5f0JTnqGvTGTrr/lgjDZVgw5uPB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MuPmmDtqOqYrbiwgfRb8DTA+0tA4NoHdjhjvtHq7pzrRDtMmc0/qrU7V5ib8FqrEzv yirWUCM+RBqu3WrCNHgHM/Jo1OOwIDQpK1sMV27C0dtkatyoujF4U2dr1ql26XxGKY4L nXFNjTnKaTjQtzHI34HrWZ4b+skfa56BftUJA= MIME-Version: 1.0 Received: by 10.216.91.80 with SMTP id g58mr924371wef.122.1258844045183; Sat, 21 Nov 2009 14:54:05 -0800 (PST) In-Reply-To: <1258477937.2303.51.camel@balrog.2hip.net> References: <1258477937.2303.51.camel@balrog.2hip.net> Date: Sat, 21 Nov 2009 17:54:05 -0500 Message-ID: From: Jeremy Thornhill To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 22:54:07 -0000 On Tue, Nov 17, 2009 at 12:12 PM, Robert Noland wrote= : > > This should be fixed in -CURRENT. =A0The issue seems to be that solaris > claims that the GPT header is 512 bytes, where we expected it to always > be 92 bytes. =A0The fixes are slated to merge to 7/8 stable within a few > days, however they won't make it into 8.0. > > robert. > In case anybody was curious, this change is apparently in STABLE now, and I'm happy to report that it has resolved my issues. Thanks for the heads up Robert. Jeremy From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 23:24:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDA2C106568B for ; Sat, 21 Nov 2009 23:24:22 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id A4CD88FC15 for ; Sat, 21 Nov 2009 23:24:22 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-218-170.ard.bellsouth.net [72.154.218.170]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nALNOKpv045388 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Nov 2009 18:24:21 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Jeremy Thornhill In-Reply-To: References: <1258477937.2303.51.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Sat, 21 Nov 2009 17:24:14 -0600 Message-Id: <1258845854.2305.0.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2009 23:24:22 -0000 On Sat, 2009-11-21 at 17:54 -0500, Jeremy Thornhill wrote: > On Tue, Nov 17, 2009 at 12:12 PM, Robert Noland wrote: > > > > This should be fixed in -CURRENT. The issue seems to be that solaris > > claims that the GPT header is 512 bytes, where we expected it to always > > be 92 bytes. The fixes are slated to merge to 7/8 stable within a few > > days, however they won't make it into 8.0. > > > > robert. > > > > In case anybody was curious, this change is apparently in STABLE now, > and I'm happy to report that it has resolved my issues. Thanks for the > heads up Robert. Correct, I MFC'd it to 7/8 stable this morning. robert. > Jeremy -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Sat Nov 21 23:44:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC6F7106566C for ; Sat, 21 Nov 2009 23:44:02 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDF98FC08 for ; Sat, 21 Nov 2009 23:44:01 +0000 (UTC) Received: by bwz5 with SMTP id 5so4525643bwz.3 for ; Sat, 21 Nov 2009 15:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PSvVkprGZs4IzREUAC08fOsn0+NrrGzHTIPKAZmBb/k=; b=itU/Bpko6D4jK7AJD0UTMWoyzaw3tJ8ppDJTq3RPweW5ru55YFt856kmqIDgHi1VyB 6fU5mUe7rZ7UkuoziWFhMX94ykzB0KtdP4XwPvjVPEjT2QrFZaRbPqDrUu3jcV85OlMV 7FUNySukjtHH0gjBTzEKWPOpFrKn9IDNUSiGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=squklKSjjZo0OVMOmAvXhsRdMgGe+Ye4gJi+RizQU6Qd1tIyWhwukbF3FEdFLuG4WV r3/oKukE+V5pmfxu8yHEGDqDw7EFAAn37cV+s1u46vEjjxZ7TiO49tkYAGmuBDyXzAy1 Tyh3JG/wfoe2vEv3ZMsh7bI3lhpwDww4sdAO0= MIME-Version: 1.0 Received: by 10.204.48.202 with SMTP id s10mr614947bkf.106.1258847041080; Sat, 21 Nov 2009 15:44:01 -0800 (PST) In-Reply-To: <4B08275A.3070209@gwdg.de> References: <4B05C709.2090005@dougbarton.us> <20091120110123.GG2331@deviant.kiev.zoral.com.ua> <4b069fec.141bf30a.7f54.ffff8735@mx.google.com> <4B06BCC5.1000806@gwdg.de> <4B08275A.3070209@gwdg.de> Date: Sat, 21 Nov 2009 23:44:01 +0000 Message-ID: <6101e8c40911211544y2347b832kda66f3217fb6aa55@mail.gmail.com> From: Oliver Pinter To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , Aditya Sarawgi , freebsd-current@freebsd.org, delphij@freebsd.org, dougb@dougbarton.us Subject: Re: multimedia/vlc causes a panic if media files are on 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, 21 Nov 2009 23:44:02 -0000 can you run memtest? On 11/21/09, Rainer Hurling wrote: > On 20.11.2009 16:59 (UTC+1), Rainer Hurling wrote: >> On 20.11.2009 20:26 (UTC+1), Aditya Sarawgi wrote: >>> On Fri, Nov 20, 2009 at 01:01:23PM +0200, Kostik Belousov wrote: >>>> On Thu, Nov 19, 2009 at 02:30:33PM -0800, Doug Barton wrote: >>>>> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=140648 for more >>>>> information, including a trace. >>>>> >>>>> There is also some evidence that the same problem is triggered by >>>>> accessing files on an NTFS partition. The VLC folks have suggested >>>>> that the problem may be related to threading. >>>> This is because msdosfs and ntfs are not mpsafe, and it seems that >>>> VLC using recently added F_RDAHEAD/F_READAHEAD fcntls. >>>> >>>> Please try this. >>>> >>>> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c >>>> index 434f54a..676de65 100644 >>>> --- a/sys/kern/kern_descrip.c >>>> +++ b/sys/kern/kern_descrip.c >>>> @@ -718,14 +718,15 @@ kern_fcntl(struct thread *td, int fd, int cmd, >>>> intptr_t arg) >>>> do { >>>> new = old = fp->f_flag; >>>> new |= FRDAHEAD; >>>> - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == >>>> 0); >>>> + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); >>>> readahead_vnlock_fail: >>>> VFS_UNLOCK_GIANT(vfslocked); >>>> + vfslocked = 0; >>>> } else { >>>> do { >>>> new = old = fp->f_flag; >>>> new &= ~FRDAHEAD; >>>> - } while (atomic_cmpset_rel_int(&fp->f_flag, old, new) == >>>> 0); >>>> + } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); >>>> } >>>> fdrop(fp, td); >>>> break; >>> >>> I have been getting panics with VLC on UFS filesytem too, Although the >>> frequency of panics on a UFS filesystem is pretty low as compared to >>> msdosfs and ntfs systems and they are very abrupt. I will try getting >>> a trace. >> >> I am observing panics also with newest vlc port on ufs2. System panics >> whenever playing .flv files. > > With this patch even my panics went away :-) > > Thank you very much, > Rainer Hurling > > _______________________________________________ > 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" >