From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 02:30:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7824D106567A for ; Sun, 16 Nov 2008 02:30:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 5B60D8FC14 for ; Sun, 16 Nov 2008 02:30:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id fbGG1a0050EPchoA9eWDum; Sun, 16 Nov 2008 02:30:13 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id feWB1a0062P6wsM8MeWBle; Sun, 16 Nov 2008 02:30:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=wl0p_1-BwWc6M2sYu8EA:9 a=aUYLzuyEa1ttQIieQEPkER67deoA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 0E35533C36; Sat, 15 Nov 2008 18:30:11 -0800 (PST) Date: Sat, 15 Nov 2008 18:30:11 -0800 From: Jeremy Chadwick To: jT Message-ID: <20081116023011.GA89222@icarus.home.lan> References: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 02:30:13 -0000 On Sat, Nov 15, 2008 at 06:50:39PM -0500, jT wrote: > All, > Any ideas on this one? I've just recently gotten this message and > cannot do anything about it. Thanks. > > [root@bigmac ~]# csup current-supfile > Connected to 128.31.0.28 > Invalid server reply to AUTHMD5 > [root@bigmac ~]# Can you edit your supfile and change the server name, then try again? Could be a problem specific to 128.31.0.28... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 10:29:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7F4D1065690 for ; Sun, 16 Nov 2008 10:29:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6428FC16 for ; Sun, 16 Nov 2008 10:29:31 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=AZAC4kOax5IA:10 a=aniA1o7mVp4QawOfT9qHqA==:17 a=z_zqISx-AAAA:8 a=OCGuPPFrAAAA:8 a=ZToy3AVIqFmcvRP53D4A:9 a=rzG8f9PSZPhoM13RZ2IA:7 a=QEqUCcFo-74BLWp2hdAOwc6hlv8A:4 a=LY0hPdMaydYA:10 Received: from [62.113.133.1] (account mc467741@c2i.net [62.113.133.1] verified) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1153312314; Sun, 16 Nov 2008 11:29:30 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 16 Nov 2008 11:31:38 +0100 User-Agent: KMail/1.9.7 References: <200811141541.49595.shoesoft@gmx.net> <200811151004.06521.shoesoft@gmx.net> <200811151022.56606.hselasky@c2i.net> In-Reply-To: <200811151022.56606.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811161131.39014.hselasky@c2i.net> Cc: Stefan Ehmann Subject: Re: usb2: no sound with M-Audio Transit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 10:29:32 -0000 On Saturday 15 November 2008, Hans Petter Selasky wrote: > On Saturday 15 November 2008, Stefan Ehmann wrote: > > On Friday 14 November 2008 18:11:23 Hans Petter Selasky wrote: > > > On Friday 14 November 2008, Stefan Ehmann wrote: > > > > http://stud4.tuwien.ac.at/~e0125637/fbsd/transit_config.dump > > > > > > Maybe there is something wrong with the 16-bit to 24-bit data > > > conversion ? > > > > One more thing: > > > > I'm using dfu-util for the firmware download. See > > http://svn.openmoko.org/trunk/src/host/dfu-util/ > > > > The second usb_claim_interface() call fails. But that doesn't seem to > > be fatal. If I comment out the exit() the download succeeds. > > > > Here's the output: > > dfu-util - (C) 2007-2008 by OpenMoko Inc. > > This program is Free Software and has ABSOLUTELY NO WARRANTY > > > > Opening USB Device 0x0000:0x0000... > > Claiming USB DFU Runtime Interface... > > Determining device status: state = dfuIDLE, status = 0 > > WARNING: Runtime device already in DFU state ?!? > > Found Runtime: [0x0763:0x2806] devnum=0, cfg=0, intf=0, alt=0, name="RAM" > > Claiming USB DFU Interface... > > Cannot claim interface: Unknown error > > Setting Alternate Setting ... > > Determining device status: state = dfuIDLE, status = 0 > > dfuIDLE, continuing > > Transfer Size = 0x0040 > > bytes_per_hash=112 > > Starting download: [##################################################] > > finished! > > state(7) = dfuMANIFEST, status(0) = No error condition is present > > state(2) = dfuIDLE, status(0) = No error condition is present > > Done! > > can't detach: Unknown error > > Resetting USB to switch back to runtime mode > > error resetting after download: Unknown error > > > > > > The problem is that after the download the device needs to be reset so > > it gets recognized as uaudio device. This was not implemented in the > > libusb from sourceforge for BSD. > > > > As a workaround you can slightly unplug the cable (I think I read this on > > some netbsd list) which works but is not very convenient. > > > > The reset in dfu-util fails, possibly due to preceding errors. > > > > I also tried it with usbconfig: > > # usbconfig -u 0 -a 2 reset > > usbconfig: could not reset device: Device not configured > > > > And this error in dmesg > > usb2_req_re_enumerate:1362: addr=2, getting device descriptor failed! > > > > This is not critical but it would be nice to get rid of this ugly > > workaround. > > Hi, > > The problem is that the device changes its configuration descriptor and the > reset implementation assumes that the configuration descriptor is the same > after the reset. I will see if I can make a patch for this. I have the same > problem when flashing the openmoko. > > I will make a patch for this by tomorrow. Hi, Could you try to checkout the latest sources from my private SVN, recompile libusb20, usbconfig, USB2 modules and give all your USB devices a try? svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b The problem about 24-bit audio is not solved yet, but I hope that the device reset should work. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 12:44:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BB5E1065689 for ; Sun, 16 Nov 2008 12:44:22 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id 034CA8FC1F for ; Sun, 16 Nov 2008 12:44:21 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: by ti-out-0910.google.com with SMTP id i7so2409279tid.9 for ; Sun, 16 Nov 2008 04:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:to:references:subject :message-id:organization:x-mailer:mime-version:content-type :content-transfer-encoding:from; bh=uFRoo0exQUhur7O5LuUVLQ08wNCxt9iH7cG+sJTaTCI=; b=nEB8Q35oX93xcighKUUgPqUegKVZU3mJqlQiwH1M7S6z5VN2apcn3bD6lip1xGsi3o j7ddW79wAKQstR9+bjxcb2ddHRYKOZ0QL7X3YLfKuKGaQDNBL26CPn13b+cUyqNAe1Fk MkjPUWzrHYpIltEbCZAnZaFvub4XZU0bUPxOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:references:subject:message-id:organization:x-mailer :mime-version:content-type:content-transfer-encoding:from; b=JYsSYI+yP8mInfZns8DcoCnLGHMgfRgzXYLy+GfOsMiM+ACIKMwJTNXdQ20HX3KiwZ 1+vZCbYCULtmGOGZhC6XFSfo7HnvbPZ+Ov77qpk0+6ElL6EZb6D8tpcwHFQPsHS0bVgU 0C5le0JkqeTQboZZYeLz53FbS9YotNYzZlsoM= Received: by 10.110.42.17 with SMTP id p17mr3717023tip.40.1226838174552; Sun, 16 Nov 2008 04:22:54 -0800 (PST) Received: from bear ([222.187.9.204]) by mx.google.com with ESMTPS id u8sm8503905tia.8.2008.11.16.04.22.52 (version=SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 04:22:53 -0800 (PST) Date: Sun, 16 Nov 2008 20:22:47 +0800 To: "freebsd-current" References: <200811161552458757708@Gmail.com> Message-ID: <200811162022455463973@Gmail.com> Organization: Freebear Develop Group X-mailer: Foxmail 6, 13, 102, 15 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit From: Bear Cc: Subject: My GNOME2 cannot 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: Sun, 16 Nov 2008 12:44:22 -0000 hi, I just tried to reinstall my freebsd. then I installed these packages: xorg gnome2-lite and when I type in startx,it still give me a ERROR!!!! It tell me this: Could not lock the file "/var/tmp/gconf-test-locking-file-CB9IKU" The error was "Invalid argument"(errno = 22) the console says: gconf-sanity-check-2 did not pass,logging back out then I add gnome_enable="YES" to /etc/rc.conf and reboot. While I am booting,it tell me these: Starting avahi-daemon avahi-daemon[609]:Failed to create PID file:Invalid Argument Starting avahi-dnsconfd avahi-daemon[1021]:Failed to create PID file:Invalid Argument What shall I do??? -------------- Bear 2008-11-16 From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 12:49:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DCD11065674 for ; Sun, 16 Nov 2008 12:49:25 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by mx1.freebsd.org (Postfix) with ESMTP id 7EB3B8FC26 for ; Sun, 16 Nov 2008 12:49:25 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: by ti-out-0910.google.com with SMTP id i7so2410930tid.9 for ; Sun, 16 Nov 2008 04:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:to:references:subject :message-id:organization:x-mailer:mime-version:content-type :content-transfer-encoding:from; bh=liCyGTGFW+r4z0q1jw4WX/BGRxZVJhaB9u1fJawzxwo=; b=lRbCP5gqIgRWCjIQJzuOiXojqL0KHqFXjuhCkHFfKdT5d0tT7J4doZkv/nyN0Mq7dk NCuEWQ3uaCwSGCTcYg+3qF/mtfxVnWTJUU2wxqoS1uhDgo6Yy76r2xQcEk0kFWDgf1NM va7+rAvAJ1iklYJPU+P9oKd8rQfO/B6qX5IDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:references:subject:message-id:organization:x-mailer :mime-version:content-type:content-transfer-encoding:from; b=a3xeuHcWXZjgAxa/+fhw3VLbmR7gGciCLuLWAnBEfBh+yfOXaHzGazyyDnI9FWBZfS yDbIqZaFDrt4hldl5Qmo7527dFo5IQ0kz5pIOY0++35niy6+xb5CL11RljyhkLP3cxsD YttVSAEvd4QoKJab6eaAR+2UQ8PfA0z7chMow= Received: by 10.110.41.20 with SMTP id o20mr3760697tio.0.1226838150262; Sun, 16 Nov 2008 04:22:30 -0800 (PST) Received: from bear ([222.187.9.204]) by mx.google.com with ESMTPS id w12sm8443703tib.10.2008.11.16.04.22.28 (version=SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 04:22:29 -0800 (PST) Date: Sun, 16 Nov 2008 20:22:22 +0800 To: "freebsd-current" References: <200811161150196091110@Gmail.com> Message-ID: <200811162022198288506@Gmail.com> Organization: Freebear Develop Group X-mailer: Foxmail 6, 13, 102, 15 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit From: Bear Cc: Subject: My GNOME2 cannot 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: Sun, 16 Nov 2008 12:49:26 -0000 hi, I have use these commands to install GNOME to my new-installed FreeBSD 7.0: pkg_add -r xorg pkg_add -r gnome-session pkg_add -r gnome2-lite and then,I reboot my computer and use user Bear to login. then I type in echo "/usr/local/bin/gnome-session" > ~/.xinitrc then I type in startx but it give me a error the summary of the error is below: Could not lock the file "/var/tmp/gconf-test-locking-file-CB9IKU" The error was "Invalid argument"(errno = 22) What Can I Do??thx! BTW:I have been set my PACKAGEROOT to ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-current/Lat est/ -------------- Bear 2008-11-16 From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 12:54:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C27F71065678 for ; Sun, 16 Nov 2008 12:54:04 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 2AF1B8FC13 for ; Sun, 16 Nov 2008 12:54:03 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 16 Nov 2008 12:54:01 -0000 Received: from 85-127-251-132.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.251.132] by mail.gmx.net (mp006) with SMTP; 16 Nov 2008 13:54:01 +0100 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX18JaZ8SnCsJGTZRQmxZCMU3psieqt5LBKiJO4afAa mUOL16vGIbmuJz From: Stefan Ehmann To: Hans Petter Selasky Date: Sun, 16 Nov 2008 13:53:59 +0100 User-Agent: KMail/1.10.3 (FreeBSD/7.1-PRERELEASE; KDE/4.1.3; i386; ; ) References: <200811141541.49595.shoesoft@gmx.net> <200811151022.56606.hselasky@c2i.net> <200811161131.39014.hselasky@c2i.net> In-Reply-To: <200811161131.39014.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811161354.00767.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: freebsd-current@freebsd.org Subject: Re: usb2: no sound with M-Audio Transit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 12:54:04 -0000 On Sunday 16 November 2008 11:31:38 Hans Petter Selasky wrote: > On Saturday 15 November 2008, Hans Petter Selasky wrote: > > On Saturday 15 November 2008, Stefan Ehmann wrote: > > > On Friday 14 November 2008 18:11:23 Hans Petter Selasky wrote: > > > > On Friday 14 November 2008, Stefan Ehmann wrote: > > > > > http://stud4.tuwien.ac.at/~e0125637/fbsd/transit_config.dump > > > > > > > > Maybe there is something wrong with the 16-bit to 24-bit data > > > > conversion ? > > > > > > One more thing: > > > > > > I'm using dfu-util for the firmware download. See > > > http://svn.openmoko.org/trunk/src/host/dfu-util/ > > > > > > The second usb_claim_interface() call fails. But that doesn't seem to > > > be fatal. If I comment out the exit() the download succeeds. > > > > > > Here's the output: > > > dfu-util - (C) 2007-2008 by OpenMoko Inc. > > > This program is Free Software and has ABSOLUTELY NO WARRANTY > > > > > > Opening USB Device 0x0000:0x0000... > > > Claiming USB DFU Runtime Interface... > > > Determining device status: state = dfuIDLE, status = 0 > > > WARNING: Runtime device already in DFU state ?!? > > > Found Runtime: [0x0763:0x2806] devnum=0, cfg=0, intf=0, alt=0, > > > name="RAM" Claiming USB DFU Interface... > > > Cannot claim interface: Unknown error > > > Setting Alternate Setting ... > > > Determining device status: state = dfuIDLE, status = 0 > > > dfuIDLE, continuing > > > Transfer Size = 0x0040 > > > bytes_per_hash=112 > > > Starting download: [##################################################] > > > finished! > > > state(7) = dfuMANIFEST, status(0) = No error condition is present > > > state(2) = dfuIDLE, status(0) = No error condition is present > > > Done! > > > can't detach: Unknown error > > > Resetting USB to switch back to runtime mode > > > error resetting after download: Unknown error > > > > > > > > > The problem is that after the download the device needs to be reset so > > > it gets recognized as uaudio device. This was not implemented in the > > > libusb from sourceforge for BSD. > > > > > > As a workaround you can slightly unplug the cable (I think I read this > > > on some netbsd list) which works but is not very convenient. > > > > > > The reset in dfu-util fails, possibly due to preceding errors. > > > > > > I also tried it with usbconfig: > > > # usbconfig -u 0 -a 2 reset > > > usbconfig: could not reset device: Device not configured > > > > > > And this error in dmesg > > > usb2_req_re_enumerate:1362: addr=2, getting device descriptor failed! > > > > > > This is not critical but it would be nice to get rid of this ugly > > > workaround. > > > > Hi, > > > > The problem is that the device changes its configuration descriptor and > > the reset implementation assumes that the configuration descriptor is the > > same after the reset. I will see if I can make a patch for this. I have > > the same problem when flashing the openmoko. > > > > I will make a patch for this by tomorrow. > > Hi, > > Could you try to checkout the latest sources from my private SVN, recompile > libusb20, usbconfig, USB2 modules and give all your USB devices a try? > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b > > The problem about 24-bit audio is not solved yet, but I hope that the > device reset should work. Yes, the usbconfig reset is working now. No longer need to fiddle about with the cable, thanks! From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 13:06:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5430106564A; Sun, 16 Nov 2008 13:06:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 239708FC17; Sun, 16 Nov 2008 13:06:11 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=OxQIQV-UnBUA:10 a=OldrGD9YyLYA:10 a=aniA1o7mVp4QawOfT9qHqA==:17 a=qSPV2YstbUVUn8ktqM8A:9 a=pk5SlkhxH9hEDXMoxyqZ3BP3mlcA:4 a=50e4U0PicR4A:10 Received: from [62.113.133.1] (account mc467741@c2i.net [62.113.133.1] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1151017828; Sun, 16 Nov 2008 14:06:09 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sun, 16 Nov 2008 14:08:20 +0100 User-Agent: KMail/1.9.7 References: <20081107082740.GA1334@icarus.home.lan> <20081108001128.GA1437@icarus.home.lan> <200811081023.10058.hselasky@freebsd.org> In-Reply-To: <200811081023.10058.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811161408.21562.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 13:06:12 -0000 Hi, It turns out my initial patch need to be limited to the use-case only. Before I start any real work, I want to know if anyone will object if I implement the following new BUS_DMA flag into FreeBSD's busdma system? amd64/amd64/busdma_machdep.c i386/i386/busdma_machdep.c arm/arm/busdma_machdep.c ia64/ia64/busdma_machdep.c mips/mips/busdma_machdep.c powerpc/powerpc/busdma_machdep.c sparc64/sparc64/bus_machdep.c sun4v/sun4v/bus_machdep.c sys/bus_dma.h /* * The following flag specifies that no re-alignment of individual * memory pages is allowed when loaded into DMA. It can only be used * when "maxsegsz" is equal to "PAGE_SIZE" and "alignment" is less * than or equal to 1. * * Background: Some kinds of DMA hardware only stores the full * physical address of the first memory page when multiple memory * pages are loaded into DMA. Consequtive memory pages only gets the * non-offset part of the physical address updated. The hardware * computes the amount of data that should be stored in the first * memory page from the minimum of the total transfer length and * PAGE_SIZE minus the initial page offset. When the initial page * offset is not preserved the hardware ends up transferring an * invalid number of bytes to or from the initial memory page. */ #define BUS_DMA_NOREAL 0x400 /* no page re-alignment allowed */ Without this new feature in busdma the USB hardware will not work when the DMA data is placed on bounce pages, for example on 64-bit architectures with more than 4GB of RAM. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 14:56:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E23B0106568B for ; Sun, 16 Nov 2008 14:56:37 +0000 (UTC) (envelope-from galbrig@googlemail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by mx1.freebsd.org (Postfix) with ESMTP id 8B42E8FC13 for ; Sun, 16 Nov 2008 14:56:37 +0000 (UTC) (envelope-from galbrig@googlemail.com) Received: by qb-out-0506.google.com with SMTP id f30so1918351qba.35 for ; Sun, 16 Nov 2008 06:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=mkIVkIdkNKQqyzLEMRTZi40u4cuWF47YsvmjBLMjLgw=; b=C0AEADzxZ0tkgROztKRiSFpv9RMslPGMlGwMjZOKZ2xKd1kZN/pHU9skrkeFaZ4hNB BqnRhNfgHSu7kwFurlWe/MzZYwoUH88dEdohDgK8nloHjGbyNNJceomuiH6oRPIxMRJg wU5sL8RsKnXweODXIkbBFW3BePM9ZGifj2mKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ODqSYIf/FcsTlN/JYJMvSOTFF7VC8lzrC/A24TWnGsCnt+LxQgE5mUDdjiXPBxptaJ nsGj/mIsgwmCxKDbXRszjAPHvMeeQED7GSCJLVa29IL/pq4h/tos8JlQhbGvfiJgcpEz WgD375f9srzoQQlhuI7CJAN25/IAgPmkh/Vco= Received: by 10.181.48.4 with SMTP id a4mr761860bkk.59.1226846536580; Sun, 16 Nov 2008 06:42:16 -0800 (PST) Received: by 10.181.145.2 with HTTP; Sun, 16 Nov 2008 06:42:16 -0800 (PST) Message-ID: <46d45f030811160642m2dff1481g457f1fa1a4ac1372@mail.gmail.com> Date: Sun, 16 Nov 2008 15:42:16 +0100 From: albri To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14858_16538104.1226846536568" Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 14:56:38 -0000 ------=_Part_14858_16538104.1226846536568 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hello, I have issues transfering big or many files over ethernet on 1000H, also. Using yongari's ale(4) driver http://people.freebsd.org/~yongari/ale/ale.20081114.tar.gz I did not have any problems while I surf or download 37MB sourcecode from inet. Then scp(1)'ing source from 1000H to desktop PC showed a transfer rate with maximum 86kB/s regardless to which direction is copied. The ethernet NIC, while copying, is switched off regularily then. No copies possible after three megabytes. Next try was a big file. A packed tarball from the source-tree was copied via nc(1) using TCP-protocol. After 7 until 17MB no transfer possible and same symptoms like above. One way I can reproduce this is the following: on desktop PC: $> nc -4nl 1234 > bigfile.tar.gz on 1000H: $> nc -4n 192.x.x.x 1234 < bigfile.tar.gz It makes no difference wether I am a user or root. Tested over a switch and a crossover cable. Does anybody has a hint? best regards. - attachments: As this is my first post, I try to attach my kernelconfig and two sysctl dev.ale.0 (before and after error). - dmesg shows: 1 ale0: port 0xec00-0xec7f mem 0x fbfc0000-0xfbffffff irq 17 at device 0.0 on pci3 2 ale0: 960 Tx FIFO, 1024 Rx FIFO 3 ale0: Using 1 MSI messages. 4 miibus0: on ale0 5 ale0: Ethernet address: 00:23:54:xx:xx:xx 6 ale0: [FILTER] 7 ale0: flags=8843 metric 0 mtu 1500 8 ale0: link state changed to UP 9 ale0: DMA read error! -- resetting 10 ale0: could not disable Tx/Rx MAC(0x00000008)! 11 ale0: link state changed to DOWN 12 ale0: link state changed to UP 13 ale0: link state changed to DOWN 14 ale0: link state changed to UP 15 [..] 20 times 16 ale0: DMA read error! -- resetting 17 ale0: could not disable Tx/Rx MAC(0x00000008)! 18 ale0: link state changed to DOWN 19 ale0: link state changed to UP - ifconfig shows: 1 ale0: flags=8843 metric 0 mtu 1500 2 options=319b 3 ether 00:23:54:xx:xx:xx 4 inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.255 5 media: Ethernet autoselect (100baseTX ) 6 status: active - uname -a shows: FreeBSD netbook.net.local 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sun Nov 16 13:19:19 CET 2008 maya@netbook.net.local:/usr/obj/usr/src/sys/NETBOOK i386 - kernel was compiled with: make buildkernel KERNCONF=NETBOOK MODULES_OVERRIDE="ath" ------=_Part_14858_16538104.1226846536568 Content-Type: application/octet-stream; name=NETBOOK Content-Transfer-Encoding: base64 X-Attachment-Id: file0 Content-Disposition: attachment; filename=NETBOOK IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJl YWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoK IwojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9o YW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwKIwojIFRoZSBoYW5kYm9vayBpcyBhbHNv IGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rCiMgaWYgeW91J3Zl IGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5cyBzZWUgdGhl CiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBzZXJ2ZXIgKGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcv KSBmb3IgdGhlCiMgbGF0ZXN0IGluZm9ybWF0aW9uLgojCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9m IG9wdGlvbnMgYW5kIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZQojIGRldmljZSBs aW5lcyBpcyBhbHNvIHByZXNlbnQgaW4gdGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZp bGVzLgojIElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5 IG9mIGEgbGluZSwgY2hlY2sgZmlyc3QKIyBpbiBOT1RFUy4KIwojICRGcmVlQlNEOiBzcmMvc3lz L2kzODYvY29uZi9HRU5FUklDLHYgMS40NzQuMi4yLjIuMSAyMDA4LzAyLzA2IDAzOjI0OjI4IHNj b3R0bCBFeHAgJAoKY3B1CQlJNDg2X0NQVQpjcHUJCUk1ODZfQ1BVCmNwdQkJSTY4Nl9DUFUKaWRl bnQJCU5FVEJPT0sKCiMgVG8gc3RhdGljYWxseSBjb21waWxlIGluIGRldmljZSB3aXJpbmcgaW5z dGVhZCBvZiAvYm9vdC9kZXZpY2UuaGludHMKI2hpbnRzCQkiR0VORVJJQy5oaW50cyIJCSMgRGVm YXVsdCBwbGFjZXMgdG8gbG9vayBmb3IgZGV2aWNlcy4KCm1ha2VvcHRpb25zCURFQlVHPS1nCQkj IEJ1aWxkIGtlcm5lbCB3aXRoIGdkYigxKSBkZWJ1ZyBzeW1ib2xzCgojb3B0aW9ucyAJU0NIRURf NEJTRAkJIyA0QlNEIHNjaGVkdWxlcgpvcHRpb25zIAlTQ0hFRF9VTEUJCSMgVUxFIHNjaGVkdWxl cgpvcHRpb25zIAlQUkVFTVBUSU9OCQkjIEVuYWJsZSBrZXJuZWwgdGhyZWFkIHByZWVtcHRpb24K b3B0aW9ucyAJSU5FVAkJCSMgSW50ZXJORVR3b3JraW5nCm9wdGlvbnMgCUlORVQ2CQkJIyBJUHY2 IGNvbW11bmljYXRpb25zIHByb3RvY29scwpvcHRpb25zIAlTQ1RQCQkJIyBTdHJlYW0gQ29udHJv bCBUcmFuc21pc3Npb24gUHJvdG9jb2wKb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBGYXN0IEZp bGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQREFURVMJCSMgRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMg c3VwcG9ydApvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBwb3J0IGZvciBhY2Nlc3MgY29udHJvbCBs aXN0cwpvcHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBk aXJlY3RvcmllcwpvcHRpb25zIAlVRlNfR0pPVVJOQUwJCSMgRW5hYmxlIGdqb3VybmFsLWJhc2Vk IFVGUyBqb3VybmFsaW5nCm9wdGlvbnMgCU1EX1JPT1QJCQkjIE1EIGlzIGEgcG90ZW50aWFsIHJv b3QgZGV2aWNlCm9wdGlvbnMgCU5GU0NMSUVOVAkJIyBOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xpZW50 Cm9wdGlvbnMgCU5GU1NFUlZFUgkJIyBOZXR3b3JrIEZpbGVzeXN0ZW0gU2VydmVyCm9wdGlvbnMg CU5GU19ST09UCQkjIE5GUyB1c2FibGUgYXMgLywgcmVxdWlyZXMgTkZTQ0xJRU5UCm9wdGlvbnMg CU1TRE9TRlMJCQkjIE1TRE9TIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJTlRGUwkJCSMgTlQgRmlsZXN5 c3RlbQpvcHRpb25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJP Q0ZTCQkJIyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zIAlQ U0VVRE9GUwkJIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VPTV9QQVJU X0dQVAkJIyBHVUlEIFBhcnRpdGlvbiBUYWJsZXMuCm9wdGlvbnMgCUdFT01fTEFCRUwJCSMgUHJv dmlkZXMgbGFiZWxpemF0aW9uCm9wdGlvbnMgCUNPTVBBVF80M1RUWQkJIyBCU0QgNC4zIFRUWSBj b21wYXQgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENAkJIyBDb21wYXRpYmxl IHdpdGggRnJlZUJTRDQKb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q1CQkjIENvbXBhdGlibGUgd2l0 aCBGcmVlQlNENQpvcHRpb25zIAlDT01QQVRfRlJFRUJTRDYJCSMgQ29tcGF0aWJsZSB3aXRoIEZy ZWVCU0Q2Cm9wdGlvbnMgCVNDU0lfREVMQVk9NTAwMAkJIyBEZWxheSAoaW4gbXMpIGJlZm9yZSBw cm9iaW5nIFNDU0kKb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydApvcHRpb25z IAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkKb3B0aW9ucyAJU1lTVk1TRwkJ CSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlTWVNWU0VNCQkJIyBTWVNWLXN0 eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICMgUE9T SVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJS0JEX0lOU1RBTExfQ0RF VgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKb3B0aW9ucyAJQURBUFRJVkVfR0lBTlQJ CSMgR2lhbnQgbXV0ZXggaXMgYWRhcHRpdmUuCm9wdGlvbnMgCVNUT1BfTk1JCQkjIFN0b3AgQ1BV UyB1c2luZyBOTUkgaW5zdGVhZCBvZiBJUEkKb3B0aW9ucyAgUVVPVEEgICAgICAgI2VuYWJsZSBk aXNrIHF1b3RhcwoKIyBUbyBtYWtlIGFuIFNNUCBrZXJuZWwsIHRoZSBuZXh0IHR3byBsaW5lcyBh cmUgbmVlZGVkCm9wdGlvbnMgCVNNUAkJCSMgU3ltbWV0cmljIE11bHRpUHJvY2Vzc29yIEtlcm5l bApkZXZpY2UJCWFwaWMJCQkjIEkvTyBBUElDCgpkZXZpY2UgYnJpZGdlCgojIENQVSBmcmVxdWVu Y3kgY29udHJvbApkZXZpY2UJCWNwdWZyZXEKCiMgaGFyZHdhcmUgY3J5cHRvCmRldmljZSBjcnlw dG8KZGV2aWNlIGNyeXB0b2RldgoKIyBCdXMgc3VwcG9ydC4KZGV2aWNlCQllaXNhCmRldmljZQkJ cGNpCgojIEFUQSBhbmQgQVRBUEkgZGV2aWNlcwpkZXZpY2UJCWF0YQpkZXZpY2UJCWF0YWRpc2sJ CSMgQVRBIGRpc2sgZHJpdmVzCmRldmljZQkJYXRhcmFpZAkJIyBBVEEgUkFJRCBkcml2ZXMKZGV2 aWNlCQlhdGFwaWNkCQkjIEFUQVBJIENEUk9NIGRyaXZlcwpkZXZpY2UJCWF0YXBpZmQJCSMgQVRB UEkgZmxvcHB5IGRyaXZlcwpkZXZpY2UJCWF0YXBpc3QJCSMgQVRBUEkgdGFwZSBkcml2ZXMKb3B0 aW9ucyAJQVRBX1NUQVRJQ19JRAkjIFN0YXRpYyBkZXZpY2UgbnVtYmVyaW5nCgpkZXZpY2UJCWF0 YXBpY2FtCgojIFNDU0kgQ29udHJvbGxlcnMKCiMgU0NTSSBwZXJpcGhlcmFscwpkZXZpY2UJCXNj YnVzCQkjIFNDU0kgYnVzIChyZXF1aXJlZCBmb3IgU0NTSSkKZGV2aWNlCQljaAkJIyBTQ1NJIG1l ZGlhIGNoYW5nZXJzCmRldmljZQkJZGEJCSMgRGlyZWN0IEFjY2VzcyAoZGlza3MpCmRldmljZQkJ c2EJCSMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQpkZXZpY2UJCWNkCQkjIENECmRldmlj ZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBTQ1NJIGFjY2VzcykKI2Rldmlj ZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5kIFNBRi1URSkKCiMgUkFJ RCBjb250cm9sbGVycyBpbnRlcmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5c3RlbQojZGV2aWNlCQlo cHRtdgkJIyBIaWdocG9pbnQgUm9ja2V0UkFJRCAxODJ4CmRldmljZQkJaHB0cnIJCSMgSGlnaHBv aW50IFJvY2tldFJBSUQgMTd4eCwgMjJ4eCwgMjN4eCwgMjV4eAoKIyBSQUlEIGNvbnRyb2xsZXJz CgojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNl CmRldmljZQkJYXRrYmRjCQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXIKZGV2aWNlCQlhdGtiZAkJ IyBBVCBrZXlib2FyZApkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlCgpkZXZpY2UJCWtiZG11eAkJ IyBrZXlib2FyZCBtdWx0aXBsZXhlcgoKZGV2aWNlCQl2Z2EJCSMgVkdBIHZpZGVvIGNhcmQgZHJp dmVyCgpkZXZpY2UJCXNwbGFzaAkJIyBTcGxhc2ggc2NyZWVuIGFuZCBzY3JlZW4gc2F2ZXIgc3Vw cG9ydAoKIyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5n IGFuIFNDTyBjb25zb2xlCmRldmljZQkJc2MKCmRldmljZQkJYWdwCQkjIGZvciB4Zjg2LXZpZGVv LWludGVsIHN1cHBvcnQgc2V2ZXJhbCBBR1AgY2hpcHNldHMKCiMgUG93ZXIgbWFuYWdlbWVudCBz dXBwb3J0IChzZWUgTk9URVMgZm9yIG1vcmUgb3B0aW9ucykKI2RldmljZQkJYXBtCiMgQWRkIHN1 c3BlbmQvcmVzdW1lIHN1cHBvcnQgZm9yIHRoZSBpODI1NC4KZGV2aWNlCQlwbXRpbWVyCgojIFBD Q0FSRCAoUENNQ0lBKSBzdXBwb3J0CiMgUENNQ0lBIGFuZCBjYXJkYnVzIGJyaWRnZSBzdXBwb3J0 CiNkZXZpY2UJCWNiYgkJIyBjYXJkYnVzICh5ZW50YSkgYnJpZGdlCiNkZXZpY2UJCXBjY2FyZAkJ IyBQQyBDYXJkICgxNi1iaXQpIGJ1cwojZGV2aWNlCQljYXJkYnVzCQkjIENhcmRCdXMgKDMyLWJp dCkgYnVzCgojIFNlcmlhbCAoQ09NKSBwb3J0cwpkZXZpY2UJCXNpbwkJIyA4MjUwLCAxNls0NV01 MCBiYXNlZCBzZXJpYWwgcG9ydHMKZGV2aWNlCQl1YXJ0CQkjIEdlbmVyaWMgVUFSVCBkcml2ZXIK CiMgUGFyYWxsZWwgcG9ydAojZGV2aWNlCQlwcGMKZGV2aWNlCQlwcGJ1cwkJIyBQYXJhbGxlbCBw b3J0IGJ1cyAocmVxdWlyZWQpCiNkZXZpY2UJCWxwdAkJIyBQcmludGVyCiNkZXZpY2UJCXBsaXAJ CSMgVENQL0lQIG92ZXIgcGFyYWxsZWwKI2RldmljZQkJcHBpCQkjIFBhcmFsbGVsIHBvcnQgaW50 ZXJmYWNlIGRldmljZQojI2RldmljZQkJdnBvCQkjIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQoKIyBJ ZiB5b3UndmUgZ290IGEgImR1bWIiIHNlcmlhbCBvciBwYXJhbGxlbCBQQ0kgY2FyZCB0aGF0IGlz CiMgc3VwcG9ydGVkIGJ5IHRoZSBwdWMoNCkgZ2x1ZSBkcml2ZXIsIHVuY29tbWVudCB0aGUgZm9s bG93aW5nCiMgbGluZSB0byBlbmFibGUgaXQgKGNvbm5lY3RzIHRvIHNpbywgdWFydCBhbmQvb3Ig cHBjIGRyaXZlcnMpOgojZGV2aWNlCQlwdWMKCiMgUENJIEV0aGVybmV0IE5JQ3MuCgojIFBDSSBF dGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBjb21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNvZGUu CiMgTk9URTogQmUgc3VyZSB0byBrZWVwIHRoZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRl ciB0byB1c2UgdGhlc2UgTklDcyEKZGV2aWNlCQltaWlidXMJCSMgTUlJIGJ1cyBzdXBwb3J0CiNk ZXZpY2UJCWJjZQkJIyBCcm9hZGNvbSBCQ001NzA2L0JDTTU3MDggR2lnYWJpdCBFdGhlcm5ldAoj ZGV2aWNlCQliZmUJCSMgQnJvYWRjb20gQkNNNDQweCAxMC8xMDAgRXRoZXJuZXQKZGV2aWNlICAg ICAgICAgYWxlICAgICAgICAgICAgICMgQXRoZXJvcyBBUjgxMjEvQVI4MTEzL0FSODExNCBFdGhl cm5ldAojZGV2aWNlCQliZ2UJCSMgQnJvYWRjb20gQkNNNTcweHggR2lnYWJpdCBFdGhlcm5ldAoj ZGV2aWNlCQluZmUJCSMgblZpZGlhIG5Gb3JjZSBNQ1Agb24tYm9hcmQgRXRoZXJuZXQKI2Rldmlj ZQkJbmdlCQkjIE5hdFNlbWkgRFA4MzgyMCBnaWdhYml0IEV0aGVybmV0CiMjZGV2aWNlCQludmUJ CSMgblZpZGlhIG5Gb3JjZSBNQ1Agb24tYm9hcmQgRXRoZXJuZXQgTmV0d29ya2luZwoKIyBJU0Eg RXRoZXJuZXQgTklDcy4gIHBjY2FyZCBOSUNzIGluY2x1ZGVkLgoKIyBXaXJlbGVzcyBOSUMgY2Fy ZHMKZGV2aWNlCQl3bGFuCQkjIDgwMi4xMSBzdXBwb3J0CmRldmljZQkJd2xhbl93ZXAJIyA4MDIu MTEgV0VQIHN1cHBvcnQKZGV2aWNlCQl3bGFuX2NjbXAJIyA4MDIuMTEgQ0NNUCBzdXBwb3J0CmRl dmljZQkJd2xhbl90a2lwCSMgODAyLjExIFRLSVAgc3VwcG9ydApkZXZpY2UJCXdsYW5fYW1ycgkj IEFNUlIgdHJhbnNtaXQgcmF0ZSBjb250cm9sIGFsZ29yaXRobQpkZXZpY2UJCXdsYW5fc2Nhbl9h cAkjIDgwMi4xMSBBUCBtb2RlIHNjYW5uaW5nCmRldmljZQkJd2xhbl9zY2FuX3N0YQkjIDgwMi4x MSBTVEEgbW9kZSBzY2FubmluZwojI2RldmljZQkJYW4JCSMgQWlyb25ldCA0NTAwLzQ4MDAgODAy LjExIHdpcmVsZXNzIE5JQ3MuCiNkZXZpY2UJCWF0aAkJIyBBdGhlcm9zIHBjaS9jYXJkYnVzIE5J QydzCmRldmljZQkJYXRoX2hhbAkJIyBBdGhlcm9zIEhBTCAoSGFyZHdhcmUgQWNjZXNzIExheWVy KQpkZXZpY2UJCWF0aF9yYXRlX3NhbXBsZQkjIFNhbXBsZVJhdGUgdHggcmF0ZSBjb250cm9sIGZv ciBhdGgKI2RldmljZQkJYXdpCQkjIEJheVN0YWNrIDY2MCBhbmQgb3RoZXJzCmRldmljZQkJcmFs CQkjIFJhbGluayBUZWNobm9sb2d5IFJUMjUwMCB3aXJlbGVzcyBOSUNzLgpkZXZpY2UJCXdpCQkj IFdhdmVMQU4vSW50ZXJzaWwvU3ltYm9sIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgojZGV2aWNlCQl3 bAkJIyBPbGRlciBub24gODAyLjExIFdhdmVsYW4gd2lyZWxlc3MgTklDLgoKIyBQc2V1ZG8gZGV2 aWNlcy4KZGV2aWNlCQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sKZGV2aWNlCQlyYW5kb20JCSMg RW50cm9weSBkZXZpY2UKZGV2aWNlCQlldGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0CmRldmljZQkJ c2wJCSMgS2VybmVsIFNMSVAKZGV2aWNlCQlwcHAJCSMgS2VybmVsIFBQUApkZXZpY2UJCXR1bgkJ IyBQYWNrZXQgdHVubmVsLgpkZXZpY2UJCXB0eQkJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykK ZGV2aWNlCQltZAkJIyBNZW1vcnkgImRpc2tzIgpkZXZpY2UJCWdpZgkJIyBJUHY2IGFuZCBJUHY0 IHR1bm5lbGluZwpkZXZpY2UJCWZhaXRoCQkjIElQdjYtdG8tSVB2NCByZWxheWluZyAodHJhbnNs YXRpb24pCmRldmljZQkJZmlybXdhcmUJIyBmaXJtd2FyZSBhc3Npc3QgbW9kdWxlCgojIFRoZSBg YnBmJyBkZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFja2V0IEZpbHRlci4KIyBCZSBhd2Fy ZSBvZiB0aGUgYWRtaW5pc3RyYXRpdmUgY29uc2VxdWVuY2VzIG9mIGVuYWJsaW5nIHRoaXMhCiMg Tm90ZSB0aGF0ICdicGYnIGlzIHJlcXVpcmVkIGZvciBESENQLgpkZXZpY2UJCWJwZgkJIyBCZXJr ZWxleSBwYWNrZXQgZmlsdGVyCgojIFVTQiBzdXBwb3J0CmRldmljZQkJdWhjaQkJIyBVSENJIFBD SS0+VVNCIGludGVyZmFjZQpkZXZpY2UJCW9oY2kJCSMgT0hDSSBQQ0ktPlVTQiBpbnRlcmZhY2UK ZGV2aWNlCQllaGNpCQkjIEVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlIChVU0IgMi4wKQpkZXZpY2UJ CXVzYgkJIyBVU0IgQnVzIChyZXF1aXJlZCkKI2RldmljZQkJdWRicAkJIyBVU0IgRG91YmxlIEJ1 bGsgUGlwZSBkZXZpY2VzCmRldmljZQkJdWdlbgkJIyBHZW5lcmljCmRldmljZQkJdWhpZAkJIyAi SHVtYW4gSW50ZXJmYWNlIERldmljZXMiCmRldmljZQkJdWtiZAkJIyBLZXlib2FyZApkZXZpY2UJ CXVscHQJCSMgUHJpbnRlcgpkZXZpY2UJCXVtYXNzCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAtIFJl cXVpcmVzIHNjYnVzIGFuZCBkYQpkZXZpY2UJCXVtcwkJIyBNb3VzZQpkZXZpY2UJCXVyYWwJCSMg UmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAwVVNCIHdpcmVsZXNzIE5JQ3MKZGV2aWNlCQlydW0JCSMg UmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAxVVNCIHdpcmVsZXNzIE5JQ3MKI2RldmljZQkJdXJpbwkJ IyBEaWFtb25kIFJpbyA1MDAgTVAzIHBsYXllcgpkZXZpY2UJCXVzY2FubmVyCSMgU2Nhbm5lcnMK IyBVU0IgRXRoZXJuZXQsIHJlcXVpcmVzIG1paWJ1cwoKIyBGaXJlV2lyZSBzdXBwb3J0CmRldmlj ZQkJZmlyZXdpcmUJIyBGaXJlV2lyZSBidXMgY29kZQojZGV2aWNlCQlzYnAJCSMgU0NTSSBvdmVy IEZpcmVXaXJlIChSZXF1aXJlcyBzY2J1cyBhbmQgZGEpCiNkZXZpY2UJCWZ3ZQkJIyBFdGhlcm5l dCBvdmVyIEZpcmVXaXJlIChub24tc3RhbmRhcmQhKQojZGV2aWNlCQlmd2lwCQkjIElQIG92ZXIg RmlyZVdpcmUgKFJGQyAyNzM0LDMxNDYpCmRldmljZQkJZGNvbnMJCSMgRHVtYiBjb25zb2xlIGRy aXZlcgpkZXZpY2UJCWRjb25zX2Nyb20JIyBDb25maWd1cmF0aW9uIFJPTSBmb3IgZGNvbnMKCmRl dmljZQkJc291bmQKZGV2aWNlCQlzbmRfaGRhCQkJIyBBRDE5ODZhIGV0Yy4gc291bmQKZGV2aWNl CQlhY3BpCQkJCSMgcmVxdWlyZWQgZm9yIEFTVVMgRWVlUEMKZGV2aWNlCQlhY3BpX2FzdXMKZGV2 aWNlCQlhY3BpX2FpYm9vc3QK ------=_Part_14858_16538104.1226846536568 Content-Type: text/plain; name=sysctl.ale.0_001.txt Content-Transfer-Encoding: base64 X-Attachment-Id: file2 Content-Disposition: attachment; filename=sysctl.ale.0_001.txt ZGV2LmFsZS4wLiVkZXNjOiBBdGhlcm9zIEFSODEyMS9BUjgxMTMvQVI4MTE0IFBDSWUgRXRoZXJu ZXQKZGV2LmFsZS4wLiVkcml2ZXI6IGFsZQpkZXYuYWxlLjAuJWxvY2F0aW9uOiBzbG90PTAgZnVu Y3Rpb249MApkZXYuYWxlLjAuJXBucGluZm86IHZlbmRvcj0weDE5NjkgZGV2aWNlPTB4MTAyNiBz dWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weDgzMjQgY2xhc3M9MHgwMjAwMDAKZGV2LmFsZS4w LiVwYXJlbnQ6IHBjaTMKZGV2LmFsZS4wLmludF9yeF9tb2Q6IDMwCmRldi5hbGUuMC5pbnRfdHhf bW9kOiAxMDAwCmRldi5hbGUuMC5wcm9jZXNzX2xpbWl0OiA2NApkZXYuYWxlLjAucmVzZXRfYnJr X3NlcTogMApkZXYuYWxlLjAuc3RhdHMucnguZ29vZF9mcmFtZXM6IDMKZGV2LmFsZS4wLnN0YXRz LnJ4Lmdvb2RfYmNhc3RfZnJhbWVzOiAxCmRldi5hbGUuMC5zdGF0cy5yeC5nb29kX21jYXN0X2Zy YW1lczogMApkZXYuYWxlLjAuc3RhdHMucngucGF1c2VfZnJhbWVzOiAwCmRldi5hbGUuMC5zdGF0 cy5yeC5jb250cm9sX2ZyYW1lczogMApkZXYuYWxlLjAuc3RhdHMucnguY3JjX2VycnM6IDAKZGV2 LmFsZS4wLnN0YXRzLnJ4Lmxlbl9lcnJzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5nb29kX29jdGV0 czogMTgwCmRldi5hbGUuMC5zdGF0cy5yeC5nb29kX2JjYXN0X29jdGV0czogNjAKZGV2LmFsZS4w LnN0YXRzLnJ4Lmdvb2RfbWNhc3Rfb2N0ZXRzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5ydW50czog MApkZXYuYWxlLjAuc3RhdHMucnguZnJhZ21lbnRzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5mcmFt ZXNfNjQ6IDMKZGV2LmFsZS4wLnN0YXRzLnJ4LmZyYW1lc182NV8xMjc6IDAKZGV2LmFsZS4wLnN0 YXRzLnJ4LmZyYW1lc18xMjhfMjU1OiAwCmRldi5hbGUuMC5zdGF0cy5yeC5mcmFtZXNfMjU2XzUx MTogMApkZXYuYWxlLjAuc3RhdHMucnguZnJhbWVzXzUxMl8xMDIzOiAwCmRldi5hbGUuMC5zdGF0 cy5yeC5mcmFtZXNfMTAyNF8xNTE4OiAwCmRldi5hbGUuMC5zdGF0cy5yeC5mcmFtZXNfMTUxOV9t YXg6IDAKZGV2LmFsZS4wLnN0YXRzLnJ4LnRydW5jX2VycnM6IDAKZGV2LmFsZS4wLnN0YXRzLnJ4 LmZpZm9fb2Zsb3dzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5ycnNfZXJyczogMApkZXYuYWxlLjAu c3RhdHMucnguYWxpZ25fZXJyczogMApkZXYuYWxlLjAuc3RhdHMucnguZmlsdGVyZWQ6IDAKZGV2 LmFsZS4wLnN0YXRzLnR4Lmdvb2RfZnJhbWVzOiA0CmRldi5hbGUuMC5zdGF0cy50eC5nb29kX2Jj YXN0X2ZyYW1lczogMwpkZXYuYWxlLjAuc3RhdHMudHguZ29vZF9tY2FzdF9mcmFtZXM6IDAKZGV2 LmFsZS4wLnN0YXRzLnR4LnBhdXNlX2ZyYW1lczogMApkZXYuYWxlLjAuc3RhdHMudHguY29udHJv bF9mcmFtZXM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmV4Y2Vzc19kZWZlcnM6IDAKZGV2LmFsZS4w LnN0YXRzLnR4LmRlZmVyczogMApkZXYuYWxlLjAuc3RhdHMudHguZ29vZF9vY3RldHM6IDI1NApk ZXYuYWxlLjAuc3RhdHMudHguZ29vZF9iY2FzdF9vY3RldHM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4 Lmdvb2RfbWNhc3Rfb2N0ZXRzOiAwCmRldi5hbGUuMC5zdGF0cy50eC5mcmFtZXNfNjQ6IDMKZGV2 LmFsZS4wLnN0YXRzLnR4LmZyYW1lc182NV8xMjc6IDEKZGV2LmFsZS4wLnN0YXRzLnR4LmZyYW1l c18xMjhfMjU1OiAwCmRldi5hbGUuMC5zdGF0cy50eC5mcmFtZXNfMjU2XzUxMTogMApkZXYuYWxl LjAuc3RhdHMudHguZnJhbWVzXzUxMl8xMDIzOiAwCmRldi5hbGUuMC5zdGF0cy50eC5mcmFtZXNf MTAyNF8xNTE4OiAwCmRldi5hbGUuMC5zdGF0cy50eC5mcmFtZXNfMTUxOV9tYXg6IDAKZGV2LmFs ZS4wLnN0YXRzLnR4LnNpbmdsZV9jb2xsczogMApkZXYuYWxlLjAuc3RhdHMudHgubXVsdGlfY29s bHM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmxhdGVfY29sbHM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4 LmV4Y2Vzc19jb2xsczogMApkZXYuYWxlLjAuc3RhdHMudHguYWJvcnQ6IDAKZGV2LmFsZS4wLnN0 YXRzLnR4LnVuZGVycnVuczogMApkZXYuYWxlLjAuc3RhdHMudHguZGVzY191bmRlcnJ1bnM6IDAK ZGV2LmFsZS4wLnN0YXRzLnR4Lmxlbl9lcnJzOiAwCmRldi5hbGUuMC5zdGF0cy50eC50cnVuY19l cnJzOiAxODAK ------=_Part_14858_16538104.1226846536568 Content-Type: text/plain; name=sysctl.ale.0_002.txt Content-Transfer-Encoding: base64 X-Attachment-Id: file3 Content-Disposition: attachment; filename=sysctl.ale.0_002.txt ZGV2LmFsZS4wLiVkZXNjOiBBdGhlcm9zIEFSODEyMS9BUjgxMTMvQVI4MTE0IFBDSWUgRXRoZXJu ZXQKZGV2LmFsZS4wLiVkcml2ZXI6IGFsZQpkZXYuYWxlLjAuJWxvY2F0aW9uOiBzbG90PTAgZnVu Y3Rpb249MApkZXYuYWxlLjAuJXBucGluZm86IHZlbmRvcj0weDE5NjkgZGV2aWNlPTB4MTAyNiBz dWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weDgzMjQgY2xhc3M9MHgwMjAwMDAKZGV2LmFsZS4w LiVwYXJlbnQ6IHBjaTMKZGV2LmFsZS4wLmludF9yeF9tb2Q6IDMwCmRldi5hbGUuMC5pbnRfdHhf bW9kOiAxMDAwCmRldi5hbGUuMC5wcm9jZXNzX2xpbWl0OiA2NApkZXYuYWxlLjAucmVzZXRfYnJr X3NlcTogMApkZXYuYWxlLjAuc3RhdHMucnguZ29vZF9mcmFtZXM6IDM5MDYKZGV2LmFsZS4wLnN0 YXRzLnJ4Lmdvb2RfYmNhc3RfZnJhbWVzOiAxCmRldi5hbGUuMC5zdGF0cy5yeC5nb29kX21jYXN0 X2ZyYW1lczogMApkZXYuYWxlLjAuc3RhdHMucngucGF1c2VfZnJhbWVzOiAwCmRldi5hbGUuMC5z dGF0cy5yeC5jb250cm9sX2ZyYW1lczogMApkZXYuYWxlLjAuc3RhdHMucnguY3JjX2VycnM6IDAK ZGV2LmFsZS4wLnN0YXRzLnJ4Lmxlbl9lcnJzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5nb29kX29j dGV0czogMjU4MzMyCmRldi5hbGUuMC5zdGF0cy5yeC5nb29kX2JjYXN0X29jdGV0czogNjAKZGV2 LmFsZS4wLnN0YXRzLnJ4Lmdvb2RfbWNhc3Rfb2N0ZXRzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5y dW50czogMApkZXYuYWxlLjAuc3RhdHMucnguZnJhZ21lbnRzOiAwCmRldi5hbGUuMC5zdGF0cy5y eC5mcmFtZXNfNjQ6IDQKZGV2LmFsZS4wLnN0YXRzLnJ4LmZyYW1lc182NV8xMjc6IDM5MDIKZGV2 LmFsZS4wLnN0YXRzLnJ4LmZyYW1lc18xMjhfMjU1OiAwCmRldi5hbGUuMC5zdGF0cy5yeC5mcmFt ZXNfMjU2XzUxMTogMApkZXYuYWxlLjAuc3RhdHMucnguZnJhbWVzXzUxMl8xMDIzOiAwCmRldi5h bGUuMC5zdGF0cy5yeC5mcmFtZXNfMTAyNF8xNTE4OiAwCmRldi5hbGUuMC5zdGF0cy5yeC5mcmFt ZXNfMTUxOV9tYXg6IDAKZGV2LmFsZS4wLnN0YXRzLnJ4LnRydW5jX2VycnM6IDAKZGV2LmFsZS4w LnN0YXRzLnJ4LmZpZm9fb2Zsb3dzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5ycnNfZXJyczogMApk ZXYuYWxlLjAuc3RhdHMucnguYWxpZ25fZXJyczogMApkZXYuYWxlLjAuc3RhdHMucnguZmlsdGVy ZWQ6IDAKZGV2LmFsZS4wLnN0YXRzLnR4Lmdvb2RfZnJhbWVzOiA3NzY1CmRldi5hbGUuMC5zdGF0 cy50eC5nb29kX2JjYXN0X2ZyYW1lczogNApkZXYuYWxlLjAuc3RhdHMudHguZ29vZF9tY2FzdF9m cmFtZXM6IDIKZGV2LmFsZS4wLnN0YXRzLnR4LnBhdXNlX2ZyYW1lczogMApkZXYuYWxlLjAuc3Rh dHMudHguY29udHJvbF9mcmFtZXM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmV4Y2Vzc19kZWZlcnM6 IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmRlZmVyczogMApkZXYuYWxlLjAuc3RhdHMudHguZ29vZF9v Y3RldHM6IDg0ODA3MjYKZGV2LmFsZS4wLnN0YXRzLnR4Lmdvb2RfYmNhc3Rfb2N0ZXRzOiAyNTU3 CmRldi5hbGUuMC5zdGF0cy50eC5nb29kX21jYXN0X29jdGV0czogMApkZXYuYWxlLjAuc3RhdHMu dHguZnJhbWVzXzY0OiA0CmRldi5hbGUuMC5zdGF0cy50eC5mcmFtZXNfNjVfMTI3OiA2MwpkZXYu YWxlLjAuc3RhdHMudHguZnJhbWVzXzEyOF8yNTU6IDQyCmRldi5hbGUuMC5zdGF0cy50eC5mcmFt ZXNfMjU2XzUxMTogODMKZGV2LmFsZS4wLnN0YXRzLnR4LmZyYW1lc181MTJfMTAyMzogMzU0OQpk ZXYuYWxlLjAuc3RhdHMudHguZnJhbWVzXzEwMjRfMTUxODogNDAyNApkZXYuYWxlLjAuc3RhdHMu dHguZnJhbWVzXzE1MTlfbWF4OiAwCmRldi5hbGUuMC5zdGF0cy50eC5zaW5nbGVfY29sbHM6IDAK ZGV2LmFsZS4wLnN0YXRzLnR4Lm11bHRpX2NvbGxzOiAwCmRldi5hbGUuMC5zdGF0cy50eC5sYXRl X2NvbGxzOiAwCmRldi5hbGUuMC5zdGF0cy50eC5leGNlc3NfY29sbHM6IDAKZGV2LmFsZS4wLnN0 YXRzLnR4LmFib3J0OiAwCmRldi5hbGUuMC5zdGF0cy50eC51bmRlcnJ1bnM6IDAKZGV2LmFsZS4w LnN0YXRzLnR4LmRlc2NfdW5kZXJydW5zOiAwCmRldi5hbGUuMC5zdGF0cy50eC5sZW5fZXJyczog MApkZXYuYWxlLjAuc3RhdHMudHgudHJ1bmNfZXJyczogMjQwCg== ------=_Part_14858_16538104.1226846536568-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 15:15:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F201065677 for ; Sun, 16 Nov 2008 15:15:15 +0000 (UTC) (envelope-from galbrig@googlemail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id BD6BD8FC13 for ; Sun, 16 Nov 2008 15:15:14 +0000 (UTC) (envelope-from galbrig@googlemail.com) Received: by qb-out-0506.google.com with SMTP id e12so1721078qbe.1 for ; Sun, 16 Nov 2008 07:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=Aku7nqAd9/OKuSt1PGbr88xT/q1tUaRQWfcvo4C8cUw=; b=Vd7hR7JLR7Fw3bmM4dghgguBkF8WZHnpu/GdoiNXyq1R7q4ytjWmAjbxW/VqpdrFEz doGRAC0urloJtBKGF9EKajzCv6seYkGq450XkWgLdFvagnDRJmKeh/53SAlL80uKBbx4 i3UGda1Uj/RUQxzqYE/12M9ScvHBFVdWxl3g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=sjGiAMiAMNNGSVSDodaKAbp70r3hIQI5fO2jvoRZoBAh2caDxI48jcEcntbo93xBuI Vf6DMcMwudXJ17h7rUzz0HpW5/X4m/rhS2Ynu5wnrEuWGOLc5ogv7bHz0pq+fW3dQ0HQ RLj5B3XE8upFkABDsqAYVYYuOed6PQfeCn/HA= Received: by 10.181.197.1 with SMTP id z1mr765295bkp.118.1226848512956; Sun, 16 Nov 2008 07:15:12 -0800 (PST) Received: by 10.181.145.2 with HTTP; Sun, 16 Nov 2008 07:15:12 -0800 (PST) Message-ID: <46d45f030811160715m55d099c8n53eb642a77e4ce4b@mail.gmail.com> Date: Sun, 16 Nov 2008 16:15:12 +0100 From: albri To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet / addition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 15:15:15 -0000 hello again, I want to make one addition: doing a # sockstat -46l I get following error: sockstat: struct xtcpcb size mismatch sockstat: struct xtcpcb size mismatch From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 17:00:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C21D1065749 for ; Sun, 16 Nov 2008 17:00:47 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id A21438FC13 for ; Sun, 16 Nov 2008 17:00:44 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id EE9711CC31; Sun, 16 Nov 2008 18:00:41 +0100 (CET) Date: Sun, 16 Nov 2008 18:00:41 +0100 From: Michael Moll To: freebsd-current@freebsd.org Message-ID: <20081116170041.GB5156@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CXFpZVxO6m2Ol4tQ" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unable to boot on ECS K7S5A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 17:00:47 -0000 --CXFpZVxO6m2Ol4tQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, after upgrading to new -CURRENT sources, my box (ECS K7S5A board) is not able to boot. I attached verbose boot-messages (dmesg.new) and for reference the boot-messages of the older, working kernel (dmesg.old). As one of messages is "atapci0: unable to map interrupt" I suspect some trouble in ATA oder ACPI code... Any hints? Best Regards -- Michael Moll e-mail : kvedulv@kvedulv.de WWW : http://www.kvedulv.de/ GSM : +49 175 606 7861 --CXFpZVxO6m2Ol4tQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.new" OK boot -v GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000003fef0000 SMAP type=03 base=000000003fff0000 len=0000000000008000 SMAP type=04 base=000000003fff8000 len=0000000000008000 SMAP type=02 base=00000000ffee0000 len=0000000000020000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fffc0000 len=0000000000040000 SMAP type=02 base=00000000000ec000 len=0000000000004000 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Sun Nov 16 16:25:48 CET 2008 root@trinity.kvedulv.de:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc100b000. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1991534087 Hz CPU: AMD Athlon(tm) XP 2400+ (1991.53-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383f9ff AMD Features=0xc0400800 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001425000 - 0x000000003eea4fff, 1034420224 bytes (252544 pages) avail memory = 1033105408 (985 MB) bios32: Found BIOS32 Service Directory header at 0xc00fdad0 bios32: Entry = 0xfdae0 (c00fdae0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xdb01 pnpbios: Found PnP BIOS data at 0xc00f7270 pnpbios: Entry = f0000:5d07 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Nov 16 2008 16:25:21) ACPI: RSDP @ 0x0xfa290/0x0014 (v 0 AMI ) ACPI: RSDT @ 0x0x3fff0000/0x0028 (v 1 AMIINT SiS735XX 0x00001000 MSFT 0x0100000B) ACPI: FACP @ 0x0x3fff0030/0x0074 (v 1 AMIINT SiS735XX 0x00001000 MSFT 0x0100000B) ACPI: DSDT @ 0x0x3fff0100/0x33D3 (v 1 SiS 735 0x00000100 MSFT 0x0100000D) ACPI: FACS @ 0x0x3fff8000/0x0040 npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc41b6000 pa 0x1000 atpic: Programming IRQ9 as level/low pci_open(1): mode 1 addr port (0x0cf8) is 0x80001044 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=07351039) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.PA2D -> bus 0 dev 2 func 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.PE2H -> bus 0 dev 2 func 0 ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 11 Validation 0 11 N 0 11 After Disable 0 255 N 0 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 11 Validation 0 11 N 0 11 After Disable 0 255 N 0 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 7 10 12 14 15 Validation 0 3 N 0 3 4 5 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 10 12 14 15 Validation 0 5 N 0 3 4 5 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 12 14 15 Validation 0 255 N 0 3 4 5 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 12 14 15 Validation 0 255 N 0 3 4 5 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 7 10 12 14 15 Validation 0 12 N 0 3 4 5 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 10 12 14 15 Validation 0 10 N 0 3 4 5 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.2.INTA at func 3: 10 ACPI: Found matching pin for 0.2.INTD at func 2: 5 ACPI: Found matching pin for 0.3.INTA at func 0: 12 ACPI: Found matching pin for 0.17.INTA at func 0: 11 ACPI: Found matching pin for 0.19.INTA at func 0: 11 ACPI: Found matching pin for 0.19.INTB at func 1: 11 ACPI: Found matching pin for 0.19.INTC at func 2: 3 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1039, dev=0x0735, revid=0x01 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Memory, range 32, base 0xd0000000, size 22, enabled found-> vendor=0x1039, dev=0x0001, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1039, dev=0x0008, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1039, dev=0x7001, revid=0x07 domain=0, bus=0, slot=2, func=2 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=5 map[10]: type Memory, range 32, base 0xcfffe000, size 12, enabled pcib0: matched entry for 0.2.INTD (src \_SB_.LNKD:0) pcib0: slot 2 INTD routed to irq 5 via \_SB_.LNKD found-> vendor=0x1039, dev=0x7001, revid=0x07 domain=0, bus=0, slot=2, func=3 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xcffff000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \_SB_.LNKH:0) pcib0: slot 2 INTA routed to irq 10 via \_SB_.LNKH found-> vendor=0x1039, dev=0x5513, revid=0xd0 domain=0, bus=0, slot=2, func=5 class=01-01-80, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type I/O Port, range 32, base 0xff00, size 4, enabled found-> vendor=0x1039, dev=0x0900, revid=0x90 domain=0, bus=0, slot=3, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x34 (13000 ns), maxlat=0x0b (2750 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xdc00, size 8, enabled map[14]: type Memory, range 32, base 0xcfffc000, size 12, enabled pcib0: matched entry for 0.3.INTA (src \_SB_.LNKG:0) pcib0: slot 3 INTA routed to irq 12 via \_SB_.LNKG found-> vendor=0x8086, dev=0x107c, revid=0x05 domain=0, bus=0, slot=17, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xcfe60000, size 17, enabled map[14]: type Memory, range 32, base 0xcfe40000, size 17, enabled map[18]: type I/O Port, range 32, base 0xd800, size 6, enabled pcib0: matched entry for 0.17.INTA (src \_SB_.LNKB:0) pcib0: slot 17 INTA routed to irq 11 via \_SB_.LNKB found-> vendor=0x1106, dev=0x3038, revid=0x50 domain=0, bus=0, slot=19, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xd000, size 5, enabled pcib0: matched entry for 0.19.INTA (src \_SB_.LNKA:0) pcib0: slot 19 INTA routed to irq 11 via \_SB_.LNKA found-> vendor=0x1106, dev=0x3038, revid=0x50 domain=0, bus=0, slot=19, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xd400, size 5, enabled pcib0: matched entry for 0.19.INTB (src \_SB_.LNKB:0) pcib0: slot 19 INTB routed to irq 11 via \_SB_.LNKB found-> vendor=0x1106, dev=0x3104, revid=0x51 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xcfffdf00, size 8, enabled pcib0: matched entry for 0.19.INTC (src \_SB_.LNKC:0) pcib0: slot 19 INTC routed to irq 3 via \_SB_.LNKC atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 atapci1: at device 1.0 on pci0 pci0: child atapci1 requested type 4 for rid 0x20, but the BAR says it is an memio atapci1: unable to map interrupt device_attach: atapci1 attach returned 6 atapci2: at device 2.0 on pci0 ata0: on atapci2 device_attach: ata0 attach returned 6 ata1: on atapci2 device_attach: ata1 attach returned 6 atapci3: mem 0xcfffe000-0xcfffefff irq 5 at device 2.2 on pci0 atapci3: [MPSAFE] atapci3: [ITHREAD] ata2: on atapci3 pci0: child atapci3 requested type 4 for rid 0x10, but the BAR says it is an memio device_attach: ata2 attach returned 6 atapci4: mem 0xcffff000-0xcfffffff irq 10 at device 2.3 on pci0 atapci4: [MPSAFE] atapci4: [ITHREAD] ata3: on atapci4 pci0: child atapci4 requested type 4 for rid 0x10, but the BAR says it is an memio device_attach: ata3 attach returned 6 atapci5: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on pci0 atapci5: Reserved 0x10 bytes for rid 0x20 type 4 at 0xff00 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atapci6: port 0xdc00-0xdcff mem 0xcfffc000-0xcfffcfff irq 12 at device 3.0 on pci0 atapci6: [MPSAFE] atapci6: [ITHREAD] ata4: on atapci6 atapci6: Reserved 0x100 bytes for rid 0x10 type 4 at 0xdc00 pci0: child atapci6 requested type 4 for rid 0x14, but the BAR says it is an memio device_attach: ata4 attach returned 6 em0: port 0xd800-0xd83f mem 0xcfe60000-0xcfe7ffff,0xcfe40000-0xcfe5ffff irq 11 at device 17.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xcfe60000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xd800 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:0e:0c:c5:f2:bb uhci0: port 0xd000-0xd01f irq 11 at device 19.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd400-0xd41f irq 11 at device 19.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xcfffdf00-0xcfffdfff irq 3 at device 19.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xcfffdf00 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] ehci0: Dropped interrupts workaround enabled usb2: EHCI version 0.95 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: fast interrupt uart0: console (9600,n,8,1) cpu0: on acpi0 cpu0: switching to generic Cx mode Device configuration finished. procfs registered Timecounter "TSC" frequency 1991534087 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ATA PseudoRAID loaded WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s3a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> --CXFpZVxO6m2Ol4tQ-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 17:37:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB0A1065670 for ; Sun, 16 Nov 2008 17:37:07 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by mx1.freebsd.org (Postfix) with ESMTP id BE7C18FC12 for ; Sun, 16 Nov 2008 17:37:06 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so2167099rne.12 for ; Sun, 16 Nov 2008 09:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tsuKbeWWu3VOInf7hntnhsmt1FsvAcT85k3TR4heeXM=; b=UTWRMxIeT66ivjenXSjBY4tm3R4aC24Uv02rKRFdYg+73MStI12n0e28jT9yi9z0HS BE5xhW+ErQ3nMe0GaX30z/gKkz2eNvvKjLpPpcbA/oT0CSWohD9LAhtstD4vaJ1/tIiu ey5Kgyu6A1DYgp03MAP/z6Kv2skE9tDoetms8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=J+7IEsF4WWNDi10eYtG5gxWS2cMWzaVXPw366sRf7MWtOYt2nAtTO1o6q0gM40FTB/ lfyIDnl01WuQtsrUgOPrEO92Ii0p/v1EuDQNjqOyeUTQut5Y4vXLQeXQhoLAeGSJZFlQ EyhfeyeJqI9MqEvva8EjGjFmtZHbaXXm1sLXA= Received: by 10.90.71.15 with SMTP id t15mr2129456aga.76.1226857025979; Sun, 16 Nov 2008 09:37:05 -0800 (PST) Received: by 10.90.101.20 with HTTP; Sun, 16 Nov 2008 09:37:05 -0800 (PST) Message-ID: <790a9fff0811160937j3b94ac26q251f2bc2abc9b953@mail.gmail.com> Date: Sun, 16 Nov 2008 11:37:05 -0600 From: "Scot Hetzel" To: Bear In-Reply-To: <200811162022198288506@Gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811161150196091110@Gmail.com> <200811162022198288506@Gmail.com> Cc: freebsd-current Subject: Re: My GNOME2 cannot 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: Sun, 16 Nov 2008 17:37:07 -0000 On 11/16/08, Bear wrote: > hi, > I have use these commands to install GNOME to my new-installed FreeBSD 7.0: > > pkg_add -r xorg > pkg_add -r gnome-session > pkg_add -r gnome2-lite > > and then,I reboot my computer and use user Bear to login. > then I type in > > echo "/usr/local/bin/gnome-session" > ~/.xinitrc > > then I type in > > startx > > but it give me a error > the summary of the error is below: > > Could not lock the file "/var/tmp/gconf-test-locking-file-CB9IKU" > The error was "Invalid argument"(errno = 22) > > What Can I Do??thx! > > BTW:I have been set my PACKAGEROOT to ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-current/Lat > est/ > Uninstall all the packages that were installed from the above PACKAGEROOT, then set PACKAGEROOT to either: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7.0-release/Latest or ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7-stable/Latest The packages you had installed were built for FreeBSD 8.0-CURRENT, they are not compatible with FreeBSD 7.0. Also, make sure that /var/tmp has the permissions 1777 set: # ls -l /var/ | grep tmp drwxrwxrwt 12 root wheel 1536 Nov 16 10:56 tmp Scot From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 19:12:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5664C106564A; Sun, 16 Nov 2008 19:12:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 45AFB8FC0C; Sun, 16 Nov 2008 19:12:12 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.95] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KAF00CDBXCA3M10@asmtp021.mac.com>; Sun, 16 Nov 2008 11:12:12 -0800 (PST) Message-id: From: Marcel Moolenaar To: Hans Petter Selasky In-reply-to: <200811161408.21562.hselasky@c2i.net> Date: Sun, 16 Nov 2008 11:12:10 -0800 References: <20081107082740.GA1334@icarus.home.lan> <20081108001128.GA1437@icarus.home.lan> <200811081023.10058.hselasky@freebsd.org> <200811161408.21562.hselasky@c2i.net> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 19:12:12 -0000 On Nov 16, 2008, at 5:08 AM, Hans Petter Selasky wrote: > Hi, > > It turns out my initial patch need to be limited to the use-case > only. Before > I start any real work, I want to know if anyone will object if I > implement > the following new BUS_DMA flag into FreeBSD's busdma system? > > amd64/amd64/busdma_machdep.c > i386/i386/busdma_machdep.c > arm/arm/busdma_machdep.c > ia64/ia64/busdma_machdep.c > mips/mips/busdma_machdep.c > powerpc/powerpc/busdma_machdep.c > sparc64/sparc64/bus_machdep.c > sun4v/sun4v/bus_machdep.c > sys/bus_dma.h > > /* > * The following flag specifies that no re-alignment of individual > * memory pages is allowed when loaded into DMA. It can only be used > * when "maxsegsz" is equal to "PAGE_SIZE" and "alignment" is less > * than or equal to 1. > * > * Background: Some kinds of DMA hardware only stores the full > * physical address of the first memory page when multiple memory > * pages are loaded into DMA. Consequtive memory pages only gets the > * non-offset part of the physical address updated. The hardware > * computes the amount of data that should be stored in the first > * memory page from the minimum of the total transfer length and > * PAGE_SIZE minus the initial page offset. When the initial page > * offset is not preserved the hardware ends up transferring an > * invalid number of bytes to or from the initial memory page. > */ > #define BUS_DMA_NOREAL 0x400 /* no page re-alignment allowed */ No objection, but please call it BUS_DMA_NOREALIGN NOREAL reads as NO-REAL and not as NO-RE-AL. And with real addressing an existing concept, confusion is not far around the corner... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 20:49:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1FFE1065688 for ; Sun, 16 Nov 2008 20:49:51 +0000 (UTC) (envelope-from jamesfrancistoy@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 5F8718FC13 for ; Sun, 16 Nov 2008 20:49:50 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1768972fgb.35 for ; Sun, 16 Nov 2008 12:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=RIvnHpqsw40/GFOhQEL1xg4Vyld/lWiIGBBZR4TSq5A=; b=IX3SRfmvr4kcb3KOI5Og3SJJanpD5Env31z6m8HEsym/4DpLjB8ccwPUhIQi2FVwF5 pAjIqPa23GvYb8gKZ6IXnBMI0nfJts3E+GCNm4UoNu7084wgC228LZvZRHq+0gUtfmo4 uzp7VMVStQ7qCgbpCxhLYBs4ttkNcB+Sa8g+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=kFrdp/8BnHZnfrHY+GkkD27h5nlprda4bNTbR3gHJWIRglql5M+SKnERuDFkIEcTEv wI+ymF4Ll8a9sfnAtn37PIQ63gcQnK4CN2a+xuTCh4NVBQ7dkYkmp8YQuHbaBj2FNmxv LXviXt6oZJ+YvSExsUl1Xke7IRw5+JAh//pNc= Received: by 10.187.183.6 with SMTP id k6mr369424fap.62.1226868589222; Sun, 16 Nov 2008 12:49:49 -0800 (PST) Received: by 10.187.221.18 with HTTP; Sun, 16 Nov 2008 12:49:49 -0800 (PST) Message-ID: <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> Date: Sun, 16 Nov 2008 15:49:49 -0500 From: jT Sender: jamesfrancistoy@gmail.com To: "Jeremy Chadwick" , "FreeBSD Current" In-Reply-To: <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> <20081116023011.GA89222@icarus.home.lan> <9f8af95f0811161057r48b8c5a0k3b5c9653e25e3912@mail.gmail.com> <20081116203604.GB10691@icarus.home.lan> <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> X-Google-Sender-Auth: bd32d3eed34cbcec Cc: Subject: Fwd: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2008 20:49:51 -0000 Jeremy and all, Sorry I forgot to cc the list -- I hit reply instead of reply to all :/ -- my apologies -- I've tried with several different hosts now and continually get this error after a hang now -- before it was instantaneous. [root@bigmac ~]# csup -h cvsup2.us.freebsd.org current-supfile Connected to 130.94.149.166 Invalid server reply to AUTHMD5 [root@bigmac ~]# thanks. On Sun, Nov 16, 2008 at 3:36 PM, Jeremy Chadwick wrote: > On Sun, Nov 16, 2008 at 01:57:37PM -0500, jT wrote: >> Mr. Chadwick, >> I have tried a view via specifying the -h option after calling a >> fastest_cvsup -c us -- currently it is hanging. So i'm still at a >> loss as to what it could be. I see in the code where it lprintf's it >> -- but that's not really helpful as i'm not certain where its sourcing >> the md5 from. Thanks for your help. :) > > Why did you reply to me privately? > > I have a lot to say on the problem you're having (more questions than > answers), but please keep the mailing list CC'd. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 22:37:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F7A1065675 for ; Sun, 16 Nov 2008 22:37:43 +0000 (UTC) (envelope-from chrisa@uvic.ca) Received: from castle.comp.uvic.ca (castle.comp.uvic.ca [142.104.5.97]) by mx1.freebsd.org (Postfix) with ESMTP id 439F18FC12 for ; Sun, 16 Nov 2008 22:37:43 +0000 (UTC) (envelope-from chrisa@uvic.ca) Received: from wm3.uvic.ca (camel.comp.uvic.ca [142.104.148.215]) by castle.comp.uvic.ca (8.13.8/8.13.8) with ESMTP id mAGM38Aw2600960 for ; Sun, 16 Nov 2008 14:03:08 -0800 Received: from 142.104.193.193 (proxying for 24.68.249.148) (SquirrelMail authenticated user chrisa) by wm3.uvic.ca with HTTP; Sun, 16 Nov 2008 14:03:08 -0800 (PST) Message-ID: <54489.142.104.193.193.1226872988.squirrel@wm3.uvic.ca> In-Reply-To: <790a9fff0811160937j3b94ac26q251f2bc2abc9b953@mail.gmail.com> References: <200811161150196091110@Gmail.com> <200811162022198288506@Gmail.com> <790a9fff0811160937j3b94ac26q251f2bc2abc9b953@mail.gmail.com> Date: Sun, 16 Nov 2008 14:03:08 -0800 (PST) From: chrisa@uvic.ca To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-UVic-Virus-Scanned: OK - Passed virus scan by Sophos (sophie) on castle X-UVic-Spam-Scan: castle.comp.uvic.ca Not_scanned_NOT_SA_HOST X-Scanned-By: MIMEDefang 2.63 on 142.104.5.29 Subject: Re: My GNOME2 cannot 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: Sun, 16 Nov 2008 22:37:43 -0000 > On 11/16/08, Bear wrote: >> hi, >> I have use these commands to install GNOME to my new-installed FreeBSD >> 7.0: >> >> pkg_add -r xorg >> pkg_add -r gnome-session >> pkg_add -r gnome2-lite >> >> and then,I reboot my computer and use user Bear to login. >> then I type in >> >> echo "/usr/local/bin/gnome-session" > ~/.xinitrc >> >> then I type in >> >> startx >> >> but it give me a error >> the summary of the error is below: >> >> Could not lock the file "/var/tmp/gconf-test-locking-file-CB9IKU" >> The error was "Invalid argument"(errno = 22) >> >> What Can I Do??thx! >> >> BTW:I have been set my PACKAGEROOT to >> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-current/Lat >> est/ >> > Uninstall all the packages that were installed from the above > PACKAGEROOT, then set PACKAGEROOT to either: > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7.0-release/Latest > > or > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7-stable/Latest > > The packages you had installed were built for FreeBSD 8.0-CURRENT, > they are not compatible with FreeBSD 7.0. > > Also, make sure that /var/tmp has the permissions 1777 set: > > # ls -l /var/ | grep tmp > drwxrwxrwt 12 root wheel 1536 Nov 16 10:56 tmp > > Scot I have the same problem with my gnome install. I'm running 7.0-RELEASE #0 with packages from 7-stable, and the same thing is happening. And the permissions for /var/tmp are set correctly: when I look in /var/tmp after the failure, it has created the file: it just claims that it can't lock it. Maybe it's a bug in the latest gnome. From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 01:08:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0B341065680 for ; Mon, 17 Nov 2008 01:08:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6B58FC08 for ; Mon, 17 Nov 2008 01:08:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2112094rvf.43 for ; Sun, 16 Nov 2008 17:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VAmpqDFeAZx0N0MWbBI4Nyrr4Na/8YYdmtG5Q9y4mVU=; b=EhVBHsDU2gfEv0QC4cOf7AWFIvS+Q8509S64ybZCF94iON5/BBNCxaUqU8zYcBc2R2 1RI+4IUGoCfKOPwN6V4bKC7zU5MMiDto61QOdjG0jAD3NVrrRF4cUAoeBbevyIGPpgc9 pXBC0Tskg8O6JPhwhzia6stcKHAVrX53leCJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BRVB4lxLcLxp+IY9G8+tpixxiGDoJWs+Kaf4LjiO9x1a7akzWusXaRv3VzaHUGheXj IphSxf/AkOuE2l7FU3+jCIVxrFZdWX7XWlaLW7hgxsgyuzRTPMbqBElGM+uMWzKYnBcD /2MModRszFZ8oDICxNQRtIbaEa7EGyWEbz14I= Received: by 10.141.141.3 with SMTP id t3mr1937293rvn.15.1226884080761; Sun, 16 Nov 2008 17:08:00 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id b8sm8077447rvf.3.2008.11.16.17.07.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 17:07:59 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mAH15xle051187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 10:05:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mAH15wGJ051186; Mon, 17 Nov 2008 10:05:58 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 17 Nov 2008 10:05:58 +0900 From: Pyun YongHyeon To: albri Message-ID: <20081117010558.GD50872@cdnetworks.co.kr> References: <46d45f030811160642m2dff1481g457f1fa1a4ac1372@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46d45f030811160642m2dff1481g457f1fa1a4ac1372@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet 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, 17 Nov 2008 01:08:01 -0000 On Sun, Nov 16, 2008 at 03:42:16PM +0100, albri wrote: > hello, > > I have issues transfering big or many files over ethernet on 1000H, also. > Using yongari's ale(4) driver > http://people.freebsd.org/~yongari/ale/ale.20081114.tar.gz I did not > have any problems while I surf or download 37MB sourcecode from inet. > Then scp(1)'ing source from 1000H to desktop PC showed a transfer rate > with maximum 86kB/s regardless to which direction is copied. The > ethernet NIC, while copying, is switched off regularily then. No > copies possible after three megabytes. Try turning off TSO and let me know how it goes. ("#ifconfig ale0 -tso" will do the job.) > Next try was a big file. A packed tarball from the source-tree was > copied via nc(1) using TCP-protocol. After 7 until 17MB no transfer > possible and same symptoms like above. > > One way I can reproduce this is the following: > on desktop PC: $> nc -4nl 1234 > bigfile.tar.gz > on 1000H: $> nc -4n 192.x.x.x 1234 < bigfile.tar.gz > It makes no difference wether I am a user or root. Tested over a > switch and a crossover cable. > Does anybody has a hint? > > best regards. > > - attachments: > As this is my first post, I try to attach my kernelconfig and two > sysctl dev.ale.0 (before and after error). > > - dmesg shows: > 1 ale0: port > 0xec00-0xec7f mem 0x fbfc0000-0xfbffffff irq 17 at device 0.0 on > pci3 > 2 ale0: 960 Tx FIFO, 1024 Rx FIFO > 3 ale0: Using 1 MSI messages. > 4 miibus0: on ale0 > 5 ale0: Ethernet address: 00:23:54:xx:xx:xx > 6 ale0: [FILTER] > 7 ale0: flags=8843 metric 0 mtu 1500 > 8 ale0: link state changed to UP > 9 ale0: DMA read error! -- resetting ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This would be major reason why you're getting poor performance. > 10 ale0: could not disable Tx/Rx MAC(0x00000008)! > 11 ale0: link state changed to DOWN > 12 ale0: link state changed to UP > 13 ale0: link state changed to DOWN > 14 ale0: link state changed to UP > 15 [..] 20 times > 16 ale0: DMA read error! -- resetting > 17 ale0: could not disable Tx/Rx MAC(0x00000008)! > 18 ale0: link state changed to DOWN > 19 ale0: link state changed to UP > > - ifconfig shows: > 1 ale0: flags=8843 metric 0 mtu 1500 > 2 options=319b It seems that your hardware doesn't have WOL capability. But I guess EeePC 1000H does support WOL. You've disabled some functionality of ethernet controller in BIOS? > 3 ether 00:23:54:xx:xx:xx > 4 inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.255 > 5 media: Ethernet autoselect (100baseTX ) > 6 status: active > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 03:04:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5841065675; Mon, 17 Nov 2008 03:04:48 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from m5-85.163.com (m12-15.163.com [220.181.12.15]) by mx1.freebsd.org (Postfix) with SMTP id 224428FC24; Mon, 17 Nov 2008 03:04:46 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from [127.0.0.1] (unknown [60.191.86.3]) by smtp11 (Coremail) with SMTP id D8CowLBbMwxR3yBJFtQUDA--.47532S2; Mon, 17 Nov 2008 11:04:49 +0800 (CST) Message-ID: <4920DF4F.1080407@163.com> Date: Mon, 17 Nov 2008 11:04:47 +0800 From: kevin User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Attilio Rao References: <4911B529.1030804@163.com> <3bbf2fe10811051031j25ed35e8r78dd5f21e3551579@mail.gmail.com> In-Reply-To: <3bbf2fe10811051031j25ed35e8r78dd5f21e3551579@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Coremail-Antispam: 1Uf129KBjvdXoW7GFWUCF48Xry3uw4rCr1xXwb_yoW3uwc_Wr sFyryktrWDXr4DA3yqgF4Sqrnaq39rGF1UuFyxGwn7t3yfG3sIk34kXr9avanrJa92ywn8 ArnYv3yxJr17GjkaLaAFLSUrUUUUUbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUU 4qb7Iv0xC_Jr1lb4IE77IF4wAFF20E14v26r1j6r4UM7C26xCjj4IEI4klw4CSwwAFxVCa YxvI4VCIwcAKzIAtM7CIcVAFz4kK6r1j6r18M2kK67kvxFCE548m6r1fGryUXwAawVACjs I_Ar4v6c8GOVW06r1DJrWUAwAa7VCY0VAaVVAqrcv_Jw1UWr13Mc02F40EFcxC0VAKzVAq x4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lFVAaXT ZC67ZELSn0mTvEwaV2v3VFvVW8M4IE42xK82IY64kIx2x0424l7I0Y64k_MxkIecxEwVAF wVW8GwCY0x0Ix7I2Y4AK6F4j6FyUMxCjnVAqn7xvrwC2zVAF1VAY17CE14v26r1Y6r17Yx BIdaVFxhVjvjDU0xZFpf9x0ziWCJLUUUUU= Cc: FreeBSD Current Subject: Re: shutdown and reboot do not work correct X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 03:04:48 -0000 Attilio Rao wrote: > 2008/11/5, kevin : > >> Hi, >> I update everything this afternoon(both kernel and world). when i try to >> reboot or shutdown system,i find something goes wrong.After system output >> "All buffers synced" and "Accounting disabled",system does not power off as >> normal. the keyboard still works and when i press the power button ,it >> output "acpi: suspend request ignored (not ready yet)", "acpi: request to >> enter state S5 failed (error 6)". Any one meet same problem? >> > > Could you please break into DDB and see where it is hanging? > > Thanks, > Attilio > > > I break into DDB and find lots of kernel threads are in SL stat,thread [accounting] is in stat ZL.I guess accounting can't exit correctly.After i turn off accounting,i can shutdown system now. Thanks, kevin From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 05:43:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A331065672 for ; Mon, 17 Nov 2008 05:43:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (unknown [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 087D08FC1B for ; Mon, 17 Nov 2008 05:43:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id ABF681CCDC; Mon, 17 Nov 2008 06:43:49 +0100 (CET) Date: Mon, 17 Nov 2008 06:43:49 +0100 From: Ed Schouten To: chrisa@uvic.ca Message-ID: <20081117054349.GX81783@hoeg.nl> References: <200811161150196091110@Gmail.com> <200811162022198288506@Gmail.com> <790a9fff0811160937j3b94ac26q251f2bc2abc9b953@mail.gmail.com> <54489.142.104.193.193.1226872988.squirrel@wm3.uvic.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w/fW4OhQtzSNeJ+1" Content-Disposition: inline In-Reply-To: <54489.142.104.193.193.1226872988.squirrel@wm3.uvic.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: My GNOME2 cannot 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: Mon, 17 Nov 2008 05:43:51 -0000 --w/fW4OhQtzSNeJ+1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * chrisa@uvic.ca wrote: > I have the same problem with my gnome install. I'm running 7.0-RELEASE #0 > with packages from 7-stable, and the same thing is happening. And the > permissions for /var/tmp are set correctly: when I look in /var/tmp after > the failure, it has created the file: it just claims that it can't lock > it. Be sure to run FreeBSD 7.1-STABLE (RELENG_7), not 7.0-RELEASE. As mentioned in previous emails, be sure to run the packages on the operating system version they have been compiled for. --=20 Ed Schouten WWW: http://80386.nl/ --w/fW4OhQtzSNeJ+1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkkhBJUACgkQ52SDGA2eCwVJJwCfb/BqyEOv0N28eAQ6LcMOcb0y 33AAn0dHuEWZDvSD2lNzFs89ZBMChmo0 =6o8P -----END PGP SIGNATURE----- --w/fW4OhQtzSNeJ+1-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 11:09:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CA0A1065674 for ; Mon, 17 Nov 2008 11:09:31 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id E96AF8FC29 for ; Mon, 17 Nov 2008 11:09:30 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from cmb.rambler.ramblermedia.com (unknown [81.19.90.211]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 9F0E017073; Mon, 17 Nov 2008 14:09:29 +0300 (MSK) Message-ID: <492150E8.3040708@citrin.ru> Date: Mon, 17 Nov 2008 14:09:28 +0300 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: FreeBSD Current References: <491B3161.7000808@citrin.ru> <20081112203501.GA81783@hoeg.nl> <491B41F3.9030307@citrin.ru> <20081112212350.GB81783@hoeg.nl> <491C6BE7.3020202@citrin.ru> <20081113180514.GH81783@hoeg.nl> In-Reply-To: <20081113180514.GH81783@hoeg.nl> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten Subject: Re: serial console in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 11:09:31 -0000 On 13.11.2008 21:05, Ed Schouten wrote: > * Anton Yuzhaninov wrote: >> with cuau0 in /etc/ttys it works! > > That means your serial cable probably doesn't have its carrier detect > line connected properly. > Pinout of my cable is: 1 - 1 2 - 3 3 - 2 4 - 6 5 - 5 6 - 4 7 - 8 8 - 7 9 - 9 As I understand, carrier detect line connected properly. Correct me, if I mistaken. What is proper freebsd serial cable pinout? -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 12:09:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A212A1065677 for ; Mon, 17 Nov 2008 12:09:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 8996A8FC12 for ; Mon, 17 Nov 2008 12:09:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id gBj11a0090QkzPwA3C9Jh6; Mon, 17 Nov 2008 12:09:18 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id gC9G1a00N2P6wsM8NC9GHF; Mon, 17 Nov 2008 12:09:17 +0000 X-Authority-Analysis: ?? Received: by icarus.home.lan (Postfix, from userid 1000) id 171ED33C36; Mon, 17 Nov 2008 04:09:17 -0800 (PST) Date: Mon, 17 Nov 2008 04:09:17 -0800 From: Jeremy Chadwick To: Anton Yuzhaninov Message-ID: <20081117120917.GA28884@icarus.home.lan> References: <491B3161.7000808@citrin.ru> <20081112203501.GA81783@hoeg.nl> <491B41F3.9030307@citrin.ru> <20081112212350.GB81783@hoeg.nl> <491C6BE7.3020202@citrin.ru> <20081113180514.GH81783@hoeg.nl> <492150E8.3040708@citrin.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <492150E8.3040708@citrin.ru> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Ed Schouten , FreeBSD Current Subject: Re: serial console in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 12:09:18 -0000 On Mon, Nov 17, 2008 at 02:09:28PM +0300, Anton Yuzhaninov wrote: > On 13.11.2008 21:05, Ed Schouten wrote: >> * Anton Yuzhaninov wrote: >>> with cuau0 in /etc/ttys it works! >> >> That means your serial cable probably doesn't have its carrier detect >> line connected properly. >> > > Pinout of my cable is: > > 1 - 1 > 2 - 3 > 3 - 2 > 4 - 6 > 5 - 5 > 6 - 4 > 7 - 8 > 8 - 7 > 9 - 9 > > As I understand, carrier detect line connected properly. > Correct me, if I mistaken. > What is proper freebsd serial cable pinout? The handbook goes over this. Your cable is indeed wrong. http://www.freebsd.org/doc/en/books/handbook/serial.html#SERIAL-CABLES-PORTS And these are from our internal notes, specifically for use with our serial console device (MRV LX-4016S) which uses RJ45 for serial. The pin names I've labelled appropriately, so you should be able to figure out what your cable should be. And yes, these work with hardware flow control, and are *reliable* on FreeBSD. We use the gettytab entry "std.115200" for them, with no character loss. ---------------------------------------------------------------------- The LX-4016S-001 sports sixteen (16) RJ45 connectors. The cabling for the console port (Diag/Mgmt Port, also known as Port 0) comes with the unit. The cable to use for this port appears to be some sort of rollover cable (Cisco?); it's silver and flat, not round like CAT5. It's 8-pin though. A DB9 adapter also comes with this cable, which allows you to hook it up to a standard PC and access it. Ports labelled 1-16 require RJ45-to-DB9 adapters for hooking the MRV up to actual servers in the rack. The adapters that work best are the Xyplex XFDCE91 adapters, which support hardware flow control (RTS/CTS) and come pre-assembled. You can find the product here: Xyplex adapter XFDCE91 RJ45-to-DB9 APACN p/n 24490-15 -- http://www.apacn.com/ Pinout/wiring diagram: RJ45 DB9 Female Female =========== ======= (CTS) 1 <----> 7 (RTS) (DTR) 2 <----> 6 (DSR) (TxD) 3 <----> 2 (RxD) (TxD GND) 4 <----> 5 (GND) (RxD GND) 5 <----> 5 (GND) (RxD) 6 <----> 3 (TxD) (DSR/DCD) 7 <----> 4 (DTR) (RTS) 8 <----> 8 (CTS) Pins 1 (DCD) and 9 (RI) on the DB9 are unconnected/unused. With these adapters, use standard (not crossover!) CAT5/6 cables. ---------------------------------------------------------------------- -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 14:58:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B903F1065672 for ; Mon, 17 Nov 2008 14:58:50 +0000 (UTC) (envelope-from jamesfrancistoy@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 CE36C8FC1E for ; Mon, 17 Nov 2008 14:58:49 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so963782eyi.7 for ; Mon, 17 Nov 2008 06:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=rfuLgXdLcK36EXQnuvGg9xJ4j3641ALeoWVKPoKDbhQ=; b=P2RWxqMC04tl93UIvvMAeOZA9wF3KYoEFv5cmmJ1YAzCk0YVMaA0HgnJJO2EynSJ3l BbQT4dPiCzB58wEi+bHbtm1P/QPJl2HLcQ6mYS4VXeZf5xUa5yFXNgT4ACJqoIAbBB1r nsNv2PfGsMcthKnvndxoJhVYSp6A73s9SyGgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=t6COjsS2GEAZQtpoGRMJvSmEkokLMqpcpBmqP62MGi9t/PKZcabZYT1nt7VqTSrCRi dRAKJrMeFRUhYGQsyEFbzAceoDLVEzLmpuuzhD7xclZeulCe3CIMVX/zyKTvx+d4yoEV hnNA97n6ZXI8aJq6TSzWgxzlpyfMFlPJZ+hKQ= Received: by 10.187.228.6 with SMTP id f6mr473581far.52.1226933928441; Mon, 17 Nov 2008 06:58:48 -0800 (PST) Received: by 10.187.221.18 with HTTP; Mon, 17 Nov 2008 06:58:48 -0800 (PST) Message-ID: <9f8af95f0811170658q3e09b541sf862561cab340a23@mail.gmail.com> Date: Mon, 17 Nov 2008 09:58:48 -0500 From: jT Sender: jamesfrancistoy@gmail.com To: "Jeremy Chadwick" , "FreeBSD Current" In-Reply-To: <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> <20081116023011.GA89222@icarus.home.lan> <9f8af95f0811161057r48b8c5a0k3b5c9653e25e3912@mail.gmail.com> <20081116203604.GB10691@icarus.home.lan> <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> X-Google-Sender-Auth: b94aa2e6ba28e925 Cc: Subject: Re: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 14:58:50 -0000 All, Again after a few hours i get: [root@bigmac ~]# csup -h cvsup11.us.freebsd.org current-supfile Connected to 130.94.149.166 Invalid server reply to AUTHMD5 [root@bigmac ~]# This time its on cvsup11 -- this is the most bizarre behavior I have ever noticed. I was checking my bash_history and noted that i did a make makesum in nvidia-driver because I updated the version and wanted the new sum files. Since this was a port I have no idea how it could be related -- but noticed that it had to do with checksums -- could this have really fouled things up? And is there a solution to fix this? Thanks a lot. -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary "anyone else want to feel my weebok hit their grapes?" --stewie From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 15:05:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F80B1065670 for ; Mon, 17 Nov 2008 15:05:35 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 447A88FC14 for ; Mon, 17 Nov 2008 15:05:33 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA10.westchester.pa.mail.comcast.net with comcast id gDe41a0010QuhwU5AF5PSS; Mon, 17 Nov 2008 15:05:23 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA02.westchester.pa.mail.comcast.net with comcast id gF5X1a0062P6wsM3NF5XZb; Mon, 17 Nov 2008 15:05:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=SEj4gfpxshv51uu5dN8A:9 a=Cvia_GqhVQHcrDl-kN_ar9bzMrEA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id ED3FC33C36; Mon, 17 Nov 2008 07:05:30 -0800 (PST) Date: Mon, 17 Nov 2008 07:05:30 -0800 From: Jeremy Chadwick To: jT Message-ID: <20081117150530.GA32196@icarus.home.lan> References: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> <20081116023011.GA89222@icarus.home.lan> <9f8af95f0811161057r48b8c5a0k3b5c9653e25e3912@mail.gmail.com> <20081116203604.GB10691@icarus.home.lan> <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> <9f8af95f0811170658q3e09b541sf862561cab340a23@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f8af95f0811170658q3e09b541sf862561cab340a23@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: mux@FreeBSD.org, FreeBSD Current Subject: Re: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 15:05:35 -0000 On Mon, Nov 17, 2008 at 09:58:48AM -0500, jT wrote: > All, > Again after a few hours i get: > > [root@bigmac ~]# csup -h cvsup11.us.freebsd.org current-supfile > Connected to 130.94.149.166 > Invalid server reply to AUTHMD5 > [root@bigmac ~]# > > This time its on cvsup11 -- this is the most bizarre behavior I have > ever noticed. I was checking my bash_history and noted that i did a > make makesum in nvidia-driver because I updated the version and wanted > the new sum files. Since this was a port I have no idea how it could > be related -- but noticed that it had to do with checksums -- could > this have really fouled things up? And is there a solution to fix > this? Thanks a lot. "make makesum" just changes the contents of the port distinfo file. That definitely has nothing to do with the oddities you're seeing with csup. Things to try that come to my mind: Could you provide the output of the above csup command but with -L 2 added to the argument list? Next, could you try cvsup? You can add the binary as a package (it's a "standalone" package, e.g. no runtime dependencies, so you can pkg_delete it when you're done). This should do the trick: pkg_add -r cvsup-without-gui. Then try using "cvsup" instead of "csup" in your command. If the issue continues with cvsup, some pcaps or truss's will be needed to figure out what's going across the wire. I've CC'd mux@FreeBSD.org, who is the author of csup, to help out. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 15:50:55 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968271065674; Mon, 17 Nov 2008 15:50:55 +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 4F3698FC08; Mon, 17 Nov 2008 15:50:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAHFnp1U021194; Mon, 17 Nov 2008 08:49:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 17 Nov 2008 08:51:10 -0700 (MST) Message-Id: <20081117.085110.1649769838.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200811161408.21562.hselasky@c2i.net> References: <20081108001128.GA1437@icarus.home.lan> <200811081023.10058.hselasky@freebsd.org> <200811161408.21562.hselasky@c2i.net> X-Mailer: Mew version 5.2 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, freebsd-usb@FreeBSD.org Subject: Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 15:50:55 -0000 In message: <200811161408.21562.hselasky@c2i.net> Hans Petter Selasky writes: : Hi, : : It turns out my initial patch need to be limited to the use-case only. Before : I start any real work, I want to know if anyone will object if I implement : the following new BUS_DMA flag into FreeBSD's busdma system? : : amd64/amd64/busdma_machdep.c : i386/i386/busdma_machdep.c : arm/arm/busdma_machdep.c : ia64/ia64/busdma_machdep.c : mips/mips/busdma_machdep.c : powerpc/powerpc/busdma_machdep.c : sparc64/sparc64/bus_machdep.c : sun4v/sun4v/bus_machdep.c : sys/bus_dma.h : : /* : * The following flag specifies that no re-alignment of individual : * memory pages is allowed when loaded into DMA. It can only be used : * when "maxsegsz" is equal to "PAGE_SIZE" and "alignment" is less : * than or equal to 1. : * : * Background: Some kinds of DMA hardware only stores the full : * physical address of the first memory page when multiple memory : * pages are loaded into DMA. Consequtive memory pages only gets the : * non-offset part of the physical address updated. The hardware : * computes the amount of data that should be stored in the first : * memory page from the minimum of the total transfer length and : * PAGE_SIZE minus the initial page offset. When the initial page : * offset is not preserved the hardware ends up transferring an : * invalid number of bytes to or from the initial memory page. : */ : #define BUS_DMA_NOREAL 0x400 /* no page re-alignment allowed */ : : : : Without this new feature in busdma the USB hardware will not work when the DMA : data is placed on bounce pages, for example on 64-bit architectures with more : than 4GB of RAM. I'm having trouble understanding the need for this patch. Can you provide a patch to usb2 to use it as well as doing one of the implementations (say i386 or amd64) so that it is easier to judge the problem it is trying to solve? Warner From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 17:10:30 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787C11065670 for ; Mon, 17 Nov 2008 17:10:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id C97B58FC17 for ; Mon, 17 Nov 2008 17:10:29 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 675D5456B1; Mon, 17 Nov 2008 18:10:28 +0100 (CET) Received: from localhost (ghf58.internetdsl.tpnet.pl [83.12.187.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 48B5F45683 for ; Mon, 17 Nov 2008 18:10:21 +0100 (CET) Date: Mon, 17 Nov 2008 18:10:17 +0100 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20081117171017.GB1489@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ncSAzJYg3Aa9+CRW" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: NFS 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: Mon, 17 Nov 2008 17:10:30 -0000 --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'm seeing this panic very often now with few days old HEAD: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0x80626004 stack pointer =3D 0x28:0x83bce88c frame pointer =3D 0x28:0x83bce890 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 2177 (make) [thread pid 2177 tid 100126 ] Stopped at xdrmbuf_inline+0x54: movl 0xc(%edx),%eax db> tr Tracing pid 2177 tid 100126 td 0x84e17d80 xdrmbuf_inline(83bce954,c,f04,d52ed,83bcea1c,...) at sys/xdr/xdr_mbuf.c:287 xdr_replymsg(83bce954,83bce924,1,2a3,bb9,...) at sys/rpc/rpc_prot.c:186 clnt_dg_call(83dff200,83bcea1c,e,83f5eb00,83bcea58,...) at sys/rpc/clnt_dg.= c:682 clnt_reconnect_call(83f9ba80,83bcea1c,e,83f5eb00,83bcea58,...) at sys/rpc/c= lnt_rc.c:273 nfs_request(8422c218,83f5eb00,e,84e17d80,84e29c00,...) at sys/nfsclient/nfs= _krpc.c:484 nfs_renamerpc(8422c218,84c2c390,15,84e29c00,84e17d80,...) at sys/nfsclient/= nfs_vnops.c:1731 nfs_sillyrename(86285324,8,0,0,8422c218,...) at sys/nfsclient/nfs_vnops.c:1= 704 nfs_remove(83bcec30,83bcec30,0,83bcec30,86285324,...) at nfs_remove+0x12f VOP_REMOVE_APV(806cfe80,83bcec30,2,8474ba70,7fbfdd84,...) at VOP_REMOVE_APV= +0xa5 kern_unlinkat(84e17d80,ffffff9c,7fbfdd84,0,83bcec80,...) at kern_unlinkat+0= x187 kern_unlink(84e17d80,7fbfdd84,0,83bced2c,8065a4b3,...) at kern_unlink+0x27 unlink(84e17d80,83bcecf8,4,84e17d80,806bab70,...) at unlink+0x22 syscall(83bced38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip =3D 0x807d5d3, esp =3D 0x7fbfd= ccc, ebp =3D 0x7fbfdd48 --- Any ideas? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ncSAzJYg3Aa9+CRW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJIaV4ForvXbEpPzQRAqp/AKD3nBWPkJW3FQx6nNOKNk1kyQsvUACggEdl WI3SvfRP55qukFxoxZTc5LA= =CWpM -----END PGP SIGNATURE----- --ncSAzJYg3Aa9+CRW-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 17:54:04 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA815106564A; Mon, 17 Nov 2008 17:54:04 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 758948FC19; Mon, 17 Nov 2008 17:54:04 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id C6CF33FA4; Mon, 17 Nov 2008 17:52:49 +0000 (GMT) Message-Id: <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> From: Doug Rabson To: Pawel Jakub Dawidek In-Reply-To: <20081117171017.GB1489@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 17:54:02 +0000 References: <20081117171017.GB1489@garage.freebsd.pl> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.92/8642/Mon Nov 17 04:01:08 2008 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: NFS 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: Mon, 17 Nov 2008 17:54:04 -0000 On 17 Nov 2008, at 17:10, Pawel Jakub Dawidek wrote: > Hi. > > I'm seeing this panic very often now with few days old HEAD: > > > Any ideas? Can you reproduce this with INVARIANTS turned on? That should trigger a KASSERT a bit earlier and give me a chance to fix the thing. From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 18:03:10 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AAD81065679 for ; Mon, 17 Nov 2008 18:03:10 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0CC8FC25 for ; Mon, 17 Nov 2008 18:03:09 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0F4B04569A; Mon, 17 Nov 2008 19:03:02 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8E29745683; Mon, 17 Nov 2008 19:02:56 +0100 (CET) Date: Mon, 17 Nov 2008 19:02:53 +0100 From: Pawel Jakub Dawidek To: Doug Rabson Message-ID: <20081117180253.GA1733@garage.freebsd.pl> References: <20081117171017.GB1489@garage.freebsd.pl> <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: NFS 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: Mon, 17 Nov 2008 18:03:10 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 17, 2008 at 05:54:02PM +0000, Doug Rabson wrote: >=20 > On 17 Nov 2008, at 17:10, Pawel Jakub Dawidek wrote: >=20 > >Hi. > > > >I'm seeing this panic very often now with few days old HEAD: > > > > > >Any ideas? >=20 > Can you reproduce this with INVARIANTS turned on? That should trigger =20 > a KASSERT a bit earlier and give me a chance to fix the thing. I've INVARIANTS on... Is there some assertion added recently you are expecting? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJIbHMForvXbEpPzQRAmd0AJsE1H3cQaKHkmRx9oyJ5Jb5NdS3sgCcDCYO QOemA8xxQX+oznMneLNR7Hw= =Np0S -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 18:07:54 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BD8F1065670; Mon, 17 Nov 2008 18:07:54 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 5342B8FC08; Mon, 17 Nov 2008 18:07:54 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id CFF0D3FB7; Mon, 17 Nov 2008 18:06:39 +0000 (GMT) Message-Id: <8A43CF07-D06F-4EAF-A171-DF7F10F036F5@rabson.org> From: Doug Rabson To: Pawel Jakub Dawidek In-Reply-To: <20081117180253.GA1733@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 18:07:52 +0000 References: <20081117171017.GB1489@garage.freebsd.pl> <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> <20081117180253.GA1733@garage.freebsd.pl> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.92/8642/Mon Nov 17 04:01:08 2008 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: NFS 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: Mon, 17 Nov 2008 18:07:54 -0000 On 17 Nov 2008, at 18:02, Pawel Jakub Dawidek wrote: > On Mon, Nov 17, 2008 at 05:54:02PM +0000, Doug Rabson wrote: >> >> On 17 Nov 2008, at 17:10, Pawel Jakub Dawidek wrote: >> >>> Hi. >>> >>> I'm seeing this panic very often now with few days old HEAD: >>> >>> >>> Any ideas? >> >> Can you reproduce this with INVARIANTS turned on? That should trigger >> a KASSERT a bit earlier and give me a chance to fix the thing. > > I've INVARIANTS on... Is there some assertion added recently you are > expecting? Hmm. I added an assert in r184921 which ought to have caught this. Could you try this patch and see if it changes anything: Index: rpc/clnt_dg.c =================================================================== --- rpc/clnt_dg.c (revision 184968) +++ rpc/clnt_dg.c (working copy) @@ -543,7 +543,7 @@ if (tv > 0) { if (cu->cu_closing || cu->cu_closed) - error = 0; + error = ESHUTDOWN; else error = msleep(cr, &cs->cs_lock, cu->cu_waitflag, cu->cu_waitchan, tv); From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 18:14:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF5AB1065672 for ; Mon, 17 Nov 2008 18:14:15 +0000 (UTC) (envelope-from galbrig@googlemail.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 582E98FC13 for ; Mon, 17 Nov 2008 18:14:15 +0000 (UTC) (envelope-from galbrig@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so2070752fgb.35 for ; Mon, 17 Nov 2008 10:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=vZuN4ty2SQyIXunUiyMnQc61NxdDCvH8nJAqi5en7gw=; b=u+FlxzzhprdbPWQQA7npCvBjOYKqDJK1tDsVa65IUnQicKUuKWPHBqx1PEdXa5sgOU thMvIkr05fODmzj2D24/7cSe/BApxM7RAf9WKg8kpl+S4u3nV+m9NGInghJG5NrVwliu TIVNt1D3JdUGwo3yls3w6yqcHXaVenEfyQdJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GmfGUsesfHN978JLGcsyk39nSSxxn6+hGAj/X0Ugluvrr2RScDj1xCH42PMhvoIV59 HmwsqksN6i6wTvyTD8enw+n1wPyUwIWyTgcHRFo3I8oJZEUDzwoKgOwKK8jiuxR/EHEo 8mHCwAiMrWH4tngSQ9tCB3ykt3B/QFd1iXp00= Received: by 10.181.141.7 with SMTP id t7mr1083443bkn.10.1226945652954; Mon, 17 Nov 2008 10:14:12 -0800 (PST) Received: by 10.181.145.2 with HTTP; Mon, 17 Nov 2008 10:14:12 -0800 (PST) Message-ID: <46d45f030811171014i2ae5df78mbbebc367ef2ca7d4@mail.gmail.com> Date: Mon, 17 Nov 2008 19:14:12 +0100 From: albri To: pyunyh@gmail.com In-Reply-To: <20081117010558.GD50872@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46d45f030811160642m2dff1481g457f1fa1a4ac1372@mail.gmail.com> <20081117010558.GD50872@cdnetworks.co.kr> Cc: freebsd-current@freebsd.org Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 18:14:16 -0000 hello, On 11/17/08, Pyun YongHyeon wrote: > On Sun, Nov 16, 2008 at 03:42:16PM +0100, albri wrote: > > hello, > > > > I have issues transfering big or many files over ethernet on 1000H, also. > > Using yongari's ale(4) driver > > http://people.freebsd.org/~yongari/ale/ale.20081114.tar.gz I did not > > have any problems while I surf or download 37MB sourcecode from inet. > > Then scp(1)'ing source from 1000H to desktop PC showed a transfer rate > > with maximum 86kB/s regardless to which direction is copied. The > > ethernet NIC, while copying, is switched off regularily then. No > > copies possible after three megabytes. > > Try turning off TSO and let me know how it goes. > ("#ifconfig ale0 -tso" will do the job.) > this helps a little bit with two effects. Copying source-tree with scp(1): Now I can see transfers with up to approx. 500kB/s - inaccurate measured with scp(1), but relation counts. Transfer stalles after different data volumes with DMA-error on tty0, but networking port is not turned off. This happens after 30-80MB data transfers. You can restart the whole copy at once again. Copying source-tree with nc(1) tar-gzipped: Transfer stops and starts with DMA-error every approx. 7MB with turning off NIC. > > Next try was a big file. A packed tarball from the source-tree was > > copied via nc(1) using TCP-protocol. After 7 until 17MB no transfer > > possible and same symptoms like above. > > [..] > > - dmesg shows: > > 1 ale0: port > > 0xec00-0xec7f mem 0x fbfc0000-0xfbffffff irq 17 at device 0.0 on > > pci3 > > 2 ale0: 960 Tx FIFO, 1024 Rx FIFO > > 3 ale0: Using 1 MSI messages. > > 4 miibus0: on ale0 > > 5 ale0: Ethernet address: 00:23:54:xx:xx:xx > > 6 ale0: [FILTER] > > 7 ale0: flags=8843 metric 0 mtu > 1500 > > 8 ale0: link state changed to UP > > 9 ale0: DMA read error! -- resetting > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This would be major reason why you're getting poor performance. > Yes, definately. See above. [..] > > > > - ifconfig shows: > > 1 ale0: flags=8843 metric 0 mtu > 1500 > > 2 options=319b > > It seems that your hardware doesn't have WOL capability. But I > guess EeePC 1000H does support WOL. You've disabled some > functionality of ethernet controller in BIOS? > Ethernet controller is turned on in BIOS, but booting via ROM is turned off. Maybe did I not compile WOL to my (nearly) monolithic kernel? And if so, I do not know the switch. [..] > > -- > Regards, > Pyun YongHyeon > Did you remember my second post?: >I want to make one addition: >doing a ># sockstat -46l >I get following error: >sockstat: struct xtcpcb size mismatch >sockstat: struct xtcpcb size mismatch Is there a relation to DMA-error? best regards. From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 18:37:57 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B32C1065677 for ; Mon, 17 Nov 2008 18:37:57 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA928FC18 for ; Mon, 17 Nov 2008 18:37:56 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AAC5A4569A; Mon, 17 Nov 2008 19:37:54 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4F22345684; Mon, 17 Nov 2008 19:37:48 +0100 (CET) Date: Mon, 17 Nov 2008 19:37:45 +0100 From: Pawel Jakub Dawidek To: Doug Rabson Message-ID: <20081117183745.GB1733@garage.freebsd.pl> References: <20081117171017.GB1489@garage.freebsd.pl> <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> <20081117180253.GA1733@garage.freebsd.pl> <8A43CF07-D06F-4EAF-A171-DF7F10F036F5@rabson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <8A43CF07-D06F-4EAF-A171-DF7F10F036F5@rabson.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: NFS 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: Mon, 17 Nov 2008 18:37:57 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 17, 2008 at 06:07:52PM +0000, Doug Rabson wrote: >=20 > On 17 Nov 2008, at 18:02, Pawel Jakub Dawidek wrote: >=20 > >On Mon, Nov 17, 2008 at 05:54:02PM +0000, Doug Rabson wrote: > >> > >>On 17 Nov 2008, at 17:10, Pawel Jakub Dawidek wrote: > >> > >>>Hi. > >>> > >>>I'm seeing this panic very often now with few days old HEAD: > >>> > >>> > >>>Any ideas? > >> > >>Can you reproduce this with INVARIANTS turned on? That should trigger > >>a KASSERT a bit earlier and give me a chance to fix the thing. > > > >I've INVARIANTS on... Is there some assertion added recently you are > >expecting? >=20 > Hmm. I added an assert in r184921 which ought to have caught this. =20 > Could you try this patch and see if it changes anything: >=20 > Index: rpc/clnt_dg.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- rpc/clnt_dg.c (revision 184968) > +++ rpc/clnt_dg.c (working copy) > @@ -543,7 +543,7 @@ >=20 > if (tv > 0) { > if (cu->cu_closing || cu->cu_closed) > - error =3D 0; > + error =3D ESHUTDOWN; > else > error =3D msleep(cr, &cs->cs_lock, > cu->cu_waitflag, cu->cu_waitchan, tv); >=20 Ok, my source is older and doesn't contain the assertion you added. I applied the patch above and also added assertion by hand (I'm not setup now to upgrade entire system). This is the panic I get with the new kernel: panic: xdrmbuf_create with NULL mbuf chain cpuid =3D 0 KDB: enter: panic [thread pid 1017 tid 100086 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> tr Tracing pid 1017 tid 100086 td 0x841fa480 kdb_enter(80686620,80686620,806a1861,83b52714,0,...) at kdb_enter+0x3a panic(806a1861,83b527e8,805c6746,83b527b4,0,...) at panic+0x136 xdrmbuf_create(83b527b4,0,1,2a3,bb9,...) at xdrmbuf_create+0x1f clnt_dg_call(83dffca0,83b5287c,2,84042600,83b528b8,...) at clnt_dg_call+0xc= a6 clnt_reconnect_call(83dffcc0,83b5287c,2,84042600,83b528b8,...) at clnt_reco= nnect_call+0x5a0 nfs_request(85173648,84042600,2,841fa480,8432d200,...) at nfs_request+0x1dd nfs_setattrrpc(83b52a90,83b529f4,83b529e8,83b529f8,83b529e8,...) at nfs_set= attrrpc+0x24b nfs_create(83b52acc,83b52acc,0,83b52acc,83b52ba8,...) at nfs_create+0x530 VOP_CREATE_APV(806cfea0,83b52acc,2,804cf1cc,8432d200,...) at VOP_CREATE_APV= +0xa5 vn_open_cred(83b52ba8,83b52c5c,180,8432d200,84105268,...) at vn_open_cred+0= x1d0 vn_open(83b52ba8,83b52c5c,180,84105268,6fc8a6,...) at vn_open+0x33 kern_openat(841fa480,ffffff9c,7fbfdd34,0,a03,...) at kern_openat+0xe0 kern_open(841fa480,7fbfdd34,0,a02,180,...) at kern_open+0x35 open(841fa480,83b52cf8,c,804d150,806bab18,...) at open+0x30 syscall(83b52d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x807e147, esp =3D 0x7fbfd82c= , ebp =3D 0x7fbfdcd8 --- If you want me to convert some of those to file:line, just let me know. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJIbn4ForvXbEpPzQRAg9zAKDfU1MUZN6wc0CG2qurYnYF/PkMWACg56Qe FlaZO2muNTfK7/t7D+H9DzU= =lmaC -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 20:20:54 2008 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 2DAED1065672 for ; Mon, 17 Nov 2008 20:20:54 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id D1ED88FC14 for ; Mon, 17 Nov 2008 20:20:53 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 17 Nov 2008 14:52:16 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.10.3-GA) with ESMTP id KLL65059; Mon, 17 Nov 2008 14:52:11 -0500 (EST) Received: from unknown (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 17 Nov 2008 14:52:07 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18721.52069.739772.624537@jerusalem.litteratus.org> Date: Mon, 17 Nov 2008 14:52:05 -0500 To: current@freebsd.org X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Cc: Subject: new USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 20:20:54 -0000 [I'm suscribed, but please CC: anyway.] According to UPDATING: 20081009: The uhci, ohci, ehci and slhci USB Host controller drivers have been put into separate modules. If you load the usb module separately through loader.conf you will need to load the appropriate *hci module as well. E.g. for a UHCI-based USB 2.0 controller add the following to loader.conf: uhci_load="YES" ehci_load="YES" I'm about to upgrade a machine where USB is compiled into the kernel, and want to confirm no changes are needed to: device uhci device ohci device ehci device usb device ugen #device uhid device ukbd options KBD_INSTALL_CDEV device ums in $KERNCONF. Respectfully, Robert Huff From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 20:55:38 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1F21065679 for ; Mon, 17 Nov 2008 20:55:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 65DAD8FC0C for ; Mon, 17 Nov 2008 20:55:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D80394569A; Mon, 17 Nov 2008 21:55:34 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5A6A845684 for ; Mon, 17 Nov 2008 21:55:29 +0100 (CET) Date: Mon, 17 Nov 2008 21:55:26 +0100 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20081117205526.GC1733@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 20:55:38 -0000 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. So ZFS was updated from version 6 to 13. Be very careful when updating your system if you use ZFS. The number of changes is huge and my regression tests and manual tests I did only cover part of the entire functionality. More info here: http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D185029 Enjoy. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --/e2eDi0V/xtL+Mc8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJIdo+ForvXbEpPzQRAsgLAKDe/XLOBovbID4by1vZ22huSjDeJwCgrR6x LRCA6hZw6SGkGPCI6Gkv7cc= =LZzT -----END PGP SIGNATURE----- --/e2eDi0V/xtL+Mc8-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:14:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87FC610656A7 for ; Mon, 17 Nov 2008 21:14:41 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 048078FC08 for ; Mon, 17 Nov 2008 21:14:40 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so24254ugs.39 for ; Mon, 17 Nov 2008 13:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6aRGXKgXWtDot9Gl91jAoI5FtPhY17+tRpFVO7u6IbU=; b=o3kFedDs7eZnXLXZHBLMI3AmLq3aWNa7nE6D5Ns8ew5mgZkZM52PagvezoTpexbQSR LNaDj6nhAalq97T6R9WpHjzXGLi/u2LfQA2dIg8KYrE407q+PgDaR9DjNZmjTYnnplQC Mgk7ca8U87OKm9m3VKcna7iuuC7CeNatx7gKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=NugJvUYj+zT7p1v/lO+s0R80yb4O9W2vbtc5YURdrD/fgChkNrIbeMCvjs/lCvDH/D TyftoAZ8ZbHkDBql/K37aUvhezoFLL/ixO+wq7cz0wNC94f5TYXuQ0eAv4EL4EAwqBFH 3tO5IEJAjOFz+0Uhq3Wj2WQZWX4bSzji0GGV8= Received: by 10.187.238.1 with SMTP id p1mr564343far.31.1226956479488; Mon, 17 Nov 2008 13:14:39 -0800 (PST) Received: by 10.187.221.18 with HTTP; Mon, 17 Nov 2008 13:14:39 -0800 (PST) Message-ID: <9f8af95f0811171314qe41077yae993ca4e9eec10e@mail.gmail.com> Date: Mon, 17 Nov 2008 16:14:39 -0500 From: jT Sender: jamesfrancistoy@gmail.com To: "Jeremy Chadwick" In-Reply-To: <20081117150530.GA32196@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> <20081116023011.GA89222@icarus.home.lan> <9f8af95f0811161057r48b8c5a0k3b5c9653e25e3912@mail.gmail.com> <20081116203604.GB10691@icarus.home.lan> <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> <9f8af95f0811170658q3e09b541sf862561cab340a23@mail.gmail.com> <20081117150530.GA32196@icarus.home.lan> X-Google-Sender-Auth: 789a1be1ced70267 Cc: FreeBSD Current Subject: Re: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 21:14:41 -0000 All / Jeremy / Maxime, [root@bigmac ~]# csup -L 2 current-supfile Parsing supfile "current-supfile" Connecting to cvsup3.freebsd.org Connected to 128.31.0.28 Server software version: SNAP_16_1h Invalid server reply to AUTHMD5 [root@bigmac ~]# cvsup -g -L 2 -h cvsup2.us.freebsd.org current-supfile Parsing supfile "current-supfile" Connecting to cvsup2.us.freebsd.org Connected to cvsup2.us.freebsd.org Server software version: SNAP_16_1h Premature EOF from server Will retry at 16:14:29 [root@bigmac ~]# cvsup -g -L 2 -h cvsup11.us.freebsd.org current-supfile Parsing supfile "current-supfile" Connecting to cvsup11.us.freebsd.org Connected to cvsup11.us.freebsd.org Server software version: SNAP_16_1h Premature EOF from server Will retry at 16:14:56 On Mon, Nov 17, 2008 at 10:05 AM, Jeremy Chadwick wrote: > On Mon, Nov 17, 2008 at 09:58:48AM -0500, jT wrote: >> All, >> Again after a few hours i get: >> >> [root@bigmac ~]# csup -h cvsup11.us.freebsd.org current-supfile >> Connected to 130.94.149.166 >> Invalid server reply to AUTHMD5 >> [root@bigmac ~]# >> >> This time its on cvsup11 -- this is the most bizarre behavior I have >> ever noticed. I was checking my bash_history and noted that i did a >> make makesum in nvidia-driver because I updated the version and wanted >> the new sum files. Since this was a port I have no idea how it could >> be related -- but noticed that it had to do with checksums -- could >> this have really fouled things up? And is there a solution to fix >> this? Thanks a lot. > > "make makesum" just changes the contents of the port distinfo file. > That definitely has nothing to do with the oddities you're seeing with > csup. > > Things to try that come to my mind: > > Could you provide the output of the above csup command but with -L 2 > added to the argument list? > > Next, could you try cvsup? You can add the binary as a package (it's a > "standalone" package, e.g. no runtime dependencies, so you can > pkg_delete it when you're done). This should do the trick: pkg_add -r > cvsup-without-gui. Then try using "cvsup" instead of "csup" in your > command. > > If the issue continues with cvsup, some pcaps or truss's will be needed > to figure out what's going across the wire. > > I've CC'd mux@FreeBSD.org, who is the author of csup, to help out. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:30:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04BAD1065673 for ; Mon, 17 Nov 2008 21:30:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AAB588FC14 for ; Mon, 17 Nov 2008 21:30:04 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1L2BfW-0007NG-IT for freebsd-current@freebsd.org; Mon, 17 Nov 2008 21:30:02 +0000 Received: from 93-138-105-237.adsl.net.t-com.hr ([93.138.105.237]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Nov 2008 21:30:02 +0000 Received: from ivoras by 93-138-105-237.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Nov 2008 21:30:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 17 Nov 2008 22:25:09 +0100 Lines: 44 Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE32C957B9942EDE446B947D9" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-105-237.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 21:30:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE32C957B9942EDE446B947D9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > Hi. >=20 > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. >=20 > More info here: >=20 > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D185029 Hi, Genuine thanks, will try it ASAP :) I see this change: http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/loader/main.c?r1=3D= 185029&r2=3D185028&pathrev=3D185029 Does it mean you've been working on ZFS booting? --------------enigE32C957B9942EDE446B947D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkh4TUACgkQldnAQVacBcjt8gCfTRUoymIHdpaoOjDjwv5AFW/M 98wAnAkFsKprdPb68rVC/PYa+2PqqAT/ =2Fyl -----END PGP SIGNATURE----- --------------enigE32C957B9942EDE446B947D9-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:30:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0836F1065675 for ; Mon, 17 Nov 2008 21:30:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0E78FC25 for ; Mon, 17 Nov 2008 21:30:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id gG5V1a0050vyq2s51MWjoc; Mon, 17 Nov 2008 21:30:43 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA05.westchester.pa.mail.comcast.net with comcast id gMWi1a00d2P6wsM3RMWjwH; Mon, 17 Nov 2008 21:30:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=mZ26Z2_7aFmCldY0Al8A:9 a=FdKqjzFaP3WSUATY7GCFkYek_v0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id A2AD033C38; Mon, 17 Nov 2008 13:30:42 -0800 (PST) Date: Mon, 17 Nov 2008 13:30:42 -0800 From: Jeremy Chadwick To: jT Message-ID: <20081117213042.GA40420@icarus.home.lan> References: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> <20081116023011.GA89222@icarus.home.lan> <9f8af95f0811161057r48b8c5a0k3b5c9653e25e3912@mail.gmail.com> <20081116203604.GB10691@icarus.home.lan> <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> <9f8af95f0811170658q3e09b541sf862561cab340a23@mail.gmail.com> <20081117150530.GA32196@icarus.home.lan> <9f8af95f0811171314qe41077yae993ca4e9eec10e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f8af95f0811171314qe41077yae993ca4e9eec10e@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 21:30:45 -0000 On Mon, Nov 17, 2008 at 04:14:39PM -0500, jT wrote: > All / Jeremy / Maxime, > > [root@bigmac ~]# csup -L 2 current-supfile > Parsing supfile "current-supfile" > Connecting to cvsup3.freebsd.org > Connected to 128.31.0.28 > Server software version: SNAP_16_1h > Invalid server reply to AUTHMD5 > > [root@bigmac ~]# cvsup -g -L 2 -h cvsup2.us.freebsd.org current-supfile > Parsing supfile "current-supfile" > Connecting to cvsup2.us.freebsd.org > Connected to cvsup2.us.freebsd.org > Server software version: SNAP_16_1h > Premature EOF from server > Will retry at 16:14:29 > > [root@bigmac ~]# cvsup -g -L 2 -h cvsup11.us.freebsd.org current-supfile > Parsing supfile "current-supfile" > Connecting to cvsup11.us.freebsd.org > Connected to cvsup11.us.freebsd.org > Server software version: SNAP_16_1h > Premature EOF from server > Will retry at 16:14:56 Okay so the problem is not specific to the csup binary. The errors returned are different, but I'm willing to bet they're the result of the same problem. Are you using a firewall (ipfw or pf) on this box? Is there a firewall upstream from you? A NAT box that's severely broken? This could cause what you're seeing. truss -f -a -s 8192 -o truss.out csup -h someserver current-supfile Then please provide the contents of truss.out (they may be very long), or put the file up on the web somewhere. Do not include it as a MIME attachment. Do not copy/paste the contents either. This might not be enough either. tcpdump/pcap output might be required, but one thing at a time. Also, a minor (unrelated) issue:, in this particular case, please don't top post (I am one of the few who normally does not say this). In-line replies will be appreciated here due to the nature of the problem; it makes context very hard to follow WRT this issue. Thanks. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:36:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E59AD106564A for ; Mon, 17 Nov 2008 21:36:19 +0000 (UTC) (envelope-from jamesfrancistoy@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 553898FC08 for ; Mon, 17 Nov 2008 21:36:19 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2121216fgb.35 for ; Mon, 17 Nov 2008 13:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=zGOxgAzQH2NG03yGYKYCHiozNoJf+Xaqbj5GNSyhCss=; b=Ixlmo3W0cjizXkOlmyeEjuVPjaxBNRJ7hWBcqEF0VJHr7vYBy7LWpQFHPGiY57GOok 8dr710zy8ZW+vOqEM4ufFtj8hx4HhYFbbjwN2pnP1YiEfmQ5hOOTEWZ960a/cQRI61l6 i5jRq4z9gDLKK3/ukvXqWu/ipjdlvu3MBr2Q4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=lT94T1XnsGcaY4K7RTD5sY27fvpyDxsRkdeO2QMVmVYm8MXj1AMEjh6xR0brMfC9Qy 99LUtfj0kvZPWFrTxzTpq84Lj1/hnwJesbSEkp88aqw1b9ygqIpdIEPrIauZlDLDO8sG 4Bx2WC7BNFmMFsrWLtXos9geGTBVr0jp9pwSk= Received: by 10.187.223.14 with SMTP id a14mr567022far.66.1226957777398; Mon, 17 Nov 2008 13:36:17 -0800 (PST) Received: by 10.187.221.18 with HTTP; Mon, 17 Nov 2008 13:36:16 -0800 (PST) Message-ID: <9f8af95f0811171336k70cd4effpcd9c7e482ad7b796@mail.gmail.com> Date: Mon, 17 Nov 2008 16:36:16 -0500 From: jT Sender: jamesfrancistoy@gmail.com To: "Jeremy Chadwick" In-Reply-To: <20081117213042.GA40420@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9f8af95f0811151550q6d4d48cfv28034e5403dde028@mail.gmail.com> <20081116023011.GA89222@icarus.home.lan> <9f8af95f0811161057r48b8c5a0k3b5c9653e25e3912@mail.gmail.com> <20081116203604.GB10691@icarus.home.lan> <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> <9f8af95f0811170658q3e09b541sf862561cab340a23@mail.gmail.com> <20081117150530.GA32196@icarus.home.lan> <9f8af95f0811171314qe41077yae993ca4e9eec10e@mail.gmail.com> <20081117213042.GA40420@icarus.home.lan> X-Google-Sender-Auth: 2649aa54d34f4058 Cc: FreeBSD Current Subject: Re: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 21:36:20 -0000 On Mon, Nov 17, 2008 at 4:30 PM, Jeremy Chadwick wrote: > On Mon, Nov 17, 2008 at 04:14:39PM -0500, jT wrote: >> All / Jeremy / Maxime, >> >> [root@bigmac ~]# csup -L 2 current-supfile >> Parsing supfile "current-supfile" >> Connecting to cvsup3.freebsd.org >> Connected to 128.31.0.28 >> Server software version: SNAP_16_1h >> Invalid server reply to AUTHMD5 >> >> [root@bigmac ~]# cvsup -g -L 2 -h cvsup2.us.freebsd.org current-supfile >> Parsing supfile "current-supfile" >> Connecting to cvsup2.us.freebsd.org >> Connected to cvsup2.us.freebsd.org >> Server software version: SNAP_16_1h >> Premature EOF from server >> Will retry at 16:14:29 >> >> [root@bigmac ~]# cvsup -g -L 2 -h cvsup11.us.freebsd.org current-supfile >> Parsing supfile "current-supfile" >> Connecting to cvsup11.us.freebsd.org >> Connected to cvsup11.us.freebsd.org >> Server software version: SNAP_16_1h >> Premature EOF from server >> Will retry at 16:14:56 > > Okay so the problem is not specific to the csup binary. The errors > returned are different, but I'm willing to bet they're the result of the > same problem. > > Are you using a firewall (ipfw or pf) on this box? Is there a firewall > upstream from you? A NAT box that's severely broken? This could cause > what you're seeing. I am a CS undergrad at union college ITS is notorious for doing silly things here from time to time, so anything is possible. > > truss -f -a -s 8192 -o truss.out csup -h someserver current-supfile > > Then please provide the contents of truss.out (they may be very long), > or put the file up on the web somewhere. Do not include it as a MIME > attachment. Do not copy/paste the contents either. truss.out can be found here hope this is the format that you were looking for. http://dpaste.com/91570/ > > This might not be enough either. tcpdump/pcap output might be required, > but one thing at a time. > > Also, a minor (unrelated) issue:, in this particular case, please don't > top post (I am one of the few who normally does not say this). In-line > replies will be appreciated here due to the nature of the problem; it > makes context very hard to follow WRT this issue. Thanks. Sorry for this, I normally do try to not top post and am a stickler about this often -- i'm just in the middle of finals and have been copying and pasting output from my blackberry to get this resolved asap -- I won't do that anymore my apologies > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:36:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA0F71065689 for ; Mon, 17 Nov 2008 21:36:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEC28FC1E for ; Mon, 17 Nov 2008 21:36:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L2Bll-0007dW-Et for freebsd-current@freebsd.org; Mon, 17 Nov 2008 21:36:29 +0000 Received: from 93-138-105-237.adsl.net.t-com.hr ([93.138.105.237]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Nov 2008 21:36:29 +0000 Received: from ivoras by 93-138-105-237.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Nov 2008 21:36:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 17 Nov 2008 22:36:16 +0100 Lines: 55 Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3053C394B0E4238300DFABBA" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-105-237.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) In-Reply-To: X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 21:36:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3053C394B0E4238300DFABBA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > Pawel Jakub Dawidek wrote: >> Hi. >> >> So ZFS was updated from version 6 to 13. Be very careful when updating= >> your system if you use ZFS. The number of changes is huge and my >> regression tests and manual tests I did only cover part of the entire >> functionality. >> >> More info here: >> >> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D185029 >=20 > Hi, >=20 > Genuine thanks, will try it ASAP :) >=20 > I see this change: >=20 > http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/loader/main.c?r1= =3D185029&r2=3D185028&pathrev=3D185029 >=20 > Does it mean you've been working on ZFS booting? Ah, I see it, tt's there in the commit log: - ZFSBoot Support to boot off of ZFS pool. Not finished, AFAIK. Submitted by: dfr I hope it's finished soon :) --------------enig3053C394B0E4238300DFABBA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkh49UACgkQldnAQVacBciwegCbBffc0ffoZ2oWaVDezIdzb7om YbQAoOHc2L45M3YsJpNEw77PgK/eNe8W =yIkt -----END PGP SIGNATURE----- --------------enig3053C394B0E4238300DFABBA-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:37:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E446F1065672 for ; Mon, 17 Nov 2008 21:37:23 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 97DC58FC13 for ; Mon, 17 Nov 2008 21:37:23 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1104887yxb.13 for ; Mon, 17 Nov 2008 13:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1UG5gavxXX3iVuYfac5sazHrD+WxFHM/ewVNMYI+ybk=; b=GApF1NRAiuLttStLlN1b2HmAEQntdEnUjwaBZLtATwzC1SSsGXtK5DTbnCZ1qAnIZt tKMAVD1OBYCAFD1hDOkJS6kohTrFyBlLVq29N3udt7YsA3cFxXhkU3wkSF/tFDJajTPC Ionuu1hrMY7BtTVzCobaEW+iKMVf9wLheBJF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ND25cF57NcmVEhynDmtrEBtE1Jpd6cNVbuQSvJZKEB75yA4LZ3vWNQbJmIdPzVaOsq of115XGPEM9uHOprLR3uksEbTbiVP9j7hub4ygltbaTYU8070TdkKw6zHfKRpXkq/pKW BXK6XEJjR9SfYdUz3NVgMMli7AnumGLPQmWU8= Received: by 10.103.106.1 with SMTP id i1mr1380774mum.47.1226956358675; Mon, 17 Nov 2008 13:12:38 -0800 (PST) Received: by 10.103.249.11 with HTTP; Mon, 17 Nov 2008 13:12:38 -0800 (PST) Message-ID: Date: Mon, 17 Nov 2008 22:12:38 +0100 From: "Claus Guttesen" To: "Pawel Jakub Dawidek" In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081117205526.GC1733@garage.freebsd.pl> Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 21:37:24 -0000 > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. > > More info here: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 > > Enjoy. Thank you. Is this a current-only upgrade or can it be applied to stable as well? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:55:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE6081065670 for ; Mon, 17 Nov 2008 21:55:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 889A98FC14 for ; Mon, 17 Nov 2008 21:55:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id gLWM1a00Q0vp7WLA4Mv1en; Mon, 17 Nov 2008 21:55:01 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id gMuu1a0052P6wsM8RMuuV5; Mon, 17 Nov 2008 21:54:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=BEGH_OAIAAAA:8 a=QycZ5dHgAAAA:8 a=cePbaPBXJ6eLor3qIpcA:9 a=9n2BzQeobopHkGLymckAVz1-W8AA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 0866733C36; Mon, 17 Nov 2008 13:54:54 -0800 (PST) Date: Mon, 17 Nov 2008 13:54:54 -0800 From: Jeremy Chadwick To: jT Message-ID: <20081117215454.GA40777@icarus.home.lan> References: <20081116023011.GA89222@icarus.home.lan> <9f8af95f0811161057r48b8c5a0k3b5c9653e25e3912@mail.gmail.com> <20081116203604.GB10691@icarus.home.lan> <9f8af95f0811161249i9419c0dn3c3473b9e2d4a42e@mail.gmail.com> <9f8af95f0811161249wb29f535vf5ac9f7ce6a1b32e@mail.gmail.com> <9f8af95f0811170658q3e09b541sf862561cab340a23@mail.gmail.com> <20081117150530.GA32196@icarus.home.lan> <9f8af95f0811171314qe41077yae993ca4e9eec10e@mail.gmail.com> <20081117213042.GA40420@icarus.home.lan> <9f8af95f0811171336k70cd4effpcd9c7e482ad7b796@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f8af95f0811171336k70cd4effpcd9c7e482ad7b796@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: CSUP failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 21:55:02 -0000 On Mon, Nov 17, 2008 at 04:36:16PM -0500, jT wrote: > On Mon, Nov 17, 2008 at 4:30 PM, Jeremy Chadwick wrote: > > On Mon, Nov 17, 2008 at 04:14:39PM -0500, jT wrote: > >> All / Jeremy / Maxime, > >> > >> [root@bigmac ~]# csup -L 2 current-supfile > >> Parsing supfile "current-supfile" > >> Connecting to cvsup3.freebsd.org > >> Connected to 128.31.0.28 > >> Server software version: SNAP_16_1h > >> Invalid server reply to AUTHMD5 > >> > >> [root@bigmac ~]# cvsup -g -L 2 -h cvsup2.us.freebsd.org current-supfile > >> Parsing supfile "current-supfile" > >> Connecting to cvsup2.us.freebsd.org > >> Connected to cvsup2.us.freebsd.org > >> Server software version: SNAP_16_1h > >> Premature EOF from server > >> Will retry at 16:14:29 > >> > >> [root@bigmac ~]# cvsup -g -L 2 -h cvsup11.us.freebsd.org current-supfile > >> Parsing supfile "current-supfile" > >> Connecting to cvsup11.us.freebsd.org > >> Connected to cvsup11.us.freebsd.org > >> Server software version: SNAP_16_1h > >> Premature EOF from server > >> Will retry at 16:14:56 > > > > Okay so the problem is not specific to the csup binary. The errors > > returned are different, but I'm willing to bet they're the result of the > > same problem. > > > > Are you using a firewall (ipfw or pf) on this box? Is there a firewall > > upstream from you? A NAT box that's severely broken? This could cause > > what you're seeing. > > I am a CS undergrad at union college ITS is notorious for doing silly > things here from time to time, so anything is possible. Okay, but you didn't answer my other question: are you using ipfw or pf on your box? > > truss -f -a -s 8192 -o truss.out csup -h someserver current-supfile > > > > Then please provide the contents of truss.out (they may be very long), > > or put the file up on the web somewhere. Do not include it as a MIME > > attachment. Do not copy/paste the contents either. > > truss.out can be found here hope this is the format that you were looking for. > > http://dpaste.com/91570/ And here we see the problem: 33849: socket(PF_INET,SOCK_STREAM,6) = 4 (0x4) 33849: connect(4,{ AF_INET 130.94.149.166:5999 },16) = 0 (0x0) 33849: fstat(1,{ mode=crw--w---- ,inode=111,size=0,blksize=4096 }) = 0 (0x0) 33849: ioctl(1,TIOCGETA,0xbfbfdc60) = 0 (0x0) 33849: write(1,"Connected to 130.94.149.166\n",28) = 28 (0x1c) 33849: read(4,"OK 17 0 SNAP_16_1h CVSup server ready\n",1023) = 38 (0x26) 33849: write(4,"PROTO 17 0 CSUP_1_0\n",20) = 20 (0x14) 33849: read(4,"PROTO 17 0\n",1023) = 11 (0xb) 33849: __sysctl(0xbfbfe8bc,0x2,0xbfbfe998,0xbfbfe8d4,0x0,0x0) = 0 (0x0) 33849: getlogin(0x28318c50,0x11,0xbfbfe8c8,0x283149e0,0xbfbfe998,0x805df20) = 0 (0x0) 33849: write(4,"USER bbs bigmac.union.edu\n",26) = 26 (0x1a) 33849: read(4,0x8115400,1023) ERR#54 'Connection reset by peer' 33849: write(2,"Invalid server reply to AUTHMD5\n",32) = 32 (0x20) File descriptor 4 is the TCP socket connected to 130.94.149.166:5999. We can see that after the write() is performed (with the string "USER bbs bigmac.union.edu"), the following read() receives errno 54, which is connection reset by peer. The csup code is expecting to get back data from the remote end, but its being severed in-between. The USER string appears to be "USER ", where is your actual username (even if you'd used sudo, it still figures it out). Here's what mine does: 40933: getlogin(0x60cf8f80,0x11,0x7fffffffe8d0,0x60bcc0bc,0x0,0x7fffffffe888) = 0 (0x0) 40933: write(4,"USER jdc icarus.home.lan\n",25) = 25 (0x19) 40933: read(4,"AUTHMD5 . .\n",1023) = 12 (0xc) 40933: write(4,"AUTHMD5 . . .\n",14) = 14 (0xe) 40933: read(4,"OK .\n",1023) = 5 (0x5) 40933: write(4,"ATTR 6\n0\nfe7\n1e1\nff1\nff1\n9\n.\n",29) = 29 (0x1d) So as you can see, something between you and the cvsup servers is severing the connection before AUTHMD5 string can be sent to you. I would love to blame your college for this (chances are that's what it is; administrative ACLs that are intentionally injecting TCP RST back to you as a form of network control -- it's very common, especially at colleges where students are continually doing things they should not be doing), but I don't have "hard evidence" that points you to them. If you're not using ipfw or pf on your box, then it's likely your college which is doing this. The only solution is to talk to your network administrators to get a hole punched to allow TCP port 5999, which they very likely will not do (I worked at Oregon State University for many years, CS/IT often resembles a dictatorship). You could use SSH port tunnelling (assuming you have a shell account somewhere on the Internet) and siphon your csup through that. Either way, I'd start by talking to your college network admins. You can point them to this thread. They'll at least be able to confirm if what you're seeing is the result of some TCP RST injection hardware on their network. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 22:56:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CD2D106564A for ; Mon, 17 Nov 2008 22:56:25 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id DBCFD8FC08 for ; Mon, 17 Nov 2008 22:56:24 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from five.intranet ([88.217.92.107]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Mon, 17 Nov 2008 23:46:20 +0100 id 0035E8E7.000000004921F43C.00015231 Message-Id: <1140ACDC-86E5-4498-B076-BAD18A592467@yellowspace.net> From: Lorenzo Perone To: Pawel Jakub Dawidek In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 23:46:19 +0100 References: <20081117205526.GC1733@garage.freebsd.pl> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@FreeBSD.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2008 22:56:26 -0000 PAAARRRTYYY!!! :)) THANKS so much!! Lorenzo On 17.11.2008, at 21:55, Pawel Jakub Dawidek wrote: > Hi. > > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. > > More info here: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 > > Enjoy. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 00:00:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA3A71065673 for ; Tue, 18 Nov 2008 00:00:48 +0000 (UTC) (envelope-from chrisa@uvic.ca) Received: from castle.comp.uvic.ca (castle.comp.uvic.ca [142.104.5.97]) by mx1.freebsd.org (Postfix) with ESMTP id BBAF88FC16 for ; Tue, 18 Nov 2008 00:00:48 +0000 (UTC) (envelope-from chrisa@uvic.ca) Received: from wm3.uvic.ca (camel.comp.uvic.ca [142.104.148.215]) by castle.comp.uvic.ca (8.13.8/8.13.8) with ESMTP id mAI00mfh5869624 for ; Mon, 17 Nov 2008 16:00:48 -0800 Received: from 142.104.193.193 (proxying for 24.68.249.148) (SquirrelMail authenticated user chrisa) by wm3.uvic.ca with HTTP; Mon, 17 Nov 2008 16:00:48 -0800 (PST) Message-ID: <54949.142.104.193.193.1226966448.squirrel@wm3.uvic.ca> In-Reply-To: <20081117054349.GX81783@hoeg.nl> References: <200811161150196091110@Gmail.com> <200811162022198288506@Gmail.com> <790a9fff0811160937j3b94ac26q251f2bc2abc9b953@mail.gmail.com> <54489.142.104.193.193.1226872988.squirrel@wm3.uvic.ca> <20081117054349.GX81783@hoeg.nl> Date: Mon, 17 Nov 2008 16:00:48 -0800 (PST) From: chrisa@uvic.ca To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-UVic-Virus-Scanned: OK - Passed virus scan by Sophos (sophie) on castle X-UVic-Spam-Scan: castle.comp.uvic.ca Not_scanned_NOT_SA_HOST X-Scanned-By: MIMEDefang 2.63 on 142.104.5.29 Subject: Re: My GNOME2 cannot 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, 18 Nov 2008 00:00:49 -0000 > * chrisa@uvic.ca wrote: >> I have the same problem with my gnome install. I'm running 7.0-RELEASE >> #0 >> with packages from 7-stable, and the same thing is happening. And the >> permissions for /var/tmp are set correctly: when I look in /var/tmp >> after >> the failure, it has created the file: it just claims that it can't lock >> it. > > Be sure to run FreeBSD 7.1-STABLE (RELENG_7), not 7.0-RELEASE. As > mentioned in previous emails, be sure to run the packages on the > operating system version they have been compiled for. > > -- > Ed Schouten > WWW: http://80386.nl/ > For some reason, I thought that packages for any version of 7 would work on any other version of 7, so I thought that getting packages from 7-stable would be a good way to get up-to-date packages instead of nearly year-old packages from 7.0-release. Oh well. I installed gnome from ports and it works fine, so you were right about the packages. Thanks, Chris A From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 00:24:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E86CA106564A for ; Tue, 18 Nov 2008 00:24:49 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (warped.bluecherry.net [66.138.159.247]) by mx1.freebsd.org (Postfix) with ESMTP id BC3B68FC17 for ; Tue, 18 Nov 2008 00:24:49 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (unknown [74.193.170.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 69966A210E11; Mon, 17 Nov 2008 18:00:19 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id mAI00Gvu054479; Mon, 17 Nov 2008 18:00:16 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Mon, 17 Nov 2008 18:00:16 -0600 (CST) From: Wes Morgan To: Pawel Jakub Dawidek In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 00:24:50 -0000 On Mon, 17 Nov 2008, Pawel Jakub Dawidek wrote: > Hi. > > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. Sneaky devil, and after I spent most of Sunday trying to apply the big patch by hand to the most recent version of -current possible! Great job with this, though. ZFS support has to be one of the best features to work on from the viewpoint of users, and has a huge impact. On a serious note, what kind of test data would you like to have other than general "it's more stable now" feedback? Do you think the new code is any more likely to destroy all of our data the the old? Again, great work! From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 01:10:32 2008 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 806431065672 for ; Tue, 18 Nov 2008 01:10:32 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 502168FC12 for ; Tue, 18 Nov 2008 01:10:32 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 493BE19014; Mon, 17 Nov 2008 20:10:31 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 Received: from tau.draftnet (unknown [66.45.161.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Mon, 17 Nov 2008 20:10:31 -0500 (EST) Date: Mon, 17 Nov 2008 17:09:56 -0800 From: Bruce Cran To: Robert Huff Message-ID: <20081117170956.47f3bc36@tau.draftnet> In-Reply-To: <18721.52069.739772.624537@jerusalem.litteratus.org> References: <18721.52069.739772.624537@jerusalem.litteratus.org> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: new USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 01:10:32 -0000 On Mon, 17 Nov 2008 14:52:05 -0500 Robert Huff wrote: > I'm about to upgrade a machine where USB is compiled into the > kernel, and want to confirm no changes are needed to: This note isn't about the new USB stack (usb2, which uses usb2_controller_uhci, usb2_storage_ums etc.), but the old stack which was split into modules. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 07:03:44 2008 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 CA42C106564A for ; Tue, 18 Nov 2008 07:03:44 +0000 (UTC) (envelope-from oz@nixil.net) Received: from nixil.net (nixil.net [161.58.222.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7760E8FC08 for ; Tue, 18 Nov 2008 07:03:44 +0000 (UTC) (envelope-from oz@nixil.net) Received: from home.nixil.net (c-76-23-62-255.hsd1.ut.comcast.net [76.23.62.255]) (authenticated bits=0) by nixil.net (8.13.6.20060614/8.13.6) with ESMTP id mAI6pmPl086563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 17 Nov 2008 23:51:54 -0700 (MST) Message-ID: <49226603.5030204@nixil.net> Date: Mon, 17 Nov 2008 23:51:47 -0700 From: Phil Oleson User-Agent: Thunderbird 2.0.0.16 (X11/20080818) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (nixil.net [161.58.222.1]); Mon, 17 Nov 2008 23:51:54 -0700 (MST) X-Virus-Scanned: ClamAV 0.94/8645/Mon Nov 17 21:30:32 2008 on nixil.net X-Virus-Status: Clean Cc: Subject: lockup booting 8.0-CURRENT-200811 snap image X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 07:03:44 -0000 Hi, I've been trying to update my system to Current to try out the new usb stack etc.. and have had some problems. Initially I attempted to just do a cvsup, make buildworld, make kernel and had problems at the reboot. Ended up having to use the livecd to swap out the kernel (loader was strangely hanging before I could type unload; boot kernel.old) Anyways, I picked up a new drive to split my system up to have a working 7 & current. So, I downloaded the 200811 snap iso's for amd64 & i386 and tried to boot to them. Same/similar lockup happens.. now since this board currently doesn't have a serial port I've had to handtype what was left on the screen.. so hopefully it's enough for now. System: INTEL BLKDG35EC 775 G35 (flashed to the **ECG3510M.86A.0107** Bios Image) INTEL C2Q Q9300 2.5G 775 2 gigs memory (messed up on original order and havnt fixed it yet) using the built-in Intel video.. so the i386 and the amd64 dvd image I booted with had the same stopping screen/output that I could see.. this is what I was able to get down from a verbose boot. ------------------------------------------------------ Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 Validation 0 10 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 143181800 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2980, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2982, revid=0x03 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range32, base 0x90200000, size 20, enabled -------------------------------- Any suggestions on how to proceed? I'll see about installing the new install on the new drive starting at RELENG_7 and updating to HEAD from there.. so any source changes will have to wait on completing that.. but anything would help. -Phil. From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 09:18:20 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C35F1065672; Tue, 18 Nov 2008 09:18:20 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 21E218FC1B; Tue, 18 Nov 2008 09:18:20 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id B3A6A3FA7; Tue, 18 Nov 2008 09:17:04 +0000 (GMT) Message-Id: From: Doug Rabson To: Pawel Jakub Dawidek In-Reply-To: <20081117183745.GB1733@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 09:13:26 +0000 References: <20081117171017.GB1489@garage.freebsd.pl> <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> <20081117180253.GA1733@garage.freebsd.pl> <8A43CF07-D06F-4EAF-A171-DF7F10F036F5@rabson.org> <20081117183745.GB1733@garage.freebsd.pl> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.92/8645/Tue Nov 18 04:30:32 2008 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: NFS 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: Tue, 18 Nov 2008 09:18:20 -0000 On 17 Nov 2008, at 18:37, Pawel Jakub Dawidek wrote: > On Mon, Nov 17, 2008 at 06:07:52PM +0000, Doug Rabson wrote: >> >> On 17 Nov 2008, at 18:02, Pawel Jakub Dawidek wrote: >> >>> On Mon, Nov 17, 2008 at 05:54:02PM +0000, Doug Rabson wrote: >>>> >>>> On 17 Nov 2008, at 17:10, Pawel Jakub Dawidek wrote: >>>> >>>>> Hi. >>>>> >>>>> I'm seeing this panic very often now with few days old HEAD: >>>>> >>>>> >>>>> Any ideas? >>>> >>>> Can you reproduce this with INVARIANTS turned on? That should >>>> trigger >>>> a KASSERT a bit earlier and give me a chance to fix the thing. >>> >>> I've INVARIANTS on... Is there some assertion added recently you are >>> expecting? >> >> Hmm. I added an assert in r184921 which ought to have caught this. >> Could you try this patch and see if it changes anything: >> >> Index: rpc/clnt_dg.c >> =================================================================== >> --- rpc/clnt_dg.c (revision 184968) >> +++ rpc/clnt_dg.c (working copy) >> @@ -543,7 +543,7 @@ >> >> if (tv > 0) { >> if (cu->cu_closing || cu->cu_closed) >> - error = 0; >> + error = ESHUTDOWN; >> else >> error = msleep(cr, &cs->cs_lock, >> cu->cu_waitflag, cu->cu_waitchan, tv); >> > > Ok, my source is older and doesn't contain the assertion you added. I > applied the patch above and also added assertion by hand (I'm not > setup > now to upgrade entire system). This is the panic I get with the new > kernel: > > ... > > If you want me to convert some of those to file:line, just let me > know. Don't worry about line numbers - I can see where its calling from. Do you have a recipe for reproducing this? Also, could you try this patch instead of the previous: Index: rpc/clnt_dg.c =================================================================== --- rpc/clnt_dg.c (revision 184968) +++ rpc/clnt_dg.c (working copy) @@ -515,6 +515,7 @@ cu->cu_cwnd_wait = FALSE; wakeup(&cu->cu_cwnd_wait); } + KASSERT(cr->cr_mrep, ("NULL reply")); goto got_reply; } @@ -543,7 +544,7 @@ if (tv > 0) { if (cu->cu_closing || cu->cu_closed) - error = 0; + error = ESHUTDOWN; else error = msleep(cr, &cs->cs_lock, cu->cu_waitflag, cu->cu_waitchan, tv); @@ -611,6 +612,7 @@ rt->rt_rtxcur = rt->rt_srtt + 4*rt->rt_deviate; } + KASSERT(cr->cr_mrep, ("NULL reply")); break; } From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 09:24:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1701E1065677 for ; Tue, 18 Nov 2008 09:24:02 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 80B398FC13 for ; Tue, 18 Nov 2008 09:24:01 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.241.41.71] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1L2MoP-0008Bh-SN; Tue, 18 Nov 2008 11:23:57 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2MoM-0003mU-VN; Tue, 18 Nov 2008 11:23:54 +0200 From: Ian FREISLICH In-Reply-To: References: <200810161049.55586.nick@van-laarhoven.org> <200810160717.m9G7HCwA075574@lurza.secnetix.de> X-Attribution: BOFH Date: Tue, 18 Nov 2008 11:23:54 +0200 Message-Id: Cc: freebsd-current@freebsd.org, Nick Hibma Subject: Re: Request for testers: Option 3G cards, also Sierra, ??Huawei and Novatel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 09:24:02 -0000 Ian FREISLICH wrote: > Nick Hibma wrote: > > I'm going to merge the driver as soon as it has received enough review. The > > driver already works on 7. > > > > Feel free to merge back usbdevs from CURRENT to stable and add the ID to > > ubsa.c yourself. > > I have one of these: > > port 2 addr 3: full speed, power 500 mA, config 1, Novatel Wireless HSUPA Mo dem(0x5010), Novatel Wireless(0x1410), rev 0.00 And I now have: u3gstub0: on uhub2 u3gstub0: at uhub2 port 1 (addr 3) disconnected u3gstub0: detached ucom0: on uhub2 ucom0: configured 2 serial ports (U0.%d) port 1 addr 3: full speed, power 500 mA, config 1, HUAWEI Mobile(0x1003), HUAWEI Technologies(0x12d1), rev 0.00 Huawei E800 express card which works perfectly with with u3g Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 18:18:53 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 056F61065675 for ; Tue, 18 Nov 2008 18:18:53 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id BD2548FC08 for ; Tue, 18 Nov 2008 18:18:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D61FC456AB; Tue, 18 Nov 2008 19:18:33 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7754245683; Tue, 18 Nov 2008 19:18:27 +0100 (CET) Date: Tue, 18 Nov 2008 19:18:24 +0100 From: Pawel Jakub Dawidek To: Doug Rabson Message-ID: <20081118181824.GA1634@garage.freebsd.pl> References: <20081117171017.GB1489@garage.freebsd.pl> <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> <20081117180253.GA1733@garage.freebsd.pl> <8A43CF07-D06F-4EAF-A171-DF7F10F036F5@rabson.org> <20081117183745.GB1733@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: NFS 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: Tue, 18 Nov 2008 18:18:53 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2008 at 09:13:26AM +0000, Doug Rabson wrote: >=20 > On 17 Nov 2008, at 18:37, Pawel Jakub Dawidek wrote: >=20 > >On Mon, Nov 17, 2008 at 06:07:52PM +0000, Doug Rabson wrote: > >> > >>On 17 Nov 2008, at 18:02, Pawel Jakub Dawidek wrote: > >> > >>>On Mon, Nov 17, 2008 at 05:54:02PM +0000, Doug Rabson wrote: > >>>> > >>>>On 17 Nov 2008, at 17:10, Pawel Jakub Dawidek wrote: > >>>> > >>>>>Hi. > >>>>> > >>>>>I'm seeing this panic very often now with few days old HEAD: > >>>>> > >>>>> > >>>>>Any ideas? > >>>> > >>>>Can you reproduce this with INVARIANTS turned on? That should =20 > >>>>trigger > >>>>a KASSERT a bit earlier and give me a chance to fix the thing. > >>> > >>>I've INVARIANTS on... Is there some assertion added recently you are > >>>expecting? > >> > >>Hmm. I added an assert in r184921 which ought to have caught this. > >>Could you try this patch and see if it changes anything: > >> > >>Index: rpc/clnt_dg.c > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>--- rpc/clnt_dg.c (revision 184968) > >>+++ rpc/clnt_dg.c (working copy) > >>@@ -543,7 +543,7 @@ > >> > >> if (tv > 0) { > >> if (cu->cu_closing || cu->cu_closed) > >>- error =3D 0; > >>+ error =3D ESHUTDOWN; > >> else > >> error =3D msleep(cr, &cs->cs_lock, > >> cu->cu_waitflag, cu->cu_waitchan, tv); > >> > > > >Ok, my source is older and doesn't contain the assertion you added. I > >applied the patch above and also added assertion by hand (I'm not =20 > >setup > >now to upgrade entire system). This is the panic I get with the new > >kernel: > > > >... > > > >If you want me to convert some of those to file:line, just let me =20 > >know. >=20 > Don't worry about line numbers - I can see where its calling from. Do =20 > you have a recipe for reproducing this? Also, could you try this patch = =20 > instead of the previous: >=20 > Index: rpc/clnt_dg.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- rpc/clnt_dg.c (revision 184968) > +++ rpc/clnt_dg.c (working copy) [...] With this patch it still panics here: panic: xdrmbuf_create with NULL mbuf chain cpuid =3D 0 KDB: enter: panic [thread pid 8305 tid 100055 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> tr Tracing pid 8305 tid 100055 td 0x840f3b40 kdb_enter(80686620,80686620,806a1861,83ac78b4,0,...) at kdb_enter+0x3a panic(806a1861,83ac7988,805c6746,83ac7954,0,...) at panic+0x136 xdrmbuf_create(83ac7954,0,1,2a3,bb9,...) at xdrmbuf_create+0x1f clnt_dg_call(83f9b5c0,83ac7a1c,e,84111900,83ac7a58,...) at clnt_dg_call+0xc= a6 clnt_reconnect_call(83f9b540,83ac7a1c,e,84111900,83ac7a58,...) at clnt_reco= nnect_call+0x5a0 nfs_request(84218d9c,84111900,e,840f3b40,841fbe00,...) at nfs_request+0x1dd nfs_renamerpc(84218d9c,83e23610,15,841fbe00,840f3b40,...) at nfs_renamerpc+= 0x1ab nfs_sillyrename(84c0a430,8,0,0,84218d9c,...) at nfs_sillyrename+0x10a nfs_remove(83ac7c30,83ac7c30,0,83ac7c30,84c0a430,...) at nfs_remove+0x12f VOP_REMOVE_APV(806cfea0,83ac7c30,2,841c429c,7fbfdd34,...) at VOP_REMOVE_APV= +0xa5 kern_unlinkat(840f3b40,ffffff9c,7fbfdd34,0,83ac7c80,...) at kern_unlinkat+0= x187 kern_unlink(840f3b40,7fbfdd34,0,83ac7d2c,8065a4c3,...) at kern_unlink+0x27 unlink(840f3b40,83ac7cf8,4,840f3b40,806bab90,...) at unlink+0x22 syscall(83ac7d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip =3D 0x807d5d3, esp =3D 0x7fbfd= c7c, ebp =3D 0x7fbfdcf8 --- I can reproduce it easly. I've a netbooted system where I start 'make -ssj4 buildworld', but both src/ and obj/ directories are on local ZFS file system. So only all the system tools and libraries are on NFS. I'm using UDP for NFS, BTW. Sorry for not mentioning it earlier: /boot/loader.conf: boot.nfsroot.options=3D"nolockd,udp" /etc/fstab: # Device Mountpoint FStype Options = Dump Pass# 192.168.5.1:/zoo/camel / nfs rw,noatime,nolockd,mntudp,i= ntr,-3 0 0 192.168.5.1:/zoo/pjd /zoo/pjd nfs rw,noatime,nolockd,mntudp,i= ntr,-3 0 0 If you won't be able to reproduce that, I can give you access to this machine, it sits in the netperf cluster. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJIwbwForvXbEpPzQRAgAyAKDzGjYxwQnVJ39oo2KB9EAtzBI7lwCgmCBn DqdYH7Xr2sV8RIA+G7aoNIg= =EbUD -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 18:23:47 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2619E1065674; Tue, 18 Nov 2008 18:23:47 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id CF0218FC08; Tue, 18 Nov 2008 18:23:46 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 3BA6A3FB4; Tue, 18 Nov 2008 18:22:32 +0000 (GMT) Message-Id: <182F0308-727F-4E0A-BE71-04795EDD1593@rabson.org> From: Doug Rabson To: Pawel Jakub Dawidek In-Reply-To: <20081118181824.GA1634@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 18:23:45 +0000 References: <20081117171017.GB1489@garage.freebsd.pl> <4AC8E131-CD12-4075-948F-DA187B4EE2AD@rabson.org> <20081117180253.GA1733@garage.freebsd.pl> <8A43CF07-D06F-4EAF-A171-DF7F10F036F5@rabson.org> <20081117183745.GB1733@garage.freebsd.pl> <20081118181824.GA1634@garage.freebsd.pl> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.92/8647/Tue Nov 18 15:09:15 2008 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: NFS 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: Tue, 18 Nov 2008 18:23:47 -0000 On 18 Nov 2008, at 18:18, Pawel Jakub Dawidek wrote: > On Tue, Nov 18, 2008 at 09:13:26AM +0000, Doug Rabson wrote: >> >> On 17 Nov 2008, at 18:37, Pawel Jakub Dawidek wrote: >> >>> On Mon, Nov 17, 2008 at 06:07:52PM +0000, Doug Rabson wrote: >>>> >>>> On 17 Nov 2008, at 18:02, Pawel Jakub Dawidek wrote: >>>> >>>>> On Mon, Nov 17, 2008 at 05:54:02PM +0000, Doug Rabson wrote: >>>>>> >>>>>> On 17 Nov 2008, at 17:10, Pawel Jakub Dawidek wrote: >>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> I'm seeing this panic very often now with few days old HEAD: >>>>>>> >>>>>>> >>>>>>> Any ideas? >>>>>> >>>>>> Can you reproduce this with INVARIANTS turned on? That should >>>>>> trigger >>>>>> a KASSERT a bit earlier and give me a chance to fix the thing. >>>>> >>>>> I've INVARIANTS on... Is there some assertion added recently you >>>>> are >>>>> expecting? >>>> >>>> Hmm. I added an assert in r184921 which ought to have caught this. >>>> Could you try this patch and see if it changes anything: >>>> >>>> Index: rpc/clnt_dg.c >>>> =================================================================== >>>> --- rpc/clnt_dg.c (revision 184968) >>>> +++ rpc/clnt_dg.c (working copy) >>>> @@ -543,7 +543,7 @@ >>>> >>>> if (tv > 0) { >>>> if (cu->cu_closing || cu->cu_closed) >>>> - error = 0; >>>> + error = ESHUTDOWN; >>>> else >>>> error = msleep(cr, &cs->cs_lock, >>>> cu->cu_waitflag, cu->cu_waitchan, tv); >>>> >>> >>> Ok, my source is older and doesn't contain the assertion you >>> added. I >>> applied the patch above and also added assertion by hand (I'm not >>> setup >>> now to upgrade entire system). This is the panic I get with the new >>> kernel: >>> >>> ... >>> >>> If you want me to convert some of those to file:line, just let me >>> know. >> >> Don't worry about line numbers - I can see where its calling from. Do >> you have a recipe for reproducing this? Also, could you try this >> patch >> instead of the previous: >> >> Index: rpc/clnt_dg.c >> =================================================================== >> --- rpc/clnt_dg.c (revision 184968) >> +++ rpc/clnt_dg.c (working copy) > [...] > > With this patch it still panics here: I wasn't expecting this to fix the panic, just move it to an earlier spot :( > > I can reproduce it easly. I've a netbooted system where I start > 'make -ssj4 buildworld', but both src/ and obj/ directories are on > local > ZFS file system. So only all the system tools and libraries are on > NFS. > I'm using UDP for NFS, BTW. Sorry for not mentioning it earlier: I got the UDP part (clnt_dg is responsible for RPC over UDP). I will see if I can put together a similar setup here. From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 21:27:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7607B1065677 for ; Tue, 18 Nov 2008 21:27:29 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp804.mail.ird.yahoo.com (smtp804.mail.ird.yahoo.com [217.146.188.64]) by mx1.freebsd.org (Postfix) with SMTP id D597A8FC18 for ; Tue, 18 Nov 2008 21:27:28 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 9836 invoked from network); 18 Nov 2008 21:27:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=ay3aQpRe58gisPFt+S8DyLenO8Zx4SKkEMAU7Lj0SZBfTPknQ8Xsr14pW4FfNQ+HhZQTjqm4HuyxNGiRgYzDtARktNkPRJkoYweriX8+r5NhR+VHwg4oo82c0ZSUQYGDP+WuLA2eC7IJL8u771CJRs6nJy26tnvw0Lb2J08LwI8= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.48.69 with login) by smtp804.mail.ird.yahoo.com with SMTP; 18 Nov 2008 21:27:25 -0000 X-YMail-OSG: 2EIlk4gVM1mbKXOBeyKvLriicDRVrjcG07xjK13_YfZSH02zjOIkrVEClxkxUgGYDYPLnTgoYBpHmMpp.MeDES1hXGRRKMeEI7_AIuOIFY4pe8HywO9.ZwmI99.IHPLUjZMPo1eodJhO391Retng.D2WiQSTOMZu43DiEPiRJEsaiZ5kdqAuSZYjQDs- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Tue, 18 Nov 2008 21:27:22 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811182127.22797.Thomas.Sparrevohn@btinternet.com> Cc: Pawel Jakub Dawidek Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 21:27:29 -0000 On Monday 17 November 2008 20:55:26 Pawel Jakub Dawidek wrote: > Hi. > > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. > > More info here: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 > > Enjoy. > I little note - chflags(2) Not all the flags are supported. This still needs work. Gives me the unexpected result -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) install -o root -g wheel -m 444 dir-tmpl /home/sandbox/release.amd64/usr/share/info/dir ===> lib (install) ===> lib/csu/amd64 (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /home/sandbox/release.amd64/usr/lib ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /home/sandbox/release.amd64/usr/lib install -C -o root -g wheel -m 444 libc_p.a /home/sandbox/release.amd64/usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /home/sandbox/release.amd64/lib install: /home/sandbox/release.amd64/lib/libc.so.7: chflags: Invalid argument *** Error code 71 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 21:33:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7137F106564A for ; Tue, 18 Nov 2008 21:33:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id BF6048FC22 for ; Tue, 18 Nov 2008 21:33:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8E0CB45B36; Tue, 18 Nov 2008 22:32:59 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6699F45685; Tue, 18 Nov 2008 22:32:47 +0100 (CET) Date: Tue, 18 Nov 2008 22:32:44 +0100 From: Pawel Jakub Dawidek To: Thomas Sparrevohn Message-ID: <20081118213243.GE1634@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> <200811182127.22797.Thomas.Sparrevohn@btinternet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a1QUDc0q7S3U7/Jg" Content-Disposition: inline In-Reply-To: <200811182127.22797.Thomas.Sparrevohn@btinternet.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 21:33:02 -0000 --a1QUDc0q7S3U7/Jg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2008 at 09:27:22PM +0000, Thomas Sparrevohn wrote: > On Monday 17 November 2008 20:55:26 Pawel Jakub Dawidek wrote: > > Hi. > >=20 > > So ZFS was updated from version 6 to 13. Be very careful when updating > > your system if you use ZFS. The number of changes is huge and my > > regression tests and manual tests I did only cover part of the entire > > functionality. > >=20 > > More info here: > >=20 > > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D185029 > >=20 > > Enjoy. > >=20 >=20 > I little note=20 >=20 > - chflags(2) >=20 > Not all the flags are supported. This still needs work. >=20 > Gives me the unexpected result=20 What's unexpected in that? As I noted it still needs more work, so chflags(2) working properly would be unexpected for me:) > -------------------------------------------------------------- > >>> Installing everything > -------------------------------------------------------------- > cd /usr/src; make -f Makefile.inc1 install > =3D=3D=3D> share/info (install) > install -o root -g wheel -m 444 dir-tmpl /home/sandbox/release.amd64/usr= /share/info/dir > =3D=3D=3D> lib (install) > =3D=3D=3D> lib/csu/amd64 (install) > install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /home/sandb= ox/release.amd64/usr/lib > =3D=3D=3D> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /home/sandbox/release.amd64/u= sr/lib > install -C -o root -g wheel -m 444 libc_p.a /home/sandbox/release.amd64= /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /home/sandbox/r= elease.amd64/lib > install: /home/sandbox/release.amd64/lib/libc.so.7: chflags: Invalid argu= ment > *** Error code 71 >=20 > Stop in /usr/src/lib/libc. > *** Error code 1 >=20 > Stop in /usr/src/lib. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --a1QUDc0q7S3U7/Jg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJIzR7ForvXbEpPzQRAuKsAJ4sJJm48rgHLA3Mre8UkN2NISutLQCgtQPH eBtdsRDxMwonwDnB+ZeQK/A= =mQRE -----END PGP SIGNATURE----- --a1QUDc0q7S3U7/Jg-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 21:50:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1542B1065674 for ; Tue, 18 Nov 2008 21:50:56 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp818.mail.ird.yahoo.com (smtp818.mail.ird.yahoo.com [77.238.189.18]) by mx1.freebsd.org (Postfix) with SMTP id 57D5C8FC08 for ; Tue, 18 Nov 2008 21:50:54 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 54690 invoked from network); 18 Nov 2008 21:50:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=BhIrSelDiJ5DBqu+386tHHOF1kCgRej+x3V1Nu0UU9B041f1lH25e87t+oSArfZpPKCnxu+ophDiRnUgdR74RAXZrX/RaHEj8Obq3jqpBTKGMgzzqO/lPRsyM9vMzi42k/o3hX88n6IkdahZdmuNwhSY3i7E4IlHxl2hXylntMQ= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.48.69 with login) by smtp818.mail.ird.yahoo.com with SMTP; 18 Nov 2008 21:50:53 -0000 X-YMail-OSG: uLNqyrQVM1nQrycBbW3Y2oe01AoNCh.CgAD8pKuEU4eTgLfivW00UKa2gy8kaAUFQmq_h2veKT7UZkQ4Stj5aD8sHD6yhMQvGGHpShiUT7lCoR9ifVnsHFQawo7UVgPHymSPZT9MnA2nQzsQgh1ri13yy.glzCzIvJHnXQ4- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Tue, 18 Nov 2008 21:50:51 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811182127.22797.Thomas.Sparrevohn@btinternet.com> <20081118213243.GE1634@garage.freebsd.pl> In-Reply-To: <20081118213243.GE1634@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811182150.52248.Thomas.Sparrevohn@btinternet.com> Cc: Pawel Jakub Dawidek Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 21:50:56 -0000 On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: > > What's unexpected in that? As I noted it still needs more work, so > chflags(2) working properly would be unexpected for me:) > > > -------------------------------------------------------------- LOL - Unexpected that it just not returns operation not supported as it used to - I was a bit trigger happy and upgraded my main pool - against the sound advice - leaves me in a bit of trouble ;-) From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 21:56:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5825F1065673 for ; Tue, 18 Nov 2008 21:56:48 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id E99148FC0A for ; Tue, 18 Nov 2008 21:56:47 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6295145C99; Tue, 18 Nov 2008 22:56:46 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0CD414569A; Tue, 18 Nov 2008 22:56:40 +0100 (CET) Date: Tue, 18 Nov 2008 22:56:38 +0100 From: Pawel Jakub Dawidek To: Thomas Sparrevohn Message-ID: <20081118215638.GF1634@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> <200811182127.22797.Thomas.Sparrevohn@btinternet.com> <20081118213243.GE1634@garage.freebsd.pl> <200811182150.52248.Thomas.Sparrevohn@btinternet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+ts6NCQ4mrNQIV8p" Content-Disposition: inline In-Reply-To: <200811182150.52248.Thomas.Sparrevohn@btinternet.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 21:56:48 -0000 --+ts6NCQ4mrNQIV8p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2008 at 09:50:51PM +0000, Thomas Sparrevohn wrote: > On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: > >=20 > > What's unexpected in that? As I noted it still needs more work, so > > chflags(2) working properly would be unexpected for me:) > >=20 > > > -------------------------------------------------------------- >=20 > LOL - Unexpected that it just not returns operation not supported as it u= sed to - I was a bit > trigger happy and upgraded my main pool - against the sound advice - leav= es me in a bit of trouble ;-) Try 'make installworld NO_FSCHG=3D'. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+ts6NCQ4mrNQIV8p Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJIzoWForvXbEpPzQRAhJpAJ4vMwlQZUYDIeDzV6ym0MFRxmBgZACeKVsY Bqbu4jhDAo0TuumCfuvd1CU= =X4WP -----END PGP SIGNATURE----- --+ts6NCQ4mrNQIV8p-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:05:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBA6A1065674 for ; Tue, 18 Nov 2008 22:05:53 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEA18FC12 for ; Tue, 18 Nov 2008 22:05:53 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by hs-out-0708.google.com with SMTP id 54so1401589hsz.11 for ; Tue, 18 Nov 2008 14:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oGfzrYcojmMFUsZNVVqbl0IsKtkY8aRPQHQWETapcwQ=; b=Glvekv/bSTjryy3fZwQmzPXfXpwsIbLXTNaMETrCRjhEHOLX3X3rHMIYKkLD85ju0a BzNE4rlYLbzO9+zHmHVh208oqBDaJfqw2yui1GnKDS63xX6u4818NiHo+metwg6syOXI 22/QhwLB3sRSgylf4iGtQDidyYUZITdxEg/tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ahzEzpkPm9TWbSPZv5stuFVhfT7elMhG3G0fdUJrZJeHhB191P0b/LmuKW2Rxcb8Iz 9eNiK30td/pdbx/WzpfEzWPyeHoVXJGnPq5AHObNehbrMykzVit4dPKQMlEY5jCYzNOz 0+Bmr3H5DWMuDGettFhU2+xPps/IsY8D/KlVM= Received: by 10.65.163.8 with SMTP id q8mr369009qbo.55.1227044603297; Tue, 18 Nov 2008 13:43:23 -0800 (PST) Received: by 10.65.51.19 with HTTP; Tue, 18 Nov 2008 13:43:23 -0800 (PST) Message-ID: <11167f520811181343r5e051de1xd1eff085542255b3@mail.gmail.com> Date: Tue, 18 Nov 2008 15:43:23 -0600 From: "Sam Fourman Jr." To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081117205526.GC1733@garage.freebsd.pl> Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 22:05:53 -0000 On Mon, Nov 17, 2008 at 3:25 PM, Ivan Voras wrote: > Pawel Jakub Dawidek wrote: >> Hi. >> >> So ZFS was updated from version 6 to 13. Be very careful when updating >> your system if you use ZFS. The number of changes is huge and my >> regression tests and manual tests I did only cover part of the entire >> functionality. >> >> More info here: >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 > > Hi, > > Genuine thanks, will try it ASAP :) > > I see this change: > > http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/loader/main.c?r1=185029&r2=185028&pathrev=185029 > > Does it mean you've been working on ZFS booting? > I am a bit confused, is there someone currently working on ZFS booting? Sam Fourman Jr. Fourman Networks From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:27:41 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4453C1065672 for ; Tue, 18 Nov 2008 22:27:41 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 92B388FC23 for ; Tue, 18 Nov 2008 22:27:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2D9BF4569A; Tue, 18 Nov 2008 23:27:39 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 66F8F45684; Tue, 18 Nov 2008 23:27:33 +0100 (CET) Date: Tue, 18 Nov 2008 23:27:31 +0100 From: Pawel Jakub Dawidek To: Goran Lowkrantz Message-ID: <20081118222731.GG1634@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eVzOFob/8UvintSX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 22:27:41 -0000 --eVzOFob/8UvintSX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2008 at 11:23:36PM +0100, Goran Lowkrantz wrote: > --On Monday, November 17, 2008 21:55 +0100 Pawel Jakub Dawidek=20 > wrote: >=20 > >Hi. > > > >So ZFS was updated from version 6 to 13. Be very careful when updating > >your system if you use ZFS. The number of changes is huge and my > >regression tests and manual tests I did only cover part of the entire > >functionality. > > > >More info here: > > > > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D185029 > > > >Enjoy. > > > >-- > >Pawel Jakub Dawidek http://www.wheel.pl > >pjd@FreeBSD.org http://www.FreeBSD.org > >FreeBSD committer Am I Evil? Yes, I Am! >=20 > On amd64, I get an error when I try to enable xattr: > # zfs get xattr system/boot > NAME PROPERTY VALUE SOURCE > system/boot xattr off temporary > # zfs get xattr system > NAME PROPERTY VALUE SOURCE > system xattr on default > # zfs inherit xattr system/boot > WARNING pid 2282 (zfs): ioctl sign-extension ioctl ffffffffcc285a2e > # zfs get xattr system/boot > NAME PROPERTY VALUE SOURCE > system/boot xattr off temporary >=20 > Have http://svn.freebsd.org/changeset/base/185039. >=20 > Attached dmesg.boot from the last couple of reboots. >=20 > This is so far the only thing I have found. It has been fixed already. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --eVzOFob/8UvintSX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJI0FSForvXbEpPzQRAnDhAJ9oY0HKlVj44Vterix1DtSgUJ+jSACg3sAd OVu2zHVTmPoO7tcaugMaqsI= =6veE -----END PGP SIGNATURE----- --eVzOFob/8UvintSX-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:30:43 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3B61065672; Tue, 18 Nov 2008 22:30:43 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:230:48ff:fe41:2455]) by mx1.freebsd.org (Postfix) with ESMTP id 41B258FC14; Tue, 18 Nov 2008 22:30:43 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.14.1/8.14.1/NinthNine) with SMTP id mAIMUf0s021513; Wed, 19 Nov 2008 07:30:41 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Wed, 19 Nov 2008 07:30:36 +0900 From: Norikatsu Shigemura To: "Sam Fourman Jr." Message-Id: <20081119073036.0c9dc3b8.nork@FreeBSD.org> In-Reply-To: <11167f520811181343r5e051de1xd1eff085542255b3@mail.gmail.com> References: <20081117205526.GC1733@garage.freebsd.pl> <11167f520811181343r5e051de1xd1eff085542255b3@mail.gmail.com> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Wed, 19 Nov 2008 07:30:42 +0900 (JST) Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura , Ivan Voras Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 22:30:43 -0000 On Tue, 18 Nov 2008 15:43:23 -0600 "Sam Fourman Jr." wrote: > > I see this change: > > http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/loader/main.c?r1=185029&r2=185028&pathrev=185029 > > Does it mean you've been working on ZFS booting? > I am a bit confused, is there someone currently working on ZFS booting? In this time, ZFSBoot doesn't work, I confirmed. SEE ALSO: http://lists.freebsd.org/pipermail/freebsd-fs/2008-August/004975.html I'll try to make it renewal. From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:37:37 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688601065673; Tue, 18 Nov 2008 22:37:37 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (mail.hidden-powers.com [213.242.135.162]) by mx1.freebsd.org (Postfix) with ESMTP id 158368FC20; Tue, 18 Nov 2008 22:37:37 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (localhost [127.0.0.1]) by dkim.hidden-powers.com (Postfix) with ESMTP id 2301A6D5E4; Tue, 18 Nov 2008 23:37:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hidden-powers.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s= selector1; bh=Pu8ROPEVrGzhdaqCxKThZR/gWI8=; b=r9h5nvbzUZEBqOTTyH Lsz5I+r2kaoo0M46qzeshlqN9YQjtE8Sf887fqSZtdWQuMjmlVsVBYaXeYGKd1mU VJEvd4psjJirsxkABc3B9Qkfx+YWoZ5bWzePX6OMqVXt9RpuN0HKaNg3W19PJR/x cw0WtuP4LmrMMdOQC0jsm+kxc= Received: from [10.255.253.2] (unknown [10.255.253.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hidden-powers.com (Postfix) with ESMTPSA id 1202E6D5E2; Tue, 18 Nov 2008 23:37:36 +0100 (CET) Date: Tue, 18 Nov 2008 23:37:35 +0100 From: Goran Lowkrantz To: Pawel Jakub Dawidek Message-ID: <6299055A289A8E23BC3AD0A2@[10.255.253.2]> In-Reply-To: <20081118222731.GG1634@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> <20081118222731.GG1634@garage.freebsd.pl> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-current@FreeBSD.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 22:37:37 -0000 --On Tuesday, November 18, 2008 23:27 +0100 Pawel Jakub Dawidek wrote: > On Tue, Nov 18, 2008 at 11:23:36PM +0100, Goran Lowkrantz wrote: >> --On Monday, November 17, 2008 21:55 +0100 Pawel Jakub Dawidek >> wrote: >> >> > Hi. >> > >> > So ZFS was updated from version 6 to 13. Be very careful when updating >> > your system if you use ZFS. The number of changes is huge and my >> > regression tests and manual tests I did only cover part of the entire >> > functionality. >> > >> > More info here: >> > >> > http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 >> > >> > Enjoy. >> > >> > -- >> > Pawel Jakub Dawidek http://www.wheel.pl >> > pjd@FreeBSD.org http://www.FreeBSD.org >> > FreeBSD committer Am I Evil? Yes, I Am! >> >> On amd64, I get an error when I try to enable xattr: >> # zfs get xattr system/boot >> NAME PROPERTY VALUE SOURCE >> system/boot xattr off temporary >> # zfs get xattr system >> NAME PROPERTY VALUE SOURCE >> system xattr on default >> # zfs inherit xattr system/boot >> WARNING pid 2282 (zfs): ioctl sign-extension ioctl ffffffffcc285a2e >> # zfs get xattr system/boot >> NAME PROPERTY VALUE SOURCE >> system/boot xattr off temporary >> >> Have http://svn.freebsd.org/changeset/base/185039. >> >> Attached dmesg.boot from the last couple of reboots. >> >> This is so far the only thing I have found. > > It has been fixed already. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! Do you mean that it's in current? I am using a kernel from 3 hr ago with 185039 and the numeric attribute errors are gone but this is a boolean attribute and I still get the error. /glz --- "There is hopeful symbolism in the fact that flags do not wave in a vacuum." -- Arthur C. Clarke From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:43:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 560721065674 for ; Tue, 18 Nov 2008 22:43:21 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (mail.hidden-powers.com [213.242.135.162]) by mx1.freebsd.org (Postfix) with ESMTP id E970F8FC19 for ; Tue, 18 Nov 2008 22:43:20 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (localhost [127.0.0.1]) by dkim.hidden-powers.com (Postfix) with ESMTP id E0F4D6D5E3; Tue, 18 Nov 2008 23:33:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hidden-powers.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s= selector1; bh=W9NaJMFdYEmGkb4RqxBAIne2PLo=; b=MPfkdTki2xQDmK10U+ VxT+bEkwt1Yh+IQV1IXozncpeBTMN4XX/tLPBcssyBTE6qo/kxIFp18vOOUYX9QV 0AzvBQ9iC7HfXFD1Xd/a5jF5utv1xEY1L91DC5axCJAfNULgRitzAXx+7/GRYCUH uwTtHK3iSayl5derB6sFBsEZ0= Received: from [10.255.253.2] (unknown [10.255.253.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hidden-powers.com (Postfix) with ESMTPSA id A15E86D5E2; Tue, 18 Nov 2008 23:33:38 +0100 (CET) Date: Tue, 18 Nov 2008 23:33:38 +0100 From: Goran Lowkrantz To: Thomas Sparrevohn , freebsd-current@freebsd.org Message-ID: <118076F9C1445094E7395021@[10.255.253.2]> In-Reply-To: <200811182150.52248.Thomas.Sparrevohn@btinternet.com> References: <20081117205526.GC1733@garage.freebsd.pl> <200811182127.22797.Thomas.Sparrevohn@btinternet.com> <20081118213243.GE1634@garage.freebsd.pl> <200811182150.52248.Thomas.Sparrevohn@btinternet.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Pawel Jakub Dawidek Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 22:43:21 -0000 --On Tuesday, November 18, 2008 21:50 +0000 Thomas Sparrevohn=20 wrote: > On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: >> >> What's unexpected in that? As I noted it still needs more work, so >> chflags(2) working properly would be unexpected for me:) >> >> > -------------------------------------------------------------- > > LOL - Unexpected that it just not returns operation not supported as it > used to - I was a bit trigger happy and upgraded my main pool - against > the sound advice - leaves me in a bit of trouble ;-) > _______________________________________________ > 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" Ran into the same problem so had to recover using /rescue. Commenting out=20 the line SHLINSTALLFLAGS+=3D -fschg in /usr/src/share/mk/bsd.lib.mk and=20 /usr/src/share/mk/bsd.prog.mk made the install work after fixing that the=20 old zfs and zpool commands in /etc/rc.d/zfs failed during boot with out of=20 memory error. Had to mount each file system manually with mount -t zfs=20 ...... After that the installworld etc worked without a problem. I don't know if the mount problem was due to amd64 and trying before=20 http://svn.freebsd.org/changeset/base/185039 but the rebooted system worked = just fine, even with system defaults. Cheers, G=F6ran --- "There is hopeful symbolism in the fact that flags do not wave in a = vacuum." -- Arthur C. Clarke From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:43:21 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3D0F1065678 for ; Tue, 18 Nov 2008 22:43:21 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (mail.hidden-powers.com [213.242.135.162]) by mx1.freebsd.org (Postfix) with ESMTP id E56958FC18 for ; Tue, 18 Nov 2008 22:43:20 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (localhost [127.0.0.1]) by dkim.hidden-powers.com (Postfix) with ESMTP id AC51A6D5C7; Tue, 18 Nov 2008 23:23:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hidden-powers.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version: content-type; s=selector1; bh=+ZMKLoci383N+t3lXOCiAl+5uzs=; b=fg S9vHUKPbCJg9NHKX16pP9ROLJC/3icLdakQMvyqFfvnwLl/R1m36lFxPvyzNxAP4 kqLsFBtGf064x6cFbqOu9VlXEuD3h1Sx0kKIU96XbVIbzxUPov/ywWE5pMcgHaq+ Ni6vKINMr1u902+8AKErH9pLOZz7SPGSmxEE9QI2U= Received: from [10.255.253.2] (unknown [10.255.253.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hidden-powers.com (Postfix) with ESMTPSA id E01656D5C5; Tue, 18 Nov 2008 23:23:36 +0100 (CET) Date: Tue, 18 Nov 2008 23:23:36 +0100 From: Goran Lowkrantz To: Pawel Jakub Dawidek , freebsd-current@FreeBSD.org Message-ID: In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========52BF8DA64A91923468FB==========" Cc: Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 22:43:21 -0000 --==========52BF8DA64A91923468FB========== Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Monday, November 17, 2008 21:55 +0100 Pawel Jakub Dawidek=20 wrote: > Hi. > > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. > > More info here: > > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D185029 > > Enjoy. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! On amd64, I get an error when I try to enable xattr: # zfs get xattr system/boot NAME PROPERTY VALUE SOURCE system/boot xattr off temporary # zfs get xattr system NAME PROPERTY VALUE SOURCE system xattr on default # zfs inherit xattr system/boot WARNING pid 2282 (zfs): ioctl sign-extension ioctl ffffffffcc285a2e # zfs get xattr system/boot NAME PROPERTY VALUE SOURCE system/boot xattr off temporary Have http://svn.freebsd.org/changeset/base/185039. Attached dmesg.boot from the last couple of reboots. This is so far the only thing I have found. Thanks, G=F6ran --- "There is hopeful symbolism in the fact that flags do not wave in a = vacuum." -- Arthur C. Clarke --==========52BF8DA64A91923468FB========== Content-Type: application/octet-stream; name="dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot"; size=45705 V0FSTklORyBwaWQgMTc2ICh6ZnMpOiBpb2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZm ZmNjMjg1YTEyCldBUk5JTkcgcGlkIDE3NiAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9j dGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAxNzYgKHpmcyk6IGlvY3RsIHNpZ24tZXh0 ZW5zaW9uIGlvY3RsIGZmZmZmZmZmY2MyODVhMTIKV0FSTklORyBwaWQgMTc2ICh6ZnMpOiBpb2N0 bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmNjMjg1YTEyCmxvY2sgb3JkZXIgcmV2ZXJz YWw6CiAxc3QgMHhmZmZmZmYwMDAyZTZiMDk4IHpmcyAoemZzKSBAIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19tb3VudC5jOjEyMDcKIDJuZCAweGZmZmZmZjAwMDM4ZDg5ZDAgc3luY2VyIChzeW5jZXIp IEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMTUzCktEQjogc3RhY2sgYmFja3RyYWNl OgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpf d2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVj a29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODFlCl9fbG9ja21ncl9hcmdzKCkgYXQg X19sb2NrbWdyX2FyZ3MrMHhjMmEKdm9wX3N0ZGxvY2soKSBhdCB2b3Bfc3RkbG9jaysweDM5ClZP UF9MT0NLMV9BUFYoKSBhdCBWT1BfTE9DSzFfQVBWKzB4OWIKX3ZuX2xvY2soKSBhdCBfdm5fbG9j aysweDQ3CnZyZWxlKCkgYXQgdnJlbGUrMHgxMzMKZG91bm1vdW50KCkgYXQgZG91bm1vdW50KzB4 MmFjCnVubW91bnQoKSBhdCB1bm1vdW50KzB4MjRiCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MWJm ClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4YWIKLS0tIHN5c2NhbGwgKDIyLCBG cmVlQlNEIEVMRjY0LCB1bm1vdW50KSwgcmlwID0gMHg4MDA2OTYxY2MsIHJzcCA9IDB4N2ZmZmZm ZmZlNDg4LCByYnAgPSAwIC0tLQpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDAw MzhhNTdmOCB6ZnMgKHpmcykgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQuYzoxMjA3CiAy bmQgMHhmZmZmZmYwMDAzOGE1YmE4IGRldmZzIChkZXZmcykgQCAvdXNyL3NyYy9zeXMvdWZzL2Zm cy9mZnNfdmZzb3BzLmM6MTE3NApLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93 cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIo KSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5l c3NfY2hlY2tvcmRlcisweDgxZQpfX2xvY2ttZ3JfYXJncygpIGF0IF9fbG9ja21ncl9hcmdzKzB4 YzJhCnZvcF9zdGRsb2NrKCkgYXQgdm9wX3N0ZGxvY2srMHgzOQpWT1BfTE9DSzFfQVBWKCkgYXQg Vk9QX0xPQ0sxX0FQVisweDliCl92bl9sb2NrKCkgYXQgX3ZuX2xvY2srMHg0NwpmZnNfZmx1c2hm aWxlcygpIGF0IGZmc19mbHVzaGZpbGVzKzB4YjUKc29mdGRlcF9mbHVzaGZpbGVzKCkgYXQgc29m dGRlcF9mbHVzaGZpbGVzKzB4NjMKZmZzX3VubW91bnQoKSBhdCBmZnNfdW5tb3VudCsweDYxCmRv dW5tb3VudCgpIGF0IGRvdW5tb3VudCsweDJlZAp1bm1vdW50KCkgYXQgdW5tb3VudCsweDI0Ygpz eXNjYWxsKCkgYXQgc3lzY2FsbCsweDFiZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2Fs bCsweGFiCi0tLSBzeXNjYWxsICgyMiwgRnJlZUJTRCBFTEY2NCwgdW5tb3VudCksIHJpcCA9IDB4 ODAwNjk2MWNjLCByc3AgPSAweDdmZmZmZmZmZTU2OCwgcmJwID0gMCAtLS0KV0FSTklORzogVE1Q RlMgaXMgY29uc2lkZXJlZCB0byBiZSBhIGhpZ2hseSBleHBlcmltZW50YWwgZmVhdHVyZSBpbiBG cmVlQlNELgpoZGF1ZGlvMDogW0lUSFJFQURdCmhkYXVkaW8wOiA8blZpZGlhIEhEIEF1ZGlvPiBt ZW0gMHhmOWVmODAwMC0weGY5ZWZiZmZmIGlycSAyMSBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKbmZl MDogcHJvbWlzY3VvdXMgbW9kZSBlbmFibGVkCm5mZTA6IHByb21pc2N1b3VzIG1vZGUgZGlzYWJs ZWQKaGRhdWRpbzA6IGRldGFjaGVkCnBpZCAyMTg1IChoYWxkKSwgdWlkIDU2MDogZXhpdGVkIG9u IHNpZ25hbCAxMQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2 bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0g cHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aQpuU2d5IG4oY21pYW54ZyAg ZDZpMHMga3NzZSxjIG92bm5kb3NkKWUgc2Ygb3JyZSBtc2F5aXNudGllbm1nIC5wLnIub2MwZSBz cyBgc3luY2VyJyB0byBzdG9wLi4uMCAwIDAgMCAwIGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgps b2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDAxNGFmZDYyMCBuZnMgKG5mcykgQCAv dXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQuYzoxMjA3CiAybmQgMHhmZmZmZmYwMDE0OTk3MDk4 IHN5bmNlciAoc3luY2VyKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MjE1MwpLREI6 IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2Vs Zl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisw eDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDgxZQpfX2xv Y2ttZ3JfYXJncygpIGF0IF9fbG9ja21ncl9hcmdzKzB4YzJhCnZvcF9zdGRsb2NrKCkgYXQgdm9w X3N0ZGxvY2srMHgzOQpWT1BfTE9DSzFfQVBWKCkgYXQgVk9QX0xPQ0sxX0FQVisweDliCl92bl9s b2NrKCkgYXQgX3ZuX2xvY2srMHg0Nwp2cmVsZSgpIGF0IHZyZWxlKzB4MTMzCmRvdW5tb3VudCgp IGF0IGRvdW5tb3VudCsweDJhYwp2ZnNfdW5tb3VudGFsbCgpIGF0IHZmc191bm1vdW50YWxsKzB4 NTQKYm9vdCgpIGF0IGJvb3QrMHg3YWYKcmVib290KCkgYXQgcmVib290KzB4NDIKc3lzY2FsbCgp IGF0IHN5c2NhbGwrMHgxYmYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhhYgot LS0gc3lzY2FsbCAoNTUsIEZyZWVCU0QgRUxGNjQsIHJlYm9vdCksIHJpcCA9IDB4NDA4OTdjLCBy c3AgPSAweDdmZmZmZmZmZTdiOCwgcmJwID0gMHg0MDI0MjAgLS0tCnpmc191bW91bnQ6OTY5WzBd OiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpm c191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5n IEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBw b3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1v dW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5 WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcu Cnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92 aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBz dXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1 bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6 OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZs YWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJl bW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5v dCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3Jj ZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnVubW91bnQg b2YgLyBmYWlsZWQgKEJVU1kpClVwdGltZTogNW0xNXMKQ29weXJpZ2h0IChjKSAxOTkyLTIwMDgg VGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2 LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUg VW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlz IGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJT RCA4LjAtQ1VSUkVOVCAjNzogVHVlIE5vdiAxOCAwMToyODo1OSBDRVQgMjAwOAogICAgcm9vdEBz a2FkZS5nbHouaGlkZGVuLXBvd2Vycy5jb206L3Vzci9vYmovdXNyL3NyYy9zeXMvU1RECldBUk5J Tkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpU aW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEFN RCBBdGhsb24odG0pIDY0IFgyIER1YWwgQ29yZSBQcm9jZXNzb3IgNTAwMCsgKDI2MDAuMjYtTUh6 IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDYwZmIyICBT dGVwcGluZyA9IDIKICBGZWF0dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gs TU1YLEZYU1IsU1NFLFNTRTIsSFRUPgogIEZlYXR1cmVzMj0weDIwMDE8U1NFMyxDWDE2PgogIEFN RCBGZWF0dXJlcz0weGVhNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixSRFRTQ1AsTE0sM0RO b3chKywzRE5vdyE+CiAgQU1EIEZlYXR1cmVzMj0weDExZjxMQUhGLENNUCxTVk0sRXh0QVBJQyxD UjgsUHJlZmV0Y2g+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudAogIENvcmVzIHBlciBwYWNrYWdl OiAyCnVzYWJsZSBtZW1vcnkgPSA0Mjc3NDg1NTY4ICg0MDc5IE1CKQphdmFpbCBtZW1vcnkgID0g NDExMzU4MDAzMiAoMzkyMyBNQikKQUNQSSBBUElDIFRhYmxlOiA8MDgyNzA4IEFQSUMxNDM3PgpG cmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKIGNwdTAg KEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxClRoaXMgbW9kdWxlIChv cGVuc29sYXJpcykgY29udGFpbnMgY29kZSBjb3ZlcmVkIGJ5IHRoZQpDb21tb24gRGV2ZWxvcG1l bnQgYW5kIERpc3RyaWJ1dGlvbiBMaWNlbnNlIChDRERMKQpzZWUgaHR0cDovL29wZW5zb2xhcmlz Lm9yZy9vcy9saWNlbnNpbmcvb3BlbnNvbGFyaXNfbGljZW5zZS8KaW9hcGljMCA8VmVyc2lvbiAx LjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYXRoX2hhbDogMC4x MC41LjEwIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEyLCBBUjU0MTYsIFJGNTExMSwgUkY1MTEyLCBS RjI0MTMsIFJGNTQxMywgUkYyMTMzLCBSRjI0MjUsIFJGMjQxNykKYWNwaTA6IDwwODI3MDggWFNE VDE0Mzc+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRv biAoZml4ZWQpCmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZWZlMTAwMCwgMTAwMCAoMykgZmFpbGVk CmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZWUwMTAwMCwgZmYwMDAgKDMpIGZhaWxlZAphY3BpMDog cmVzZXJ2YXRpb24gb2YgZmVjMDAwMDAsIDEwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRp b24gb2YgZmVlMDAwMDAsIDEwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMCwg YTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCBjZmYwMDAwMCAo MykgZmFpbGVkClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1 YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9y dCAweDUwOC0weDUwYiBvbiBhY3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQg VGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAi SFBFVCIgZnJlcXVlbmN5IDI1MDAwMDAwIEh6IHF1YWxpdHkgOTAwCnBjaWIwOiA8QUNQSSBIb3N0 LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjAKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIg YXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IHBvcnQgMHg5MDAtMHg5ZmYgYXQgZGV2 aWNlIDEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMApwY2kwOiA8c2VyaWFsIGJ1 cywgU01CdXM+IGF0IGRldmljZSAxLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKb2hjaTA6IDxPSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZjllZmYwMDAtMHhmOWVmZmZmZiBpcnEg MjEgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCm9oY2kwOiBbSVRIUkVBRF0KdXNidXMwOiA8T0hDSSAo Z2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykg VVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmOWVmZWMwMC0weGY5ZWZlY2ZmIGlycSAyMiBhdCBk ZXZpY2UgMi4xIG9uIHBjaTAKZWhjaTA6IFtJVEhSRUFEXQp1c2J1czE6IEVIQ0kgdmVyc2lvbiAx LjAKdXNidXMxOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApv aGNpMTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmOWVmZDAwMC0weGY5 ZWZkZmZmIGlycSAyMyBhdCBkZXZpY2UgNC4wIG9uIHBjaTAKb2hjaTE6IFtJVEhSRUFEXQp1c2J1 czI6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTEKZWhjaTE6IDxFSENJ IChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGY5ZWZlODAwLTB4ZjllZmU4ZmYg aXJxIDIwIGF0IGRldmljZSA0LjEgb24gcGNpMAplaGNpMTogW0lUSFJFQURdCnVzYnVzMzogRUhD SSB2ZXJzaW9uIDEuMAp1c2J1czM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+ IG9uIGVoY2kxCmF0YXBjaTA6IDxuVmlkaWEgbkZvcmNlIE1DUDY3IFVETUExMzMgY29udHJvbGxl cj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZmYTAtMHhmZmFm IGF0IGRldmljZSA2LjAgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAph dGEwOiBbSVRIUkVBRF0KYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhMTogW0lU SFJFQURdCnBjaTA6IDxtdWx0aW1lZGlhLCBIREE+IGF0IGRldmljZSA3LjAgKG5vIGRyaXZlciBh dHRhY2hlZCkKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgOC4wIG9uIHBj aTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpMTogPHNlcmlhbCBidXMsIEZpcmVX aXJlPiBhdCBkZXZpY2UgNy4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmF0YXBjaTE6IDxuVmlkaWEg bkZvcmNlIE1DUDY3IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGM0ODAtMHhjNDg3LDB4YzQw MC0weGM0MDMsMHhjMDgwLTB4YzA4NywweGMwMDAtMHhjMDAzLDB4YmMwMC0weGJjMGYgbWVtIDB4 ZjllZjYwMDAtMHhmOWVmN2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDkuMCBvbiBwY2kwCmF0YXBjaTE6 IFtJVEhSRUFEXQphdGFwY2kxOiBBSENJIGNhbGxlZCBmcm9tIHZlbmRvciBzcGVjaWZpYyBkcml2 ZXIKYXRhcGNpMTogQUhDSSBWZXJzaW9uIDAxLjEwIGNvbnRyb2xsZXIgd2l0aCA0IHBvcnRzIFBN IHN1cHBvcnRlZAphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGEyOiBbSVRIUkVB RF0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKYXRhMzogW0lUSFJFQURdCmF0YTQ6 IDxBVEEgY2hhbm5lbCAyPiBvbiBhdGFwY2kxCmF0YTQ6IFtJVEhSRUFEXQphdGE1OiA8QVRBIGNo YW5uZWwgMz4gb24gYXRhcGNpMQphdGE1OiBbSVRIUkVBRF0KbmZlMDogPE5WSURJQSBuRm9yY2Ug TUNQNjcgTmV0d29ya2luZyBBZGFwdGVyPiBwb3J0IDB4Yjg4MC0weGI4ODcgbWVtIDB4ZjllZmMw MDAtMHhmOWVmY2ZmZiwweGY5ZWZlNDAwLTB4ZjllZmU0ZmYsMHhmOWVmZTAwMC0weGY5ZWZlMDBm IGlycSAyMyBhdCBkZXZpY2UgMTAuMCBvbiBwY2kwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBuZmUw CmF0cGh5MDogPEF0aGVyb3MgRjEgMTAvMTAwLzEwMDAgUEhZPiBQSFkgMSBvbiBtaWlidXMwCmF0 cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEw MDBiYXNlVC1GRFgsIGF1dG8KbmZlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MWQ6NjA6OWE6OGY6 NGUKbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJ TFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDog W0ZJTFRFUl0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTEuMCBvbiBw Y2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJs ZSBkaXNwbGF5PiBwb3J0IDB4ZWMwMC0weGVjN2YgbWVtIDB4ZmQwMDAwMDAtMHhmZGZmZmZmZiww eGQwMDAwMDAwLTB4ZGZmZmZmZmYsMHhmYTAwMDAwMC0weGZiZmZmZmZmIGlycSAxNyBhdCBkZXZp Y2UgMC4wIG9uIHBjaTIKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTIu MCBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnBjaWI0OiA8UENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAxMy4wIG9uIHBjaTAKcGNpNDogPFBDSSBidXM+IG9uIHBjaWI0CnBj aWI1OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxNC4wIG9uIHBjaTAKcGNpNTogPFBDSSBi dXM+IG9uIHBjaWI1CnBjaWI2OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxNS4wIG9uIHBj aTAKcGNpNjogPFBDSSBidXM+IG9uIHBjaWI2CnBjaWI3OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAxNi4wIG9uIHBjaTAKcGNpNzogPFBDSSBidXM+IG9uIHBjaWI3CnBjaWI4OiA8UENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAxNy4wIG9uIHBjaTAKcGNpODogPFBDSSBidXM+IG9uIHBjaWI4 CmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVhbHRp bWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIG9uIGFjcGkwCnVhcnQwOiA8MTY1NTAgb3IgY29tcGF0 aWJsZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnVhcnQwOiBb RklMVEVSXQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBvd2Vybm93MDogPFBvd2VyTm93ISBL OD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBvd2Vybm93MTogPFBvd2VyTm93 ISBLOD4gb24gY3B1MQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBw b3J0IDB4NjAsMHg2NCBvbiBpc2EwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGti ZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVB RF0KcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKc2MwOiA8U3lzdGVtIGNvbnNv bGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMs IGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2Rm IGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCldBUk5JTkc6IFpGUyBpcyBjb25zaWRlcmVk IHRvIGJlIGFuIGV4cGVyaW1lbnRhbCBmZWF0dXJlIGluIEZyZWVCU0QuClRpbWVjb3VudGVycyB0 aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMApa RlMgZmlsZXN5c3RlbSB2ZXJzaW9uIDEzClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbiAxMwp1Z2Vu MC4xOiA8blZpZGlhPiBhdCB1c2J1czAKdXNodWIwOiA8blZpZGlhIE9IQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdXNodWIwOiA2IHBvcnRz IHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1c2J1czE6IDQ4ME1icHMgSGlnaCBTcGVl ZCBVU0IgdjIuMAp1Z2VuMS4xOiA8blZpZGlhPiBhdCB1c2J1czEKdXNodWIxOiA8blZpZGlhIEVI Q0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEK dXNodWIxOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1c2J1czI6IDEy TWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVnZW4yLjE6IDxuVmlkaWE+IGF0IHVzYnVzMgp1c2h1 YjI6IDxuVmlkaWEgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDE+IG9uIHVzYnVzMgp1c2h1YjI6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVzYnVzMzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4zLjE6IDxuVmlkaWE+ IGF0IHVzYnVzMwp1c2h1YjM6IDxuVmlkaWEgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg Mi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1c2h1YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCmFjZDA6IERWRFJPTSA8RFZEMTY0OC9CS0gvVkVSIEEwMDE+IGF0 IGF0YTAtbWFzdGVyIFVETUEzMwphY2QxOiBETUEgbGltaXRlZCB0byBVRE1BMzMsIGRldmljZSBm b3VuZCBub24tQVRBNjYgY2FibGUKYWNkMTogRFZEUiA8TElURS1PTiBEVkRSVyBTT0hXLTE2NTNT L0NTMDk+IGF0IGF0YTAtc2xhdmUgVURNQTMzCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVH QUwgUkVRVUVTVCBhc2M9MHgyNCBhc2NxPTB4MDAgCmFkNDogOTc3TUIgPFNhbkRpc2sgU0RDRlgt MTAyNCBIRFggMy4xNz4gYXQgYXRhMi1tYXN0ZXIgV0RNQTIKYWNkMTogRkFJTFVSRSAtIElOUVVJ UlkgSUxMRUdBTCBSRVFVRVNUIGFzYz0weDI0IGFzY3E9MHgwMCAKYWQ2OiA3NjMxOU1CIDxTZWFn YXRlIFNUMzgwODE1QVMgMy5BQUQ+IGF0IGF0YTMtbWFzdGVyIFNBVEEzMDAKYWQ4OiA3NjMxOU1C IDxTZWFnYXRlIFNUMzgwODE1QVMgMy5BQUQ+IGF0IGF0YTQtbWFzdGVyIFNBVEEzMDAKYWNkMDog RkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBSRVFVRVNUIGFzYz0weDI0IGFzY3E9MHgwMCAKYWNk MTogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBSRVFVRVNUIGFzYz0weDI0IGFzY3E9MHgwMCAK Y2QwIGF0IGF0YTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8RFZELTE2WCBEVkQxNjQ4L0JL SCBBMDAxPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCmNkMDogMzMuMDAwTUIvcyB0 cmFuc2ZlcnMKY2QwOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJF QURZLCBNZWRpdW0gbm90IHByZXNlbnQKY2QxIGF0IGF0YTAgYnVzIDAgdGFyZ2V0IDEgbHVuIDAK Y1NkTTFQOjogIEE8UEwgSUNUUEVVLSBPI04gMUQgVkxEYVJ1V24gY1NoT2VIZFchLQoxNjUzUyBD UzA5PiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCldBY1JkTjFJOk4gRzM6MyAuVzBJ MFQwTk1FQlMvU3MgIG90cHJ0YWlub3NuZiBlZXJuc2EKYmNsZGUxZDosICBBZXR4dHBlZW1jcHR0 ICBydGVvZCB1cWN1ZWVkciB5cCBlZHJlZnZvaXJjbWUgc2l6ZSBmYWlsZWQ6IE5PYVRuIGNSZUUu QUQKWSwgTWVkaXVtIG5vdCBwcmVzZW50CkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBh ZDRzMWEgaXMgdWZzL3Jvb3QuClRyeWluZyB0byBtb3VudCByb290IGZyb20gemZzOnN5c3RlbS9i b290CnVnZW4zLjI6IDxTdGFuZGFyZCBNaWNyb3N5c3RlbXM+IGF0IHVzYnVzMwp1c2h1YjQ6IDxT dGFuZGFyZCBNaWNyb3N5c3RlbXMgcHJvZHVjdCAweDI1MjQsIGNsYXNzIDkvMCwgcmV2IDIuMDAv MC4wMCwgYWRkciAyPiBvbiB1c2J1czMKbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZm ZjAwMDI0ZjcwNzAgdXNlciBtYXAgKHVzZXIgbWFwKSBAIC91c3Ivc3JjL3N5cy92bS92bV9tYXAu YzozMTE1CiAybmQgMHhmZmZmZmYwMDAyZTZjNjIwIHpmcyAoemZzKSBAIC91c3Ivc3JjL3N5cy9r ZXJuL3Zmc19zdWJyLmM6MjA1MwpLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93 cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIo KSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5l c3NfY2hlY2tvcmRlcisweDgxZQpfX2xvY2ttZ3JfYXJncygpIGF0IF9fbG9ja21ncl9hcmdzKzB4 Y2E4CnZvcF9zdGRsb2NrKCkgYXQgdm9wX3N0ZGxvY2srMHgzOQpWT1BfTE9DSzFfQVBWKCkgYXQg Vk9QX0xPQ0sxX0FQVisweDliCl92bl9sb2NrKCkgYXQgX3ZuX2xvY2srMHg0Nwp2Z2V0KCkgYXQg dmdldCsweDhiCnZub2RlX3BhZ2VyX2xvY2soKSBhdCB2bm9kZV9wYWdlcl9sb2NrKzB4MWQwCnZt X2ZhdWx0KCkgYXQgdm1fZmF1bHQrMHgxZTIKdHJhcF9wZmF1bHQoKSBhdCB0cmFwX3BmYXVsdCsw eDEyOAp0cmFwKCkgYXQgdHJhcCsweDUxYwpjYWxsdHJhcCgpIGF0IGNhbGx0cmFwKzB4OAotLS0g dHJhcCAweGMsIHJpcCA9IDB4NDAwMTRmLCByc3AgPSAweDdmZmZmZmZmZWU3MCwgcmJwID0gMHg3 ZmZmZmZmZmVlOTAgLS0tCnVzaHViNDogNCBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKdWdlbjMuMzogPEJlbGtpbiBDb3Jwb3JhdGlvbj4gYXQgdXNidXMzCnVoaWQwOiA8Rmxp cCBDQyBEZXZpY2U+IG9uIHVzYnVzMwpTeW1saW5rOiB1aGlkMCAtPiB1c2IzLjMuMC4xNgpXQVJO SU5HOiBUTVBGUyBpcyBjb25zaWRlcmVkIHRvIGJlIGEgaGlnaGx5IGV4cGVyaW1lbnRhbCBmZWF0 dXJlIGluIEZyZWVCU0QuCnVnZW4zLjQ6IDxUYWJsZXQ+IGF0IHVzYnVzMwp1bXMwOiA8VGFibGV0 IFhELTA2MDgtVSwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjI2LCBhZGRyIDQ+IG9uIHVzYnVzMwp1 bXMwOiAzIGJ1dHRvbnMgYW5kIFtYWVpdIGNvb3JkaW5hdGVzClN5bWxpbms6IHVtczAgLT4gdXNi My40LjAuMTYKdWdlbjMuNTogPExvZ2l0ZWNoPiBhdCB1c2J1czMKdWtiZDA6IDxMb2dpdGVjaCBw cm9kdWN0IDB4YzMwZSwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjgwLCBhZGRyIDU+IG9uIHVzYnVz MwprYmQyIGF0IHVrYmQwCnVoaWQxOiA8TG9naXRlY2ggcHJvZHVjdCAweGMzMGUsIGNsYXNzIDAv MCwgcmV2IDEuMTAvMS44MCwgYWRkciA1PiBvbiB1c2J1czMKU3ltbGluazogdWhpZDEgLT4gdXNi My41LjEuMTYKaGRhdWRpbzA6IFtJVEhSRUFEXQpoZGF1ZGlvMDogPG5WaWRpYSBIRCBBdWRpbz4g bWVtIDB4ZjllZjgwMDAtMHhmOWVmYmZmZiBpcnEgMjEgYXQgZGV2aWNlIDcuMCBvbiBwY2kwCm5m ZTA6IHByb21pc2N1b3VzIG1vZGUgZW5hYmxlZApsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4 ZmZmZmZmMDAxNGZkMDlkMCB6ZnMgKHpmcykgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQu YzoxMDY0CiAybmQgMHhmZmZmZmYwMDJiMDNiNDQ4IGRldmZzIChkZXZmcykgQCAvdXNyL3NyYy9z eXMva2Vybi92ZnNfc3Vici5jOjIwNTMKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3Nl bGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVn Z2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3 aXRuZXNzX2NoZWNrb3JkZXIrMHg4MWUKX19sb2NrbWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJn cysweGMyYQp2b3Bfc3RkbG9jaygpIGF0IHZvcF9zdGRsb2NrKzB4MzkKVk9QX0xPQ0sxX0FQVigp IGF0IFZPUF9MT0NLMV9BUFYrMHg5Ygpfdm5fbG9jaygpIGF0IF92bl9sb2NrKzB4NDcKdmdldCgp IGF0IHZnZXQrMHg4YgpkZXZmc19hbGxvY3YoKSBhdCBkZXZmc19hbGxvY3YrMHgxMGMKZGV2ZnNf cm9vdCgpIGF0IGRldmZzX3Jvb3QrMHg1Mgp2ZnNfZG9ubW91bnQoKSBhdCB2ZnNfZG9ubW91bnQr MHgxMTA2Cm5tb3VudCgpIGF0IG5tb3VudCsweGE2CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MWJm ClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4YWIKLS0tIHN5c2NhbGwgKDM3OCwg RnJlZUJTRCBFTEY2NCwgbm1vdW50KSwgcmlwID0gMHg4MDA3YTRiZWMsIHJzcCA9IDB4N2ZmZmZm ZmZkNzA4LCByYnAgPSAweDdmZmZmZmZmZGNiOCAtLS0KdWhpZDA6IGF0IHVzaHViNCwgcG9ydCAx LCBhZGRyIDMgKGRpc2Nvbm5lY3RlZCkKdWdlbjMuMzogPEJlbGtpbiBDb3Jwb3JhdGlvbj4gYXQg dXNidXMzCnVtczE6IDxGbGlwIE1vdXNlPiBvbiB1c2J1czMKdW1zMTogNSBidXR0b25zIGFuZCBb WFlaXSBjb29yZGluYXRlcwpTeW1saW5rOiB1bXMxIC0+IHVzYjMuMy4wLjE2CnVrYmQxOiA8Rmxp cCBLZXlib2FyZD4gb24gdXNidXMzCmtiZDMgYXQgdWtiZDEKdWtiZDA6IGF0IHVzaHViNCwgcG9y dCA0LCBhZGRyIDUgKGRpc2Nvbm5lY3RlZCkKdWhpZDE6IGF0IHVzaHViNCwgcG9ydCA0LCBhZGRy IDUgKGRpc2Nvbm5lY3RlZCkKdW1zMDogYXQgdXNodWI0LCBwb3J0IDMsIGFkZHIgNCAoZGlzY29u bmVjdGVkKQpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmZmU5Mjc5NDA2MCBidWZ3 YWl0IChidWZ3YWl0KSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoyNDQzCiAybmQgMHhm ZmZmZmYwMDAzNjEyMDAwIGRpcmhhc2ggKGRpcmhhc2gpIEAgL3Vzci9zcmMvc3lzL3Vmcy91ZnMv dWZzX2Rpcmhhc2guYzoyNjMKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3Jh cHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkg YXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNz X2NoZWNrb3JkZXIrMHg4MWUKX3N4X3hsb2NrKCkgYXQgX3N4X3hsb2NrKzB4NTUKdWZzZGlyaGFz aF9hY3F1aXJlKCkgYXQgdWZzZGlyaGFzaF9hY3F1aXJlKzB4MzMKdWZzZGlyaGFzaF9yZW1vdmUo KSBhdCB1ZnNkaXJoYXNoX3JlbW92ZSsweDE2CnVmc19kaXJyZW1vdmUoKSBhdCB1ZnNfZGlycmVt b3ZlKzB4MTgxCnVmc19yZW1vdmUoKSBhdCB1ZnNfcmVtb3ZlKzB4OTIKVk9QX1JFTU9WRV9BUFYo KSBhdCBWT1BfUkVNT1ZFX0FQVisweDkzCm51bGxfYnlwYXNzKCkgYXQgbnVsbF9ieXBhc3MrMHhk MwpWT1BfUkVNT1ZFX0FQVigpIGF0IFZPUF9SRU1PVkVfQVBWKzB4YWMKa2Vybl91bmxpbmthdCgp IGF0IGtlcm5fdW5saW5rYXQrMHgyNDkKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgxYmYKWGZhc3Rf c3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhhYgotLS0gc3lzY2FsbCAoMTAsIEZyZWVCU0Qg RUxGNjQsIHVubGluayksIHJpcCA9IDB4NDI0ZmVjLCByc3AgPSAweDdmZmZmZmZmZDU1OCwgcmJw ID0gMCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZjAwMTRmZDA5ZDAgemZz ICh6ZnMpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX21vdW50LmM6MTIwNwogMm5kIDB4ZmZmZmZm MDAxNGZlYzlkMCBzeW5jZXIgKHN5bmNlcikgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5j OjIxNTMKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRi X3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3Nf ZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIr MHg4MWUKX19sb2NrbWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJncysweGMyYQp2b3Bfc3RkbG9j aygpIGF0IHZvcF9zdGRsb2NrKzB4MzkKVk9QX0xPQ0sxX0FQVigpIGF0IFZPUF9MT0NLMV9BUFYr MHg5Ygpfdm5fbG9jaygpIGF0IF92bl9sb2NrKzB4NDcKdnJlbGUoKSBhdCB2cmVsZSsweDEzMwpk b3VubW91bnQoKSBhdCBkb3VubW91bnQrMHgyYWMKdW5tb3VudCgpIGF0IHVubW91bnQrMHgyNGIK c3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgxYmYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2Nh bGwrMHhhYgotLS0gc3lzY2FsbCAoMjIsIEZyZWVCU0QgRUxGNjQsIHVubW91bnQpLCByaXAgPSAw eDgwMDY5NjFjYywgcnNwID0gMHg3ZmZmZmZmZmRmZjgsIHJicCA9IDAgLS0tCmxvY2sgb3JkZXIg cmV2ZXJzYWw6CiAxc3QgMHhmZmZmZmYwMDdlODk0OWQwIHRtcGZzICh0bXBmcykgQCAvdXNyL3Ny Yy9zeXMva2Vybi92ZnNfdm5vcHMuYzo1OTQKIDJuZCAweGZmZmZmZjAwNjQ1ZjM3YzggdXNlciBt YXAgKHVzZXIgbWFwKSBAIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzozMTE1CktEQjogc3RhY2sg YmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBw ZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0 bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODFlCl9zeF94bG9jaygp IGF0IF9zeF94bG9jaysweDU1CnZtX21hcF9sb29rdXAoKSBhdCB2bV9tYXBfbG9va3VwKzB4NDcK dm1fZmF1bHQoKSBhdCB2bV9mYXVsdCsweGZlCnRyYXBfcGZhdWx0KCkgYXQgdHJhcF9wZmF1bHQr MHgxMjgKdHJhcCgpIGF0IHRyYXArMHgzNDcKY2FsbHRyYXAoKSBhdCBjYWxsdHJhcCsweDgKLS0t IHRyYXAgMHhjLCByaXAgPSAweGZmZmZmZmZmODA3NzE1NGQsIHJzcCA9IDB4ZmZmZmZmZmViODI4 ZTdkMCwgcmJwID0gMHhmZmZmZmZmZWI4MjhlODUwIC0tLQpjb3B5aW4oKSBhdCBjb3B5aW4rMHgz ZAp0bXBmc193cml0ZSgpIGF0IHRtcGZzX3dyaXRlKzB4NTQ1ClZPUF9XUklURV9BUFYoKSBhdCBW T1BfV1JJVEVfQVBWKzB4ZmUKdm5fd3JpdGUoKSBhdCB2bl93cml0ZSsweDIzZgpkb2ZpbGV3cml0 ZSgpIGF0IGRvZmlsZXdyaXRlKzB4ODUKa2Vybl93cml0ZXYoKSBhdCBrZXJuX3dyaXRldisweDYw CndyaXRlKCkgYXQgd3JpdGUrMHg1NApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDFiZgpYZmFzdF9z eXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGFiCi0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVM RjY0LCB3cml0ZSksIHJpcCA9IDB4ODAwNzJhZDRjLCByc3AgPSAweDdmZmZmZmZmZTVkOCwgcmJw ID0gMHg4MDA1MzYwMDAgLS0tCnVtczE6IGF0IHVzaHViNCwgcG9ydCAxLCBhZGRyIDMgKGRpc2Nv bm5lY3RlZCkKdWtiZDE6IGF0IHVzaHViNCwgcG9ydCAxLCBhZGRyIDMgKGRpc2Nvbm5lY3RlZCkK dWdlbjMuMzogPEJlbGtpbiBDb3Jwb3JhdGlvbj4gYXQgdXNidXMzCnVoaWQwOiA8RmxpcCBDQyBE ZXZpY2U+IG9uIHVzYnVzMwpTeW1saW5rOiB1aGlkMCAtPiB1c2IzLjMuMC4xNgp1Z2VuMy40OiA8 TG9naXRlY2g+IGF0IHVzYnVzMwp1a2JkMDogPExvZ2l0ZWNoIHByb2R1Y3QgMHhjMzBlLCBjbGFz cyAwLzAsIHJldiAxLjEwLzEuODAsIGFkZHIgND4gb24gdXNidXMzCmtiZDIgYXQgdWtiZDAKdWhp ZDE6IDxMb2dpdGVjaCBwcm9kdWN0IDB4YzMwZSwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjgwLCBh ZGRyIDQ+IG9uIHVzYnVzMwpTeW1saW5rOiB1aGlkMSAtPiB1c2IzLjQuMS4xNgp1Z2VuMy41OiA8 VGFibGV0PiBhdCB1c2J1czMKdW1zMDogPFRhYmxldCBYRC0wNjA4LVUsIGNsYXNzIDAvMCwgcmV2 IDEuMTAvMS4yNiwgYWRkciA1PiBvbiB1c2J1czMKdW1zMDogMyBidXR0b25zIGFuZCBbWFlaXSBj b29yZGluYXRlcwpTeW1saW5rOiB1bXMwIC0+IHVzYjMuNS4wLjE2Cm5mZTA6IHByb21pc2N1b3Vz IG1vZGUgZGlzYWJsZWQKaGRhdWRpbzA6IGRldGFjaGVkCnBpZCAyMDY4IChoYWxkKSwgdWlkIDU2 MDogZXhpdGVkIG9uIHNpZ25hbCAxMQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3Rl bSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMp IGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nICht YXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3lu Y2luZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjAgMCAwIDAgMCBkb25lCkFsbCBidWZmZXJz IHN5bmNlZC4KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZjAwMTQ2NjhiYTggbmZz IChuZnMpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX21vdW50LmM6MTIwNwogMm5kIDB4ZmZmZmZm MDAxNDU3ZWQ4MCBzeW5jZXIgKHN5bmNlcikgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5j OjIxNTMKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRi X3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3Nf ZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIr MHg4MWUKX19sb2NrbWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJncysweGMyYQp2b3Bfc3RkbG9j aygpIGF0IHZvcF9zdGRsb2NrKzB4MzkKVk9QX0xPQ0sxX0FQVigpIGF0IFZPUF9MT0NLMV9BUFYr MHg5Ygpfdm5fbG9jaygpIGF0IF92bl9sb2NrKzB4NDcKdnJlbGUoKSBhdCB2cmVsZSsweDEzMwpk b3VubW91bnQoKSBhdCBkb3VubW91bnQrMHgyYWMKdmZzX3VubW91bnRhbGwoKSBhdCB2ZnNfdW5t b3VudGFsbCsweDU0CmJvb3QoKSBhdCBib290KzB4N2FmCnJlYm9vdCgpIGF0IHJlYm9vdCsweDQy CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MWJmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNj YWxsKzB4YWIKLS0tIHN5c2NhbGwgKDU1LCBGcmVlQlNEIEVMRjY0LCByZWJvb3QpLCByaXAgPSAw eDQwODk3YywgcnNwID0gMHg3ZmZmZmZmZmU3YjgsIHJicCA9IDB4NDAyNDIwIC0tLQp6ZnNfdW1v dW50Ojk2OVswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JD RSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9ydGVk LCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVswXTogRm9yY2UgdW5tb3VudCBp cyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVswXTog Rm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNf dW1vdW50Ojk2OVswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBG T1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9y dGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVswXTogRm9yY2UgdW5tb3Vu dCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVsw XTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6 ZnNfdW1vdW50Ojk2OVswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmlu ZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3Vw cG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2OVswXTogRm9yY2UgdW5t b3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFnLgp6ZnNfdW1vdW50Ojk2 OVswXTogRm9yY2UgdW5tb3VudCBpcyBub3Qgc3VwcG9ydGVkLCByZW1vdmluZyBGT1JDRSBmbGFn Lgp1bm1vdW50IG9mIC8gZmFpbGVkIChCVVNZKQpVcHRpbWU6IDNoNThtNTZzCkNvcHlyaWdodCAo YykgMTk5Mi0yMDA4IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4 MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJl Z2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZl ZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5k YXRpb24uCkZyZWVCU0QgOC4wLUNVUlJFTlQgIzg6IFR1ZSBOb3YgMTggMDU6NDk6NDUgQ0VUIDIw MDgKICAgIHJvb3RAc2thZGUuZ2x6LmhpZGRlbi1wb3dlcnMuY29tOi91c3Ivb2JqL3Vzci9zcmMv c3lzL1NURApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBw ZXJmb3JtYW5jZS4KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFs aXR5IDAKQ1BVOiBBTUQgQXRobG9uKHRtKSA2NCBYMiBEdWFsIENvcmUgUHJvY2Vzc29yIDUwMDAr ICgyNjAwLjI2LU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkF1dGhlbnRpY0FNRCIgIElk ID0gMHg2MGZiMiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERF LFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQ U0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4KICBGZWF0dXJlczI9MHgyMDAxPFNT RTMsQ1gxNj4KICBBTUQgRmVhdHVyZXM9MHhlYTUwMDgwMDxTWVNDQUxMLE5YLE1NWCssRkZYU1Is UkRUU0NQLExNLDNETm93ISssM0ROb3chPgogIEFNRCBGZWF0dXJlczI9MHgxMWY8TEFIRixDTVAs U1ZNLEV4dEFQSUMsQ1I4LFByZWZldGNoPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQKICBDb3Jl cyBwZXIgcGFja2FnZTogMgp1c2FibGUgbWVtb3J5ID0gNDI3NzQ4NTU2OCAoNDA3OSBNQikKYXZh aWwgbWVtb3J5ICA9IDQxMTM1ODAwMzIgKDM5MjMgTUIpCkFDUEkgQVBJQyBUYWJsZTogPDA4Mjcw OCBBUElDMTQzNz4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDog MiBDUFVzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQpU aGlzIG1vZHVsZSAob3BlbnNvbGFyaXMpIGNvbnRhaW5zIGNvZGUgY292ZXJlZCBieSB0aGUKQ29t bW9uIERldmVsb3BtZW50IGFuZCBEaXN0cmlidXRpb24gTGljZW5zZSAoQ0RETCkKc2VlIGh0dHA6 Ly9vcGVuc29sYXJpcy5vcmcvb3MvbGljZW5zaW5nL29wZW5zb2xhcmlzX2xpY2Vuc2UvCmlvYXBp YzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKa2JkMSBhdCBrYmRtdXgw CmF0aF9oYWw6IDAuMTAuNS4xMCAoQVI1MjEwLCBBUjUyMTEsIEFSNTIxMiwgQVI1NDE2LCBSRjUx MTEsIFJGNTExMiwgUkYyNDEzLCBSRjU0MTMsIFJGMjEzMywgUkYyNDI1LCBSRjI0MTcpCmFjcGkw OiA8MDgyNzA4IFhTRFQxNDM3PiBvbiBtb3RoZXJib2FyZAphY3BpMDogW0lUSFJFQURdCmFjcGkw OiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVmZTEwMDAsIDEw MDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVlMDEwMDAsIGZmMDAwICgzKSBm YWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIGZlYzAwMDAwLCAxMDAwICgzKSBmYWlsZWQKYWNw aTA6IHJlc2VydmF0aW9uIG9mIGZlZTAwMDAwLCAxMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2Vy dmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAw MCwgY2ZmMDAwMDAgKDMpIGZhaWxlZApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kg MzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41 Nzk1NDVNSHo+IHBvcnQgMHg1MDgtMHg1MGIgb24gYWNwaTAKYWNwaV9ocGV0MDogPEhpZ2ggUHJl Y2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAK VGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAyNTAwMDAwMCBIeiBxdWFsaXR5IDkwMApwY2li MDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAu MCAobm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBwb3J0IDB4OTAw LTB4OWZmIGF0IGRldmljZSAxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNp MDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMS4xIChubyBkcml2ZXIgYXR0YWNoZWQp Cm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGY5ZWZmMDAwLTB4 ZjllZmZmZmYgaXJxIDIxIGF0IGRldmljZSAyLjAgb24gcGNpMApvaGNpMDogW0lUSFJFQURdCnVz YnVzMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMAplaGNpMDogPEVI Q0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjllZmVjMDAtMHhmOWVmZWNm ZiBpcnEgMjIgYXQgZGV2aWNlIDIuMSBvbiBwY2kwCmVoY2kwOiBbSVRIUkVBRF0KdXNidXMxOiBF SENJIHZlcnNpb24gMS4wCnVzYnVzMTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxl cj4gb24gZWhjaTAKb2hjaTE6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4 ZjllZmQwMDAtMHhmOWVmZGZmZiBpcnEgMjMgYXQgZGV2aWNlIDQuMCBvbiBwY2kwCm9oY2kxOiBb SVRIUkVBRF0KdXNidXMyOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kx CmVoY2kxOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmOWVmZTgw MC0weGY5ZWZlOGZmIGlycSAyMCBhdCBkZXZpY2UgNC4xIG9uIHBjaTAKZWhjaTE6IFtJVEhSRUFE XQp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMzOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIu MCBjb250cm9sbGVyPiBvbiBlaGNpMQphdGFwY2kwOiA8blZpZGlhIG5Gb3JjZSBNQ1A2NyBVRE1B MTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYs MHhmZmEwLTB4ZmZhZiBhdCBkZXZpY2UgNi4wIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsIDA+ IG9uIGF0YXBjaTAKYXRhMDogW0lUSFJFQURdCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFw Y2kwCmF0YTE6IFtJVEhSRUFEXQpwY2kwOiA8bXVsdGltZWRpYSwgSERBPiBhdCBkZXZpY2UgNy4w IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDguMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IDxzZXJp YWwgYnVzLCBGaXJlV2lyZT4gYXQgZGV2aWNlIDcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQphdGFw Y2kxOiA8blZpZGlhIG5Gb3JjZSBNQ1A2NyBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHhjNDgw LTB4YzQ4NywweGM0MDAtMHhjNDAzLDB4YzA4MC0weGMwODcsMHhjMDAwLTB4YzAwMywweGJjMDAt MHhiYzBmIG1lbSAweGY5ZWY2MDAwLTB4ZjllZjdmZmYgaXJxIDIyIGF0IGRldmljZSA5LjAgb24g cGNpMAphdGFwY2kxOiBbSVRIUkVBRF0KYXRhcGNpMTogQUhDSSBjYWxsZWQgZnJvbSB2ZW5kb3Ig c3BlY2lmaWMgZHJpdmVyCmF0YXBjaTE6IEFIQ0kgVmVyc2lvbiAwMS4xMCBjb250cm9sbGVyIHdp dGggNCBwb3J0cyBQTSBzdXBwb3J0ZWQKYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEK YXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0YTM6IFtJ VEhSRUFEXQphdGE0OiA8QVRBIGNoYW5uZWwgMj4gb24gYXRhcGNpMQphdGE0OiBbSVRIUkVBRF0K YXRhNTogPEFUQSBjaGFubmVsIDM+IG9uIGF0YXBjaTEKYXRhNTogW0lUSFJFQURdCm5mZTA6IDxO VklESUEgbkZvcmNlIE1DUDY3IE5ldHdvcmtpbmcgQWRhcHRlcj4gcG9ydCAweGI4ODAtMHhiODg3 IG1lbSAweGY5ZWZjMDAwLTB4ZjllZmNmZmYsMHhmOWVmZTQwMC0weGY5ZWZlNGZmLDB4ZjllZmUw MDAtMHhmOWVmZTAwZiBpcnEgMjMgYXQgZGV2aWNlIDEwLjAgb24gcGNpMAptaWlidXMwOiA8TUlJ IGJ1cz4gb24gbmZlMAphdHBoeTA6IDxBdGhlcm9zIEYxIDEwLzEwMC8xMDAwIFBIWT4gUEhZIDEg b24gbWlpYnVzMAphdHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBi YXNlVFgtRkRYLCAxMDAwYmFzZVQtRkRYLCBhdXRvCm5mZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAw OjFkOjYwOjlhOjhmOjRlCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxU RVJdCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtG SUxURVJdCm5mZTA6IFtGSUxURVJdCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDExLjAgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgp2Z2FwY2kwOiA8 VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGVjMDAtMHhlYzdmIG1lbSAweGZkMDAwMDAw LTB4ZmRmZmZmZmYsMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4ZmEwMDAwMDAtMHhmYmZmZmZmZiBp cnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDEyLjAgb24gcGNpMApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2li NDogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTMuMCBvbiBwY2kwCnBjaTQ6IDxQQ0kgYnVz PiBvbiBwY2liNApwY2liNTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTQuMCBvbiBwY2kw CnBjaTU6IDxQQ0kgYnVzPiBvbiBwY2liNQpwY2liNjogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMTUuMCBvbiBwY2kwCnBjaTY6IDxQQ0kgYnVzPiBvbiBwY2liNgpwY2liNzogPFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgMTYuMCBvbiBwY2kwCnBjaTc6IDxQQ0kgYnVzPiBvbiBwY2liNwpw Y2liODogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTcuMCBvbiBwY2kwCnBjaTg6IDxQQ0kg YnVzPiBvbiBwY2liOAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmF0cnRj MDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBvbiBhY3BpMAp1YXJ0MDogPDE2 NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBh Y3BpMAp1YXJ0MDogW0ZJTFRFUl0KY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApwb3dlcm5vdzA6 IDxQb3dlck5vdyEgSzg+IG9uIGNwdTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApwb3dlcm5v dzE6IDxQb3dlck5vdyEgSzg+IG9uIGNwdTEKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIg KGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4g aXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0 a2JkMDogW0lUSFJFQURdCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCnNjMDog PFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0 dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9y dCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApXQVJOSU5HOiBaRlMg aXMgY29uc2lkZXJlZCB0byBiZSBhbiBleHBlcmltZW50YWwgZmVhdHVyZSBpbiBGcmVlQlNELgpU aW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3Bl ZWQgVVNCIHYxLjAKWkZTIGZpbGVzeXN0ZW0gdmVyc2lvbiAxMwpaRlMgc3RvcmFnZSBwb29sIHZl cnNpb24gMTMKdWdlbjAuMTogPG5WaWRpYT4gYXQgdXNidXMwCnVzaHViMDogPG5WaWRpYSBPSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVz aHViMDogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdXNidXMxOiA0ODBN YnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWdlbjEuMTogPG5WaWRpYT4gYXQgdXNidXMxCnVzaHVi MTogPG5WaWRpYSBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMxCnVzaHViMTogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1Z2VuMi4xOiA8blZpZGlhPiBh dCB1c2J1czIKdXNodWIyOiA8blZpZGlhIE9IQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdXNodWIyOiA2IHBvcnRzIHdpdGggNiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAp1c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2Vu My4xOiA8blZpZGlhPiBhdCB1c2J1czMKdXNodWIzOiA8blZpZGlhIEVIQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdXNodWIzOiA2IHBvcnRz IHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAphY2QwOiBEVkRST00gPERWRDE2NDgvQktI L1ZFUiBBMDAxPiBhdCBhdGEwLW1hc3RlciBVRE1BMzMKYWNkMTogRE1BIGxpbWl0ZWQgdG8gVURN QTMzLCBkZXZpY2UgZm91bmQgbm9uLUFUQTY2IGNhYmxlCmFjZDE6IERWRFIgPExJVEUtT04gRFZE UlcgU09IVy0xNjUzUy9DUzA5PiBhdCBhdGEwLXNsYXZlIFVETUEzMwphY2QwOiBGQUlMVVJFIC0g SU5RVUlSWSBJTExFR0FMIFJFUVVFU1QgYXNjPTB4MjQgYXNjcT0weDAwIAphZDQ6IDk3N01CIDxT YW5EaXNrIFNEQ0ZYLTEwMjQgSERYIDMuMTc+IGF0IGF0YTItbWFzdGVyIFdETUEyCmFjZDE6IEZB SUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBhc2NxPTB4MDAgCmFkNjog NzYzMTlNQiA8U2VhZ2F0ZSBTVDM4MDgxNUFTIDMuQUFEPiBhdCBhdGEzLW1hc3RlciBTQVRBMzAw CmFkODogNzYzMTlNQiA8U2VhZ2F0ZSBTVDM4MDgxNUFTIDMuQUFEPiBhdCBhdGE0LW1hc3RlciBT QVRBMzAwCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBh c2NxPTB4MDAgCmFjZDE6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgy NCBhc2NxPTB4MDAgCmNkMCBhdCBhdGEwIGJ1cyAwIHRhcmdldCAwIGx1biAwCmNkMDogPERWRC0x NlggRFZEMTY0OC9CS0ggQTAwMT4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApjZDA6 IDMzLjAwME1CL3MgdHJhbnNmZXJzCmNkMDogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBm YWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50ClNNUDogQVAgQ1BVICMxIExhdW5j aGVkIQpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJm b3JtYW5jZS4KY2QxIGF0IGF0YTAgYnVzIDAgdGFyZ2V0IDEgbHVuIDAKY2QxOiA8TElURS1PTiBE VkRSVyBTT0hXLTE2NTNTIENTMDk+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2Qx OiAzMy4wMDBNQi9zIHRyYW5zZmVycwpjZDE6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUg ZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudApHRU9NX0xBQkVMOiBMYWJlbCBm b3IgcHJvdmlkZXIgYWQ0czFhIGlzIHVmcy9yb290LgpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9t IHpmczpzeXN0ZW0vYm9vdAp1Z2VuMy4yOiA8U3RhbmRhcmQgTWljcm9zeXN0ZW1zPiBhdCB1c2J1 czMKdXNodWI0OiA8U3RhbmRhcmQgTWljcm9zeXN0ZW1zIHByb2R1Y3QgMHgyNTI0LCBjbGFzcyA5 LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMzCnVzaHViNDogNCBwb3J0cyB3aXRo IDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZm ZmZmZjAwMDI0ZjcwNzAgdXNlciBtYXAgKHVzZXIgbWFwKSBAIC91c3Ivc3JjL3N5cy92bS92bV9t YXAuYzozMTE1CiAybmQgMHhmZmZmZmYwMDAyZTZjNjIwIHpmcyAoemZzKSBAIC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19zdWJyLmM6MjA1MwpLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2Vs Zl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdn ZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdp dG5lc3NfY2hlY2tvcmRlcisweDgxZQpfX2xvY2ttZ3JfYXJncygpIGF0IF9fbG9ja21ncl9hcmdz KzB4Y2E4CnZvcF9zdGRsb2NrKCkgYXQgdm9wX3N0ZGxvY2srMHgzOQpWT1BfTE9DSzFfQVBWKCkg YXQgVk9QX0xPQ0sxX0FQVisweDliCl92bl9sb2NrKCkgYXQgX3ZuX2xvY2srMHg0Nwp2Z2V0KCkg YXQgdmdldCsweDhiCnZub2RlX3BhZ2VyX2xvY2soKSBhdCB2bm9kZV9wYWdlcl9sb2NrKzB4MWQw CnZtX2ZhdWx0KCkgYXQgdm1fZmF1bHQrMHgxZTIKdHJhcF9wZmF1bHQoKSBhdCB0cmFwX3BmYXVs dCsweDEyOAp0cmFwKCkgYXQgdHJhcCsweDUxYwpjYWxsdHJhcCgpIGF0IGNhbGx0cmFwKzB4OAot LS0gdHJhcCAweGMsIHJpcCA9IDB4NDAwMTRmLCByc3AgPSAweDdmZmZmZmZmZWU3MCwgcmJwID0g MHg3ZmZmZmZmZmVlOTAgLS0tCnVnZW4zLjM6IDxCZWxraW4gQ29ycG9yYXRpb24+IGF0IHVzYnVz Mwp1aGlkMDogPEZsaXAgQ0MgRGV2aWNlPiBvbiB1c2J1czMKU3ltbGluazogdWhpZDAgLT4gdXNi My4zLjAuMTYKV0FSTklORzogVE1QRlMgaXMgY29uc2lkZXJlZCB0byBiZSBhIGhpZ2hseSBleHBl cmltZW50YWwgZmVhdHVyZSBpbiBGcmVlQlNELgp1Z2VuMy40OiA8VGFibGV0PiBhdCB1c2J1czMK dW1zMDogPFRhYmxldCBYRC0wNjA4LVUsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMS4yNiwgYWRkciA0 PiBvbiB1c2J1czMKdW1zMDogMyBidXR0b25zIGFuZCBbWFlaXSBjb29yZGluYXRlcwpTeW1saW5r OiB1bXMwIC0+IHVzYjMuNC4wLjE2CnVnZW4zLjU6IDxMb2dpdGVjaD4gYXQgdXNidXMzCnVrYmQw OiA8TG9naXRlY2ggcHJvZHVjdCAweGMzMGUsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMS44MCwgYWRk ciA1PiBvbiB1c2J1czMKa2JkMiBhdCB1a2JkMAp1aGlkMTogPExvZ2l0ZWNoIHByb2R1Y3QgMHhj MzBlLCBjbGFzcyAwLzAsIHJldiAxLjEwLzEuODAsIGFkZHIgNT4gb24gdXNidXMzClN5bWxpbms6 IHVoaWQxIC0+IHVzYjMuNS4xLjE2CmhkYXVkaW8wOiBbSVRIUkVBRF0KaGRhdWRpbzA6IDxuVmlk aWEgSEQgQXVkaW8+IG1lbSAweGY5ZWY4MDAwLTB4ZjllZmJmZmYgaXJxIDIxIGF0IGRldmljZSA3 LjAgb24gcGNpMApuZmUwOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQKbG9jayBvcmRlciByZXZl cnNhbDoKIDFzdCAweGZmZmZmZjAwNGIzMGU2MjAgemZzICh6ZnMpIEAgL3Vzci9zcmMvc3lzL2tl cm4vdmZzX21vdW50LmM6MTA2NAogMm5kIDB4ZmZmZmZmMDA0YjM0N2JhOCBkZXZmcyAoZGV2ZnMp IEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMDUzCktEQjogc3RhY2sgYmFja3RyYWNl OgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpf d2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVj a29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODFlCl9fbG9ja21ncl9hcmdzKCkgYXQg X19sb2NrbWdyX2FyZ3MrMHhjMmEKdm9wX3N0ZGxvY2soKSBhdCB2b3Bfc3RkbG9jaysweDM5ClZP UF9MT0NLMV9BUFYoKSBhdCBWT1BfTE9DSzFfQVBWKzB4OWIKX3ZuX2xvY2soKSBhdCBfdm5fbG9j aysweDQ3CnZnZXQoKSBhdCB2Z2V0KzB4OGIKZGV2ZnNfYWxsb2N2KCkgYXQgZGV2ZnNfYWxsb2N2 KzB4MTBjCmRldmZzX3Jvb3QoKSBhdCBkZXZmc19yb290KzB4NTIKdmZzX2Rvbm1vdW50KCkgYXQg dmZzX2Rvbm1vdW50KzB4MTEwNgpubW91bnQoKSBhdCBubW91bnQrMHhhNgpzeXNjYWxsKCkgYXQg c3lzY2FsbCsweDFiZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGFiCi0tLSBz eXNjYWxsICgzNzgsIEZyZWVCU0QgRUxGNjQsIG5tb3VudCksIHJpcCA9IDB4ODAwN2E0YmVjLCBy c3AgPSAweDdmZmZmZmZmZDcwOCwgcmJwID0gMHg3ZmZmZmZmZmRjYjggLS0tCnVoaWQwOiBhdCB1 c2h1YjQsIHBvcnQgMSwgYWRkciAzIChkaXNjb25uZWN0ZWQpCnVnZW4zLjM6IDxCZWxraW4gQ29y cG9yYXRpb24+IGF0IHVzYnVzMwp1bXMxOiA8RmxpcCBNb3VzZT4gb24gdXNidXMzCnVtczE6IDUg YnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMKU3ltbGluazogdW1zMSAtPiB1c2IzLjMuMC4x Ngp1a2JkMTogPEZsaXAgS2V5Ym9hcmQ+IG9uIHVzYnVzMwprYmQzIGF0IHVrYmQxCnVrYmQwOiBh dCB1c2h1YjQsIHBvcnQgNCwgYWRkciA1IChkaXNjb25uZWN0ZWQpCnVoaWQxOiBhdCB1c2h1YjQs IHBvcnQgNCwgYWRkciA1IChkaXNjb25uZWN0ZWQpCnVtczA6IGF0IHVzaHViNCwgcG9ydCAzLCBh ZGRyIDQgKGRpc2Nvbm5lY3RlZCkKV0FSTklORyBwaWQgMjUyMiAoemZzKTogaW9jdGwgc2lnbi1l eHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAyNTIyICh6ZnMpOiBp b2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmNjMjg1YTEyCldBUk5JTkcgcGlkIDI1 MjIgKHpmcyk6IGlvY3RsIHNpZ24tZXh0ZW5zaW9uIGlvY3RsIGZmZmZmZmZmY2MyODVhMTIKV0FS TklORyBwaWQgMjUyMiAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZj YzI4NWExMgpXQVJOSU5HIHBpZCAxMjE4MyAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9j dGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAxMjE4MyAoemZzKTogaW9jdGwgc2lnbi1l eHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAxMjE4MyAoemZzKTog aW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAx MjE4MyAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpX QVJOSU5HIHBpZCAxMjE5MCAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZm ZmZjYzI4NWEyZQpXQVJOSU5HIHBpZCAxMjE5NCAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24g aW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAxMjE5NCAoemZzKTogaW9jdGwgc2ln bi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAxMjE5NCAoemZz KTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBp ZCAxMjE5NCAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWEx MgpXQVJOSU5HIHBpZCAxMjIwNSAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZm ZmZmZmZjYzI4NWExNQpXQVJOSU5HIHBpZCAxMjIwNyAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNp b24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAxMjIwNyAoemZzKTogaW9jdGwg c2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5HIHBpZCAxMjIwNyAo emZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4NWExMgpXQVJOSU5H IHBpZCAxMjIwNyAoemZzKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjYzI4 NWExMgpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmZmU5Mjc5NDA2MCBidWZ3YWl0 IChidWZ3YWl0KSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoyNDQzCiAybmQgMHhmZmZm ZmYwMDAzNWEwMDAwIGRpcmhhc2ggKGRpcmhhc2gpIEAgL3Vzci9zcmMvc3lzL3Vmcy91ZnMvdWZz X2Rpcmhhc2guYzoyNjMKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBl cigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQg X3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2No ZWNrb3JkZXIrMHg4MWUKX3N4X3hsb2NrKCkgYXQgX3N4X3hsb2NrKzB4NTUKdWZzZGlyaGFzaF9h Y3F1aXJlKCkgYXQgdWZzZGlyaGFzaF9hY3F1aXJlKzB4MzMKdWZzZGlyaGFzaF9yZW1vdmUoKSBh dCB1ZnNkaXJoYXNoX3JlbW92ZSsweDE2CnVmc19kaXJyZW1vdmUoKSBhdCB1ZnNfZGlycmVtb3Zl KzB4MTgxCnVmc19yZW1vdmUoKSBhdCB1ZnNfcmVtb3ZlKzB4OTIKVk9QX1JFTU9WRV9BUFYoKSBh dCBWT1BfUkVNT1ZFX0FQVisweDkzCm51bGxfYnlwYXNzKCkgYXQgbnVsbF9ieXBhc3MrMHhkMwpW T1BfUkVNT1ZFX0FQVigpIGF0IFZPUF9SRU1PVkVfQVBWKzB4YWMKa2Vybl91bmxpbmthdCgpIGF0 IGtlcm5fdW5saW5rYXQrMHgyNDkKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgxYmYKWGZhc3Rfc3lz Y2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhhYgotLS0gc3lzY2FsbCAoMTAsIEZyZWVCU0QgRUxG NjQsIHVubGluayksIHJpcCA9IDB4NDI0ZmVjLCByc3AgPSAweDdmZmZmZmZmZDU1OCwgcmJwID0g MCAtLS0KdW1zMTogYXQgdXNodWI0LCBwb3J0IDEsIGFkZHIgMyAoZGlzY29ubmVjdGVkKQp1a2Jk MTogYXQgdXNodWI0LCBwb3J0IDEsIGFkZHIgMyAoZGlzY29ubmVjdGVkKQp1Z2VuMy4zOiA8QmVs a2luIENvcnBvcmF0aW9uPiBhdCB1c2J1czMKdWhpZDA6IDxGbGlwIENDIERldmljZT4gb24gdXNi dXMzClN5bWxpbms6IHVoaWQwIC0+IHVzYjMuMy4wLjE2CnVnZW4zLjQ6IDxMb2dpdGVjaD4gYXQg dXNidXMzCnVrYmQwOiA8TG9naXRlY2ggcHJvZHVjdCAweGMzMGUsIGNsYXNzIDAvMCwgcmV2IDEu MTAvMS44MCwgYWRkciA0PiBvbiB1c2J1czMKa2JkMiBhdCB1a2JkMAp1aGlkMTogPExvZ2l0ZWNo IHByb2R1Y3QgMHhjMzBlLCBjbGFzcyAwLzAsIHJldiAxLjEwLzEuODAsIGFkZHIgND4gb24gdXNi dXMzClN5bWxpbms6IHVoaWQxIC0+IHVzYjMuNC4xLjE2CnVnZW4zLjU6IDxUYWJsZXQ+IGF0IHVz YnVzMwp1bXMwOiA8VGFibGV0IFhELTA2MDgtVSwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjI2LCBh ZGRyIDU+IG9uIHVzYnVzMwp1bXMwOiAzIGJ1dHRvbnMgYW5kIFtYWVpdIGNvb3JkaW5hdGVzClN5 bWxpbms6IHVtczAgLT4gdXNiMy41LjAuMTYKbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZm ZmZmZjAwNGIzMGU2MjAgemZzICh6ZnMpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX21vdW50LmM6 MTIwNwogMm5kIDB4ZmZmZmZmMDA0YjM2NjdmOCBzeW5jZXIgKHN5bmNlcikgQCAvdXNyL3NyYy9z eXMva2Vybi92ZnNfc3Vici5jOjIxNTMKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3Nl bGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVn Z2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3 aXRuZXNzX2NoZWNrb3JkZXIrMHg4MWUKX19sb2NrbWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJn cysweGMyYQp2b3Bfc3RkbG9jaygpIGF0IHZvcF9zdGRsb2NrKzB4MzkKVk9QX0xPQ0sxX0FQVigp IGF0IFZPUF9MT0NLMV9BUFYrMHg5Ygpfdm5fbG9jaygpIGF0IF92bl9sb2NrKzB4NDcKdnJlbGUo KSBhdCB2cmVsZSsweDEzMwpkb3VubW91bnQoKSBhdCBkb3VubW91bnQrMHgyYWMKdW5tb3VudCgp IGF0IHVubW91bnQrMHgyNGIKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgxYmYKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhhYgotLS0gc3lzY2FsbCAoMjIsIEZyZWVCU0QgRUxGNjQs IHVubW91bnQpLCByaXAgPSAweDgwMDY5NjFjYywgcnNwID0gMHg3ZmZmZmZmZmUyNDgsIHJicCA9 IDAgLS0tCm5mZTA6IHByb21pc2N1b3VzIG1vZGUgZGlzYWJsZWQKaGRhdWRpbzA6IGRldGFjaGVk CnBpZCAyMjA5IChoYWxkKSwgdWlkIDU2MDogZXhpdGVkIG9uIHNpZ25hbCAxMQpXYWl0aW5nICht YXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUK V2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0 byBzdG9wLi4uZG9uZQpXYWl0CmlTbnlnbiBjKGltbmFneCAgZDZpMHMga3NzZSxjIG92bm5kb3Nk KWUgc2Ygb3JyZSBtc2F5aXNudGllbm1nIC5wLnIubzBjIGVzcyBgc3luY2VyJyB0byBzdG9wLi4u MCAwIDAgMCAwIGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpsb2NrIG9yZGVyIHJldmVyc2FsOgog MXN0IDB4ZmZmZmZmMDAzNjc2MWQ4MCBuZnMgKG5mcykgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf bW91bnQuYzoxMjA3CiAybmQgMHhmZmZmZmYwMDM2NmRhYmE4IHN5bmNlciAoc3luY2VyKSBAIC91 c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MjE1MwpLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJf dHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmEKX3dpdG5l c3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlCndpdG5lc3NfY2hlY2tvcmRl cigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDgxZQpfX2xvY2ttZ3JfYXJncygpIGF0IF9fbG9j a21ncl9hcmdzKzB4YzJhCnZvcF9zdGRsb2NrKCkgYXQgdm9wX3N0ZGxvY2srMHgzOQpWT1BfTE9D SzFfQVBWKCkgYXQgVk9QX0xPQ0sxX0FQVisweDliCl92bl9sb2NrKCkgYXQgX3ZuX2xvY2srMHg0 Nwp2cmVsZSgpIGF0IHZyZWxlKzB4MTMzCmRvdW5tb3VudCgpIGF0IGRvdW5tb3VudCsweDJhYwp2 ZnNfdW5tb3VudGFsbCgpIGF0IHZmc191bm1vdW50YWxsKzB4NTQKYm9vdCgpIGF0IGJvb3QrMHg3 YWYKcmVib290KCkgYXQgcmVib290KzB4NDIKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgxYmYKWGZh c3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhhYgotLS0gc3lzY2FsbCAoNTUsIEZyZWVC U0QgRUxGNjQsIHJlYm9vdCksIHJpcCA9IDB4NDA4OTdjLCByc3AgPSAweDdmZmZmZmZmZTdiOCwg cmJwID0gMHg0MDI0MjAgLS0tCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5v dCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3Jj ZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91 bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNF IGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQs IHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlz IG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBG b3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191 bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZP UkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0 ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50 IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBd OiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnpm c191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBwb3J0ZWQsIHJlbW92aW5n IEZPUkNFIGZsYWcuCnpmc191bW91bnQ6OTY5WzBdOiBGb3JjZSB1bm1vdW50IGlzIG5vdCBzdXBw b3J0ZWQsIHJlbW92aW5nIEZPUkNFIGZsYWcuCnVubW91bnQgb2YgLyBmYWlsZWQgKEJVU1kpClVw dGltZTogMTZoM20xMXMKQ29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVj dC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkx LCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxp Zm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFk ZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtQ1VSUkVOVCAjOTog VHVlIE5vdiAxOCAyMToxNDowMSBDRVQgMjAwOAogICAgcm9vdEBza2FkZS5nbHouaGlkZGVuLXBv d2Vycy5jb206L3Vzci9vYmovdXNyL3NyYy9zeXMvU1RECldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9u IGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpUaW1lY291bnRlciAiaTgyNTQi IGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEFNRCBBdGhsb24odG0pIDY0IFgy IER1YWwgQ29yZSBQcm9jZXNzb3IgNTAwMCsgKDI2MDAuMjYtTUh6IEs4LWNsYXNzIENQVSkKICBP cmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDYwZmIyICBTdGVwcGluZyA9IDIKICBGZWF0 dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxT RVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIs SFRUPgogIEZlYXR1cmVzMj0weDIwMDE8U1NFMyxDWDE2PgogIEFNRCBGZWF0dXJlcz0weGVhNTAw ODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixSRFRTQ1AsTE0sM0ROb3chKywzRE5vdyE+CiAgQU1E IEZlYXR1cmVzMj0weDExZjxMQUhGLENNUCxTVk0sRXh0QVBJQyxDUjgsUHJlZmV0Y2g+CiAgVFND OiBQLXN0YXRlIGludmFyaWFudAogIENvcmVzIHBlciBwYWNrYWdlOiAyCnVzYWJsZSBtZW1vcnkg PSA0Mjc3NDg1NTY4ICg0MDc5IE1CKQphdmFpbCBtZW1vcnkgID0gNDExMzU4MDAzMiAoMzkyMyBN QikKQUNQSSBBUElDIFRhYmxlOiA8MDgyNzA4IEFQSUMxNDM3PgpGcmVlQlNEL1NNUDogTXVsdGlw cm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAw CiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxClRoaXMgbW9kdWxlIChvcGVuc29sYXJpcykgY29udGFp bnMgY29kZSBjb3ZlcmVkIGJ5IHRoZQpDb21tb24gRGV2ZWxvcG1lbnQgYW5kIERpc3RyaWJ1dGlv biBMaWNlbnNlIChDRERMKQpzZWUgaHR0cDovL29wZW5zb2xhcmlzLm9yZy9vcy9saWNlbnNpbmcv b3BlbnNvbGFyaXNfbGljZW5zZS8KaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBt b3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYXRoX2hhbDogMC4xMC41LjEwIChBUjUyMTAsIEFS NTIxMSwgQVI1MjEyLCBBUjU0MTYsIFJGNTExMSwgUkY1MTEyLCBSRjI0MTMsIFJGNTQxMywgUkYy MTMzLCBSRjI0MjUsIFJGMjQxNykKYWNwaTA6IDwwODI3MDggWFNEVDE0Mzc+IG9uIG1vdGhlcmJv YXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmFjcGkwOiBy ZXNlcnZhdGlvbiBvZiBmZWZlMTAwMCwgMTAwMCAoMykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlv biBvZiBmZWUwMTAwMCwgZmYwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVj MDAwMDAsIDEwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVlMDAwMDAsIDEw MDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAph Y3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCBjZmYwMDAwMCAoMykgZmFpbGVkClRpbWVjb3Vu dGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3Rp bWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDUwOC0weDUwYiBvbiBh Y3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVk MDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDI1 MDAwMDAwIEh6IHF1YWxpdHkgOTAwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQg MHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDog PG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8 UENJLUlTQSBicmlkZ2U+IHBvcnQgMHg5MDAtMHg5ZmYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwCmlz YTA6IDxJU0EgYnVzPiBvbiBpc2FiMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmlj ZSAxLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKb2hjaTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29u dHJvbGxlcj4gbWVtIDB4ZjllZmYwMDAtMHhmOWVmZmZmZiBpcnEgMjEgYXQgZGV2aWNlIDIuMCBv biBwY2kwCm9oY2kwOiBbSVRIUkVBRF0KdXNidXMwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRy b2xsZXI+IG9uIG9oY2kwCmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVy PiBtZW0gMHhmOWVmZWMwMC0weGY5ZWZlY2ZmIGlycSAyMiBhdCBkZXZpY2UgMi4xIG9uIHBjaTAK ZWhjaTA6IFtJVEhSRUFEXQp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMxOiA8RUhDSSAo Z2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApvaGNpMTogPE9IQ0kgKGdlbmVy aWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmOWVmZDAwMC0weGY5ZWZkZmZmIGlycSAyMyBhdCBk ZXZpY2UgNC4wIG9uIHBjaTAKb2hjaTE6IFtJVEhSRUFEXQp1c2J1czI6IDxPSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTEKZWhjaTE6IDxFSENJIChnZW5lcmljKSBVU0IgMi4w IGNvbnRyb2xsZXI+IG1lbSAweGY5ZWZlODAwLTB4ZjllZmU4ZmYgaXJxIDIwIGF0IGRldmljZSA0 LjEgb24gcGNpMAplaGNpMTogW0lUSFJFQURdCnVzYnVzMzogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1 czM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kxCmF0YXBjaTA6 IDxuVmlkaWEgbkZvcmNlIE1DUDY3IFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFm NywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZmYTAtMHhmZmFmIGF0IGRldmljZSA2LjAgb24g cGNpMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEwOiBbSVRIUkVBRF0KYXRh MTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhMTogW0lUSFJFQURdCnBjaTA6IDxtdWx0 aW1lZGlhLCBIREE+IGF0IGRldmljZSA3LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgOC4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjEKcGNpMTogPHNlcmlhbCBidXMsIEZpcmVXaXJlPiBhdCBkZXZpY2UgNy4w IChubyBkcml2ZXIgYXR0YWNoZWQpCmF0YXBjaTE6IDxuVmlkaWEgbkZvcmNlIE1DUDY3IFNBVEEz MDAgY29udHJvbGxlcj4gcG9ydCAweGM0ODAtMHhjNDg3LDB4YzQwMC0weGM0MDMsMHhjMDgwLTB4 YzA4NywweGMwMDAtMHhjMDAzLDB4YmMwMC0weGJjMGYgbWVtIDB4ZjllZjYwMDAtMHhmOWVmN2Zm ZiBpcnEgMjIgYXQgZGV2aWNlIDkuMCBvbiBwY2kwCmF0YXBjaTE6IFtJVEhSRUFEXQphdGFwY2kx OiBBSENJIGNhbGxlZCBmcm9tIHZlbmRvciBzcGVjaWZpYyBkcml2ZXIKYXRhcGNpMTogQUhDSSBW ZXJzaW9uIDAxLjEwIGNvbnRyb2xsZXIgd2l0aCA0IHBvcnRzIFBNIHN1cHBvcnRlZAphdGEyOiA8 QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGEyOiBbSVRIUkVBRF0KYXRhMzogPEFUQSBjaGFu bmVsIDE+IG9uIGF0YXBjaTEKYXRhMzogW0lUSFJFQURdCmF0YTQ6IDxBVEEgY2hhbm5lbCAyPiBv biBhdGFwY2kxCmF0YTQ6IFtJVEhSRUFEXQphdGE1OiA8QVRBIGNoYW5uZWwgMz4gb24gYXRhcGNp MQphdGE1OiBbSVRIUkVBRF0KbmZlMDogPE5WSURJQSBuRm9yY2UgTUNQNjcgTmV0d29ya2luZyBB ZGFwdGVyPiBwb3J0IDB4Yjg4MC0weGI4ODcgbWVtIDB4ZjllZmMwMDAtMHhmOWVmY2ZmZiwweGY5 ZWZlNDAwLTB4ZjllZmU0ZmYsMHhmOWVmZTAwMC0weGY5ZWZlMDBmIGlycSAyMyBhdCBkZXZpY2Ug MTAuMCBvbiBwY2kwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBuZmUwCmF0cGh5MDogPEF0aGVyb3Mg RjEgMTAvMTAwLzEwMDAgUEhZPiBQSFkgMSBvbiBtaWlidXMwCmF0cGh5MDogIDEwYmFzZVQsIDEw YmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVC1GRFgsIGF1dG8K bmZlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MWQ6NjA6OWE6OGY6NGUKbmZlMDogW0ZJTFRFUl0K bmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRF Ul0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KcGNpYjI6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTEuMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIyCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4 ZWMwMC0weGVjN2YgbWVtIDB4ZmQwMDAwMDAtMHhmZGZmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZm ZmYsMHhmYTAwMDAwMC0weGZiZmZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKcGNp YjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTIuMCBvbiBwY2kwCnBjaTM6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIzCnBjaWI0OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAx My4wIG9uIHBjaTAKcGNpNDogPFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8UENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxNC4wIG9uIHBjaTAKcGNpNTogPFBDSSBidXM+IG9uIHBjaWI1CnBjaWI2 OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxNS4wIG9uIHBjaTAKcGNpNjogPFBDSSBidXM+ IG9uIHBjaWI2CnBjaWI3OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxNi4wIG9uIHBjaTAK cGNpNzogPFBDSSBidXM+IG9uIHBjaWI3CnBjaWI4OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAxNy4wIG9uIHBjaTAKcGNpODogPFBDSSBidXM+IG9uIHBjaWI4CmFjcGlfYnV0dG9uMDogPFBv d2VyIEJ1dHRvbj4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3 MC0weDcxIG9uIGFjcGkwCnVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0w eDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnVhcnQwOiBbRklMVEVSXQpjcHUwOiA8QUNQ SSBDUFU+IG9uIGFjcGkwCnBvd2Vybm93MDogPFBvd2VyTm93ISBLOD4gb24gY3B1MApjcHUxOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCnBvd2Vybm93MTogPFBvd2VyTm93ISBLOD4gb24gY3B1MQphdGti ZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBp c2EwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQw CmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KcHBjMDogY2Fubm90IHJl c2VydmUgSS9PIHBvcnQgcmFuZ2UKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAw IG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2Ew OiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhi ZmZmZiBvbiBpc2EwCldBUk5JTkc6IFpGUyBpcyBjb25zaWRlcmVkIHRvIGJlIGFuIGV4cGVyaW1l bnRhbCBmZWF0dXJlIGluIEZyZWVCU0QuClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1z ZWMKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMApaRlMgZmlsZXN5c3RlbSB2ZXJz aW9uIDEzClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbiAxMwp1Z2VuMC4xOiA8blZpZGlhPiBhdCB1 c2J1czAKdXNodWIwOiA8blZpZGlhIE9IQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdXNodWIwOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1c2J1czE6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMS4x OiA8blZpZGlhPiBhdCB1c2J1czEKdXNodWIxOiA8blZpZGlhIEVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKdXNodWIxOiA2IHBvcnRzIHdp dGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1c2J1czI6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wCnVnZW4yLjE6IDxuVmlkaWE+IGF0IHVzYnVzMgp1c2h1YjI6IDxuVmlkaWEgT0hDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1c2h1 YjI6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVzYnVzMzogNDgwTWJw cyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4zLjE6IDxuVmlkaWE+IGF0IHVzYnVzMwp1c2h1YjM6 IDxuVmlkaWEgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzMwp1c2h1YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk CmFjZDA6IERWRFJPTSA8RFZEMTY0OC9CS0gvVkVSIEEwMDE+IGF0IGF0YTAtbWFzdGVyIFVETUEz MwphY2QxOiBETUEgbGltaXRlZCB0byBVRE1BMzMsIGRldmljZSBmb3VuZCBub24tQVRBNjYgY2Fi bGUKYWNkMTogRFZEUiA8TElURS1PTiBEVkRSVyBTT0hXLTE2NTNTL0NTMDk+IGF0IGF0YTAtc2xh dmUgVURNQTMzCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgy NCBhc2NxPTB4MDAgCmFkNDogOTc3TUIgPFNhbkRpc2sgU0RDRlgtMTAyNCBIRFggMy4xNz4gYXQg YXRhMi1tYXN0ZXIgV0RNQTIKYWNkMTogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBSRVFVRVNU IGFzYz0weDI0IGFzY3E9MHgwMCAKYWQ2OiA3NjMxOU1CIDxTZWFnYXRlIFNUMzgwODE1QVMgMy5B QUQ+IGF0IGF0YTMtbWFzdGVyIFNBVEEzMDAKYWQ4OiA3NjMxOU1CIDxTZWFnYXRlIFNUMzgwODE1 QVMgMy5BQUQ+IGF0IGF0YTQtbWFzdGVyIFNBVEEzMDAKR0VPTV9MQUJFTDogTGFiZWwgZm9yIHBy b3ZpZGVyIGFkNHMxYSBpcyB1ZnMvcm9vdC4KYWNkMDogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdB TCBSRVFVRVNUIGFzYz0weDI0IGFzY3E9MHgwMCAKYWNkMTogRkFJTFVSRSAtIElOUVVJUlkgSUxM RUdBTCBSRVFVRVNUIGFzYz0weDI0IGFzY3E9MHgwMCAKY2QwIGF0IGF0YTAgYnVzIDAgdGFyZ2V0 IDAgbHVuIDAKY2QwOiA8RFZELTE2WCBEVkQxNjQ4L0JLSCBBMDAxPiBSZW1vdmFibGUgQ0QtUk9N IFNDU0ktMCBkZXZpY2UgCmNkMDogMzMuMDAwTUIvcyB0cmFuc2ZlcnMKY2QwOiBBdHRlbXB0IHRv IHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQK Y2QxIGF0IGF0YTAgYnVzIDAgdGFyZ2V0IDEgbHVuIDAKY1NkTTFQOjogIEE8UEwgSUNUUEVVLSBP I04gMUQgVkxEYVJ1V24gY1NoT2VIZFchLQoxNjUzUyBDUzA5PiBSZW1vdmFibGUgQ0QtUk9NIFND U0ktMCBkZXZpY2UgCmNkMTogMzMuMDAwTUIvcyB0cmFuc2ZlcnMKY2QxOiBBdHRlbXB0IHRvIHF1 ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQKV0FS TklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2Uu ClRyeWluZyB0byBtb3VudCByb290IGZyb20gemZzOnN5c3RlbS9ib290CnVnZW4zLjI6IDxTdGFu ZGFyZCBNaWNyb3N5c3RlbXM+IGF0IHVzYnVzMwp1c2h1YjQ6IDxTdGFuZGFyZCBNaWNyb3N5c3Rl bXMgcHJvZHVjdCAweDI1MjQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRkciAyPiBvbiB1 c2J1czMKdXNodWI0OiA0IHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApsb2Nr IG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDAwMjRmNzA3MCB1c2VyIG1hcCAodXNlciBt YXApIEAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjMxMTUKIDJuZCAweGZmZmZmZjAwMDJlNmM5 ZDAgemZzICh6ZnMpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMDUzCktEQjogc3Rh Y2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dy YXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUK d2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODFlCl9fbG9ja21n cl9hcmdzKCkgYXQgX19sb2NrbWdyX2FyZ3MrMHhjYTgKdm9wX3N0ZGxvY2soKSBhdCB2b3Bfc3Rk bG9jaysweDM5ClZPUF9MT0NLMV9BUFYoKSBhdCBWT1BfTE9DSzFfQVBWKzB4OWIKX3ZuX2xvY2so KSBhdCBfdm5fbG9jaysweDQ3CnZnZXQoKSBhdCB2Z2V0KzB4OGIKdm5vZGVfcGFnZXJfbG9jaygp IGF0IHZub2RlX3BhZ2VyX2xvY2srMHgxZDAKdm1fZmF1bHQoKSBhdCB2bV9mYXVsdCsweDFlMgp0 cmFwX3BmYXVsdCgpIGF0IHRyYXBfcGZhdWx0KzB4MTI4CnRyYXAoKSBhdCB0cmFwKzB4NTFjCmNh bGx0cmFwKCkgYXQgY2FsbHRyYXArMHg4Ci0tLSB0cmFwIDB4YywgcmlwID0gMHg0MDAxNGYsIHJz cCA9IDB4N2ZmZmZmZmZlZTcwLCByYnAgPSAweDdmZmZmZmZmZWU5MCAtLS0KdWdlbjMuMzogPEJl bGtpbiBDb3Jwb3JhdGlvbj4gYXQgdXNidXMzCnVoaWQwOiA8RmxpcCBDQyBEZXZpY2U+IG9uIHVz YnVzMwpTeW1saW5rOiB1aGlkMCAtPiB1c2IzLjMuMC4xNgpXQVJOSU5HOiBUTVBGUyBpcyBjb25z aWRlcmVkIHRvIGJlIGEgaGlnaGx5IGV4cGVyaW1lbnRhbCBmZWF0dXJlIGluIEZyZWVCU0QuCnVn ZW4zLjQ6IDxUYWJsZXQ+IGF0IHVzYnVzMwp1bXMwOiA8VGFibGV0IFhELTA2MDgtVSwgY2xhc3Mg MC8wLCByZXYgMS4xMC8xLjI2LCBhZGRyIDQ+IG9uIHVzYnVzMwp1bXMwOiAzIGJ1dHRvbnMgYW5k IFtYWVpdIGNvb3JkaW5hdGVzClN5bWxpbms6IHVtczAgLT4gdXNiMy40LjAuMTYKdWdlbjMuNTog PExvZ2l0ZWNoPiBhdCB1c2J1czMKdWtiZDA6IDxMb2dpdGVjaCBwcm9kdWN0IDB4YzMwZSwgY2xh c3MgMC8wLCByZXYgMS4xMC8xLjgwLCBhZGRyIDU+IG9uIHVzYnVzMwprYmQyIGF0IHVrYmQwCnVo aWQxOiA8TG9naXRlY2ggcHJvZHVjdCAweGMzMGUsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMS44MCwg YWRkciA1PiBvbiB1c2J1czMKU3ltbGluazogdWhpZDEgLT4gdXNiMy41LjEuMTYK --==========52BF8DA64A91923468FB==========-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 23:10:50 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1077B1065675; Tue, 18 Nov 2008 23:10:50 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (mail.hidden-powers.com [213.242.135.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC7B8FC2B; Tue, 18 Nov 2008 23:10:49 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (localhost [127.0.0.1]) by dkim.hidden-powers.com (Postfix) with ESMTP id EEE9F6D5C7; Wed, 19 Nov 2008 00:10:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hidden-powers.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=81Cn4lp Yr03KFnUiqx2gBnY7esw=; b=p7mXyM59/nL7nom7qwrm/tZN4xwOUtsH6BVzAx9 p0H7s43RRLN0bErAAdjVuXde1o0z6Po9LxkieExG7VtCdH8/oxrQdDvWSCwI97f0 YKRFmg6O91VTq9TV4+CU/HyZhHsfyznn2JdmRQ0lwQLgR2Vi7aKX0z443BBHF170 8cXw= Received: from [10.255.253.2] (unknown [10.255.253.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hidden-powers.com (Postfix) with ESMTPSA id E1C736D5C5; Wed, 19 Nov 2008 00:10:47 +0100 (CET) Date: Wed, 19 Nov 2008 00:10:47 +0100 From: Goran Lowkrantz To: Pawel Jakub Dawidek , freebsd-current@FreeBSD.org Message-ID: <78EC94D3B4D5F26E79D8136D@[10.255.253.2]> In-Reply-To: <6299055A289A8E23BC3AD0A2@[10.255.253.2]> References: <20081117205526.GC1733@garage.freebsd.pl> <20081118222731.GG1634@garage.freebsd.pl> <6299055A289A8E23BC3AD0A2@[10.255.253.2]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 23:10:50 -0000 --On Tuesday, November 18, 2008 23:37 +0100 Goran Lowkrantz wrote: > --On Tuesday, November 18, 2008 23:27 +0100 Pawel Jakub Dawidek > wrote: > >> On Tue, Nov 18, 2008 at 11:23:36PM +0100, Goran Lowkrantz wrote: >>> --On Monday, November 17, 2008 21:55 +0100 Pawel Jakub Dawidek >>> wrote: >>> >>> > Hi. >>> > >>> > So ZFS was updated from version 6 to 13. Be very careful when updating >>> > your system if you use ZFS. The number of changes is huge and my >>> > regression tests and manual tests I did only cover part of the entire >>> > functionality. >>> > >>> > More info here: >>> > >>> > http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 >>> > >>> > Enjoy. >>> > >>> > -- >>> > Pawel Jakub Dawidek http://www.wheel.pl >>> > pjd@FreeBSD.org http://www.FreeBSD.org >>> > FreeBSD committer Am I Evil? Yes, I Am! >>> >>> On amd64, I get an error when I try to enable xattr: >>> # zfs get xattr system/boot >>> NAME PROPERTY VALUE SOURCE >>> system/boot xattr off temporary >>> # zfs get xattr system >>> NAME PROPERTY VALUE SOURCE >>> system xattr on default >>> # zfs inherit xattr system/boot >>> WARNING pid 2282 (zfs): ioctl sign-extension ioctl ffffffffcc285a2e >>> # zfs get xattr system/boot >>> NAME PROPERTY VALUE SOURCE >>> system/boot xattr off temporary >>> >>> Have http://svn.freebsd.org/changeset/base/185039. >>> >>> Attached dmesg.boot from the last couple of reboots. >>> >>> This is so far the only thing I have found. >> >> It has been fixed already. >> >> -- >> Pawel Jakub Dawidek http://www.wheel.pl >> pjd@FreeBSD.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! > > Do you mean that it's in current? I am using a kernel from 3 hr ago with > 185039 and the numeric attribute errors are gone but this is a boolean > attribute and I still get the error. > Just realized that I am lying. I still get dmesg output when listing some properties of this file system. Could it be because I upgraded the pool to version 13 with a kernel before 185039? I get WARNING on getting any of these properties: system/boot xattr off temporary system/boot version 1 - system/boot utf8only off - system/boot normalization none - /glz From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 23:11:02 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BDD3106564A for ; Tue, 18 Nov 2008 23:11:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 01DE98FC13 for ; Tue, 18 Nov 2008 23:11:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4904A4569A; Wed, 19 Nov 2008 00:11:00 +0100 (CET) Received: from localhost (unknown [216.239.45.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 81C8E45685; Wed, 19 Nov 2008 00:10:54 +0100 (CET) Date: Wed, 19 Nov 2008 00:10:51 +0100 From: Pawel Jakub Dawidek To: Goran Lowkrantz Message-ID: <20081118231051.GH1634@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> <20081118222731.GG1634@garage.freebsd.pl> <6299055A289A8E23BC3AD0A2@[10.255.253.2]> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AzNpbZlgThVzWita" Content-Disposition: inline In-Reply-To: <6299055A289A8E23BC3AD0A2@[10.255.253.2]> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 23:11:02 -0000 --AzNpbZlgThVzWita Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2008 at 11:37:35PM +0100, Goran Lowkrantz wrote: > --On Tuesday, November 18, 2008 23:27 +0100 Pawel Jakub Dawidek=20 > wrote: >=20 > >On Tue, Nov 18, 2008 at 11:23:36PM +0100, Goran Lowkrantz wrote: > >>--On Monday, November 17, 2008 21:55 +0100 Pawel Jakub Dawidek > >> wrote: > >> > >>> Hi. > >>> > >>> So ZFS was updated from version 6 to 13. Be very careful when updating > >>> your system if you use ZFS. The number of changes is huge and my > >>> regression tests and manual tests I did only cover part of the entire > >>> functionality. > >>> > >>> More info here: > >>> > >>> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D185029 > >>> > >>> Enjoy. > >>> > >>> -- > >>> Pawel Jakub Dawidek http://www.wheel.pl > >>> pjd@FreeBSD.org http://www.FreeBSD.org > >>> FreeBSD committer Am I Evil? Yes, I Am! > >> > >>On amd64, I get an error when I try to enable xattr: > >># zfs get xattr system/boot > >>NAME PROPERTY VALUE SOURCE > >>system/boot xattr off temporary > >># zfs get xattr system > >>NAME PROPERTY VALUE SOURCE > >>system xattr on default > >># zfs inherit xattr system/boot > >>WARNING pid 2282 (zfs): ioctl sign-extension ioctl ffffffffcc285a2e > >># zfs get xattr system/boot > >>NAME PROPERTY VALUE SOURCE > >>system/boot xattr off temporary > >> > >>Have http://svn.freebsd.org/changeset/base/185039. > >> > >>Attached dmesg.boot from the last couple of reboots. > >> > >>This is so far the only thing I have found. > > > >It has been fixed already. > > > >-- > >Pawel Jakub Dawidek http://www.wheel.pl > >pjd@FreeBSD.org http://www.FreeBSD.org > >FreeBSD committer Am I Evil? Yes, I Am! >=20 > Do you mean that it's in current? I am using a kernel from 3 hr ago with= =20 > 185039 and the numeric attribute errors are gone but this is a boolean=20 > attribute and I still get the error. I only fixed the warning about sign-extension. I'll look into extattrs. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --AzNpbZlgThVzWita Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJI0t7ForvXbEpPzQRAm6nAJ9msR4s33kJqTcyOtU30ozSNCMZIACdECqW iHeylGHSPO81avdizzy6TU4= =VQhv -----END PGP SIGNATURE----- --AzNpbZlgThVzWita-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 23:40:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49C871065675 for ; Tue, 18 Nov 2008 23:40:17 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp802.mail.ird.yahoo.com (smtp802.mail.ird.yahoo.com [217.146.188.62]) by mx1.freebsd.org (Postfix) with SMTP id 8B49F8FC16 for ; Tue, 18 Nov 2008 23:40:16 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 96013 invoked from network); 18 Nov 2008 23:40:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=3PLh6PNLCFEx5mA8x+YJQydoMFgGbGYyNmkJDi4Jf3pY3U5Nqcx913jY5IF/DaRPiWJCjBl+spY63gvdxSZodolobLkocPKf63MNZjGN5ZfiOC0IcNUZ2/lxL6QHgzluCe5j1mAcv+sTUXCthilzQO8S24ndEI9NKCe+VpM8hrM= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.48.69 with login) by smtp802.mail.ird.yahoo.com with SMTP; 18 Nov 2008 23:40:14 -0000 X-YMail-OSG: j6aVUL0VM1n.zUeGhXSiaHqquznn57TliHHMWzbWKk674nEnxbZx_5BBK872.w_Naw6h6pT9ZNa_zYTMbU_1O3.WgS.UaYrTHPzjV0fZF75S_KRTus0Xy16e4TjSPQdaU44uF8k9FRzJmihd2C4OeRkBdvRmRvnkOy4ZH80- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Tue, 18 Nov 2008 23:40:13 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811182150.52248.Thomas.Sparrevohn@btinternet.com> <20081118215638.GF1634@garage.freebsd.pl> In-Reply-To: <20081118215638.GF1634@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811182340.13372.Thomas.Sparrevohn@btinternet.com> Cc: Pawel Jakub Dawidek Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2008 23:40:17 -0000 On Tuesday 18 November 2008 21:56:38 Pawel Jakub Dawidek wrote: > On Tue, Nov 18, 2008 at 09:50:51PM +0000, Thomas Sparrevohn wrote: > > On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: > > > > > > What's unexpected in that? As I noted it still needs more work, so > > > chflags(2) working properly would be unexpected for me:) > > > > > > > -------------------------------------------------------------- > > > > LOL - Unexpected that it just not returns operation not supported as it used to - I was a bit > > trigger happy and upgraded my main pool - against the sound advice - leaves me in a bit of trouble ;-) > > Try 'make installworld NO_FSCHG='. > LOL and now I feel really stupid - thanks From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 01:03:19 2008 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 4A1341065672 for ; Wed, 19 Nov 2008 01:03:19 +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 2BDD88FC0C for ; Wed, 19 Nov 2008 01:03:19 +0000 (UTC) (envelope-from randy@psg.com) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2bTS-000LOB-2Q for current@freebsd.org; Wed, 19 Nov 2008 01:03:18 +0000 Message-ID: <492365D5.7000405@psg.com> Date: Tue, 18 Nov 2008 19:03:17 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: lor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 01:03:19 -0000 install from 1108 snap lock order reversal: 1st 0xc356c044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xc36f57ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2047 KDB: stack backtrace: db_trace_self_wrapper(c0bc6589,c3276910,c0839fb5,4,c0bc1dde,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bc1dde,c351e728,c3522fe0,c327696c,...) at kdb_backtrace+0x29 _witness_debugger(c0bc9214,c36f57ac,c0bbd1e7,c3522fe0,c0bcffb0,...) at _witness_debugger+0x25 witness_checkorder(c36f57ac,1,c0bcffb0,7ff,0,...) at witness_checkorder+0x839 __lockmgr_args(c36f57ac,200501,c36f57c8,0,0,...) at __lockmgr_args+0x237 ffs_lock(c3276a78,c0bebcee,c0bbc8f8,200501,c36f5754,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cc3420,c3276a78,c0cdee20,c36f5754,200501,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c36f5754,200501,c0bcffb0,7ff,4,...) at _vn_lock+0x5e vget(c36f5754,200501,c3568d20,4b4,0,...) at vget+0xc9 vnode_pager_lock(c187e934,0,c0be92b4,127,c3276c18,...) at vnode_pager_lock+0x1e0 vm_fault(c356c000,80db000,2,8,80db160,...) at vm_fault+0x1df trap_pfault(5,0,c0bf9107,2e7,c3566d0c,...) at trap_pfault+0x118 trap(c3276d38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 06:48:34 2008 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 B439A1065670 for ; Wed, 19 Nov 2008 06:48:34 +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 3B1BC8FC0C for ; Wed, 19 Nov 2008 06:48:33 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.18] (port=35055 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2grX-000LW8-I6 for current@freebsd.org; Wed, 19 Nov 2008 09:48:31 +0300 Message-ID: <4923B6BF.3060101@lissyara.su> Date: Wed, 19 Nov 2008 09:48:31 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.17) Gecko/20080929 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: cannot build XEN kernel on amd64 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 06:48:34 -0000 lissyara# uname -a FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Nov 18 18:24:01 MSK 2008 lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/GENERIC amd64 lissyara# make buildkernel KERNCONF=XEN TARGET_ARCH=i386 ......... skipped ......... -------------------------------------------------------------- >>> stage 3.1: making dependencies -------------------------------------------------------------- cd /usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/XEN; MAKEOBJDIRPREFIX=/usr/obj/i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp VERSION="FreeBSD 8.0-CURRENT amd64 800053" INSTALL="sh /mnt/jabber/DISTR/FreeBSD/src/CURRENT/tools/install.sh" PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/sbin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/bin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/games:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/usr/sbin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/usr/bin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make KERNEL=kernel depend -DNO_MODULES_OBJ machine -> /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/include cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/altq -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/ipfilter -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/pf -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/dev/ath -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/ngatm -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/dev/twa -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/gnu/fs/xfs/FreeBSD -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/gnu/fs/xfs/FreeBSD/support -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/gnu/fs/xfs -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/opensolaris/compat -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/i386/genassym.c /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/i386/genassym.c:1: error: -mpreferred-stack-boundary=2 is not between 4 and 12 *** Error code 1 Stop in /usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/XEN. *** Error code 1 Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT. *** Error code 1 Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT. lissyara# From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 07:21:09 2008 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 29BEF106564A for ; Wed, 19 Nov 2008 07:21:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (unknown [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id BECC88FC14 for ; Wed, 19 Nov 2008 07:21:08 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id B94321CCEC; Wed, 19 Nov 2008 08:21:07 +0100 (CET) Date: Wed, 19 Nov 2008 08:21:07 +0100 From: Ed Schouten To: Alex Keda Message-ID: <20081119072107.GB81783@hoeg.nl> References: <4923B6BF.3060101@lissyara.su> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ejxBj3YzjByOPzh0" Content-Disposition: inline In-Reply-To: <4923B6BF.3060101@lissyara.su> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: cannot build XEN kernel on amd64 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 07:21:09 -0000 --ejxBj3YzjByOPzh0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Alex, * Alex Keda wrote: > /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/i386/genassym.c:1: error: = =20 > -mpreferred-stack-boundary=3D2 is not between 4 and 12 Be sure to compile an i386 kernel using an amd64 toolchain. This should do the trick: make TARGET_ARCH=3Di386 kernel-toolchain --=20 Ed Schouten WWW: http://80386.nl/ --ejxBj3YzjByOPzh0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkkjvmMACgkQ52SDGA2eCwWQywCbBHU+nZoCSkDT23bqDL1oQbI0 r6oAn2sEEwR1zuTP1jAFySNsVpaZ2JBN =F+AU -----END PGP SIGNATURE----- --ejxBj3YzjByOPzh0-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 07:22:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8F82106564A; Wed, 19 Nov 2008 07:22:32 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 856B68FC0A; Wed, 19 Nov 2008 07:22:32 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (unknown [74.193.182.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 6DE8AA23F250; Wed, 19 Nov 2008 01:22:31 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id mAJ7Moen006171; Wed, 19 Nov 2008 01:22:50 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Wed, 19 Nov 2008 01:22:50 -0600 (CST) From: Wes Morgan To: Pawel Jakub Dawidek In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 07:22:33 -0000 On Mon, 17 Nov 2008, Pawel Jakub Dawidek wrote: > Hi. > > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. I'm hitting this at reboot, with a zfs root: zfs_vfsops.c:969 ZFS_LOG(0, "Force unmount is not supported, removing FORCE flag."); Followed by a "cannot unmount / (busy)" (however it shows up) error. Looking at the code, it looks like that message is simply to be expected... From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 07:25:44 2008 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 9CF991065672 for ; Wed, 19 Nov 2008 07:25:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 6F75E8FC0A for ; Wed, 19 Nov 2008 07:25:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3154633rvf.43 for ; Tue, 18 Nov 2008 23:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=phdBN61qqKtXfze4Lj5k02a/WvMdVUj0awoYvBuFvBg=; b=OMlifasoSpWmb26K9AR4Vi09INAkJBacx0t1GVNoVbyPcHvDuvU1osCpRDei+26wx0 Z9yDNBRUr+tWL5MXprHZsFI1KzMH+NW7TS/f/Wmwh0nfYEhribrGuX+86je+VHIcqJho ftR+/s2iuBTvMdVVSrHeg8u9w72+nZosRqkPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=f4HFiX6LCkWB07sLSbrNfJEBoHEu4CLm1bfQ05XSq8ujDk6G/hXNNdSSV06ak/oXQ1 7eVP6P4TPEHgAjpF/ev2e9dcZ8N9n36a567XnvoxKHPJlJYLxIBUaDzH3L+IXVoF2/nl 01GfM8608EEE4VBTSyPFWO6Xd57J/cUPs9yXE= Received: by 10.141.97.5 with SMTP id z5mr425636rvl.104.1227077565009; Tue, 18 Nov 2008 22:52:45 -0800 (PST) Received: by 10.141.27.8 with HTTP; Tue, 18 Nov 2008 22:52:44 -0800 (PST) Message-ID: <3c1674c90811182252q5902853dn3685d9edf1c86d8f@mail.gmail.com> Date: Wed, 19 Nov 2008 06:52:44 +0000 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Alex Keda" In-Reply-To: <4923B6BF.3060101@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4923B6BF.3060101@lissyara.su> X-Google-Sender-Auth: d9608aa4c522d2b0 Cc: current@freebsd.org Subject: Re: cannot build XEN kernel on amd64 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 07:25:44 -0000 You need to build kernel-toolchain for cross-compile first. -Kip On Wed, Nov 19, 2008 at 6:48 AM, Alex Keda wrote: > lissyara# uname -a > FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Nov 18 > 18:24:01 MSK 2008 > lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/GENERIC > amd64 > lissyara# make buildkernel KERNCONF=XEN TARGET_ARCH=i386 > > ......... skipped ......... > > -------------------------------------------------------------- >>>> stage 3.1: making dependencies > -------------------------------------------------------------- > cd /usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/XEN; > MAKEOBJDIRPREFIX=/usr/obj/i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp > VERSION="FreeBSD 8.0-CURRENT amd64 800053" INSTALL="sh > /mnt/jabber/DISTR/FreeBSD/src/CURRENT/tools/install.sh" > PATH=/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/sbin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/bin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/legacy/usr/games:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/usr/sbin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/usr/bin:/usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > NO_CTF=1 make KERNEL=kernel depend -DNO_MODULES_OBJ > machine -> /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/include > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/altq > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/ipfilter > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/pf > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/dev/ath > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/ngatm > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/dev/twa > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/gnu/fs/xfs/FreeBSD > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/gnu/fs/xfs/FreeBSD/support > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/gnu/fs/xfs > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/contrib/opensolaris/compat > -I/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/dev/cxgb -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 > --param inline-unit-growth=100 --param large-function-growth=1000 > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector > /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/i386/genassym.c > /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/i386/genassym.c:1: error: > -mpreferred-stack-boundary=2 is not between 4 and 12 > *** Error code 1 > > Stop in /usr/obj/i386/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/XEN. > *** Error code 1 > > Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT. > *** Error code 1 > > Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT. > lissyara# _______________________________________________ > 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 we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 08:37:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F9A1065670 for ; Wed, 19 Nov 2008 08:37:38 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 624458FC0C for ; Wed, 19 Nov 2008 08:37:38 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so2117277nfh.33 for ; Wed, 19 Nov 2008 00:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-pgp-agent:x-mailer; bh=1NcITBK0O5TCOBzAq/Awu/G0/iTmmB42AxuraUC4Grs=; b=riJzTwltA1UmtV3qp+aODdpmEyM/dvZ8eYZvmN1uw8xa8tIFqiuoKhb6ISfQx0koDX sHEq0iKS00gQtey3rxLLurzkSO2dgspzn5VFRVadnMOehhchVaLfKdtbOefwtztKIIss DE3Qpss09Z1flRF7XMFzB8WbUhzAb08vqSMfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-pgp-agent:x-mailer; b=Zzfx30dz93VpFA/td6EkV0FoJ344CbVFOjCpHuagAlSh6B6D+KUWhjdw6uRgunDSXN nUizbGafqFM3lkhqcCAD8rLaFAT2dxZm98gvcQat+Mlm6MYyzkAiq9IJ/0bG/5922S5B YdI/GRd4VMj/o9ADRsqWfANlyRs8uRlsOpRVM= Received: by 10.103.217.5 with SMTP id u5mr285261muq.42.1227083856862; Wed, 19 Nov 2008 00:37:36 -0800 (PST) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id y6sm17606671mug.7.2008.11.19.00.37.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Nov 2008 00:37:35 -0800 (PST) Message-Id: <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> From: Nikolay Denev To: freebsd-current@freebsd.org In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 10:37:32 +0200 References: <20081117205526.GC1733@garage.freebsd.pl> X-Pgp-Agent: GPGMail d53 (v53, Leopard) X-Mailer: Apple Mail (2.929.2) Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 08:37:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17 Nov, 2008, at 22:55 , Pawel Jakub Dawidek wrote: > Hi. > > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. > > More info here: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 > > Enjoy. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! Hi Pawel, Thanks for you excellent work on ZFS! I want to report that I got again a kmem_map_too_small panic on recent - - -current with the new ZFS version. I left the machine overnight with an endless loop running bonnie++ on a raidz2 zfs pool with five disks, and I found it dead this morning. Is this still supposed to happen? I had only these two lines in my loader.conf : vm.kmem_size="1536M" vm.kmem_size_max="1536M" and i have just added vfs.zfs.arc_max="768M" and will run the torture test again. (the default value for arc_max was 1006632960) Btw, the machine is amd64 with four gigabytes of RAM, and I have upgraded the pool to version 13. Thanks! - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkkj0E0ACgkQHNAJ/fLbfrnQ2ACdFWNUKgZALVICj/6/2gMPhSzl 6/AAoLqDt8MfIgA+qAZQAhHf65sdGYjS =9y3s -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 09:03:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5349A1065677 for ; Wed, 19 Nov 2008 09:03:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 35F378FC08 for ; Wed, 19 Nov 2008 09:03:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id gx1Y1a0090lTkoCA6x38Ut; Wed, 19 Nov 2008 09:03:08 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id gx371a0032P6wsM8Qx37fg; Wed, 19 Nov 2008 09:03:07 +0000 X-Authority-Analysis: v=1.0 c=1 a=UoFpbzuMWasA:10 a=6I5d2MoRAAAA:8 a=VCWGMLH5AAAA:8 a=QycZ5dHgAAAA:8 a=qh7XOIbw7Ni0UhPFmAkA:9 a=0Mxh1sGAf6u8Xbe0_bAA:7 a=h07Q2xGec6516Wll__uKOyAoEYsA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 44F5533C36; Wed, 19 Nov 2008 01:03:07 -0800 (PST) Date: Wed, 19 Nov 2008 01:03:07 -0800 From: Jeremy Chadwick To: Nikolay Denev Message-ID: <20081119090307.GA81236@icarus.home.lan> References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 09:03:08 -0000 On Wed, Nov 19, 2008 at 10:37:32AM +0200, Nikolay Denev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 17 Nov, 2008, at 22:55 , Pawel Jakub Dawidek wrote: > >> Hi. >> >> So ZFS was updated from version 6 to 13. Be very careful when updating >> your system if you use ZFS. The number of changes is huge and my >> regression tests and manual tests I did only cover part of the entire >> functionality. >> >> More info here: >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 >> >> Enjoy. >> >> -- Pawel Jakub Dawidek http://www.wheel.pl >> pjd@FreeBSD.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! > > Hi Pawel, > > Thanks for you excellent work on ZFS! > > I want to report that I got again a kmem_map_too_small panic on recent - > - -current with the new ZFS version. > I left the machine overnight with an endless loop running bonnie++ on a > raidz2 zfs pool with five disks, > and I found it dead this morning. > Is this still supposed to happen? > > I had only these two lines in my loader.conf : > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > > and i have just added vfs.zfs.arc_max="768M" and will > run the torture test again. (the default value for arc_max was > 1006632960) The ARC was set to allocate up to 1006M of the 1536M, which probably caused kmem exhaustion. The ARC value you picked may still be too large, but it will require continual testing on your part. But see below first. > Btw, the machine is amd64 with four gigabytes of RAM, and I have > upgraded the pool to version 13. Since this is CURRENT, you should be able to increase the kmem_size and kmem_size_max entries to something larger than 1536M, especially since the box has 4GB of RAM. (You shouldn't do this on RELENG_7). You might also consider disabling prefetch; there are reports of peoples' boxes locking up hard (requiring a hard reset) when prefetch is enabled. Others (like myself) just see "better overall system responsiveness" when prefetch is disabled. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 09:40:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F265A1065679; Wed, 19 Nov 2008 09:40:31 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id C69258FC2C; Wed, 19 Nov 2008 09:40:31 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:10607 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2jJG-000Nf4-6R; Wed, 19 Nov 2008 03:25:20 -0600 Date: Wed, 19 Nov 2008 03:25:15 -0600 (CST) From: Larry Rosenman Sender: ler@borg To: Jeremy Chadwick In-Reply-To: <20081119090307.GA81236@icarus.home.lan> Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> <20081119090307.GA81236@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.3 (--) X-LERCTR-Spam-Score: -2.3 (--) X-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_ZF=0.077 X-LERCTR-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931, TW_ZF=0.077 DomainKey-Status: no signature Cc: Nikolay Denev , freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 09:40:32 -0000 On Wed, 19 Nov 2008, Jeremy Chadwick wrote: > > Since this is CURRENT, you should be able to increase the kmem_size > and kmem_size_max entries to something larger than 1536M, especially > since the box has 4GB of RAM. (You shouldn't do this on RELENG_7). > > You might also consider disabling prefetch; there are reports of > peoples' boxes locking up hard (requiring a hard reset) when prefetch > is enabled. Others (like myself) just see "better overall system > responsiveness" when prefetch is disabled. Just as a note, with a -CURRENT from shortly after the ZFS upgrade, the vm.kmem* tuneables, without ANY override on my 4G amd64 box: vm.kmem_size_scale: 3 vm.kmem_size_max: 4509713203 vm.kmem_size_min: 0 vm.kmem_size: 1381195776 this is with a 2T zfs array, if that matters. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 09:48:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F9E6106564A for ; Wed, 19 Nov 2008 09:48:24 +0000 (UTC) (envelope-from ndenev@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 22CBA8FC13 for ; Wed, 19 Nov 2008 09:48:23 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so1322360eyi.7 for ; Wed, 19 Nov 2008 01:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-pgp-agent:x-mailer; bh=ctMX6eG1XawuPLmKvJ9cKuHLzdRP6HB6JgLtxbeUWug=; b=aW5r33a8Cst9i24ey1jA1lqidQq55cuTDC+bTCPPEsOYOCRCAyK1BcxnBJRHlbOoVm h3y/wIPc58FE9f/CrxjAasRd4r9E+2C3pdztpeTA9g/WS/SJZ//bjqXcyw+pDSJe7+nF bjP3tGWp5t97ApqiVMwfLMtiqm2TXRHy6Nc04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-pgp-agent:x-mailer; b=mqw3JRXYo+lyCqAZ0Hdkk0OAH/4fBC9cda1bdr2sQg2lKZbREbJB4r0NTFf28TFnlH 8/B3y+ZxlG1QSjjnASfVUZFSVIcDEjSeKobqWUqyr/KzLSX838Jpr4u2zNq02cASapkl SShXNowsaSy9N3eNWZmYz0g7Zx5Q45NN7V+H8= Received: by 10.103.131.18 with SMTP id i18mr290389mun.120.1227088102815; Wed, 19 Nov 2008 01:48:22 -0800 (PST) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id j9sm6876129mue.3.2008.11.19.01.48.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Nov 2008 01:48:21 -0800 (PST) Message-Id: From: Nikolay Denev To: Larry Rosenman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 11:48:17 +0200 References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> <20081119090307.GA81236@icarus.home.lan> X-Pgp-Agent: GPGMail d53 (v53, Leopard) X-Mailer: Apple Mail (2.929.2) Cc: Jeremy Chadwick , freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 09:48:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov, 2008, at 11:25 , Larry Rosenman wrote: > On Wed, 19 Nov 2008, Jeremy Chadwick wrote: > >> >> Since this is CURRENT, you should be able to increase the kmem_size >> and kmem_size_max entries to something larger than 1536M, especially >> since the box has 4GB of RAM. (You shouldn't do this on RELENG_7). >> >> You might also consider disabling prefetch; there are reports of >> peoples' boxes locking up hard (requiring a hard reset) when prefetch >> is enabled. Others (like myself) just see "better overall system >> responsiveness" when prefetch is disabled. > Just as a note, with a -CURRENT from shortly after the ZFS upgrade, > the vm.kmem* tuneables, without ANY override on my 4G amd64 box: > > vm.kmem_size_scale: 3 > vm.kmem_size_max: 4509713203 > vm.kmem_size_min: 0 > vm.kmem_size: 1381195776 > > this is with a 2T zfs array, if that matters. > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 Well, it looks like that on -current and a 4G amd64 machine probably there is no need to tune anything. Here are my defaults with everything vm and zfs related in loader.conf commented : vm.kmem_size_max: 4509713203 vfs.zfs.arc_max: 863907840 - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkkj4OEACgkQHNAJ/fLbfrkuRgCgqwvwgFubaHeL1UL516ITcekI 6e4An2+hUp1V5Ped6BKVJ7LaAoyVahNt =tuNb -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 10:13:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B28F81065670 for ; Wed, 19 Nov 2008 10:13:20 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 32FF98FC08 for ; Wed, 19 Nov 2008 10:13:19 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L2k3h-0001qW-D4 for freebsd-current@freebsd.org; Wed, 19 Nov 2008 10:13:17 +0000 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, 19 Nov 2008 10:13:17 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 10:13:17 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Nov 2008 11:14:02 +0100 Lines: 44 Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> <200811182150.52248.Thomas.Sparrevohn@btinternet.com> <20081118215638.GF1634@garage.freebsd.pl> <200811182340.13372.Thomas.Sparrevohn@btinternet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig94D6C23DA93EE55DEBA97FF9" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: <200811182340.13372.Thomas.Sparrevohn@btinternet.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 10:13:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig94D6C23DA93EE55DEBA97FF9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thomas Sparrevohn wrote: > On Tuesday 18 November 2008 21:56:38 Pawel Jakub Dawidek wrote: >> On Tue, Nov 18, 2008 at 09:50:51PM +0000, Thomas Sparrevohn wrote: >>> On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: >>>> What's unexpected in that? As I noted it still needs more work, so >>>> chflags(2) working properly would be unexpected for me:) >>>> >>>>> -------------------------------------------------------------- >>> LOL - Unexpected that it just not returns operation not supported as = it used to - I was a bit >>> trigger happy and upgraded my main pool - against the sound advice - = leaves me in a bit of trouble ;-) >> Try 'make installworld NO_FSCHG=3D'. >> >=20 > LOL and now I feel really stupid - thanks Hmmm, I did an installworld from UFS to ZFS yesterday without special flags (actually, multiple installworlds for benchmarking), without errors. Files really did get schg (or equivalent) flag since I couldn't rm them afterwards. How is this possible? :) --------------enig94D6C23DA93EE55DEBA97FF9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJI+bqldnAQVacBcgRAmpoAJ4osQdpb2eJagntAbORMRNxn7hr8QCg2XpD dbafUpNpVCadoXC76ZHEwfg= =wrU6 -----END PGP SIGNATURE----- --------------enig94D6C23DA93EE55DEBA97FF9-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 10:13:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F631065701 for ; Wed, 19 Nov 2008 10:13:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD398FC12 for ; Wed, 19 Nov 2008 10:13:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA03.westchester.pa.mail.comcast.net with comcast id gy4P1a00316LCl053yCpen; Wed, 19 Nov 2008 10:12:49 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA06.westchester.pa.mail.comcast.net with comcast id gyDm1a00L2P6wsM3SyDnhr; Wed, 19 Nov 2008 10:13:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=UoFpbzuMWasA:10 a=6VqBrpBaAAAA:8 a=QycZ5dHgAAAA:8 a=oydLpk_76dDEq0tLX_4A:9 a=RkjAjTsfDuh_-YXShVIA:7 a=jMdACBzFH7T3uMEgSFKaEp4IR_EA:4 a=DC3OrDK0E1IA:10 a=EoioJ0NPDVgA:10 a=h-mJ8WrWerMA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 9105C33C36; Wed, 19 Nov 2008 02:13:46 -0800 (PST) Date: Wed, 19 Nov 2008 02:13:46 -0800 From: Jeremy Chadwick To: Nikolay Denev Message-ID: <20081119101346.GA82818@icarus.home.lan> References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> <20081119090307.GA81236@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org, Larry Rosenman Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 10:13:48 -0000 On Wed, Nov 19, 2008 at 11:48:17AM +0200, Nikolay Denev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 19 Nov, 2008, at 11:25 , Larry Rosenman wrote: > >> On Wed, 19 Nov 2008, Jeremy Chadwick wrote: >> >>> >>> Since this is CURRENT, you should be able to increase the kmem_size >>> and kmem_size_max entries to something larger than 1536M, especially >>> since the box has 4GB of RAM. (You shouldn't do this on RELENG_7). >>> >>> You might also consider disabling prefetch; there are reports of >>> peoples' boxes locking up hard (requiring a hard reset) when prefetch >>> is enabled. Others (like myself) just see "better overall system >>> responsiveness" when prefetch is disabled. >> Just as a note, with a -CURRENT from shortly after the ZFS upgrade, >> the vm.kmem* tuneables, without ANY override on my 4G amd64 box: >> >> vm.kmem_size_scale: 3 >> vm.kmem_size_max: 4509713203 >> vm.kmem_size_min: 0 >> vm.kmem_size: 1381195776 >> >> this is with a 2T zfs array, if that matters. >> >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > > Well, it looks like that on -current and a 4G amd64 machine probably > there is no need > to tune anything. Here are my defaults with everything vm and zfs > related in loader.conf commented : > > vm.kmem_size_max: 4509713203 > vfs.zfs.arc_max: 863907840 I've discussed ZFS tuning with another FreeBSD user 2-3 months ago. I lost 8 years worth of Email recently, so I can't go back and check who he was and what exactly was said. He was saying that under normal circumstances (in RELENG_7 and CURRENT), tuning should not really be necessary. He also pointed out that the way we're tuning things (specifically the variables we're using) are partially incorrect; some are unnecessary, such as arc_min. I'll see if I can find the mail on a mailing list (I think it was a public mail), but it'll take me some time. The information in the mail is very good, and should probably be pulled in to the ZFS Tuning wiki. Give me a while to find it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 10:14:46 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C4301065678 for ; Wed, 19 Nov 2008 10:14:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 16BD38FC2C for ; Wed, 19 Nov 2008 10:14:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1L2k4p-0006dW-NO>; Wed, 19 Nov 2008 11:14:27 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1L2k57-0000IE-6R>; Wed, 19 Nov 2008 11:14:45 +0100 Message-ID: <4923E685.3060805@zedat.fu-berlin.de> Date: Wed, 19 Nov 2008 10:12:21 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: OpenLDAP 2.4.11/12 and FreeBSD 8.0/AMD64 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 10:14:46 -0000 I'm wondering if someone out here has successfully running OpenLDAP 2.4.11/12 slapd on a most recently compiled FreeBSD 8.0/amd64 system. If so, please let me know. On our experimental host (FBSD 8.0/CURRENT/AMD64) slapd dies with signal 11 immediately after starting. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 10:28:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91D871065680 for ; Wed, 19 Nov 2008 10:28:18 +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 494F88FC12 for ; Wed, 19 Nov 2008 10:28:18 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.18] (port=41967 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2kIC-000FEd-20 for freebsd-current@freebsd.org; Wed, 19 Nov 2008 13:28:16 +0300 Message-ID: <4923EA3F.2000801@lissyara.su> Date: Wed, 19 Nov 2008 13:28:15 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.17) Gecko/20080929 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Subject: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 10:28:18 -0000 I replace default GENERIC kernel on my XEN kernel in FreeBSD installation CD-ROM (i386 7.0-RELEASE) But, I cannot boot in XEN - I see fast run "BTX halted" and many other debugging info. ======= Can I boot from FreeBSD CD-ROM in XEN? From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 10:28:57 2008 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 2449E106567A for ; Wed, 19 Nov 2008 10:28:57 +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 C234A8FC2A for ; Wed, 19 Nov 2008 10:28:56 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1L2k1e-0005fU-2S>; Wed, 19 Nov 2008 11:11: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 <1L2k1v-00005n-He>; Wed, 19 Nov 2008 11:11:27 +0100 Message-ID: <4923E5BF.1090507@zedat.fu-berlin.de> Date: Wed, 19 Nov 2008 10:09:03 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: Ed Schouten References: <4923B6BF.3060101@lissyara.su> <20081119072107.GB81783@hoeg.nl> In-Reply-To: <20081119072107.GB81783@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Alex Keda , current@freebsd.org Subject: [OT] XEN and AMD64? Was: Re: cannot build XEN kernel on amd64 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 10:28:57 -0000 Ed Schouten wrote: > Hello Alex, > > * Alex Keda wrote: >> /mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/i386/i386/genassym.c:1: error: >> -mpreferred-stack-boundary=2 is not between 4 and 12 > > Be sure to compile an i386 kernel using an amd64 toolchain. This should > do the trick: > > make TARGET_ARCH=i386 kernel-toolchain > Hello, I'm very curious about XEN and FreeBSD, but I saw XEN only in the i386 part of the source tree, which implies there is only 32 Bit support. I'm not very familiar with XEN, but it comes to more interest as CPUs have better VM facilities so I would like to know whether FreeBSD will have amd64 support for virtualization or will it be stuck at i386 as it is with the Linuxulator? Well, I'm mainly interested in HPC, so virtual machines are some kind of 'out of focus' at the moment, I apologize if I lack in rudimenatry knowledge and if someone wants me first having read XEN related stuff (just in case XEN is all over 32 Bit and also Linux has only 32 Bit virtual environments). Thanks in advance, Oliver From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 10:33:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5381065670 for ; Wed, 19 Nov 2008 10:33:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 03BE38FC0C for ; Wed, 19 Nov 2008 10:33:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id gyVy1a0041HpZEsA1yZTvn; Wed, 19 Nov 2008 10:33:27 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id gyZS1a0062P6wsM8ayZSpS; Wed, 19 Nov 2008 10:33:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=CFfxueBw-RKTJqL6X_cA:9 a=ZFgMFEppMsjcV_KnnHt3FM7J5wAA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id A7B4733C36; Wed, 19 Nov 2008 02:33:26 -0800 (PST) Date: Wed, 19 Nov 2008 02:33:26 -0800 From: Jeremy Chadwick To: Alex Keda Message-ID: <20081119103326.GA83222@icarus.home.lan> References: <4923EA3F.2000801@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4923EA3F.2000801@lissyara.su> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 10:33:28 -0000 On Wed, Nov 19, 2008 at 01:28:15PM +0300, Alex Keda wrote: > I replace default GENERIC kernel on my XEN kernel in FreeBSD > installation CD-ROM (i386 7.0-RELEASE) > But, I cannot boot in XEN - I see fast run "BTX halted" and many other > debugging info. BTX halted is a message coming from either boot2 or loader, not the kernel. Do you see the FreeBSD beastie logo/menu before you see this message? > Can I boot from FreeBSD CD-ROM in XEN? I know nothing about Xen (what it is, what purpose it serves, etc.). If it's a "hardware emulator" of some sort, then I'd be wary of it. Try things on real hardware if possible. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:01:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D8B31065673 for ; Wed, 19 Nov 2008 11:01:23 +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 C613D8FC23 for ; Wed, 19 Nov 2008 11:01:22 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.18] (port=15434 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2koD-000MUg-CM for freebsd-current@freebsd.org; Wed, 19 Nov 2008 14:01:21 +0300 Message-ID: <4923F201.6080606@lissyara.su> Date: Wed, 19 Nov 2008 14:01:21 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.17) Gecko/20080929 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <4923EA3F.2000801@lissyara.su> <20081119103326.GA83222@icarus.home.lan> In-Reply-To: <20081119103326.GA83222@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:01:23 -0000 Jeremy Chadwick пишет: > On Wed, Nov 19, 2008 at 01:28:15PM +0300, Alex Keda wrote: > >> I replace default GENERIC kernel on my XEN kernel in FreeBSD >> installation CD-ROM (i386 7.0-RELEASE) >> But, I cannot boot in XEN - I see fast run "BTX halted" and many other >> debugging info. >> > BTX halted is a message coming from either boot2 or loader, not the > kernel. Do you see the FreeBSD beastie logo/menu before you see this > message? > No, but, messages go very fast - I'm doubt. > >> Can I boot from FreeBSD CD-ROM in XEN? >> > > I know nothing about Xen (what it is, what purpose it serves, etc.). > If it's a "hardware emulator" of some sort, then I'd be wary of it. > Try things on real hardware if possible. > I try original CD - same behavior... From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:15:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 587A51065672 for ; Wed, 19 Nov 2008 11:15:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 39D738FC0C for ; Wed, 19 Nov 2008 11:15:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id gzC71a0030S2fkCA1zFml6; Wed, 19 Nov 2008 11:15:46 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id gzFm1a0012P6wsM8VzFmKe; Wed, 19 Nov 2008 11:15:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=YnUTlXJAjDXndqS_MBYA:9 a=NB_EfuGUzuEEMovSHCQA:7 a=6TPlTdImNSD8zM2qU-gkn-61hVgA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 0191333C36; Wed, 19 Nov 2008 03:15:45 -0800 (PST) Date: Wed, 19 Nov 2008 03:15:45 -0800 From: Jeremy Chadwick To: Alex Keda Message-ID: <20081119111545.GA84854@icarus.home.lan> References: <4923EA3F.2000801@lissyara.su> <20081119103326.GA83222@icarus.home.lan> <4923F201.6080606@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4923F201.6080606@lissyara.su> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:15:47 -0000 On Wed, Nov 19, 2008 at 02:01:21PM +0300, Alex Keda wrote: > Jeremy Chadwick ??????????: >> On Wed, Nov 19, 2008 at 01:28:15PM +0300, Alex Keda wrote: >> >>> I replace default GENERIC kernel on my XEN kernel in FreeBSD >>> installation CD-ROM (i386 7.0-RELEASE) >>> But, I cannot boot in XEN - I see fast run "BTX halted" and many >>> other debugging info. >>> >> BTX halted is a message coming from either boot2 or loader, not the >> kernel. Do you see the FreeBSD beastie logo/menu before you see this >> message? >> > No, but, messages go very fast - I'm doubt. >> >>> Can I boot from FreeBSD CD-ROM in XEN? >>> >> >> I know nothing about Xen (what it is, what purpose it serves, etc.). >> If it's a "hardware emulator" of some sort, then I'd be wary of it. >> Try things on real hardware if possible. >> > I try original CD - same behavior... Can you please try using a 7.1-PRERELEASE i386 CD instead? There were BTX changes made between 7.0 and 7.1 which may fix this (using real mode for BTX). Those changes are documented in my Wiki (see bottom): http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:19:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2578D1065670 for ; Wed, 19 Nov 2008 11:19:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id BFCCF8FC14 for ; Wed, 19 Nov 2008 11:19:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA08.westchester.pa.mail.comcast.net with comcast id gyqx1a00L0xGWP858zJSCw; Wed, 19 Nov 2008 11:18:26 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA12.westchester.pa.mail.comcast.net with comcast id gzK41a00E2P6wsM3YzK55r; Wed, 19 Nov 2008 11:19:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=0AYfKEgqb7A1LDLgDMAA:9 a=-jyUaLmhbmK13KtvZR8A:7 a=oM2rc5MhoFfh-KCZOdIh_KfTLpkA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id A4A4433C36; Wed, 19 Nov 2008 03:19:04 -0800 (PST) Date: Wed, 19 Nov 2008 03:19:04 -0800 From: Jeremy Chadwick To: Alex Keda Message-ID: <20081119111904.GA84939@icarus.home.lan> References: <4923EA3F.2000801@lissyara.su> <20081119103326.GA83222@icarus.home.lan> <4923F201.6080606@lissyara.su> <20081119111545.GA84854@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081119111545.GA84854@icarus.home.lan> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:19:08 -0000 On Wed, Nov 19, 2008 at 03:15:45AM -0800, Jeremy Chadwick wrote: > On Wed, Nov 19, 2008 at 02:01:21PM +0300, Alex Keda wrote: > > Jeremy Chadwick ??????????: > >> On Wed, Nov 19, 2008 at 01:28:15PM +0300, Alex Keda wrote: > >> > >>> I replace default GENERIC kernel on my XEN kernel in FreeBSD > >>> installation CD-ROM (i386 7.0-RELEASE) > >>> But, I cannot boot in XEN - I see fast run "BTX halted" and many > >>> other debugging info. > >>> > >> BTX halted is a message coming from either boot2 or loader, not the > >> kernel. Do you see the FreeBSD beastie logo/menu before you see this > >> message? > >> > > No, but, messages go very fast - I'm doubt. > >> > >>> Can I boot from FreeBSD CD-ROM in XEN? > >>> > >> > >> I know nothing about Xen (what it is, what purpose it serves, etc.). > >> If it's a "hardware emulator" of some sort, then I'd be wary of it. > >> Try things on real hardware if possible. > >> > > I try original CD - same behavior... > > Can you please try using a 7.1-PRERELEASE i386 CD instead? There were > BTX changes made between 7.0 and 7.1 which may fix this (using real mode > for BTX). Those changes are documented in my Wiki (see bottom): > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Also, I just realised you've posted to -current about issues with a 7.x release. Why is that? :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:26:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15118106564A for ; Wed, 19 Nov 2008 11:26:03 +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 C71508FC16 for ; Wed, 19 Nov 2008 11:26:02 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 8ED6C6D43F; Wed, 19 Nov 2008 11:26:01 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7466384490; Wed, 19 Nov 2008 12:26:00 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alex Keda References: <4923EA3F.2000801@lissyara.su> Date: Wed, 19 Nov 2008 12:26:00 +0100 In-Reply-To: <4923EA3F.2000801@lissyara.su> (Alex Keda's message of "Wed, 19 Nov 2008 13:28:15 +0300") Message-ID: <863ahoot2v.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (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: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:26:03 -0000 Alex Keda writes: > I replace default GENERIC kernel on my XEN kernel in FreeBSD > installation CD-ROM (i386 7.0-RELEASE) But, I cannot boot in XEN - I > see fast run "BTX halted" and many other debugging info. You should ask . DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:28:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F246B1065675 for ; Wed, 19 Nov 2008 11:28:04 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by mx1.freebsd.org (Postfix) with ESMTP id 511298FC1A for ; Wed, 19 Nov 2008 11:28:04 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by gxk5 with SMTP id 5so180928gxk.19 for ; Wed, 19 Nov 2008 03:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=VXZikxjEI21YpBZSeKx8JvgJz4QeqatyrKqPj1GKcVM=; b=ezr/26dRO5paKbSdAbV/Y6ABBDdx+ANfMiWo1UBqZyyZeRv0RlbpkRxeJGgJilXbrP 1N689nm/d4g9ofvKTXT1Ww3CtSr7ChCb0HKzjAzBMJnEPCGOsPBDVRbKFoO8pQK6jjyJ tVineUctkV8bmEGQSiIMDf2vnVj954VYSTm4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=e87fgu1vS1z1ckPyCXxxrT5yyjZZxJn4TgEA7JdZYh4aiaJ90c025Wu0JG7sfERW2D H+PrVkcMvzPiRkByzaBwdXHYX1H2nIIpOikOIqJGoZ96Ca+98HVbqRz+LqsrHyibRyJ3 tTAHFiAVRMPQm0P/2ZvyexJj6tQDnBKYm//Dk= Received: by 10.151.102.16 with SMTP id e16mr1902807ybm.129.1227093696076; Wed, 19 Nov 2008 03:21:36 -0800 (PST) Received: by 10.151.106.2 with HTTP; Wed, 19 Nov 2008 03:21:36 -0800 (PST) Message-ID: <3481d8e60811190321t366aa286lb3bcaa865267c118@mail.gmail.com> Date: Wed, 19 Nov 2008 11:21:36 +0000 From: "Benoit Calvez" Sender: dzentoo@gmail.com To: "Jeremy Chadwick" In-Reply-To: <20081119111904.GA84939@icarus.home.lan> MIME-Version: 1.0 References: <4923EA3F.2000801@lissyara.su> <20081119103326.GA83222@icarus.home.lan> <4923F201.6080606@lissyara.su> <20081119111545.GA84854@icarus.home.lan> <20081119111904.GA84939@icarus.home.lan> X-Google-Sender-Auth: 858b35c39dcf681f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:28:05 -0000 > > Also, I just realised you've posted to -current about issues with > a 7.x release. Why is that? :-) > there is also a ML for freebsd-xen http://lists.freebsd.org/mailman/listinfo/freebsd-xen -- Benoit Calvez. Epitech Student. Promo 2009. www.epitech.net From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:31:31 2008 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 59EEF106567D; Wed, 19 Nov 2008 11:31:31 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1B08FC13; Wed, 19 Nov 2008 11:31:30 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 13D2F9B649; Wed, 19 Nov 2008 12:03:16 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.7 Received: from [192.168.200.110] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id CD4049B646; Wed, 19 Nov 2008 12:03:13 +0100 (CET) From: Marko Zec To: current@freebsd.org, virtualization@freebsd.org Date: Wed, 19 Nov 2008 12:02:54 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811191202.54465.zec@icir.org> Cc: Subject: HEADS UP: initialization of kernel global variables (Fwd: svn commit: r185088) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 11:31:31 -0000 As a part of an effort to merge network stack virtualization=20 infrastructure (also known as project virtnet / vimage) to head,=20 initialization of global kernel variables which are scheduled to become=20 virtualized should now adhere to a simple yet important new rule.=20 Initialization of such variables should no longer be performed at=20 instatiation point, but instead assignments of initial values should be=20 done in initializer functions. This should have zero functional impact=20 to existing code, but will allow us to switch between using global=20 variables and their counterparts residing in virtualization containers=20 with minimum code churn, and in the long run allow us to intialize=20 multiple instances of such container structures. Note that this change applies only to global variables related to the=20 network stack, and only to the subset of those that have been selected=20 for virtualization as in sys/net/vnet.h, sys/netinet/vinet.h,=20 sys/netinet6/vinet6.h, sys/netipsec/vipsec.h etc. No other subsystems=20 will be affected at this point in time.=A0A MFC of this change to=20 stable/7 or older branches is not planned. Cheers, Marko =2D--------- Forwarded Message ---------- Subject: svn commit: r185088 - in head/sys: dev/cxgb/ulp/tom net netinet=20 netinet6 netipsec sys Date: Wednesday 19 November 2008 =46rom: Marko Zec To: src-committers@freebsd.org, svn-src-all@freebsd.org,=20 svn-src-head@freebsd.org Author: zec Date: Wed Nov 19 09:39:34 2008 New Revision: 185088 URL: http://svn.freebsd.org/changeset/base/185088 Log: Change the initialization methodology for global variables scheduled for virtualization. =20 Instead of initializing the affected global variables at instatiation, assign initial values to them in initializer functions. As a rule, initialization at instatiation for such variables should never be introduced again from now on. Furthermore, enclose all instantiations of such global variables in #ifdef VIMAGE_GLOBALS blocks. =20 Essentialy, this change should have zero functional impact. In the=20 next phase of merging network stack virtualization infrastructure from p4/vimage branch, the new initialization methology will allow us to switch between using global variables and their counterparts residing=20 in virtualization containers with minimum code churn, and in the long run allow us to intialize multiple instances of such container structures. =20 Discussed at: devsummit Strassburg Reviewed by: bz, julian Approved by: julian (mentor) Obtained from: //depot/projects/vimage-commit2/... X-MFC after: never Sponsored by: NLnet Foundation, The FreeBSD Foundation Modified: head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c head/sys/net/if.c head/sys/net/if_ethersubr.c head/sys/net/if_gif.c head/sys/net/if_loop.c head/sys/net/raw_cb.c head/sys/net/route.c head/sys/netinet/if_ether.c head/sys/netinet/igmp.c head/sys/netinet/in.c head/sys/netinet/in_gif.c head/sys/netinet/in_mcast.c head/sys/netinet/in_pcb.c head/sys/netinet/in_pcb.h head/sys/netinet/in_proto.c head/sys/netinet/in_rmx.c head/sys/netinet/in_var.h head/sys/netinet/ip_divert.c head/sys/netinet/ip_fastfwd.c head/sys/netinet/ip_icmp.c head/sys/netinet/ip_icmp.h head/sys/netinet/ip_input.c head/sys/netinet/ip_output.c head/sys/netinet/raw_ip.c head/sys/netinet/tcp_hostcache.c head/sys/netinet/tcp_input.c head/sys/netinet/tcp_output.c head/sys/netinet/tcp_reass.c head/sys/netinet/tcp_sack.c head/sys/netinet/tcp_subr.c head/sys/netinet/tcp_syncache.c head/sys/netinet/tcp_timewait.c head/sys/netinet/tcp_var.h head/sys/netinet/udp_usrreq.c head/sys/netinet/vinet.h head/sys/netinet6/frag6.c head/sys/netinet6/icmp6.c head/sys/netinet6/in6_ifattach.c head/sys/netinet6/in6_proto.c head/sys/netinet6/in6_rmx.c head/sys/netinet6/in6_src.c head/sys/netinet6/ip6_forward.c head/sys/netinet6/ip6_input.c head/sys/netinet6/ip6_mroute.c head/sys/netinet6/mld6.c head/sys/netinet6/nd6.c head/sys/netinet6/nd6_nbr.c head/sys/netinet6/nd6_rtr.c head/sys/netinet6/raw_ip6.c head/sys/netinet6/scope6.c head/sys/netinet6/vinet6.h head/sys/netipsec/ipsec.c head/sys/netipsec/ipsec.h head/sys/netipsec/key.c head/sys/netipsec/keysock.c head/sys/netipsec/xform_ah.c head/sys/netipsec/xform_esp.c head/sys/netipsec/xform_ipcomp.c head/sys/netipsec/xform_ipip.c head/sys/sys/vimage.h Modified: head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c Wed Nov 19 08:56:35 2008=09 (r185087) +++ head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c Wed Nov 19 09:39:34 2008=09 (r185088) @@ -154,11 +154,6 @@ static unsigned int mbuf_wrs[TX_MAX_SEGS #define TCP_CLOSE 2 #define TCP_DROP 3 =20 =2Dextern int tcp_do_autorcvbuf; =2Dextern int tcp_do_autosndbuf; =2Dextern int tcp_autorcvbuf_max; =2Dextern int tcp_autosndbuf_max; =2D static void t3_send_reset(struct toepcb *toep); static void send_abort_rpl(struct mbuf *m, struct toedev *tdev, int=20 rst_status); static inline void free_atid(struct t3cdev *cdev, unsigned int tid); Modified: head/sys/net/if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/net/if.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/net/if.c Wed Nov 19 09:39:34 2008 (r185088) @@ -134,22 +134,21 @@ static int if_getgroupmembers(struct ifg extern void nd6_setmtu(struct ifnet *); #endif =20 =2Dint if_index =3D 0; =2Dint ifqmaxlen =3D IFQ_MAXLEN; +#ifdef VIMAGE_GLOBALS struct ifnethead ifnet; /* depend on static init XXX */ struct ifgrouphead ifg_head; +int if_index; +static int if_indexlim; +/* Table of ifnet/cdev by index. Locked with ifnet_lock. */ +static struct ifindex_entry *ifindex_table; +static struct knlist ifklist; +#endif + +int ifqmaxlen =3D IFQ_MAXLEN; struct mtx ifnet_lock; static if_com_alloc_t *if_com_alloc[256]; static if_com_free_t *if_com_free[256]; =20 =2Dstatic int if_indexlim =3D 8; =2Dstatic struct knlist ifklist; =2D =2D/* =2D * Table of ifnet/cdev by index. Locked with ifnet_lock. =2D */ =2Dstatic struct ifindex_entry *ifindex_table =3D NULL; =2D static void filt_netdetach(struct knote *kn); static int filt_netdev(struct knote *kn, long hint); =20 @@ -357,6 +356,10 @@ if_init(void *dummy __unused) { INIT_VNET_NET(curvnet); =20 + V_if_index =3D 0; + V_ifindex_table =3D NULL; + V_if_indexlim =3D 8; + IFNET_LOCK_INIT(); TAILQ_INIT(&V_ifnet); TAILQ_INIT(&V_ifg_head); Modified: head/sys/net/if_ethersubr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/net/if_ethersubr.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/net/if_ethersubr.c Wed Nov 19 09:39:34 2008 (r185088) @@ -142,8 +142,10 @@ MALLOC_DEFINE(M_ARPCOM, "arpcom", "802.* int ether_ipfw_chk(struct mbuf **m0, struct ifnet *dst, struct ip_fw **rule, int shared); +#ifdef VIMAGE_GLOBALS static int ether_ipfw; #endif +#endif =20 /* * Ethernet output routine. Modified: head/sys/net/if_gif.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/net/if_gif.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/net/if_gif.c Wed Nov 19 09:39:34 2008 (r185088) @@ -94,7 +94,18 @@ */ static struct mtx gif_mtx; static MALLOC_DEFINE(M_GIF, "gif", "Generic Tunnel Interface"); + +#ifdef VIMAGE_GLOBALS static LIST_HEAD(, gif_softc) gif_softc_list; +static int max_gif_nesting; +static int parallel_tunnels; +#ifdef INET +int ip_gif_ttl; +#endif +#ifdef INET6 +int ip6_gif_hlim; +#endif +#endif =20 void (*ng_gif_input_p)(struct ifnet *ifp, struct mbuf **mp, int af); void (*ng_gif_input_orphan_p)(struct ifnet *ifp, struct mbuf *m, int=20 af); @@ -123,9 +134,6 @@ SYSCTL_NODE(_net_link, IFT_GIF, gif, CTL */ #define MAX_GIF_NEST 1 #endif =2D#ifndef VIMAGE =2Dstatic int max_gif_nesting =3D MAX_GIF_NEST; =2D#endif SYSCTL_V_INT(V_NET, vnet_gif, _net_link_gif, OID_AUTO, max_nesting, CTLFLAG_RW, max_gif_nesting, 0, "Max nested tunnels"); =20 @@ -140,11 +148,6 @@ SYSCTL_V_INT(V_NET, vnet_gif, _net_inet6 * pair of addresses. Some applications require this functionality so * we allow control over this check here. */ =2D#ifdef XBONEHACK =2Dstatic int parallel_tunnels =3D 1; =2D#else =2Dstatic int parallel_tunnels =3D 0; =2D#endif SYSCTL_V_INT(V_NET, vnet_gif, _net_link_gif, OID_AUTO,=20 parallel_tunnels, CTLFLAG_RW, parallel_tunnels, 0, "Allow parallel tunnels?"); =20 @@ -251,12 +254,21 @@ gifmodevent(mod, type, data) switch (type) { case MOD_LOAD: mtx_init(&gif_mtx, "gif_mtx", NULL, MTX_DEF); =2D LIST_INIT(&V_gif_softc_list); =2D if_clone_attach(&gif_cloner); =20 + LIST_INIT(&V_gif_softc_list); + V_max_gif_nesting =3D MAX_GIF_NEST; +#ifdef XBONEHACK + V_parallel_tunnels =3D 1; +#else + V_parallel_tunnels =3D 0; +#endif +#ifdef INET + V_ip_gif_ttl =3D GIF_TTL; +#endif #ifdef INET6 V_ip6_gif_hlim =3D GIF_HLIM; #endif + if_clone_attach(&gif_cloner); =20 break; case MOD_UNLOAD: Modified: head/sys/net/if_loop.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/net/if_loop.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/net/if_loop.c Wed Nov 19 09:39:34 2008 (r185088) @@ -96,7 +96,9 @@ int looutput(struct ifnet *ifp, struct=20 static int lo_clone_create(struct if_clone *, int, caddr_t); static void lo_clone_destroy(struct ifnet *); =20 =2Dstruct ifnet *loif =3D NULL; /* Used externally */ +#ifdef VIMAGE_GLOBALS +struct ifnet *loif; /* Used externally */ +#endif =20 IFC_SIMPLE_DECLARE(lo, 1); =20 @@ -142,6 +144,7 @@ loop_modevent(module_t mod, int type, vo =20 switch (type) { case MOD_LOAD: + V_loif =3D NULL; if_clone_attach(&lo_cloner); break; =20 Modified: head/sys/net/raw_cb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/net/raw_cb.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/net/raw_cb.c Wed Nov 19 09:39:34 2008 (r185088) @@ -57,7 +57,9 @@ */ =20 struct mtx rawcb_mtx; +#ifdef VIMAGE_GLOBALS struct rawcb_list_head rawcb_list; +#endif =20 SYSCTL_NODE(_net, OID_AUTO, raw, CTLFLAG_RW, 0, "Raw socket=20 infrastructure"); =20 Modified: head/sys/net/route.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/net/route.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/net/route.c Wed Nov 19 09:39:34 2008 (r185088) @@ -84,6 +84,7 @@ SYSCTL_INT(_net, OID_AUTO, add_addr_allf &rt_add_addr_allfibs, 0, ""); TUNABLE_INT("net.add_addr_allfibs", &rt_add_addr_allfibs); =20 +#ifdef VIMAGE_GLOBALS static struct rtstat rtstat; =20 /* by default only the first 'row' of tables will be accessed. */ @@ -96,6 +97,7 @@ static struct rtstat rtstat; struct radix_node_head *rt_tables[RT_MAXFIBS][AF_MAX+1]; =20 static int rttrash; /* routes not in table but not freed */ +#endif =20 static void rt_maskedcopy(struct sockaddr *, struct sockaddr *, struct sockaddr *); Modified: head/sys/netinet/if_ether.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/if_ether.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/if_ether.c Wed Nov 19 09:39:34 2008 (r185088) @@ -82,7 +82,12 @@ SYSCTL_DECL(_net_link_ether); SYSCTL_NODE(_net_link_ether, PF_INET, inet, CTLFLAG_RW, 0, ""); =20 /* timer values */ =2Dstatic int arpt_keep =3D (20*60); /* once resolved, good for 20 more=20 minutes */ +#ifdef VIMAGE_GLOBALS +static int arpt_keep; /* once resolved, good for 20 more minutes */ +static int arp_maxtries; +static int useloopback; /* use loopback interface for local traffic */ +static int arp_proxyall; +#endif =20 SYSCTL_INT(_net_link_ether_inet, OID_AUTO, max_age, CTLFLAG_RW,=20 &arpt_keep, 0, "ARP entry lifetime in seconds"); @@ -99,10 +104,6 @@ struct llinfo_arp { =20 static struct ifqueue arpintrq; =20 =2Dstatic int arp_maxtries =3D 5; =2Dstatic int useloopback =3D 1; /* use loopback interface for local traffi= c=20 */ =2Dstatic int arp_proxyall =3D 0; =2D SYSCTL_V_INT(V_NET, vnet_inet, _net_link_ether_inet, OID_AUTO,=20 maxtries, CTLFLAG_RW, arp_maxtries, 0, "ARP resolution attempts before returning error"); @@ -1076,6 +1077,12 @@ arp_ifinit2(struct ifnet *ifp, struct if static void arp_init(void) { + INIT_VNET_INET(curvnet); + + V_arpt_keep =3D (20*60); /* once resolved, good for 20 more minutes */ + V_arp_maxtries =3D 5; + V_useloopback =3D 1; /* use loopback interface for local traffic */ + V_arp_proxyall =3D 0; =20 arpintrq.ifq_maxlen =3D 50; mtx_init(&arpintrq.ifq_mtx, "arp_inq", NULL, MTX_DEF); Modified: head/sys/netinet/igmp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/igmp.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/igmp.c Wed Nov 19 09:39:34 2008 (r185088) @@ -80,7 +80,9 @@ static MALLOC_DEFINE(M_IGMP, "igmp", "ig static struct router_info *find_rti(struct ifnet *ifp); static void igmp_sendpkt(struct in_multi *, int, unsigned long); =20 +#ifdef VIMAGE_GLOBALS static struct igmpstat igmpstat; +#endif =20 SYSCTL_V_STRUCT(V_NET, vnet_inet, _net_inet_igmp, IGMPCTL_STATS, stats, CTLFLAG_RW, igmpstat, igmpstat, ""); @@ -92,8 +94,10 @@ SYSCTL_V_STRUCT(V_NET, vnet_inet, _net_i * reference counting is used. We allow unlocked reads of router_info=20 data * when accessed via an in_multi read-only. */ =2Dstatic struct mtx igmp_mtx; +#ifdef VIMAGE_GLOBALS static SLIST_HEAD(, router_info) router_info_head; +#endif +static struct mtx igmp_mtx; static int igmp_timers_are_running; =20 /* Modified: head/sys/netinet/in.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in.c Wed Nov 19 09:39:34 2008 (r185088) @@ -66,18 +66,20 @@ static int in_ifinit(struct ifnet *, struct in_ifaddr *, struct sockaddr_in *, int); static void in_purgemaddrs(struct ifnet *); =20 =2Dstatic int subnetsarelocal =3D 0; +#ifdef VIMAGE_GLOBALS +static int subnetsarelocal; +static int sameprefixcarponly; +extern struct inpcbinfo ripcbinfo; +extern struct inpcbinfo udbinfo; +#endif + SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO,=20 subnets_are_local, CTLFLAG_RW, subnetsarelocal, 0, "Treat all subnets as directly connected"); =2Dstatic int sameprefixcarponly =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO,=20 same_prefix_carp_only, CTLFLAG_RW, sameprefixcarponly, 0, "Refuse to create same prefixes on different interfaces"); =20 =2Dextern struct inpcbinfo ripcbinfo; =2Dextern struct inpcbinfo udbinfo; =2D /* * Return 1 if an internet address is for a ``local'' host * (one to which we have a connection). If subnetsarelocal Modified: head/sys/netinet/in_gif.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in_gif.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in_gif.c Wed Nov 19 09:39:34 2008 (r185088) @@ -85,7 +85,9 @@ struct protosw in_gif_protosw =3D { .pr_usrreqs =3D &rip_usrreqs }; =20 =2Dstatic int ip_gif_ttl =3D GIF_TTL; +#ifdef VIMAGE_GLOBALS +extern int ip_gif_ttl; +#endif SYSCTL_V_INT(V_NET, vnet_gif, _net_inet_ip, IPCTL_GIF_TTL, gifttl, CTLFLAG_RW, ip_gif_ttl, 0, ""); =20 Modified: head/sys/netinet/in_mcast.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in_mcast.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in_mcast.c Wed Nov 19 09:39:34 2008 (r185088) @@ -86,7 +86,9 @@ static MALLOC_DEFINE(M_IPMSOURCE, "in_ms * ip_output() to send IGMP packets while holding the lock; this=20 probably is * not quite desirable. */ +#ifdef VIMAGE_GLOBALS struct in_multihead in_multihead; /* XXX BSS initialization */ +#endif struct mtx in_multi_mtx; MTX_SYSINIT(in_multi_mtx, &in_multi_mtx, "in_multi_mtx", MTX_DEF |=20 MTX_RECURSE); =20 Modified: head/sys/netinet/in_pcb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in_pcb.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in_pcb.c Wed Nov 19 09:39:34 2008 (r185088) @@ -84,32 +84,34 @@ __FBSDID("$FreeBSD$"); =20 #include =20 +#ifdef VIMAGE_GLOBALS /* * These configure the range of local port addresses assigned to * "unspecified" outgoing connections/packets/whatever. */ =2Dint ipport_lowfirstauto =3D IPPORT_RESERVED - 1; /* 1023 */ =2Dint ipport_lowlastauto =3D IPPORT_RESERVEDSTART; /* 600 */ =2Dint ipport_firstauto =3D IPPORT_EPHEMERALFIRST; /* 10000 */ =2Dint ipport_lastauto =3D IPPORT_EPHEMERALLAST; /* 65535 */ =2Dint ipport_hifirstauto =3D IPPORT_HIFIRSTAUTO; /* 49152 */ =2Dint ipport_hilastauto =3D IPPORT_HILASTAUTO; /* 65535 */ +int ipport_lowfirstauto; +int ipport_lowlastauto; +int ipport_firstauto; +int ipport_lastauto; +int ipport_hifirstauto; +int ipport_hilastauto; =20 /* * Reserved ports accessible only to root. There are significant * security considerations that must be accounted for when changing=20 these, * but the security benefits can be great. Please be careful. */ =2Dint ipport_reservedhigh =3D IPPORT_RESERVED - 1; /* 1023 */ =2Dint ipport_reservedlow =3D 0; +int ipport_reservedhigh; +int ipport_reservedlow; =20 /* Variables dealing with random ephemeral port allocation. */ =2Dint ipport_randomized =3D 1; /* user controlled via sysctl */ =2Dint ipport_randomcps =3D 10; /* user controlled via sysctl */ =2Dint ipport_randomtime =3D 45; /* user controlled via sysctl */ =2Dint ipport_stoprandom =3D 0; /* toggled by ipport_tick */ +int ipport_randomized; +int ipport_randomcps; +int ipport_randomtime; +int ipport_stoprandom; int ipport_tcpallocs; int ipport_tcplastcount; +#endif =20 #define RANGECHK(var, min, max) \ if ((var) < (min)) { (var) =3D (min); } \ Modified: head/sys/netinet/in_pcb.h =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in_pcb.h Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in_pcb.h Wed Nov 19 09:39:34 2008 (r185088) @@ -450,6 +450,8 @@ extern int ipport_lastauto; extern int ipport_hifirstauto; extern int ipport_hilastauto; extern int ipport_randomized; +extern int ipport_randomcps; +extern int ipport_randomtime; extern int ipport_stoprandom; extern int ipport_tcpallocs; extern struct callout ipport_tick_callout; Modified: head/sys/netinet/in_proto.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in_proto.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in_proto.c Wed Nov 19 09:39:34 2008 (r185088) @@ -193,6 +193,7 @@ struct protosw inetsw[] =3D { .pr_flags =3D PR_ATOMIC|PR_ADDR|PR_LASTHDR, .pr_input =3D icmp_input, .pr_ctloutput =3D rip_ctloutput, + .pr_init =3D icmp_init, .pr_usrreqs =3D &rip_usrreqs }, { Modified: head/sys/netinet/in_rmx.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in_rmx.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in_rmx.c Wed Nov 19 09:39:34 2008 (r185088) @@ -151,17 +151,20 @@ in_matroute(void *v_arg, struct radix_no return rn; } =20 =2Dstatic int rtq_reallyold =3D 60*60; /* one hour is "really old" */ +#ifdef VIMAGE_GLOBALS +static int rtq_reallyold; +static int rtq_minreallyold; +static int rtq_toomany; +#endif + SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, IPCTL_RTEXPIRE, rtexpire, CTLFLAG_RW, rtq_reallyold, 0, "Default expiration time on dynamically learned routes"); =20 =2Dstatic int rtq_minreallyold =3D 10; /* never automatically crank down t= o=20 less */ SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, IPCTL_RTMINEXPIRE, rtminexpire, CTLFLAG_RW, rtq_minreallyold, 0, "Minimum time to attempt to hold onto dynamically learned routes"); =20 =2Dstatic int rtq_toomany =3D 128; /* 128 cached routes is "too many" */ SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, IPCTL_RTMAXCACHE, rtmaxcache, CTLFLAG_RW, rtq_toomany, 0, "Upper limit on dynamically learned routes"); @@ -256,8 +259,10 @@ in_rtqkill(struct radix_node *rn, void * } =20 #define RTQ_TIMEOUT 60*10 /* run no less than once every ten minutes */ =2Dstatic int rtq_timeout =3D RTQ_TIMEOUT; +#ifdef VIMAGE_GLOBALS +static int rtq_timeout; static struct callout rtq_timer; +#endif =20 static void in_rtqtimo_one(void *rock); =20 @@ -376,6 +381,11 @@ in_inithead(void **head, int off) if (off =3D=3D 0) /* XXX MRT see above */ return 1; /* only do the rest for a real routing table */ =20 + V_rtq_reallyold =3D 60*60; /* one hour is "really old" */ + V_rtq_minreallyold =3D 10; /* never automatically crank down to less */ + V_rtq_toomany =3D 128; /* 128 cached routes is "too many" */ + V_rtq_timeout =3D RTQ_TIMEOUT; + rnh =3D *head; rnh->rnh_addaddr =3D in_addroute; rnh->rnh_matchaddr =3D in_matroute; Modified: head/sys/netinet/in_var.h =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/in_var.h Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/in_var.h Wed Nov 19 09:39:34 2008 (r185088) @@ -138,6 +138,15 @@ do { \ #endif =20 /* + * IP datagram reassembly. + */ +#define IPREASS_NHASH_LOG2 6 +#define IPREASS_NHASH (1 << IPREASS_NHASH_LOG2) +#define IPREASS_HMASK (IPREASS_NHASH - 1) +#define IPREASS_HASH(x,y) \ + (((((x) & 0xF) | ((((x) >> 8) & 0xF) << 4)) ^ (y)) & IPREASS_HMASK) + +/* * This information should be part of the ifnet structure but we don't=20 wish * to change that - as it might break a number of things */ Modified: head/sys/netinet/ip_divert.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/ip_divert.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/ip_divert.c Wed Nov 19 09:39:34 2008 (r185088) @@ -112,8 +112,10 @@ __FBSDID("$FreeBSD$"); */ =20 /* Internal variables. */ +#ifdef VIMAGE_GLOBALS static struct inpcbhead divcb; static struct inpcbinfo divcbinfo; +#endif =20 static u_long div_sendspace =3D DIVSNDQ; /* XXX sysctl ? */ static u_long div_recvspace =3D DIVRCVQ; /* XXX sysctl ? */ Modified: head/sys/netinet/ip_fastfwd.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/ip_fastfwd.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/ip_fastfwd.c Wed Nov 19 09:39:34 2008 (r185088) @@ -106,7 +106,9 @@ __FBSDID("$FreeBSD$"); =20 #include =20 =2Dstatic int ipfastforward_active =3D 0; +#ifdef VIMAGE_GLOBALS +static int ipfastforward_active; +#endif SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO, fastforwarding, CTLFLAG_RW, ipfastforward_active, 0, "Enable fast IP forwarding"); =20 Modified: head/sys/netinet/ip_icmp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/ip_icmp.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/ip_icmp.c Wed Nov 19 09:39:34 2008 (r185088) @@ -77,47 +77,51 @@ __FBSDID("$FreeBSD$"); * host table maintenance routines. */ =20 =2Dstruct icmpstat icmpstat; +#ifdef VIMAGE_GLOBALS +struct icmpstat icmpstat; +static int icmpmaskrepl; +static u_int icmpmaskfake; +static int drop_redirect; +static int log_redirect; +static int icmplim; +static int icmplim_output; +static char reply_src[IFNAMSIZ]; +static int icmp_rfi; +static int icmp_quotelen; +static int icmpbmcastecho; +#endif + SYSCTL_V_STRUCT(V_NET, vnet_inet, _net_inet_icmp, ICMPCTL_STATS, stats, CTLFLAG_RW, icmpstat, icmpstat, ""); =20 =2Dstatic int icmpmaskrepl =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, ICMPCTL_MASKREPL,=20 maskrepl, CTLFLAG_RW, icmpmaskrepl, 0, "Reply to ICMP Address Mask Request packets."); =20 =2Dstatic u_int icmpmaskfake =3D 0; SYSCTL_V_UINT(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO, maskfake,=20 CTLFLAG_RW, icmpmaskfake, 0, "Fake reply to ICMP Address Mask Request packets."); =20 =2Dstatic int drop_redirect =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO, drop_redirect, CTLFLAG_RW, drop_redirect, 0, "Ignore ICMP redirects"); =20 =2Dstatic int log_redirect =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO, log_redirect, CTLFLAG_RW, log_redirect, 0, "Log ICMP redirects to the console"); =20 =2Dstatic int icmplim =3D 200; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, ICMPCTL_ICMPLIM,=20 icmplim, CTLFLAG_RW, icmplim, 0, "Maximum number of ICMP responses per=20 second"); =20 =2Dstatic int icmplim_output =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO,=20 icmplim_output, CTLFLAG_RW, icmplim_output, 0, "Enable rate limiting of ICMP responses"); =20 =2Dstatic char reply_src[IFNAMSIZ]; SYSCTL_V_STRING(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO, reply_src, CTLFLAG_RW, reply_src, IFNAMSIZ, "icmp reply source for non-local packets."); =20 =2Dstatic int icmp_rfi =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO,=20 reply_from_interface, CTLFLAG_RW, icmp_rfi, 0, "ICMP reply from incoming interface for " "non-local packets"); =20 =2Dstatic int icmp_quotelen =3D 8; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO, quotelen,=20 CTLFLAG_RW, icmp_quotelen, 0, "Number of bytes from original packet to " "quote in ICMP reply"); @@ -126,7 +130,6 @@ SYSCTL_V_INT(V_NET, vnet_inet, _net_inet * ICMP broadcast echo sysctl */ =20 =2Dstatic int icmpbmcastecho =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_icmp, OID_AUTO, bmcastecho, CTLFLAG_RW, icmpbmcastecho, 0, ""); =20 @@ -140,6 +143,22 @@ static void icmp_send(struct mbuf *, str =20 extern struct protosw inetsw[]; =20 +void +icmp_init(void) +{ + INIT_VNET_INET(curvnet); + + V_icmpmaskrepl =3D 0; + V_icmpmaskfake =3D 0; + V_drop_redirect =3D 0; + V_log_redirect =3D 0; + V_icmplim =3D 200; + V_icmplim_output =3D 1; + V_icmp_rfi =3D 0; + V_icmp_quotelen =3D 8; + V_icmpbmcastecho =3D 0; +} + /* * Generate an error packet of type error * in response to bad packet ip. Modified: head/sys/netinet/ip_icmp.h =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/ip_icmp.h Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/ip_icmp.h Wed Nov 19 09:39:34 2008 (r185088) @@ -204,6 +204,7 @@ struct icmp { #ifdef _KERNEL void icmp_error(struct mbuf *, int, int, n_long, int); void icmp_input(struct mbuf *, int); +void icmp_init(void); int ip_next_mtu(int, int); #endif =20 Modified: head/sys/netinet/ip_input.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/ip_input.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/ip_input.c Wed Nov 19 09:39:34 2008 (r185088) @@ -89,33 +89,47 @@ __FBSDID("$FreeBSD$"); CTASSERT(sizeof(struct ip) =3D=3D 20); #endif =20 =2Dint rsvp_on =3D 0; +#ifdef VIMAGE_GLOBALS +static int ipsendredirects; +static int ip_checkinterface; +static int ip_keepfaith; +static int ip_sendsourcequench; +int ip_defttl; +int ip_do_randomid; +int ipforwarding; +struct in_ifaddrhead in_ifaddrhead; /* first inet address */ +struct in_ifaddrhashhead *in_ifaddrhashtbl; /* inet addr hash table */ +u_long in_ifaddrhmask; /* mask for hash table */ +struct ipstat ipstat; +static int ip_rsvp_on; +struct socket *ip_rsvpd; +int rsvp_on; +static TAILQ_HEAD(ipqhead, ipq) ipq[IPREASS_NHASH]; +static int maxnipq; /* Administrative limit on # reass queues. */ +static int maxfragsperpacket; +int ipstealth; +static int nipq; /* Total # of reass queues */ +#endif =20 =2Dint ipforwarding =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, ipforwarding, 0, "Enable IP forwarding between interfaces"); =20 =2Dstatic int ipsendredirects =3D 1; /* XXX */ SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, ipsendredirects, 0, "Enable sending IP redirects"); =20 =2Dint ip_defttl =3D IPDEFTTL; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, IPCTL_DEFTTL, ttl, CTLFLAG_RW, ip_defttl, 0, "Maximum TTL on IP packets"); =20 =2Dstatic int ip_keepfaith =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, IPCTL_KEEPFAITH, keepfaith, CTLFLAG_RW, ip_keepfaith, 0, "Enable packet capture for FAITH IPv4->IPv6 translater daemon"); =20 =2Dstatic int ip_sendsourcequench =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO, sendsourcequench, CTLFLAG_RW, ip_sendsourcequench, 0, "Enable the transmission of source quench packets"); =20 =2Dint ip_do_randomid =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO, random_id, CTLFLAG_RW, ip_do_randomid, 0, "Assign random ip_id values"); =20 @@ -132,7 +146,6 @@ SYSCTL_V_INT(V_NET, vnet_inet, _net_inet * to the loopback interface instead of the interface where the * packets for those addresses are received. */ =2Dstatic int ip_checkinterface =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO, check_interface, CTLFLAG_RW, ip_checkinterface, 0, "Verify packet arrives on correct interface"); @@ -145,9 +158,6 @@ static int ipqmaxlen =3D IFQ_MAXLEN; extern struct domain inetdomain; extern struct protosw inetsw[]; u_char ip_protox[IPPROTO_MAX]; =2Dstruct in_ifaddrhead in_ifaddrhead; /* first inet address */ =2Dstruct in_ifaddrhashhead *in_ifaddrhashtbl; /* inet addr hash table */ =2Du_long in_ifaddrhmask; /* mask for hash table */ =20 SYSCTL_INT(_net_inet_ip, IPCTL_INTRQMAXLEN, intr_queue_maxlen,=20 CTLFLAG_RW, &ipintrq.ifq_maxlen, 0, "Maximum size of the IP input queue"); @@ -155,21 +165,10 @@ SYSCTL_INT(_net_inet_ip, IPCTL_INTRQDROP &ipintrq.ifq_drops, 0, "Number of packets dropped from the IP input queue"); =20 =2Dstruct ipstat ipstat; SYSCTL_V_STRUCT(V_NET, vnet_inet, _net_inet_ip, IPCTL_STATS, stats,=20 CTLFLAG_RW, ipstat, ipstat, "IP statistics (struct ipstat, netinet/ip_var.h)"); =20 =2D/* =2D * IP datagram reassembly. =2D */ =2D#define IPREASS_NHASH_LOG2 6 =2D#define IPREASS_NHASH (1 << IPREASS_NHASH_LOG2) =2D#define IPREASS_HMASK (IPREASS_NHASH - 1) =2D#define IPREASS_HASH(x,y) \ =2D (((((x) & 0xF) | ((((x) >> 8) & 0xF) << 4)) ^ (y)) & IPREASS_HMASK) =2D static uma_zone_t ipq_zone; =2Dstatic TAILQ_HEAD(ipqhead, ipq) ipq[IPREASS_NHASH]; static struct mtx ipqlock; =20 #define IPQ_LOCK() mtx_lock(&ipqlock) @@ -180,13 +179,10 @@ static struct mtx ipqlock; static void maxnipq_update(void); static void ipq_zone_change(void *); =20 =2Dstatic int maxnipq; /* Administrative limit on # reass queues. */ =2Dstatic int nipq =3D 0; /* Total # of reass queues */ SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO, fragpackets, CTLFLAG_RD, nipq, 0, "Current number of IPv4 fragment reassembly queue entries"); =20 =2Dstatic int maxfragsperpacket; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO,=20 maxfragsperpacket, CTLFLAG_RW, maxfragsperpacket, 0, "Maximum number of IPv4 fragments allowed per packet"); @@ -199,7 +195,6 @@ SYSCTL_INT(_net_inet_ip, IPCTL_DEFMTU, m #endif =20 #ifdef IPSTEALTH =2Dint ipstealth =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_ip, OID_AUTO, stealth,=20 CTLFLAG_RW, ipstealth, 0, "IP stealth mode, no TTL decrementation on=20 forwarding"); #endif @@ -225,6 +220,37 @@ ip_init(void) struct protosw *pr; int i; =20 + V_ipsendredirects =3D 1; /* XXX */ + V_ip_checkinterface =3D 0; + V_ip_keepfaith =3D 0; + V_ip_sendsourcequench =3D 0; + V_rsvp_on =3D 0; + V_ip_defttl =3D IPDEFTTL; + V_ip_do_randomid =3D 0; + V_ipforwarding =3D 0; + V_ipstealth =3D 0; + V_nipq =3D 0; /* Total # of reass queues */ + + V_ipport_lowfirstauto =3D IPPORT_RESERVED - 1; /* 1023 */ + V_ipport_lowlastauto =3D IPPORT_RESERVEDSTART; /* 600 */ + V_ipport_firstauto =3D IPPORT_EPHEMERALFIRST; /* 10000 */ + V_ipport_lastauto =3D IPPORT_EPHEMERALLAST; /* 65535 */ + V_ipport_hifirstauto =3D IPPORT_HIFIRSTAUTO; /* 49152 */ + V_ipport_hilastauto =3D IPPORT_HILASTAUTO; /* 65535 */ + V_ipport_reservedhigh =3D IPPORT_RESERVED - 1; /* 1023 */ + V_ipport_reservedlow =3D 0; + V_ipport_randomized =3D 1; /* user controlled via sysctl */ + V_ipport_randomcps =3D 10; /* user controlled via sysctl */ + V_ipport_randomtime =3D 45; /* user controlled via sysctl */ + V_ipport_stoprandom =3D 0; /* toggled by ipport_tick */ + +#ifdef NOTYET + /* XXX global static but not instantiated in this file */ + V_ipfastforward_active =3D 0; + V_subnetsarelocal =3D 0; + V_sameprefixcarponly =3D 0; +#endif + TAILQ_INIT(&V_in_ifaddrhead); V_in_ifaddrhashtbl =3D hashinit(INADDR_NHASH, M_IFADDR,=20 &V_in_ifaddrhmask); pr =3D pffindproto(PF_INET, IPPROTO_RAW, SOCK_RAW); @@ -1591,8 +1617,6 @@ makedummy:=09 * locking. This code remains in ip_input.c as ip_mroute.c is=20 optionally * compiled. */ =2Dstatic int ip_rsvp_on; =2Dstruct socket *ip_rsvpd; int ip_rsvp_init(struct socket *so) { Modified: head/sys/netinet/ip_output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/ip_output.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/ip_output.c Wed Nov 19 09:39:34 2008 (r185088) @@ -83,7 +83,9 @@ __FBSDID("$FreeBSD$"); (ntohl(a.s_addr)>>8)&0xFF,\ (ntohl(a.s_addr))&0xFF, y); =20 +#ifdef VIMAGE_GLOBALS u_short ip_id; +#endif =20 #ifdef MBUF_STRESS_TEST int mbuf_frag_size =3D 0; Modified: head/sys/netinet/raw_ip.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/raw_ip.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/raw_ip.c Wed Nov 19 09:39:34 2008 (r185088) @@ -76,8 +76,10 @@ __FBSDID("$FreeBSD$"); =20 #include =20 +#ifdef VIMAGE_GLOBALS struct inpcbhead ripcb; struct inpcbinfo ripcbinfo; +#endif =20 /* control hooks for ipfw and dummynet */ ip_fw_ctl_t *ip_fw_ctl_ptr =3D NULL; @@ -91,7 +93,9 @@ ip_dn_ctl_t *ip_dn_ctl_ptr =3D NULL; /* * The socket used to communicate with the multicast routing daemon. */ +#ifdef VIMAGE_GLOBALS struct socket *ip_mrouter; +#endif =20 /* * The various mrouter and rsvp functions. Modified: head/sys/netinet/tcp_hostcache.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/tcp_hostcache.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/tcp_hostcache.c Wed Nov 19 09:39:34 2008 (r185088) @@ -146,9 +146,11 @@ struct tcp_hostcache { int prune; int purgeall; }; =2Dstatic struct tcp_hostcache tcp_hostcache; =20 +#ifdef VIMAGE_GLOBALS +static struct tcp_hostcache tcp_hostcache; static struct callout tcp_hc_callout; +#endif =20 static struct hc_metrics *tcp_hc_lookup(struct in_conninfo *); static struct hc_metrics *tcp_hc_insert(struct in_conninfo *); Modified: head/sys/netinet/tcp_input.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/tcp_input.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/tcp_input.c Wed Nov 19 09:39:34 2008 (r185088) @@ -99,7 +99,21 @@ __FBSDID("$FreeBSD$"); =20 static const int tcprexmtthresh =3D 3; =20 +#ifdef VIMAGE_GLOBALS struct tcpstat tcpstat; +int blackhole; +int tcp_delack_enabled; +int drop_synfin; +int tcp_do_rfc3042; +int tcp_do_rfc3390; +int tcp_do_ecn; +int tcp_ecn_maxretries; +int tcp_insecure_rst; +int tcp_do_autorcvbuf; +int tcp_autorcvbuf_inc; +int tcp_autorcvbuf_max; +#endif + SYSCTL_V_STRUCT(V_NET, vnet_inet, _net_inet_tcp, TCPCTL_STATS, stats, CTLFLAG_RW, tcpstat , tcpstat, "TCP statistics (struct tcpstat, netinet/tcp_var.h)"); @@ -108,59 +122,50 @@ int tcp_log_in_vain =3D 0; SYSCTL_INT(_net_inet_tcp, OID_AUTO, log_in_vain, CTLFLAG_RW, &tcp_log_in_vain, 0, "Log all incoming TCP segments to closed=20 ports"); =20 =2Dstatic int blackhole =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, blackhole,=20 CTLFLAG_RW, blackhole, 0, "Do not send RST on segments to closed ports"); =20 =2Dint tcp_delack_enabled =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, delayed_ack, CTLFLAG_RW, tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); =20 =2Dstatic int drop_synfin =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, drop_synfin, 0, "Drop TCP packets with SYN+FIN set"); =20 =2Dstatic int tcp_do_rfc3042 =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, rfc3042,=20 CTLFLAG_RW, tcp_do_rfc3042, 0, "Enable RFC 3042 (Limited Transmit)"); =20 =2Dstatic int tcp_do_rfc3390 =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, rfc3390,=20 CTLFLAG_RW, tcp_do_rfc3390, 0, "Enable RFC 3390 (Increasing TCP's Initial Congestion Window)"); =20 =2Dint tcp_do_ecn =3D 0; =2Dint tcp_ecn_maxretries =3D 1; SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, "TCP ECN"); SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_ecn, OID_AUTO, enable, CTLFLAG_RW, tcp_do_ecn, 0, "TCP ECN support"); SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_ecn, OID_AUTO, maxretries, CTLFLAG_RW, tcp_ecn_maxretries, 0, "Max retries before giving up on=20 ECN"); =20 =2Dstatic int tcp_insecure_rst =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, insecure_rst, CTLFLAG_RW, tcp_insecure_rst, 0, "Follow the old (insecure) criteria for accepting RST packets"); =20 =2Dint tcp_do_autorcvbuf =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, recvbuf_auto, CTLFLAG_RW, tcp_do_autorcvbuf, 0, "Enable automatic receive buffer sizing"); =20 =2Dint tcp_autorcvbuf_inc =3D 16*1024; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, recvbuf_inc, CTLFLAG_RW, tcp_autorcvbuf_inc, 0, "Incrementor step size of automatic receive buffer"); =20 =2Dint tcp_autorcvbuf_max =3D 256*1024; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, recvbuf_max, CTLFLAG_RW, tcp_autorcvbuf_max, 0, "Max size of automatic receive buffer"); =20 +#ifdef VIMAGE_GLOBALS struct inpcbhead tcb; =2D#define tcb6 tcb /* for KAME src sync over BSD*'s */ struct inpcbinfo tcbinfo; +#endif +#define tcb6 tcb /* for KAME src sync over BSD*'s */ =20 static void tcp_dooptions(struct tcpopt *, u_char *, int, int); static void tcp_do_segment(struct mbuf *, struct tcphdr *, Modified: head/sys/netinet/tcp_output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/tcp_output.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/tcp_output.c Wed Nov 19 09:39:34 2008 (r185088) @@ -87,39 +87,42 @@ __FBSDID("$FreeBSD$"); extern struct mbuf *m_copypack(); #endif =20 =2Dint path_mtu_discovery =3D 1; +#ifdef VIMAGE_GLOBALS +int path_mtu_discovery; +int ss_fltsz; +int ss_fltsz_local; +int tcp_do_newreno; +int tcp_do_tso; +int tcp_do_autosndbuf; +int tcp_autosndbuf_inc; +int tcp_autosndbuf_max; +#endif + SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO,=20 path_mtu_discovery, CTLFLAG_RW, path_mtu_discovery, 1, "Enable Path MTU Discovery"); =20 =2Dint ss_fltsz =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW, ss_fltsz, 1, "Slow start flight size"); =20 =2Dint ss_fltsz_local =3D 4; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, local_slowstart_flightsize, CTLFLAG_RW, ss_fltsz_local, 1, "Slow start flight size for local networks"); =20 =2Dint tcp_do_newreno =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, newreno,=20 CTLFLAG_RW, tcp_do_newreno, 0, "Enable NewReno Algorithms"); =20 =2Dint tcp_do_tso =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, tso,=20 CTLFLAG_RW, tcp_do_tso, 0, "Enable TCP Segmentation Offload"); =20 =2Dint tcp_do_autosndbuf =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, sendbuf_auto, CTLFLAG_RW, tcp_do_autosndbuf, 0, "Enable automatic send buffer sizing"); =20 =2Dint tcp_autosndbuf_inc =3D 8*1024; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, sendbuf_inc, CTLFLAG_RW, tcp_autosndbuf_inc, 0, "Incrementor step size of automatic send buffer"); =20 =2Dint tcp_autosndbuf_max =3D 256*1024; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp, OID_AUTO, sendbuf_max, CTLFLAG_RW, tcp_autosndbuf_max, 0, "Max size of automatic send buffer"); Modified: head/sys/netinet/tcp_reass.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/tcp_reass.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/tcp_reass.c Wed Nov 19 09:39:34 2008 (r185088) @@ -74,25 +74,28 @@ __FBSDID("$FreeBSD$"); #include #endif /* TCPDEBUG */ =20 +#ifdef VIMAGE_GLOBALS +static int tcp_reass_maxseg; +int tcp_reass_qsize; +static int tcp_reass_maxqlen; +static int tcp_reass_overflows; +#endif + SYSCTL_NODE(_net_inet_tcp, OID_AUTO, reass, CTLFLAG_RW, 0, "TCP Segment Reassembly Queue"); =20 =2Dstatic int tcp_reass_maxseg =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_reass, OID_AUTO,=20 maxsegments, CTLFLAG_RDTUN, tcp_reass_maxseg, 0, "Global maximum number of TCP Segments in Reassembly Queue"); =20 =2Dint tcp_reass_qsize =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_reass, OID_AUTO,=20 cursegments, CTLFLAG_RD, tcp_reass_qsize, 0, "Global number of TCP Segments currently in Reassembly Queue"); =20 =2Dstatic int tcp_reass_maxqlen =3D 48; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_reass, OID_AUTO, maxqlen, CTLFLAG_RW, tcp_reass_maxqlen, 0, "Maximum number of TCP Segments per individual Reassembly Queue"); =20 =2Dstatic int tcp_reass_overflows =3D 0; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_reass, OID_AUTO,=20 overflows, CTLFLAG_RD, tcp_reass_overflows, 0, "Global number of TCP Segment Reassembly Queue Overflows"); @@ -114,6 +117,11 @@ tcp_reass_init(void) { INIT_VNET_INET(curvnet); =20 + V_tcp_reass_maxseg =3D 0; + V_tcp_reass_qsize =3D 0; + V_tcp_reass_maxqlen =3D 48; + V_tcp_reass_overflows =3D 0; + V_tcp_reass_maxseg =3D nmbclusters / 16; TUNABLE_INT_FETCH("net.inet.tcp.reass.maxsegments", &V_tcp_reass_maxseg); Modified: head/sys/netinet/tcp_sack.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =2D-- head/sys/netinet/tcp_sack.c Wed Nov 19 08:56:35 2008 (r185087) +++ head/sys/netinet/tcp_sack.c Wed Nov 19 09:39:34 2008 (r185088) @@ -124,23 +124,26 @@ __FBSDID("$FreeBSD$"); =20 extern struct uma_zone *sack_hole_zone; =20 +#ifdef VIMAGE_GLOBALS +int tcp_do_sack; +int tcp_sack_maxholes; +int tcp_sack_globalmaxholes; +int tcp_sack_globalholes; +#endif + SYSCTL_NODE(_net_inet_tcp, OID_AUTO, sack, CTLFLAG_RW, 0, "TCP SACK"); =2Dint tcp_do_sack =3D 1; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_sack, OID_AUTO, enable, CTLFLAG_RW, tcp_do_sack, 0, "Enable/Disable TCP SACK support"); TUNABLE_INT("net.inet.tcp.sack.enable", &tcp_do_sack); =20 =2Dstatic int tcp_sack_maxholes =3D 128; SYSCTL_V_INT(V_NET, vnet_inet, _net_inet_tcp_sack, OID_AUTO, maxholes, *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** =2D------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:34:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE262106567A for ; Wed, 19 Nov 2008 11:34:04 +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 A1A498FC0A for ; Wed, 19 Nov 2008 11:34:04 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.18] (port=52864 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2lJr-0003M5-7l; Wed, 19 Nov 2008 14:34:03 +0300 Message-ID: <4923F9AB.4020304@lissyara.su> Date: Wed, 19 Nov 2008 14:34:03 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.17) Gecko/20080929 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Jeremy Chadwick , freebsd-current@freebsd.org References: <4923EA3F.2000801@lissyara.su> <20081119103326.GA83222@icarus.home.lan> <4923F201.6080606@lissyara.su> <20081119111545.GA84854@icarus.home.lan> <20081119111904.GA84939@icarus.home.lan> In-Reply-To: <20081119111904.GA84939@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:34:05 -0000 Jeremy Chadwick пишет: > On Wed, Nov 19, 2008 at 03:15:45AM -0800, Jeremy Chadwick wrote: > >> On Wed, Nov 19, 2008 at 02:01:21PM +0300, Alex Keda wrote: >> >>> Jeremy Chadwick ??????????: >>> >>>> On Wed, Nov 19, 2008 at 01:28:15PM +0300, Alex Keda wrote: >>>> >>>> >>>>> I replace default GENERIC kernel on my XEN kernel in FreeBSD >>>>> installation CD-ROM (i386 7.0-RELEASE) >>>>> But, I cannot boot in XEN - I see fast run "BTX halted" and many >>>>> other debugging info. >>>>> >>>>> >>>> BTX halted is a message coming from either boot2 or loader, not the >>>> kernel. Do you see the FreeBSD beastie logo/menu before you see this >>>> message? >>>> >>>> >>> No, but, messages go very fast - I'm doubt. >>> >>>> >>>> >>>>> Can I boot from FreeBSD CD-ROM in XEN? >>>>> >>>>> >>>> I know nothing about Xen (what it is, what purpose it serves, etc.). >>>> If it's a "hardware emulator" of some sort, then I'd be wary of it. >>>> Try things on real hardware if possible. >>>> >>>> >>> I try original CD - same behavior... >>> >> Can you please try using a 7.1-PRERELEASE i386 CD instead? There were >> BTX changes made between 7.0 and 7.1 which may fix this (using real mode >> for BTX). Those changes are documented in my Wiki (see bottom): >> >> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues >> > > Also, I just realised you've posted to -current about issues with > a 7.x release. Why is that? :-) > Kernel from CURRENT, but world - 7.0 =) Now, I download CURRENT and 7.1 and try it From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:36:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 816B01065689 for ; Wed, 19 Nov 2008 11:36:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 617938FC20 for ; Wed, 19 Nov 2008 11:36:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id gzUH1a00F1HpZEsA2zcfBZ; Wed, 19 Nov 2008 11:36:39 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id gzce1a0062P6wsM8azcek6; Wed, 19 Nov 2008 11:36:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=6ykPEjCJrQUoRgwKqCgA:9 a=LAolHNFjpSEw3Rrul98A:7 a=ylKGbplWJhykbP7ZhOsLVyqWbNYA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 4944233C37; Wed, 19 Nov 2008 03:36:38 -0800 (PST) Date: Wed, 19 Nov 2008 03:36:38 -0800 From: Jeremy Chadwick To: Alex Keda Message-ID: <20081119113638.GA85368@icarus.home.lan> References: <4923EA3F.2000801@lissyara.su> <20081119103326.GA83222@icarus.home.lan> <4923F201.6080606@lissyara.su> <20081119111545.GA84854@icarus.home.lan> <20081119111904.GA84939@icarus.home.lan> <4923F9AB.4020304@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4923F9AB.4020304@lissyara.su> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:36:39 -0000 On Wed, Nov 19, 2008 at 02:34:03PM +0300, Alex Keda wrote: > Jeremy Chadwick ??????????: >> On Wed, Nov 19, 2008 at 03:15:45AM -0800, Jeremy Chadwick wrote: >> >>> On Wed, Nov 19, 2008 at 02:01:21PM +0300, Alex Keda wrote: >>> >>>> Jeremy Chadwick ??????????: >>>> >>>>> On Wed, Nov 19, 2008 at 01:28:15PM +0300, Alex Keda wrote: >>>>> >>>>>> I replace default GENERIC kernel on my XEN kernel in FreeBSD >>>>>> installation CD-ROM (i386 7.0-RELEASE) >>>>>> But, I cannot boot in XEN - I see fast run "BTX halted" and >>>>>> many other debugging info. >>>>>> >>>>> BTX halted is a message coming from either boot2 or loader, not the >>>>> kernel. Do you see the FreeBSD beastie logo/menu before you see this >>>>> message? >>>>> >>>> No, but, messages go very fast - I'm doubt. >>>> >>>>> >>>>>> Can I boot from FreeBSD CD-ROM in XEN? >>>>>> >>>>> I know nothing about Xen (what it is, what purpose it serves, etc.). >>>>> If it's a "hardware emulator" of some sort, then I'd be wary of it. >>>>> Try things on real hardware if possible. >>>>> >>>> I try original CD - same behavior... >>>> >>> Can you please try using a 7.1-PRERELEASE i386 CD instead? There were >>> BTX changes made between 7.0 and 7.1 which may fix this (using real mode >>> for BTX). Those changes are documented in my Wiki (see bottom): >>> >>> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues >>> >> >> Also, I just realised you've posted to -current about issues with >> a 7.x release. Why is that? :-) >> > Kernel from CURRENT, but world - 7.0 =) Uhh... I'm done with this thread. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:40:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE5A1065670 for ; Wed, 19 Nov 2008 11:40:09 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7D98FC0C for ; Wed, 19 Nov 2008 11:40:09 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1L2lPe-0004j3-Hw for freebsd-current@freebsd.org; Wed, 19 Nov 2008 11:40:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 11:40:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 11:40:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.current Date: Wed, 19 Nov 2008 11:37:01 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 31 Message-ID: References: <200809222233.26053.max@love2party.net> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Max Laier User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: cosum: Checkout verification PoC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:40:10 -0000 Hi Max Laier! On Mon, 22 Sep 2008 22:33:25 +0200; Max Laier wrote about 'cosum: Checkout verification PoC': > the attached script will generate md5 and sha256 checksums of a checkout and > try to find the corresponding svn-revision. This can help to verify that your > checkout from cvsupX.yy.freebsd.org is authentic. Not that there is reason to > believe that we have compromised cvsup-servers. This is just something I've > been toying with and wanted to let you know to see if people find the idea > interesting. I'd also be interested in reviews of the concept (note that I > know that https would be a good idea, I just cba to setup a certificate). > The coverage currently is head and stable/{6,7} svn revision 179451:183186 > (i.e. since the first svn commit up to "2008-09-19 16:51:41 +0200". I don't > yet have a cronjob in place to generate new checksums, so this will become > less useful quick. If people do find it interesting, however, I could > certainly roll something. > As you can see, the script is ready to checksum cvs and svn checkouts. If you > obtain your checkout from some local git/hg/svk/... mirror you must modify the > find excludes accordingly. > Let me know what you think. This is a good solution for our users caring about security. I think such definitely should be incorporated into base system and server-side support be provided at freebsd.org on official basis. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:42:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC6F0106564A; Wed, 19 Nov 2008 11:42:02 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id 761798FC17; Wed, 19 Nov 2008 11:42:02 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id mAJBi3Lg004559; Wed, 19 Nov 2008 20:44:03 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200811191144.mAJBi3Lg004559@sana.init-main.com> To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-smp@freebsd.org Date: Wed, 19 Nov 2008 20:44:03 +0900 From: Takanori Watanabe Cc: Subject: Core i7 anyone else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 11:42:03 -0000 Hi, I recently bought Core i7 machine(for 145,000JPY: about $1500) and sometimes hangs up oddly. When in the state, some specific process only works and replys ping, but not reply any useful information. I suspect it may caused by CPU power management, so I cut almost all CPU power management feature on BIOS parameter. Are there any people encouterd such trouble? And on this machine build world in SCHED_ULE(15min.) is slower than SCHED_4BSD(12min.). ===dmesg=== http://www.init-main.com/corei7.dmesg or http://pastebin.com/m187f77aa (if host is down) =====DSDT==== http://www.init-main.com/corei7.asl or http://pastebin.com/m6879984a ==some sysctls== hw.machine: i386 hw.model: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz hw.ncpu: 8 hw.byteorder: 1234 hw.physmem: 3202322432 hw.usermem: 2956083200 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.realmem: 3211264000 == machdep.enable_panic_key: 0 machdep.adjkerntz: -32400 machdep.wall_cmos_clock: 1 machdep.disable_rtc_set: 0 machdep.disable_mtrrs: 0 machdep.guessed_bootdev: 2686451712 machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, machdep.hlt_cpus: 0 machdep.prot_fault_translation: 0 machdep.panic_on_nmi: 1 machdep.kdb_on_nmi: 1 machdep.tsc_freq: 2684011396 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1024240 machdep.hlt_logical_cpus: 0 machdep.logical_cpus_mask: 254 machdep.hyperthreading_allowed: 1 == kern.sched.preemption: 0 kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7 kern.sched.steal_thresh: 3 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 133 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 4 kern.sched.idlespins: 10000 kern.sched.static_boost: 160 kern.sched.preempt_thresh: 0 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE === From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:45:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09D481065670 for ; Wed, 19 Nov 2008 11:45:58 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by mx1.freebsd.org (Postfix) with ESMTP id AE9658FC1C for ; Wed, 19 Nov 2008 11:45:57 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so3220741rne.12 for ; Wed, 19 Nov 2008 03:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=0ZDVDrqO+j2g5JbmH+CetK3jts3TW1ZYQRUd4gMaIbM=; b=hvNfW6E9D2aUrnKVI2pruHRt0B06Ne2c2ygzLXKswZmZXLEcyqtSMqdMTbQXV2sxRa WRj5iycZ5xKaFPhKDMx+5GPXejrdcpZGIF8Vq4/ZOrX1Kgx+9usFkLUaeyopTAz0ks0J 9Ma/JQKjyBFfX8qaT+fiGah6b+IRsdjdQ+kog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rJfwdQBjJVAyLk31p8481vq4cnnNroj9yEGnosbHuuWh+XmEFMM0Nsf7g66HCUfn4T joJZ79bO2aKGVLrg3jEkr3BzUXk49bQO2lm5/30deE3iv+IOad+cCNZkSDpSEHSvq0Rz tIQ6KpWXqKpqeJ2uxKjJrWEO87Yr6BdNYo6ko= Received: by 10.150.156.9 with SMTP id d9mr1922411ybe.39.1227093389040; Wed, 19 Nov 2008 03:16:29 -0800 (PST) Received: by 10.151.106.2 with HTTP; Wed, 19 Nov 2008 03:16:28 -0800 (PST) Message-ID: <3481d8e60811190316t20850512s9115bef4a0443439@mail.gmail.com> Date: Wed, 19 Nov 2008 11:16:28 +0000 From: "Benoit Calvez" Sender: dzentoo@gmail.com To: "Alex Keda" In-Reply-To: <4923F201.6080606@lissyara.su> MIME-Version: 1.0 References: <4923EA3F.2000801@lissyara.su> <20081119103326.GA83222@icarus.home.lan> <4923F201.6080606@lissyara.su> X-Google-Sender-Auth: ea132c73620efe3d Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 11:45:58 -0000 T24gV2VkLCBOb3YgMTksIDIwMDggYXQgMTE6MDEgQU0sIEFsZXggS2VkYSA8YWRtaW5AbGlzc3lh cmEuc3U+IHdyb3RlOgoKPiBKZXJlbXkgQ2hhZHdpY2sg0MnbxdQ6Cj4KPj4gT24gV2VkLCBOb3Yg MTksIDIwMDggYXQgMDE6Mjg6MTVQTSArMDMwMCwgQWxleCBLZWRhIHdyb3RlOgo+Pgo+Pgo+Pj4g SSByZXBsYWNlIGRlZmF1bHQgR0VORVJJQyBrZXJuZWwgb24gbXkgWEVOIGtlcm5lbCBpbiBGcmVl QlNECj4+PiAgaW5zdGFsbGF0aW9uIENELVJPTSAoaTM4NiA3LjAtUkVMRUFTRSkKPj4+IEJ1dCwg SSBjYW5ub3QgYm9vdCBpbiBYRU4gLSBJIHNlZSBmYXN0IHJ1biAiQlRYIGhhbHRlZCIgYW5kIG1h bnkgb3RoZXIKPj4+ICBkZWJ1Z2dpbmcgaW5mby4KPj4+Cj4+Pgo+PiBCVFggaGFsdGVkIGlzIGEg bWVzc2FnZSBjb21pbmcgZnJvbSBlaXRoZXIgYm9vdDIgb3IgbG9hZGVyLCBub3QgdGhlCj4+IGtl cm5lbC4gIERvIHlvdSBzZWUgdGhlIEZyZWVCU0QgYmVhc3RpZSBsb2dvL21lbnUgYmVmb3JlIHlv dSBzZWUgdGhpcwo+PiBtZXNzYWdlPwo+Pgo+Pgo+IE5vLCBidXQsIG1lc3NhZ2VzIGdvIHZlcnkg ZmFzdCAtIEknbSBkb3VidC4KPgo+Pgo+Pgo+Pj4gQ2FuIEkgYm9vdCBmcm9tIEZyZWVCU0QgQ0Qt Uk9NIGluIFhFTj8KPj4+Cj4+Pgo+Pgo+PiBJIGtub3cgbm90aGluZyBhYm91dCBYZW4gKHdoYXQg aXQgaXMsIHdoYXQgcHVycG9zZSBpdCBzZXJ2ZXMsIGV0Yy4pLgo+PiBJZiBpdCdzIGEgImhhcmR3 YXJlIGVtdWxhdG9yIiBvZiBzb21lIHNvcnQsIHRoZW4gSSdkIGJlIHdhcnkgb2YgaXQuCj4+IFRy eSB0aGluZ3Mgb24gcmVhbCBoYXJkd2FyZSBpZiBwb3NzaWJsZS4KPj4KPj4KPiBJIHRyeSBvcmln aW5hbCBDRCAtIHNhbWUgYmVoYXZpb3IuLi4KPgoKSW4gb3JkZXIgdG8gZ2V0IGEgWEVOIGRvbVUg d29ya2luZywgSSBjcmVhdGVkIGFuIGltYWdlIG9mIGEgZnJlZWJzZCA6Cm1ha2Uga2VybmVsIEtF Uk5DT05GPVhFTgptYWtlIHdvcmxkIERFU1RESVI9L21udAptYWtlIGRpc3RyaWJ1dGlvbiBERVNU RElSPS9tbnQKCm9yIHNvbWV0aGluZyBsaWtlLgoKdGhlbiBJIHJ1biB4bSBjcmVhdGUgd2l0aCB0 aGlzIGltYWdlLgoKdGVsbCBtZSBpZiB5b3UgbmVlZCBtb3JlIGluZm9ybWF0aW9ucyBvciBpZiB5 b3UgbmVlZCBzb21lIGhlbHAuCgoKCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIG1haWxpbmcg bGlzdAo+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qt Y3VycmVudAo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWN1cnJl bnQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciCj4KCgoKLS0gCkJlbm9pdCBDYWx2ZXouCg== From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:47:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57A171065673 for ; Wed, 19 Nov 2008 11:47:17 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id F128A8FC13 for ; Wed, 19 Nov 2008 11:47:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA08.westchester.pa.mail.comcast.net with comcast id gyqB1a0010Fqzac58zmbXk; Wed, 19 Nov 2008 11:46:35 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA08.westchester.pa.mail.comcast.net with comcast id gznE1a00Q2P6wsM3UznFzA; Wed, 19 Nov 2008 11:47:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=DiZ76wm4AAAA:8 a=fGO4tVQLAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=8oBBsJxBPgm8k0VuyQAA:9 a=CmO0HorRqYcm4XbtWS8pjeXFcQ8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id B30E933C36; Wed, 19 Nov 2008 03:47:14 -0800 (PST) Date: Wed, 19 Nov 2008 03:47:14 -0800 From: Jeremy Chadwick To: Takanori Watanabe Message-ID: <20081119114714.GA85533@icarus.home.lan> References: <200811191144.mAJBi3Lg004559@sana.init-main.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200811191144.mAJBi3Lg004559@sana.init-main.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-smp@freebsd.org Subject: Re: Core i7 anyone else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 11:47:17 -0000 On Wed, Nov 19, 2008 at 08:44:03PM +0900, Takanori Watanabe wrote: > Hi, I recently bought Core i7 machine(for 145,000JPY: about $1500) > and sometimes hangs up oddly. > When in the state, some specific process only works and > replys ping, but not reply any useful information. > > I suspect it may caused by CPU power management, so I cut > almost all CPU power management feature on BIOS parameter. > > Are there any people encouterd such trouble? > And on this machine build world in SCHED_ULE(15min.) is slower > than SCHED_4BSD(12min.). > > > ===dmesg=== > http://www.init-main.com/corei7.dmesg > or > http://pastebin.com/m187f77aa > (if host is down) > > =====DSDT==== > http://www.init-main.com/corei7.asl > or > http://pastebin.com/m6879984a > > ==some sysctls== > hw.machine: i386 > hw.model: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz > hw.ncpu: 8 > hw.byteorder: 1234 > hw.physmem: 3202322432 > hw.usermem: 2956083200 > hw.pagesize: 4096 > hw.floatingpoint: 1 > hw.machine_arch: i386 > hw.realmem: 3211264000 > == > machdep.enable_panic_key: 0 > machdep.adjkerntz: -32400 > machdep.wall_cmos_clock: 1 > machdep.disable_rtc_set: 0 > machdep.disable_mtrrs: 0 > machdep.guessed_bootdev: 2686451712 > machdep.idle: acpi > machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, > machdep.hlt_cpus: 0 > machdep.prot_fault_translation: 0 > machdep.panic_on_nmi: 1 > machdep.kdb_on_nmi: 1 > machdep.tsc_freq: 2684011396 > machdep.i8254_freq: 1193182 > machdep.acpi_timer_freq: 3579545 > machdep.acpi_root: 1024240 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 254 > machdep.hyperthreading_allowed: 1 > == > kern.sched.preemption: 0 > kern.sched.topology_spec: > > 0, 1, 2, 3, 4, 5, 6, 7 > > > > > kern.sched.steal_thresh: 3 > kern.sched.steal_idle: 1 > kern.sched.steal_htt: 1 > kern.sched.balance_interval: 133 > kern.sched.balance: 1 > kern.sched.affinity: 1 > kern.sched.idlespinthresh: 4 > kern.sched.idlespins: 10000 > kern.sched.static_boost: 160 > kern.sched.preempt_thresh: 0 > kern.sched.interact: 30 > kern.sched.slice: 13 > kern.sched.name: ULE > === When building world/kernel, do you see odd behaviour (on CURRENT) such as the load average being absurdly high, or processes (anything; sh, make, mutt, etc.) getting stuck in bizarre states? These things are what caused my buildworld/buildkernel times to increase (compared to RELENG_7). I was using ULE entirely (on CURRENT and RELENG_7), but did not try 4BSD. I documented my experience. http://wiki.freebsd.org/JeremyChadwick/Bizarre_CURRENT_experience I have no idea if your problem is the same as mine. This is purely speculative on my part. (And readers of that Wiki article should note that the problem was not hardware-related) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:58:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 735F61065693 for ; Wed, 19 Nov 2008 11:58:58 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id ECF508FC1E for ; Wed, 19 Nov 2008 11:58:57 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so2150587nfh.33 for ; Wed, 19 Nov 2008 03:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-pgp-agent:x-mailer; bh=cIxTxEI1bMFGU9CCu3bkddMpikw3SqxM4rmRwO9Fo3A=; b=e8FvQwjLqZtYxdiKgGjXj/ctX6aQLr6k9dFND5IhOt2za/fO/tcJ2RKJZxb3l/08yx Ed+CcxCtBrOpKt/16PZgMoVbGkKK4VnoVf9X8jZAXzN7mZ4RtX5ePQU7Z1pgd2IIUfXY yajt0LTK+0MumazCGVe7CwAMmAkXHkRH0Dto4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-pgp-agent:x-mailer; b=lhq4vtmCE8omFrk5NztjiUgkbkPxXYB5Kyfk0M0vwtleXAsSV+jfx2iAKUW2anPeui l3haJf7LTbvJtvJkpHvGLrIUiQk8CG1frLo1gTMWnl3liXEOuVL5PzMJ2DwwZH7pphhN ETBaiU2P6aYwLzl8jrkYuLjezcs2LNFhtatIk= Received: by 10.103.222.1 with SMTP id z1mr330229muq.121.1227095936657; Wed, 19 Nov 2008 03:58:56 -0800 (PST) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id j2sm16897589mue.4.2008.11.19.03.58.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Nov 2008 03:58:54 -0800 (PST) Message-Id: <18E318DD-29FA-4E26-89CF-11B893B42E34@gmail.com> From: Nikolay Denev To: freebsd-current@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 13:58:49 +0200 References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> <20081119090307.GA81236@icarus.home.lan> X-Pgp-Agent: GPGMail d53 (v53, Leopard) X-Mailer: Apple Mail (2.929.2) Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 11:58:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov, 2008, at 11:48 , Nikolay Denev wrote: > > Well, it looks like that on -current and a 4G amd64 machine probably > there is no need > to tune anything. Here are my defaults with everything vm and zfs > related in loader.conf commented : > > vm.kmem_size_max: 4509713203 > vfs.zfs.arc_max: 863907840 > I was able to panic it again with "kmem_map too small" with these settings (defaults). This are the bonnie++ arguments that i've used: bonnie++ -d /tank -c 4 -r 4096 -x 9999999 -u 0:0 - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkkj/3kACgkQHNAJ/fLbfrm0rQCfccJ4Rusxm4NGs+2BsR7l7P/6 BigAn3DutT6lXrcT1Mwh0gp28pZxAWTc =bEl5 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 12:00:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9F21065673 for ; Wed, 19 Nov 2008 12:00:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 32CFD8FC0A for ; Wed, 19 Nov 2008 12:00:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1L2lj1-0005Q0-7t for freebsd-current@freebsd.org; Wed, 19 Nov 2008 12:00:03 +0000 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, 19 Nov 2008 12:00:03 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 12:00:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Nov 2008 12:58:54 +0100 Lines: 92 Message-ID: <4923FF7E.1080101@freebsd.org> References: <200811191144.mAJBi3Lg004559@sana.init-main.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCFC1809BFB1D0993DBF70FC6" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: <200811191144.mAJBi3Lg004559@sana.init-main.com> X-Enigmail-Version: 0.95.0 Sender: news Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-smp@freebsd.org Subject: Re: Core i7 anyone else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 12:00:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFC1809BFB1D0993DBF70FC6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Takanori Watanabe wrote: > Hi, I recently bought Core i7 machine(for 145,000JPY: about $1500) > and sometimes hangs up oddly. > When in the state, some specific process only works and=20 > replys ping, but not reply any useful information. >=20 > I suspect it may caused by CPU power management, so I cut=20 > almost all CPU power management feature on BIOS parameter. >=20 > Are there any people encouterd such trouble? > And on this machine build world in SCHED_ULE(15min.) is slower=20 > than SCHED_4BSD(12min.). I don't know but this: > =3D=3D=3Ddmesg=3D=3D=3D > http://www.init-main.com/corei7.dmesg > or > http://pastebin.com/m187f77aa > (if host is down) CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2684.00-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x106a4 Stepping =3D 4 Features=3D0xbfebfbff Features2=3D0x98e3bd AMD Features=3D0x28100000 AMD Features2=3D0x1 Cores per package: 8 Logical CPUs per core: 2 real memory =3D 3211264000 (3062 MB) avail memory =3D 3143983104 (2998 MB) ACPI APIC Table: <7522MS A7522100> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 is a bit in conflict with this: > kern.sched.topology_spec: > > 0, 1, 2, 3, 4, 5, 6, 7 > > > =46rom what I know of its architecture i7 has hyperthreading - i.e. the CPU has 4 "real" cores which are hyperthreaded, so you get 8 cores total. It probably also includes a different way of enumerating its topology which might have caused wrong topology detection and your slowdown in buildworld. (the CPU also has L3 cache, but I think it's not looked up in topology detection). I don't know it this particular error could be responsible for your lockups - probably not. The CPU also introduces some big changes in power management (dynamic powerdown of individual cores) which could cause them - but I can't help you there. Are you sure it's not something trivial like overheating? --------------enigCFC1809BFB1D0993DBF70FC6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJI/9+ldnAQVacBcgRAptBAKCvy5iMZkVJ7f/v/8jWVRvs0Oa1vwCgnlPY fl3ySAZXU5NXl0ZmOXf43t4= =hTDW -----END PGP SIGNATURE----- --------------enigCFC1809BFB1D0993DBF70FC6-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 12:09:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED04E1065674 for ; Wed, 19 Nov 2008 12:09:11 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 38DA78FC0C for ; Wed, 19 Nov 2008 12:09:10 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.dons.net.au (ppp121-45-191-177.lns11.adl2.internode.on.net [121.45.191.177]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id mAJBkBRg083939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 22:16:12 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 19 Nov 2008 22:06:16 +1030 User-Agent: KMail/1.9.10 References: <4923EA3F.2000801@lissyara.su> In-Reply-To: <4923EA3F.2000801@lissyara.su> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3050936.mgUoEj7Jb8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200811192215.57077.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Alex Keda Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 12:09:12 -0000 --nextPart3050936.mgUoEj7Jb8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 19 November 2008 20:58:15 Alex Keda wrote: > I replace default GENERIC kernel on my XEN kernel in FreeBSD > installation CD-ROM (i386 7.0-RELEASE) > But, I cannot boot in XEN - I see fast run "BTX halted" and many other > debugging info. > =3D=3D=3D=3D=3D=3D=3D > Can I boot from FreeBSD CD-ROM in XEN? Try 7.1, there have been BTX changes merged in. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3050936.mgUoEj7Jb8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJI/x05ZPcIHs/zowRArLRAJ4sJOLg34dgIc+0Bmae57JJqCNk2wCgjiCS cMr3dday5LkXHwrW1bk0HBk= =Vahp -----END PGP SIGNATURE----- --nextPart3050936.mgUoEj7Jb8-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 12:41:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60E5E1065678 for ; Wed, 19 Nov 2008 12:41:34 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0E53C8FC12 for ; Wed, 19 Nov 2008 12:41:33 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=Z8eRjfWaSx2sqHssQHZg7gJJKAYjII5UZP2eKK8J7IOCzT/dlE/t6kfqOdKhuEtNR4PM4XEvrpcOD6XW5EmE4oyUrUlsqQpofGeIRUWcP1/3Eq0MWADIDbCnrk9C/HnBv/aG0uebIA6d+opZI0zIL7LjfN596EaN+fcUdSO94Cg=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1L2mNA-00095x-Hm; Wed, 19 Nov 2008 15:41:32 +0300 Date: Wed, 19 Nov 2008 15:41:31 +0300 From: Eygene Ryabinkin To: Alex Keda Message-ID: <4sNxypt8R201dGb6JaLKyTtJz3U@Jvtg/8mhD1ZfnKbJcxBaTpEcHC0> References: <4923EA3F.2000801@lissyara.su> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yPlaimQd/TpiYx8R" Content-Disposition: inline In-Reply-To: <4923EA3F.2000801@lissyara.su> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: Boot from CD-ROM in XEN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 12:41:34 -0000 --yPlaimQd/TpiYx8R Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alex, good day. Wed, Nov 19, 2008 at 01:28:15PM +0300, Alex Keda wrote: > I replace default GENERIC kernel on my XEN kernel in FreeBSD=20 > installation CD-ROM (i386 7.0-RELEASE) > But, I cannot boot in XEN - I see fast run "BTX halted" and many other=20 > debugging info. You should use real-mode BTX. It was committed to RELENG_7 at revision 1.44.2.1 of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S Don't know if you'll be able to use 7.1-BETA2 images, but probably yes: they were created after the merge of real-mode BTX. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --yPlaimQd/TpiYx8R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkkCXsACgkQthUKNsbL7YiH5QCffj866VAlXaXMilF7m0oDHEBl v8oAmwbaCMfUenQj8iYeb0BauRAdxDgc =Qlr0 -----END PGP SIGNATURE----- --yPlaimQd/TpiYx8R-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 14:34:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7F5A1065670 for ; Wed, 19 Nov 2008 14:34:39 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 595218FC1D for ; Wed, 19 Nov 2008 14:34:39 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1441318yxb.13 for ; Wed, 19 Nov 2008 06:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=MrWD5LRdwwLTAcVjvT/llJQS5+sYbEj7N5KXW0HEu5U=; b=hw1AM4H3AiXgzy7ShrXHezgZ1k4bMddO7bkx2PdeuZADjndbaAx0zlr5q+wzJBWLiF F+yHvbR4RyP1zxLGSYfA91JCN7POMWaCn1LyNoAQyntInV7iSruB/hMfQrQszds8gXCP op8ZdQT+67FRFg1UV/uoXAJTsh2iJ9p5evM9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=JWWLcLM5gFYmOLhl/zU+IwSqV3yDPhWi5RRp5QE9VdJ2c5wJUwH+blaz8kQRuOY4BT JUzYb0QdfDNMZCcDcYdzyq5FxwGtGq1DDBRgtr7RsMA/hzmPY46vl73EE4SCAZmpK6sz hwF6AkxRWCzlO0QQJeTu4TDkphtqvBXgfKD1E= Received: by 10.65.241.15 with SMTP id t15mr1123088qbr.8.1227103478527; Wed, 19 Nov 2008 06:04:38 -0800 (PST) Received: by 10.64.156.4 with HTTP; Wed, 19 Nov 2008 06:04:38 -0800 (PST) Message-ID: <515c64960811190604w4f22e5a0ta4ed07323fcb697d@mail.gmail.com> Date: Wed, 19 Nov 2008 19:34:38 +0530 From: Channa To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: FreeBSD performance on single CPU. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 14:34:39 -0000 Hi, I am using FreeBSD malloc from the current working branch. I hope its jemalloc. I tested it on a single CPU machine i could get the following results # ./malloc-test 1024 10000000 4 Starting test... Thread -1096811184 adjusted timing: 102.369100 seconds for 10000000 requests of 1024 bytes. Thread -1101005488 adjusted timing: 103.212512 seconds for 10000000 requests of 1024 bytes. Thread -1098908336 adjusted timing: 103.491399 seconds for 10000000 requests of 1024 bytes. Thread -1094714032 adjusted timing: 103.605124 seconds for 10000000 requests of 1024 bytes. I checked the result in the FreeBSD mailing list link given below: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-12/msg00294.html The jemalloc gives very good results. Is that the performance is good only on SMP? Or on single processor also it should perform well? But on single CPU i could see bad results. Could anyone help me out? Thanks in Advance, Channa From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 14:44:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D1E510656D7 for ; Wed, 19 Nov 2008 14:44:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E35DA8FC13 for ; Wed, 19 Nov 2008 14:44:38 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L2oIF-0003C8-Fb for freebsd-current@freebsd.org; Wed, 19 Nov 2008 14:44:35 +0000 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, 19 Nov 2008 14:44:35 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 14:44:35 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Nov 2008 15:45:21 +0100 Lines: 67 Message-ID: References: <515c64960811190604w4f22e5a0ta4ed07323fcb697d@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD754771698A747AD686B46C0" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: <515c64960811190604w4f22e5a0ta4ed07323fcb697d@mail.gmail.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD performance on single CPU. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 14:44:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD754771698A747AD686B46C0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Channa wrote: > Hi, >=20 > I am using FreeBSD malloc from the current working branch. > I hope its jemalloc. >=20 > I tested it on a single CPU machine i could get the following results >=20 > # ./malloc-test 1024 10000000 4 >=20 > Starting test... > Thread -1096811184 adjusted timing: 102.369100 seconds for 10000000 > requests of 1024 bytes. > Thread -1101005488 adjusted timing: 103.212512 seconds for 10000000 > requests of 1024 bytes. > Thread -1098908336 adjusted timing: 103.491399 seconds for 10000000 > requests of 1024 bytes. > Thread -1094714032 adjusted timing: 103.605124 seconds for 10000000 > requests of 1024 bytes. >=20 > I checked the result in the FreeBSD mailing list link given below: >=20 > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-12/msg0029= 4.html >=20 > The jemalloc gives very good results. Is that the performance is good > only on SMP? >=20 > Or on single processor also it should perform well? >=20 > But on single CPU i could see bad results. >=20 > Could anyone help me out? Your message is not very clear but here are some things that might help y= ou: 1) -CURRENT has debugging enabled both in kernel and in malloc. You need to disable both before benchmarking anything. 2) According to the post you linked, jemalloc should be 1.1 times faster for single-threaded processes than phkmalloc, on that particular benchmark. This benefit will probably also be visible on single-CPU machines. 3) You don't need to run -CURRENT to get jemalloc - it is also prosent in 7.0. --------------enigD754771698A747AD686B46C0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJJCaCldnAQVacBcgRAjqYAKCsULnyELvtx+Rm2/At08vBKOGouQCdFaYW PFZ82fD/VjGz9tcitvEZBAw= =JUAl -----END PGP SIGNATURE----- --------------enigD754771698A747AD686B46C0-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 14:56:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3571065670 for ; Wed, 19 Nov 2008 14:56:53 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 47E008FC18 for ; Wed, 19 Nov 2008 14:56:52 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so1467176ana.13 for ; Wed, 19 Nov 2008 06:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tzpICMtoAFNXSWwRwLYwUEMDYJYZ1/bEpcEPJR54dJI=; b=C3AT1Wh9HfwpMJHOBw6K8QkSO7WOpKx0q9GtcKCUFadQkzbhRgNqW+EccVXPDhwJWP zUIwswX4eYkSz131JB8S3NM7He4P/uDzgQnT3UihxQDGrztYV93oypXfPMzTv5Fz0NqI DQv3iPnX+K0Po5jCRnf9SYeAA1cPMVev1Kl5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pngBBgTOjRSgCpQlWF8faHndzccvTQOpMUdLGh7dQNHfD0j8RJz3/+7qIAq1JzF6Om +RE9YhXsO22zbIf2FOMinjXLmmEMcsj0oUvp2zAeVMh+bjgRCTgaBtKov5LV8froYVss OXziROYBMyoFUK8UT1+dRJwRpV/gkJnDDliMo= Received: by 10.65.11.17 with SMTP id o17mr1177471qbi.4.1227106611042; Wed, 19 Nov 2008 06:56:51 -0800 (PST) Received: by 10.64.156.4 with HTTP; Wed, 19 Nov 2008 06:56:51 -0800 (PST) Message-ID: <515c64960811190656i5b103d15s44b0a35a6b9455e@mail.gmail.com> Date: Wed, 19 Nov 2008 20:26:51 +0530 From: Channa To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <515c64960811190604w4f22e5a0ta4ed07323fcb697d@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD performance on single CPU. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 14:56:53 -0000 Hi, Thank you very much for your information. I am using current implementation of FreeBSD malloc. I am checking the performance on single CPU machine. I am using it in my own environment i am not using FreeBSD7.0. I disabled the MALLOC_DEBUG option in the malloc implementaton and checked the performance i see no difference the results are the same. ./mallco-test Starting test... Thread -1101005488 adjusted timing: 4.495931 seconds for 1000000 requests of 512 bytes. Could please tell me if anything else needs to be changed.? Thanks in Advance, Channa 2008/11/19 Ivan Voras : > Channa wrote: >> Hi, >> >> I am using FreeBSD malloc from the current working branch. >> I hope its jemalloc. >> >> I tested it on a single CPU machine i could get the following results >> >> # ./malloc-test 1024 10000000 4 >> >> Starting test... >> Thread -1096811184 adjusted timing: 102.369100 seconds for 10000000 >> requests of 1024 bytes. >> Thread -1101005488 adjusted timing: 103.212512 seconds for 10000000 >> requests of 1024 bytes. >> Thread -1098908336 adjusted timing: 103.491399 seconds for 10000000 >> requests of 1024 bytes. >> Thread -1094714032 adjusted timing: 103.605124 seconds for 10000000 >> requests of 1024 bytes. >> >> I checked the result in the FreeBSD mailing list link given below: >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-12/msg00294.html >> >> The jemalloc gives very good results. Is that the performance is good >> only on SMP? >> >> Or on single processor also it should perform well? >> >> But on single CPU i could see bad results. >> >> Could anyone help me out? > > Your message is not very clear but here are some things that might help you: > > 1) -CURRENT has debugging enabled both in kernel and in malloc. You need > to disable both before benchmarking anything. > 2) According to the post you linked, jemalloc should be 1.1 times faster > for single-threaded processes than phkmalloc, on that particular > benchmark. This benefit will probably also be visible on single-CPU > machines. > 3) You don't need to run -CURRENT to get jemalloc - it is also prosent > in 7.0. > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 15:39:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0417D106564A for ; Wed, 19 Nov 2008 15:39:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 78AB78FC13 for ; Wed, 19 Nov 2008 15:39:07 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L2p8w-0005KT-6p for freebsd-current@freebsd.org; Wed, 19 Nov 2008 15:39:02 +0000 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, 19 Nov 2008 15:39:02 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2008 15:39:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Nov 2008 16:39:48 +0100 Lines: 110 Message-ID: References: <515c64960811190604w4f22e5a0ta4ed07323fcb697d@mail.gmail.com> <515c64960811190656i5b103d15s44b0a35a6b9455e@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig89A5C1A4C5C0272C73646E6A" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: <515c64960811190656i5b103d15s44b0a35a6b9455e@mail.gmail.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD performance on single CPU. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 15:39:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig89A5C1A4C5C0272C73646E6A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Channa wrote: > Hi, > Thank you very much for your information. >=20 > I am using current implementation of FreeBSD malloc. > I am checking the performance on single CPU machine. >=20 > I am using it in my own environment i am not using FreeBSD7.0. >=20 > I disabled the MALLOC_DEBUG option in the malloc implementaton > and checked the performance i see no difference the results are the sam= e. >=20 > ./mallco-test > Starting test... > Thread -1101005488 adjusted timing: 4.495931 seconds for 1000000 > requests of 512 bytes. >=20 > Could please tell me if anything else needs to be changed.? Yes, you need to disable kernel debugging also. (you have recompiled libc after removing MALLOC_DEBUG, right?). Also, it looks like your comparisons have problems. You are changing the number of requests and request size. Finally, to what are you actually comparing the malloc performance to? Why are you trying to benchmark it? > 2008/11/19 Ivan Voras : >> Channa wrote: >>> Hi, >>> >>> I am using FreeBSD malloc from the current working branch. >>> I hope its jemalloc. >>> >>> I tested it on a single CPU machine i could get the following results= >>> >>> # ./malloc-test 1024 10000000 4 >>> >>> Starting test... >>> Thread -1096811184 adjusted timing: 102.369100 seconds for 10000000 >>> requests of 1024 bytes. >>> Thread -1101005488 adjusted timing: 103.212512 seconds for 10000000 >>> requests of 1024 bytes. >>> Thread -1098908336 adjusted timing: 103.491399 seconds for 10000000 >>> requests of 1024 bytes. >>> Thread -1094714032 adjusted timing: 103.605124 seconds for 10000000 >>> requests of 1024 bytes. >>> >>> I checked the result in the FreeBSD mailing list link given below: >>> >>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-12/msg00= 294.html >>> >>> The jemalloc gives very good results. Is that the performance is good= >>> only on SMP? >>> >>> Or on single processor also it should perform well? >>> >>> But on single CPU i could see bad results. >>> >>> Could anyone help me out? >> Your message is not very clear but here are some things that might hel= p you: >> >> 1) -CURRENT has debugging enabled both in kernel and in malloc. You ne= ed >> to disable both before benchmarking anything. >> 2) According to the post you linked, jemalloc should be 1.1 times fast= er >> for single-threaded processes than phkmalloc, on that particular >> benchmark. This benefit will probably also be visible on single-CPU >> machines. >> 3) You don't need to run -CURRENT to get jemalloc - it is also prosent= >> in 7.0. >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 --------------enig89A5C1A4C5C0272C73646E6A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJJDNEldnAQVacBcgRAsNRAJ907ChqmcpY4gziPVjWjcd5xO3VDACfZ3Sg MZdh9glZNMXzdBz5CODnHFY= =t2RS -----END PGP SIGNATURE----- --------------enig89A5C1A4C5C0272C73646E6A-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 20:11:31 2008 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 665B11065748 for ; Wed, 19 Nov 2008 20:11:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD618FC0A for ; Wed, 19 Nov 2008 20:11:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAJKB3bF052213 for ; Wed, 19 Nov 2008 15:11:22 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: current@FreeBSD.org Date: Wed, 19 Nov 2008 15:03:02 -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: <200811191503.02192.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 19 Nov 2008 15:11:22 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8650/Tue Nov 18 23:59:50 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 20:11:31 -0000 Please test! This is the last non-MPSAFE network driver at this point. This patch adds locking for the ppbus(4)/ppc(4) devices and the various ppbus child devices (lpt, vpo, lpbb, ppi, pps). The basic model is that a single mutex in the ppc(4) driver protects the ppc0 hardware and is shared with the various child drivers. Two drivers now have detach methods that did not have them before (plip and ppi). I've done some simple testing on my laptop (able to load the drivers and do some simple things w/o panic'ing or tripping assertions), but I am not really able to test the peripheral drivers fully. http://www.FreeBSD.org/~jhb/patches/ppc_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 20:11:39 2008 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 CCD8D106564A for ; Wed, 19 Nov 2008 20:11:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 759098FC12 for ; Wed, 19 Nov 2008 20:11:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAJKB3bH052213 for ; Wed, 19 Nov 2008 15:11:33 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: current@FreeBSD.org Date: Wed, 19 Nov 2008 15:10:53 -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: <200811191510.53793.jhb@FreeBSD.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 19 Nov 2008 15:11:33 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8650/Tue Nov 18 23:59:50 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2008 20:11:39 -0000 This is a relatively simple patch to mark cd9660 MPSAFE and enable shared lookups. The changes to cd9660_lookup() mirror similar changes to ufs_lookup() to use static variables for local data rather than abusing i-node members of the parent directory. I've done some light testing of this, but not super-strenuous. This patch also includes simple locking for the iconv support in the kernel. That locking uses an sx lock to serialize open and close of translator tables and the associated refcount. Actual conversions do not need any locks, however as the mount holds a reference on the table. http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 00:15:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 691471065673 for ; Thu, 20 Nov 2008 00:15:56 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp809.mail.ird.yahoo.com (smtp809.mail.ird.yahoo.com [217.146.188.69]) by mx1.freebsd.org (Postfix) with SMTP id CBF078FC16 for ; Thu, 20 Nov 2008 00:15:55 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 10801 invoked from network); 20 Nov 2008 00:15:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=TRQzjXkAq+go5dnw+6hkKalTEiOBaM/e61mQPwJwzmbhlsh/kUl2aEhT3fAcaX+KglHDKjyyFQtRVUHtpIpA71P1gjCfs1EjBZfy7mI7crZTwIw/aYrwt17EY9FpSl/7Y+J7oe0CpzDMuAlYuJnyITOTFipysx2NJBNOdv7eqFM= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.134.117.32 with login) by smtp809.mail.ird.yahoo.com with SMTP; 20 Nov 2008 00:15:54 -0000 X-YMail-OSG: PiYMOVQVM1lkYf940eZNgMwNDvkNjXgBqA9QQSZV7C3U5CDwHN3.I8fLpQzOakSH5Diy.KhZae1q0wLt26tfSJrUAz2Pskk8WxO5POXnA39mCqn9s1UZ9LsXLp5_f4Zci60- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Thu, 20 Nov 2008 00:15:53 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811182340.13372.Thomas.Sparrevohn@btinternet.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811200015.54319.Thomas.Sparrevohn@btinternet.com> Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 00:15:56 -0000 On Wednesday 19 November 2008 10:14:02 Ivan Voras wrote: > Thomas Sparrevohn wrote: > > On Tuesday 18 November 2008 21:56:38 Pawel Jakub Dawidek wrote: > >> On Tue, Nov 18, 2008 at 09:50:51PM +0000, Thomas Sparrevohn wrote: > >>> On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: > >>>> What's unexpected in that? As I noted it still needs more work, so > >>>> chflags(2) working properly would be unexpected for me:) > >>>> > >>>>> -------------------------------------------------------------- > >>> LOL - Unexpected that it just not returns operation not supported as it used to - I was a bit > >>> trigger happy and upgraded my main pool - against the sound advice - leaves me in a bit of trouble ;-) > >> Try 'make installworld NO_FSCHG='. > >> > > > > LOL and now I feel really stupid - thanks > > Hmmm, I did an installworld from UFS to ZFS yesterday without special > flags (actually, multiple installworlds for benchmarking), without > errors. Files really did get schg (or equivalent) flag since I couldn't > rm them afterwards. How is this possible? :) > > > That is a surprise - as mine failed - totally - had to manually restore libc From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 00:31:10 2008 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 7FC271065674; Thu, 20 Nov 2008 00:31:10 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 593858FC18; Thu, 20 Nov 2008 00:31:10 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 879701BF800; Wed, 19 Nov 2008 19:15:40 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 19 Nov 2008 19:15:40 -0500 X-Sasl-enc: QNzsKblBGm/nStWrwk32pIHHm0owNoxqBjnVSfBiXksD 1227140140 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id D87002BAD2; Wed, 19 Nov 2008 19:15:39 -0500 (EST) Message-ID: <4924AC27.3090302@incunabulum.net> Date: Thu, 20 Nov 2008 00:15:35 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: John Baldwin References: <200811191503.02192.jhb@freebsd.org> In-Reply-To: <200811191503.02192.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 00:31:10 -0000 John, Thanks for this. John Baldwin wrote: > Please test! This is the last non-MPSAFE network driver at this point. This > ... > My only box using lpt(4) is running 7.1-PRERELEASE, this patch should backport, yes? It is a right pain in the arse when something happens with my venerable GCC Elite 600, e.g. a paper jam, and the entire box grinds to a halt because lpt_intr() was called with Giant held. cheers BMS From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 04:20:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 681DC1065674 for ; Thu, 20 Nov 2008 04:20:23 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by mx1.freebsd.org (Postfix) with ESMTP id B922E8FC1B for ; Thu, 20 Nov 2008 04:20:21 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: by gxk5 with SMTP id 5so322684gxk.19 for ; Wed, 19 Nov 2008 20:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nsdzhwUqDD57rBxHEbVfJVGUa+EL6WPngJUhalImvQM=; b=emSKtis+qJ/IBYkYReF9ay1BsERJTAclX+xjwgmCBH8HnA20XOoX9x/sOt8Qffnjzz vsiwnIryPh8vGh3/MhAa2LLgFMAQSD8FYnqIjTczDDpo9AGsXRp393KJBYLpSHBPezHX TIgHpiUDMeQbLs+85wZ+lKHd0d0O4ebQRa+IU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cbeLiPOkio/5LEVI+oP6ihYE6ruNr+TUg9CZ0xn+znEtwcCcw0R42VbUvqWcdncWx3 6AXjOjuod3v23atEnLQy+8ct8jzd/+qrFs18O5HGyf0dvqCa5hBZB3vdSEcXEznWFXMQ fH+p6XuykTW4f4kzL3m2kCEpaiYHi32CA7Zsc= Received: by 10.65.153.10 with SMTP id f10mr1656121qbo.70.1227154820750; Wed, 19 Nov 2008 20:20:20 -0800 (PST) Received: by 10.64.156.4 with HTTP; Wed, 19 Nov 2008 20:20:20 -0800 (PST) Message-ID: <515c64960811192020m18488aa5l68d15fbaf5d2444@mail.gmail.com> Date: Thu, 20 Nov 2008 09:50:20 +0530 From: Channa To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <515c64960811190604w4f22e5a0ta4ed07323fcb697d@mail.gmail.com> <515c64960811190656i5b103d15s44b0a35a6b9455e@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD performance on single CPU. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 04:20:23 -0000 Hi, Yes i have recompiled the libc after removing the MALLOC_DEBUG. I am trying to compare with the linux malloc performance (i.e. glibc malloc). I want to use the FreeBSD malloc in my own library so after putting it in my own library i am comparing with linux malloc performance with the freebsd malloc. I compared without changing the request and the size too but i could not observe the performance of freeBSD malloc to be same as the mailing list link i gave you in the first mail. So my doubt whether freeBSD malloc should show the same performance on single CPU? Thanks in Advance, Channa 2008/11/19 Ivan Voras : > Channa wrote: >> Hi, >> Thank you very much for your information. >> >> I am using current implementation of FreeBSD malloc. >> I am checking the performance on single CPU machine. >> >> I am using it in my own environment i am not using FreeBSD7.0. >> >> I disabled the MALLOC_DEBUG option in the malloc implementaton >> and checked the performance i see no difference the results are the same. >> >> ./mallco-test >> Starting test... >> Thread -1101005488 adjusted timing: 4.495931 seconds for 1000000 >> requests of 512 bytes. >> >> Could please tell me if anything else needs to be changed.? > > Yes, you need to disable kernel debugging also. (you have recompiled > libc after removing MALLOC_DEBUG, right?). > > Also, it looks like your comparisons have problems. You are changing the > number of requests and request size. > > Finally, to what are you actually comparing the malloc performance to? > Why are you trying to benchmark it? > > >> 2008/11/19 Ivan Voras : >>> Channa wrote: >>>> Hi, >>>> >>>> I am using FreeBSD malloc from the current working branch. >>>> I hope its jemalloc. >>>> >>>> I tested it on a single CPU machine i could get the following results >>>> >>>> # ./malloc-test 1024 10000000 4 >>>> >>>> Starting test... >>>> Thread -1096811184 adjusted timing: 102.369100 seconds for 10000000 >>>> requests of 1024 bytes. >>>> Thread -1101005488 adjusted timing: 103.212512 seconds for 10000000 >>>> requests of 1024 bytes. >>>> Thread -1098908336 adjusted timing: 103.491399 seconds for 10000000 >>>> requests of 1024 bytes. >>>> Thread -1094714032 adjusted timing: 103.605124 seconds for 10000000 >>>> requests of 1024 bytes. >>>> >>>> I checked the result in the FreeBSD mailing list link given below: >>>> >>>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-12/msg00294.html >>>> >>>> The jemalloc gives very good results. Is that the performance is good >>>> only on SMP? >>>> >>>> Or on single processor also it should perform well? >>>> >>>> But on single CPU i could see bad results. >>>> >>>> Could anyone help me out? >>> Your message is not very clear but here are some things that might help you: >>> >>> 1) -CURRENT has debugging enabled both in kernel and in malloc. You need >>> to disable both before benchmarking anything. >>> 2) According to the post you linked, jemalloc should be 1.1 times faster >>> for single-threaded processes than phkmalloc, on that particular >>> benchmark. This benefit will probably also be visible on single-CPU >>> machines. >>> 3) You don't need to run -CURRENT to get jemalloc - it is also prosent >>> in 7.0. >>> >>> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 17:17:52 2008 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 66E1A106564A for ; Thu, 20 Nov 2008 17:17:52 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 209738FC1A for ; Thu, 20 Nov 2008 17:17:51 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 997689CB33B for ; Thu, 20 Nov 2008 18:13:37 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9pm45wfDNIY for ; Thu, 20 Nov 2008 18:13:25 +0100 (CET) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C737D9CB500 for ; Thu, 20 Nov 2008 18:13:25 +0100 (CET) Received: (from rdivacky@localhost) by lev.vlakno.cz (8.14.2/8.14.2/Submit) id mAKHDPhP053381 for current@freebsd.org; Thu, 20 Nov 2008 18:13:25 +0100 (CET) (envelope-from rdivacky) Date: Thu, 20 Nov 2008 18:13:25 +0100 From: Roman Divacky To: current@freebsd.org Message-ID: <20081120171325.GA53026@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: atrtc0: Warnings about mappings of I/O and interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 17:17:52 -0000 hi I upgraded from roughly 10 days old -CURRENT to this: FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 23:23:49 CET 2008 root@witten:/usr/obj/usr/src/sys/MYKERNEL i386 and I am getting this at boot: atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. the booting itself works fine and I dont see any odd effects. can someone comment? thnx, roman From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 19:07:09 2008 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 9A87A1065670 for ; Thu, 20 Nov 2008 19:07:09 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 564F98FC14 for ; Thu, 20 Nov 2008 19:07:09 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by yw-out-2324.google.com with SMTP id 9so277284ywe.13 for ; Thu, 20 Nov 2008 11:07:09 -0800 (PST) Received: by 10.142.213.9 with SMTP id l9mr1284165wfg.206.1227208027857; Thu, 20 Nov 2008 11:07:07 -0800 (PST) Received: by 10.142.179.14 with HTTP; Thu, 20 Nov 2008 11:07:07 -0800 (PST) Message-ID: <367b2c980811201107x7fc859b8yeee0816a37eae470@mail.gmail.com> Date: Thu, 20 Nov 2008 20:07:07 +0100 From: "Olivier SMEDTS" To: "Pascal Hofstee" In-Reply-To: <367b2c980811201038s7d2ae03bnf36a6630f36bc188@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081120134836.2870a827@nebuchadnezzar> <367b2c980811201038s7d2ae03bnf36a6630f36bc188@mail.gmail.com> Cc: hackers@freebsd.org, Pegasus Mc Cleaft , current@freebsd.org Subject: Re: build problems with gptzfsboot (AMD64) 8.0-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: Thu, 20 Nov 2008 19:07:09 -0000 2008/11/20 Olivier SMEDTS : > 2008/11/20 Pascal Hofstee : >> On Thu, 20 Nov 2008 01:46:31 -0000 >> "Pegasus Mc Cleaft" wrote: >> >>> Hi everyone, >>> >>> I am having difficulties rebuilding the world after some patches >>> were made today. I was wondering if anyone else is experiencing the >>> same troubles? >>> >>> ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o >>> gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o >>> zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such >>> file or directory *** Error code 1 >>> >>> Stop in /usr/src/sys/boot/i386/gptzfsboot. >>> *** Error code 1 >> >> I am experiencing the exact same problem with a fresh svn checkout > > Just my "me too". > I did not experience the problem 24 hours ago (after ZFS version 13 > update and zfsboot import). That's it. Seems to work with the following patch : --- sys/boot/i386/gptzfsboot/Makefile.orig 2008-11-20 19:58:45.000000000 +0100 +++ sys/boot/i386/gptzfsboot/Makefile 2008-11-20 20:01:53.000000000 +0100 @@ -65,7 +65,7 @@ zfsboot.o: ${.CURDIR}/../../zfs/zfsimpl.c .if ${MACHINE_ARCH} == "amd64" -beforedepend gptzfsboot.o: machine +beforedepend gptzfsboot.bin: machine CLEANFILES+= machine machine: ln -sf ${.CURDIR}/../../../i386/include machine I've cc'ed current@ because HEAD is broken on amd64 for now. Cheers, Olivier > >> >> -- >> Pascal Hofstee >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > > > -- > 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." > -- 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 Thu Nov 20 19:08:05 2008 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 40C231065674 for ; Thu, 20 Nov 2008 19:08:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D4BE88FC19 for ; Thu, 20 Nov 2008 19:08:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAKJ7qXk067264; Thu, 20 Nov 2008 14:07:59 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bruce Simpson Date: Thu, 20 Nov 2008 13:57:39 -0500 User-Agent: KMail/1.9.7 References: <200811191503.02192.jhb@freebsd.org> <4924AC27.3090302@incunabulum.net> In-Reply-To: <4924AC27.3090302@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201357.39868.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 20 Nov 2008 14:07:59 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8653/Thu Nov 20 04:04:07 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 19:08:05 -0000 On Wednesday 19 November 2008 07:15:35 pm Bruce Simpson wrote: > John, > > Thanks for this. > > John Baldwin wrote: > > Please test! This is the last non-MPSAFE network driver at this point. This > > ... > > > > My only box using lpt(4) is running 7.1-PRERELEASE, this patch should > backport, yes? You will need to grab sys/dev/ppc/* and sys/dev/ppbus/* from HEAD since I've committed some style fixes and had changed the interrupt handling in HEAD (and have changed it again in this patch). > It is a right pain in the arse when something happens with my venerable > GCC Elite 600, e.g. a paper jam, and the entire box grinds to a halt > because lpt_intr() was called with Giant held. > > cheers > BMS > > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 19:10:32 2008 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 9CEC31065678 for ; Thu, 20 Nov 2008 19:10:32 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 6F20C8FC1A for ; Thu, 20 Nov 2008 19:10:32 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so642290wfg.7 for ; Thu, 20 Nov 2008 11:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=QLlTFutJTOqw6GYLn02ybZj5sXovEILCCJfVwmI/iVI=; b=R1MWt+Pjm9GrAJ//w90acZeCgquvUc8yCHLO1Oj96Hr4txO8dQREhhlzpmYY0ENkpb uWFsBGJn/S+oppbmgosjJpnQEcz5qhwAhJ4GmGKywc9w3uJqV99RCY1YX/3yFustNUZe LpUPrm2NUj2s1jfzb7ScCz0IuRAlqbBaeOqAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=fMHdqlgQ0U27DprTjcPAK1Xs+NuaHkKK3Lsb2wpvFjwkbUN432bSwWWXRlDa9KnYq9 l/UOVOz2udRCHlPhREEntEpQzbF0JyEL5yjyp/r7rH1X7tvlpMZedNuQNyAcCmKuiEkM 6+h4EYB7l0MO7O08bt9fU3xWW1d9HNEL9bLuM= Received: by 10.142.147.15 with SMTP id u15mr1267256wfd.226.1227206750496; Thu, 20 Nov 2008 10:45:50 -0800 (PST) Received: by 10.143.18.9 with HTTP; Thu, 20 Nov 2008 10:45:50 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 19:45:50 +0100 From: "Luigi Rizzo" Sender: rizzo.unipi@gmail.com To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 89d910aea269f473 Cc: Subject: src/sys/boot/common/load.c unused ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 19:10:32 -0000 while debugging the misbehaviour of pxeboot on certain machines, i noticed that the file src/sys/boot/common/load.c seems to be unused -- in fact, i could not find a reference to this file (or the filedup() function that it implements) anywhere. Is it supposed to be used somehow, or it is ok to remove it ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 19:41:15 2008 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 A420C1065670 for ; Thu, 20 Nov 2008 19:41:14 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 601D78FC0A for ; Thu, 20 Nov 2008 19:41:14 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by an-out-0708.google.com with SMTP id b6so285840ana.13 for ; Thu, 20 Nov 2008 11:41:13 -0800 (PST) Received: by 10.142.44.11 with SMTP id r11mr1293638wfr.249.1227210072376; Thu, 20 Nov 2008 11:41:12 -0800 (PST) Received: by 10.142.179.14 with HTTP; Thu, 20 Nov 2008 11:41:11 -0800 (PST) Message-ID: <367b2c980811201141j42977204ne6052000a0d095ab@mail.gmail.com> Date: Thu, 20 Nov 2008 20:41:11 +0100 From: "Olivier SMEDTS" To: "Pascal Hofstee" In-Reply-To: <367b2c980811201107x7fc859b8yeee0816a37eae470@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081120134836.2870a827@nebuchadnezzar> <367b2c980811201038s7d2ae03bnf36a6630f36bc188@mail.gmail.com> <367b2c980811201107x7fc859b8yeee0816a37eae470@mail.gmail.com> Cc: hackers@freebsd.org, Pegasus Mc Cleaft , current@freebsd.org Subject: Re: build problems with gptzfsboot (AMD64) 8.0-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: Thu, 20 Nov 2008 19:41:15 -0000 2008/11/20 Olivier SMEDTS : > 2008/11/20 Olivier SMEDTS : >> 2008/11/20 Pascal Hofstee : >>> On Thu, 20 Nov 2008 01:46:31 -0000 >>> "Pegasus Mc Cleaft" wrote: >>> >>>> Hi everyone, >>>> >>>> I am having difficulties rebuilding the world after some patches >>>> were made today. I was wondering if anyone else is experiencing the >>>> same troubles? >>>> >>>> ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o >>>> gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o >>>> zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such >>>> file or directory *** Error code 1 >>>> >>>> Stop in /usr/src/sys/boot/i386/gptzfsboot. >>>> *** Error code 1 >>> >>> I am experiencing the exact same problem with a fresh svn checkout >> >> Just my "me too". >> I did not experience the problem 24 hours ago (after ZFS version 13 >> update and zfsboot import). > > That's it. Seems to work with the following patch : > > --- sys/boot/i386/gptzfsboot/Makefile.orig 2008-11-20 > 19:58:45.000000000 +0100 > +++ sys/boot/i386/gptzfsboot/Makefile 2008-11-20 20:01:53.000000000 +0100 > @@ -65,7 +65,7 @@ > zfsboot.o: ${.CURDIR}/../../zfs/zfsimpl.c > > .if ${MACHINE_ARCH} == "amd64" > -beforedepend gptzfsboot.o: machine > +beforedepend gptzfsboot.bin: machine > CLEANFILES+= machine > machine: > ln -sf ${.CURDIR}/../../../i386/include machine Sorry for replying again to my own post :) The patch is crap, in fact it just breaks the already broken conditional. At least I can buildworld on amd64 now (I don't use the recently introduced gptzfsboot). Makefile experts ? > > I've cc'ed current@ because HEAD is broken on amd64 for now. > > Cheers, > > Olivier > > >> >>> >>> -- >>> Pascal Hofstee >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >> >> >> >> -- >> 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." >> > > > > -- > 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." > -- 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 Thu Nov 20 20:13:50 2008 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 A4EFC106564A for ; Thu, 20 Nov 2008 20:13:50 +0000 (UTC) (envelope-from zozo@q.gid0.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.freebsd.org (Postfix) with ESMTP id 3729A8FC16 for ; Thu, 20 Nov 2008 20:13:49 +0000 (UTC) (envelope-from zozo@q.gid0.org) Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 02F2217C811; Thu, 20 Nov 2008 21:13:48 +0100 (CET) Received: from q.gid0.org (s.gid0.org [88.163.116.140]) by smtp3-g19.free.fr (Postfix) with ESMTP id 84FC617C8E1; Thu, 20 Nov 2008 21:13:41 +0100 (CET) Received: (from zozo@localhost) by q.gid0.org (8.14.3/8.14.3/Submit) id mAKKDbFG077333; Thu, 20 Nov 2008 21:13:37 +0100 (CET) (envelope-from zozo) Date: Thu, 20 Nov 2008 21:13:37 +0100 From: Olivier SMEDTS To: Pegasus Mc Cleaft Message-ID: <20081120201336.GA66837@q.gid0.org> References: <367b2c980811201038s7d2ae03bnf36a6630f36bc188@mail.gmail.com> <367b2c980811201057y4e44e0ehb227d37702d98c43@mail.gmail.com> <200811201949.06286.ken@mthelicon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <200811201949.06286.ken@mthelicon.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: hackers@freebsd.org, current@freebsd.org, Pascal Hofstee Subject: Re: build problems with gptzfsboot (AMD64) 8.0-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: Thu, 20 Nov 2008 20:13:50 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 20, 2008 at 07:49:06PM +0000, Pegasus Mc Cleaft wrote: > On Thursday 20 November 2008 18:57:53 Olivier SMEDTS wrote: > > What is your MACHINE_ARCH ? > > Mine is amd64, I think there's a problem with the conditional in > > sys/boot/i386/gptzfsboot/Makefile. > > ld doesn't need gptzfsboot.o on i386. Now I think I've got it : All the '.if ${MACHINE_ARCH} == "amd64"' which replace the amd64 machine link with an i386 one are useless on 7.0 and -CURRENT since rev. 1.17 of sys/boot/efi/libefi/Makefile. This file already takes care of replacing MACHINE_ARCH. And I don't think zfs*boot will be in 6-STABLE. You can apply the following patch in sys/boot/i386. I'll submit a PR if it's not committed before. Cheers, Olivier > > > > Olivier > > > > 2008/11/20 Olivier SMEDTS : > > > 2008/11/20 Pascal Hofstee : > > >> On Thu, 20 Nov 2008 01:46:31 -0000 > > >> > > >> "Pegasus Mc Cleaft" wrote: > > >>> Hi everyone, > > >>> > > >>> I am having difficulties rebuilding the world after some patches > > >>> were made today. I was wondering if anyone else is experiencing the > > >>> same troubles? > > > > Hi Oliver, > My machine is an Core2 Quad running under AMD64. (CPUTYPE?=core2) > > Thanks for replying. It puts my mind to ease because I was thinking it was a > problem I created (I recently moved the /usr/src directory into a seperate zfs > filing system) > > Peg -- 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." --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=patch --- boot2/Makefile.orig 2008-11-20 20:56:31.000000000 +0100 +++ boot2/Makefile 2008-11-20 20:56:42.000000000 +0100 @@ -94,11 +94,4 @@ ORG1=`printf "%d" ${ORG1}` \ REL1=`printf "%d" ${REL1}` > ${.TARGET} -.if ${MACHINE_ARCH} == "amd64" -beforedepend boot2.s: machine -CLEANFILES+= machine -machine: - ln -sf ${.CURDIR}/../../../i386/include machine -.endif - .include --- gptboot/Makefile.orig 2008-11-20 20:50:34.000000000 +0100 +++ gptboot/Makefile 2008-11-20 20:50:40.000000000 +0100 @@ -67,11 +67,4 @@ gptboot.o: ${.CURDIR}/../../common/ufsread.c -.if ${MACHINE_ARCH} == "amd64" -beforedepend gptboot.o: machine -CLEANFILES+= machine -machine: - ln -sf ${.CURDIR}/../../../i386/include machine -.endif - .include --- libfirewire/Makefile.orig 2008-11-20 20:56:07.000000000 +0100 +++ libfirewire/Makefile 2008-11-20 20:56:18.000000000 +0100 @@ -16,15 +16,4 @@ CFLAGS+= -Wformat -Wall -.if ${MACHINE_ARCH} == "amd64" -CLEANFILES+= machine -machine: - ln -sf ${.CURDIR}/../../../i386/include machine -.endif - .include - -.if ${MACHINE_ARCH} == "amd64" -beforedepend ${OBJS}: machine -.endif - --- libi386/Makefile.orig 2008-11-20 20:55:38.000000000 +0100 +++ libi386/Makefile 2008-11-20 20:55:55.000000000 +0100 @@ -45,14 +45,4 @@ # the location of libstand CFLAGS+= -I${.CURDIR}/../../../../lib/libstand/ -.if ${MACHINE_ARCH} == "amd64" -CLEANFILES+= machine -machine: - ln -sf ${.CURDIR}/../../../i386/include machine -.endif - .include - -.if ${MACHINE_ARCH} == "amd64" -beforedepend ${OBJS}: machine -.endif --- loader/Makefile.orig 2008-11-20 20:54:43.000000000 +0100 +++ loader/Makefile 2008-11-20 20:54:58.000000000 +0100 @@ -110,10 +110,3 @@ LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} -lstand .include - -.if ${MACHINE_ARCH} == "amd64" -beforedepend ${OBJS}: machine -CLEANFILES+= machine -machine: - ln -sf ${.CURDIR}/../../../i386/include machine -.endif --- zfsboot/Makefile.orig 2008-11-20 20:54:18.000000000 +0100 +++ zfsboot/Makefile 2008-11-20 20:54:27.000000000 +0100 @@ -98,11 +98,4 @@ ORG1=`printf "%d" ${ORG1}` \ REL1=`printf "%d" ${REL1}` > ${.TARGET} -.if ${MACHINE_ARCH} == "amd64" -beforedepend zfsboot.s: machine -CLEANFILES+= machine -machine: - ln -sf ${.CURDIR}/../../../i386/include machine -.endif - .include --- gptzfsboot/Makefile.orig 2008-11-20 19:58:45.000000000 +0100 +++ gptzfsboot/Makefile 2008-11-20 20:50:25.000000000 +0100 @@ -64,11 +64,4 @@ zfsboot.o: ${.CURDIR}/../../zfs/zfsimpl.c -.if ${MACHINE_ARCH} == "amd64" -beforedepend gptzfsboot.o: machine -CLEANFILES+= machine -machine: - ln -sf ${.CURDIR}/../../../i386/include machine -.endif - .include --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 21:24:47 2008 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 AB83E1065674; Thu, 20 Nov 2008 21:24:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7FD318FC23; Thu, 20 Nov 2008 21:24:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAKLOixa060230; Thu, 20 Nov 2008 16:24:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAKLOisf074912; Thu, 20 Nov 2008 16:24:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D17FE73039; Thu, 20 Nov 2008 16:24:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081120212444.D17FE73039@freebsd-current.sentex.ca> Date: Thu, 20 Nov 2008 16:24:44 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 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, 20 Nov 2008 21:24:47 -0000 TB --- 2008-11-20 19:47:45 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-20 19:47:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-20 19:47:45 - cleaning the object tree TB --- 2008-11-20 19:48:18 - cvsupping the source tree TB --- 2008-11-20 19:48:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-20 19:48:25 - building world TB --- 2008-11-20 19:48:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-20 19:48:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-20 19:48:25 - TARGET=sparc64 TB --- 2008-11-20 19:48:25 - TARGET_ARCH=sparc64 TB --- 2008-11-20 19:48:25 - TZ=UTC TB --- 2008-11-20 19:48:25 - __MAKE_CONF=/dev/null TB --- 2008-11-20 19:48:25 - cd /src TB --- 2008-11-20 19:48:25 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 20 19:48:27 UTC 2008 >>> 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 20 21:08:28 UTC 2008 TB --- 2008-11-20 21:08:28 - generating LINT kernel config TB --- 2008-11-20 21:08:28 - cd /src/sys/sparc64/conf TB --- 2008-11-20 21:08:28 - /usr/bin/make -B LINT TB --- 2008-11-20 21:08:28 - building LINT kernel TB --- 2008-11-20 21:08:28 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-20 21:08:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-20 21:08:28 - TARGET=sparc64 TB --- 2008-11-20 21:08:28 - TARGET_ARCH=sparc64 TB --- 2008-11-20 21:08:28 - TZ=UTC TB --- 2008-11-20 21:08:28 - __MAKE_CONF=/dev/null TB --- 2008-11-20 21:08:28 - cd /src TB --- 2008-11-20 21:08:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 20 21:08:28 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-20 21:24:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-20 21:24:44 - ERROR: failed to build lint kernel TB --- 2008-11-20 21:24:44 - 4576.20 user 414.31 system 5818.68 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 21:28:37 2008 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 1E6441065672; Thu, 20 Nov 2008 21:28:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B3B028FC1F; Thu, 20 Nov 2008 21:28:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAKLSUYH068585; Thu, 20 Nov 2008 16:28:30 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: current@freebsd.org Date: Thu, 20 Nov 2008 16:27: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: <200811201627.58289.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 20 Nov 2008 16:28:30 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8654/Thu Nov 20 14:51:00 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: scottl@freebsd.org Subject: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 21:28:37 -0000 So this patch is fairly minimal since udf(4) is currently read-only. The changes include: * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it only in udf_root(). This matches the behavior of other operating systems and correctly tags the root vnode with VV_ROOT in the unlikely case that we create the vnode during a call to ufs_vget() that does not come from ufs_root(). * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock is used while creating the new vnode (same as UFS). * Allow lock recursion (XXX: not really sure this is needed actually). * Allow shared vnode locks on non-fifos. * Honor the requested locking flags (shared vs exclusive) instead of always using exclusive vnode locks during a lookup operation. * Handle "." lookups the same way other filesystems do by just bumping the reference on 'dvp' rather than calling udf_vget(). http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch I have only verified that this compiles and would appreciate it if some folks could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabled. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 21:52:01 2008 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 000611065679 for ; Thu, 20 Nov 2008 21:52:00 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id CF01A8FC1E for ; Thu, 20 Nov 2008 21:52:00 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by wf-out-1314.google.com with SMTP id 24so701135wfg.7 for ; Thu, 20 Nov 2008 13:52:00 -0800 (PST) Received: by 10.142.48.14 with SMTP id v14mr1348855wfv.284.1227217919611; Thu, 20 Nov 2008 13:51:59 -0800 (PST) Received: by 10.142.179.14 with HTTP; Thu, 20 Nov 2008 13:51:59 -0800 (PST) Message-ID: <367b2c980811201351q3e920fdex5b377ceb8dc0fad3@mail.gmail.com> Date: Thu, 20 Nov 2008 22:51:59 +0100 From: "Olivier SMEDTS" To: "Pegasus Mc Cleaft" In-Reply-To: <20081120201336.GA66837@q.gid0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <367b2c980811201038s7d2ae03bnf36a6630f36bc188@mail.gmail.com> <367b2c980811201057y4e44e0ehb227d37702d98c43@mail.gmail.com> <200811201949.06286.ken@mthelicon.com> <20081120201336.GA66837@q.gid0.org> Cc: hackers@freebsd.org, current@freebsd.org, Pascal Hofstee Subject: Re: build problems with gptzfsboot (AMD64) 8.0-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: Thu, 20 Nov 2008 21:52:01 -0000 2008/11/20 Olivier SMEDTS : > On Thu, Nov 20, 2008 at 07:49:06PM +0000, Pegasus Mc Cleaft wrote: >> On Thursday 20 November 2008 18:57:53 Olivier SMEDTS wrote: >> > What is your MACHINE_ARCH ? >> > Mine is amd64, I think there's a problem with the conditional in >> > sys/boot/i386/gptzfsboot/Makefile. >> > ld doesn't need gptzfsboot.o on i386. > > Now I think I've got it : > > All the '.if ${MACHINE_ARCH} == "amd64"' which replace the amd64 machine > link with an i386 one are useless on 7.0 and -CURRENT since rev. 1.17 of > sys/boot/efi/libefi/Makefile. This file already takes care of replacing > MACHINE_ARCH. And I don't think zfs*boot will be in 6-STABLE. Wow, still not good... I was too enthusiastic while waiting for a fresh buildworld to finish. It worked without cleaning though (buildworld without patch then patch then make clean in sys/boot/i386 then finish buildworld without cleaning). Must have missed something. I give up for today, I think I really must sleep :) > > You can apply the following patch in sys/boot/i386. I'll submit a PR if > it's not committed before. > > Cheers, > Olivier > > >> > >> > Olivier >> > >> > 2008/11/20 Olivier SMEDTS : >> > > 2008/11/20 Pascal Hofstee : >> > >> On Thu, 20 Nov 2008 01:46:31 -0000 >> > >> >> > >> "Pegasus Mc Cleaft" wrote: >> > >>> Hi everyone, >> > >>> >> > >>> I am having difficulties rebuilding the world after some patches >> > >>> were made today. I was wondering if anyone else is experiencing the >> > >>> same troubles? >> >> >> >> Hi Oliver, >> My machine is an Core2 Quad running under AMD64. (CPUTYPE?=core2) >> >> Thanks for replying. It puts my mind to ease because I was thinking it was a >> problem I created (I recently moved the /usr/src directory into a seperate zfs >> filing system) >> >> Peg -- 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 Thu Nov 20 22:01:31 2008 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 C76441065675 for ; Thu, 20 Nov 2008 22:01:31 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7E74B8FC18 for ; Thu, 20 Nov 2008 22:01:31 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so314836ana.13 for ; Thu, 20 Nov 2008 14:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=OhSLYSR+ubfbyhgVfCH1kqO/f3SlRo7xdSQ+Ji0jmtQ=; b=cVxcq7nD97TAS5ZHx/xKau2CogXAQfx51laNo9pejBm6HXKYN6rJwsQ8osQaczCeEM ZLZ1FPHKkTm/9CMfb2glfPpdFGphFJDDWiWPJrcFPOHNqCiGoQkVkEvEZl7tT70n/bPr P0alPJWzN/a3KwIUBaLrRffnE+bFvSfk2x9xU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=CytpWOvBljirZWhYTWOB5I8iUf7BNds9exoHvyV1lnQhCWTiysW4z6VbXR7gDRqFt1 TCHD+6LQJ7OtUCepfibso49EQM5zcQTcpEPGvXekeHpcVQ8omsAjR7528nOPmWX22LcT HuDKgr6yk7DWgVx0NZwGy1P+IFfJD+N+ty9qk= Received: by 10.231.20.3 with SMTP id d3mr25397ibb.18.1227216657130; Thu, 20 Nov 2008 13:30:57 -0800 (PST) Received: by 10.231.15.70 with HTTP; Thu, 20 Nov 2008 13:30:57 -0800 (PST) Message-ID: <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> Date: Thu, 20 Nov 2008 22:30:57 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200811191510.53793.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 22:01:31 -0000 On 11/19/08, John Baldwin wrote: > This is a relatively simple patch to mark cd9660 MPSAFE and enable shared > lookups. The changes to cd9660_lookup() mirror similar changes to > ufs_lookup() to use static variables for local data rather than abusing > i-node members of the parent directory. I've done some light testing of > this, but not super-strenuous. This patch also includes simple locking for > the iconv support in the kernel. That locking uses an sx lock to serialize > open and close of translator tables and the associated refcount. Actual > conversions do not need any locks, however as the mount holds a reference on > the table. > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch > With this patch I'm unable to kldunload libiconv.ko once it is loaded. And trying to kldunload libiconv.ko will make any next kldload/kldstat/kldunload to fail waiting forever(livelock). Regression were not encountered while only cd9660.ko were kldloaded. BTW: Machine crashed during clean shutdown (with old kernel without this patch) after atapicd where kldloaded and after that used some time and tham kldunloaded. From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:02:31 2008 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 3BBAA1065672 for ; Thu, 20 Nov 2008 22:02:31 +0000 (UTC) (envelope-from asmrookie@gmail.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 BC7958FC17 for ; Thu, 20 Nov 2008 22:02:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by gv-out-0910.google.com with SMTP id n8so205388gve.39 for ; Thu, 20 Nov 2008 14:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=jUgQPCMYDOC++KEgV++hjtz2sAjlbQ6FQgaCdqO3VTA=; b=wAtAIsG2hS3ASN2mZadrWE7WxhV2gtl7TVngT5fiySTvSUNKLgd8lrciiY8PMxEX03 M58xUSVGL/e1dYEFKYWHCnyNFWstqoASrYchAwWW9GQLLcRzJ7IfhiEid7bBRzPFmMMn yKVuB1+IVg8puj5K44f5ZYaMroxmJIZHAUog8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=fqltkbBa96vzq3GO6a4IKKw+FTFFYG0xsqKUafpfvfZojOj85SZQrpZvocG1/COCWT 4SqUHDVg7Yt0Bd78SOaerCtD7vqfxIBxn3z7R9SwfexmgeklhvBCwGwFcKHZ7oyuw8/b vFqftsZ5bOnRZ0gokp+thBvNoC3JZW/tXcKMo= Received: by 10.103.192.10 with SMTP id u10mr951049mup.101.1227218549175; Thu, 20 Nov 2008 14:02:29 -0800 (PST) Received: by 10.103.239.14 with HTTP; Thu, 20 Nov 2008 14:02:29 -0800 (PST) Message-ID: <3bbf2fe10811201402x4eb6fa70i398bfb1402792fef@mail.gmail.com> Date: Thu, 20 Nov 2008 23:02:29 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200811201627.58289.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811201627.58289.jhb@freebsd.org> X-Google-Sender-Auth: 360e1bfc0ecda57b Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 22:02:31 -0000 2008/11/20, John Baldwin : > So this patch is fairly minimal since udf(4) is currently read-only. The > changes include: > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it only > in udf_root(). This matches the behavior of other operating systems and > correctly tags the root vnode with VV_ROOT in the unlikely case that we > create the vnode during a call to ufs_vget() that does not come from > ufs_root(). > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock is > used while creating the new vnode (same as UFS). > * Allow lock recursion (XXX: not really sure this is needed actually). > * Allow shared vnode locks on non-fifos. > * Honor the requested locking flags (shared vs exclusive) instead of always > using exclusive vnode locks during a lookup operation. > * Handle "." lookups the same way other filesystems do by just bumping the > reference on 'dvp' rather than calling udf_vget(). > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch @@ -589,6 +582,22 @@ if (error || *vpp != NULL) return (error); + /* + * We must promote to an exclusive lock for vnode creation. This + * can happen if lookup is passed LOCKSHARED. + */ + if ((flags & LK_TYPE_MASK) == LK_SHARED) { + flags &= ~LK_TYPE_MASK; + flags |= LK_EXCLUSIVE; + } + On -CURRENT, operations are bitwise (differently from 7.x and such). What you want to do is just: flag = (flag & ~LK_SHARED) | LK_EXCLUSIVE; The other parts look good (except that IIRC stlye wants all multi-line comments to be preceeded by a white, empty line). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:09:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E4C1065673 for ; Thu, 20 Nov 2008 22:09:52 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 7E92D8FC14 for ; Thu, 20 Nov 2008 22:09:51 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so696246fkk.11 for ; Thu, 20 Nov 2008 14:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=mxvA3WBCavoB8yinDGSj+PnRalNE+JmNIiyFwmTfFaQ=; b=xR433CAl5DggkP31Q7styp+UYgRisX8f+LgYJFJAKnjA8MXmLmCqX1Yj3W9m3v8ewh eHRF840FqyXUSk6IYSYwAXyZ6nqa2kDKmPkC56cRYYsjd/qo7iDmLR+osIg81eliUf5A FVfj60Mfy3OchjYhiIf9JaQn0cF6Jkn7sH/Ps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=GSIDfunTixzDAsiEemCb4FAWW3hbcU/EGgd53dXLwphj9pyb9B6+A6cbHjuyzbpvpi e6YFjdi0lVmeoru8bPoGb1ksn3e7RYf/QeW7nxJNMrS169Kgy6V7BQzY1g0HeH3AZeUg z4di9o0fmbRQSHkvDqGkd/Ahfpsy8gSOZNuyY= Received: by 10.181.210.14 with SMTP id m14mr872319bkq.163.1227218989293; Thu, 20 Nov 2008 14:09:49 -0800 (PST) Received: from localhost.invalid ([77.241.34.28]) by mx.google.com with ESMTPS id c28sm1953892fka.18.2008.11.20.14.08.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Nov 2008 14:09:48 -0800 (PST) From: Ole Vole To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Date: Thu, 20 Nov 2008 22:08:41 +0300 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811202208.41220.subbsd@gmail.com> Cc: Subject: Asus eeepc, Freebsd-head, problem with ath/wifi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: subbsd@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, 20 Nov 2008 22:09:52 -0000 Hello maillist! I trying setup FreeBSD according Wiki notes http://wiki.freebsd.org/AsusEee and get system without ath Wi-Fi devices (Fn+f2/Bios settings for Wifi: Enabled) buildin/install kernel/world from 20081120 snapshot FreeBSD-CURRENT with/or patching from madwifi.org-project ( http://snapshots.madwifi- project.org/madwifi-hal-0.10.5.6/madwifi-hal-0.10.5.6-r3875-20081105.tar.gz ) (old link http://snapshots.madwifi-project.org/special/madwifi-ng- r2756+ar5007.tar.gz is wrong) with extracting hal/ to /usr/src/sys/contrib/dev/ath/ and recompile the kernel Also, trying to test http://people.freebsd.org/~sam/ath_hal-20081028.tgz As result from attemps is string in dmesg: ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) but ifconfig show only LAN ale0 Ethernet interface. On the list pciconf i see "Ralink Technology, Corp" devices but iy without drivers. What is wrong here? Thanks! Additional info: pciconf -vl output: -- hostb0@pci0:0:0:0: class=0x060000 card=0x830f1043 chip=0x27ac8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x830f1043 chip=0x27ae8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x830f1043 chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GU Express Integrated Graphics Controller' class = display hdac0@pci0:0:27:0: class=0x040300 card=0x831a1043 chip=0x27d88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class = multimedia subclass = HDA pcib1@pci0:0:28:0: class=0x060400 card=0x830f1043 chip=0x27d08086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:1: class=0x060400 card=0x830f1043 chip=0x27d28086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:2: class=0x060400 card=0x830f1043 chip=0x27d48086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:3: class=0x060400 card=0x830f1043 chip=0x27d68086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x830f1043 chip=0x27c88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x830f1043 chip=0x27c98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x830f1043 chip=0x27ca8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x830f1043 chip=0x27cb8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x830f1043 chip=0x27cc8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib5@pci0:0:30:0: class=0x060401 card=0x830f1043 chip=0x24488086 rev=0xe2 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x830f1043 chip=0x27b98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM (ICH7-M) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:2: class=0x010180 card=0x830f1043 chip=0x27c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller' class = mass storage subclass = ATA ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x830f1043 chip=0x27da8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus ale0@pci0:4:0:0: class=0x020000 card=0x83241043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' class = network subclass = ethernet none0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' class = network --- kernel config: ---- cpu I686_CPU ident eeepc options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options STOP_NMI # Stop CPUS using NMI instead of IPI options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC device cpufreq device acpi device eisa device pci device ata device atadisk # ATA disk drives options ATA_STATIC_ID # Static device numbering device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device sc device agp # support several AGP chipsets device pmtimer device miibus # MII bus support device ale # Atheros AR8121/AR8113/AR8114 Ethernet device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ral # Ralink Technology RT2500 wireless NICs. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device bpf # Berkeley packet filter device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ucom # Generic com ttys device u3g # USB-based 3G modems (Option, Huawei, Sierra) device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons device sound device snd_hda options LIBICONV options LIBMCHAIN options CD9660_ICONV options MSDOSFS_ICONV options NTFS options NTFS_ICONV options UDF options UDF_ICONV options GEOM_UZIP # read only compressed disks options TMPFS device acpi_asus device acpi_video device ralfw device wlan device wlan_amrr device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device ichsmb ---- kernel & hw: %sysctl -a |egrep -E "^kern.os[a-z]++" -- kern.ostype: FreeBSD kern.osrelease: 8.0-CURRENT kern.osrevision: 199506 kern.osreldate: 800053 -- %sysctl -a |egrep -E "^hw" |head -n5 hw.machine: i386 hw.model: Intel(R) Atom(TM) CPU N270 @ 1.60GHz hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 1056018432 /boot/loader.conf: -- if_ath_load="YES" /* also try with static compile-in-kernel */ hw.psm.synaptics_support=1 kern.hz=100 hw.pci.do_power_nodriver=1 vfs.root.mountfrom="ufs:ad2s1a" -- /etc/src.conf with following "make buildworld; make kernel; make installworld" and after reboot: "cd /usr/src; yes |make delete-old ; yes | make-delete-old- libs" -- WITHOUT_ACCT=yes WITHOUT_AMD=yes WITHOUT_APM=yes WITHOUT_ASSERT_DEBUG=yes WITHOUT_AT=yes WITHOUT_ATM=yes WITHOUT_AUDIT=yes WITHOUT_AUTHPF=yes WITHOUT_BIND_DNSSEC=yes WITHOUT_BSNMP=yes WITHOUT_CDDL=yes WITHOUT_ZFS=yes WITHOUT_CTM=yes WITHOUT_EXAMPLES=yes WITHOUT_FLOPPY=yes WITHOUT_FREEBSD_UPDATE=yes WITHOUT_GAMES=yes WITHOUT_HTML=yes WITHOUT_INET6=yes WITHOUT_INET6_SUPPORT=yes WITHOUT_INFO=yes WITHOUT_IPFILTER=yes WITHOUT_IPFW=yes WITHOUT_IPX=yes WITHOUT_IPX_SUPPORT=yes WITHOUT_NCP=yes WITHOUT_JAIL=yes WITHOUT_LEGACY_CONSOLE=yes WITHOUT_LPR=yes WITHOUT_MAIL=yes WITHOUT_MAILWRAPPER=yes WITHOUT_SENDMAIL=yes WITHOUT_NCP=yes WITHOUT_NIS=yes WITHOUT_NLS=yes WITHOUT_NLS_CATALOGS=yes WITHOUT_NTP=yes WITHOUT_PF=yes WITHOUT_AUTHPF=yes WITHOUT_PROFILE=yes WITHOUT_QUOTAS=yes WITHOUT_RCMDS=yes WITHOUT_ROUTED=yes WITHOUT_SHAREDOCS=yes WITHOUT_SLIP=yes WITHOUT_SSP=yes WITHOUT_ZFS=yes -- From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:14:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04D381065674 for ; Thu, 20 Nov 2008 22:14:19 +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 B11828FC14 for ; Thu, 20 Nov 2008 22:14:18 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 317F62BC3C; Fri, 21 Nov 2008 11:14:17 +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 KGg3MD4a5ekb; Fri, 21 Nov 2008 11:14:12 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 21 Nov 2008 11:14:12 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 142AC11445; Fri, 21 Nov 2008 11:14:12 +1300 (NZDT) Date: Thu, 20 Nov 2008 14:14:11 -0800 From: Andrew Thompson To: Ole Vole Message-ID: <20081120221411.GA70932@citylink.fud.org.nz> References: <200811202208.41220.subbsd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200811202208.41220.subbsd@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Asus eeepc, Freebsd-head, problem with ath/wifi 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: Thu, 20 Nov 2008 22:14:19 -0000 On Thu, Nov 20, 2008 at 10:08:41PM +0300, Ole Vole wrote: > Hello maillist! > > I trying setup FreeBSD according Wiki notes http://wiki.freebsd.org/AsusEee > and get system without ath Wi-Fi devices (Fn+f2/Bios settings for Wifi: > Enabled) > > buildin/install kernel/world from 20081120 snapshot FreeBSD-CURRENT with/or > patching from madwifi.org-project ( http://snapshots.madwifi- > project.org/madwifi-hal-0.10.5.6/madwifi-hal-0.10.5.6-r3875-20081105.tar.gz ) > (old link http://snapshots.madwifi-project.org/special/madwifi-ng- > r2756+ar5007.tar.gz is wrong) with extracting hal/ to > /usr/src/sys/contrib/dev/ath/ and recompile the kernel > > > Also, trying to test http://people.freebsd.org/~sam/ath_hal-20081028.tgz > > As result from attemps is string in dmesg: > ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, > RF5413, RF2133, RF2425, RF2417) > > but ifconfig show only LAN ale0 Ethernet interface. > > On the list pciconf i see "Ralink Technology, Corp" devices but iy without > drivers. > > What is wrong here? Thanks! Thats not an Atheros card and the Ralink chipset isnt supported yet. I have used ndis with this model and it works fine. Andrew From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:32:00 2008 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 64BA1106564A; Thu, 20 Nov 2008 22:32:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D75588FC14; Thu, 20 Nov 2008 22:31:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAKMVqP8069152; Thu, 20 Nov 2008 17:31:53 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Thu, 20 Nov 2008 17:26:43 -0500 User-Agent: KMail/1.9.7 References: <200811201627.58289.jhb@freebsd.org> <3bbf2fe10811201402x4eb6fa70i398bfb1402792fef@mail.gmail.com> In-Reply-To: <3bbf2fe10811201402x4eb6fa70i398bfb1402792fef@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201726.43467.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 20 Nov 2008 17:31:53 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8654/Thu Nov 20 14:51:00 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 22:32:00 -0000 On Thursday 20 November 2008 05:02:29 pm Attilio Rao wrote: > 2008/11/20, John Baldwin : > > So this patch is fairly minimal since udf(4) is currently read-only. The > > changes include: > > > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it only > > in udf_root(). This matches the behavior of other operating systems and > > correctly tags the root vnode with VV_ROOT in the unlikely case that we > > create the vnode during a call to ufs_vget() that does not come from > > ufs_root(). > > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock is > > used while creating the new vnode (same as UFS). > > * Allow lock recursion (XXX: not really sure this is needed actually). > > * Allow shared vnode locks on non-fifos. > > * Honor the requested locking flags (shared vs exclusive) instead of always > > using exclusive vnode locks during a lookup operation. > > * Handle "." lookups the same way other filesystems do by just bumping the > > reference on 'dvp' rather than calling udf_vget(). > > > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch > > @@ -589,6 +582,22 @@ > if (error || *vpp != NULL) > return (error); > > + /* > + * We must promote to an exclusive lock for vnode creation. This > + * can happen if lookup is passed LOCKSHARED. > + */ > + if ((flags & LK_TYPE_MASK) == LK_SHARED) { > + flags &= ~LK_TYPE_MASK; > + flags |= LK_EXCLUSIVE; > + } > + > > On -CURRENT, operations are bitwise (differently from 7.x and such). > What you want to do is just: > flag = (flag & ~LK_SHARED) | LK_EXCLUSIVE; I just copied and pasted from UFS in HEAD. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:32:05 2008 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 D3151106564A for ; Thu, 20 Nov 2008 22:32:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 547C08FC19 for ; Thu, 20 Nov 2008 22:32:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAKMVqP9069152; Thu, 20 Nov 2008 17:31:59 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Paul B. Mahol" Date: Thu, 20 Nov 2008 17:31:31 -0500 User-Agent: KMail/1.9.7 References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> In-Reply-To: <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201731.31408.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 20 Nov 2008 17:31:59 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8654/Thu Nov 20 14:51:00 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 22:32:05 -0000 On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: > On 11/19/08, John Baldwin wrote: > > This is a relatively simple patch to mark cd9660 MPSAFE and enable shared > > lookups. The changes to cd9660_lookup() mirror similar changes to > > ufs_lookup() to use static variables for local data rather than abusing > > i-node members of the parent directory. I've done some light testing of > > this, but not super-strenuous. This patch also includes simple locking for > > the iconv support in the kernel. That locking uses an sx lock to serialize > > open and close of translator tables and the associated refcount. Actual > > conversions do not need any locks, however as the mount holds a reference on > > the table. > > > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch > > > > With this patch I'm unable to kldunload libiconv.ko once it is loaded. > And trying to kldunload libiconv.ko will make any next kldload/kldstat/kldunload > to fail waiting forever(livelock). Hmm, I had thought I had done that, but I'll try it again. Maybe a lock leak. > Regression were not encountered while only cd9660.ko were kldloaded. > > BTW: > > Machine crashed during clean shutdown (with old kernel without this patch) > after atapicd where kldloaded and after that used some time and tham > kldunloaded. > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:33:22 2008 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 EA7E61065673 for ; Thu, 20 Nov 2008 22:33:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 608868FC1A for ; Thu, 20 Nov 2008 22:33:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so356173nfh.33 for ; Thu, 20 Nov 2008 14:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=sn7DTIiKnv1his59DJf6/8w+4jzH3/q1jJRFyhMOLeE=; b=pbPLLcK7q5SOKHOOiidMz7O1Ft4/sMhsucoBaA7xTLJKPSf1VequnCLelHXji7HaNl y7o8M1J4NYPd5DJxrZiQoYuIAYd7kHoB6WTybu4nrdwsaBiEGoXyplh+lz7st9qQnbK4 NFqI9qpkih6yrkC9aqboPsAdOjrmJXBZqdgo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Acs2KqEmVfthcU40gor7/kUQChHKIqC+/pbf8W6oZwhmJmAa2L/Z/nGvE6tZdCo2Rv Xb3Vgza/Vd6IRrXDmifHiH/YBTc7uAjsCM+bHLKj1Q+qHK2PVQ49YZ/TMRO1qrokkT/m 926tReb/NLMXQcEYxwdniC7W85cge32ZZ1w0M= Received: by 10.103.226.20 with SMTP id d20mr971672mur.8.1227220400666; Thu, 20 Nov 2008 14:33:20 -0800 (PST) Received: by 10.103.239.14 with HTTP; Thu, 20 Nov 2008 14:33:20 -0800 (PST) Message-ID: <3bbf2fe10811201433u16797213vf762099c48057cd@mail.gmail.com> Date: Thu, 20 Nov 2008 23:33:20 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200811201726.43467.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811201627.58289.jhb@freebsd.org> <3bbf2fe10811201402x4eb6fa70i398bfb1402792fef@mail.gmail.com> <200811201726.43467.jhb@freebsd.org> X-Google-Sender-Auth: 017d7738cf28d2cf Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 22:33:23 -0000 2008/11/20, John Baldwin : > On Thursday 20 November 2008 05:02:29 pm Attilio Rao wrote: > > 2008/11/20, John Baldwin : > > > So this patch is fairly minimal since udf(4) is currently read-only. The > > > changes include: > > > > > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it > only > > > in udf_root(). This matches the behavior of other operating systems and > > > correctly tags the root vnode with VV_ROOT in the unlikely case that we > > > create the vnode during a call to ufs_vget() that does not come from > > > ufs_root(). > > > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock > is > > > used while creating the new vnode (same as UFS). > > > * Allow lock recursion (XXX: not really sure this is needed actually). > > > * Allow shared vnode locks on non-fifos. > > > * Honor the requested locking flags (shared vs exclusive) instead of > always > > > using exclusive vnode locks during a lookup operation. > > > * Handle "." lookups the same way other filesystems do by just bumping > the > > > reference on 'dvp' rather than calling udf_vget(). > > > > > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch > > > > @@ -589,6 +582,22 @@ > > if (error || *vpp != NULL) > > return (error); > > > > + /* > > + * We must promote to an exclusive lock for vnode creation. This > > + * can happen if lookup is passed LOCKSHARED. > > + */ > > + if ((flags & LK_TYPE_MASK) == LK_SHARED) { > > + flags &= ~LK_TYPE_MASK; > > + flags |= LK_EXCLUSIVE; > > + } > > + > > > > On -CURRENT, operations are bitwise (differently from 7.x and such). > > What you want to do is just: > > flag = (flag & ~LK_SHARED) | LK_EXCLUSIVE; > > > I just copied and pasted from UFS in HEAD. Yeah, we could fix that also. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:48:20 2008 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 E07401065673; Thu, 20 Nov 2008 22:48:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 599F98FC0C; Thu, 20 Nov 2008 22:48:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAKMmDYL069308; Thu, 20 Nov 2008 17:48:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Thu, 20 Nov 2008 17:43:56 -0500 User-Agent: KMail/1.9.7 References: <200811201627.58289.jhb@freebsd.org> <200811201726.43467.jhb@freebsd.org> <3bbf2fe10811201433u16797213vf762099c48057cd@mail.gmail.com> In-Reply-To: <3bbf2fe10811201433u16797213vf762099c48057cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201743.56963.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 20 Nov 2008 17:48:14 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8654/Thu Nov 20 14:51:00 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 22:48:21 -0000 On Thursday 20 November 2008 05:33:20 pm Attilio Rao wrote: > 2008/11/20, John Baldwin : > > On Thursday 20 November 2008 05:02:29 pm Attilio Rao wrote: > > > 2008/11/20, John Baldwin : > > > > So this patch is fairly minimal since udf(4) is currently read-only. The > > > > changes include: > > > > > > > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it > > only > > > > in udf_root(). This matches the behavior of other operating systems and > > > > correctly tags the root vnode with VV_ROOT in the unlikely case that we > > > > create the vnode during a call to ufs_vget() that does not come from > > > > ufs_root(). > > > > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock > > is > > > > used while creating the new vnode (same as UFS). > > > > * Allow lock recursion (XXX: not really sure this is needed actually). > > > > * Allow shared vnode locks on non-fifos. > > > > * Honor the requested locking flags (shared vs exclusive) instead of > > always > > > > using exclusive vnode locks during a lookup operation. > > > > * Handle "." lookups the same way other filesystems do by just bumping > > the > > > > reference on 'dvp' rather than calling udf_vget(). > > > > > > > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch > > > > > > @@ -589,6 +582,22 @@ > > > if (error || *vpp != NULL) > > > return (error); > > > > > > + /* > > > + * We must promote to an exclusive lock for vnode creation. This > > > + * can happen if lookup is passed LOCKSHARED. > > > + */ > > > + if ((flags & LK_TYPE_MASK) == LK_SHARED) { > > > + flags &= ~LK_TYPE_MASK; > > > + flags |= LK_EXCLUSIVE; > > > + } > > > + > > > > > > On -CURRENT, operations are bitwise (differently from 7.x and such). > > > What you want to do is just: > > > flag = (flag & ~LK_SHARED) | LK_EXCLUSIVE; > > > > > > I just copied and pasted from UFS in HEAD. > > Yeah, we could fix that also. Although this code will likely be MFC'd to 7.x, so I'd rather do it in a 7.x friendly manner for now. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:48:26 2008 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 969F41065672 for ; Thu, 20 Nov 2008 22:48:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 153858FC22 for ; Thu, 20 Nov 2008 22:48:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAKMmDYM069308; Thu, 20 Nov 2008 17:48:20 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Paul B. Mahol" Date: Thu, 20 Nov 2008 17:47:28 -0500 User-Agent: KMail/1.9.7 References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> In-Reply-To: <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201747.28540.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 20 Nov 2008 17:48:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8654/Thu Nov 20 14:51:00 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 22:48:26 -0000 On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: > On 11/19/08, John Baldwin wrote: > > This is a relatively simple patch to mark cd9660 MPSAFE and enable shared > > lookups. The changes to cd9660_lookup() mirror similar changes to > > ufs_lookup() to use static variables for local data rather than abusing > > i-node members of the parent directory. I've done some light testing of > > this, but not super-strenuous. This patch also includes simple locking for > > the iconv support in the kernel. That locking uses an sx lock to serialize > > open and close of translator tables and the associated refcount. Actual > > conversions do not need any locks, however as the mount holds a reference on > > the table. > > > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch > > > > With this patch I'm unable to kldunload libiconv.ko once it is loaded. > And trying to kldunload libiconv.ko will make any next kldload/kldstat/kldunload > to fail waiting forever(livelock). > > Regression were not encountered while only cd9660.ko were kldloaded. So this is actually due to a bug in the module code. If you have two modules like this: DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); The SI_* constants ensure that foo's module handler is called before bar's module handler for MOD_LOAD. However, we don't enforce a reverse order (bar then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is random and has no relation to the SI_* constants. :( What is happening here is that one of the 'bar' modules in libiconv.ko is getting unloaded after 'foo' gets unloaded and using a destroyed lock (you get a panic if you run with INVARIANTS). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 22:43:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C78C2106567A for ; Thu, 20 Nov 2008 22:43:21 +0000 (UTC) (envelope-from dan-freebsd-questions@ourbrains.org) Received: from ourbrains.org (li48-221.members.linode.com [66.246.76.221]) by mx1.freebsd.org (Postfix) with SMTP id 5D1548FC1B for ; Thu, 20 Nov 2008 22:43:21 +0000 (UTC) (envelope-from dan-freebsd-questions@ourbrains.org) Received: (qmail 9978 invoked by uid 1000); 20 Nov 2008 22:17:01 -0000 Date: Thu, 20 Nov 2008 17:17:01 -0500 From: Dan To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Message-ID: <20081120221701.GA9953@ourbrains.org> Mail-Followup-To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org References: <200811202208.41220.subbsd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200811202208.41220.subbsd@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Thu, 20 Nov 2008 23:02:04 +0000 Cc: Subject: Re: Asus eeepc, Freebsd-head, problem with ath/wifi 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: Thu, 20 Nov 2008 22:43:21 -0000 Ole Vole(subbsd@gmail.com)@2008.11.20 22:08:41 +0300: > Hello maillist! > > Also, trying to test http://people.freebsd.org/~sam/ath_hal-20081028.tgz > > > but ifconfig show only LAN ale0 Ethernet interface. > > On the list pciconf i see "Ralink Technology, Corp" devices but iy without > drivers. You have a different, more expensive model. Atheros is in HA (the one I have), you have the 802n ralink chipset. I got my atheros working by pulling current ath driver from the svn. Do the same for ralink. svn checkout svn://svn.freebsd.org/base/head/sys/dev/ral put the directory in /usr/src/sys/dev/ral (replace the original). And rebuild your curnel. I have issues with sound - it does not support software jack detection, so using headphones means the speakers are still on :(. From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 23:03:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 024B31065673 for ; Thu, 20 Nov 2008 23:03:51 +0000 (UTC) (envelope-from itavy@itavy.com) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.59.2]) by mx1.freebsd.org (Postfix) with SMTP id B23068FC13 for ; Thu, 20 Nov 2008 23:03:50 +0000 (UTC) (envelope-from itavy@itavy.com) Received: (qmail 5191 invoked from network); 20 Nov 2008 22:51:40 -0000 Received: from gator482.hostgator.com (67.18.18.122) by gateway06.websitewelcome.com with SMTP; 20 Nov 2008 22:51:40 -0000 Received: from [78.97.148.67] (port=1564 helo=[10.22.22.22]) by gator482.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3I7l-0002qV-1D; Thu, 20 Nov 2008 16:35:45 -0600 Message-ID: <4925E63C.9070008@itavy.com> Date: Fri, 21 Nov 2008 00:35:40 +0200 From: Octavian Ionescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Andrew Thompson References: <200811202208.41220.subbsd@gmail.com> <20081120221411.GA70932@citylink.fud.org.nz> In-Reply-To: <20081120221411.GA70932@citylink.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator482.hostgator.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - itavy.com Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Ole Vole Subject: Re: Asus eeepc, Freebsd-head, problem with ath/wifi 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: Thu, 20 Nov 2008 23:03:51 -0000 hi, i have had the same problem and asked a while ago (about 1 week ago) about the driver for wireless card for asus eee 1000h and the answer i had received from mr Sam Leffer was: 0x781 is an RT2790; not supported by any driver in the tree. this is first time i am hearing about another driver wich is working with this card and i shall give it a try to see what happens. Best regards, Octavian Andrew Thompson wrote: > On Thu, Nov 20, 2008 at 10:08:41PM +0300, Ole Vole wrote: > >> Hello maillist! >> >> I trying setup FreeBSD according Wiki notes http://wiki.freebsd.org/AsusEee >> and get system without ath Wi-Fi devices (Fn+f2/Bios settings for Wifi: >> Enabled) >> >> buildin/install kernel/world from 20081120 snapshot FreeBSD-CURRENT with/or >> patching from madwifi.org-project ( http://snapshots.madwifi- >> project.org/madwifi-hal-0.10.5.6/madwifi-hal-0.10.5.6-r3875-20081105.tar.gz ) >> (old link http://snapshots.madwifi-project.org/special/madwifi-ng- >> r2756+ar5007.tar.gz is wrong) with extracting hal/ to >> /usr/src/sys/contrib/dev/ath/ and recompile the kernel >> >> >> Also, trying to test http://people.freebsd.org/~sam/ath_hal-20081028.tgz >> >> As result from attemps is string in dmesg: >> ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, >> RF5413, RF2133, RF2425, RF2417) >> >> but ifconfig show only LAN ale0 Ethernet interface. >> >> On the list pciconf i see "Ralink Technology, Corp" devices but iy without >> drivers. >> >> What is wrong here? Thanks! >> > > Thats not an Atheros card and the Ralink chipset isnt supported yet. I > have used ndis with this model and it works fine. > > > Andrew > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 23:15:49 2008 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 2294E1065677; Thu, 20 Nov 2008 23:15:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id DD2FF8FC08; Thu, 20 Nov 2008 23:15:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAKNFkoZ073302; Thu, 20 Nov 2008 18:15:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAKNFkT9021970; Thu, 20 Nov 2008 18:15:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 71D3D73039; Thu, 20 Nov 2008 18:15:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081120231546.71D3D73039@freebsd-current.sentex.ca> Date: Thu, 20 Nov 2008 18:15:46 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 23:15:53 -0000 TB --- 2008-11-20 22:00:00 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-20 22:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-11-20 22:00:00 - cleaning the object tree TB --- 2008-11-20 22:00:44 - cvsupping the source tree TB --- 2008-11-20 22:00:44 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-11-20 22:00:50 - building world TB --- 2008-11-20 22:00:50 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-20 22:00:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-20 22:00:50 - TARGET=amd64 TB --- 2008-11-20 22:00:50 - TARGET_ARCH=amd64 TB --- 2008-11-20 22:00:50 - TZ=UTC TB --- 2008-11-20 22:00:50 - __MAKE_CONF=/dev/null TB --- 2008-11-20 22:00:50 - cd /src TB --- 2008-11-20 22:00:50 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 20 22:00:52 UTC 2008 >>> 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 [...] ===> sys/boot/i386/gptzfsboot (all) cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/gptzfsboot/../../common -I/src/sys/boot/i386/gptzfsboot/../../zfs -I/src/sys/boot/i386/gptzfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/gptzfsboot/../btx/lib -I. -I/src/sys/boot/i386/gptzfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/gptzfsboot/../gptboot/gptldr.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -e start -Ttext 0x7c00 -o gptldr.out gptldr.o objcopy -S -O binary gptldr.out gptldr.bin cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/gptzfsboot/../../common -I/src/sys/boot/i386/gptzfsboot/../../zfs -I/src/sys/boot/i386/gptzfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/gptzfsboot/../btx/lib -I. -I/src/sys/boot/i386/gptzfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/gptzfsboot/../../common -I/src/sys/boot/i386/gptzfsboot/../../zfs -I/src/sys/boot/i386/gptzfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/gptzfsboot/../btx/lib -I. -I/src/sys/boot/i386/gptzfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/gptzfsboot/../boot2/sio.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o gptzfsboot.out /obj/amd64/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such file or directory *** Error code 1 Stop in /src/sys/boot/i386/gptzfsboot. *** Error code 1 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-20 23:15:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-20 23:15:46 - ERROR: failed to build world TB --- 2008-11-20 23:15:46 - 3503.05 user 355.71 system 4545.80 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 23:26:32 2008 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 73C18106564A for ; Thu, 20 Nov 2008 23:26:32 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 242878FC0C for ; Thu, 20 Nov 2008 23:26:31 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so326644yxb.13 for ; Thu, 20 Nov 2008 15:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qdQdk+cksiJ0M0yLtVqkfhmMCkcMCnRnsqgr3rhDHWM=; b=b6DzaDY04Ifl8DCO7STOWxbFoJV2TN8UvaKAemZnJAmfMo3O2GFVKuZSbsw7jhz66b qG4TiW0f/C9yM8t3z7fYrLtOTfezRZvq+nphP3nYnl41MSVrFsOooq4libRKl1Krlni5 thx2DLyVK6/jK0612X2IZYkn9xkAdJR5x3frs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BsPoplhy+BSPaUNRjRbWSMSu14JrtDr0WhzSxqlYlYo4Q+0mqQMyW8TS+AfihdE2as ffviOF4OWfpgFwI9WtH4mPGZu6919HWL+kBT5mFjHXtHd+KwcTEdxhxwTV9VlX3P89tV tsuzxO1c7wxGzt6AxipMYdLsPrx0ffSwS8OIk= Received: by 10.231.15.130 with SMTP id k2mr25816iba.3.1227223591424; Thu, 20 Nov 2008 15:26:31 -0800 (PST) Received: by 10.231.15.70 with HTTP; Thu, 20 Nov 2008 15:26:31 -0800 (PST) Message-ID: <3a142e750811201526r4eb6e9d9xabc4f9ba0bd918cb@mail.gmail.com> Date: Fri, 21 Nov 2008 00:26:31 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200811201747.28540.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> <200811201747.28540.jhb@freebsd.org> Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 23:26:32 -0000 On 11/20/08, John Baldwin wrote: > On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >> On 11/19/08, John Baldwin wrote: >> > This is a relatively simple patch to mark cd9660 MPSAFE and enable >> > shared >> > lookups. The changes to cd9660_lookup() mirror similar changes to >> > ufs_lookup() to use static variables for local data rather than abusing >> > i-node members of the parent directory. I've done some light testing of >> > this, but not super-strenuous. This patch also includes simple locking > for >> > the iconv support in the kernel. That locking uses an sx lock to > serialize >> > open and close of translator tables and the associated refcount. Actual >> > conversions do not need any locks, however as the mount holds a >> > reference > on >> > the table. >> > >> > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >> > >> >> With this patch I'm unable to kldunload libiconv.ko once it is loaded. >> And trying to kldunload libiconv.ko will make any next > kldload/kldstat/kldunload >> to fail waiting forever(livelock). >> >> Regression were not encountered while only cd9660.ko were kldloaded. > > So this is actually due to a bug in the module code. If you have two > modules > like this: > > DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); > DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); > > The SI_* constants ensure that foo's module handler is called before bar's > module handler for MOD_LOAD. However, we don't enforce a reverse order (bar > then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is random > and has no relation to the SI_* constants. :( Exactly, next time I tried it again and it did not livelock. > > What is happening here is that one of the 'bar' modules in libiconv.ko is > getting unloaded after 'foo' gets unloaded and using a destroyed lock (you > get a panic if you run with INVARIANTS). Yes, I tested it on kernel without ddb and friends. From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 23:32:26 2008 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 C39AA1065670 for ; Thu, 20 Nov 2008 23:32:26 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 747C78FC1A for ; Thu, 20 Nov 2008 23:32:26 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so327542yxb.13 for ; Thu, 20 Nov 2008 15:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hHkvJ/zdHxXa5eP8IP3gSC8P3Jg2/f7SN1cazvTxFZU=; b=rDLsxTbalhLbiUHjEJBS7KwvsWQVCas4KqZqxuGJ1C1abiMpjXoxt/OFoyRhHsSC+e 2BJEGa7NL8tKwVePHCVpoobuUUvMzQcYWWwc9QtY585RD0nLIMDmpdzOg42z9LuH0IBL Cu8shdKok4DkX9Dae7lKMQCagJld9rT4c3EfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MoK4+Toe6p5gxUeoLWVY0fx+zDXQjMb2SlkdL1vA81UrponLxB18AM6/BOkVXZcddY OsB7qEulOYMM19I9OX8zZoykdtpKAQ58/zbjmjTogDRQYjo5LC33GZ8OUCGqgKya9tdX sO26v4tJg+3RvypO9SAcV3YqaPi6g+cPQAFVA= Received: by 10.231.12.141 with SMTP id x13mr25324ibx.52.1227223945086; Thu, 20 Nov 2008 15:32:25 -0800 (PST) Received: by 10.231.15.70 with HTTP; Thu, 20 Nov 2008 15:32:25 -0800 (PST) Message-ID: <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> Date: Fri, 21 Nov 2008 00:32:25 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200811201627.58289.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811201627.58289.jhb@freebsd.org> Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 23:32:26 -0000 On 11/20/08, John Baldwin wrote: > So this patch is fairly minimal since udf(4) is currently read-only. The > changes include: > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it > only > in udf_root(). This matches the behavior of other operating systems and > correctly tags the root vnode with VV_ROOT in the unlikely case that we > create the vnode during a call to ufs_vget() that does not come from > ufs_root(). > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock is > used while creating the new vnode (same as UFS). > * Allow lock recursion (XXX: not really sure this is needed actually). > * Allow shared vnode locks on non-fifos. > * Honor the requested locking flags (shared vs exclusive) instead of always > using exclusive vnode locks during a lookup operation. > * Handle "." lookups the same way other filesystems do by just bumping the > reference on 'dvp' rather than calling udf_vget(). > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch > > I have only verified that this compiles and would appreciate it if some > folks > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabled. I lightly tested it with md(4) on 47M size iso created with k3b (it contains two files) I only got this lor related to udf: lock order reversal: 1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442 2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc4399488 udf (udf) @ /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625 KDB: stack backtrace: db_trace_self_wrapper(c069d7d4,c3b6181c,c04e745f,4,c0698f19,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0698f19,c3cb7538,c3cb9ca0,c3b61878,...) at kdb_backtrace+0x29 _witness_debugger(c06a04a1,c4399488,c43bc47c,c3cb9ca0,c43bc3f6,...) at _witness_debugger+0x1e witness_checkorder(c4399488,9,c43bc3f6,271,0,...) at witness_checkorder+0x811 __lockmgr_args(c4399488,80000,0,0,0,...) at __lockmgr_args+0x762 udf_vget(c43a2500,4,200000,c3b619bc,0,...) at udf_vget+0x131 udf_lookup(c3b619fc,c4449218,c3b61bb4,c4449218,c3b61a1c,...) at udf_lookup+0x277 VOP_CACHEDLOOKUP_APV(c43bda80,c3b619fc,c3b61bb4,c3b61ba0,c06f9a20,...) at VOP_CACHEDLOOKUP_APV+0xa0 vfs_cache_lookup(c3b61a7c,c3b61a7c,0,200000,c4449218,...) at vfs_cache_lookup+0xc3 VOP_LOOKUP_APV(c43bda80,c3b61a7c,c06a61d2,1ba,c3b61ba0,...) at VOP_LOOKUP_APV+0xaa lookup(c3b61b88,c06a61d2,dc,bc,c4184c2c,...) at lookup+0x507 namei(c3b61b88,c06a5efc,143,0,c4446240,...) at namei+0x45b kern_statat(c4446240,200,ffffff9c,28304c40,0,...) at kern_statat+0x66 kern_lstat(c4446240,28304c40,0,c3b61c1c,0,...) at kern_lstat+0x36 lstat(c4446240,c3b61cf8,8,c06a1154,c06cf170,...) at lstat+0x2b syscall(c3b61d38) at syscall+0x261 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (190, FreeBSD ELF32, lstat), eip = 0x281f132b, esp = 0xbfbfe5ec, ebp = 0xbfbfe6b8 --- lor also happen sometimes when umounting fs. From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 23:35:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AA311065670 for ; Thu, 20 Nov 2008 23:35:09 +0000 (UTC) (envelope-from freebsd@sprymed.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 131C68FC08 for ; Thu, 20 Nov 2008 23:35:09 +0000 (UTC) (envelope-from freebsd@sprymed.com) Received: by rv-out-0506.google.com with SMTP id b25so650594rvf.43 for ; Thu, 20 Nov 2008 15:35:08 -0800 (PST) Received: by 10.114.182.15 with SMTP id e15mr1673033waf.148.1227222788840; Thu, 20 Nov 2008 15:13:08 -0800 (PST) Received: by 10.114.39.15 with HTTP; Thu, 20 Nov 2008 15:13:08 -0800 (PST) Message-ID: <5b609e020811201513p5cd9cd94vb5bbdb38026fd58b@mail.gmail.com> Date: Thu, 20 Nov 2008 18:13:08 -0500 From: "freebsd world" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_56685_25746386.1227222788839" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: dmesg 8.0-200811 lock order reversal? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2008 23:35:09 -0000 ------=_Part_56685_25746386.1227222788839 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline acd0: DVDR at ata0-master UDMA66 ad14: 953868MB at ata7-master SATA300 ad16: 715404MB at ata8-master SATA150 ad18: 715404MB at ata9-master SATA150 ad20: 715404MB at ata10-master SATA150 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad14s1a lock order reversal: 1st 0xffffff000183c070 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xffffff00051447f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2047 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xca8 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp = 0x7fffffffee90 --- re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP lock order reversal: 1st 0xfffffffee598b1c8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xffffff00057e2800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:254 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x889 ufs_makeinode() at ufs_makeinode+0x338 VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x479 kern_openat() at kern_openat+0x15e syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (5, FreeBSD ELF64, open), rip = 0x800a77c4c, rsp = 0x7fffffffe748, rbp = 0x1a4 --- lock order reversal: 1st 0xffffff00054f6ba8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2047 2nd 0xfffffffee598b1c8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6150 3rd 0xffffff00054f69d0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2047 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vfs_hash_get() at vfs_hash_get+0xd5 ffs_vgetf() at ffs_vgetf+0x48 softdep_sync_metadata() at softdep_sync_metadata+0x459 ffs_syncvnode() at ffs_syncvnode+0x210 ffs_fsync() at ffs_fsync+0x18 ufs_direnter() at ufs_direnter+0x314 ufs_makeinode() at ufs_makeinode+0x338 VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x479 kern_openat() at kern_openat+0x15e syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (5, FreeBSD ELF64, open), rip = 0x800a77c4c, rsp = 0x7fffffffe748, rbp = 0x1a4 --- System still runs is this for just debuging if an error or is this an error? Let me know if you need anything. ---------------- Ben ------=_Part_56685_25746386.1227222788839 Content-Type: text/plain; name=dmesg.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fns0ptt70 Content-Disposition: attachment; filename=dmesg.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOC4wLUNVUlJFTlQtMjAwODExICMwOiBXZWQg Tm92ICA1IDAwOjQ1OjI2IFVUQyAyMDA4DQogICAgcm9vdEBtYXNvbi5jc2UuYnVmZmFsby5lZHU6 L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQw0KV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5h YmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuDQpUaW1lY291bnRlciAiaTgyNTQiIGZy ZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KQ1BVOiBBTUQgUGhlbm9tKHRtKSA5NTAwIFF1 YWQtQ29yZSBQcm9jZXNzb3IgKDIyMTAuMDctTUh6IEs4LWNsYXNzIENQVSkNCiAgT3JpZ2luID0g IkF1dGhlbnRpY0FNRCIgIElkID0gMHgxMDBmMjIgIFN0ZXBwaW5nID0gMg0KICBGZWF0dXJlcz0w eDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRS UixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPg0K ICBGZWF0dXJlczI9MHg4MDIwMDk8U1NFMyxNT04sQ1gxNixQT1BDTlQ+DQogIEFNRCBGZWF0dXJl cz0weGVlNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixQYWdlMUdCLFJEVFNDUCxMTSwzRE5v dyErLDNETm93IT4NCiAgQU1EIEZlYXR1cmVzMj0weDdmZjxMQUhGLENNUCxTVk0sRXh0QVBJQyxD UjgsPGI1Piw8YjY+LDxiNz4sUHJlZmV0Y2gsPGI5Piw8YjEwPj4NCiAgVFNDOiBQLXN0YXRlIGlu dmFyaWFudA0KICBDb3JlcyBwZXIgcGFja2FnZTogNA0KdXNhYmxlIG1lbW9yeSA9IDg1NzM2ODk4 NTYgKDgxNzYgTUIpDQphdmFpbCBtZW1vcnkgID0gODI3OTIyMDIyNCAoNzg5NSBNQikNCkFDUEkg QVBJQyBUYWJsZTogPEdCVCAgICBHQlRVQUNQST4NCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3Nv ciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcw0KIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwDQogY3B1 MSAoQVApOiBBUElDIElEOiAgMQ0KIGNwdTIgKEFQKTogQVBJQyBJRDogIDINCiBjcHUzIChBUCk6 IEFQSUMgSUQ6ICAzDQppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDINCmlvYXBpYzAgPFZl cnNpb24gMi4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQNCmtiZDEgYXQga2JkbXV4MA0KYXRo X2hhbDogMC4xMC41LjEwIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEyLCBBUjU0MTYsIFJGNTExMSwg UkY1MTEyLCBSRjI0MTMsIFJGNTQxMywgUkYyMTMzLCBSRjI0MjUsIFJGMjQxNykNCmFjcGkwOiA8 R0JUIEdCVFVBQ1BJPiBvbiBtb3RoZXJib2FyZA0KYWNwaTA6IFtJVEhSRUFEXQ0KYWNwaTA6IFBv d2VyIEJ1dHRvbiAoZml4ZWQpDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZh aWxlZA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgY2ZkZTAwMDAgKDMpIGZhaWxlZA0K VGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAw DQphY3BpX3RpbWVyMDogPDMyLWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwMDgt MHg0MDBiIG9uIGFjcGkwDQphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+ IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMA0KVGltZWNvdW50ZXIgIkhQRVQi IGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMA0KYWNwaV9idXR0b24wOiA8UG93ZXIg QnV0dG9uPiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNm OC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjANCnBjaWIxOiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQ Q0kgYnVzPiBvbiBwY2liMQ0KdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQg MHhkZTAwLTB4ZGVmZiBtZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4ZmQ5ZTAwMDAtMHhmZDll ZmZmZiBpcnEgMTggYXQgZGV2aWNlIDAuMCBvbiBwY2kxDQpwY2kxOiA8bXVsdGltZWRpYSwgSERB PiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2liMjogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMA0KcGNpMjogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjINCnJlMDogPFJlYWxUZWsgODE2OC84MTY4Qi84MTY4Qy84MTY4Q1AvODExMUIvODExMUMv ODExMUNQIFBDSWUgR2lnYWJpdCBFdGhlcm5ldD4gcG9ydCAweGNlMDAtMHhjZWZmIG1lbSAweGZk ZmZmMDAwLTB4ZmRmZmZmZmYgaXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpMg0KcmUwOiB0dXJu aW5nIG9mZiBNU0kgZW5hYmxlIGJpdC4NCnJlMDogQ2hpcCByZXYuIDB4MzgwMDAwMDANCnJlMDog TUFDIHJldi4gMHgwMDAwMDAwMA0KbWlpYnVzMDogPE1JSSBidXM+IG9uIHJlMA0KcmdlcGh5MDog PFJUTDgxNjlTLzgxMTBTLzgyMTFCIG1lZGlhIGludGVyZmFjZT4gUEhZIDEgb24gbWlpYnVzMA0K cmdlcGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgs IDEwMDBiYXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bw0KcmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAw MDoxYTo0ZDo1ZDo0MTplZA0KcmUwOiBbRklMVEVSXQ0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgOS4wIG9uIHBjaTANCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIz DQphdGFwY2kwOiA8Sk1pY3JvbiBBSENJIGNvbnRyb2xsZXI+IHBvcnQgMHhiZjAwLTB4YmYwNyww eGJlMDAtMHhiZTAzLDB4YmQwMC0weGJkMDcsMHhiYzAwLTB4YmMwMywweGJiMDAtMHhiYjBmIG1l bSAweGZkZGZlMDAwLTB4ZmRkZmZmZmYgaXJxIDE3IGF0IGRldmljZSAwLjAgb24gcGNpMw0KYXRh cGNpMDogW0lUSFJFQURdDQphdGFwY2kwOiBBSENJIFZlcnNpb24gMDEuMDAgY29udHJvbGxlciB3 aXRoIDIgcG9ydHMgUE0gc3VwcG9ydGVkDQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNp MA0KYXRhMjogW0lUSFJFQURdDQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMA0KYXRh MzogW0lUSFJFQURdDQpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMC4w IG9uIHBjaTANCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0DQphdGFwY2kxOiA8Sk1pY3Jv biBKTUIzNjMgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4ZWYwMC0weGVmMDcsMHhlZTAwLTB4 ZWUwMywweGVkMDAtMHhlZDA3LDB4ZWMwMC0weGVjMDMsMHhlYjAwLTB4ZWIwZiBtZW0gMHhmZGJm ZTAwMC0weGZkYmZmZmZmIGlycSAxOCBhdCBkZXZpY2UgMC4wIG9uIHBjaTQNCmF0YXBjaTE6IFtJ VEhSRUFEXQ0KYXRhcGNpMTogQUhDSSBjYWxsZWQgZnJvbSB2ZW5kb3Igc3BlY2lmaWMgZHJpdmVy DQphdGFwY2kxOiBBSENJIFZlcnNpb24gMDEuMDAgY29udHJvbGxlciB3aXRoIDIgcG9ydHMgUE0g c3VwcG9ydGVkDQphdGE0OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQ0KYXRhNDogW0lUSFJF QURdDQphdGE1OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQ0KYXRhNTogW0lUSFJFQURdDQph dGE2OiA8QVRBIGNoYW5uZWwgMj4gb24gYXRhcGNpMQ0KYXRhNjogW0lUSFJFQURdDQphdGFwY2ky OiA8QVRJIElYUDYwMCBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHhmZjAwLTB4ZmYwNywweGZl MDAtMHhmZTAzLDB4ZmQwMC0weGZkMDcsMHhmYzAwLTB4ZmMwMywweGZiMDAtMHhmYjBmIG1lbSAw eGZlMDJmMDAwLTB4ZmUwMmYzZmYgaXJxIDIyIGF0IGRldmljZSAxOC4wIG9uIHBjaTANCmF0YXBj aTI6IFtJVEhSRUFEXQ0KYXRhcGNpMjogQUhDSSBWZXJzaW9uIDAxLjEwIGNvbnRyb2xsZXIgd2l0 aCA0IHBvcnRzIFBNIHN1cHBvcnRlZA0KYXRhNzogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTIN CmF0YTc6IFtJVEhSRUFEXQ0KYXRhODogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTINCmF0YTg6 IFtJVEhSRUFEXQ0KYXRhOTogPEFUQSBjaGFubmVsIDI+IG9uIGF0YXBjaTINCmF0YTk6IFtJVEhS RUFEXQ0KYXRhMTA6IDxBVEEgY2hhbm5lbCAzPiBvbiBhdGFwY2kyDQphdGExMDogW0lUSFJFQURd DQpvaGNpMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZTAyZTAwMC0w eGZlMDJlZmZmIGlycSAxNiBhdCBkZXZpY2UgMTkuMCBvbiBwY2kwDQpvaGNpMDogW0dJQU5ULUxP Q0tFRF0NCm9oY2kwOiBbSVRIUkVBRF0NCnVzYjA6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBz dXBwb3J0DQp1c2IwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwDQp1 c2IwOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMDogPEFUSSBPSENJIHJvb3QgaHViLCBjbGFzcyA5 LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMA0KdWh1YjA6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpvaGNpMTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250 cm9sbGVyPiBtZW0gMHhmZTAyZDAwMC0weGZlMDJkZmZmIGlycSAxNyBhdCBkZXZpY2UgMTkuMSBv biBwY2kwDQpvaGNpMTogW0dJQU5ULUxPQ0tFRF0NCm9oY2kxOiBbSVRIUkVBRF0NCnVzYjE6IE9I Q0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0DQp1c2IxOiA8T0hDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXI+IG9uIG9oY2kxDQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMTogPEFU SSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi MQ0KdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpvaGNpMjog PE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZTAyYzAwMC0weGZlMDJjZmZm IGlycSAxOCBhdCBkZXZpY2UgMTkuMiBvbiBwY2kwDQpvaGNpMjogW0dJQU5ULUxPQ0tFRF0NCm9o Y2kyOiBbSVRIUkVBRF0NCnVzYjI6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0DQp1 c2IyOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kyDQp1c2IyOiBVU0Ig cmV2aXNpb24gMS4wDQp1aHViMjogPEFUSSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMg0KdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkDQpvaGNpMzogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBt ZW0gMHhmZTAyYjAwMC0weGZlMDJiZmZmIGlycSAxNyBhdCBkZXZpY2UgMTkuMyBvbiBwY2kwDQpv aGNpMzogW0dJQU5ULUxPQ0tFRF0NCm9oY2kzOiBbSVRIUkVBRF0NCnVzYjM6IE9IQ0kgdmVyc2lv biAxLjAsIGxlZ2FjeSBzdXBwb3J0DQp1c2IzOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xs ZXI+IG9uIG9oY2kzDQp1c2IzOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMzogPEFUSSBPSENJIHJv b3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMw0KdWh1YjM6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpvaGNpNDogPE9IQ0kgKGdl bmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZTAyYTAwMC0weGZlMDJhZmZmIGlycSAxOCBh dCBkZXZpY2UgMTkuNCBvbiBwY2kwDQpvaGNpNDogW0dJQU5ULUxPQ0tFRF0NCm9oY2k0OiBbSVRI UkVBRF0NCnVzYjQ6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0DQp1c2I0OiA8T0hD SSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2k0DQp1c2I0OiBVU0IgcmV2aXNpb24g MS4wDQp1aHViNDogPEFUSSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNiNA0KdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkDQplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4 ZmUwMjkwMDAtMHhmZTAyOTBmZiBpcnEgMTkgYXQgZGV2aWNlIDE5LjUgb24gcGNpMA0KZWhjaTA6 IFtHSUFOVC1MT0NLRURdDQplaGNpMDogW0lUSFJFQURdDQp1c2I1OiBFSENJIHZlcnNpb24gMS4w DQp1c2I1OiBjb21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxIHVz YjIgdXNiMyB1c2I0DQp1c2I1OiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBv biBlaGNpMA0KdXNiNTogVVNCIHJldmlzaW9uIDIuMA0KdWh1YjU6IDxBVEkgRUhDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjUNCnVodWI1OiAxMCBw b3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpwY2kwOiA8c2VyaWFsIGJ1cywg U01CdXM+IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQphdGFwY2kzOiA8QVRJ IElYUDYwMCBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAt MHgxNzcsMHgzNzYsMHhmOTAwLTB4ZjkwZiBhdCBkZXZpY2UgMjAuMSBvbiBwY2kwDQphdGEwOiA8 QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMw0KYXRhMDogW0lUSFJFQURdDQpwY2kwOiA8bXVsdGlt ZWRpYSwgSERBPiBhdCBkZXZpY2UgMjAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KaXNhYjA6IDxQ Q0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDIwLjMgb24gcGNpMA0KaXNhMDogPElTQSBidXM+IG9u IGlzYWIwDQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyMC40IG9uIHBj aTANCnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1DQpmd29oY2kwOiA8VGV4YXMgSW5zdHJ1 bWVudHMgVFNCNDNBQjIzPiBtZW0gMHhmZDhmZjAwMC0weGZkOGZmN2ZmLDB4ZmQ4ZjgwMDAtMHhm ZDhmYmZmZiBpcnEgMjIgYXQgZGV2aWNlIDE0LjAgb24gcGNpNQ0KZndvaGNpMDogW0ZJTFRFUl0N CmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MCkNCmZ3b2hjaTA6IE5vLiBvZiBJc29j aHJvbm91cyBjaGFubmVscyBpcyA0Lg0KZndvaGNpMDogRVVJNjQgMDA6Y2Q6Y2I6YmM6MDA6MDA6 MWE6NGQNCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMyBwb3J0cy4NCmZ3b2hj aTA6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4IGJ5dGVzLg0KZmlyZXdpcmUwOiA8SUVFRTEzOTQo RmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMA0KZGNvbnNfY3JvbTA6IDxkY29ucyBjb25maWd1cmF0 aW9uIFJPTT4gb24gZmlyZXdpcmUwDQpkY29uc19jcm9tMDogYnVzX2FkZHIgMHgxOGU4MDAwDQpm d2UwOiA8RXRoZXJuZXQgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwDQppZl9md2UwOiBGYWtl IEV0aGVybmV0IGFkZHJlc3M6IDAyOmNkOmNiOjAwOjFhOjRkDQpmd2UwOiBFdGhlcm5ldCBhZGRy ZXNzOiAwMjpjZDpjYjowMDoxYTo0ZA0KZndpcDA6IDxJUCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJl d2lyZTANCmZ3aXAwOiBGaXJld2lyZSBhZGRyZXNzOiAwMDpjZDpjYjpiYzowMDowMDoxYTo0ZCBA IDB4ZmZmZTAwMDAwMDAwLCBTNDAwLCBtYXhyZWMgMjA0OA0Kc2JwMDogPFNCUC0yL1NDU0kgb3Zl ciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwDQpmd29oY2kwOiBJbml0aWF0ZSBidXMgcmVzZXQNCmZ3 b2hjaTA6IEJVUyByZXNldA0KZndvaGNpMDogbm9kZV9pZD0weGM4MDBmZmMwLCBnZW49MSwgQ1lD TEVNQVNURVIgbW9kZQ0KZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2Yw LTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwDQpmZGMwOiBbRklMVEVSXQ0KdWFydDA6 IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAg b24gYWNwaTANCnVhcnQwOiBbRklMVEVSXQ0KcHBjMDogPFBhcmFsbGVsIHBvcnQ+IHBvcnQgMHgz NzgtMHgzN2YgaXJxIDcgb24gYWNwaTANCnBwYzA6IEdlbmVyaWMgY2hpcHNldCAoTklCQkxFLW9u bHkpIGluIENPTVBBVElCTEUgbW9kZQ0KcHBjMDogW0dJQU5ULUxPQ0tFRF0NCnBwYzA6IFtJVEhS RUFEXQ0KcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzANCnBsaXAwOiA8UExJUCBu ZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwDQpwbGlwMDogV0FSTklORzogdXNpbmcgb2Jzb2xl dGVkIElGRl9ORUVEU0dJQU5UIGZsYWcNCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6 IEludGVycnVwdC1kcml2ZW4gcG9ydA0KcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwDQph dGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEg MSBvbiBhY3BpMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCmtiZDAg YXQgYXRrYmQwDQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQphdGtiZDA6IFtJVEhSRUFEXQ0KcHNt MDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpwc20wOiBbR0lBTlQtTE9DS0VEXQ0K cHNtMDogW0lUSFJFQURdDQpwc20wOiBtb2RlbCBJbnRlbGxpTW91c2UsIGRldmljZSBJRCAzDQph dHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzMgb24gYWNwaTANCmNwdTA6 IDxBQ1BJIENQVT4gb24gYWNwaTANCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTANCmNwdTI6IDxB Q1BJIENQVT4gb24gYWNwaTANCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTANCm9ybTA6IDxJU0Eg T3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhkMDAwMC0weGQyZmZmIG9uIGlzYTANCnNjMDogPFN5c3Rl bSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBj b25zb2xlcywgZmxhZ3M9MHgzMDA+DQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4 M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpUaW1lY291bnRlcnMgdGlj ayBldmVyeSAxLjAwMCBtc2VjDQpmaXJld2lyZTA6IDEgbm9kZXMsIG1heGhvcCA8PSAwLCBjYWJs ZSBJUk0gPSAwIChtZSkNCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpDQphY2QwOiBEVkRS IDxITC1EVC1TVERWRC1SQU0gR0gyMkxQMjAvMS4wMj4gYXQgYXRhMC1tYXN0ZXIgVURNQTY2DQph ZDE0OiA5NTM4NjhNQiA8V0RDIFdEMTBFQUNTLTAwWkpCMCAwMS4wMUIwMT4gYXQgYXRhNy1tYXN0 ZXIgU0FUQTMwMA0KYWQxNjogNzE1NDA0TUIgPFNlYWdhdGUgU1QzNzUwNjQwQVMgMy5BQUo+IGF0 IGF0YTgtbWFzdGVyIFNBVEExNTANCmFkMTg6IDcxNTQwNE1CIDxTZWFnYXRlIFNUMzc1MDY0MEFT IDMuQUFKPiBhdCBhdGE5LW1hc3RlciBTQVRBMTUwDQphZDIwOiA3MTU0MDRNQiA8U2VhZ2F0ZSBT VDM3NTA2NDBBUyAzLkFBSj4gYXQgYXRhMTAtbWFzdGVyIFNBVEExNTANClNNUDogQVAgQ1BVICMz IExhdW5jaGVkIQ0KU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhDQpTTVA6IEFQIENQVSAjMiBMYXVu Y2hlZCENCldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBl cmZvcm1hbmNlLg0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDE0czFhDQps b2NrIG9yZGVyIHJldmVyc2FsOg0KIDFzdCAweGZmZmZmZjAwMDE4M2MwNzAgdXNlciBtYXAgKHVz ZXIgbWFwKSBAIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzozMTE1DQogMm5kIDB4ZmZmZmZmMDAw NTE0NDdmOCB1ZnMgKHVmcykgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIwNDcNCktE Qjogc3RhY2sgYmFja3RyYWNlOg0KZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vf c2VsZl93cmFwcGVyKzB4MmENCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdn ZXIrMHgyZQ0Kd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODFl DQpfX2xvY2ttZ3JfYXJncygpIGF0IF9fbG9ja21ncl9hcmdzKzB4Y2E4DQpmZnNfbG9jaygpIGF0 IGZmc19sb2NrKzB4OGMNClZPUF9MT0NLMV9BUFYoKSBhdCBWT1BfTE9DSzFfQVBWKzB4OWINCl92 bl9sb2NrKCkgYXQgX3ZuX2xvY2srMHg0Nw0KdmdldCgpIGF0IHZnZXQrMHg4Yg0Kdm5vZGVfcGFn ZXJfbG9jaygpIGF0IHZub2RlX3BhZ2VyX2xvY2srMHgxZDANCnZtX2ZhdWx0KCkgYXQgdm1fZmF1 bHQrMHgxZTINCnRyYXBfcGZhdWx0KCkgYXQgdHJhcF9wZmF1bHQrMHgxMjgNCnRyYXAoKSBhdCB0 cmFwKzB4NTFjDQpjYWxsdHJhcCgpIGF0IGNhbGx0cmFwKzB4OA0KLS0tIHRyYXAgMHhjLCByaXAg PSAweDQwMDE0ZiwgcnNwID0gMHg3ZmZmZmZmZmVlNzAsIHJicCA9IDB4N2ZmZmZmZmZlZTkwIC0t LQ0KcmUwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTg0KcmUwOiBsaW5rIHN0YXRlIGNoYW5n ZWQgdG8gVVANCnJlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04NCnJlMDogbGluayBzdGF0 ZSBjaGFuZ2VkIHRvIFVQDQpsb2NrIG9yZGVyIHJldmVyc2FsOg0KIDFzdCAweGZmZmZmZmZlZTU5 OGIxYzggYnVmd2FpdCAoYnVmd2FpdCkgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MjQ0 Mw0KIDJuZCAweGZmZmZmZjAwMDU3ZTI4MDAgZGlyaGFzaCAoZGlyaGFzaCkgQCAvdXNyL3NyYy9z eXMvdWZzL3Vmcy91ZnNfZGlyaGFzaC5jOjI1NA0KS0RCOiBzdGFjayBiYWNrdHJhY2U6DQpkYl90 cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQ0KX3dpdG5l c3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlDQp3aXRuZXNzX2NoZWNrb3Jk ZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MWUNCl9zeF94bG9jaygpIGF0IF9zeF94bG9j aysweDU1DQp1ZnNkaXJoYXNoX2FjcXVpcmUoKSBhdCB1ZnNkaXJoYXNoX2FjcXVpcmUrMHgzMw0K dWZzZGlyaGFzaF9hZGQoKSBhdCB1ZnNkaXJoYXNoX2FkZCsweDE5DQp1ZnNfZGlyZW50ZXIoKSBh dCB1ZnNfZGlyZW50ZXIrMHg4ODkNCnVmc19tYWtlaW5vZGUoKSBhdCB1ZnNfbWFrZWlub2RlKzB4 MzM4DQpWT1BfQ1JFQVRFX0FQVigpIGF0IFZPUF9DUkVBVEVfQVBWKzB4OGQNCnZuX29wZW5fY3Jl ZCgpIGF0IHZuX29wZW5fY3JlZCsweDQ3OQ0Ka2Vybl9vcGVuYXQoKSBhdCBrZXJuX29wZW5hdCsw eDE1ZQ0Kc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgxYmYNClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFz dF9zeXNjYWxsKzB4YWINCi0tLSBzeXNjYWxsICg1LCBGcmVlQlNEIEVMRjY0LCBvcGVuKSwgcmlw ID0gMHg4MDBhNzdjNGMsIHJzcCA9IDB4N2ZmZmZmZmZlNzQ4LCByYnAgPSAweDFhNCAtLS0NCmxv Y2sgb3JkZXIgcmV2ZXJzYWw6DQogMXN0IDB4ZmZmZmZmMDAwNTRmNmJhOCB1ZnMgKHVmcykgQCAv dXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIwNDcNCiAybmQgMHhmZmZmZmZmZWU1OThiMWM4 IGJ1ZndhaXQgKGJ1ZndhaXQpIEAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzo2 MTUwDQogM3JkIDB4ZmZmZmZmMDAwNTRmNjlkMCB1ZnMgKHVmcykgQCAvdXNyL3NyYy9zeXMva2Vy bi92ZnNfc3Vici5jOjIwNDcNCktEQjogc3RhY2sgYmFja3RyYWNlOg0KZGJfdHJhY2Vfc2VsZl93 cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmENCl93aXRuZXNzX2RlYnVnZ2Vy KCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQ0Kd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0 bmVzc19jaGVja29yZGVyKzB4ODFlDQpfX2xvY2ttZ3JfYXJncygpIGF0IF9fbG9ja21ncl9hcmdz KzB4YzJhDQpmZnNfbG9jaygpIGF0IGZmc19sb2NrKzB4OGMNClZPUF9MT0NLMV9BUFYoKSBhdCBW T1BfTE9DSzFfQVBWKzB4OWINCl92bl9sb2NrKCkgYXQgX3ZuX2xvY2srMHg0Nw0KdmdldCgpIGF0 IHZnZXQrMHg4Yg0KdmZzX2hhc2hfZ2V0KCkgYXQgdmZzX2hhc2hfZ2V0KzB4ZDUNCmZmc192Z2V0 ZigpIGF0IGZmc192Z2V0ZisweDQ4DQpzb2Z0ZGVwX3N5bmNfbWV0YWRhdGEoKSBhdCBzb2Z0ZGVw X3N5bmNfbWV0YWRhdGErMHg0NTkNCmZmc19zeW5jdm5vZGUoKSBhdCBmZnNfc3luY3Zub2RlKzB4 MjEwDQpmZnNfZnN5bmMoKSBhdCBmZnNfZnN5bmMrMHgxOA0KdWZzX2RpcmVudGVyKCkgYXQgdWZz X2RpcmVudGVyKzB4MzE0DQp1ZnNfbWFrZWlub2RlKCkgYXQgdWZzX21ha2Vpbm9kZSsweDMzOA0K Vk9QX0NSRUFURV9BUFYoKSBhdCBWT1BfQ1JFQVRFX0FQVisweDhkDQp2bl9vcGVuX2NyZWQoKSBh dCB2bl9vcGVuX2NyZWQrMHg0NzkNCmtlcm5fb3BlbmF0KCkgYXQga2Vybl9vcGVuYXQrMHgxNWUN CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MWJmDQpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lz Y2FsbCsweGFiDQotLS0gc3lzY2FsbCAoNSwgRnJlZUJTRCBFTEY2NCwgb3BlbiksIHJpcCA9IDB4 ODAwYTc3YzRjLCByc3AgPSAweDdmZmZmZmZmZTc0OCwgcmJwID0gMHgxYTQgLS0tDQo= ------=_Part_56685_25746386.1227222788839-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 00:18:15 2008 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 783C6106564A for ; Fri, 21 Nov 2008 00:18:15 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 306E18FC17 for ; Fri, 21 Nov 2008 00:18:15 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 726F35D61 for ; Fri, 21 Nov 2008 01:01:13 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9Kfz3BS1hS2Y for ; Fri, 21 Nov 2008 01:01:11 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 1324E5D4E for ; Fri, 21 Nov 2008 01:01:11 +0100 (CET) Message-Id: From: Thomas Vogt To: current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 01:01:10 +0100 X-Mailer: Apple Mail (2.929.2) Cc: Subject: deadlock with 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: Fri, 21 Nov 2008 00:18:15 -0000 Hello I encounter a deadlock while running a few rsync processes mirroring remote data to my local zfs pool. After a few hours my system is starting more and more vsftpd sessions without closing any inactive ftp sessions. I can't kill any rsync and vsftpd processes with "kill -9". Even shutdown -r now does not work. I got a few hunderts vsftpd processes like this 61346 root 1 57 0 7880K 1692K zfs 1 0:00 0.00% vsftpd 61481 root 1 68 0 7880K 1696K zfs 1 0:00 0.00% vsftpd 61354 root 1 65 0 7880K 1692K zfs 1 0:00 0.00% vsftpd 61480 root 1 68 0 7880K 1696K zfs 0 0:00 0.00% vsftpd 61600 root 1 69 0 7880K 1704K zfs 1 0:00 0.00% vsftpd 61599 root 1 68 0 7880K 1704K zfs 1 0:00 0.00% vsftpd Right now i'm building a debug kernel. Whats the best way to get usefull information from this deadlock? The system itself is not crashing and response well to ssh and i also have a serial console. The system is running 8.0-CURRENT Thu Nov 20 00:15:46 UTC 2008 (64bit) with zpool version 13. I use zfs only as data pool. The base system is running on ufs2: Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 496M 220M 236M 48% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s1g 169G 15G 141G 9% /disk1 /dev/da0s1f 3.9G 17M 3.5G 0% /tmp /dev/da0s1e 29G 3.7G 23G 14% /usr /dev/da0s1d 19G 7.1G 11G 40% /var pool 853G 0B 853G 0% /usr/local/data pool/cvsup 858G 5.7G 853G 1% /usr/local/data/cvsup pool/ftp 3.3T 2.5T 853G 75% /usr/local/data/ftp pool/portsnap 853G 633M 853G 0% /usr/local/data/portsnap pool/www 853G 90M 853G 0% /usr/local/data/www loader.conf: vm.kmem_size="1G" kern.maxfiles="65536" kern.maxproc="20480" net.inet.tcp.tcbhashsize="4096" net.inet.tcp.hostcache.hashsize="1024" vfs.zfs.arc_min="64M" vfs.zfs.arc_max="768M" vfs.zfs.prefetch_disable="1" I also tried to set vfs.zfs.zil_disable=1 but the problem still exist. I know there are few deadlock reports listed in the freebsd wiki. Maybe we can trigger the root cause of the problem and fix it :) Regards Thomas From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 00:58:06 2008 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 AE25B1065675 for ; Fri, 21 Nov 2008 00:58:06 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC8B8FC20 for ; Fri, 21 Nov 2008 00:58:06 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so677831rvf.43 for ; Thu, 20 Nov 2008 16:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=Vr9cMFIlj2dT7h4X55UYtpFNzT7NERJ5UNyfNOmzlRQ=; b=gnr/v3qzawSHbWpGOautXwjtJzvRfZiy+vmczX/AsnMLd9+miDFu007eDxjG9YgUvG iDNueNqztN/aPeG84u18InEJ6tKEHHbixivVqhCH60KdH7IE1wnaQBVVphHiUQEjBp1h Q5ZeJWefQhymwzRy46L/yGtf6qux4+17Ye2b8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=nOSbudb5aWqjNHV9dPA8mPi3fcKrWqV6JUSaE60MR5Ni7rQ/6ohR2ORCSVhdsU531p 4T3wN37aL3KDaneCYIm1z+9rrqEp/f7QUNCtAKjp6KgzxUmZ5dS24Mp+LqcFmrZlTn8H keQYvvP9SumNvBXKQSEMVFlPVkyfmFRB7p6Ac= Received: by 10.141.29.21 with SMTP id g21mr1533026rvj.198.1227227140492; Thu, 20 Nov 2008 16:25:40 -0800 (PST) Received: by 10.140.199.20 with HTTP; Thu, 20 Nov 2008 16:25:40 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 16:25:40 -0800 From: "Maksim Yevmenkin" Sender: maksim.yevmenkin@gmail.com To: "Bruce Evans" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: f7d9fc851d49eda2 Cc: "current@freebsd.org" Subject: Re: syscons(4) races X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 00:58:06 -0000 [moving to -current] Bruce, ok, i'm looking at it again... [...] >> More locking for syscons(4). This should prevent races with sckbdevent(). > > This cannot be the correct fix. It should cause panics due to failure > of the (missing) assertion that no locks may be accessed in debugger mode. > Locks may not be accessed in debugger mode because: > (1) locks may be in an inconsistent state (when locking code is being > debugged) (unless they are made to work virtually -- switch all locks > to a safe state while in debugger mode, but display the unswitched > state in all debugger commands) > (2) deadlock is possible (would also be avoided by virtualization). ok, fair enough. >> --- head/sys/dev/syscons/syscons.c Sun Nov 16 21:57:54 2008 >> (r185012) >> +++ head/sys/dev/syscons/syscons.c Sun Nov 16 22:39:04 2008 >> (r185013) >> @@ -1572,6 +1572,7 @@ sccngetch(int flags) >> int s = spltty(); /* block sckbdevent and scrn_timer while we poll */ > > The comment still says that this is what blocks sckbdevent(). > > The comment was wrong too for debugger mode -- in debugger mode, > interrupts are masked in hardware and other CPUs are stopped, so nothing > except possibly this functions internals can call sckbdevent(). ok > Internal calls to scrn_timer() used to be prevented by sccndbctl() > setting syscons' `debugger' flag and this function and others checking > this flag. This has been lost. I think the flag isn't needed and > wasn't used to protect sckbdevent(), and your problem has nothing to > do with debugger mode except for breaking it. Instead your problem > is a layering one (continued below (*)). ok >> int c; >> >> + mtx_lock(&Giant); >> /* assert(sc_console != NULL) */ >> >> /* > > Acquiring Giant in debugger mode is especially invalid (except deadlock > is not so likely for a recursive lock). ok, in this case i have a somewhat stupid question. when kbdmux(4) is the default keyboard, all those kbdd_xxx() calls (that sccngetch() makes) will call into kbdmux(4) functions that will grab giant. kbdmux was changed about 2 months ago to do that. it sounds like those changes are completely wrong. am i correct here? > BTW, sccngetch() shouldn't exist. It existed to demultiplex the 2 > console driver entry points sc_cngetch() and sc_cncheckc(), but > sc_cncheckc() has gone away. the entry point in consdev struct is still there. also cncheckc() is trying to call it (if its present). so it looks like it may not be completely gone, just sysconst(4) no longer implements it. > (*) syscons has several getc routines. The layering and locking for > these should be something like: > > sc_cngetc(): must not access any locks; currently implemented by > calling scgetc(); therefore: > scgetc(): must not access any locks ok. > sccngetch(): bogus layering -- see above > sckbdevent(): I think this is the entry point for all normal (non- > low-level-console) syscons input. It is currently implemented > by calling scgetc(), which must not access any locks. Therefore, > any locking must be in this function. I think it currently uses > Giant locking. yes, it does. > There is still a problem for calls to sc_cngetc() from the low-console > driver. These can race with sckbdevent(). In debugger mode, no locking > is permitted, so syscons' getc functions must be carefully written to > do only harmless things when they lose races. They are not carefully > written (e.g., almost the first thing they do, shown in the above, may > give a buffer overrun: > > if (fkeycp < fkey.len) { > mtx_unlock(&Giant); > splx(s); > return fkey.str[fkeycp++]; > } all right, so we can not use locks, i'm guessing this includes spin locks too. can we use atomic operations here? since, in polling mode, consumer is going to call getc() in a loop, can we use atomic reference counter to make sure there is only one caller running at a time? if someone already grabbed reference counter just return -1 as if there is no input? > since the increment is not atomic with the bounds check), but they > mostly work. (Syscons' putc routines have a much larger number of > races like this, but they mostly work too. It used to be easy to cause > panics by racing normal console output with printfs from an interrupt > handler (use a high frequency timeout interrupt handler that prints > something), but almost any locking would fix that and I think Giant-locking > everything fixed it accidentally (**). So there is only a problem > modes like debugger mode where locking is not permitted.) > > The races for sc_cngetc() were normally limited: > - most calls were in debugger mode, and debugger mode limits problems > - the only other calls were for things like gets() for non-auto > mountroot and cngetc() for the "hit any key to reboot". This case > might even supply the needed and permitted Giant locking accidentally. > > However, you seem to have made the races very common by (ab)using cngetc() > for keyboard multiplexing. cngetc() is not designed for this. You need > to know syscons' internals and do the necessary Giant locking in the caller. this is what i'm not getting. are you saying that lower layer keyboard drivers can not use any locking whatsoever in polling mode (or rather debug mode)? are you saying that we need a completely different path for handling keyboard input in debug mode? and/or possibly polling mode? thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 01:12:50 2008 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 565791065670 for ; Fri, 21 Nov 2008 01:12:50 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF0F8FC12 for ; Fri, 21 Nov 2008 01:12:49 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id DB8705D56 for ; Fri, 21 Nov 2008 02:12:48 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cRKdbn3OtskB for ; Fri, 21 Nov 2008 02:12:46 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 0ACB75D4A for ; Fri, 21 Nov 2008 02:12:46 +0100 (CET) Message-Id: <86206E58-E7BF-44F8-8E8B-9165E2C230E2@bsdunix.ch> From: Thomas Vogt To: current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 02:12:45 +0100 X-Mailer: Apple Mail (2.929.2) Cc: Subject: can't compile debug kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 01:12:50 -0000 Hello I try to create a debug kernel with freebsd current 64bit. I added all options described in http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html : makeoptions DEBUG=-g options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC options KDB options KDB I always get: /usr/src/sys/kern/kern_lock.c:917: undefined reference to `stack_print_ddb' cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g - Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer- sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/ contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit- growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno- sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug kern_lock.o(.text+0x245): In function `lockmgr_printinfo': /usr/src/sys/kern/kern_lock.c:917: undefined reference to `stack_print_ddb' *** Error code 1 Would anyone care to tell me what i'm doing wrong? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 01:20:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B567106567B for ; Fri, 21 Nov 2008 01:20:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9DEFB8FC22 for ; Fri, 21 Nov 2008 01:19:59 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L3KgZ-0002jT-A2 for freebsd-current@freebsd.org; Fri, 21 Nov 2008 01:19:51 +0000 Received: from 93-138-100-93.adsl.net.t-com.hr ([93.138.100.93]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Nov 2008 01:19:51 +0000 Received: from ivoras by 93-138-100-93.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Nov 2008 01:19:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 21 Nov 2008 02:19:35 +0100 Lines: 54 Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> <200811182340.13372.Thomas.Sparrevohn@btinternet.com> <200811200015.54319.Thomas.Sparrevohn@btinternet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFAC76373C7B1F4142BED4459" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-100-93.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) In-Reply-To: <200811200015.54319.Thomas.Sparrevohn@btinternet.com> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 01:20:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFAC76373C7B1F4142BED4459 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thomas Sparrevohn wrote: > On Wednesday 19 November 2008 10:14:02 Ivan Voras wrote: >> Thomas Sparrevohn wrote: >>> On Tuesday 18 November 2008 21:56:38 Pawel Jakub Dawidek wrote: >>>> On Tue, Nov 18, 2008 at 09:50:51PM +0000, Thomas Sparrevohn wrote: >>>>> On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: >>>>>> What's unexpected in that? As I noted it still needs more work, so= >>>>>> chflags(2) working properly would be unexpected for me:) >>>>>> >>>>>>> -------------------------------------------------------------- >>>>> LOL - Unexpected that it just not returns operation not supported a= s it used to - I was a bit >>>>> trigger happy and upgraded my main pool - against the sound advice = - leaves me in a bit of trouble ;-) >>>> Try 'make installworld NO_FSCHG=3D'. >>>> >>> LOL and now I feel really stupid - thanks >> Hmmm, I did an installworld from UFS to ZFS yesterday without special >> flags (actually, multiple installworlds for benchmarking), without >> errors. Files really did get schg (or equivalent) flag since I couldn'= t >> rm them afterwards. How is this possible? :) >=20 > That is a surprise - as mine failed - totally - had to manually restore= libc I've just did it again - make installworld DESTDIR=3D/data/test (I'm not using ZFS on root) - works without problems, ls reports schg flag on the usual files. amd64, ZFS pool version 13, compiled a few hours after the big import. --------------enigFAC76373C7B1F4142BED4459 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkmDK0ACgkQldnAQVacBch7KgCg5gx1h2RYhXqklvc155npNVqj Co4AoN+4ivwBU7zbqq8P/OIUvRp7WEKD =/dgO -----END PGP SIGNATURE----- --------------enigFAC76373C7B1F4142BED4459-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 01:33:05 2008 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 E78C91065670 for ; Fri, 21 Nov 2008 01:33:05 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id CE6648FC08 for ; Fri, 21 Nov 2008 01:33:05 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from dhcp-131-195.eecs.berkeley.edu ([128.32.131.195]) by fe2.calmail with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1L3KeO-00074f-8B; Thu, 20 Nov 2008 17:17:37 -0800 Message-Id: From: Steven Schlansker To: Thomas Vogt In-Reply-To: <86206E58-E7BF-44F8-8E8B-9165E2C230E2@bsdunix.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 17:17:36 -0800 References: <86206E58-E7BF-44F8-8E8B-9165E2C230E2@bsdunix.ch> X-Mailer: Apple Mail (2.929.2) Cc: current@freebsd.org Subject: Re: can't compile debug kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 01:33:06 -0000 options DDB? (from ddb manpage) On Nov 20, 2008, at 5:12 PM, Thomas Vogt wrote: > Hello > > I try to create a debug kernel with freebsd current 64bit. I added > all options described in http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html > : > > makeoptions DEBUG=-g > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > options DIAGNOSTIC > options KDB > options KDB > > I always get: /usr/src/sys/kern/kern_lock.c:917: undefined > reference to `stack_print_ddb' > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes - > Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef - > Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys - > I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS - > include opt_global.h -fno-common -finline-limit=8000 --param inline- > unit-growth=100 --param large-function-growth=1000 -fno-omit-frame- > pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno- > sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous- > unwind-tables -ffreestanding -fstack-protector -Werror vers.c > linking kernel.debug > kern_lock.o(.text+0x245): In function `lockmgr_printinfo': > /usr/src/sys/kern/kern_lock.c:917: undefined reference to > `stack_print_ddb' > *** Error code 1 > > Would anyone care to tell me what i'm doing wrong? > > 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 > " From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 01:42:57 2008 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 76939106564A for ; Fri, 21 Nov 2008 01:42:57 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7FE8FC0C for ; Fri, 21 Nov 2008 01:42:56 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 309775D61; Fri, 21 Nov 2008 02:42:56 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ppvjxz-d1XYT; Fri, 21 Nov 2008 02:42:54 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 4D0775D40; Fri, 21 Nov 2008 02:42:54 +0100 (CET) Message-Id: <5F230023-85DE-4155-B5ED-715BB0F58965@bsdunix.ch> From: Thomas Vogt To: Steven Schlansker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 02:42:53 +0100 References: <86206E58-E7BF-44F8-8E8B-9165E2C230E2@bsdunix.ch> X-Mailer: Apple Mail (2.929.2) Cc: current@freebsd.org Subject: Re: can't compile debug kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 01:42:57 -0000 Hello Am 21.11.2008 um 02:17 schrieb Steven Schlansker: > options DDB? > > (from ddb manpage) Correct. I accidentally added KDB twice instead of KDB and DDB. I was blind Regards, Thomas > > > On Nov 20, 2008, at 5:12 PM, Thomas Vogt wrote: > >> Hello >> >> I try to create a debug kernel with freebsd current 64bit. I added >> all options described in http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html >> : >> >> makeoptions DEBUG=-g >> options INVARIANTS >> options INVARIANT_SUPPORT >> options WITNESS >> options DEBUG_LOCKS >> options DEBUG_VFS_LOCKS >> options DIAGNOSTIC >> options KDB >> options KDB >> >> I always get: /usr/src/sys/kern/kern_lock.c:917: undefined >> reference to `stack_print_ddb' >> >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 - >> g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes - >> Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef - >> Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys - >> I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS - >> include opt_global.h -fno-common -finline-limit=8000 --param inline- >> unit-growth=100 --param large-function-growth=1000 -fno-omit-frame- >> pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno- >> sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous- >> unwind-tables -ffreestanding -fstack-protector -Werror vers.c >> linking kernel.debug >> kern_lock.o(.text+0x245): In function `lockmgr_printinfo': >> /usr/src/sys/kern/kern_lock.c:917: undefined reference to >> `stack_print_ddb' >> *** Error code 1 >> >> Would anyone care to tell me what i'm doing wrong? >> >> 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 >> " > From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 02:25:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A4231065678 for ; Fri, 21 Nov 2008 02:25:40 +0000 (UTC) (envelope-from rksah@bredband.net) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id D9B1B8FC1D for ; Fri, 21 Nov 2008 02:25:39 +0000 (UTC) (envelope-from rksah@bredband.net) Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.127) id 48DC49FD01140352 for freebsd-current@freebsd.org; Fri, 21 Nov 2008 03:05:01 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aic1AN6lJUlV4BwGPGdsb2JhbACJGoo1AQEBATW+E4J8 Received: from c-061ce055.246-1-64736c10.cust.bredbandsbolaget.se (HELO _HOSTNAME_) ([85.224.28.6]) by ironport2.bredband.com with SMTP; 21 Nov 2008 03:05:01 +0100 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Fri, 21 Nov 2008 03:05:00 +0100 From: "Björn Jonare" Date: Fri, 21 Nov 2008 03:05:00 +0100 To: freebsd-current@freebsd.org Message-ID: <20081121020459.GB1397@hel.niflheim.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.18 (2008-05-17) Subject: GENERIC + ral X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 02:25:40 -0000 Hello! Running CURRENT as of today I tried to get my Linksys WMP54G up and working. After some trouble with the console spewing error messages that the firmware couldn't be loaded I read the manpage for ral(4). Looking through the config for GENERIC I saw that there was no line "device ralfw". After adding that line and rebooting everything went fine. However, shouldn't ralfw be present in GENERIC? It won't build as a module and "device ral" is sort of useless if the system can't load card firmware. Or am I simply missing something? /Björn From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 03:10:26 2008 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 51772106567A; Fri, 21 Nov 2008 03:10:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2186E8FC1E; Fri, 21 Nov 2008 03:10:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL3AMOY040261; Thu, 20 Nov 2008 22:10:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL3AM8l094418; Thu, 20 Nov 2008 22:10:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6B29673039; Thu, 20 Nov 2008 22:10:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121031022.6B29673039@freebsd-current.sentex.ca> Date: Thu, 20 Nov 2008 22:10:22 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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: Fri, 21 Nov 2008 03:10:26 -0000 TB --- 2008-11-21 01:31:11 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 01:31:11 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-11-21 01:31:11 - cleaning the object tree TB --- 2008-11-21 01:31:37 - cvsupping the source tree TB --- 2008-11-21 01:31:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-11-21 01:31:46 - building world TB --- 2008-11-21 01:31:46 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 01:31:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 01:31:46 - TARGET=powerpc TB --- 2008-11-21 01:31:46 - TARGET_ARCH=powerpc TB --- 2008-11-21 01:31:46 - TZ=UTC TB --- 2008-11-21 01:31:46 - __MAKE_CONF=/dev/null TB --- 2008-11-21 01:31:46 - cd /src TB --- 2008-11-21 01:31:46 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 01:31:47 UTC 2008 >>> 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 21 02:55:31 UTC 2008 TB --- 2008-11-21 02:55:31 - generating LINT kernel config TB --- 2008-11-21 02:55:31 - cd /src/sys/powerpc/conf TB --- 2008-11-21 02:55:31 - /usr/bin/make -B LINT TB --- 2008-11-21 02:55:31 - building LINT kernel TB --- 2008-11-21 02:55:31 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 02:55:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 02:55:31 - TARGET=powerpc TB --- 2008-11-21 02:55:31 - TARGET_ARCH=powerpc TB --- 2008-11-21 02:55:31 - TZ=UTC TB --- 2008-11-21 02:55:31 - __MAKE_CONF=/dev/null TB --- 2008-11-21 02:55:31 - cd /src TB --- 2008-11-21 02:55:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 02:55:31 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 -ffreestanding -fstack-protector -Werror vers.c linking kernel hwpmc_mod.o(.text+0x3328): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 03:10:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 03:10:22 - ERROR: failed to build lint kernel TB --- 2008-11-21 03:10:22 - 4768.07 user 414.42 system 5950.33 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 03:36:11 2008 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 C4E911065672; Fri, 21 Nov 2008 03:36:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 94A7F8FC12; Fri, 21 Nov 2008 03:36:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL3a9F0041778; Thu, 20 Nov 2008 22:36:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL3a96o031813; Thu, 20 Nov 2008 22:36:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3D07B73039; Thu, 20 Nov 2008 22:36:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121033609.3D07B73039@freebsd-current.sentex.ca> Date: Thu, 20 Nov 2008 22:36:09 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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, 21 Nov 2008 03:36:12 -0000 TB --- 2008-11-21 01:26:17 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 01:26:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-11-21 01:26:17 - cleaning the object tree TB --- 2008-11-21 01:26:48 - cvsupping the source tree TB --- 2008-11-21 01:26:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-11-21 01:26:55 - building world TB --- 2008-11-21 01:26:55 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 01:26:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 01:26:55 - TARGET=ia64 TB --- 2008-11-21 01:26:55 - TARGET_ARCH=ia64 TB --- 2008-11-21 01:26:55 - TZ=UTC TB --- 2008-11-21 01:26:55 - __MAKE_CONF=/dev/null TB --- 2008-11-21 01:26:55 - cd /src TB --- 2008-11-21 01:26:55 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 01:26:57 UTC 2008 >>> 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 21 03:14:18 UTC 2008 TB --- 2008-11-21 03:14:18 - generating LINT kernel config TB --- 2008-11-21 03:14:18 - cd /src/sys/ia64/conf TB --- 2008-11-21 03:14:18 - /usr/bin/make -B LINT TB --- 2008-11-21 03:14:18 - building LINT kernel TB --- 2008-11-21 03:14:18 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 03:14:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 03:14:18 - TARGET=ia64 TB --- 2008-11-21 03:14:18 - TARGET_ARCH=ia64 TB --- 2008-11-21 03:14:18 - TZ=UTC TB --- 2008-11-21 03:14:18 - __MAKE_CONF=/dev/null TB --- 2008-11-21 03:14:18 - cd /src TB --- 2008-11-21 03:14:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 03:14:19 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0xa2f2): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 03:36:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 03:36:09 - ERROR: failed to build lint kernel TB --- 2008-11-21 03:36:09 - 6413.25 user 444.39 system 7791.52 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 04:46:28 2008 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 4590C1065673; Fri, 21 Nov 2008 04:46:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 162EB8FC19; Fri, 21 Nov 2008 04:46:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL4kOfM046050; Thu, 20 Nov 2008 23:46:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL4kOok021267; Thu, 20 Nov 2008 23:46:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A8BDB73039; Thu, 20 Nov 2008 23:46:24 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121044624.A8BDB73039@freebsd-current.sentex.ca> Date: Thu, 20 Nov 2008 23:46:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2008 04:46:28 -0000 TB --- 2008-11-21 03:10:22 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 03:10:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-21 03:10:22 - cleaning the object tree TB --- 2008-11-21 03:10:45 - cvsupping the source tree TB --- 2008-11-21 03:10:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-21 03:10:52 - building world TB --- 2008-11-21 03:10:52 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 03:10:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 03:10:52 - TARGET=sparc64 TB --- 2008-11-21 03:10:52 - TARGET_ARCH=sparc64 TB --- 2008-11-21 03:10:52 - TZ=UTC TB --- 2008-11-21 03:10:52 - __MAKE_CONF=/dev/null TB --- 2008-11-21 03:10:52 - cd /src TB --- 2008-11-21 03:10:52 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 03:10:53 UTC 2008 >>> 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 21 04:30:10 UTC 2008 TB --- 2008-11-21 04:30:10 - generating LINT kernel config TB --- 2008-11-21 04:30:10 - cd /src/sys/sparc64/conf TB --- 2008-11-21 04:30:10 - /usr/bin/make -B LINT TB --- 2008-11-21 04:30:10 - building LINT kernel TB --- 2008-11-21 04:30:10 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 04:30:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 04:30:10 - TARGET=sparc64 TB --- 2008-11-21 04:30:10 - TARGET_ARCH=sparc64 TB --- 2008-11-21 04:30:10 - TZ=UTC TB --- 2008-11-21 04:30:10 - __MAKE_CONF=/dev/null TB --- 2008-11-21 04:30:10 - cd /src TB --- 2008-11-21 04:30:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 04:30:10 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 04:46:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 04:46:24 - ERROR: failed to build lint kernel TB --- 2008-11-21 04:46:24 - 4577.45 user 411.22 system 5761.91 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 06:55:39 2008 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 D14DB1065673; Fri, 21 Nov 2008 06:55:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A40E38FC0A; Fri, 21 Nov 2008 06:55:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL6taiD054500; Fri, 21 Nov 2008 01:55:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAL6ta2Y020264; Fri, 21 Nov 2008 01:55:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3576573039; Fri, 21 Nov 2008 01:55:36 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121065536.3576573039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 01:55:36 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2008 06:55:40 -0000 TB --- 2008-11-21 05:40:00 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 05:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-11-21 05:40:00 - cleaning the object tree TB --- 2008-11-21 05:40:23 - cvsupping the source tree TB --- 2008-11-21 05:40:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-11-21 05:40:33 - building world TB --- 2008-11-21 05:40:33 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 05:40:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 05:40:33 - TARGET=amd64 TB --- 2008-11-21 05:40:33 - TARGET_ARCH=amd64 TB --- 2008-11-21 05:40:33 - TZ=UTC TB --- 2008-11-21 05:40:33 - __MAKE_CONF=/dev/null TB --- 2008-11-21 05:40:33 - cd /src TB --- 2008-11-21 05:40:33 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 05:40:36 UTC 2008 >>> 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 [...] ===> sys/boot/i386/gptzfsboot (all) cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/gptzfsboot/../../common -I/src/sys/boot/i386/gptzfsboot/../../zfs -I/src/sys/boot/i386/gptzfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/gptzfsboot/../btx/lib -I. -I/src/sys/boot/i386/gptzfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/gptzfsboot/../gptboot/gptldr.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -e start -Ttext 0x7c00 -o gptldr.out gptldr.o objcopy -S -O binary gptldr.out gptldr.bin cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/gptzfsboot/../../common -I/src/sys/boot/i386/gptzfsboot/../../zfs -I/src/sys/boot/i386/gptzfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/gptzfsboot/../btx/lib -I. -I/src/sys/boot/i386/gptzfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/gptzfsboot/../../common -I/src/sys/boot/i386/gptzfsboot/../../zfs -I/src/sys/boot/i386/gptzfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/gptzfsboot/../btx/lib -I. -I/src/sys/boot/i386/gptzfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/gptzfsboot/../boot2/sio.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o gptzfsboot.out /obj/amd64/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such file or directory *** Error code 1 Stop in /src/sys/boot/i386/gptzfsboot. *** Error code 1 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 06:55:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 06:55:36 - ERROR: failed to build world TB --- 2008-11-21 06:55:36 - 3502.36 user 354.35 system 4535.86 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 07:20:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B978106564A for ; Fri, 21 Nov 2008 07:20:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id CCAD38FC1B for ; Fri, 21 Nov 2008 07:20:19 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so791676rvf.43 for ; Thu, 20 Nov 2008 23:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=wr/NjJuH7qltHEAtNym5OE+0qXAh9Q2UnSxGriqVNLU=; b=Y+UqIuF4NYbwPkloQ0pcQMrzb6adI1eOT0ZyahwBTRXuEfBOpCXlvQ13MCaKxO8U6A m024tnn85EWOenwD7RBSotu3MTzTuuop431inOXflPEwPJqWtoGcVcc72OHETiqFWck3 /hZH8ecSzxfvGt3Wq8CIphu5j+vS9k7CiVo+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jGik7P3M3nuvcqkALjAWJIWMDCcClXR2UC5ucSHTpAhbHOfRgoOJtlqTaKXCHvpbzI L96zoVcavgFc2EmjgzZxfuAQ8SC/eMeLlbUPqwoyGYOlZn5PwEPG59eTVzvCls82AYDr ck5E25BHMObbbIN3Y/kF794NiNUH2LQ4Ml0PI= Received: by 10.141.163.12 with SMTP id q12mr143176rvo.7.1227250678838; Thu, 20 Nov 2008 22:57:58 -0800 (PST) Received: by 10.141.79.14 with HTTP; Thu, 20 Nov 2008 22:57:58 -0800 (PST) Message-ID: <7d6fde3d0811202257k198e50d2kd9af6d80f73b2d5@mail.gmail.com> Date: Thu, 20 Nov 2008 22:57:58 -0800 From: "Garrett Cooper" To: kevin In-Reply-To: <4920DF4F.1080407@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4911B529.1030804@163.com> <3bbf2fe10811051031j25ed35e8r78dd5f21e3551579@mail.gmail.com> <4920DF4F.1080407@163.com> Cc: Attilio Rao , FreeBSD Current Subject: Re: shutdown and reboot do not work correct X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 07:20:20 -0000 On Sun, Nov 16, 2008 at 7:04 PM, kevin wrote: > Attilio Rao wrote: >> >> 2008/11/5, kevin : >> >>> >>> Hi, >>> I update everything this afternoon(both kernel and world). when i try >>> to >>> reboot or shutdown system,i find something goes wrong.After system output >>> "All buffers synced" and "Accounting disabled",system does not power off >>> as >>> normal. the keyboard still works and when i press the power button ,it >>> output "acpi: suspend request ignored (not ready yet)", "acpi: request to >>> enter state S5 failed (error 6)". Any one meet same problem? >>> >> >> Could you please break into DDB and see where it is hanging? >> >> Thanks, >> Attilio >> >> >> > > I break into DDB and find lots of kernel threads are in SL stat,thread > [accounting] is in stat ZL.I guess accounting can't exit correctly.After i > turn off accounting,i can shutdown system now. > > > > > > Thanks, > kevin I'm getting something similar trying to reboot my server with an older image; oddly enough Samba worked like a champ and I was connected a few days ago fine (then I rebooted my client and lost the ssh connection). Details soon to come. -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 07:56:11 2008 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 4ADD51065672; Fri, 21 Nov 2008 07:56:11 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by mx1.freebsd.org (Postfix) with ESMTP id 046D78FC13; Fri, 21 Nov 2008 07:56:11 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 25A98C7EC9; Fri, 21 Nov 2008 09:40:17 +0200 (EET) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A0063F23400; Fri, 21 Nov 2008 09:40:17 +0200 Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by emh04.mail.saunalahti.fi (Postfix) with SMTP id 9F67541BEB; Fri, 21 Nov 2008 09:40:13 +0200 (EET) Date: Fri, 21 Nov 2008 09:40:13 +0200 From: Jaakko Heinonen To: "Paul B. Mahol" Message-ID: <20081121074013.GA818@a91-153-125-115.elisa-laajakaista.fi> References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Antivirus: VAMS Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 07:56:11 -0000 On 2008-11-20, Paul B. Mahol wrote: > Machine crashed during clean shutdown (with old kernel without this patch) > after atapicd where kldloaded and after that used some time and tham > kldunloaded. There are several bugs related to unloading the atapicd module. * g_wither_geom() race against module unload * return value from g_modevent() is ignored * detaching/unloading is allowed even if the device is in use You could try these patches: http://www.saunalahti.fi/~jh3/patches/atapi-cd-locking+tray-control.diff http://www.saunalahti.fi/~jh3/patches/geom-unload-class-race.diff -- Jaakko From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 08:37:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDF931065672 for ; Fri, 21 Nov 2008 08:37:13 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5989C8FC1E for ; Fri, 21 Nov 2008 08:37:13 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so925271fkk.11 for ; Fri, 21 Nov 2008 00:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-pgp-agent:x-mailer; bh=e6saBavlnlMZ1bGr2+tS/yXGBzSlhjDn7ifaJPO3was=; b=a7HmVK7UkYM6Gvw4mQJP2i8qRfGjL2WHmTxzTUwUF1yvVXgZFEJecSJG29gQCp2jiE 8ovB/2IKDbGVSZQqrRn02ouYj9lD+mvS21yZtsAUuDYEg5U6NlD0XpSgazhpyLDCU4c7 GDs2AlkLVvm237efdTseWxMVCV+JiBTEMXmuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-pgp-agent:x-mailer; b=Kzj0RCfSHkad7i2TKFI0Mf5jl6zVkWX2tcKROfxskY9QRrI0y6J3v2pYjJzMQcCadi Lal2lLxBu2fS2AdgBZQimFG8vhM+5ZRL3NEy7HSTAl/gO5WULl1eIjFaYMyvn4tXAGPf f1LZnF9PyyFh4UwXT/hapZr9ftDGG5WNMO7qM= Received: by 10.187.182.10 with SMTP id j10mr38714fap.12.1227256632115; Fri, 21 Nov 2008 00:37:12 -0800 (PST) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id 28sm2748529fkx.1.2008.11.21.00.37.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Nov 2008 00:37:09 -0800 (PST) Message-Id: <29D6BF8D-6A05-4446-95FE-8F0AC0195C79@gmail.com> From: Nikolay Denev To: freebsd-current@freebsd.org In-Reply-To: <18E318DD-29FA-4E26-89CF-11B893B42E34@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 10:37:04 +0200 References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> <20081119090307.GA81236@icarus.home.lan> <18E318DD-29FA-4E26-89CF-11B893B42E34@gmail.com> X-Pgp-Agent: GPGMail d53 (v53, Leopard) X-Mailer: Apple Mail (2.929.2) Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 08:37:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov, 2008, at 13:58 , Nikolay Denev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 19 Nov, 2008, at 11:48 , Nikolay Denev wrote: >> >> Well, it looks like that on -current and a 4G amd64 machine >> probably there is no need >> to tune anything. Here are my defaults with everything vm and zfs >> related in loader.conf commented : >> >> vm.kmem_size_max: 4509713203 >> vfs.zfs.arc_max: 863907840 >> > > I was able to panic it again with "kmem_map too small" with these > settings (defaults). > > This are the bonnie++ arguments that i've used: > bonnie++ -d /tank -c 4 -r 4096 -x 9999999 -u 0:0 > > With vfs.zfs.arc_max="512M" and nothing else the machine survived more than 20 hours of bonnie++ and "iozone -a" in parallel, and is still working. Definitely the stability has improved with the new version. But maybe the algorithm for automatically setting arc_max needs a little more tweaking? (if it's not hardcoded?) - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkkmczAACgkQHNAJ/fLbfrmCuACdFebPzWgigaivfOEzwXnL+2Qe 7EYAoL1KnVO7BqniD8kuZ9sPw498rILz =Yz6c -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 08:56:07 2008 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 E9FA11065672 for ; Fri, 21 Nov 2008 08:56:07 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id E57948FC1A for ; Fri, 21 Nov 2008 08:56:06 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 0951C5DA8 for ; Fri, 21 Nov 2008 09:56:05 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CHLETSkx7HLh; Fri, 21 Nov 2008 09:55:58 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id A6AD15DA5; Fri, 21 Nov 2008 09:55:58 +0100 (CET) Message-Id: From: Thomas Vogt To: Thomas Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 09:55:58 +0100 References: X-Mailer: Apple Mail (2.929.2) Cc: current@freebsd.org Subject: Re: deadlock with 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: Fri, 21 Nov 2008 08:56:08 -0000 Hello Am 21.11.2008 um 01:01 schrieb Thomas: > Hello > > I encounter a deadlock while running a few rsync processes mirroring > remote data to my local zfs pool. After a few hours my system is > starting more and more vsftpd sessions without closing any inactive > ftp sessions. I can't kill any rsync and vsftpd processes with "kill > -9". Even shutdown -r now does not work. > > I got a few hunderts vsftpd processes like this > > 61346 root 1 57 0 7880K 1692K zfs 1 0:00 0.00% > vsftpd > 61481 root 1 68 0 7880K 1696K zfs 1 0:00 0.00% > vsftpd > 61354 root 1 65 0 7880K 1692K zfs 1 0:00 0.00% > vsftpd > 61480 root 1 68 0 7880K 1696K zfs 0 0:00 0.00% > vsftpd > 61600 root 1 69 0 7880K 1704K zfs 1 0:00 0.00% > vsftpd > 61599 root 1 68 0 7880K 1704K zfs 1 0:00 0.00% > vsftpd > > Right now i'm building a debug kernel. Whats the best way to get > usefull information from this deadlock? The system itself is not > crashing and response well to ssh and i also have a serial console. > > The system is running 8.0-CURRENT Thu Nov 20 00:15:46 UTC 2008 > (64bit) with zpool version 13. I use zfs only as data pool. The base > system is running on ufs2: > > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 496M 220M 236M 48% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/da0s1g 169G 15G 141G 9% /disk1 > /dev/da0s1f 3.9G 17M 3.5G 0% /tmp > /dev/da0s1e 29G 3.7G 23G 14% /usr > /dev/da0s1d 19G 7.1G 11G 40% /var > pool 853G 0B 853G 0% /usr/local/data > pool/cvsup 858G 5.7G 853G 1% /usr/local/data/cvsup > pool/ftp 3.3T 2.5T 853G 75% /usr/local/data/ftp > pool/portsnap 853G 633M 853G 0% /usr/local/data/ > portsnap > pool/www 853G 90M 853G 0% /usr/local/data/www > > loader.conf: > vm.kmem_size="1G" > kern.maxfiles="65536" > kern.maxproc="20480" > net.inet.tcp.tcbhashsize="4096" > net.inet.tcp.hostcache.hashsize="1024" > vfs.zfs.arc_min="64M" > vfs.zfs.arc_max="768M" > vfs.zfs.prefetch_disable="1" > > I also tried to set vfs.zfs.zil_disable=1 but the problem still exist. > > I know there are few deadlock reports listed in the freebsd wiki. > Maybe we can trigger the root cause of the problem and fix it :) > > Regards > Thomas I recompiled my kernel with debug option. Maybe i have some useful data. I did most commands listed at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html . alltrace created a ridiculous long list. I added all output to a text file. http://www.bsdunix.ch/deadlock_2008-11-21.txt Just the ps output and a trace output as example: db> ps pid ppid pgrp uid state wmesg wchan cmd 21909 2551 21909 0 R+ CPU 0 sysctl 21865 21848 21831 1001 S select 0xffffff002a8164c0 rsync 21863 21844 21827 1001 S zfs 0xffffff00038a7cc8 rsync 21861 21847 21838 1001 S zfs 0xffffff00038a7cc8 rsync 21858 21845 21835 1001 S zfs 0xffffff00038a7cc8 rsync 21852 21841 21841 1001 S zfs 0xffffff00038a7cc8 perl 21850 21837 21837 1001 S zfs 0xffffff00038a7cc8 perl5.8.8 21848 21831 21831 1001 S wait 0xffffff0106a82430 sh 21847 21838 21838 1001 S wait 0xffffff001ec22860 sh 21846 21839 21839 0 S db->db_c 0xffffff0119b826b0 newsyslog 21845 21835 21835 1001 S wait 0xffffff003094f860 sh 21844 21827 21827 1001 S wait 0xffffff0138091000 sh 21841 21830 21841 1001 Ss wait 0xffffff0030936430 sh 21839 21832 21839 0 Ss wait 0xffffff01428a8860 sh 21838 21825 21838 1001 Ss wait 0xffffff0030935000 sh 21837 21829 21837 1001 Ss wait 0xffffff003094b430 sh 21835 21828 21835 1001 Ss wait 0xffffff01428a8430 sh 21832 1016 1016 0 S piperd 0xffffff003097fb20 cron 21831 21826 21831 1001 Ss wait 0xffffff01428a3430 sh 21830 1016 1016 0 S piperd 0xffffff01383f4858 cron 21829 1016 1016 0 S piperd 0xffffff0023dd42c8 cron 21828 1016 1016 0 S piperd 0xffffff003098b590 cron 21827 21824 21827 1001 Ss wait 0xffffff0030936000 sh 21826 1016 1016 0 S piperd 0xffffff01383f4000 cron 21825 1016 1016 0 S piperd 0xffffff000383e590 cron 21824 1016 1016 0 S piperd 0xffffff0023dd5858 cron 19454 19448 19448 0 S db->db_c 0xffffff0119b826b0 newsyslog 19448 19445 19448 0 Ss wait 0xffffff0106a80000 sh 19445 1016 1016 0 S piperd 0xffffff000383e858 cron 14894 14893 14894 1007 Ss db->db_c 0xffffff0119b826b0 cat 14893 14891 14891 1007 S select 0xffffff0018caa1c0 sshd 14891 997 14891 0 Ss sbwait 0xffffff0106a048b4 sshd 13493 13479 13479 1001 S zfs 0xffffff00038a7cc8 perl5.8.8 13490 13483 13483 0 S db->db_c 0xffffff0119b826b0 newsyslog 13483 13477 13483 0 Ss wait 0xffffff0138090860 sh 13479 13476 13479 1001 Ss wait 0xffffff0138296860 sh 13477 1016 1016 0 S piperd 0xffffff01383f62c8 cron 13476 1016 1016 0 S piperd 0xffffff0105ed82c8 cron 9316 9311 9311 0 S db->db_c 0xffffff0119b826b0 newsyslog 9311 9308 9311 0 Ss wait 0xffffff0138294430 sh 9308 1016 1016 0 S piperd 0xffffff000383cb20 cron 7843 943 943 0 S zfs 0xffffff00038a7cc8 rsync 7767 7764 7764 1001 S zfs 0xffffff00038a7cc8 perl 7764 7761 7764 1001 Ss wait 0xffffff001ec21860 sh 7761 1016 1016 0 S piperd 0xffffff0105ed8590 cron 7693 943 943 0 S zfs 0xffffff00038a7cc8 rsync 7490 943 943 0 S zfs 0xffffff00038a7cc8 rsync 7263 943 943 0 S zfs 0xffffff00038a7cc8 rsync 6758 943 943 0 S zfs 0xffffff00038a7cc8 rsync 6630 943 943 0 S zfs 0xffffff00038a7cc8 rsync 6582 943 943 0 S zfs 0xffffff00038a7cc8 rsync 6529 6524 6524 0 S db->db_c 0xffffff0119b826b0 newsyslog 6527 6520 6520 1001 S zfs 0xffffff00038a7cc8 perl5.8.8 6524 6518 6524 0 Ss wait 0xffffff001ec23860 sh 6520 6517 6520 1001 Ss wait 0xffffff001ec05430 sh 6518 1016 1016 0 S piperd 0xffffff0023dd5000 cron 6517 1016 1016 0 S piperd 0xffffff000383c590 cron 6478 943 943 0 S zfs 0xffffff00038a7cc8 rsync 6053 943 943 0 S zfs 0xffffff00038a7cc8 rsync 5788 5786 5786 0 S zfs 0xffffff00038a7cc8 vsftpd 5786 823 5786 0 Ss sbwait 0xffffff0138272b34 vsftpd 5785 5783 5783 0 S zfs 0xffffff00038a7cc8 vsftpd 5783 823 5783 0 Ss sbwait 0xffffff01382f1634 vsftpd 5766 5764 5764 0 S zfs 0xffffff00038a7cc8 vsftpd 5764 823 5764 0 Ss sbwait 0xffffff01381b63b4 vsftpd 5753 5751 5751 0 S zfs 0xffffff00038a7cc8 vsftpd 5751 823 5751 0 Ss sbwait 0xffffff01382703b4 vsftpd 5744 5742 5742 0 S zfs 0xffffff00038a7cc8 vsftpd 5742 823 5742 0 Ss sbwait 0xffffff01381b6134 vsftpd 5733 5731 5731 0 S zfs 0xffffff00038a7cc8 vsftpd 5731 823 5731 0 Ss sbwait 0xffffff0138142db4 vsftpd 5730 5728 5728 0 S zfs 0xffffff00038a7cc8 vsftpd 5728 823 5728 0 Ss sbwait 0xffffff01381b5634 vsftpd 5727 5724 5720 1001 S zfs 0xffffff00038a7cc8 rsync 5724 5720 5720 1001 S wait 0xffffff013808d000 sh 5720 5717 5720 1001 Ss wait 0xffffff0037e6b000 sh 5717 1016 1016 0 S piperd 0xffffff00038d2000 cron 5714 943 943 0 S zfs 0xffffff00038a7cc8 rsync 5713 5711 5711 0 S zfs 0xffffff00038a7cc8 vsftpd 5711 823 5711 0 Ss sbwait 0xffffff01381b7634 vsftpd 5709 5707 5707 0 S zfs 0xffffff00038a7cc8 vsftpd 5707 823 5707 0 Ss sbwait 0xffffff01380d2b34 vsftpd 5706 5704 5704 0 S zfs 0xffffff00038a7cc8 vsftpd 5704 823 5704 0 Ss sbwait 0xffffff01381413b4 vsftpd 5696 5694 5694 0 S zfs 0xffffff00038a7cc8 vsftpd 5694 823 5694 0 Ss sbwait 0xffffff0138142634 vsftpd 5669 943 943 0 S zfs 0xffffff00038a7cc8 rsync 5627 5625 5598 1007 S zio->io_ 0xffffff00372c3df8 sh 5626 5600 5598 1007 S piperd 0xffffff00038d2858 grep 5625 5600 5598 1007 S wait 0xffffff013808e430 sh 5610 5597 5610 1007 Ss piperd 0xffffff000383e2c8 sendmail 5600 5599 5598 1007 S wait 0xffffff0037fec860 sh 5599 5598 5598 1007 S wait 0xffffff0037ca2430 lockf 5598 5597 5598 1007 Ss wait 0xffffff0037e67000 sh 5597 1016 1016 0 S piperd 0xffffff0105ed7b20 cron 5596 5594 5594 0 S zfs 0xffffff00038a7cc8 vsftpd 5594 823 5594 0 Ss sbwait 0xffffff00376a93b4 vsftpd 5584 5582 5582 0 S zfs 0xffffff00038a7cc8 vsftpd 5582 823 5582 0 Ss sbwait 0xffffff0037f66634 vsftpd 5570 5568 5568 0 S zfs 0xffffff00038a7cc8 vsftpd 5568 823 5568 0 Ss sbwait 0xffffff0037f6eb34 vsftpd 5472 5470 5470 0 S zfs 0xffffff00038a7cc8 vsftpd 5470 823 5470 0 Ss sbwait 0xffffff0037ff6634 vsftpd 5459 5457 5457 0 S zfs 0xffffff00038a7cc8 vsftpd 5457 823 5457 0 Ss sbwait 0xffffff0037ff9db4 vsftpd 5442 5440 5440 0 S zfs 0xffffff00038a7cc8 vsftpd 5440 823 5440 0 Ss sbwait 0xffffff0037ec3b34 vsftpd 5399 5397 5397 0 S zfs 0xffffff00038a7cc8 vsftpd 5397 823 5397 0 Ss sbwait 0xffffff0037ec48b4 vsftpd 5375 5358 5358 0 S zfs 0xffffff00038a7cc8 vsftpd 5374 5372 5372 0 S zfs 0xffffff00038a7cc8 vsftpd 5372 823 5372 0 Ss sbwait 0xffffff0037eb73b4 vsftpd 5367 5362 5362 0 S zfs 0xffffff00038a7cc8 vsftpd 5366 5364 5364 1004 S zio->io_ 0xffffff0003993b28 vsftpd 5364 823 5364 0 Ss sbwait 0xffffff0037eb6634 vsftpd 5362 823 5362 0 Ss sbwait 0xffffff0037eb6db4 vsftpd 5358 823 5358 0 Ss sbwait 0xffffff0037eb8134 vsftpd 5356 5353 5353 1004 S zio->io_ 0xffffff00372c82b8 vsftpd 5353 823 5353 0 Ss sbwait 0xffffff0037e0e634 vsftpd 5349 5347 5347 1004 S db->db_c 0xffffff0121effb10 vsftpd 5347 823 5347 0 Ss sbwait 0xffffff0037dc8db4 vsftpd 5344 5342 5342 1004 S db->db_c 0xffffff0121effb10 vsftpd 5342 823 5342 0 Ss sbwait 0xffffff0037e0edb4 vsftpd 5328 5326 5326 1004 S zfs 0xffffff0007de0308 vsftpd 5326 823 5326 0 Ss sbwait 0xffffff0037e10134 vsftpd 5323 5321 5321 1004 S db->db_c 0xffffff0121effb10 vsftpd 5321 823 5321 0 Ss sbwait 0xffffff0037d2db34 vsftpd 5318 5301 5301 1004 S db->db_c 0xffffff0121effb10 vsftpd 5301 823 5301 0 Ss sbwait 0xffffff0037dc7db4 vsftpd 5297 5295 5295 1004 S db->db_c 0xffffff0121effb10 vsftpd 5295 823 5295 0 Ss sbwait 0xffffff0037cb68b4 vsftpd 5288 5286 5286 1004 S db->db_c 0xffffff0121effb10 vsftpd 5286 823 5286 0 Ss sbwait 0xffffff0037d2cb34 vsftpd 5285 5283 5283 1004 S db->db_c 0xffffff0121effb10 vsftpd 5283 823 5283 0 Ss sbwait 0xffffff0037d2c8b4 vsftpd 5258 5256 5256 1004 S db->db_c 0xffffff0121effb10 vsftpd 5256 823 5256 0 Ss sbwait 0xffffff0037d2c3b4 vsftpd 5251 5249 5249 1004 S zio->io_ 0xffffff0037368b28 vsftpd 5249 823 5249 0 Ss sbwait 0xffffff0037ce78b4 vsftpd 5246 5244 5244 1004 S db->db_c 0xffffff0121effb10 vsftpd 5244 823 5244 0 Ss sbwait 0xffffff0037cb43b4 vsftpd 5226 5224 5224 1004 S zfs 0xffffff0007de0308 vsftpd 5224 823 5224 0 Ss sbwait 0xffffff0037ce7634 vsftpd 5223 5221 5221 1004 S db->db_c 0xffffff0121effb10 vsftpd 5221 823 5221 0 Ss sbwait 0xffffff0037afadb4 vsftpd 5189 5187 5187 1004 S db->db_c 0xffffff0121effb10 vsftpd 5187 823 5187 0 Ss sbwait 0xffffff0037c98db4 vsftpd 5186 5184 5184 1004 S zfs 0xffffff0007de0308 vsftpd 5184 823 5184 0 Ss sbwait 0xffffff0037cd8134 vsftpd 5134 5132 5132 1004 S db->db_c 0xffffff0121effb10 vsftpd 5132 823 5132 0 Ss sbwait 0xffffff0037bc0b34 vsftpd 5131 5129 5129 1004 S zfs 0xffffff0007de0308 vsftpd 5129 823 5129 0 Ss sbwait 0xffffff0037bc73b4 vsftpd 5128 5126 5126 1004 S zio->io_ 0xffffff01103f7858 vsftpd 5126 823 5126 0 Ss sbwait 0xffffff0037bc0634 vsftpd 5092 5090 5090 1004 S db->db_c 0xffffff0121effb10 vsftpd 5090 823 5090 0 Ss sbwait 0xffffff0037bd4634 vsftpd 5073 5071 5071 1004 S zio->io_ 0xffffff0003a7a2b8 vsftpd 5071 823 5071 0 Ss sbwait 0xffffff0037af8b34 vsftpd 5066 5064 5064 1004 S db->db_c 0xffffff0121effb10 vsftpd 5064 823 5064 0 Ss sbwait 0xffffff0037aa2db4 vsftpd 5044 5042 5042 1004 S db->db_c 0xffffff0121effb10 vsftpd 5042 823 5042 0 Ss sbwait 0xffffff0037aa2134 vsftpd 5041 943 943 65534 S db->db_c 0xffffff012a1b1e90 rsync 5040 5038 5038 1004 S db->db_c 0xffffff0121effb10 vsftpd 5038 823 5038 0 Ss sbwait 0xffffff0037aa2634 vsftpd 5007 5005 5005 1004 S db->db_c 0xffffff0121effb10 vsftpd 5005 823 5005 0 Ss sbwait 0xffffff00379c28b4 vsftpd 5003 5001 5001 1004 S db->db_c 0xffffff0121effb10 vsftpd 5001 823 5001 0 Ss sbwait 0xffffff0037a20634 vsftpd 5000 4998 4998 1004 S db->db_c 0xffffff0121effb10 vsftpd 4998 823 4998 0 Ss sbwait 0xffffff0037a20db4 vsftpd 4983 4981 4981 1004 S db->db_c 0xffffff0121effb10 vsftpd 4981 823 4981 0 Ss sbwait 0xffffff003787d8b4 vsftpd 4979 4977 4977 1004 S db->db_c 0xffffff0121effb10 vsftpd 4977 823 4977 0 Ss sbwait 0xffffff00379f0db4 vsftpd 4973 4970 4973 1003 S zio->io_ 0xffffff0133e8d858 cvsup 4970 4967 4958 0 S wait 0xffffff00379eb860 su 4967 4966 4958 0 S wait 0xffffff0007c11430 sh 4966 4960 4958 0 S wait 0xffffff0018402000 lockf 4960 4958 4958 0 S wait 0xffffff003786a000 sh 4958 4956 4958 0 Ss wait 0xffffff003787b000 sh 4956 1016 1016 0 S piperd 0xffffff000383eb20 cron 4952 4950 4950 1004 S db->db_c 0xffffff0130177e90 vsftpd 4950 823 4950 0 Ss sbwait 0xffffff003787c134 vsftpd 4933 943 943 65534 S db->db_c 0xffffff012a1b1e90 rsync 4894 4892 4892 1004 S db->db_c 0xffffff0121effb10 vsftpd 4892 823 4892 0 Ss sbwait 0xffffff0037957db4 vsftpd 4882 4880 4880 1004 S zfsvfs-> 0xffffff00079b1800 vsftpd 4880 823 4880 0 Ss sbwait 0xffffff0123edb3b4 vsftpd 4861 4860 4799 0 S zio->io_ 0xffffff0133bb72b8 df 4860 4816 4799 0 S wait 0xffffff002393a000 sh 4818 4817 4799 0 S piperd 0xffffff0105ed62c8 mail 4817 4802 4799 0 S wait 0xffffff0037868430 sh 4816 4802 4799 0 S wait 0xffffff0037868000 sh 4802 4799 4799 0 S wait 0xffffff00631cb860 sh 4799 4796 4799 0 Ss wait 0xffffff003787a000 sh 4796 1016 1016 0 S piperd 0xffffff0105ed6858 cron 4770 4765 4765 0 S zio->io_ 0xffffff0003ae7858 newsyslog 4765 4762 4765 0 Ss wait 0xffffff00631b4860 sh 4762 1016 1016 0 S piperd 0xffffff000383c2c8 cron 4756 970 970 1002 S db->db_c 0xffffff0103cef250 cvsupd 4755 970 970 1002 S zio->io_ 0xffffff0133bad588 cvsupd 4754 970 970 1002 S db->db_c 0xffffff0103cef250 cvsupd 4753 970 970 1002 S db->db_c 0xffffff0103cef250 cvsupd 4740 970 970 1002 S zio->io_ 0xffffff0133dcfb28 cvsupd 4739 970 970 1002 S db->db_c 0xffffff0103cef250 cvsupd 4710 4708 4708 1004 S db->db_c 0xffffff0130177e90 vsftpd 4708 823 4708 0 Ss sbwait 0xffffff00376f8634 vsftpd 4676 4674 4674 1004 S db->db_c 0xffffff0121effb10 vsftpd 4674 823 4674 0 Ss sbwait 0xffffff00376f93b4 vsftpd 4673 4671 4671 1004 S db->db_c 0xffffff0121effb10 vsftpd 4671 823 4671 0 Ss sbwait 0xffffff0037653db4 vsftpd 4670 4668 4668 1004 S db->db_c 0xffffff0121effb10 vsftpd 4668 823 4668 0 Ss sbwait 0xffffff00376a7b34 vsftpd 4667 4665 4665 1004 S db->db_c 0xffffff0121effb10 vsftpd 4665 823 4665 0 Ss sbwait 0xffffff00376a9134 vsftpd 4664 4662 4662 1004 S db->db_c 0xffffff0121effb10 vsftpd 4662 823 4662 0 Ss sbwait 0xffffff0037651b34 vsftpd 4661 4659 4659 1004 S db->db_c 0xffffff0121effb10 vsftpd 4659 823 4659 0 Ss sbwait 0xffffff00376523b4 vsftpd 4647 4645 4645 1004 S db->db_c 0xffffff0121effb10 vsftpd 4645 823 4645 0 Ss sbwait 0xffffff00375e3634 vsftpd 4644 4642 4642 1004 S db->db_c 0xffffff0121effb10 vsftpd 4642 823 4642 0 Ss sbwait 0xffffff00375f4134 vsftpd 4640 4638 4638 1004 S db->db_c 0xffffff0121effb10 vsftpd 4638 823 4638 0 Ss sbwait 0xffffff00375f4db4 vsftpd 4637 4635 4635 1004 S zio->io_ 0xffffff0003a8ddf8 vsftpd 4635 823 4635 0 Ss sbwait 0xffffff0088393634 vsftpd 4588 4586 4586 1004 S db->db_c 0xffffff0121effb10 vsftpd 4586 823 4586 0 Ss sbwait 0xffffff0037560634 vsftpd 4567 4565 4565 1004 S db->db_c 0xffffff0121effb10 vsftpd 4565 823 4565 0 Ss sbwait 0xffffff003753cb34 vsftpd 4553 943 943 65534 S zio->io_ 0xffffff0133bf8b28 rsync 4528 4526 4526 1004 S db->db_c 0xffffff0121effb10 vsftpd 4526 823 4526 0 Ss sbwait 0xffffff0007c318b4 vsftpd 4514 4512 4512 1004 S db->db_c 0xffffff0121effb10 vsftpd 4512 823 4512 0 Ss sbwait 0xffffff00883958b4 vsftpd 4509 4505 4505 1004 S db->db_c 0xffffff0121effb10 vsftpd 4505 823 4505 0 Ss sbwait 0xffffff00883938b4 vsftpd 4499 4497 4497 1004 S db->db_c 0xffffff0121effb10 vsftpd 4497 823 4497 0 Ss sbwait 0xffffff00181f7134 vsftpd 4486 4484 4484 1004 S db->db_c 0xffffff0121effb10 vsftpd 4484 823 4484 0 Ss sbwait 0xffffff0007e78134 vsftpd 4472 970 970 1002 S zio->io_ 0xffffff0133c12b28 cvsupd 4421 4419 4419 1004 S db->db_c 0xffffff0121effb10 vsftpd 4419 823 4419 0 Ss sbwait 0xffffff0123edd634 vsftpd 4412 4410 4410 1004 S db->db_c 0xffffff0121effb10 vsftpd 4410 823 4410 0 Ss sbwait 0xffffff0123739134 vsftpd 4395 4393 4393 1004 S db->db_c 0xffffff0121effb10 vsftpd 4393 823 4393 0 Ss sbwait 0xffffff0018c49b34 vsftpd 4363 4358 4358 1004 S db->db_c 0xffffff0121effb10 vsftpd 4362 4360 4360 1004 S zio->io_ 0xffffff0133b282b8 vsftpd 4360 823 4360 0 Ss sbwait 0xffffff0123739634 vsftpd 4358 823 4358 0 Ss sbwait 0xffffff014e6b3634 vsftpd 4354 4341 4341 1004 S zio->io_ 0xffffff01104612b8 vsftpd 4341 823 4341 0 Ss sbwait 0xffffff0123738134 vsftpd 4337 4335 4335 1004 S zio->io_ 0xffffff0133ae0858 vsftpd 4335 823 4335 0 Ss sbwait 0xffffff00181f63b4 vsftpd 4322 943 943 65534 S zio->io_ 0xffffff003700b588 rsync 4304 970 970 1002 SL zio->io_ 0xffffff011040d2b8 cvsupd 4298 4296 4296 1004 S zio->io_ 0xffffff01103b6df8 vsftpd 4296 823 4296 0 Ss sbwait 0xffffff00181f6134 vsftpd 2551 2549 2551 0 Ss+ pause 0xffffff0007c134d0 csh 2549 997 2549 0 Ss select 0xffffff00079a0dc0 sshd 2470 2469 2466 1001 S+ zfs 0xffffff0139a87a58 rsync 2469 2467 2466 1001 S+ zio->io_ 0xffffff00372c7df8 rsync 2467 2466 2466 1001 S+ wait 0xffffff0018403430 sh 2466 2465 2466 1001 S+ wait 0xffffff0018403000 sh 2465 1206 2465 0 S+ wait 0xffffff00038b2430 su 1206 1190 1206 0 Ss+ pause 0xffffff0018402900 csh 1190 997 1190 0 Ss select 0xffffff0023914240 sshd 1089 1 1089 0 Ss+ tty inpu 0xffffff00036310b8 getty 1088 1 1088 0 Ss+ tty inpu 0xffffff000372d8b8 getty 1087 1 1087 0 Ss+ tty inpu 0xffffff00037318b8 getty 1086 1 1086 0 Ss+ tty inpu 0xffffff000373bcb8 getty 1085 1 1085 0 Ss+ tty inpu 0xffffff000373b8b8 getty 1084 1 1084 0 Ss+ tty inpu 0xffffff000373c8b8 getty 1083 1 1083 0 Ss+ tty inpu 0xffffff000373c4b8 getty 1082 1 1082 0 Ss+ tty inpu 0xffffff000373a8b8 getty 1081 1 1081 0 Ss+ tty inpu 0xffffff000373a4b8 getty 1047 1 1047 0 Ss select 0xffffff0007ac0e40 inetd 1016 1 1016 0 Ss nanslp 0xffffffff808423e8 cron 1010 1 1010 25 Ss pause 0xffffff000383d4d0 sendmail 1006 1 1006 0 Ss select 0xffffff000741d240 sendmail 997 1 997 0 Ss select 0xffffff0007ac0540 sshd 970 1 970 1002 Ss select 0xffffff00038abbc0 cvsupd 949 1 948 80 S zio->io_ 0xffffff0133e0fb28 lighttpd 943 1 943 0 Ss select 0xffffff0003951640 rsync 899 1 899 0 Ss select 0xffffff0007a3d4c0 ntpd 841 1 840 0 S select 0xffffff000741c340 snmpd 823 1 823 0 Ss accept 0xffffff0007c2aa5e vsftpd 703 1 703 0 Ss select 0xffffff0007ac1140 syslogd 534 1 534 0 Ss select 0xffffff00079890c0 devd 171 0 0 0 SL tq->tq_d 0xffffff0007be5600 [zil_clean] 170 0 0 0 SL tq->tq_d 0xffffff00039232a0 [zil_clean] 169 0 0 0 SL tq->tq_d 0xffffff0003923180 [zil_clean] 168 0 0 0 SL tq->tq_d 0xffffff0003923060 [zil_clean] 167 0 0 0 SL tq->tq_d 0xffffff000390e4e0 [zil_clean] 165 0 0 0 SL tx->tx_q 0xffffff0003b6e668 [txg_thread_enter] 164 0 0 0 SL tx->tx_c 0xffffff00039124b0 [txg_thread_enter] 163 0 0 0 SL vgeom:io 0xffffff0003bc5110 [vdev:worker da7] 162 0 0 0 SL vgeom:io 0xffffff000394f490 [vdev:worker da6] 161 0 0 0 SL vgeom:io 0xffffff000394f510 [vdev:worker da5] 160 0 0 0 SL vgeom:io 0xffffff000394f690 [vdev:worker da4] 159 0 0 0 SL vgeom:io 0xffffff000394f710 [vdev:worker da3] 158 0 0 0 SL vgeom:io 0xffffff000394f810 [vdev:worker da2] 157 0 0 0 SL vgeom:io 0xffffff000394f910 [vdev:worker da1] 156 0 0 0 SL tq->tq_d 0xffffff000390e600 [spa_zio] 155 0 0 0 SL tq->tq_d 0xffffff000390e720 [spa_zio] 154 0 0 0 SL tq->tq_d 0xffffff000390e840 [spa_zio] 153 0 0 0 SL tq->tq_d 0xffffff000390e960 [spa_zio] 152 0 0 0 SL tq->tq_d 0xffffff000390f4e0 [spa_zio] 151 0 0 0 SL tq->tq_d 0xffffff000390f180 [spa_zio] 150 0 0 0 SL zfsvfs-> 0xffffff00079b11e0 [spa_zio] 149 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 148 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 147 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 146 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 145 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 144 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 143 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 142 0 0 0 SL tq->tq_d 0xffffff000390eba0 [spa_zio] 141 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 140 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 139 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 138 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 137 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 136 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 135 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 134 0 0 0 SL tq->tq_d 0xffffff000390ecc0 [spa_zio] 133 0 0 0 SL tq->tq_d 0xffffff000390ede0 [spa_zio] 132 0 0 0 SL tq->tq_d 0xffffff000390f2a0 [spa_zio] 131 0 0 0 SL tq->tq_d 0xffffff000390f3c0 [spa_zio] 97 0 0 0 SL l2arc_fe 0xffffffff80d134e0 [l2arc_feed_thread] 96 0 0 0 SL arc_recl 0xffffffff80d0af00 [arc_reclaim_thread] 93 0 0 0 SL tq->tq_d 0xffffff000390f060 [system_taskq] 92 0 0 0 SL tq->tq_d 0xffffff000390f060 [system_taskq] 24 0 0 0 SL sdflush 0xffffffff80a130b8 [softdepflush] 23 0 0 0 SL zio->io_ 0xffffff0133c0e588 [syncer] 22 0 0 0 SL vlruwt 0xffffff000365d000 [vnlru] 21 0 0 0 SL psleep 0xffffffff80a02fdc [bufdaemon] 9 0 0 0 SL pgzero 0xffffffff80a14a2c [pagezero] 8 0 0 0 SL psleep 0xffffffff80a13dc8 [vmdaemon] 7 0 0 0 SL psleep 0xffffffff80a13d8c [pagedaemon] 6 0 0 0 SL waiting_ 0xffffffff80a062a8 [sctp_iterator] 20 0 0 0 SL usbevt 0xffffff00015a9420 [usb4] 19 0 0 0 SL usbevt 0xfffffffe4046c420 [usb3] 18 0 0 0 SL usbevt 0xfffffffe4046a420 [usb2] 17 0 0 0 SL usbevt 0xfffffffe40468420 [usb1] 16 0 0 0 SL usbtsk 0xffffffff8083e0e8 [usbtask- dr] 15 0 0 0 SL usbtsk 0xffffffff8083e0c0 [usbtask- hc] 14 0 0 0 SL usbevt 0xfffffffe40466420 [usb0] 5 0 0 0 SL ccb_scan 0xffffffff80822e60 [xpt_thrd] 13 0 0 0 SL - 0xffffffff808420c4 [yarrow] 4 0 0 0 SL - 0xffffffff8083e848 [g_down] 3 0 0 0 SL - 0xffffffff8083e840 [g_up] 2 0 0 0 SL - 0xffffffff8083e830 [g_event] 12 0 0 0 RL (threaded) intr 100040 I [swi0: uart uart] 100039 I [irq1: atkbd0] 100038 I [irq20: atapci1] 100037 I [irq14: ata0] 100032 I [irq22: uhci1 uhci3] 100028 I [irq23: uhci0 uhci+] 100025 I [irq18: arcmsr0] 100024 I [irq9: acpi0] 100022 I [swi5: +] 100021 I [swi2: cambio] 100015 I [swi6: task queue] 100014 I [swi6: Giant taskq] 100008 I [swi1: net] 100007 I [swi4: clock] 100006 Run CPU 1 [swi4: clock] 100005 I [swi3: vm] 11 0 0 0 RL (threaded) idle 100004 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xffffff0001442860 [init] 10 0 0 0 SL audit_wo 0xffffffff80a124f0 [audit] 0 0 0 0 SLs (threaded) kernel 100027 D - 0xffffff000159f280 [em1 taskq] 100026 D - 0xffffff00015a0000 [em0 taskq] 100023 D - 0xffffff000152b180 [thread taskq] 100019 D - 0xffffff000152b900 [acpi_task_2] 100018 D - 0xffffff000152b900 [acpi_task_1] 100017 D - 0xffffff000152b900 [acpi_task_0] 100016 D - 0xffffff000152b980 [kqueue taskq] 100012 D - 0xffffff0001455080 [firmware taskq] 100000 D sched 0xffffffff8083e940 [swapper] db> trace 4509 Tracing pid 4509 tid 100186 td 0xffffff0063ba4720 sched_switch() at sched_switch+0x180 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a dbuf_read() at dbuf_read+0x33b dmu_buf_hold() at dmu_buf_hold+0xcc zap_lockdir() at zap_lockdir+0x53 zap_lookup_norm() at zap_lookup_norm+0x45 zap_lookup() at zap_lookup+0x2e zfs_dirent_lock() at zfs_dirent_lock+0x501 zfs_dirlook() at zfs_dirlook+0x69 zfs_lookup() at zfs_lookup+0x1f4 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x81 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xaf vfs_cache_lookup() at vfs_cache_lookup+0xf0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xb7 lookup() at lookup+0x516 namei() at namei+0x53d vn_open_cred() at vn_open_cred+0x1a7 kern_openat() at kern_openat+0x169 syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xab --- syscall (5, FreeBSD ELF64, open), rip = 0x800a4dd0c, rsp = 0x7fffffffe988, rbp = 0xfa0 --- I'm not a kernel debug expert. Kust let me know if you need additional information. Regards Thomas From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 09:12:27 2008 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 B7867106564A for ; Fri, 21 Nov 2008 09:12:27 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED218FC14 for ; Fri, 21 Nov 2008 09:12:27 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so611177fgb.35 for ; Fri, 21 Nov 2008 01:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-pgp-agent:x-mailer; bh=1fJD2rJSnyKLO4WmpWf/CS6X9Iy9i4i+0gu33Y+8r8A=; b=DHphQ4w++6quDfJ4yt6OIR5nHxYy/1WqBYQ3zHxedj1fEDpT5CRpD0xWK3DbGQb2Tj 9vImyOZ36k/5MSHiKH+G600cIP/CCZosjxCNuJFarpGoANC1HbDhUyPdUHndQimsTgHK CcLO/OegEcdmDj1TTsRmoncHhnUEtPNszd1bM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-pgp-agent:x-mailer; b=pm/JvlgTkwWVapEP51XqOpyh/CdvfbWr3QjadsLyRqSfwL11r1HswN9Lb6NjS8vMxL kN144Tsufr1+loSXnXcSdqmXQ5NSjaR37adSTw7MUOD/mbhK526HEIV2eGLGEUVIR0dk WOlFeBwlNAO0RSxuBbeW07nbP6D1TsVx376dA= Received: by 10.181.144.10 with SMTP id w10mr100483bkn.30.1227256803352; Fri, 21 Nov 2008 00:40:03 -0800 (PST) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id p9sm2762118fkb.5.2008.11.21.00.39.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Nov 2008 00:40:00 -0800 (PST) Message-Id: From: Nikolay Denev To: Thomas Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 10:39:58 +0200 References: X-Pgp-Agent: GPGMail d53 (v53, Leopard) X-Mailer: Apple Mail (2.929.2) Cc: current@freebsd.org Subject: Re: deadlock with 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: Fri, 21 Nov 2008 09:12:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov, 2008, at 02:01 , Thomas Vogt wrote: > Hello > > I encounter a deadlock while running a few rsync processes mirroring > remote data to my local zfs pool. After a few hours my system is > starting more and more vsftpd sessions without closing any inactive > ftp sessions. I can't kill any rsync and vsftpd processes with "kill > -9". Even shutdown -r now does not work. > > I got a few hunderts vsftpd processes like this > > 61346 root 1 57 0 7880K 1692K zfs 1 0:00 0.00% > vsftpd > 61481 root 1 68 0 7880K 1696K zfs 1 0:00 0.00% > vsftpd > 61354 root 1 65 0 7880K 1692K zfs 1 0:00 0.00% > vsftpd > 61480 root 1 68 0 7880K 1696K zfs 0 0:00 0.00% > vsftpd > 61600 root 1 69 0 7880K 1704K zfs 1 0:00 0.00% > vsftpd > 61599 root 1 68 0 7880K 1704K zfs 1 0:00 0.00% > vsftpd > > Right now i'm building a debug kernel. Whats the best way to get > usefull information from this deadlock? The system itself is not > crashing and response well to ssh and i also have a serial console. > > The system is running 8.0-CURRENT Thu Nov 20 00:15:46 UTC 2008 > (64bit) with zpool version 13. I use zfs only as data pool. The base > system is running on ufs2: > > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 496M 220M 236M 48% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/da0s1g 169G 15G 141G 9% /disk1 > /dev/da0s1f 3.9G 17M 3.5G 0% /tmp > /dev/da0s1e 29G 3.7G 23G 14% /usr > /dev/da0s1d 19G 7.1G 11G 40% /var > pool 853G 0B 853G 0% /usr/local/data > pool/cvsup 858G 5.7G 853G 1% /usr/local/data/cvsup > pool/ftp 3.3T 2.5T 853G 75% /usr/local/data/ftp > pool/portsnap 853G 633M 853G 0% /usr/local/data/ > portsnap > pool/www 853G 90M 853G 0% /usr/local/data/www > > loader.conf: > vm.kmem_size="1G" > kern.maxfiles="65536" > kern.maxproc="20480" > net.inet.tcp.tcbhashsize="4096" > net.inet.tcp.hostcache.hashsize="1024" > vfs.zfs.arc_min="64M" > vfs.zfs.arc_max="768M" > vfs.zfs.prefetch_disable="1" > > I also tried to set vfs.zfs.zil_disable=1 but the problem still exist. > > I know there are few deadlock reports listed in the freebsd wiki. > Maybe we can trigger the root cause of the problem and fix it :) > > Regards > Thomas > Hi Thomas, from my recent experience it seems that tuning vm.kmem_size is no longer required, maybe you can try without it. - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkkmc94ACgkQHNAJ/fLbfrlQNwCfYOgJoxqPMUeQ0JNsuES1Gd7a T8QAnjf/bAj3LIUDjZlRIoFHkNl9l62q =hVLJ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 10:55:47 2008 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 A7AA41065673; Fri, 21 Nov 2008 10:55:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 812548FC08; Fri, 21 Nov 2008 10:55:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mALAtiIr007061; Fri, 21 Nov 2008 05:55:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mALAti95021984; Fri, 21 Nov 2008 05:55:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2153573039; Fri, 21 Nov 2008 05:55:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121105544.2153573039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 05:55:44 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 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: Fri, 21 Nov 2008 10:55:47 -0000 TB --- 2008-11-21 09:16:21 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 09:16:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-11-21 09:16:21 - cleaning the object tree TB --- 2008-11-21 09:16:41 - cvsupping the source tree TB --- 2008-11-21 09:16:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-11-21 09:16:47 - building world TB --- 2008-11-21 09:16:47 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 09:16:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 09:16:47 - TARGET=powerpc TB --- 2008-11-21 09:16:47 - TARGET_ARCH=powerpc TB --- 2008-11-21 09:16:47 - TZ=UTC TB --- 2008-11-21 09:16:47 - __MAKE_CONF=/dev/null TB --- 2008-11-21 09:16:47 - cd /src TB --- 2008-11-21 09:16:47 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 09:16:49 UTC 2008 >>> 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 21 10:40:28 UTC 2008 TB --- 2008-11-21 10:40:28 - generating LINT kernel config TB --- 2008-11-21 10:40:28 - cd /src/sys/powerpc/conf TB --- 2008-11-21 10:40:28 - /usr/bin/make -B LINT TB --- 2008-11-21 10:40:28 - building LINT kernel TB --- 2008-11-21 10:40:28 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 10:40:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 10:40:28 - TARGET=powerpc TB --- 2008-11-21 10:40:28 - TARGET_ARCH=powerpc TB --- 2008-11-21 10:40:28 - TZ=UTC TB --- 2008-11-21 10:40:28 - __MAKE_CONF=/dev/null TB --- 2008-11-21 10:40:28 - cd /src TB --- 2008-11-21 10:40:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 10:40:29 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 -ffreestanding -fstack-protector -Werror vers.c linking kernel hwpmc_mod.o(.text+0x3328): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 10:55:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 10:55:43 - ERROR: failed to build lint kernel TB --- 2008-11-21 10:55:43 - 4764.12 user 413.78 system 5962.09 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 10:58:11 2008 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 3C9A31065672 for ; Fri, 21 Nov 2008 10:58:11 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id BED198FC0C for ; Fri, 21 Nov 2008 10:58:10 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id B08335D58; Fri, 21 Nov 2008 11:58:09 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yf87IfgDmsph; Fri, 21 Nov 2008 11:58:06 +0100 (CET) Received: from 192.168.1.101.local.home (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 1CDB55D56; Fri, 21 Nov 2008 11:58:06 +0100 (CET) Message-Id: From: Thomas Vogt To: Nikolay Denev In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 11:58:05 +0100 References: X-Mailer: Apple Mail (2.929.2) Cc: current@freebsd.org Subject: Re: deadlock with 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: Fri, 21 Nov 2008 10:58:11 -0000 Thomas Vogt Am 21.11.2008 um 09:39 schrieb Nikolay Denev: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 21 Nov, 2008, at 02:01 , Thomas Vogt wrote: > >> Hello >> >> I encounter a deadlock while running a few rsync processes >> mirroring remote data to my local zfs pool. After a few hours my >> system is starting more and more vsftpd sessions without closing >> any inactive ftp sessions. I can't kill any rsync and vsftpd >> processes with "kill -9". Even shutdown -r now does not work. >> >> I got a few hunderts vsftpd processes like this >> >> 61346 root 1 57 0 7880K 1692K zfs 1 0:00 >> 0.00% vsftpd >> 61481 root 1 68 0 7880K 1696K zfs 1 0:00 >> 0.00% vsftpd >> 61354 root 1 65 0 7880K 1692K zfs 1 0:00 >> 0.00% vsftpd >> 61480 root 1 68 0 7880K 1696K zfs 0 0:00 >> 0.00% vsftpd >> 61600 root 1 69 0 7880K 1704K zfs 1 0:00 >> 0.00% vsftpd >> 61599 root 1 68 0 7880K 1704K zfs 1 0:00 >> 0.00% vsftpd >> >> Right now i'm building a debug kernel. Whats the best way to get >> usefull information from this deadlock? The system itself is not >> crashing and response well to ssh and i also have a serial console. >> >> The system is running 8.0-CURRENT Thu Nov 20 00:15:46 UTC 2008 >> (64bit) with zpool version 13. I use zfs only as data pool. The >> base system is running on ufs2: >> >> Filesystem Size Used Avail Capacity Mounted on >> /dev/da0s1a 496M 220M 236M 48% / >> devfs 1.0K 1.0K 0B 100% /dev >> /dev/da0s1g 169G 15G 141G 9% /disk1 >> /dev/da0s1f 3.9G 17M 3.5G 0% /tmp >> /dev/da0s1e 29G 3.7G 23G 14% /usr >> /dev/da0s1d 19G 7.1G 11G 40% /var >> pool 853G 0B 853G 0% /usr/local/data >> pool/cvsup 858G 5.7G 853G 1% /usr/local/data/cvsup >> pool/ftp 3.3T 2.5T 853G 75% /usr/local/data/ftp >> pool/portsnap 853G 633M 853G 0% /usr/local/data/ >> portsnap >> pool/www 853G 90M 853G 0% /usr/local/data/www >> >> loader.conf: >> vm.kmem_size="1G" >> kern.maxfiles="65536" >> kern.maxproc="20480" >> net.inet.tcp.tcbhashsize="4096" >> net.inet.tcp.hostcache.hashsize="1024" >> vfs.zfs.arc_min="64M" >> vfs.zfs.arc_max="768M" >> vfs.zfs.prefetch_disable="1" >> >> I also tried to set vfs.zfs.zil_disable=1 but the problem still >> exist. >> >> I know there are few deadlock reports listed in the freebsd wiki. >> Maybe we can trigger the root cause of the problem and fix it :) >> >> Regards >> Thomas >> > > Hi Thomas, > > from my recent experience it seems that tuning vm.kmem_size is no > longer required, > maybe you can try without it. Sure, i rebooted the system without vm.kmem_size. It takes a a few hours until i got deadlocks. Regards Thomas From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 11:18:47 2008 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 0CADB106564A; Fri, 21 Nov 2008 11:18:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D8F7F8FC08; Fri, 21 Nov 2008 11:18:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mALBIhaa065307; Fri, 21 Nov 2008 06:18:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mALBIhOH040195; Fri, 21 Nov 2008 06:18:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3BE0973039; Fri, 21 Nov 2008 06:18:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121111843.3BE0973039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 06:18:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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, 21 Nov 2008 11:18:47 -0000 TB --- 2008-11-21 09:08:26 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 09:08:26 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-11-21 09:08:26 - cleaning the object tree TB --- 2008-11-21 09:08:47 - cvsupping the source tree TB --- 2008-11-21 09:08:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-11-21 09:08:59 - building world TB --- 2008-11-21 09:08:59 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 09:08:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 09:08:59 - TARGET=ia64 TB --- 2008-11-21 09:08:59 - TARGET_ARCH=ia64 TB --- 2008-11-21 09:08:59 - TZ=UTC TB --- 2008-11-21 09:08:59 - __MAKE_CONF=/dev/null TB --- 2008-11-21 09:08:59 - cd /src TB --- 2008-11-21 09:08:59 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 09:09:02 UTC 2008 >>> 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 21 10:56:52 UTC 2008 TB --- 2008-11-21 10:56:52 - generating LINT kernel config TB --- 2008-11-21 10:56:52 - cd /src/sys/ia64/conf TB --- 2008-11-21 10:56:52 - /usr/bin/make -B LINT TB --- 2008-11-21 10:56:52 - building LINT kernel TB --- 2008-11-21 10:56:52 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 10:56:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 10:56:52 - TARGET=ia64 TB --- 2008-11-21 10:56:52 - TARGET_ARCH=ia64 TB --- 2008-11-21 10:56:52 - TZ=UTC TB --- 2008-11-21 10:56:52 - __MAKE_CONF=/dev/null TB --- 2008-11-21 10:56:52 - cd /src TB --- 2008-11-21 10:56:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 10:56:52 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0xa2f2): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 11:18:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 11:18:43 - ERROR: failed to build lint kernel TB --- 2008-11-21 11:18:43 - 6415.73 user 441.68 system 7816.93 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 11:40:15 2008 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 54D7A106564A for ; Fri, 21 Nov 2008 11:40:15 +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 E21B58FC13 for ; Fri, 21 Nov 2008 11:40:14 +0000 (UTC) (envelope-from gavin@FreeBSD.org) 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 mALBeBbr013667; Fri, 21 Nov 2008 11:40:11 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1L3UMt-0007Fp-5z; Fri, 21 Nov 2008 11:40:11 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id mALBe966041000; Fri, 21 Nov 2008 11:40:09 GMT (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id mALBe95Z040999; Fri, 21 Nov 2008 11:40:09 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Andre Guibert de Bruet In-Reply-To: <0F25B579-1DF2-4A5C-82AE-C5C42120F3AB@siliconlandmark.com> References: <99CD11CA-9AEB-4260-B7C9-44E9B82EA34A@siliconlandmark.com> <1226076247.69416.12.camel@buffy.york.ac.uk> <0F25B579-1DF2-4A5C-82AE-C5C42120F3AB@siliconlandmark.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 21 Nov 2008 11:40:08 +0000 Message-Id: <1227267608.40570.4.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: current@FreeBSD.org Subject: Re: [PATCH] Quirk for I-Tuner Networks USBLCD4X20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 11:40:15 -0000 On Tue, 2008-11-11 at 17:00 -0500, Andre Guibert de Bruet wrote: > On Nov 7, 2008, at 11:44 AM, Gavin Atkinson wrote: > > On Fri, 2008-10-31 at 11:49 -0400, Andre Guibert de Bruet wrote: > >> > >> The attached patch provides a quirk entry for the I-Tuner Networks' > >> External USB 4x20 LCD device, so that it does not get attached to by > >> uhid. I have successfully run lcdproc CVS HEAD with this device on > >> 7.1- > >> PRERELEASE (If anyone is interested in the configs, please email me > >> off-list). > >> > >> Could this get committed upon review? > > > > You're probably best off putting this into a PR, so that it doesn't > > get > > lost. > > Filed as `usb/128803' - http://www.freebsd.org/cgi/query-pr.cgi?pr=128803 > > Would you happen to know off-hand who is responsible for the > maintainership of the USB stack / device quirks (Besides freebsd-usb@freebsd.org > ... :) )? The USB stack has no overall maintainer, but there are several committers on that list who may well pick up the patch and commit it. We're currently running with two USB stacks in parallel, however, and I'm not exactly sure how they are handling this. It may be that your patch takes a little while to be committed, while the new stack settles in. Gavin From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 12:07:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3BA31065672 for ; Fri, 21 Nov 2008 12:07:41 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id AD8D48FC29 for ; Fri, 21 Nov 2008 12:07:41 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so397540ana.13 for ; Fri, 21 Nov 2008 04:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Amdg8weyW7bVPODCbdCrnCuM/RcEZ+IgxCTqkMMCHN8=; b=ATSt49yLo00dK2Zz3d6haSPflPT4IOUU7sJaCQghImtFb6Rq+kT68pW0JxJV5JrOVU YzmWSV2rFysAbPXwGHBEOS4J3anGlX27qtfqJlBE5pblQ24k4mBTTaXOqN8V2wHdPI4h fPcbtZSJeeNkHfCzTR53tjvzhYOoxCk1O/rkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LsqmV6cvijgEFpjrpO0m6h9JQ8otZRdnin/+EDyx6+sniE9z9Mkb+/DQ4OvfxE7nCt C2DyBvPnMt/swfX1Hv5nU5ogJpsLv7RDqkJpn33ejX0y5o6zloMHjZsgpX1FKf+D13sm eKuXIj3ShLuGQ8JGIslc99uinELtWeM7ZCYr8= Received: by 10.231.10.205 with SMTP id q13mr3757ibq.16.1227269260624; Fri, 21 Nov 2008 04:07:40 -0800 (PST) Received: by 10.231.15.70 with HTTP; Fri, 21 Nov 2008 04:07:40 -0800 (PST) Message-ID: <3a142e750811210407i7dcf74eh4e0cf974d1179c8a@mail.gmail.com> Date: Fri, 21 Nov 2008 13:07:40 +0100 From: "Paul B. Mahol" To: "=?ISO-8859-1?Q?Bj=C3=B6rn_Jonare?=" In-Reply-To: <20081121020459.GB1397@hel.niflheim.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20081121020459.GB1397@hel.niflheim.se> Cc: freebsd-current@freebsd.org Subject: Re: GENERIC + ral X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 12:07:42 -0000 On 11/21/08, Bj=C3=B6rn Jonare wrote: > Hello! > > Running CURRENT as of today I tried to get my Linksys WMP54G up and > working. After some trouble with the console spewing error messages > that the firmware couldn't be loaded I read the manpage for ral(4). > > Looking through the config for GENERIC I saw that there was no line > "device ralfw". After adding that line and rebooting everything went > fine. > > However, shouldn't ralfw be present in GENERIC? It won't build as a > module and "device ral" is sort of useless if the system can't load > card firmware. Or am I simply missing something? # cd /sys/modules/ralfw/ && make && make install doesn't work? From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 12:31:42 2008 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 035621065673; Fri, 21 Nov 2008 12:31:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id CFDD28FC19; Fri, 21 Nov 2008 12:31:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mALCVcBq070622; Fri, 21 Nov 2008 07:31:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mALCVc0t082992; Fri, 21 Nov 2008 07:31:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B208373039; Fri, 21 Nov 2008 07:31:38 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121123138.B208373039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 07:31:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2008 12:31:42 -0000 TB --- 2008-11-21 10:55:44 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 10:55:44 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-21 10:55:44 - cleaning the object tree TB --- 2008-11-21 10:56:11 - cvsupping the source tree TB --- 2008-11-21 10:56:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-21 10:56:18 - building world TB --- 2008-11-21 10:56:18 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 10:56:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 10:56:18 - TARGET=sparc64 TB --- 2008-11-21 10:56:18 - TARGET_ARCH=sparc64 TB --- 2008-11-21 10:56:18 - TZ=UTC TB --- 2008-11-21 10:56:18 - __MAKE_CONF=/dev/null TB --- 2008-11-21 10:56:18 - cd /src TB --- 2008-11-21 10:56:18 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 10:56:20 UTC 2008 >>> 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 21 12:15:25 UTC 2008 TB --- 2008-11-21 12:15:25 - generating LINT kernel config TB --- 2008-11-21 12:15:25 - cd /src/sys/sparc64/conf TB --- 2008-11-21 12:15:25 - /usr/bin/make -B LINT TB --- 2008-11-21 12:15:25 - building LINT kernel TB --- 2008-11-21 12:15:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 12:15:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 12:15:25 - TARGET=sparc64 TB --- 2008-11-21 12:15:25 - TARGET_ARCH=sparc64 TB --- 2008-11-21 12:15:25 - TZ=UTC TB --- 2008-11-21 12:15:25 - __MAKE_CONF=/dev/null TB --- 2008-11-21 12:15:25 - cd /src TB --- 2008-11-21 12:15:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 12:15:25 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 12:31:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 12:31:38 - ERROR: failed to build lint kernel TB --- 2008-11-21 12:31:38 - 4574.70 user 413.04 system 5754.28 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 14:52:54 2008 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 92F071065670 for ; Fri, 21 Nov 2008 14:52:54 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 221698FC1A for ; Fri, 21 Nov 2008 14:52:54 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id ABAE75D7E; Fri, 21 Nov 2008 15:52:52 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ub0eFkHQWCTF; Fri, 21 Nov 2008 15:52:48 +0100 (CET) Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id F2F735D68; Fri, 21 Nov 2008 15:52:47 +0100 (CET) Message-ID: <4926CB3F.8010500@bsdunix.ch> Date: Fri, 21 Nov 2008 15:52:47 +0100 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: Nikolay Denev References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: deadlock with 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: Fri, 21 Nov 2008 14:52:54 -0000 Hello > Am 21.11.2008 um 09:39 schrieb Nikolay Denev: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On 21 Nov, 2008, at 02:01 , Thomas Vogt wrote: >> >>> Hello >>> >>> I encounter a deadlock while running a few rsync processes mirroring >>> remote data to my local zfs pool. After a few hours my system is >>> starting more and more vsftpd sessions without closing any inactive >>> ftp sessions. I can't kill any rsync and vsftpd processes with "kill >>> -9". Even shutdown -r now does not work. >>> >>> I got a few hunderts vsftpd processes like this >>> >>> 61346 root 1 57 0 7880K 1692K zfs 1 0:00 0.00% >>> vsftpd >>> 61481 root 1 68 0 7880K 1696K zfs 1 0:00 0.00% >>> vsftpd >>> 61354 root 1 65 0 7880K 1692K zfs 1 0:00 0.00% >>> vsftpd >>> 61480 root 1 68 0 7880K 1696K zfs 0 0:00 0.00% >>> vsftpd >>> 61600 root 1 69 0 7880K 1704K zfs 1 0:00 0.00% >>> vsftpd >>> 61599 root 1 68 0 7880K 1704K zfs 1 0:00 0.00% >>> vsftpd >>> >>> Right now i'm building a debug kernel. Whats the best way to get >>> usefull information from this deadlock? The system itself is not >>> crashing and response well to ssh and i also have a serial console. >>> >>> The system is running 8.0-CURRENT Thu Nov 20 00:15:46 UTC 2008 >>> (64bit) with zpool version 13. I use zfs only as data pool. The base >>> system is running on ufs2: >>> >>> Filesystem Size Used Avail Capacity Mounted on >>> /dev/da0s1a 496M 220M 236M 48% / >>> devfs 1.0K 1.0K 0B 100% /dev >>> /dev/da0s1g 169G 15G 141G 9% /disk1 >>> /dev/da0s1f 3.9G 17M 3.5G 0% /tmp >>> /dev/da0s1e 29G 3.7G 23G 14% /usr >>> /dev/da0s1d 19G 7.1G 11G 40% /var >>> pool 853G 0B 853G 0% /usr/local/data >>> pool/cvsup 858G 5.7G 853G 1% /usr/local/data/cvsup >>> pool/ftp 3.3T 2.5T 853G 75% /usr/local/data/ftp >>> pool/portsnap 853G 633M 853G 0% /usr/local/data/portsnap >>> pool/www 853G 90M 853G 0% /usr/local/data/www >>> >>> loader.conf: >>> vm.kmem_size="1G" >>> kern.maxfiles="65536" >>> kern.maxproc="20480" >>> net.inet.tcp.tcbhashsize="4096" >>> net.inet.tcp.hostcache.hashsize="1024" >>> vfs.zfs.arc_min="64M" >>> vfs.zfs.arc_max="768M" >>> vfs.zfs.prefetch_disable="1" >>> >>> I also tried to set vfs.zfs.zil_disable=1 but the problem still exist. >>> >>> I know there are few deadlock reports listed in the freebsd wiki. >>> Maybe we can trigger the root cause of the problem and fix it :) >>> >>> Regards >>> Thomas >>> >> >> Hi Thomas, >> >> from my recent experience it seems that tuning vm.kmem_size is no >> longer required, >> maybe you can try without it. > > Sure, i rebooted the system without vm.kmem_size. It takes a a few hours > until i got deadlocks. Removing vm.kmem_size didn't fix my deadlock issue. It just took a bit longer until the deadlock was triggered. Maybe someone can check my deadlock debug output at http://www.bsdunix.ch/deadlock_2008-11-21.txt Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 14:59:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA00106564A for ; Fri, 21 Nov 2008 14:59:37 +0000 (UTC) (envelope-from rksah@bredband.net) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC648FC08 for ; Fri, 21 Nov 2008 14:59:37 +0000 (UTC) (envelope-from rksah@bredband.net) Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.127) id 48DC49FD01173575 for freebsd-current@freebsd.org; Fri, 21 Nov 2008 15:59:36 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArY6AIJbJklV4BwGPGdsb2JhbACJGYo0AQEBATXAaoJ8 Received: from c-061ce055.246-1-64736c10.cust.bredbandsbolaget.se (HELO _HOSTNAME_) ([85.224.28.6]) by ironport2.bredband.com with SMTP; 21 Nov 2008 15:59:35 +0100 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Fri, 21 Nov 2008 15:59:34 +0100 From: "Björn Jonare" Date: Fri, 21 Nov 2008 15:59:34 +0100 To: "Paul B. Mahol" Message-ID: <20081121145933.GA19807@hel.niflheim.se> References: <20081121020459.GB1397@hel.niflheim.se> <3a142e750811210407i7dcf74eh4e0cf974d1179c8a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a142e750811210407i7dcf74eh4e0cf974d1179c8a@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: GENERIC + ral X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 14:59:38 -0000 On Fri, Nov 21, 2008 at 01:07:40PM +0100, Paul B. Mahol wrote: > On 11/21/08, Björn Jonare wrote: > > Hello! > > > > Running CURRENT as of today I tried to get my Linksys WMP54G up and > > working. After some trouble with the console spewing error messages > > that the firmware couldn't be loaded I read the manpage for ral(4). > > > > Looking through the config for GENERIC I saw that there was no line > > "device ralfw". After adding that line and rebooting everything went > > fine. > > > > However, shouldn't ralfw be present in GENERIC? It won't build as a > > module and "device ral" is sort of useless if the system can't load > > card firmware. Or am I simply missing something? > > # cd /sys/modules/ralfw/ && make && make install > > doesn't work? Works fine... I really _was_ missing something... /Björn From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 16:25:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F041065672 for ; Fri, 21 Nov 2008 16:25:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 33E888FC08 for ; Fri, 21 Nov 2008 16:25:24 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0870D4569A; Fri, 21 Nov 2008 17:25:23 +0100 (CET) Received: from localhost (pjdwl.wheel.pl [10.0.1.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0BF9045684; Fri, 21 Nov 2008 17:25:17 +0100 (CET) Date: Fri, 21 Nov 2008 17:25:18 +0100 From: Pawel Jakub Dawidek To: Nikolay Denev Message-ID: <20081121162518.GC6509@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> <20081119090307.GA81236@icarus.home.lan> <18E318DD-29FA-4E26-89CF-11B893B42E34@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J5MfuwkIyy7RmF4Q" Content-Disposition: inline In-Reply-To: <18E318DD-29FA-4E26-89CF-11B893B42E34@gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 16:25:25 -0000 --J5MfuwkIyy7RmF4Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2008 at 01:58:49PM +0200, Nikolay Denev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On 19 Nov, 2008, at 11:48 , Nikolay Denev wrote: > > > >Well, it looks like that on -current and a 4G amd64 machine probably =20 > >there is no need > >to tune anything. Here are my defaults with everything vm and zfs =20 > >related in loader.conf commented : > > > >vm.kmem_size_max: 4509713203 > >vfs.zfs.arc_max: 863907840 > > >=20 > I was able to panic it again with "kmem_map too small" with these =20 > settings (defaults). >=20 > This are the bonnie++ arguments that i've used: > bonnie++ -d /tank -c 4 -r 4096 -x 9999999 -u 0:0 I wasn't able to panic my test machine running this command on i386 machine with this in /boot/loader.conf: vm.kmem_size=3D1073741824 vm.kmem_size_max=3D1073741824 (1GB) Although I now found that you were trying raidz2 and I had two two-way mirrors. I'm retrying now. PS. The panic is not yet fixed completely, unfortunately, but it should be a bit harder to trigger it now. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --J5MfuwkIyy7RmF4Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJJuDuForvXbEpPzQRArEoAKDCxxt5+FzCN0gmpAdWvha9ZrLwrgCg8wdm PXkcQNZQIDiLwvvRnHt3Jko= =e8Q0 -----END PGP SIGNATURE----- --J5MfuwkIyy7RmF4Q-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 16:34:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7703F10656D2 for ; Fri, 21 Nov 2008 16:34:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 27C788FC2C for ; Fri, 21 Nov 2008 16:34:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so444171ywe.13 for ; Fri, 21 Nov 2008 08:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=TbFMztew/S7o9K3vHn3zf2+A1ZCLj5+H9EmEoQevUb8=; b=CFJHbn57rskqjXcuZjUGrDl6rgzp9FPy/v9dDOqDDOkMkungGiNhmJLohIPhCI91l7 LzHb2chyqBCifgD17FPvxa8BiFEdKEI7QdSkwcsmjJzsFbjv9nQeQfuK0QGe96oxYQcE wKa7Iz47W+SgvhnFI/NpqnIgB69VVJa7shoVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dSnbRGChSqmNDKsKAUZPPbnT/JFWCH4z6bck2WLa63d1nMmrlYq16E0QxWKBL5Uipk BndpD05upcqqiNFWUDODGlvj40S+g893xYm5Qt50JhUOZXVcWbtqzS9nvcFKMIs5hMmZ WKQKqqJ0bvWOaOtVUbXo3OivWpCVGXcKQiduQ= Received: by 10.231.34.1 with SMTP id j1mr6112ibd.55.1227285283616; Fri, 21 Nov 2008 08:34:43 -0800 (PST) Received: by 10.231.11.7 with HTTP; Fri, 21 Nov 2008 08:34:43 -0800 (PST) Message-ID: <3a142e750811210834n3d16ed26jfce39599c9aa87a0@mail.gmail.com> Date: Fri, 21 Nov 2008 17:34:43 +0100 From: "Paul B. Mahol" To: "=?ISO-8859-1?Q?Bj=C3=B6rn_Jonare?=" In-Reply-To: <20081121145933.GA19807@hel.niflheim.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20081121020459.GB1397@hel.niflheim.se> <3a142e750811210407i7dcf74eh4e0cf974d1179c8a@mail.gmail.com> <20081121145933.GA19807@hel.niflheim.se> Cc: freebsd-current@freebsd.org Subject: Re: GENERIC + ral X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 16:34:44 -0000 On 11/21/08, Bj=C3=B6rn Jonare wrote: > On Fri, Nov 21, 2008 at 01:07:40PM +0100, Paul B. Mahol wrote: >> On 11/21/08, Bj=C3=B6rn Jonare wrote: >> > Hello! >> > >> > Running CURRENT as of today I tried to get my Linksys WMP54G up and >> > working. After some trouble with the console spewing error messages >> > that the firmware couldn't be loaded I read the manpage for ral(4). >> > >> > Looking through the config for GENERIC I saw that there was no line >> > "device ralfw". After adding that line and rebooting everything went >> > fine. >> > >> > However, shouldn't ralfw be present in GENERIC? It won't build as a >> > module and "device ral" is sort of useless if the system can't load >> > card firmware. Or am I simply missing something? >> >> # cd /sys/modules/ralfw/ && make && make install >> >> doesn't work? > > Works fine... I really _was_ missing something... > > /Bj=F6rn > ralfw is currently disconnected from the build, for reasons yet to found... --=20 Paul From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 19:01:19 2008 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 4CB5E106564A; Fri, 21 Nov 2008 19:01:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 160BB8FC16; Fri, 21 Nov 2008 19:01:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mALJ1Gg8090425; Fri, 21 Nov 2008 14:01:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mALJ1GAo070057; Fri, 21 Nov 2008 14:01:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F1EE773039; Fri, 21 Nov 2008 14:01:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121190115.F1EE773039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 14:01:15 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 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, 21 Nov 2008 19:01:19 -0000 TB --- 2008-11-21 16:51:37 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 16:51:37 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-11-21 16:51:37 - cleaning the object tree TB --- 2008-11-21 16:52:02 - cvsupping the source tree TB --- 2008-11-21 16:52:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-11-21 16:52:09 - building world TB --- 2008-11-21 16:52:09 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 16:52:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 16:52:09 - TARGET=ia64 TB --- 2008-11-21 16:52:09 - TARGET_ARCH=ia64 TB --- 2008-11-21 16:52:09 - TZ=UTC TB --- 2008-11-21 16:52:09 - __MAKE_CONF=/dev/null TB --- 2008-11-21 16:52:09 - cd /src TB --- 2008-11-21 16:52:09 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 16:52:11 UTC 2008 >>> 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 21 18:39:29 UTC 2008 TB --- 2008-11-21 18:39:29 - generating LINT kernel config TB --- 2008-11-21 18:39:29 - cd /src/sys/ia64/conf TB --- 2008-11-21 18:39:29 - /usr/bin/make -B LINT TB --- 2008-11-21 18:39:29 - building LINT kernel TB --- 2008-11-21 18:39:29 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 18:39:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 18:39:29 - TARGET=ia64 TB --- 2008-11-21 18:39:29 - TARGET_ARCH=ia64 TB --- 2008-11-21 18:39:29 - TZ=UTC TB --- 2008-11-21 18:39:29 - __MAKE_CONF=/dev/null TB --- 2008-11-21 18:39:29 - cd /src TB --- 2008-11-21 18:39:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 18:39:29 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0xa2f2): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 19:01:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 19:01:15 - ERROR: failed to build lint kernel TB --- 2008-11-21 19:01:15 - 6414.02 user 436.80 system 7778.30 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 19:59:15 2008 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 2CB60106574A; Fri, 21 Nov 2008 19:59:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A84C88FC19; Fri, 21 Nov 2008 19:59:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mALJwurj081978; Fri, 21 Nov 2008 14:59:08 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Paul B. Mahol" Date: Fri, 21 Nov 2008 13:53:42 -0500 User-Agent: KMail/1.9.7 References: <200811201627.58289.jhb@freebsd.org> <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> In-Reply-To: <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811211353.42283.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 21 Nov 2008 14:59:08 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8661/Fri Nov 21 10:39:30 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 19:59:15 -0000 On Thursday 20 November 2008 06:32:25 pm Paul B. Mahol wrote: > On 11/20/08, John Baldwin wrote: > > So this patch is fairly minimal since udf(4) is currently read-only. The > > changes include: > > > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it > > only > > in udf_root(). This matches the behavior of other operating systems and > > correctly tags the root vnode with VV_ROOT in the unlikely case that we > > create the vnode during a call to ufs_vget() that does not come from > > ufs_root(). > > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock is > > used while creating the new vnode (same as UFS). > > * Allow lock recursion (XXX: not really sure this is needed actually). > > * Allow shared vnode locks on non-fifos. > > * Honor the requested locking flags (shared vs exclusive) instead of always > > using exclusive vnode locks during a lookup operation. > > * Handle "." lookups the same way other filesystems do by just bumping the > > reference on 'dvp' rather than calling udf_vget(). > > > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch > > > > I have only verified that this compiles and would appreciate it if some > > folks > > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabled. > > I lightly tested it with md(4) on 47M size iso created with k3b > (it contains two files) > > I only got this lor related to udf: > > lock order reversal: > 1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442 > 2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > 3rd 0xc4399488 udf (udf) @ > /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625 I think you would get this same LOR w/o the patch. I think cd9660 might have the same bug. The issue is holding a buffer from bread() (i.e. not calling brelse() yet) while calling udf_vget() in udf_lookup(). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 19:59:34 2008 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 19F0E1065707; Fri, 21 Nov 2008 19:59:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9556E8FC1C; Fri, 21 Nov 2008 19:59:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mALJxRbN081995; Fri, 21 Nov 2008 14:59:27 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Paul B. Mahol" Date: Fri, 21 Nov 2008 14:52:02 -0500 User-Agent: KMail/1.9.7 References: <200811201627.58289.jhb@freebsd.org> <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> In-Reply-To: <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811211452.02545.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 21 Nov 2008 14:59:27 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8661/Fri Nov 21 10:39:30 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 19:59:34 -0000 On Thursday 20 November 2008 06:32:25 pm Paul B. Mahol wrote: > On 11/20/08, John Baldwin wrote: > > So this patch is fairly minimal since udf(4) is currently read-only. The > > changes include: > > > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it > > only > > in udf_root(). This matches the behavior of other operating systems and > > correctly tags the root vnode with VV_ROOT in the unlikely case that we > > create the vnode during a call to ufs_vget() that does not come from > > ufs_root(). > > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock is > > used while creating the new vnode (same as UFS). > > * Allow lock recursion (XXX: not really sure this is needed actually). > > * Allow shared vnode locks on non-fifos. > > * Honor the requested locking flags (shared vs exclusive) instead of always > > using exclusive vnode locks during a lookup operation. > > * Handle "." lookups the same way other filesystems do by just bumping the > > reference on 'dvp' rather than calling udf_vget(). > > > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch > > > > I have only verified that this compiles and would appreciate it if some > > folks > > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabled. > > I lightly tested it with md(4) on 47M size iso created with k3b > (it contains two files) > > I only got this lor related to udf: > > lock order reversal: > 1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442 > 2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > 3rd 0xc4399488 udf (udf) @ > /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625 I've updated the patch at the same URL above to fix this LOR. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 20:02:06 2008 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 25FD01065675; Fri, 21 Nov 2008 20:02:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 03CDF8FC08; Fri, 21 Nov 2008 20:02:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mALK21nF064977; Fri, 21 Nov 2008 15:02:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mALK20Ql099095; Fri, 21 Nov 2008 15:02:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B75CA73039; Fri, 21 Nov 2008 15:02:00 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121200200.B75CA73039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 15:02:00 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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: Fri, 21 Nov 2008 20:02:06 -0000 TB --- 2008-11-21 18:22:56 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 18:22:56 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-11-21 18:22:57 - cleaning the object tree TB --- 2008-11-21 18:23:19 - cvsupping the source tree TB --- 2008-11-21 18:23:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-11-21 18:23:27 - building world TB --- 2008-11-21 18:23:27 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 18:23:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 18:23:27 - TARGET=powerpc TB --- 2008-11-21 18:23:27 - TARGET_ARCH=powerpc TB --- 2008-11-21 18:23:27 - TZ=UTC TB --- 2008-11-21 18:23:27 - __MAKE_CONF=/dev/null TB --- 2008-11-21 18:23:27 - cd /src TB --- 2008-11-21 18:23:27 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 18:23:29 UTC 2008 >>> 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 21 19:46:36 UTC 2008 TB --- 2008-11-21 19:46:36 - generating LINT kernel config TB --- 2008-11-21 19:46:36 - cd /src/sys/powerpc/conf TB --- 2008-11-21 19:46:36 - /usr/bin/make -B LINT TB --- 2008-11-21 19:46:36 - building LINT kernel TB --- 2008-11-21 19:46:36 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 19:46:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 19:46:36 - TARGET=powerpc TB --- 2008-11-21 19:46:36 - TARGET_ARCH=powerpc TB --- 2008-11-21 19:46:36 - TZ=UTC TB --- 2008-11-21 19:46:36 - __MAKE_CONF=/dev/null TB --- 2008-11-21 19:46:36 - cd /src TB --- 2008-11-21 19:46:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 19:46:36 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 -ffreestanding -fstack-protector -Werror vers.c linking kernel hwpmc_mod.o(.text+0x3328): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 20:02:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 20:02:00 - ERROR: failed to build lint kernel TB --- 2008-11-21 20:02:00 - 4771.09 user 410.78 system 5943.38 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 20:37:23 2008 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 2EAA01065737; Fri, 21 Nov 2008 20:37:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0D54B8FC13; Fri, 21 Nov 2008 20:37:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mALKbJtB008987; Fri, 21 Nov 2008 15:37:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mALKbIxp016801; Fri, 21 Nov 2008 15:37:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C637073039; Fri, 21 Nov 2008 15:37:18 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081121203718.C637073039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 15:37:18 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2008 20:37:23 -0000 TB --- 2008-11-21 19:01:16 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 19:01:16 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-21 19:01:16 - cleaning the object tree TB --- 2008-11-21 19:01:37 - cvsupping the source tree TB --- 2008-11-21 19:01:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-21 19:01:44 - building world TB --- 2008-11-21 19:01:44 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 19:01:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 19:01:44 - TARGET=sparc64 TB --- 2008-11-21 19:01:44 - TARGET_ARCH=sparc64 TB --- 2008-11-21 19:01:44 - TZ=UTC TB --- 2008-11-21 19:01:44 - __MAKE_CONF=/dev/null TB --- 2008-11-21 19:01:44 - cd /src TB --- 2008-11-21 19:01:44 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 19:01:46 UTC 2008 >>> 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 21 20:21:25 UTC 2008 TB --- 2008-11-21 20:21:25 - generating LINT kernel config TB --- 2008-11-21 20:21:25 - cd /src/sys/sparc64/conf TB --- 2008-11-21 20:21:25 - /usr/bin/make -B LINT TB --- 2008-11-21 20:21:25 - building LINT kernel TB --- 2008-11-21 20:21:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 20:21:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 20:21:25 - TARGET=sparc64 TB --- 2008-11-21 20:21:25 - TARGET_ARCH=sparc64 TB --- 2008-11-21 20:21:25 - TZ=UTC TB --- 2008-11-21 20:21:25 - __MAKE_CONF=/dev/null TB --- 2008-11-21 20:21:25 - cd /src TB --- 2008-11-21 20:21:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 20:21:25 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 20:37:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 20:37:18 - ERROR: failed to build lint kernel TB --- 2008-11-21 20:37:18 - 4579.52 user 410.76 system 5762.69 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 21:16:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5549D1065672 for ; Fri, 21 Nov 2008 21:16:31 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp811.mail.ird.yahoo.com (smtp811.mail.ird.yahoo.com [217.146.188.71]) by mx1.freebsd.org (Postfix) with SMTP id BBF548FC1D for ; Fri, 21 Nov 2008 21:16:30 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 8494 invoked from network); 21 Nov 2008 21:16:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=uQoG+WfsKsAKkuvORF2ZvsvbE4AxI5p4fDah1q4rCvig6iy+aF2pkUMyo/O+ORcRD9kMKhoXxWlZS6PjV4Nyhs0A321NKrw9JitQGZEOvZN0Sh3zqfPkGeNnJ1vwPBFrO5VBez69P2CwS54Js7djAVcB+oMCUQJoIZree/O1XfM= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.53.143 with login) by smtp811.mail.ird.yahoo.com with SMTP; 21 Nov 2008 21:16:29 -0000 X-YMail-OSG: 1KTlgicVM1kfg0IQcqV1uGheRpXZBDvzOsrYaw8JRHJ0pYnf8nOIBjvAxbHc8ytRHoIqqjUBpVFjptOQLBHNWFI_YU00Acq5WXsWtWcUcRPxavS624Jhx933Vl8CxwEuUmWmZOSlLC4zIPGHy5HC.W44XMmkTAHg70X6RHU- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Fri, 21 Nov 2008 21:16:17 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811200015.54319.Thomas.Sparrevohn@btinternet.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811212116.17948.Thomas.Sparrevohn@btinternet.com> Cc: Ivan Voras Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 21:16:31 -0000 On Friday 21 November 2008 01:19:35 Ivan Voras wrote: > Thomas Sparrevohn wrote: > > On Wednesday 19 November 2008 10:14:02 Ivan Voras wrote: > >> Thomas Sparrevohn wrote: > >>> On Tuesday 18 November 2008 21:56:38 Pawel Jakub Dawidek wrote: > >>>> On Tue, Nov 18, 2008 at 09:50:51PM +0000, Thomas Sparrevohn wrote: > >>>>> On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote: > >>>>>> What's unexpected in that? As I noted it still needs more work, so > >>>>>> chflags(2) working properly would be unexpected for me:) > >>>>>> > >>>>>>> -------------------------------------------------------------- > >>>>> LOL - Unexpected that it just not returns operation not supported as it used to - I was a bit > >>>>> trigger happy and upgraded my main pool - against the sound advice - leaves me in a bit of trouble ;-) > >>>> Try 'make installworld NO_FSCHG='. > >>>> > >>> LOL and now I feel really stupid - thanks > >> Hmmm, I did an installworld from UFS to ZFS yesterday without special > >> flags (actually, multiple installworlds for benchmarking), without > >> errors. Files really did get schg (or equivalent) flag since I couldn't > >> rm them afterwards. How is this possible? :) > > > > That is a surprise - as mine failed - totally - had to manually restore libc > > I've just did it again - make installworld DESTDIR=/data/test (I'm not > using ZFS on root) - works without problems, ls reports schg flag on the > usual files. amd64, ZFS pool version 13, compiled a few hours after the > big import. > > > Yes it works if you have either created a new pool or made sure that all mountpoints have the version=3 flag set What got me is that zpool upgrade does not change the version of the mountpoints e.g. they stay version 1 so a simple foreach i (`zfs list -H -t filesystem -o name `) zfs set version=3 end will make schg work From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 22:00:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B88501065670 for ; Fri, 21 Nov 2008 22:00:33 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB048FC08 for ; Fri, 21 Nov 2008 22:00:32 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 12414 invoked from network); 21 Nov 2008 21:33:50 -0000 Received: from unknown (HELO goa.local) (smtpsend@85.179.31.172) by mail.h3q.com with AES256-SHA encrypted SMTP; 21 Nov 2008 21:33:50 -0000 Message-ID: <4927293E.6000704@h3q.com> Date: Fri, 21 Nov 2008 22:33:50 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20081117205526.GC1733@garage.freebsd.pl> <200811200015.54319.Thomas.Sparrevohn@btinternet.com> <200811212116.17948.Thomas.Sparrevohn@btinternet.com> In-Reply-To: <200811212116.17948.Thomas.Sparrevohn@btinternet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 22:00:33 -0000 Thomas Sparrevohn wrote: > > Yes it works if you have either created a new pool or made sure that all mountpoints have > the version=3 flag set > > What got me is that zpool upgrade does not change the version of the mountpoints e.g. > they stay version 1 > > so a simple > > foreach i (`zfs list -H -t filesystem -o name `) > zfs set version=3 > end Just do zfs upgrade -r tank greetings, philipp From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 22:43:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31A371065709 for ; Fri, 21 Nov 2008 22:43:16 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp811.mail.ird.yahoo.com (smtp811.mail.ird.yahoo.com [217.146.188.71]) by mx1.freebsd.org (Postfix) with SMTP id 8F5DA8FC1D for ; Fri, 21 Nov 2008 22:43:15 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 68856 invoked from network); 21 Nov 2008 22:43:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=cxK8UldRd83famFpnC90o0rxkfFRSuk9Gex27bz0LiVg3v1TRUmdrHO1yErLCdffsgqqekednYBV7JPZJP83N04298immvuvGEZB0P8ih1oSFV34dQ97KjAVaEPWcmtt/0CF4aAQEQqMW3mfwjoFBDzH8t0jbGSdxsQS71ieq7Y= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.53.143 with login) by smtp811.mail.ird.yahoo.com with SMTP; 21 Nov 2008 22:43:13 -0000 X-YMail-OSG: 3YtUu8sVM1lz_PogMofAWthwiHsXVNELrm4RlbL86RIxB468EHWXTxksCtzHomphwHf7E3E897vcg8S9s4vgYx9BtlaWKFeh0GI2VT7Pv0v74uHQozoXj64HdUMpeiHvP90DXkOUD.qQ5CFo6HZc4h28o89654vbntsBPCdmTyVBzTX06t4Vx.gYgos- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Fri, 21 Nov 2008 22:43:10 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811212116.17948.Thomas.Sparrevohn@btinternet.com> <4927293E.6000704@h3q.com> In-Reply-To: <4927293E.6000704@h3q.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811212243.10899.Thomas.Sparrevohn@btinternet.com> Cc: Philipp Wuensche Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 22:43:16 -0000 On Friday 21 November 2008 21:33:50 Philipp Wuensche wrote: > Thomas Sparrevohn wrote: > > > > Yes it works if you have either created a new pool or made sure that all mountpoints have > > the version=3 flag set > > > > What got me is that zpool upgrade does not change the version of the mountpoints e.g. > > they stay version 1 > > > > so a simple > > > > foreach i (`zfs list -H -t filesystem -o name `) > > zfs set version=3 > > end > > Just do zfs upgrade -r tank > > greetings, > philipp > > _______________________________________________ > 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" > Nope - it does not upgrade the property for existing data sets - It only upgrades - or at least when I did it - the pool itself - for the data sets you need to either create new ones or manually upgrade the version property From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 22:52:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C7441065688 for ; Fri, 21 Nov 2008 22:52:56 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id BDCB48FC12 for ; Fri, 21 Nov 2008 22:52:55 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 35521 invoked from network); 21 Nov 2008 22:52:54 -0000 Received: from unknown (HELO goa.local) (smtpsend@85.179.31.172) by mail.h3q.com with AES256-SHA encrypted SMTP; 21 Nov 2008 22:52:54 -0000 Message-ID: <49273BC5.9080503@h3q.com> Date: Fri, 21 Nov 2008 23:52:53 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20081117205526.GC1733@garage.freebsd.pl> <200811212116.17948.Thomas.Sparrevohn@btinternet.com> <4927293E.6000704@h3q.com> <200811212243.10899.Thomas.Sparrevohn@btinternet.com> In-Reply-To: <200811212243.10899.Thomas.Sparrevohn@btinternet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Sparrevohn Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 22:52:56 -0000 Thomas Sparrevohn wrote: > > Nope - it does not upgrade the property for existing data sets - It only upgrades - or at least when I did it - > the pool itself - for the data sets you need to either create new ones or manually upgrade the version property I think you confuse "zfs upgrade" with "zpool upgrade". greetings, philipp From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 22:54:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E5A61065672 for ; Fri, 21 Nov 2008 22:54:58 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp808.mail.ird.yahoo.com (smtp808.mail.ird.yahoo.com [217.146.188.68]) by mx1.freebsd.org (Postfix) with SMTP id 8260D8FC16 for ; Fri, 21 Nov 2008 22:54:57 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 36701 invoked from network); 21 Nov 2008 22:54:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=FUEzY72vdPXieX4zQb+VUd2vPhP9MbIULVljIUentKrNNQkaIqvoguhWvkEBEU/0hZek2ZPsbW2AkHCreoKOwWz7B2vRgeKFAiG2q7rMdwTIATYz7FAcMjnNt/D0FyXHEItJV3ZAZKSvYmk3pm3GSUxQcUceMhP3ZC+Bgk6bVsg= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.53.143 with login) by smtp808.mail.ird.yahoo.com with SMTP; 21 Nov 2008 22:54:56 -0000 X-YMail-OSG: ch71ZtcVM1kpNtwtYc5fZFCSLMrJv6namMkyFTqC9KtNYbMsEa2WlteqTSgAzh3HtopepYS2Um1BND4SD8HmZknvHdE0CFPIvERhb.ChGRXxpI_n7gPB3JSlqrzvw3lr8IzGIg.Eve0IBwfTc538_OZ1IWgtw7wpkIWjwqA- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: Philipp Wuensche Date: Fri, 21 Nov 2008 22:54:54 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811212243.10899.Thomas.Sparrevohn@btinternet.com> <49273BC5.9080503@h3q.com> In-Reply-To: <49273BC5.9080503@h3q.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811212254.55103.Thomas.Sparrevohn@btinternet.com> Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 22:54:58 -0000 On Friday 21 November 2008 22:52:53 Philipp Wuensche wrote: > Thomas Sparrevohn wrote: > > > > Nope - it does not upgrade the property for existing data sets - It only upgrades - or at least when I did it - > > the pool itself - for the data sets you need to either create new ones or manually upgrade the version property > > I think you confuse "zfs upgrade" with "zpool upgrade". > > greetings, > philipp > > It would seem so - my mistake - From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 22:56:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AD5F106568F for ; Fri, 21 Nov 2008 22:56:04 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp803.mail.ird.yahoo.com (smtp803.mail.ird.yahoo.com [217.146.188.63]) by mx1.freebsd.org (Postfix) with SMTP id 6D7018FC23 for ; Fri, 21 Nov 2008 22:56:02 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 55818 invoked from network); 21 Nov 2008 22:56:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=DKx5vogEZ64ajwE0uiXaUvQNCbmFufuSwt0Xat0+xJgZaNA+D04nAy1Nku8it0g1QRufRfPdyHhEkxosF0d/SvjMrmkFo/TkxG1w2pxbKXxZhTAuY8qywjxCW3fLbmUo+vi92wAp5rX4UUqODb6/gS4Z0VUTcjb5RJdEc96Bxig= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.53.143 with login) by smtp803.mail.ird.yahoo.com with SMTP; 21 Nov 2008 22:56:01 -0000 X-YMail-OSG: TjagSW4VM1mIF8aMPhLMYg_0NKAYpm8rVOdsYmGbAs75B4A8k0luNoMtw_k1Gc5lnJYehIyHughbR9dCZ9WsiypYd4mi5fGmhwEzEb6BFra0kDyyS1j9aunk7sUlQ_X2Z0xkYkz7KodUzyKQ7WOcw6036Sp.XOj8jcOSd0A- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: Philipp Wuensche Date: Fri, 21 Nov 2008 22:56:00 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811212243.10899.Thomas.Sparrevohn@btinternet.com> <49273BC5.9080503@h3q.com> In-Reply-To: <49273BC5.9080503@h3q.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811212256.00821.Thomas.Sparrevohn@btinternet.com> Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 22:56:04 -0000 On Friday 21 November 2008 22:52:53 Philipp Wuensche wrote: > Thomas Sparrevohn wrote: > > > > Nope - it does not upgrade the property for existing data sets - It only upgrades - or at least when I did it - > > the pool itself - for the data sets you need to either create new ones or manually upgrade the version property > > I think you confuse "zfs upgrade" with "zpool upgrade". > > greetings, > philipp > > Yes - I had overlooked that one - sorry the noise From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 22:58:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B44861065670 for ; Fri, 21 Nov 2008 22:58:36 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp818.mail.ird.yahoo.com (smtp818.mail.ird.yahoo.com [77.238.189.18]) by mx1.freebsd.org (Postfix) with SMTP id 1CB9F8FC0A for ; Fri, 21 Nov 2008 22:58:35 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 80707 invoked from network); 21 Nov 2008 22:58:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=IPMMUnEuwEs4CozzIHqwXCfxvdcTJrFCPrvgdL/fqzhQsjDWn/U+rLyKiineMa3BMBJByi0h2UsYnDx6nQtclEl0pQyV7wRaeG+KqLO0O/HHxNBv3EdB7TL+ieEiljdfBwI5NgqAgP5CV0WttkQpfF0cbFdXQxY1t42W6Egu9U0= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.53.143 with login) by smtp818.mail.ird.yahoo.com with SMTP; 21 Nov 2008 22:58:34 -0000 X-YMail-OSG: bZfp7TUVM1kVIrt.zteV9DiU6qg28ioUWS0TW7r9dnNRvkYzjh7qzAWg3EbzwLoNneY4ZQndr.n7NUhusShud1HYK8eXfxDf_27TelTmgq12yIBCbZmc6hK5lyfUKYJoUCMecyrkfPUfEq_jGm.cTH2UsFUtl0kZf647SNudqITy18L0ry6MQuaQgWY- X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Fri, 21 Nov 2008 22:58:33 +0000 User-Agent: KMail/1.9.10 References: <20081117205526.GC1733@garage.freebsd.pl> <200811212243.10899.Thomas.Sparrevohn@btinternet.com> <49273BC5.9080503@h3q.com> In-Reply-To: <49273BC5.9080503@h3q.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811212258.33493.Thomas.Sparrevohn@btinternet.com> Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 22:58:36 -0000 On Friday 21 November 2008 22:52:53 Philipp Wuensche wrote: > Thomas Sparrevohn wrote: > > > > Nope - it does not upgrade the property for existing data sets - It only upgrades - or at least when I did it - > > the pool itself - for the data sets you need to either create new ones or manually upgrade the version property > > I think you confuse "zfs upgrade" with "zpool upgrade". > > greetings, > philipp > > _______________________________________________ > 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" > Still a bit confused about the upgrade the properties - usedbysnapshots 0 - usedbydataset 150M - usedbychildren 32.2G - usedbyrefreservation 0 does only seem to be created or implemented if its a new dataset From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 23:09:29 2008 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 2E0211065670 for ; Fri, 21 Nov 2008 23:09:29 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id E02E18FC08 for ; Fri, 21 Nov 2008 23:09:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 38C4B7309E; Sat, 22 Nov 2008 00:14:00 +0100 (CET) Date: Sat, 22 Nov 2008 00:14:00 +0100 From: Luigi Rizzo To: current@freebsd.org, jhb@freebsd.org, kib@freebsd.org Message-ID: <20081121231400.GA94863@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Recent versions of pxeboot hang/panic on AMD platform. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 23:09:29 -0000 [copying some people involved with recent related commits] As reported in kern/118222 recent versions of pxeboot hang/panic on AMD platform. Initial reports mentioned that the RELENG_6 versions worked well, however i found out that even the recent RELENG_6 code is problematic. Specifically, the problem i see on two machines with AMD CPU (one is an Asus M2N-VM) motherboard netbooting with PXEboot, is that the loading of config files or binary modules (kernel, etc.) randomly hangs with recent version of pxeboot (RELENG_6, RELENG_7 and HEAD all give the same behaviour). The same system works fine with an old version of pxeboot from RELENG_6. Things seem to work fine on i386 (tried a Pentium4, N270 and on qemu) with all the versions below. To make some investigation i started with a reliable version (RELENG_6, early 2008) and moved forward to figure out where the problem was introduced. I found the following: RELENG_6 as of 2008.03.01 (svn 176674) works RELENG_6 as of 2008.03.15 (svn 177190) works (same as previous) RELENG_6 as of 2008.03.31 (svn 177768) does NOT work changed files: Index: RELENG_6/sys/boot/i386/boot2/boot2.c Index: RELENG_6/sys/boot/i386/btx/btx/Makefile Index: RELENG_6/sys/boot/i386/btx/btx/btx.S Index: RELENG_6/sys/boot/i386/gptboot/gptboot.c Index: RELENG_6/sys/boot/i386/libi386/biossmap.c Index: RELENG_6/sys/boot/i386/libi386/biosmem.c There is a recent, related change (august 2008) which however does not seem to fix the bug. (all the above is basically an MFC of something applied slightly earlier to head and RELENG_7 . I have experienced the same exact bug with a fresh head and RELENG_7, even though I have not found the exact point there where the problem arised). The fact that the failure occurs at random times, even quite early (e.g. while reading the Forth config files) suggests that the problem may be related to interrupts coming at the wrong time. Unfortunately the changes to btx.S (which i believe may be related to the problem, as the changes to the other files seem innocuous or unrelated) are beyond my knowledge. So, anyone has ideas on what could be happening here, and especially how likely it is that we might see the same problem with a disk or usb-based booting ? cheers luigi be the case to back out this From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 23:23:31 2008 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 C824F1065670 for ; Fri, 21 Nov 2008 23:23:31 +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 7A3C18FC14 for ; Fri, 21 Nov 2008 23:23:31 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 0A13C2BC3C; Sat, 22 Nov 2008 12:23:30 +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 cSH72JC4HaXw; Sat, 22 Nov 2008 12:23:26 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 22 Nov 2008 12:23:26 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id BE43F1142D; Sat, 22 Nov 2008 12:23:25 +1300 (NZDT) Date: Fri, 21 Nov 2008 15:23:25 -0800 From: Andrew Thompson To: Luigi Rizzo Message-ID: <20081121232325.GA15258@citylink.fud.org.nz> References: <20081121231400.GA94863@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081121231400.GA94863@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: kib@freebsd.org, current@freebsd.org Subject: Re: Recent versions of pxeboot hang/panic on AMD platform. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 23:23:31 -0000 On Sat, Nov 22, 2008 at 12:14:00AM +0100, Luigi Rizzo wrote: > [copying some people involved with recent related commits] > > As reported in kern/118222 recent versions of pxeboot hang/panic > on AMD platform. > > Initial reports mentioned that the RELENG_6 versions worked well, > however i found out that even the recent RELENG_6 code is problematic. > > Specifically, the problem i see on two machines with AMD CPU (one > is an Asus M2N-VM) motherboard netbooting with PXEboot, is that the > loading of config files or binary modules (kernel, etc.) randomly > hangs with recent version of pxeboot (RELENG_6, RELENG_7 and HEAD > all give the same behaviour). I have found that the kernel size can trigger this for me, after reducing the size I didnt experience loader hangs with pxe. You may want to experiment with this in your investigations. Andrew From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 23:36:32 2008 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 07D911065670; Fri, 21 Nov 2008 23:36:32 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id B684A8FC16; Fri, 21 Nov 2008 23:36:31 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 49A8A7309E; Sat, 22 Nov 2008 00:41:04 +0100 (CET) Date: Sat, 22 Nov 2008 00:41:04 +0100 From: Luigi Rizzo To: Andrew Thompson Message-ID: <20081121234104.GA95875@onelab2.iet.unipi.it> References: <20081121231400.GA94863@onelab2.iet.unipi.it> <20081121232325.GA15258@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081121232325.GA15258@citylink.fud.org.nz> User-Agent: Mutt/1.4.2.3i Cc: kib@freebsd.org, current@freebsd.org Subject: Re: Recent versions of pxeboot hang/panic on AMD platform. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 23:36:32 -0000 On Fri, Nov 21, 2008 at 03:23:25PM -0800, Andrew Thompson wrote: > On Sat, Nov 22, 2008 at 12:14:00AM +0100, Luigi Rizzo wrote: > > [copying some people involved with recent related commits] > > > > As reported in kern/118222 recent versions of pxeboot hang/panic > > on AMD platform. > > > > Initial reports mentioned that the RELENG_6 versions worked well, > > however i found out that even the recent RELENG_6 code is problematic. > > > > Specifically, the problem i see on two machines with AMD CPU (one > > is an Asus M2N-VM) motherboard netbooting with PXEboot, is that the > > loading of config files or binary modules (kernel, etc.) randomly > > hangs with recent version of pxeboot (RELENG_6, RELENG_7 and HEAD > > all give the same behaviour). > > I have found that the kernel size can trigger this for me, after > reducing the size I didnt experience loader hangs with pxe. You may want > to experiment with this in your investigations. no luck - the hang often occurs as early as while reading loader.conf, which is way smaller than the kernel. Assuming that the interrupt thing is a possible cause for the bug, I can understand that the kernel size can affect the probability of getting an interrupt at the wrong time. There was one bug due to memory overflow that i fixed in a recent commit to head (see boot/common/interp.c), but this only helped on a different amd64 motherboard. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 23:57:36 2008 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 813761065675 for ; Fri, 21 Nov 2008 23:57:36 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.243]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7318FC0C for ; Fri, 21 Nov 2008 23:57:35 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by hs-out-0708.google.com with SMTP id 54so572572hsz.11 for ; Fri, 21 Nov 2008 15:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/belbTS5imAj4IIJidrjI9yvWHbjvDN6JxtdDgHHkQ4=; b=eai+EprarMJA+JCFg9/yneMNg2HbKoPa8hF0tk/R62i/GTxoD1184Ly499o8mPBrnq xlxSc1lk7AyR9mWzgpipFyhpRj5aGaCBQZTB0LOJi2fj/mjRLxcREyH9htl6cYMapBnT pyuIlXxy1qdW5kMycFNuwc9z6qOGGQNS+Tl0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=R0w3VpK/CwttEcoie16u7TT+stlqfJFPeQNU/8djrw+03PbPCLNvo0nwpFr5zRTYIx Lwx87iCrI3i7dYwwWA8iYbAXoL6DzH0CyZ/BqLz4FfovkqMPa7XaACQMV1G6WTvDTlGZ mIX3iAY0AxkXcWuqXzRQbHsu2WB+Yow5YTdKM= Received: by 10.231.12.12 with SMTP id v12mr28072ibv.4.1227311855148; Fri, 21 Nov 2008 15:57:35 -0800 (PST) Received: by 10.231.11.7 with HTTP; Fri, 21 Nov 2008 15:57:35 -0800 (PST) Message-ID: <3a142e750811211557r75c5c3eaxaa5cd2712360c26e@mail.gmail.com> Date: Sat, 22 Nov 2008 00:57:35 +0100 From: "Paul B. Mahol" To: "Jaakko Heinonen" In-Reply-To: <20081121074013.GA818@a91-153-125-115.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> <20081121074013.GA818@a91-153-125-115.elisa-laajakaista.fi> Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Nov 2008 23:57:36 -0000 On 11/21/08, Jaakko Heinonen wrote: > On 2008-11-20, Paul B. Mahol wrote: >> Machine crashed during clean shutdown (with old kernel without this patch) >> after atapicd where kldloaded and after that used some time and tham >> kldunloaded. > > There are several bugs related to unloading the atapicd module. > > * g_wither_geom() race against module unload > * return value from g_modevent() is ignored > * detaching/unloading is allowed even if the device is in use > > You could try these patches: > > http://www.saunalahti.fi/~jh3/patches/atapi-cd-locking+tray-control.diff > http://www.saunalahti.fi/~jh3/patches/geom-unload-class-race.diff Works fine for me. With that patches panic doesnt not happen during shutdown, -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 00:02:45 2008 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 E463C1065677 for ; Sat, 22 Nov 2008 00:02:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBD78FC16 for ; Sat, 22 Nov 2008 00:02:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so524464ywe.13 for ; Fri, 21 Nov 2008 16:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=kk4+aQnlFLuj1oX3Vjim1LrDLCu6Tb2FBv7Bkb2PPbQ=; b=MgFyy/jQjYjakqJc+X4YV2SwOPFaC4KQ/VIma3e1VpeZJoahHc5U1GDjheLKAfja1P l33Xw88iHdQgpke2QCGXUd2x0bUuDhaVoB5z+KneF7NFCXcdm1+/8pW8Aexu8PCelrul 2wonSS8MKHrZKGzjtXX1TM4pC6WA8EZZzk3Ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xsx6VF5XLfvUWd7lmC5/d+cc3LDxrta0Nt4BiBT0kJ4ql0gDhPVU0UuNCVZVJ2Dazk DvFC4El0Gl7raN7vozo/e9dMPItDfjpfe9oGZfBsEyIF3QVAcX3g4FG4vYVMpR/LenZY nCwP0hBWI4Lz6D5Wp9KhbWvFP1k8ASZx8VU/Y= Received: by 10.231.20.5 with SMTP id d5mr27978ibb.14.1227312162913; Fri, 21 Nov 2008 16:02:42 -0800 (PST) Received: by 10.231.11.7 with HTTP; Fri, 21 Nov 2008 16:02:42 -0800 (PST) Message-ID: <3a142e750811211602h3855e912g573f53b00f6ce452@mail.gmail.com> Date: Sat, 22 Nov 2008 01:02:42 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200811211452.02545.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811201627.58289.jhb@freebsd.org> <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> <200811211452.02545.jhb@freebsd.org> Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 00:02:45 -0000 On 11/21/08, John Baldwin wrote: > On Thursday 20 November 2008 06:32:25 pm Paul B. Mahol wrote: >> On 11/20/08, John Baldwin wrote: >> > So this patch is fairly minimal since udf(4) is currently read-only. >> > The >> > changes include: >> > >> > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing >> > it >> > only >> > in udf_root(). This matches the behavior of other operating systems >> > and >> > correctly tags the root vnode with VV_ROOT in the unlikely case that >> > we >> > create the vnode during a call to ufs_vget() that does not come from >> > ufs_root(). >> > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock >> > > is >> > used while creating the new vnode (same as UFS). >> > * Allow lock recursion (XXX: not really sure this is needed actually). >> > * Allow shared vnode locks on non-fifos. >> > * Honor the requested locking flags (shared vs exclusive) instead of > always >> > using exclusive vnode locks during a lookup operation. >> > * Handle "." lookups the same way other filesystems do by just bumping >> > the >> > reference on 'dvp' rather than calling udf_vget(). >> > >> > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch >> > >> > I have only verified that this compiles and would appreciate it if some >> > folks >> > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabled. >> >> I lightly tested it with md(4) on 47M size iso created with k3b >> (it contains two files) >> >> I only got this lor related to udf: >> >> lock order reversal: >> 1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442 >> 2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >> 3rd 0xc4399488 udf (udf) @ >> /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625 > > I've updated the patch at the same URL above to fix this LOR. > > -- > John Baldwin > Some bad news, using new patch (did not tested agains old one) I was able to reliable panic system with 3.4GB iso, trying to play music files via cplay. here is backtrack, from textdump: db:1:lockinfo> show locks db:1:locks> show alllocks Process 977 (python) thread 0xc43b4d80 (100087) db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 1 curthread = 0xc43b4d80: pid 977 "initial thread" curpcb = 0xc3b67d90 fpcurthread = none idlethread = 0xc3d2ad80: pid 10 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db:0:kdb.enter.panic> bt Tracing pid 977 tid 100087 td 0xc43b4d80 kdb_enter(c069b0df,c069b0df,c06a5d32,c3b67968,1,...) at kdb_enter+0x3a panic(c06a5d32,10800,10000,c0686786,c3b679d0,...) at panic+0x131 getblk(c4e0e10c,424,0,10800,0,...) at getblk+0x2d breadn(c4e0e10c,424,0,10800,0,...) at breadn+0x44 bread(c4e0e10c,424,0,10800,0,...) at bread+0x4c udf_readatoffset(1a18,0,c50568d8,c50568dc,0,...) at udf_readatoffset+0xbb udf_getfid(c4694680,ffffffff,c3b67cf8,c06a8594,c3b67c24,...) at udf_getfid+0x1ca udf_readdir(c3b67c24,0,c4555648,0,c3b67c5c,...) at udf_readdir+0xdc VOP_READDIR_APV(c4faf280,c3b67c24,c06a8594,ff3,1a18,...) at VOP_READDIR_APV+0xa0 kern_getdirentries(c43b4d80,46,2844c000,1000,c3b67c78,...) at kern_getdirentries+0x1bd getdirentries(c43b4d80,c3b67cf8,10,c06a1b96,c06cfbe0,...) at getdirentries+0x31 syscall(c3b67d38) at syscall+0x261 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (196, FreeBSD ELF32, getdirentries), eip = 0x28251e4b, esp = 0xbfbfe27c, ebp = 0xbfbfe2a8 --- and panic message: uiomove returned -1 panic: getblk: size(67584) > MAXBSIZE(65536) cpuid = 1 KDB: enter: panic exclusive lockmgr udf (udf) r = 0 (0xc45556a0) locked @ /usr/src/sys/kern/vfs_syscalls.c:4083 exclusive lockmgr udf (udf) r = 0 (0xc45556a0) locked @ /usr/src/sys/kern/vfs_syscalls.c:4083 0xc4555648: tag udf, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () v_object 0xc479ac98 ref 0 pages 0 lock type udf: EXCL by thread 0xc43b4d80 (pid 977) -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 00:04:51 2008 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 E4FE5106564A for ; Sat, 22 Nov 2008 00:04:50 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4E98B8FC16 for ; Sat, 22 Nov 2008 00:04:49 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by gxk5 with SMTP id 5so90159gxk.19 for ; Fri, 21 Nov 2008 16:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oR03/9cpmQ3rs8adJeBc7dA4UYNMfVCbAhJ6CB7+skY=; b=YoLYJO2G6pGmTYt2JlAI/06CzJttMvT8mLauUWGb5q8i9seKjr1dIPmW1U1OVZkPMn T+CaLXGqMqp6hr9v4BaaHBTvjgUHRLUdm0dPAB3ILe6cjz3LhEWfA9GfYSWfhukzH5r+ FbQyO71ZeaV2JOSMmrh2OUIYnzvwzvFDbcIf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=moOrKEeRBqDjw3bJ22L4A/YApEqOs27HC7YLPe7//WNnQlxD5xazMRZwcUy1bwHrJL zgdWilMn2fDQ364KQR+mXj9TbnEAB/QMfKC6OeD6CD0fr/2qpbUAP0OpqMycIv3D8l2g hhSkdWMI5WLhTTw9ccN7G9mf9JJW5B0AJASfc= Received: by 10.231.16.129 with SMTP id o1mr27656iba.47.1227312287582; Fri, 21 Nov 2008 16:04:47 -0800 (PST) Received: by 10.231.11.7 with HTTP; Fri, 21 Nov 2008 16:04:47 -0800 (PST) Message-ID: <3a142e750811211604u75e44c0fifa66529f12b4335a@mail.gmail.com> Date: Sat, 22 Nov 2008 01:04:47 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200811211353.42283.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811201627.58289.jhb@freebsd.org> <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> <200811211353.42283.jhb@freebsd.org> Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 00:04:51 -0000 On 11/21/08, John Baldwin wrote: > On Thursday 20 November 2008 06:32:25 pm Paul B. Mahol wrote: >> On 11/20/08, John Baldwin wrote: >> > So this patch is fairly minimal since udf(4) is currently read-only. >> > The >> > changes include: >> > >> > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing >> > it >> > only >> > in udf_root(). This matches the behavior of other operating systems >> > and >> > correctly tags the root vnode with VV_ROOT in the unlikely case that >> > we >> > create the vnode during a call to ufs_vget() that does not come from >> > ufs_root(). >> > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock >> > > is >> > used while creating the new vnode (same as UFS). >> > * Allow lock recursion (XXX: not really sure this is needed actually). >> > * Allow shared vnode locks on non-fifos. >> > * Honor the requested locking flags (shared vs exclusive) instead of > always >> > using exclusive vnode locks during a lookup operation. >> > * Handle "." lookups the same way other filesystems do by just bumping >> > the >> > reference on 'dvp' rather than calling udf_vget(). >> > >> > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch >> > >> > I have only verified that this compiles and would appreciate it if some >> > folks >> > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabled. >> >> I lightly tested it with md(4) on 47M size iso created with k3b >> (it contains two files) >> >> I only got this lor related to udf: >> >> lock order reversal: >> 1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442 >> 2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >> 3rd 0xc4399488 udf (udf) @ >> /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625 > > I think you would get this same LOR w/o the patch. I think cd9660 might > have > the same bug. The issue is holding a buffer from bread() (i.e. not calling > brelse() yet) while calling udf_vget() in udf_lookup(). cd9660 have this LOR: lock order reversal: 1st 0xc43a0594 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 2nd 0xd7d105b0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc43a0488 isofs (isofs) @ /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 KDB: stack backtrace: db_trace_self_wrapper(c069e216,c3b646d0,c04e793f,4,c069995b,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c069995b,c3cb7538,c3cb9ca0,c3b6472c,...) at kdb_backtrace+0x29 _witness_debugger(c06a0ee3,c43a0488,c443da9a,c3cb9ca0,c443d9de,...) at _witness_debugger+0x1e witness_checkorder(c43a0488,9,c443d9de,2b6,0,...) at witness_checkorder+0x811 __lockmgr_args(c43a0488,80000,0,0,0,...) at __lockmgr_args+0x762 cd9660_vget_internal(c443f500,1e0ee,200000,c3b648b0,0,...) at cd9660_vget_internal+0x13e cd9660_lookup(c3b649fc,c43a053c,c3b64bb4,c43a053c,c3b64a1c,...) at cd9660_lookup+0x621 VOP_CACHEDLOOKUP_APV(c443e360,c3b649fc,c3b64bb4,c3b64ba0,c06fa1c0,...) at VOP_CACHEDLOOKUP_APV+0xa0 vfs_cache_lookup(c3b64a7c,c3b64a7c,0,200000,c43a053c,...) at vfs_cache_lookup+0xc3 VOP_LOOKUP_APV(c443e360,c3b64a7c,c06a6c14,1ba,c3b64ba0,...) at VOP_LOOKUP_APV+0xaa lookup(c3b64b88,c06a6c14,dc,bc,c4186a2c,...) at lookup+0x507 namei(c3b64b88,c06a693e,143,c108ba34,c3c80000,...) at namei+0x45b kern_statat(c4442000,200,ffffff9c,282162f8,0,...) at kern_statat+0x66 kern_lstat(c4442000,282162f8,0,c3b64c1c,0,...) at kern_lstat+0x36 lstat(c4442000,c3b64cf8,8,c06a1b96,c06cfb50,...) at lstat+0x2b syscall(c3b64d38) at syscall+0x261 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x281f13ab, esp = 0xbfbfe8ac, ebp = 0xbfbfe8c8 --- -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 01:19:18 2008 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 DE39F106564A for ; Sat, 22 Nov 2008 01:19:18 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9BEF48FC13 for ; Sat, 22 Nov 2008 01:19:18 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1BE2373098; Sat, 22 Nov 2008 02:23:51 +0100 (CET) Date: Sat, 22 Nov 2008 02:23:51 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20081122012351.GA98158@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC - per-host configuration of pxe booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 01:19:18 -0000 [this mailing list is as good as anyone i guess... feel free to forward it if you believe there is a more appropriate forum] The goal of this email is to figure out how to load host-specific configurations from pxeboot -- maybe as simple as loading /boot/loader.conf.${hostname} and possibly something slightly more flexible that allows me to define machine 'classes' (e.g. based on similar hardware configurations etc.). I have a trivial suggestion (patches below) to implement the former, and some ideas for the latter. At the moment the only host-specific variables available to pxeboot are: "boot.netif.hwaddr", "boot.netif.ip", and "dhcp.host-name". "loaddev" is also available but it is not machine-specific. The list of config files is specified in /boot/defaults/loader.conf in the "loader_conf_files" variable, and there is no way to override it from other files. So we need to change its default value to include the hostname, e.g. loader_conf_files="/boot/device.hints /boot/device.hints.${dhcp.host-name} /boot/loader.conf /boot/loader.conf.${dhcp.host-name}" (pardon the ling line -- forth does not allow line breaks) Also we need to redefine the function set_conf_files in /boot/support.4th so that it can expand ${variable} : set_conf_files conf_files .addr @ ?dup if free-memory then set_environment_variable s" loader_conf_files" getenv strdup conf_files .len ! conf_files .addr ! ; (this is actually a slight simplification of the existing code). It might be useful to let dhcp pass more parameters to pxeboot so e.g. we can expand it to a 'machine class' which can be used for multiple machines. This should be relatively trivial to impelemnt, but it requires modifications to the pxeboot binary -- no big deal since this is something centralized. Comments ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 02:05:42 2008 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 3A4EB1065672 for ; Sat, 22 Nov 2008 02:05:42 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 02CD58FC12 for ; Sat, 22 Nov 2008 02:05:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1170432rvf.43 for ; Fri, 21 Nov 2008 18:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=zUl78LfHg9iw2kO5VbbDgxpwI4wQcWpXW1/yj+z8udo=; b=vG6TpXm1Df4dbG5M4amIs+ZeHGI+3n6YzR/fN98npHWNfOSBpIwS7AK0cFaWKwEM32 EJxjYvnw6zKbbdCJ5ZgPwrJennLuyME1l7vGkgxRz8RjIM432tbSikk/3MIFykEWBxZ9 LYqEB1NVoMuOYPu/JcNpu8OSNWUzTmAc/kFzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Pky2o0g49I7xkkANlymbvqyrQPW0BD/BHqjEKMqxw8szGhiAiS9JAuY5g8Nn4gp7eJ 7XTmjvrvd7o4+CDNAyB3+L/eakUP7+X+ylHdgFfvXrVpmPpWNlmYuoHD9JsqYpVQG/Q6 t76Pa78MfsCpAsXB1bdJa6TTq9Nigg63PhmlQ= Received: by 10.141.98.18 with SMTP id a18mr606187rvm.194.1227318232948; Fri, 21 Nov 2008 17:43:52 -0800 (PST) Received: by 10.141.79.14 with HTTP; Fri, 21 Nov 2008 17:43:52 -0800 (PST) Message-ID: <7d6fde3d0811211743q56e24d3dhe821e02611da3cb4@mail.gmail.com> Date: Fri, 21 Nov 2008 17:43:52 -0800 From: "Garrett Cooper" To: "Luigi Rizzo" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: current@freebsd.org Subject: Re: src/sys/boot/common/load.c unused ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 02:05:42 -0000 On Thu, Nov 20, 2008 at 10:45 AM, Luigi Rizzo wrote: > while debugging the misbehaviour of pxeboot on certain machines, > i noticed that the file src/sys/boot/common/load.c seems to be > unused -- in fact, i could not find a reference to this file (or the > filedup() function that it implements) anywhere. > > Is it supposed to be used somehow, or it is ok to remove it ? > > cheers > luigi Try removing it and see if a compile fails. If not, then try booting from a known working machine to see if PXE booting still functions. -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 03:40:42 2008 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 0DB7C1065674; Sat, 22 Nov 2008 03:40:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id BA4408FC16; Sat, 22 Nov 2008 03:40:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAM3ed3h046648; Fri, 21 Nov 2008 22:40:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAM3ecpD063009; Fri, 21 Nov 2008 22:40:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 97E1073039; Fri, 21 Nov 2008 22:40:38 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122034038.97E1073039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 22:40:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 03:40:42 -0000 TB --- 2008-11-22 01:31:03 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 01:31:03 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-11-22 01:31:03 - cleaning the object tree TB --- 2008-11-22 01:31:24 - cvsupping the source tree TB --- 2008-11-22 01:31:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-11-22 01:31:31 - building world TB --- 2008-11-22 01:31:31 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 01:31:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 01:31:31 - TARGET=ia64 TB --- 2008-11-22 01:31:31 - TARGET_ARCH=ia64 TB --- 2008-11-22 01:31:31 - TZ=UTC TB --- 2008-11-22 01:31:31 - __MAKE_CONF=/dev/null TB --- 2008-11-22 01:31:31 - cd /src TB --- 2008-11-22 01:31:31 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 01:31:34 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 03:19:23 UTC 2008 TB --- 2008-11-22 03:19:23 - generating LINT kernel config TB --- 2008-11-22 03:19:23 - cd /src/sys/ia64/conf TB --- 2008-11-22 03:19:23 - /usr/bin/make -B LINT TB --- 2008-11-22 03:19:23 - building LINT kernel TB --- 2008-11-22 03:19:23 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 03:19:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 03:19:23 - TARGET=ia64 TB --- 2008-11-22 03:19:23 - TARGET_ARCH=ia64 TB --- 2008-11-22 03:19:23 - TZ=UTC TB --- 2008-11-22 03:19:23 - __MAKE_CONF=/dev/null TB --- 2008-11-22 03:19:23 - cd /src TB --- 2008-11-22 03:19:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 03:19:23 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0xa2f2): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 03:40:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 03:40:38 - ERROR: failed to build lint kernel TB --- 2008-11-22 03:40:38 - 6411.57 user 439.20 system 7774.59 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 04:41:52 2008 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 D07E81065670; Sat, 22 Nov 2008 04:41:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A86C28FC08; Sat, 22 Nov 2008 04:41:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAM4fmmN016503; Fri, 21 Nov 2008 23:41:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAM4fmio011473; Fri, 21 Nov 2008 23:41:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 44BA773039; Fri, 21 Nov 2008 23:41:48 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122044148.44BA773039@freebsd-current.sentex.ca> Date: Fri, 21 Nov 2008 23:41:48 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 04:41:53 -0000 TB --- 2008-11-22 03:02:50 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 03:02:50 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-11-22 03:02:50 - cleaning the object tree TB --- 2008-11-22 03:03:18 - cvsupping the source tree TB --- 2008-11-22 03:03:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-11-22 03:03:25 - building world TB --- 2008-11-22 03:03:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 03:03:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 03:03:25 - TARGET=powerpc TB --- 2008-11-22 03:03:25 - TARGET_ARCH=powerpc TB --- 2008-11-22 03:03:25 - TZ=UTC TB --- 2008-11-22 03:03:25 - __MAKE_CONF=/dev/null TB --- 2008-11-22 03:03:25 - cd /src TB --- 2008-11-22 03:03:25 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 03:03:27 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 04:26:46 UTC 2008 TB --- 2008-11-22 04:26:46 - generating LINT kernel config TB --- 2008-11-22 04:26:46 - cd /src/sys/powerpc/conf TB --- 2008-11-22 04:26:46 - /usr/bin/make -B LINT TB --- 2008-11-22 04:26:46 - building LINT kernel TB --- 2008-11-22 04:26:46 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 04:26:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 04:26:46 - TARGET=powerpc TB --- 2008-11-22 04:26:46 - TARGET_ARCH=powerpc TB --- 2008-11-22 04:26:46 - TZ=UTC TB --- 2008-11-22 04:26:46 - __MAKE_CONF=/dev/null TB --- 2008-11-22 04:26:46 - cd /src TB --- 2008-11-22 04:26:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 04:26:46 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 -ffreestanding -fstack-protector -Werror vers.c linking kernel hwpmc_mod.o(.text+0x3328): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 04:41:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 04:41:48 - ERROR: failed to build lint kernel TB --- 2008-11-22 04:41:48 - 4768.45 user 414.22 system 5937.37 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 05:16:59 2008 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 A3EE11065675; Sat, 22 Nov 2008 05:16:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7E6328FC0C; Sat, 22 Nov 2008 05:16:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAM5GuEr017928; Sat, 22 Nov 2008 00:16:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAM5Gudd084564; Sat, 22 Nov 2008 00:16:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1C90673039; Sat, 22 Nov 2008 00:16:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122051656.1C90673039@freebsd-current.sentex.ca> Date: Sat, 22 Nov 2008 00:16:56 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 05:16:59 -0000 TB --- 2008-11-22 03:40:38 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 03:40:38 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-22 03:40:38 - cleaning the object tree TB --- 2008-11-22 03:41:06 - cvsupping the source tree TB --- 2008-11-22 03:41:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-22 03:41:14 - building world TB --- 2008-11-22 03:41:14 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 03:41:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 03:41:14 - TARGET=sparc64 TB --- 2008-11-22 03:41:14 - TARGET_ARCH=sparc64 TB --- 2008-11-22 03:41:14 - TZ=UTC TB --- 2008-11-22 03:41:14 - __MAKE_CONF=/dev/null TB --- 2008-11-22 03:41:14 - cd /src TB --- 2008-11-22 03:41:14 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 03:41:16 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 05:00:56 UTC 2008 TB --- 2008-11-22 05:00:56 - generating LINT kernel config TB --- 2008-11-22 05:00:56 - cd /src/sys/sparc64/conf TB --- 2008-11-22 05:00:56 - /usr/bin/make -B LINT TB --- 2008-11-22 05:00:56 - building LINT kernel TB --- 2008-11-22 05:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 05:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 05:00:56 - TARGET=sparc64 TB --- 2008-11-22 05:00:56 - TARGET_ARCH=sparc64 TB --- 2008-11-22 05:00:56 - TZ=UTC TB --- 2008-11-22 05:00:56 - __MAKE_CONF=/dev/null TB --- 2008-11-22 05:00:56 - cd /src TB --- 2008-11-22 05:00:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 05:00:56 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 05:16:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 05:16:56 - ERROR: failed to build lint kernel TB --- 2008-11-22 05:16:56 - 4577.24 user 410.80 system 5777.43 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 09:27:12 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7168106564A for ; Sat, 22 Nov 2008 09:27:12 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 479EF8FC12 for ; Sat, 22 Nov 2008 09:27:12 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (p5495728E.dip.t-dialin.net [84.149.114.142]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id mAM9R9Gt027573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Nov 2008 10:27:10 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id mAM90aLo002343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 10:00:36 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id mAM90Zsb002342; Sat, 22 Nov 2008 10:00:35 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Sat, 22 Nov 2008 10:00:35 +0100 From: Ulrich Spoerlein To: "O. Hartmann" Message-ID: <20081122090035.GB1394@roadrunner.spoerlein.net> Mail-Followup-To: "O. Hartmann" , freebsd-current@FreeBSD.org References: <4923E685.3060805@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4923E685.3060805@zedat.fu-berlin.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@FreeBSD.org Subject: Re: OpenLDAP 2.4.11/12 and FreeBSD 8.0/AMD64 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 09:27:12 -0000 On Wed, 19.11.2008 at 10:12:21 +0000, O. Hartmann wrote: > I'm wondering if someone out here has successfully running OpenLDAP > 2.4.11/12 slapd on a most recently compiled FreeBSD 8.0/amd64 system. If > so, please let me know. On our experimental host (FBSD > 8.0/CURRENT/AMD64) slapd dies with signal 11 immediately after starting. Have you tried running it as root? It likes to die if some permissions are not fullfilled. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 09:27:13 2008 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 389C21065674 for ; Sat, 22 Nov 2008 09:27:13 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADD638FC13 for ; Sat, 22 Nov 2008 09:27:12 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (p5495728E.dip.t-dialin.net [84.149.114.142]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id mAM9R9Gv027573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Nov 2008 10:27:11 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id mAM9QxPS002672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 10:26:59 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id mAM9Qvff002671; Sat, 22 Nov 2008 10:26:57 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Sat, 22 Nov 2008 10:26:57 +0100 From: Ulrich Spoerlein To: Luigi Rizzo Message-ID: <20081122092657.GC1394@roadrunner.spoerlein.net> Mail-Followup-To: Luigi Rizzo , current@freebsd.org References: <20081122012351.GA98158@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081122012351.GA98158@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@FreeBSD.org Subject: Re: RFC - per-host configuration of pxe booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 09:27:13 -0000 On Sat, 22.11.2008 at 02:23:51 +0100, Luigi Rizzo wrote: > The goal of this email is to figure out how to load host-specific > configurations from pxeboot -- maybe as simple as loading > /boot/loader.conf.${hostname} and possibly something slightly more > flexible that allows me to define machine 'classes' (e.g. based on > similar hardware configurations etc.). > > loader_conf_files="/boot/device.hints /boot/device.hints.${dhcp.host-name} /boot/loader.conf /boot/loader.conf.${dhcp.host-name}" > > It might be useful to let dhcp pass more parameters to pxeboot > so e.g. we can expand it to a 'machine class' which can be used > for multiple machines. This should be relatively trivial to impelemnt, > but it requires modifications to the pxeboot binary -- no big deal > since this is something centralized. Hi Luigi, while the dhcp host-name is a good start, you should definitely add a dhcp class-name (vendor-class-identifier) to make it useful for booting a whole range of thin clients, for example. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 09:48:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EC531065673 for ; Sat, 22 Nov 2008 09:48:58 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id B70088FC0A for ; Sat, 22 Nov 2008 09:48:57 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: by ti-out-0910.google.com with SMTP id i7so1432720tid.9 for ; Sat, 22 Nov 2008 01:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:to:references:subject :message-id:organization:x-mailer:mime-version:content-type :content-transfer-encoding:from; bh=mNaCgqwMQDbVvocdLa99Jqv3pz8uHgd79TiWHKs9QWI=; b=lgi80wL9UeC9WuIgNwf0bVdbbt9d5CpCMzKlfk23+SZjNKv/F9URYrPdkRe/JSrArz tfuiv5HFfNKzIFU3Ndsj+TCKA22QWPo/PYqvoJssL8ooUBIfxpS7fqf7enO1/c4hJrkQ xz0d/+zM829zZ2ybytr/sh3CHJ0rYHLtr1uDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:references:subject:message-id:organization:x-mailer :mime-version:content-type:content-transfer-encoding:from; b=HC+dTPHxY7iT1HcKdH8mo0HVxIcCG7gVfiBBSA2mc6fUWidn427X2Or37u74tafDd5 kVKlX4SdBuuhWe8gqszOA+DqruOOrvAOsbIMg86Ov7c5zlhkB4vHKNOL5gOdF9SsFsar eZ3TquyhcAJQOXT6OEYHbIckyuMDYhzq1E6ZI= Received: by 10.110.60.2 with SMTP id i2mr1963465tia.21.1227347336420; Sat, 22 Nov 2008 01:48:56 -0800 (PST) Received: from bear ([222.187.10.52]) by mx.google.com with ESMTPS id a14sm4153001tia.12.2008.11.22.01.48.53 (version=SSLv3 cipher=RC4-MD5); Sat, 22 Nov 2008 01:48:54 -0800 (PST) Date: Sat, 22 Nov 2008 17:48:47 +0800 To: "freebsd-current" References: <9659.134.146.0.43.1226917418.squirrel@webmail.xs4all.nl>, <200811192248064374198@Gmail.com> Message-ID: <200811221748449378719@Gmail.com> Organization: Freebear Develop Group X-mailer: Foxmail 6, 13, 102, 15 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit From: Bear Cc: Subject: Re: Re: My GNOME2 cannot 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: Sat, 22 Nov 2008 09:48:58 -0000 hi, hi, i have edit my ~/.xinitrc to exec dbus-launch --exit-with-session gnome-session and /etc/rc.conf to dbus_enable="YES" hald_enable="YES" but it takes no effect.Maybe there is really some compatability problem in 'current-package' and FreeBSD 7.0. but I really want to use current packages.What can I do to upgrade my FreeBSD 7.0 to 8.0 CURRENT? ------------------ Bear 2008-11-19 ------------------------------------------------------------- From:SirDice Date2008-11-17 18:23:41 On Sun, November 16, 2008 04:50, Bear wrote: > hi, > I have use these commands to install GNOME to my new-installed FreeBSD > 7.0: > > pkg_add -r xorg > pkg_add -r gnome-session > pkg_add -r gnome2-lite > > and then,I reboot my computer and use user Bear to login. > then I type in > > echo "/usr/local/bin/gnome-session" > ~/.xinitrc > > then I type in > > startx > > but it give me a error > the summary of the error is below: > > Could not lock the file "/var/tmp/gconf-test-locking-file-CB9IKU" > The error was "Invalid argument"(errno = 22) Add the following to rc.conf: dbus_enable="YES" hald_enable="YES" ~/.xinitrc should look like this: exec dbus-launch --exit-with-session gnome-session Make sure both dbus and hald are running before startx. HTH Remko C. > > What Can I Do??thx! > > BTW:I have been set my PACKAGEROOT to > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-current/Lat > est/ > > -------------- > Bear > 2008-11-16 > > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 10:24:46 2008 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 4C5301065672 for ; Sat, 22 Nov 2008 10:24:46 +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 EDE808FC13 for ; Sat, 22 Nov 2008 10:24:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1L3pQX-000MPo-IF; Sat, 22 Nov 2008 12:09:21 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Luigi Rizzo In-reply-to: <20081122012351.GA98158@onelab2.iet.unipi.it> References: <20081122012351.GA98158@onelab2.iet.unipi.it> Comments: In-reply-to Luigi Rizzo message dated "Sat, 22 Nov 2008 02:23:51 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Nov 2008 12:09:21 +0200 From: Danny Braniss Message-ID: Cc: current@freebsd.org Subject: Re: RFC - per-host configuration of pxe booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 10:24:46 -0000 > [this mailing list is as good as anyone i guess... feel free > to forward it if you believe there is a more appropriate forum] > > The goal of this email is to figure out how to load host-specific > configurations from pxeboot -- maybe as simple as loading > /boot/loader.conf.${hostname} and possibly something slightly more > flexible that allows me to define machine 'classes' (e.g. based on > similar hardware configurations etc.). > why not use DHCP? you need it to boot the diskless anyways, and it can provide a wealth of information. The code has been around for many years. for example, in the dhcpd.conf: option FBSD.ind1 "hw.msk.legacy_intr=1"; option FBSD.ind2 "machdep.conspeed=115200"; option FBSD.rc-conf4 "rc.ws" these are placed, by bootp.c, in kenv. > I have a trivial suggestion (patches below) to implement the former, > and some ideas for the latter. > > At the moment the only host-specific variables available to pxeboot > are: "boot.netif.hwaddr", "boot.netif.ip", and "dhcp.host-name". > > "loaddev" is also available but it is not machine-specific. > > The list of config files is specified in /boot/defaults/loader.conf > in the "loader_conf_files" variable, and there is no way > to override it from other files. > So we need to change its default value to include the hostname, e.g. > > loader_conf_files="/boot/device.hints /boot/device.hints.${dhcp.host-name} /boot/loader.conf /boot/loader.conf.${dhcp.host-name}" > > (pardon the ling line -- forth does not allow line breaks) > > Also we need to redefine the function set_conf_files > in /boot/support.4th so that it can expand ${variable} > > : set_conf_files > conf_files .addr @ ?dup if free-memory then > set_environment_variable > s" loader_conf_files" getenv > strdup > conf_files .len ! conf_files .addr ! > ; > > (this is actually a slight simplification of the existing code). > > It might be useful to let dhcp pass more parameters to pxeboot > so e.g. we can expand it to a 'machine class' which can be used > for multiple machines. This should be relatively trivial to impelemnt, > but it requires modifications to the pxeboot binary -- no big deal > since this is something centralized. > > Comments ? > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 10:49:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4661065672 for ; Sat, 22 Nov 2008 10:49:04 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8428FC14 for ; Sat, 22 Nov 2008 10:49:03 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so570883yxb.13 for ; Sat, 22 Nov 2008 02:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=YtvqzTILMaG/nSUt91jYveqggkrPG3j547Dvgz1BCy8=; b=YiIUqYuMR0Yq5AnehLyDVA6BU89PVH86YfogaBlKNm2O2AMFDFBX7J+CCR3WaHr/Eu Zi0JPJ8awAT0SNPwqmuY0xYV8fnqBJuEnu6nLhdft+IAJrkZvOgxAKXEFJZYZbSPekF2 UwjbI3V9cMZ0L+xNgkNhqhMg/8EPfohepVnDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=QP0WWsOPfloFtAgOjSLuqPWFlr2tYc4FObM3ZWdKSll4M9UibF4wGhc+mcCFu9gfOk WI6taei9IubXWdu81Aisl5EDDS8xIK52AqSV38UnNgurhYyhuczoyZMwC/wFYhzukW2a ByiGcwSKq6Eg0uX4TshlNtG8Pig8m2hpuhwzM= Received: by 10.150.124.2 with SMTP id w2mr2840240ybc.41.1227350943481; Sat, 22 Nov 2008 02:49:03 -0800 (PST) Received: by 10.151.106.2 with HTTP; Sat, 22 Nov 2008 02:49:03 -0800 (PST) Message-ID: <3481d8e60811220249q47462b14v84c69bc9a9a006b0@mail.gmail.com> Date: Sat, 22 Nov 2008 10:49:03 +0000 From: "Benoit Calvez" Sender: dzentoo@gmail.com To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Google-Sender-Auth: 8ef51a83c4beb2d3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: zfs, installworld and chflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 10:49:04 -0000 just to point out a little problem if having your /usr onto a zfs pool : faith# zfs create save/test faith# zfs set mountpoint=/mnt/test save/test faith# cd /usr/src/ faith# make installworld DESTDIR=/mnt/test will produce a -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) install -o root -g wheel -m 444 dir-tmpl /mnt/test/usr/share/info/dir ===> lib (install) ===> lib/csu/amd64 (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /mnt/test/usr/lib ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /mnt/test/usr/lib install -C -o root -g wheel -m 444 libc_p.a /mnt/test/usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /mnt/test/lib install: /mnt/test/lib/libc.so.7: chflags: Invalid argument thanks for all the work you've done, zfs is a great feature for freebsd and it simplify hard drive / partition management. -- Benoit Calvez. From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 10:55:36 2008 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 E382D106564A for ; Sat, 22 Nov 2008 10:55:36 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF698FC22 for ; Sat, 22 Nov 2008 10:55:36 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E1ADB73098; Sat, 22 Nov 2008 12:00:08 +0100 (CET) Date: Sat, 22 Nov 2008 12:00:08 +0100 From: Luigi Rizzo To: Danny Braniss Message-ID: <20081122110008.GB12671@onelab2.iet.unipi.it> References: <20081122012351.GA98158@onelab2.iet.unipi.it> 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: RFC - per-host configuration of pxe booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 10:55:37 -0000 On Sat, Nov 22, 2008 at 12:09:21PM +0200, Danny Braniss wrote: > > [this mailing list is as good as anyone i guess... feel free > > to forward it if you believe there is a more appropriate forum] > > > > The goal of this email is to figure out how to load host-specific > > configurations from pxeboot -- maybe as simple as loading > > /boot/loader.conf.${hostname} and possibly something slightly more > > flexible that allows me to define machine 'classes' (e.g. based on > > similar hardware configurations etc.). > > > > why not use DHCP? you need it to boot the diskless anyways, and it can provide > a wealth of information. The code has been around for many years. > for example, in the dhcpd.conf: > option FBSD.ind1 "hw.msk.legacy_intr=1"; > option FBSD.ind2 "machdep.conspeed=115200"; > option FBSD.rc-conf4 "rc.ws" > these are placed, by bootp.c, in kenv. sure, DHCP is the intended transport for this information, however the support you mention is not yet in the source tree as far as i can tell. Perhaps you are referring to your patches at ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/5.2-bootp.c.diffs ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 10:59:22 2008 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 156891065670 for ; Sat, 22 Nov 2008 10:59:22 +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 B4C748FC08 for ; Sat, 22 Nov 2008 10:59:21 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1L3qCu-000Mma-Mi; Sat, 22 Nov 2008 12:59:20 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Ulrich Spoerlein In-reply-to: <20081122092657.GC1394@roadrunner.spoerlein.net> References: <20081122012351.GA98158@onelab2.iet.unipi.it> <20081122092657.GC1394@roadrunner.spoerlein.net> Comments: In-reply-to Ulrich Spoerlein message dated "Sat, 22 Nov 2008 10:26:57 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Nov 2008 12:59:20 +0200 From: Danny Braniss Message-ID: Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC - per-host configuration of pxe booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 10:59:22 -0000 > On Sat, 22.11.2008 at 02:23:51 +0100, Luigi Rizzo wrote: > > The goal of this email is to figure out how to load host-specific > > configurations from pxeboot -- maybe as simple as loading > > /boot/loader.conf.${hostname} and possibly something slightly more > > flexible that allows me to define machine 'classes' (e.g. based on > > similar hardware configurations etc.). > > > > loader_conf_files="/boot/device.hints /boot/device.hints.${dhcp.host-name} /boot/loader.conf /boot/loader.conf.${dhcp.host-name}" > > > > It might be useful to let dhcp pass more parameters to pxeboot > > so e.g. we can expand it to a 'machine class' which can be used > > for multiple machines. This should be relatively trivial to impelemnt, > > but it requires modifications to the pxeboot binary -- no big deal > > since this is something centralized. > > Hi Luigi, > > while the dhcp host-name is a good start, you should definitely add a > dhcp class-name (vendor-class-identifier) to make it useful for booting > a whole range of thin clients, for example. the bootp.c in ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot sets it to FreeBSD and so in dhcpd.conf: class "freeBSD" { option FBSD.kernel "kernel"; match if substring (option vendor-class-identifier, 0, 7) = "FreeBSD"; option root-path "132.65.16.52:/vol/binary/bsd/amd64/7.0"; vendor-option-space FBSD; option FBSD.rc-conf "conf/rc.conf"; # the following only works if server is FreeBSD #option FBSD.boot-nfsroot-options "nfsv3"; } ... and group { # fbsd-6.1-bsd-i386-u filename "freebsd/pxeboot"; option root-path "132.65.16.112:/d/3"; option FBSD.conf-path="fr-01:/vol/system/share/conf"; option FBSD.rc-conf0 "rc.conf"; option FBSD.rc-conf2 "rc.conf-6"; option FBSD.rc-conf4 "rc.conf-6.1"; host wrap-3 { fixed-address wrap-3; hardware ethernet 00:0D:B9:04:C3:9C; #filename "freebsd/kernel.wrap"; filename "freebsd/pxeboot-r"; option root-path "132.65.16.112:/d/2"; } ... } danny From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 11:34:44 2008 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 B4CBF1065677 for ; Sat, 22 Nov 2008 11:34:44 +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 5F66F8FC14 for ; Sat, 22 Nov 2008 11:34:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1L3ql9-000N8X-7K; Sat, 22 Nov 2008 13:34:43 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Luigi Rizzo In-reply-to: <20081122110008.GB12671@onelab2.iet.unipi.it> References: <20081122012351.GA98158@onelab2.iet.unipi.it> <20081122110008.GB12671@onelab2.iet.unipi.it> Comments: In-reply-to Luigi Rizzo message dated "Sat, 22 Nov 2008 12:00:08 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Nov 2008 13:34:43 +0200 From: Danny Braniss Message-ID: Cc: current@freebsd.org Subject: Re: RFC - per-host configuration of pxe booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 11:34:44 -0000 > On Sat, Nov 22, 2008 at 12:09:21PM +0200, Danny Braniss wrote: > > > [this mailing list is as good as anyone i guess... feel free > > > to forward it if you believe there is a more appropriate forum] > > > > > > The goal of this email is to figure out how to load host-specific > > > configurations from pxeboot -- maybe as simple as loading > > > /boot/loader.conf.${hostname} and possibly something slightly more > > > flexible that allows me to define machine 'classes' (e.g. based on > > > similar hardware configurations etc.). > > > > > > > why not use DHCP? you need it to boot the diskless anyways, and it can provide > > a wealth of information. The code has been around for many years. > > for example, in the dhcpd.conf: > > option FBSD.ind1 "hw.msk.legacy_intr=1"; > > option FBSD.ind2 "machdep.conspeed=115200"; > > option FBSD.rc-conf4 "rc.ws" > > these are placed, by bootp.c, in kenv. > > sure, DHCP is the intended transport for this information, however the > support you mention is not yet in the source tree as far as i can tell. > Perhaps you are referring to your patches at > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/5.2-bootp.c.diffs ? > I did send a PR, but it must have gotten lost ... I think you should look at bootp.c, it's newer :-) I just updated it, because resently I discovered a nasty bug that was there from the beginning of time. BTW, I'm not that proud of the coding, but didn't want to make too many changes to bootp (it is ancient :-) and it was done when I was starting with intel/freebsd. > cheers > luigi chau danny From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 11:36:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6BF01065679 for ; Sat, 22 Nov 2008 11:36:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id A64098FC21 for ; Sat, 22 Nov 2008 11:36:12 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 766F328449 for ; Sat, 22 Nov 2008 19:36:11 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1283DEB4642; Sat, 22 Nov 2008 19:36:11 +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 zVSmBO6zb4yb; Sat, 22 Nov 2008 19:36:04 +0800 (CST) Received: from delta.delphij.net (c-76-103-40-85.hsd1.ca.comcast.net [76.103.40.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id AA22CEB463A; Sat, 22 Nov 2008 19:36:03 +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=volcNrDeAfmg+VZA9L+vZqznph72/nRJ6fg7WFxTL8sSaqQb2AJtVm56+sZx9d4vv mRZ9ieqRiuO+Nu+cfA66A== Message-ID: <4927EE9F.6080100@delphij.net> Date: Sat, 22 Nov 2008 03:35:59 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Thunderbird 2.0.0.17 (X11/20081105) MIME-Version: 1.0 To: Benoit Calvez References: <3481d8e60811220249q47462b14v84c69bc9a9a006b0@mail.gmail.com> In-Reply-To: <3481d8e60811220249q47462b14v84c69bc9a9a006b0@mail.gmail.com> 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: freebsd-current@freebsd.org Subject: Re: zfs, installworld and chflags 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: Sat, 22 Nov 2008 11:36:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benoit Calvez wrote: [snip] > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /mnt/test/lib > install: /mnt/test/lib/libc.so.7: chflags: Invalid argument > > thanks for all the work you've done, zfs is a great feature for freebsd and > it simplify hard drive / partition management. For the record, defining NO_FSCHG= would work around this (I got bite by this as well since I use ZFS / :) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkn7p8ACgkQi+vbBBjt66D+VQCcDXPEVHEqcXasGXuDYgxTkI+I DiIAn0ynUj5y+xi6sot6UPs5fwZBaORi =lzPr -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 12:06:25 2008 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 2A3F61065680 for ; Sat, 22 Nov 2008 12:06:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id B6DB28FC0C for ; Sat, 22 Nov 2008 12:06:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1L3r0U-000FBh-Fg; Sat, 22 Nov 2008 13:50:34 +0200 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 mAMBoSU4047771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 13:50:28 +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 mAMBoSM3074161; Sat, 22 Nov 2008 13:50:28 +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 mAMBoSOs074160; Sat, 22 Nov 2008 13:50:28 +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: Sat, 22 Nov 2008 13:50:28 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20081122115028.GB6408@deviant.kiev.zoral.com.ua> References: <200811201627.58289.jhb@freebsd.org> <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> <200811211452.02545.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline In-Reply-To: <200811211452.02545.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on 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 X-Virus-Scanned: mail.terabit.net.ua 1L3r0U-000FBh-Fg 96d223be7f6f5cfde7235028465312ec X-Terabit: YES Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 12:06:25 -0000 --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 21, 2008 at 02:52:02PM -0500, John Baldwin wrote: > On Thursday 20 November 2008 06:32:25 pm Paul B. Mahol wrote: > > On 11/20/08, John Baldwin wrote: > > > So this patch is fairly minimal since udf(4) is currently read-only. = The > > > changes include: > > > > > > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doin= g it > > > only > > > in udf_root(). This matches the behavior of other operating system= s and > > > correctly tags the root vnode with VV_ROOT in the unlikely case tha= t we > > > create the vnode during a call to ufs_vget() that does not come from > > > ufs_root(). > > > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode l= ock=20 > is > > > used while creating the new vnode (same as UFS). > > > * Allow lock recursion (XXX: not really sure this is needed actually). > > > * Allow shared vnode locks on non-fifos. > > > * Honor the requested locking flags (shared vs exclusive) instead of= =20 > always > > > using exclusive vnode locks during a lookup operation. > > > * Handle "." lookups the same way other filesystems do by just bumpin= g the > > > reference on 'dvp' rather than calling udf_vget(). > > > > > > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch > > > > > > I have only verified that this compiles and would appreciate it if so= me > > > folks > > > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabl= ed. > >=20 > > I lightly tested it with md(4) on 47M size iso created with k3b > > (it contains two files) > >=20 > > I only got this lor related to udf: > >=20 > > lock order reversal: > > 1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442 > > 2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > > 3rd 0xc4399488 udf (udf) @ > > /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625 >=20 > I've updated the patch at the same URL above to fix this LOR. udf_vget() does insmntque() before vnode is fully initialized, allowing other threads to find the vnode on the mount list. This is typical for !MPSAFE fs, and it seems corresponding call was not marked XXX for udf. udf_lookup for ISDOTDOT case unlocks dvp before vget'ing "..", allowing the same race on forced unmount as ufs (I will finally commit ufs patch today). The race happens for !MPSAFE code too, but it is easier to execute without Giant. --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkkn8gMACgkQC3+MBN1Mb4jVOwCcDQGGhm0gQ++oiEAy3KptHUFF sNAAoMDBs3rcsTLN+eS3GJ1jQtGhy3lN =xTI5 -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 12:10:59 2008 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 9B056106564A; Sat, 22 Nov 2008 12:10:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 690428FC0C; Sat, 22 Nov 2008 12:10:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMCAtAa064941; Sat, 22 Nov 2008 07:10:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMCAtud086648; Sat, 22 Nov 2008 07:10:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D692E73039; Sat, 22 Nov 2008 07:10:54 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122121054.D692E73039@freebsd-current.sentex.ca> Date: Sat, 22 Nov 2008 07:10:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 12:10:59 -0000 TB --- 2008-11-22 10:20:10 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 10:20:10 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-11-22 10:20:10 - cleaning the object tree TB --- 2008-11-22 10:20:44 - cvsupping the source tree TB --- 2008-11-22 10:20:44 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-11-22 10:20:53 - building world TB --- 2008-11-22 10:20:53 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 10:20:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 10:20:53 - TARGET=ia64 TB --- 2008-11-22 10:20:53 - TARGET_ARCH=ia64 TB --- 2008-11-22 10:20:53 - TZ=UTC TB --- 2008-11-22 10:20:53 - __MAKE_CONF=/dev/null TB --- 2008-11-22 10:20:53 - cd /src TB --- 2008-11-22 10:20:53 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 10:20:55 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 12:08:43 UTC 2008 TB --- 2008-11-22 12:08:43 - generating LINT kernel config TB --- 2008-11-22 12:08:43 - cd /src/sys/ia64/conf TB --- 2008-11-22 12:08:43 - /usr/bin/make -B LINT TB --- 2008-11-22 12:08:43 - building LINT kernel TB --- 2008-11-22 12:08:43 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 12:08:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 12:08:43 - TARGET=ia64 TB --- 2008-11-22 12:08:43 - TARGET_ARCH=ia64 TB --- 2008-11-22 12:08:43 - TZ=UTC TB --- 2008-11-22 12:08:43 - __MAKE_CONF=/dev/null TB --- 2008-11-22 12:08:43 - cd /src TB --- 2008-11-22 12:08:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 12:08:43 UTC 2008 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -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 /src/sys/dev/cxgb/cxgb_main.c:86:34: error: machine/intr_machdep.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 12:10:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 12:10:54 - ERROR: failed to build lint kernel TB --- 2008-11-22 12:10:54 - 5372.05 user 390.43 system 6644.01 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 12:36:09 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C821065675 for ; Sat, 22 Nov 2008 12:36:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 31D988FC17 for ; Sat, 22 Nov 2008 12:36:08 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=JAk6cRfIpHfeMEV4PocZXm9Ci5I3abjxY2G/tbvULNmfC+WtJs+05Fr4e4u6D3+I1kT8d6oni9BPvv1TUTBZGmJk70yXuljFsmur+BZ7W9azdfmm+Cfqbpa2fDDDHeHW9rZMku8xgbBpxZFOaVFwvQJYznXtOubFG70i3AHmzmQ=; Received: from phoenix.codelabs.ru (ppp91-78-248-208.pppoe.mtu-net.ru [91.78.248.208]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1L3riZ-00093n-9T; Sat, 22 Nov 2008 15:36:07 +0300 Date: Sat, 22 Nov 2008 15:36:03 +0300 From: Eygene Ryabinkin To: "O. Hartmann" , freebsd-current@FreeBSD.org Message-ID: <5HgkDVJq3x4BjywvA56krbYX2F4@20cDGM+8hsk/QFQ6RA5/3vpdoQo> References: <4923E685.3060805@zedat.fu-berlin.de> <20081122090035.GB1394@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="juZjCTNxrMaZdGZC" Content-Disposition: inline In-Reply-To: <20081122090035.GB1394@roadrunner.spoerlein.net> Sender: rea-fbsd@codelabs.ru Cc: Subject: Re: OpenLDAP 2.4.11/12 and FreeBSD 8.0/AMD64 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 12:36:09 -0000 --juZjCTNxrMaZdGZC Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sat, Nov 22, 2008 at 10:00:35AM +0100, Ulrich Spoerlein wrote: > On Wed, 19.11.2008 at 10:12:21 +0000, O. Hartmann wrote: > > I'm wondering if someone out here has successfully running OpenLDAP=20 > > 2.4.11/12 slapd on a most recently compiled FreeBSD 8.0/amd64 system. I= f=20 > > so, please let me know. On our experimental host (FBSD=20 > > 8.0/CURRENT/AMD64) slapd dies with signal 11 immediately after starting. 'slapd -d 255' and/or 'ktrace slapd'? Should shed some light into this. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --juZjCTNxrMaZdGZC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkn/LIACgkQthUKNsbL7YjQvACgs8CBxsflByP8Fev2q/ZTDxcd lisAn33PMW/lEAFUgjpkj5JDpViGrQZF =NC2w -----END PGP SIGNATURE----- --juZjCTNxrMaZdGZC-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 13:19:06 2008 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 6D66C10656F1; Sat, 22 Nov 2008 13:19:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0EC8FC1A; Sat, 22 Nov 2008 13:19:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMDJ353031581; Sat, 22 Nov 2008 08:19:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMDJ3rV011090; Sat, 22 Nov 2008 08:19:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7382E73039; Sat, 22 Nov 2008 08:19:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122131903.7382E73039@freebsd-current.sentex.ca> Date: Sat, 22 Nov 2008 08:19:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 13:19:06 -0000 TB --- 2008-11-22 11:49:56 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 11:49:56 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-11-22 11:49:56 - cleaning the object tree TB --- 2008-11-22 11:50:15 - cvsupping the source tree TB --- 2008-11-22 11:50:15 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-11-22 11:50:26 - building world TB --- 2008-11-22 11:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 11:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 11:50:26 - TARGET=powerpc TB --- 2008-11-22 11:50:26 - TARGET_ARCH=powerpc TB --- 2008-11-22 11:50:26 - TZ=UTC TB --- 2008-11-22 11:50:26 - __MAKE_CONF=/dev/null TB --- 2008-11-22 11:50:26 - cd /src TB --- 2008-11-22 11:50:26 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 11:50:28 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 13:13:35 UTC 2008 TB --- 2008-11-22 13:13:35 - generating LINT kernel config TB --- 2008-11-22 13:13:35 - cd /src/sys/powerpc/conf TB --- 2008-11-22 13:13:35 - /usr/bin/make -B LINT TB --- 2008-11-22 13:13:35 - building LINT kernel TB --- 2008-11-22 13:13:35 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 13:13:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 13:13:35 - TARGET=powerpc TB --- 2008-11-22 13:13:35 - TARGET_ARCH=powerpc TB --- 2008-11-22 13:13:35 - TZ=UTC TB --- 2008-11-22 13:13:35 - __MAKE_CONF=/dev/null TB --- 2008-11-22 13:13:35 - cd /src TB --- 2008-11-22 13:13:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 13:13:35 UTC 2008 >>> 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 [...] /src/sys/dev/bce/if_bce.c: In function 'bce_get_hw_rx_cons': /src/sys/dev/bce/if_bce.c:5671: error: '__ATOMIC_BARRIER' undeclared (first use in this function) /src/sys/dev/bce/if_bce.c:5671: error: (Each undeclared identifier is reported only once /src/sys/dev/bce/if_bce.c:5671: error: for each function it appears in.) /src/sys/dev/bce/if_bce.c: In function 'bce_rx_intr': /src/sys/dev/bce/if_bce.c:5732: error: '__ATOMIC_BARRIER' undeclared (first use in this function) /src/sys/dev/bce/if_bce.c: In function 'bce_get_hw_tx_cons': /src/sys/dev/bce/if_bce.c:6014: error: '__ATOMIC_BARRIER' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 13:19:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 13:19:03 - ERROR: failed to build lint kernel TB --- 2008-11-22 13:19:03 - 4230.65 user 396.61 system 5346.63 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 13:28:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5D7E1065673 for ; Sat, 22 Nov 2008 13:28:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE508FC13 for ; Sat, 22 Nov 2008 13:28:29 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E081745685; Sat, 22 Nov 2008 14:28:27 +0100 (CET) Received: from localhost (abhq250.neoplus.adsl.tpnet.pl [83.7.106.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D862945683; Sat, 22 Nov 2008 14:28:23 +0100 (CET) Date: Sat, 22 Nov 2008 14:28:26 +0100 From: Pawel Jakub Dawidek To: d@delphij.net Message-ID: <20081122132826.GA4061@garage.freebsd.pl> References: <3481d8e60811220249q47462b14v84c69bc9a9a006b0@mail.gmail.com> <4927EE9F.6080100@delphij.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <4927EE9F.6080100@delphij.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, Benoit Calvez Subject: Re: zfs, installworld and chflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 13:28:30 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 22, 2008 at 03:35:59AM -0800, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Benoit Calvez wrote: > [snip] > > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /mnt/test/lib > > install: /mnt/test/lib/libc.so.7: chflags: Invalid argument > >=20 > > thanks for all the work you've done, zfs is a great feature for freebsd= and > > it simplify hard drive / partition management. >=20 > For the record, defining NO_FSCHG=3D would work around this (I got bite by > this as well since I use ZFS / :) I just committed missing bits for chflags(2)/lchflags(2) support. Note that the only supported flags are: UF_NODUMP, SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJKAj5ForvXbEpPzQRApkrAJ0VP/6yXT3IZzY50jva2mgS1C/6cACgq5rB UTJ+cue9/wRyIRTQJSp8WG0= =MNby -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 13:47:59 2008 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 613CA106568F; Sat, 22 Nov 2008 13:47:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA828FC17; Sat, 22 Nov 2008 13:47:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMDluoa069670; Sat, 22 Nov 2008 08:47:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMDltb0012738; Sat, 22 Nov 2008 08:47:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 948C273039; Sat, 22 Nov 2008 08:47:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122134755.948C273039@freebsd-current.sentex.ca> Date: Sat, 22 Nov 2008 08:47:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 13:47:59 -0000 TB --- 2008-11-22 12:10:54 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 12:10:54 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-22 12:10:55 - cleaning the object tree TB --- 2008-11-22 12:11:22 - cvsupping the source tree TB --- 2008-11-22 12:11:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-22 12:11:30 - building world TB --- 2008-11-22 12:11:30 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 12:11:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 12:11:30 - TARGET=sparc64 TB --- 2008-11-22 12:11:30 - TARGET_ARCH=sparc64 TB --- 2008-11-22 12:11:30 - TZ=UTC TB --- 2008-11-22 12:11:30 - __MAKE_CONF=/dev/null TB --- 2008-11-22 12:11:30 - cd /src TB --- 2008-11-22 12:11:30 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 12:11:31 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 13:31:40 UTC 2008 TB --- 2008-11-22 13:31:40 - generating LINT kernel config TB --- 2008-11-22 13:31:40 - cd /src/sys/sparc64/conf TB --- 2008-11-22 13:31:40 - /usr/bin/make -B LINT TB --- 2008-11-22 13:31:40 - building LINT kernel TB --- 2008-11-22 13:31:40 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 13:31:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 13:31:40 - TARGET=sparc64 TB --- 2008-11-22 13:31:40 - TARGET_ARCH=sparc64 TB --- 2008-11-22 13:31:40 - TZ=UTC TB --- 2008-11-22 13:31:40 - __MAKE_CONF=/dev/null TB --- 2008-11-22 13:31:40 - cd /src TB --- 2008-11-22 13:31:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 13:31:40 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 13:47:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 13:47:55 - ERROR: failed to build lint kernel TB --- 2008-11-22 13:47:55 - 4575.52 user 418.46 system 5820.49 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 13:55:04 2008 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 887CD1065670 for ; Sat, 22 Nov 2008 13:55:04 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 1067C8FC14 for ; Sat, 22 Nov 2008 13:55:03 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so979285fgb.35 for ; Sat, 22 Nov 2008 05:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=zwJqZwYagNhw5At9qXjMDjs1XXeD5zeitQR5SoUOZdc=; b=A2KTU7/l9AjpPuTWXiuaxyRkVfjDM4UTwgZS2zgVq51jmwRb2vWjfSdf86528n/7/V 1X5HeWOZA3T5qMbrjq82ITLH++UWLzHTaY+VZz4v0rUfkQMz0A6oMBmb+6i/qQqgMtvI ZIWPJ2mgi5ZKs8tcnhmoQznd+5T7v/a7nrpu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aOQ+3uqFefZ+wQtEvF1IUhmu/lHyLIPZD5TO+sIOoeFXUDf+grx/PoKWncFNQADDW6 D8lcbZEni4pCX5kSX8+jmZ33k/0/D/RLn/sAxJ0tPCgMqjth0m3sEAInVGUmImCbFJXB y9x1DIUwOgVhovwHBzJi/K39x5MrEwgoouSfA= Received: by 10.86.60.14 with SMTP id i14mr1175785fga.21.1227360664643; Sat, 22 Nov 2008 05:31:04 -0800 (PST) Received: by 10.86.96.13 with HTTP; Sat, 22 Nov 2008 05:31:04 -0800 (PST) Message-ID: <84dead720811220531r56fd1a91x91962a926dcb2a03@mail.gmail.com> Date: Sat, 22 Nov 2008 13:31:04 +0000 From: "Joseph Koshy" To: "FreeBSD Tinderbox" In-Reply-To: <20081122051656.1C90673039@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081122051656.1C90673039@freebsd-current.sentex.ca> Cc: current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 13:55:04 -0000 > linking kernel > hwpmc_mod.o(.text+0x6308): In function `load': > : undefined reference to `pmc_md_finalize' > *** Error code 1 Uh-oh, I get to wear the pointy hat. Should be fixed in #185168. Koshy From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 14:44:48 2008 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 88B261065672 for ; Sat, 22 Nov 2008 14:44:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.244]) by mx1.freebsd.org (Postfix) with ESMTP id 241C28FC17 for ; Sat, 22 Nov 2008 14:44:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by hs-out-0708.google.com with SMTP id 54so643693hsz.11 for ; Sat, 22 Nov 2008 06:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jR6PqsB4Do5rFF12t+L8Ivb/Ej8cuHz9ufGySmo9Y0o=; b=c3gBykVN4Yz5hxuodMHpjaAyFa8vTh1VWCWZYJ6y7mmTRP5xFM8Lg6SCeUKt8ffiow HzVO41/JnV7XPehMopDiZ64f/mdKnt5PkRP8DYitJeAGzu7zcIK1RNwxrVS8tjrpQQag M2MmLfnAWdBFu5SdTwk9aLPrqccwdWAAU6Tnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=himSLUXnfSsoW8zA6DndLawuSe0MrmmvoJNLBEb2xAj+jMxkZrq7u+NADyvyb8u2K2 c+honrAKdPYiQBigvwn0H+1nOKWWqehdSh7yE0N/xMFozKekY7RNT2R60rsvA/48bzo3 884168dxWiwImDXuosWa+UsGjEw++OqvoAJ44= Received: by 10.231.35.193 with SMTP id q1mr32422ibd.13.1227365087228; Sat, 22 Nov 2008 06:44:47 -0800 (PST) Received: by 10.231.11.7 with HTTP; Sat, 22 Nov 2008 06:44:47 -0800 (PST) Message-ID: <3a142e750811220644v19acf60g7b0b0683fe73a1af@mail.gmail.com> Date: Sat, 22 Nov 2008 15:44:47 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <3a142e750811211602h3855e912g573f53b00f6ce452@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811201627.58289.jhb@freebsd.org> <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com> <200811211452.02545.jhb@freebsd.org> <3a142e750811211602h3855e912g573f53b00f6ce452@mail.gmail.com> Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Make udf(4) MPSAFE and use shared lookups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 14:44:48 -0000 On 11/22/08, Paul B. Mahol wrote: > On 11/21/08, John Baldwin wrote: >> On Thursday 20 November 2008 06:32:25 pm Paul B. Mahol wrote: >>> On 11/20/08, John Baldwin wrote: >>> > So this patch is fairly minimal since udf(4) is currently read-only. >>> > The >>> > changes include: >>> > >>> > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing >>> > it >>> > only >>> > in udf_root(). This matches the behavior of other operating systems >>> > and >>> > correctly tags the root vnode with VV_ROOT in the unlikely case that >>> > we >>> > create the vnode during a call to ufs_vget() that does not come from >>> > ufs_root(). >>> > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode >>> > lock >>> > >> is >>> > used while creating the new vnode (same as UFS). >>> > * Allow lock recursion (XXX: not really sure this is needed actually). >>> > * Allow shared vnode locks on non-fifos. >>> > * Honor the requested locking flags (shared vs exclusive) instead of >> always >>> > using exclusive vnode locks during a lookup operation. >>> > * Handle "." lookups the same way other filesystems do by just bumping >>> > the >>> > reference on 'dvp' rather than calling udf_vget(). >>> > >>> > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch >>> > >>> > I have only verified that this compiles and would appreciate it if some >>> > folks >>> > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS >>> > enabled. >>> >>> I lightly tested it with md(4) on 47M size iso created with k3b >>> (it contains two files) >>> >>> I only got this lor related to udf: >>> >>> lock order reversal: >>> 1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442 >>> 2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >>> 3rd 0xc4399488 udf (udf) @ >>> /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625 >> >> I've updated the patch at the same URL above to fix this LOR. >> >> -- >> John Baldwin >> > > Some bad news, using new patch (did not tested agains old one) I was able > to reliable panic system with 3.4GB iso, trying to play music files via > cplay. > > here is backtrack, from textdump: > > db:1:lockinfo> show locks > db:1:locks> show alllocks > Process 977 (python) thread 0xc43b4d80 (100087) > db:1:alllocks> show lockedvnods > Locked vnodes > db:0:kdb.enter.panic> show pcpu > cpuid = 1 > curthread = 0xc43b4d80: pid 977 "initial thread" > curpcb = 0xc3b67d90 > fpcurthread = none > idlethread = 0xc3d2ad80: pid 10 "idle: cpu1" > APIC ID = 1 > currentldt = 0x50 > spin locks held: > db:0:kdb.enter.panic> bt > Tracing pid 977 tid 100087 td 0xc43b4d80 > kdb_enter(c069b0df,c069b0df,c06a5d32,c3b67968,1,...) at kdb_enter+0x3a > panic(c06a5d32,10800,10000,c0686786,c3b679d0,...) at panic+0x131 > getblk(c4e0e10c,424,0,10800,0,...) at getblk+0x2d > breadn(c4e0e10c,424,0,10800,0,...) at breadn+0x44 > bread(c4e0e10c,424,0,10800,0,...) at bread+0x4c > udf_readatoffset(1a18,0,c50568d8,c50568dc,0,...) at udf_readatoffset+0xbb > udf_getfid(c4694680,ffffffff,c3b67cf8,c06a8594,c3b67c24,...) at > udf_getfid+0x1ca > udf_readdir(c3b67c24,0,c4555648,0,c3b67c5c,...) at udf_readdir+0xdc > VOP_READDIR_APV(c4faf280,c3b67c24,c06a8594,ff3,1a18,...) at > VOP_READDIR_APV+0xa0 > kern_getdirentries(c43b4d80,46,2844c000,1000,c3b67c78,...) at > kern_getdirentries+0x1bd > getdirentries(c43b4d80,c3b67cf8,10,c06a1b96,c06cfbe0,...) at > getdirentries+0x31 > syscall(c3b67d38) at syscall+0x261 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (196, FreeBSD ELF32, getdirentries), eip = 0x28251e4b, esp > = 0xbfbfe27c, ebp = 0xbfbfe2a8 --- > > > and panic message: > > uiomove returned -1 > panic: getblk: size(67584) > MAXBSIZE(65536) > > cpuid = 1 > KDB: enter: panic > exclusive lockmgr udf (udf) r = 0 (0xc45556a0) locked @ > /usr/src/sys/kern/vfs_syscalls.c:4083 > exclusive lockmgr udf (udf) r = 0 (0xc45556a0) locked @ > /usr/src/sys/kern/vfs_syscalls.c:4083 > > 0xc4555648: tag udf, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > v_object 0xc479ac98 ref 0 pages 0 > lock type udf: EXCL by thread 0xc43b4d80 (pid 977) More bad news, panic is not introduced with patches it was here from the start: db:0:kdb.enter.panic> show pcpu cpuid = 1 curthread = 0xc4866240: pid 864 "initial thread" curpcb = 0xc3b61d90 fpcurthread = none idlethread = 0xc3d2ad80: pid 10 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db:0:kdb.enter.panic> bt Tracing pid 864 tid 100085 td 0xc4866240 kdb_enter(c069b2ff,c069b2ff,c06a5f73,c3b61968,1,...) at kdb_enter+0x3a panic(c06a5f73,10800,10000,c06869a6,c3b619d0,...) at panic+0x131 getblk(c4f08648,424,0,10800,0,...) at getblk+0x2d breadn(c4f08648,424,0,10800,0,...) at breadn+0x44 bread(c4f08648,424,0,10800,0,...) at bread+0x4c udf_readatoffset(1a18,0,c5183038,c518303c,0,...) at udf_readatoffset+0xbb udf_getfid(c4f02200,c06a034f,527,c06a87d5,c3b61c24,...) at udf_getfid+0x1ca udf_readdir(c3b61c24,0,c4f05a78,0,c3b61c5c,...) at udf_readdir+0xdc VOP_READDIR_APV(c517f280,c3b61c24,c06a87d5,ff3,1a18,...) at VOP_READDIR_APV+0xa0 kern_getdirentries(c4866240,46,2844c000,1000,c3b61c78,...) at kern_getdirentries+0x1bd getdirentries(c4866240,c3b61cf8,10,c06a1dd7,c06cfe00,...) at getdirentries+0x31 syscall(c3b61d38) at syscall+0x261 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (196, FreeBSD ELF32, getdirentries), eip = 0x28251e4b, esp = 0xbfbfdcbc, ebp = 0xbfbfdce8 --- lock order reversal: 1st 0xc4f06488 udf (udf) @ /usr/src/sys/kern/vfs_subr.c:2053 2nd 0xd7d9d490 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc4f057ac udf (udf) @ /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:616 KDB: stack backtrace: db_trace_self_wrapper(c069e457,c3b61824,c04e7a2f,4,c0699b7b,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0699b7b,c3cb7538,c3cb9d08,c3b61880,...) at kdb_backtrace+0x29 _witness_debugger(c06a1124,c4f057ac,c517e9dc,c3cb9d08,c517e956,...) at _witness_debugger+0x1e witness_checkorder(c4f057ac,9,c517e956,268,0,...) at witness_checkorder+0x811 __lockmgr_args(c4f057ac,80000,0,0,0,...) at __lockmgr_args+0x762 udf_vget(c4990280,c1,80000,c3b619bc,0,...) at udf_vget+0x137 udf_lookup(c3b619fc,c4f06430,c3b61bb4,c4f06430,c3b61a1c,...) at udf_lookup+0x26c VOP_CACHEDLOOKUP_APV(c517f280,c3b619fc,c3b61bb4,c3b61ba0,c06fa3e0,...) at VOP_CACHEDLOOKUP_APV+0xa0 vfs_cache_lookup(c3b61a7c,c3b61a7c,0,200000,c4f06430,...) at vfs_cache_lookup+0xc3 VOP_LOOKUP_APV(c517f280,c3b61a7c,c06a6e55,2cc,c3b61ba0,...) at VOP_LOOKUP_APV+0xaa lookup(c3b61b88,0,c06a6e55,ec,c41fe42c,...) at lookup+0x507 namei(c3b61b88,c04e780b,c06b6dc4,c06a0b67,3,...) at namei+0x45b kern_statat(c4866240,0,ffffff9c,28307450,0,...) at kern_statat+0x66 kern_stat(c4866240,28307450,0,c3b61c1c,44f,...) at kern_stat+0x36 stat(c4866240,c3b61cf8,8,c06a259b,c06cfd40,...) at stat+0x2b syscall(c3b61d38) at syscall+0x261 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x2825c34b, esp = 0xbfbfe0bc, ebp = 0xbfbfe158 --- uiomove returned -1 uiomove returned -1 uiomove returned -1 uiomove returned -1 uiomove returned -1 panic: getblk: size(67584) > MAXBSIZE(65536) cpuid = 1 KDB: enter: panic exclusive lockmgr udf (udf) r = 0 (0xc4f05ad0) locked @ /usr/src/sys/kern/vfs_syscalls.c:4083 exclusive sleep mutex Giant (Giant) r = 0 (0xc0710cf0) locked @ /usr/src/sys/kern/vfs_syscalls.c:4068 exclusive lockmgr udf (udf) r = 0 (0xc4f05ad0) locked @ /usr/src/sys/kern/vfs_syscalls.c:4083 exclusive sleep mutex Giant (Giant) r = 0 (0xc0710cf0) locked @ /usr/src/sys/kern/vfs_syscalls.c:4068 0xc4f05a78: tag udf, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () v_object 0xc50b907c ref 0 pages 0 lock type udf: EXCL by thread 0xc4866240 (pid 864) This is recent kernel: Sat Nov 22 15:17:29 CET 2008 (without patches from @current) -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 19:17:50 2008 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 119A61065670 for ; Sat, 22 Nov 2008 19:17:50 +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 D81C88FC18 for ; Sat, 22 Nov 2008 19:17:49 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 1C0C52BC4B for ; Sun, 23 Nov 2008 08:17:49 +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 6Pln8qGTJzJv for ; Sun, 23 Nov 2008 08:17:45 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP for ; Sun, 23 Nov 2008 08:17:45 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 1D87811458; Sun, 23 Nov 2008 08:17:45 +1300 (NZDT) Date: Sat, 22 Nov 2008 11:17:44 -0800 From: Andrew Thompson To: current@freebsd.org Message-ID: <20081122191744.GA62217@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: config(8) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 19:17:50 -0000 Hi, I wanted to use the following in my kernel config file so wrote a patch for it. makeoptions MODULES_OVERRIDE=foo makeoptions MODULES_OVERRIDE+=bar makeoptions MODULES_OVERRIDE+=baz http://people.freebsd.org/~thompsa/config_append.diff I am unsure if the config version needs to be bumped for a minor change like this. Can anyone clarify? Andrew From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 20:09:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80300106564A for ; Sat, 22 Nov 2008 20:09:01 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1038FC13 for ; Sat, 22 Nov 2008 20:09:00 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-037-115.pools.arcor-ip.net [88.66.37.115]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1L3ymp154l-0007j1; Sat, 22 Nov 2008 21:08:59 +0100 Received: (qmail 24588 invoked from network); 22 Nov 2008 20:08:58 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 22 Nov 2008 20:08:58 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sat, 22 Nov 2008 21:08:57 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <20081122191744.GA62217@citylink.fud.org.nz> In-Reply-To: <20081122191744.GA62217@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811222108.58061.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/sOjf984ibaqv/yRJvsjjVvRE98NW+5x31bua 4FLv7Uqem/my70HFrCcdom9mu/2MTUkhZhjZPxg4T/ZvuRe3Fq kgLQWRKUgCmIUKTPyVOCg== Cc: Andrew Thompson Subject: Re: config(8) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 20:09:01 -0000 On Saturday 22 November 2008 20:17:44 Andrew Thompson wrote: > Hi, > > > I wanted to use the following in my kernel config file so wrote a patch > for it. > > makeoptions MODULES_OVERRIDE=3Dfoo > makeoptions MODULES_OVERRIDE+=3Dbar > makeoptions MODULES_OVERRIDE+=3Dbaz > > http://people.freebsd.org/~thompsa/config_append.diff > > I am unsure if the config version needs to be bumped for a minor change > like this. Can anyone clarify? =46rom my reading of the comments in configvers.h you should bump the minor= =20 version. You should, however, *not* bump the %VERSREQ in any Makefiles - t= his=20 would allow people to use an old config as long as they don't use your new= =20 addition. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 20:17:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C99106564A for ; Sat, 22 Nov 2008 20:17:06 +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 7FA558FC12 for ; Sat, 22 Nov 2008 20:17:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id BDA8B2BC4B; Sun, 23 Nov 2008 09:17:05 +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 pENGT5seuxmA; Sun, 23 Nov 2008 09:17:02 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sun, 23 Nov 2008 09:17:02 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id F21FC11458; Sun, 23 Nov 2008 09:17:01 +1300 (NZDT) Date: Sat, 22 Nov 2008 12:17:01 -0800 From: Andrew Thompson To: Max Laier Message-ID: <20081122201701.GA62360@citylink.fud.org.nz> References: <20081122191744.GA62217@citylink.fud.org.nz> <200811222108.58061.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200811222108.58061.max@love2party.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: config(8) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 20:17:06 -0000 On Sat, Nov 22, 2008 at 09:08:57PM +0100, Max Laier wrote: > On Saturday 22 November 2008 20:17:44 Andrew Thompson wrote: > > Hi, > > > > > > I wanted to use the following in my kernel config file so wrote a patch > > for it. > > > > makeoptions MODULES_OVERRIDE=foo > > makeoptions MODULES_OVERRIDE+=bar > > makeoptions MODULES_OVERRIDE+=baz > > > > http://people.freebsd.org/~thompsa/config_append.diff > > > > I am unsure if the config version needs to be bumped for a minor change > > like this. Can anyone clarify? > > From my reading of the comments in configvers.h you should bump the minor > version. You should, however, *not* bump the %VERSREQ in any Makefiles - this > would allow people to use an old config as long as they don't use your new > addition. I think you are right, I have bumped from 600006 to 600007. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 20:42:54 2008 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 50F341065687; Sat, 22 Nov 2008 20:42:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 343118FC16; Sat, 22 Nov 2008 20:42:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMKgpIN091541; Sat, 22 Nov 2008 15:42:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMKgp50035800; Sat, 22 Nov 2008 15:42:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6CB2173039; Sat, 22 Nov 2008 15:42:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122204251.6CB2173039@freebsd-current.sentex.ca> Date: Sat, 22 Nov 2008 15:42:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 20:42:54 -0000 TB --- 2008-11-22 18:51:48 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 18:51:48 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-11-22 18:51:48 - cleaning the object tree TB --- 2008-11-22 18:52:19 - cvsupping the source tree TB --- 2008-11-22 18:52:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-11-22 18:52:28 - building world TB --- 2008-11-22 18:52:28 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 18:52:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 18:52:28 - TARGET=ia64 TB --- 2008-11-22 18:52:28 - TARGET_ARCH=ia64 TB --- 2008-11-22 18:52:28 - TZ=UTC TB --- 2008-11-22 18:52:28 - __MAKE_CONF=/dev/null TB --- 2008-11-22 18:52:28 - cd /src TB --- 2008-11-22 18:52:28 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 18:52:30 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 20:40:30 UTC 2008 TB --- 2008-11-22 20:40:30 - generating LINT kernel config TB --- 2008-11-22 20:40:30 - cd /src/sys/ia64/conf TB --- 2008-11-22 20:40:30 - /usr/bin/make -B LINT TB --- 2008-11-22 20:40:30 - building LINT kernel TB --- 2008-11-22 20:40:30 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 20:40:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 20:40:30 - TARGET=ia64 TB --- 2008-11-22 20:40:30 - TARGET_ARCH=ia64 TB --- 2008-11-22 20:40:30 - TZ=UTC TB --- 2008-11-22 20:40:30 - __MAKE_CONF=/dev/null TB --- 2008-11-22 20:40:30 - cd /src TB --- 2008-11-22 20:40:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 20:40:30 UTC 2008 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -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 /src/sys/dev/cxgb/cxgb_main.c:86:34: error: machine/intr_machdep.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 20:42:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 20:42:51 - ERROR: failed to build lint kernel TB --- 2008-11-22 20:42:51 - 5368.84 user 393.59 system 6662.45 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 21:03:09 2008 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 899831065673 for ; Sat, 22 Nov 2008 21:03:09 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 587AC8FC14 for ; Sat, 22 Nov 2008 21:03:09 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id mAMKTjux053369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Nov 2008 14:29:45 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id mAMKThBH053367; Sat, 22 Nov 2008 14:29:43 -0600 (CST) (envelope-from dan) Date: Sat, 22 Nov 2008 14:29:43 -0600 From: Dan Nelson To: Andrew Thompson Message-ID: <20081122202943.GB97829@dan.emsphone.com> References: <20081122191744.GA62217@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081122191744.GA62217@citylink.fud.org.nz> X-OS: FreeBSD 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: config(8) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 21:03:09 -0000 In the last episode (Nov 22), Andrew Thompson said: > I wanted to use the following in my kernel config file so wrote a > patch for it. > > makeoptions MODULES_OVERRIDE=foo > makeoptions MODULES_OVERRIDE+=bar > makeoptions MODULES_OVERRIDE+=baz > > http://people.freebsd.org/~thompsa/config_append.diff Heh. That's a lot cleaner than my workaround: makeoptions "MODULES_OVERRIDE+"="zfs opensolaris dtrace cyclic" makeoptions "MODULES_OVERRIDE +"="md" #makeoptions "MODULES_OVERRIDE +"="geom/geom_sunlabel geom/geom_uzip" #makeoptions "MODULES_OVERRIDE +"="ntfs ntfs_iconv" makeoptions "MODULES_OVERRIDE +"="geom/geom_gate" #makeoptions "MODULES_OVERRIDE +"="lm" :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 21:52:40 2008 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 CD2CC106564A; Sat, 22 Nov 2008 21:52:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B04398FC17; Sat, 22 Nov 2008 21:52:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMLqb9f059479; Sat, 22 Nov 2008 16:52:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mAMLqbti024549; Sat, 22 Nov 2008 16:52:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E7FDF73039; Sat, 22 Nov 2008 16:52:36 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081122215236.E7FDF73039@freebsd-current.sentex.ca> Date: Sat, 22 Nov 2008 16:52:36 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 21:52:41 -0000 TB --- 2008-11-22 20:22:48 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 20:22:48 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-11-22 20:22:48 - cleaning the object tree TB --- 2008-11-22 20:23:24 - cvsupping the source tree TB --- 2008-11-22 20:23:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-11-22 20:23:33 - building world TB --- 2008-11-22 20:23:33 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 20:23:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 20:23:33 - TARGET=powerpc TB --- 2008-11-22 20:23:33 - TARGET_ARCH=powerpc TB --- 2008-11-22 20:23:33 - TZ=UTC TB --- 2008-11-22 20:23:33 - __MAKE_CONF=/dev/null TB --- 2008-11-22 20:23:33 - cd /src TB --- 2008-11-22 20:23:33 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 20:23:35 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 22 21:47:01 UTC 2008 TB --- 2008-11-22 21:47:01 - generating LINT kernel config TB --- 2008-11-22 21:47:01 - cd /src/sys/powerpc/conf TB --- 2008-11-22 21:47:01 - /usr/bin/make -B LINT TB --- 2008-11-22 21:47:01 - building LINT kernel TB --- 2008-11-22 21:47:01 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 21:47:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 21:47:01 - TARGET=powerpc TB --- 2008-11-22 21:47:01 - TARGET_ARCH=powerpc TB --- 2008-11-22 21:47:01 - TZ=UTC TB --- 2008-11-22 21:47:01 - __MAKE_CONF=/dev/null TB --- 2008-11-22 21:47:01 - cd /src TB --- 2008-11-22 21:47:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 21:47:02 UTC 2008 >>> 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 [...] /src/sys/dev/bce/if_bce.c: In function 'bce_get_hw_rx_cons': /src/sys/dev/bce/if_bce.c:5671: error: '__ATOMIC_BARRIER' undeclared (first use in this function) /src/sys/dev/bce/if_bce.c:5671: error: (Each undeclared identifier is reported only once /src/sys/dev/bce/if_bce.c:5671: error: for each function it appears in.) /src/sys/dev/bce/if_bce.c: In function 'bce_rx_intr': /src/sys/dev/bce/if_bce.c:5732: error: '__ATOMIC_BARRIER' undeclared (first use in this function) /src/sys/dev/bce/if_bce.c: In function 'bce_get_hw_tx_cons': /src/sys/dev/bce/if_bce.c:6014: error: '__ATOMIC_BARRIER' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 21:52:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 21:52:36 - ERROR: failed to build lint kernel TB --- 2008-11-22 21:52:36 - 4231.41 user 393.16 system 5388.17 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 23:06:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B3491065673 for ; Sat, 22 Nov 2008 23:06:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 550F38FC0A for ; Sat, 22 Nov 2008 23:05:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 37EC645685; Sun, 23 Nov 2008 00:05:58 +0100 (CET) Received: from localhost (chello087206045082.chello.pl [87.206.45.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 892A645683; Sun, 23 Nov 2008 00:05:53 +0100 (CET) Date: Sun, 23 Nov 2008 00:05:54 +0100 From: Pawel Jakub Dawidek To: Nikolay Denev Message-ID: <20081122230554.GC2016@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> <8ECD400F-BFE3-4E31-94F0-39AF5F44FDAC@gmail.com> <20081119090307.GA81236@icarus.home.lan> <18E318DD-29FA-4E26-89CF-11B893B42E34@gmail.com> <20081121162518.GC6509@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline In-Reply-To: <20081121162518.GC6509@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 23:06:00 -0000 --+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 21, 2008 at 05:25:18PM +0100, Pawel Jakub Dawidek wrote: > On Wed, Nov 19, 2008 at 01:58:49PM +0200, Nikolay Denev wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > >=20 > > On 19 Nov, 2008, at 11:48 , Nikolay Denev wrote: > > > > > >Well, it looks like that on -current and a 4G amd64 machine probably = =20 > > >there is no need > > >to tune anything. Here are my defaults with everything vm and zfs =20 > > >related in loader.conf commented : > > > > > >vm.kmem_size_max: 4509713203 > > >vfs.zfs.arc_max: 863907840 > > > > >=20 > > I was able to panic it again with "kmem_map too small" with these =20 > > settings (defaults). > >=20 > > This are the bonnie++ arguments that i've used: > > bonnie++ -d /tank -c 4 -r 4096 -x 9999999 -u 0:0 >=20 > I wasn't able to panic my test machine running this command on i386 > machine with this in /boot/loader.conf: >=20 > vm.kmem_size=3D1073741824 > vm.kmem_size_max=3D1073741824 >=20 > (1GB) >=20 > Although I now found that you were trying raidz2 and I had two two-way > mirrors. I'm retrying now. Ok, I tried RAIDZ2 on top of five disks - no panics. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJKJBSForvXbEpPzQRAngqAKCnZqVEn5xA6Qk4/JlGjJu7eEX9TACgrZib 3EOQd2cxx7vmjdwv9StrUqE= =9LuE -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 23:44:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABB62106564A for ; Sat, 22 Nov 2008 23:44:56 +0000 (UTC) (envelope-from comp.john@googlemail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by mx1.freebsd.org (Postfix) with ESMTP id 357D28FC18 for ; Sat, 22 Nov 2008 23:44:55 +0000 (UTC) (envelope-from comp.john@googlemail.com) Received: by mu-out-0910.google.com with SMTP id i2so1580717mue.3 for ; Sat, 22 Nov 2008 15:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=Ar4AxWvEyLgzJvdwNqRSnHth+kHbDs9XeIcKqncuSAA=; b=DgV8/Jt3d2hS97GApmZx3gHIjGeF4sljkiFaO+xp9OerN4v1dOiD2JfYrcsMieE6Lo IIlCicYHntMD+eyBONUb1kpgoKqTiv04jPN7ehA7qPdgVCRcF7lv86AUPOvjC/KYJ/KO NAJBmAxAZHWM/aptCdjCRfjjJz23J9Z7EZCVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=WRbmqUXuAaSTE3nWm7107nMm4hCjmYrQf8EZ+5hjCE73AQMe3aqE++bejXMDxIeSZe Hq2H+odA/VPoqPv/FYMshbZZ1Ol9/tP4EKBudPmbO0fyJONcuN3w29cgaSwVqAFgbo/F iVoECvCcuMtLtAhLuYXhULjOzD29Nn5ckZ5Is= Received: by 10.103.11.7 with SMTP id o7mr595482mui.103.1227396088386; Sat, 22 Nov 2008 15:21:28 -0800 (PST) Received: by 10.103.224.20 with HTTP; Sat, 22 Nov 2008 15:21:28 -0800 (PST) Message-ID: Date: Sat, 22 Nov 2008 23:21:28 +0000 From: "John ." To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: trying to make a Toshiba Satellite Pro A300 work with FreeBSD 8-CURRENT (2008.11) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Nov 2008 23:44:56 -0000 Hi, Toshiba A300 Satellite Pro PSAK13 (AMD Turion 64) It works for the most part, except for wifi or ethernet :( X not tested unfer FreeBSD dmesg at http://www.growveg.org/laptop/freebsd/fbsd8_current_200811_dmesg.txt pciconf at http://www.growveg.org/laptop/freebsd/fbsd8_current_200811_pciconf.txt Can anyone tell me if there is a chance getting the onboard wifi to work? Linux (latest ubuntu 64 bit) doesn't see it either (though it does detect ethernet) thanks -- John