From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 04:04:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FDDA16A419; Sun, 23 Dec 2007 04:04:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDA713C459; Sun, 23 Dec 2007 04:04:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B0C5E1A4D82; Sat, 22 Dec 2007 20:03:08 -0800 (PST) Date: Sat, 22 Dec 2007 20:03:08 -0800 From: Alfred Perlstein To: David G Lawrence Message-ID: <20071223040308.GT16982@elvis.mu.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <20071222002432.GK16982@elvis.mu.org> <20071222073236.GW25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071222073236.GW25053@tnn.dglawrence.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 04:04:42 -0000 * David G Lawrence [071221 23:31] wrote: > > > > Can you use a placeholder vnode as a place to restart the scan? > > > > you might have to mark it special so that other threads/things > > > > (getnewvnode()?) don't molest it, but it can provide for a convenient > > > > restart point. > > > > > > That was one of the solutions that I considered and rejected since it > > > would significantly increase the overhead of the loop. > > > The solution provided by Kostik Belousov that uses uio_yield looks like > > > a find solution. I intend to try it out on some servers RSN. > > > > Out of curiosity's sake, why would it make the loop slower? one > > would only add the placeholder when yielding, not for every iteration. > > Actually, I misread your suggestion and was thinking marker flag, > rather than placeholder vnode. Sorry about that. The current code > actually already uses a marker vnode. It is hidden and obfuscated in > the MNT_VNODE_FOREACH macro, further hidden in the __mnt_vnode_first/next > functions, so it should be safe from vnode reclaimation/free problems. That level of obscuring is a bit worrysome. Yes, I did mean placeholder vnode. Even so, is it of utility or not? Or is it already being used and I'm missing something and should just "utsl" at this point? -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 19:54:38 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C2C16A417 for ; Sun, 23 Dec 2007 19:54:38 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3466C13C43E for ; Sun, 23 Dec 2007 19:54:38 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) by sarah.protected-networks.net (Postfix) with ESMTP id 21D5E6324 for ; Sun, 23 Dec 2007 14:54:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1198439677; bh=YDaUvkga9TXFAH +o6ZtfMQ+C1ijNMWvO17HxLBJ4SDY=; h=DomainKey-Signature:Message-ID: Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version: OpenPGP:Content-Type:Content-Transfer-Encoding; b=FJyiDVY9xyO87xb1 yC+NQQ4p12N7srcHdpEUNGcm6Ky8JBx1ay79OduU7n91AEleFivcumMEal2BrLn/Q3j 3EXe4PZwpUu+GVGqzLubkSXdQl7FccDS4ewt8Itnk/9Bz DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=SF1jOOy3rfzQReRnTLw5BpHmmY4yvzjM2U9pmcOFdqqaAmJNU3xssm9yVCvAn2g4+ baaInCnpFjHcvJK+H3rgOm+7/MPsznbNY/p40PI73SeXQeeMfoACh7H8MKLNfYu Message-ID: <476EBCFB.5080104@protected-networks.net> Date: Sun, 23 Dec 2007 14:54:35 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: freebsd-stable X-Enigmail-Version: 0.95.5 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Nikon Coolpix X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 19:54:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just curious .. is this expected behaviour on -stable? In "normal" USB mode .. Dec 23 14:19:40 toshi kernel: umass0: on uhub1 Dec 23 14:19:40 toshi root: Unknown USB device: vendor 0x04b0 product 0x0304 bus uhub1 Dec 23 14:19:40 toshi kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Dec 23 14:19:40 toshi kernel: da0: Removable Direct Access SCSI-0 device Dec 23 14:19:40 toshi kernel: da0: 1.000MB/s transfers Dec 23 14:19:40 toshi kernel: da0: 982MB (2012160 512 byte sectors: 64H 32S/T 982C) Dec 23 14:19:40 toshi kernel: umass0: Phase Error, residue = 0 Dec 23 14:19:40 toshi kernel: (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 [ .. lots of this .. ] Dec 23 14:19:59 toshi kernel: umass0: Phase Error, residue = 0 Dec 23 14:19:59 toshi kernel: (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 Dec 23 14:19:59 toshi kernel: umass0: at uhub1 port 1 (addr 2) disconnected Dec 23 14:19:59 toshi kernel: (da0:umass-sim0:0:0:0): lost device Dec 23 14:19:59 toshi kernel: (da0:umass-sim0:0:0:0): removing device entry Dec 23 14:19:59 toshi kernel: umass0: detached yet in "PTP" mode .. (whatever that might signify) .. Dec 23 14:20:53 toshi root: Unknown USB device: vendor 0x04b0 product 0x0305 bus uhub1 Dec 23 14:20:53 toshi kernel: ugen0: on uhub1 .. but digikam can't initialise it :-( Should I be able to mount it as a FAT file-system when configured as a "normal" USB device or ..how do I "talk" to it? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHbrz7Qv9rrgRC1JIRAg9vAJ9TEcunlY5+BGMmqU1QFrdf9eio8QCfVR9U xXMAP0Pb1CUBAHSjOcsxmTo= =QkTY -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 23:40:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ABA716A417 for ; Sun, 23 Dec 2007 23:40:40 +0000 (UTC) (envelope-from hexidigital@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id 60BD413C45D for ; Sun, 23 Dec 2007 23:40:40 +0000 (UTC) (envelope-from hexidigital@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so448853wxd.7 for ; Sun, 23 Dec 2007 15:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=Lxxlzi+cNA0nA4mqfM6KsS7XFyyZBZuw+9Va8otWxbA=; b=TU7KJCZOudJPQyqglmKWDp5pChMgJBEY0vjk4z5xb+kw1aesyA+wEnnOPOBTV8GR8T4/8TDeLd6VWDB8RZFh/kczKrIJ71hYV69kD0cCQnNWukDoULUtjX432X4p4am2Jn8u1V2n2e7dp4fnbG1sTT1vUxrly7x3FsdP/5lH5Bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=wsJRHnJp+LxApLQXerC3LG7PxVZJtz7JKKrWGJdlYp7xXpcPR+CiEz4EmqGit3MbJN6n3Ov5pkpzaxVgf+tAlrIY06NfUKD+rKSHn4Dci6Qu81YuXcQKTUIlBCOwjG6LbUcmSmUdSKD69Sek7o0JzeRXAI0zqn1mE4q9pVFa+fo= Received: by 10.70.53.3 with SMTP id b3mr616074wxa.82.1198451774435; Sun, 23 Dec 2007 15:16:14 -0800 (PST) Received: from ?192.168.1.4? ( [24.229.62.9]) by mx.google.com with ESMTPS id h35sm14635066wxd.20.2007.12.23.15.16.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Dec 2007 15:16:13 -0800 (PST) From: Glen Barber To: freebsd-stable@freebsd.org Date: Sun, 23 Dec 2007 18:16:03 -0500 User-Agent: KMail/1.9.7 References: <476EBCFB.5080104@protected-networks.net> In-Reply-To: <476EBCFB.5080104@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712231816.03681.hexidigital@gmail.com> Subject: Re: Nikon Coolpix X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 23:40:40 -0000 On Sunday 23 December 2007 02:54:35 pm Michael Butler wrote: -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 23:48:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D8816A420 for ; Sun, 23 Dec 2007 23:48:47 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5DD13C459 for ; Sun, 23 Dec 2007 23:48:47 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so449332wxd.7 for ; Sun, 23 Dec 2007 15:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=zB/mBfljIFMy91DqbTchoexiykM7Lm2tsC3a/wW+Fmc=; b=aTER1x/lmY7Y+r3wD7HlxJ2g2gGGOUowgerUKCXNnRglYjxAK1ws5Iz5iiPlEgevdlXtTNaPtMY/kSg4WrQxtoLGqrlCivqXmx4KQwKHgd5/wECmxysJA9xHaQwyr9Y7GDotSaboWaWZ+J+zxlT5e5jB02rRAguZQO7WJ1l+v1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=Vh2zesgk941UDHzTjPYREjxo5/ylSbZsKJr8KcpBUMfk5EeYqSe2BQW3o1CcW0AzWl/ib7LVMc8eKjeOqHHmszLjrUy2myKhb0vkxGLdA7WbSZMwyx/JZxTQruySHhvMr2k6JBYhr+23H0VESV62XRNncueE8E9PjjOTVYjtxMM= Received: by 10.70.35.1 with SMTP id i1mr2664966wxi.32.1198452032311; Sun, 23 Dec 2007 15:20:32 -0800 (PST) Received: from ?192.168.1.4? ( [24.229.62.9]) by mx.google.com with ESMTPS id h9sm5912938wxd.35.2007.12.23.15.20.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Dec 2007 15:20:31 -0800 (PST) From: Glen Barber To: freebsd-stable@freebsd.org Date: Sun, 23 Dec 2007 18:20:21 -0500 User-Agent: KMail/1.9.7 References: <476EBCFB.5080104@protected-networks.net> In-Reply-To: <476EBCFB.5080104@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712231820.21864.glen.j.barber@gmail.com> Subject: Re: Nikon Coolpix X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 23:48:47 -0000 My apologies for the blank post. Apparently, I became a bit trigger happy while setting up Kmail for mailing lists. From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 23:49:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 259F816A420 for ; Sun, 23 Dec 2007 23:49:57 +0000 (UTC) (envelope-from chris@shenton.org) Received: from shenton.org (static-71-246-241-106.washdc.fios.verizon.net [71.246.241.106]) by mx1.freebsd.org (Postfix) with SMTP id BB35013C46A for ; Sun, 23 Dec 2007 23:49:56 +0000 (UTC) (envelope-from chris@shenton.org) Received: (qmail 6589 invoked by uid 1001); 23 Dec 2007 23:49:55 -0000 From: Chris Shenton Date: Sun, 23 Dec 2007 17:17:13 -0500 References: <86hciuilpx.fsf@PECTOPAH.shenton.org> <86bq8yjwii.fsf@PECTOPAH.shenton.org> <863atxil7o.fsf@Bacalao.shenton.org> <200712201409.08385.max@love2party.net> Message-ID: <861w9dgee4.fsf@Bacalao.shenton.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: PATCH: FreeBSD-7-BETA4 'bge' ether for Dell T105 server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 23:49:57 -0000 Thanks to Max Laier's help, the ether device is now working with the 'bge' driver. Here is a patch that makes it work. I just recompiled the kernel afterwards and it comes up. PS: the T105 is now $399 but includes 1GB RAM and 2x160GB disk, in addition to the dual-core 1.8GHz Opteron and DVD reader. (Is there a better way to do this? sorry for the CC's, wasn't sure which was appropriate for getting this into the tree.) $ pwd /usr/src/sys/dev/bge $ diff -c if_bge.c* *** if_bge.c Mon Nov 26 12:33:28 2007 --- if_bge.c.NEW Sun Dec 23 15:44:40 2007 *************** *** 169,174 **** --- 169,175 ---- { BCOM_VENDORID, BCOM_DEVICEID_BCM5715S }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, $ diff -c if_bgereg.h* *** if_bgereg.h Tue May 22 15:22:58 2007 --- if_bgereg.h.NEW Sun Dec 23 15:44:53 2007 *************** *** 2011,2016 **** --- 2011,2017 ---- #define BCOM_DEVICEID_BCM5715S 0x1679 #define BCOM_DEVICEID_BCM5720 0x1658 #define BCOM_DEVICEID_BCM5721 0x1659 + #define BCOM_DEVICEID_BCM5722 0x165a #define BCOM_DEVICEID_BCM5750 0x1676 #define BCOM_DEVICEID_BCM5750M 0x167C #define BCOM_DEVICEID_BCM5751 0x1677 From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 00:14:43 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9383716A418; Mon, 24 Dec 2007 00:14:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 67A7913C43E; Mon, 24 Dec 2007 00:14:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id lBO0EfRB014370; Mon, 24 Dec 2007 11:14:41 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200712240014.lBO0EfRB014370@drugs.dv.isc.org> To: Chris Shenton From: Mark Andrews In-reply-to: Your message of "Sun, 23 Dec 2007 17:17:13 CDT." <861w9dgee4.fsf@Bacalao.shenton.org> Date: Mon, 24 Dec 2007 11:14:41 +1100 Sender: marka@isc.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: PATCH: FreeBSD-7-BETA4 'bge' ether for Dell T105 server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 00:14:43 -0000 > Thanks to Max Laier's help, the ether device is now working with the 'bge' > driver. Here is a patch that makes it work. I just recompiled the > kernel afterwards and it comes up. > > PS: the T105 is now $399 but includes 1GB RAM and 2x160GB disk, > in addition to the dual-core 1.8GHz Opteron and DVD reader. > > (Is there a better way to do this? sorry for the CC's, wasn't sure which > was appropriate for getting this into the tree.) "send-pr" is the appropriate command for submitting these sorts of fixes. > $ pwd > /usr/src/sys/dev/bge > $ diff -c if_bge.c* > *** if_bge.c Mon Nov 26 12:33:28 2007 > --- if_bge.c.NEW Sun Dec 23 15:44:40 2007 > *************** > *** 169,174 **** > --- 169,175 ---- > { BCOM_VENDORID, BCOM_DEVICEID_BCM5715S }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, > + { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, > $ diff -c if_bgereg.h* > *** if_bgereg.h Tue May 22 15:22:58 2007 > --- if_bgereg.h.NEW Sun Dec 23 15:44:53 2007 > *************** > *** 2011,2016 **** > --- 2011,2017 ---- > #define BCOM_DEVICEID_BCM5715S 0x1679 > #define BCOM_DEVICEID_BCM5720 0x1658 > #define BCOM_DEVICEID_BCM5721 0x1659 > + #define BCOM_DEVICEID_BCM5722 0x165a > #define BCOM_DEVICEID_BCM5750 0x1676 > #define BCOM_DEVICEID_BCM5750M 0x167C > #define BCOM_DEVICEID_BCM5751 0x1677 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 08:35:43 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF8C316A41A for ; Mon, 24 Dec 2007 08:35:43 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8A4FC13C469 for ; Mon, 24 Dec 2007 08:35:43 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 1461B12374; Mon, 24 Dec 2007 10:35:41 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39291-05; Mon, 24 Dec 2007 10:35:39 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 1900812357; Mon, 24 Dec 2007 10:35:39 +0200 (EET) Message-ID: <476F6F5A.90801@bulinfo.net> Date: Mon, 24 Dec 2007 10:35:38 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Kip Macy References: <476A5EE1.9000003@bulinfo.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: FreeBSD Subject: Re: Performance! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 08:35:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kip Macy wrote: > Are you sure that the settitle call is disabled on FreeBSD? > I don't know anything about this. Could you explain? > > On 12/20/07, Krassimir Slavchev wrote: > Hello, > > I have read all related threads about performance problems with multi > core systems but still have no idea what to do to make thinks better. > Below are results of testing postgresql on HP DL380G5 using sysbench. > The results are comparable to: > http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 > but the same tests running on the same hardware using Linux (kernel > 2.6.18-53.1.4.el5 SMP x86_64) are very different. > PostgreSQL is tuned equal. > > dmesg: > ... > CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > > Features=0xbfebfbff > > Features2=0xce3bd> > AMD Features=0x20000800 > AMD Features2=0x1 > Cores per package: 4 > usable memory = 8575655936 (8178 MB) > avail memory = 8288337920 (7904 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > ... > > test: > sysbench --num-threads=${i} --test=oltp --pgsql-user=bench > --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0 > --oltp-read-only=on run > > tuning: > kern.ipc.shmmax=2147483647 > kern.ipc.shmall=524288 > kern.ipc.semmsl=512 > kern.ipc.semmap=256 > kern.ipc.somaxconn=2048 > kern.maxfiles=65536 > vfs.read_max=32 > > kern.ipc.semmni=256 > kern.ipc.semmns=2048 > > results: > FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE > #threads #transactions/sec user/system > 1 500 7.4%,5.3% > 5 1990 30.9%,23.4% > 10 2510 39.9%,35.0% > 20 2549 44.5%,43.5% > 40 1921 29.8%,59.4% > 60 1580 22.7%,70.6% > 80 1341 18.9%,75.9% > 100 1227 16.5%,79.3% > > Linux > #threads #transactions/sec > 1 693 > 5 3539 > 10 5789 > 20 5791 > 40 5661 > 60 5517 > 80 5401 > 100 5319 > > > What can be done to improve these results? > > Best Regards > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHb29axJBWvpalMpkRAszAAJ9bBbHr5lskjC9fD3zHrZNvoRQL6QCeP0Sh B1YvfmvSuyXkIG15HUZ1Hfw= =ZdzN -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 09:01:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD4816A417 for ; Mon, 24 Dec 2007 09:01:59 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1595913C442 for ; Mon, 24 Dec 2007 09:01:59 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id C32A312423 for ; Mon, 24 Dec 2007 11:01:56 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41445-04 for ; Mon, 24 Dec 2007 11:01:54 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 6F6C512429 for ; Mon, 24 Dec 2007 11:01:54 +0200 (EET) Message-ID: <476F7581.8080100@bulinfo.net> Date: Mon, 24 Dec 2007 11:01:53 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: FreeBSD X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: ifconfig options? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 09:01:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, 'ifconfig -l [address_family]' does not work correct on RELENG_7 FreeBSD 6.3-BETA2: # ifconfig -l em0 em1 plip0 lo0 pflog0 #ifconfig -l ether em0 em1 But: FreeBSD 7.0-BETA4: # ifconfig -l em0 em1 plip0 lo0 pflog0 #ifconfig -l ether em0 em1 plip0 lo0 pflog0 I need this functionality to get all ethernet interfaces. Is there other way to do this? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHb3WBxJBWvpalMpkRAmZSAKCP1zuGQ/jzFDuPJEM/pCNEkP/gIACfeImb VODEPRfu0Pl38yML0WA8Tow= =Rkav -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 09:11:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9503216A417 for ; Mon, 24 Dec 2007 09:11:32 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from mx1.unixguru.nl (mx1.unixguru.nl [77.37.12.119]) by mx1.freebsd.org (Postfix) with ESMTP id 53CD813C457 for ; Mon, 24 Dec 2007 09:11:32 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from localhost (mx1.unixguru.nl [77.37.12.119]) by mx1.unixguru.nl (Postfix) with ESMTP id C67AD1F9A0; Mon, 24 Dec 2007 10:14:10 +0100 (CET) Received: from mx1.unixguru.nl ([77.37.12.119]) by localhost (vs8916.vserver4free.de [77.37.12.119]) (amavisd-new, port 10024) with ESMTP id HiMkCoy3pk3Y; Mon, 24 Dec 2007 10:14:09 +0100 (CET) Received: from mail.unixguru.nl (www.unixguru.nl [217.122.53.58]) by mx1.unixguru.nl (Postfix) with ESMTP id BF3C81F4C1; Mon, 24 Dec 2007 10:14:08 +0100 (CET) Received: from localhost (shell.unixguru.nl [192.168.10.20]) by mail.unixguru.nl (Postfix) with ESMTP id 6BF4111408; Mon, 24 Dec 2007 10:11:28 +0100 (CET) Date: Mon, 24 Dec 2007 10:11:28 +0100 From: Richard Arends To: Krassimir Slavchev Message-ID: <20071224091127.GV36624@shell.unixguru.nl> References: <476F7581.8080100@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476F7581.8080100@bulinfo.net> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Subject: Re: ifconfig options? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 09:11:32 -0000 On Mon, Dec 24, 2007 at 11:01:53AM +0200, Krassimir Slavchev wrote: > I need this functionality to get all ethernet interfaces. Is there other > way to do this? netstat -i -f link Maybe? -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 09:24:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8CA616A420 for ; Mon, 24 Dec 2007 09:24:44 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9083513C4D1 for ; Mon, 24 Dec 2007 09:24:44 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 239E3124A5; Mon, 24 Dec 2007 11:24:42 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43380-03; Mon, 24 Dec 2007 11:24:39 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id BF85D1249F; Mon, 24 Dec 2007 11:24:39 +0200 (EET) Message-ID: <476F7AD6.40802@bulinfo.net> Date: Mon, 24 Dec 2007 11:24:38 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Richard Arends References: <476F7581.8080100@bulinfo.net> <20071224091127.GV36624@shell.unixguru.nl> In-Reply-To: <20071224091127.GV36624@shell.unixguru.nl> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: FreeBSD Subject: Re: ifconfig options? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 09:24:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Arends wrote: > On Mon, Dec 24, 2007 at 11:01:53AM +0200, Krassimir Slavchev wrote: > >> I need this functionality to get all ethernet interfaces. Is there other >> way to do this? > > netstat -i -f link > > Maybe? > No, this lists all interfaces: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 00:90:27:7c:b8:68 8088136 0 6987967 0 0 plip0 1500 0 0 0 0 0 lo0 16384 138029 0 138029 0 0 pfsyn 2020 0 0 0 0 0 pflog 33208 0 0 0 0 0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHb3rWxJBWvpalMpkRAtlNAJ4yXhYcLlF7MyHg0XzKTtjWSqpBcgCfRMUp fOwhWgxe+Uv+y25Rfb1DWD0= =zopa -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 09:30:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66BB916A419 for ; Mon, 24 Dec 2007 09:30:57 +0000 (UTC) (envelope-from dindin@yandex-team.ru) Received: from cavolo.yandex.ru (cavolo.yandex.ru [87.250.244.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1162B13C442 for ; Mon, 24 Dec 2007 09:30:55 +0000 (UTC) (envelope-from dindin@yandex-team.ru) Received: from sepulcator.yandex.ru (dhcp250-185.yandex.ru [87.250.250.185]) by cavolo.yandex.ru (8.14.1/8.14.1) with ESMTP id lBO9FnpC096940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Dec 2007 12:15:50 +0300 (MSK) (envelope-from dindin@yandex-team.ru) Received: from sepulcator.yandex.ru (localhost [127.0.0.1]) by sepulcator.yandex.ru (8.14.1/8.13.8) with ESMTP id lBO9FnAq002398; Mon, 24 Dec 2007 12:15:49 +0300 (MSK) (envelope-from dindin@yandex-team.ru) Received: (from dindin@localhost) by sepulcator.yandex.ru (8.14.1/8.13.8/Submit) id lBO9Fmfo002397; Mon, 24 Dec 2007 12:15:48 +0300 (MSK) (envelope-from dindin@yandex-team.ru) X-Authentication-Warning: sepulcator.yandex.ru: dindin set sender to dindin@yandex-team.ru using -f Date: Mon, 24 Dec 2007 12:15:48 +0300 From: Denis Barov To: Michael Bushkov , freebsd-stable@freebsd.org Message-ID: <20071224091548.GA1216@sepulcator.yandex.ru> Mail-Followup-To: Denis Barov , Michael Bushkov , freebsd-stable@freebsd.org References: <20071219130028.GA12882@sepulcator.yandex.ru> <1A7EEFCD-EDA9-423A-809E-7DA2D7B1A433@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: <1A7EEFCD-EDA9-423A-809E-7DA2D7B1A433@freebsd.org> X-Operating-System: FreeBSD sepulcator.yandex.ru 7.0-BETA4 FreeBSD 7.0-BETA4 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Antivirus: Dr.Web (R) for Mail Servers on cavolo.yandex.ru host X-Antivirus-Code: 100000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: is there any hope for MFC nscd? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 09:30:57 -0000 --qcHopEYAB45HaUaB Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Michael! In attachment patch for backporing nscd from RELENG_7 to RELENG_6. Tested on FreeBSD sepulca.yandex.ru 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Dec 23 22:06:36 MSK 2007 root@sepulca.yandex.ru:/usr/obj/usr/RELENG_6_ncsd/src/sys/GENERIC amd64 and works fine. Must I prepare pr? P.S. Don't forget to mkdir -p src/usr.sbin/nscd/agents before patching ;) Sun, Dec 23, 2007 at 19:34 +0300 Michael Bushkov: > Hi Denis, > It's actually possible - at first glance it's just the matter of copying = a number of quite self-contained chunks=20 > of 7th version libc code to the RELENG_6_2 libc + copying the nscd itself= =2E I'll contact some other committers to=20 > make sure that there are no other reasons that can prevent such MFC. If e= verything is ok with it - I can do it. > The best way you can help with it is to prepare a patch that I can review= and commit :) Is it possible? >=20 > With best regards, > Michael Bushkov >=20 > On Dec 19, 2007, at 4:00 PM, Denis Barov wrote: >=20 > >Hi, Michael! > > > >Is there any hope for MFC nscd into 6.2? > >Can I help you in this task? > > > > > >Cheers > >-- > >Denis Barov > >Yandex http://www.yandex.ru > >WEB-Search Administration Team > >phone: : +7 (495) 739-70-00 add. 7154 > >e-mail: dindin@yandex-team.ru >=20 Cheers --=20 Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: dindin@yandex-team.ru --VbJkn9YxBvnuCH5J-- --qcHopEYAB45HaUaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iQCVAwUBR294w7QNqrxww2yeAQI7EQQAytQrRqiCi/l4Nb7iYwzkkvrz3F1ziLX3 AUrYs0Q7xAAWd+Q/xgTfSNqObwodrQk3Dz2nTVQXU5NoL7RCUyywvK9FP6I7LUSw 91szJfEkiD2g1xEC8v3YPil0ZDBLtzFeRGNu5eAC5FPx3O6AMbIpLUG1t6HQjr8Y qg6o7KMG1E8= =5tT8 -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 09:59:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F419816A41A for ; Mon, 24 Dec 2007 09:59:16 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7092A13C4D5 for ; Mon, 24 Dec 2007 09:59:16 +0000 (UTC) (envelope-from ruben@verweg.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verweg.com; s=verweg; t=1198489604; bh=+Bo71hkkA7S9cJQ2PwCXB0ndPH4+vXIlxjsgqQkJlEE=; h=Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=ZjNVzUa+O7SIRZT74bFZnUIPkYJn+6QASUKbS 5pynel+1Now3OJeHJ4YYV8ct2sRR7Ff40I/6xncB3FtQXg+1JvI+7RrDGt6SEwSF1E0 CKKPl3YYpQPL1+YSozKysMRAIR3HucZKozu7BUPqgoBZF+8Yla3uoV104z0/0bo7jt4 = Received: from guest-wv-58.ripe.net (chimp.ripe.net [193.0.1.199]) (authenticated bits=0) by erg.verweg.com (8.14.2/8.14.2) with ESMTP id lBO9kcsp029670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Dec 2007 09:46:44 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host chimp.ripe.net [193.0.1.199] claimed to be guest-wv-58.ripe.net Message-ID: <476F7FF9.4090406@verweg.com> Date: Mon, 24 Dec 2007 10:46:33 +0100 From: Ruben van Staveren Organization: Verweg Dot Com User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Krassimir Slavchev References: <476F7581.8080100@bulinfo.net> In-Reply-To: <476F7581.8080100@bulinfo.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5233/Mon Dec 24 09:19:48 2007 on erg.verweg.com X-Virus-Status: Clean X-Spam-Status: No, score=4.9 required=5.0 tests=DATE_IN_FUTURE_96_XX, DKIM_SIGNED,DKIM_VERIFIED,SPF_FAIL autolearn=no version=3.2.3 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on erg.verweg.com X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (erg.verweg.com [217.77.141.129]); Mon, 24 Dec 2007 09:46:50 +0000 (UTC) Cc: FreeBSD Subject: Re: ifconfig options? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 09:59:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Krassimir, Krassimir Slavchev wrote: > Hi, > > 'ifconfig -l [address_family]' does not work correct on RELENG_7 If you suspect a regression in functionality, and you can reproduce it the best thing one can do is submit a problem report with send-pr http://www.freebsd.org/send-pr.html Having them reported on the list may seem nice but stands less chance the item is picked up. Regards, Ruben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHb3/5Z88+mcQxRw0RCNdPAJ4rqsiLuVwr9QP2PAS3ALdqjNGy1QCfRu9q 65+69EzO6S2j4qyjApq7TBI= =ygDu -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 10:22:02 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F120E16A420 for ; Mon, 24 Dec 2007 10:22:02 +0000 (UTC) (envelope-from dindin@yandex-team.ru) Received: from cavolo.yandex.ru (cavolo.yandex.ru [87.250.244.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4AAD213C4E1 for ; Mon, 24 Dec 2007 10:22:02 +0000 (UTC) (envelope-from dindin@yandex-team.ru) Received: from sepulcator.yandex.ru (dhcp250-185.yandex.ru [87.250.250.185]) by cavolo.yandex.ru (8.14.1/8.14.1) with ESMTP id lBOAM0XW011293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Dec 2007 13:22:00 +0300 (MSK) (envelope-from dindin@yandex-team.ru) Received: from sepulcator.yandex.ru (localhost [127.0.0.1]) by sepulcator.yandex.ru (8.14.1/8.13.8) with ESMTP id lBOALxD0003257 for ; Mon, 24 Dec 2007 13:21:59 +0300 (MSK) (envelope-from dindin@yandex-team.ru) Received: (from dindin@localhost) by sepulcator.yandex.ru (8.14.1/8.13.8/Submit) id lBOALx49003256 for freebsd-stable@freebsd.org; Mon, 24 Dec 2007 13:21:59 +0300 (MSK) (envelope-from dindin@yandex-team.ru) X-Authentication-Warning: sepulcator.yandex.ru: dindin set sender to dindin@yandex-team.ru using -f Date: Mon, 24 Dec 2007 13:21:59 +0300 From: Denis Barov To: freebsd-stable@freebsd.org Message-ID: <20071224102159.GB1216@sepulcator.yandex.ru> Mail-Followup-To: Denis Barov , freebsd-stable@freebsd.org References: <20071219130028.GA12882@sepulcator.yandex.ru> <1A7EEFCD-EDA9-423A-809E-7DA2D7B1A433@freebsd.org> <20071224091548.GA1216@sepulcator.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20071224091548.GA1216@sepulcator.yandex.ru> X-Operating-System: FreeBSD sepulcator.yandex.ru 7.0-BETA4 FreeBSD 7.0-BETA4 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Antivirus: Dr.Web (R) for Mail Servers on cavolo.yandex.ru host X-Antivirus-Code: 100000 Subject: Re: is there any hope for MFC nscd? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 10:22:03 -0000 I'm sorry, seems attachment was stripped by mailserver or somewhat else. Gzipped patch avialable at http://www.dindin.ru/wiki/FreeBSD?action=AttachFile&do=get&target=nscd_backport.gz (78Kb) Mon, Dec 24, 2007 at 12:15 +0300 Denis Barov: > Hi, Michael! > In attachment patch for backporing nscd from RELENG_7 to RELENG_6. Tested on > > FreeBSD sepulca.yandex.ru 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Dec > 23 22:06:36 MSK 2007 > root@sepulca.yandex.ru:/usr/obj/usr/RELENG_6_ncsd/src/sys/GENERIC amd64 > > and works fine. > > Must I prepare pr? > > P.S. Don't forget to mkdir -p src/usr.sbin/nscd/agents before patching ;) > > > Sun, Dec 23, 2007 at 19:34 +0300 Michael Bushkov: > > Hi Denis, > > It's actually possible - at first glance it's just the matter of copying a number of quite self-contained chunks > > of 7th version libc code to the RELENG_6_2 libc + copying the nscd itself. I'll contact some other committers to > > make sure that there are no other reasons that can prevent such MFC. If everything is ok with it - I can do it. > > The best way you can help with it is to prepare a patch that I can review and commit :) Is it possible? > > > > With best regards, > > Michael Bushkov > > > > On Dec 19, 2007, at 4:00 PM, Denis Barov wrote: > > > > >Hi, Michael! > > > > > >Is there any hope for MFC nscd into 6.2? > > >Can I help you in this task? > > > > > > > > >Cheers > > >-- > > >Denis Barov > > >Yandex http://www.yandex.ru > > >WEB-Search Administration Team > > >phone: : +7 (495) 739-70-00 add. 7154 > > >e-mail: dindin@yandex-team.ru > > > > Cheers > -- > Denis Barov > Yandex http://www.yandex.ru > WEB-Search Administration Team > phone: : +7 (495) 739-70-00 add. 7154 > e-mail: dindin@yandex-team.ru Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: dindin@yandex-team.ru From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 13:19:22 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87B0616A419; Mon, 24 Dec 2007 13:19:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 073D013C458; Mon, 24 Dec 2007 13:19:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J6nD9-000K30-En; Mon, 24 Dec 2007 15:19:20 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBODJ71x098885; Mon, 24 Dec 2007 15:19:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBODJ68N098878; Mon, 24 Dec 2007 15:19:06 +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: Mon, 24 Dec 2007 15:19:06 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20071224131906.GB57756@deviant.kiev.zoral.com.ua> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <20071222201613.GX57756@deviant.kiev.zoral.com.ua> <20071223095314.G1323@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nuX4E7Vid9I2gnPU" Content-Disposition: inline In-Reply-To: <20071223095314.G1323@delplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 33ca3efb02d57e4381ef3dfbedf9ea6a X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1955 [Dec 24 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Mark Fullmer , freebsd-stable@freebsd.org, "Freebsd-Net@Freebsd. Org" Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 13:19:22 -0000 --nuX4E7Vid9I2gnPU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 23, 2007 at 10:20:31AM +1100, Bruce Evans wrote: > On Sat, 22 Dec 2007, Kostik Belousov wrote: > >Ok, since you talked about this first :). I already made the following > >patch, but did not published it since I still did not inspected all > >callers of MNT_VNODE_FOREACH() for safety of dropping mount interlock. > >It shall be safe, but better to check. Also, I postponed the check > >until it was reported that yielding does solve the original problem. >=20 > Good. I'd still like to unobfuscate the function call. What do you mean there ?=20 > Putting the count in the union seems fragile at best. Even if nothing > can access the marker vnode, you need to context-switch its old contents > while using it for the count, in case its old contents is used. Vnode- > printing routines might still be confused. Could you, please, describe what you mean by "contex-switch" for the VMARKER ? Mark, could you, please, retest the patch below in your setup ? I want to put a change or some edition of it into the 7.0 release, and we need to move fast to do this. diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c index 14acc5b..046af82 100644 --- a/sys/kern/vfs_mount.c +++ b/sys/kern/vfs_mount.c @@ -1994,6 +1994,12 @@ __mnt_vnode_next(struct vnode **mvp, struct mount *m= p) mtx_assert(MNT_MTX(mp), MA_OWNED); =20 KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); + if ((*mvp)->v_yield++ =3D=3D 500) { + MNT_IUNLOCK(mp); + (*mvp)->v_yield =3D 0; + uio_yield(); + MNT_ILOCK(mp); + } vp =3D TAILQ_NEXT(*mvp, v_nmntvnodes); while (vp !=3D NULL && vp->v_type =3D=3D VMARKER) vp =3D TAILQ_NEXT(vp, v_nmntvnodes); diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index dc70417..6e3119b 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -131,6 +131,7 @@ struct vnode { struct socket *vu_socket; /* v unix domain net (VSOCK) */ struct cdev *vu_cdev; /* v device (VCHR, VBLK) */ struct fifoinfo *vu_fifoinfo; /* v fifo (VFIFO) */ + int vu_yield; /* yield count (VMARKER) */ } v_un; =20 /* @@ -185,6 +186,7 @@ struct vnode { #define v_socket v_un.vu_socket #define v_rdev v_un.vu_cdev #define v_fifoinfo v_un.vu_fifoinfo +#define v_yield v_un.vu_yield =20 /* XXX: These are temporary to avoid a source sweep at this time */ #define v_object v_bufobj.bo_object --nuX4E7Vid9I2gnPU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHb7HJC3+MBN1Mb4gRAjM7AJ9DxpeIkxYG5g3BxgVpfoRsYGgVYgCgwfu+ pWV14zgIp7rRQRHlldbdOw4= =Ej13 -----END PGP SIGNATURE----- --nuX4E7Vid9I2gnPU-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 14:49:09 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5AB916A41B for ; Mon, 24 Dec 2007 14:49:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDC713C474 for ; Mon, 24 Dec 2007 14:49:08 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (c-69-244-251-12.hsd1.fl.comcast.net [69.244.251.12]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBOEEjf2037764; Mon, 24 Dec 2007 07:14:51 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <476FBED0.2080400@samsco.org> Date: Mon, 24 Dec 2007 09:14:40 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Brett Glass References: <200712220531.WAA09277@lariat.net> In-Reply-To: <200712220531.WAA09277@lariat.net> 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 (pooker.samsco.org [168.103.85.57]); Mon, 24 Dec 2007 07:14:52 -0700 (MST) X-Spam-Status: No, score=2.0 required=5.4 tests=RCVD_IN_PBL, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 14:49:09 -0000 Brett Glass wrote: > I will need to build several Web caches over the next few months, and > just took advantage of the Christmas lull (and a snowy day, when I > couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how it will > perform at this task. I built up a 4 core FreeBSD box, and asked a > friend who's a Linux fanatic to do the same with Linux on identical > hardware. I didn't watch closely how he installed everything, but asked > him not to tune it beyond setting it up properly for SMP. > > We then ran a test suite in which a client starts several processes. > Each uses wget to fetch a series of objects in rapid succession via the > cache. The fetches done by each process are the same batch of URLS, but > shuffled differently, so each URL will get a miss the first time and > then hits each time it comes up thereafter unless the cache overflows. > We're doing all GETs, with no tricky stuff like subranges. > > As has been reported in some other messages on this list, Linux is > currently blowing FreeBSD away. It's taking as much as 20% less time to > get through the benchmark, depending on exactly how the random shuffle > came out. This is with 4 GB RAM, the GENERIC FreeBSD SMP kernel (using > SCHED_ULE), and aufs as the storage schema for Squid. > > It appears, though I'd need to instrument the code more to be sure, that > the slowdown is coming from file I/O. Could it be that there less > concurrency or more overhead in FreeBSD file operations than there is in > Linux? Even with SoftUpdates turned on, the cache volume mounted with > -noatime, and aufs (which uses kqueues -- a FreeBSD invention -- to > optimize multithreaded disk access), the benchmark shows FreeBSD losing > out. Why? > Brett, There could be several problems here: 1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? I don't recall if malloc debugging got turned off yet for the 7.0 snapshots. 2. Disk subsystem. What kind of disk controller are you using? Not all drivers work well in FreeBSD. Are linux and freebsd using identical hardware? 3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? Would you mind if I logged into your test system and looked around to help diagnose the problem? Scott From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 15:49:51 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A9D316A418 for ; Mon, 24 Dec 2007 15:49:51 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id AC06F13C4CE for ; Mon, 24 Dec 2007 15:49:50 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id IAA19650; Mon, 24 Dec 2007 08:49:41 -0700 (MST) Message-Id: <200712241549.IAA19650@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Dec 2007 08:49:36 -0700 To: Scott Long From: Brett Glass In-Reply-To: <476FBED0.2080400@samsco.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 15:49:51 -0000 At 07:14 AM 12/24/2007, Scott Long wrote: >Brett, > >There could be several problems here: > >1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? I don't recall if malloc debugging got turned off yet for the >7.0 snapshots. I nuked debugging when I recompiled the kernel with SCHED_ULE. >2. Disk subsystem. What kind of disk controller are you using? Not all >drivers work well in FreeBSD. Are linux and freebsd using identical >hardware? They were. The drives are SATA. >3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? Whatever comes standard with Ubuntu. As for directory hashing: Squid doesn't use more than 256 entries in each one, so that's what I normally set. I also normally do a newfs with parameters that favor the distribution of object sizes found in Web caches. (We did this on both Linux and FreeBSD.) >Would you mind if I logged into your test system and looked around to >help diagnose the problem? The system isn't online now, because it's been a week since the tests and I also wanted to try the 6.3 beta and a few hardware changes. My guess, based on what I saw, is that UFS2 doesn't take as much advantage of SMP as Linux's file system does and threads are blocking on file I/O. (Networking does not seem to be the botteneck, though I have heard that the IP stack in 7-CURRENT needs optimization and that this had been proposed as a sponsored project.) --Brett P.S. -- If the chip manufacturers were not making it so that one needs to go to SMP to get more processing power, I wouldn't be doing SMP. I'd rather use FreeBSD 4.11 on a single core "gaming" CPU, as I did a few years ago when I needed a very fast server. But this isn't a viable option nowadays.... From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 16:11:15 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5291216A468 for ; Mon, 24 Dec 2007 16:11:15 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D006E13C458 for ; Mon, 24 Dec 2007 16:11:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (c-69-244-251-12.hsd1.fl.comcast.net [69.244.251.12]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBOGB2Hk038170; Mon, 24 Dec 2007 09:11:08 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <476FDA10.4060107@samsco.org> Date: Mon, 24 Dec 2007 11:10:56 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Brett Glass References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> In-Reply-To: <200712241549.IAA19650@lariat.net> 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 (pooker.samsco.org [168.103.85.57]); Mon, 24 Dec 2007 09:11:08 -0700 (MST) X-Spam-Status: No, score=2.0 required=5.4 tests=RCVD_IN_PBL, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 16:11:15 -0000 Brett Glass wrote: > At 07:14 AM 12/24/2007, Scott Long wrote: > >> Brett, >> >> There could be several problems here: >> >> 1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? I don't recall if malloc debugging got turned off yet for the >> 7.0 snapshots. > > I nuked debugging when I recompiled the kernel with SCHED_ULE. Did you also nuke malloc debugging? > >> 2. Disk subsystem. What kind of disk controller are you using? Not all >> drivers work well in FreeBSD. Are linux and freebsd using identical >> hardware? > > They were. The drives are SATA. Connected to what controller? > >> 3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? > > Whatever comes standard with Ubuntu. Which is??? > As for directory hashing: Squid doesn't > use more than 256 entries in each one, so that's what I normally set. I > also normally do a newfs with parameters that favor the distribution of > object sizes found in Web caches. (We did this on both Linux and FreeBSD.) newfs tuning has little to do with this. > >> Would you mind if I logged into your test system and looked around to >> help diagnose the problem? > > The system isn't online now, because it's been a week since the tests and > I also wanted to try the 6.3 beta and a few hardware changes. > > My guess, based on what I saw, is that UFS2 doesn't take as much advantage of > SMP as Linux's file system does and threads are blocking on file I/O. That's really just speculation on your part, though. UFS is SMP capable, but there really are a whole lot of factors that some into play here so it's really hard to speculate with any chance of success. I can tell you from my experience that a thrashed namei cache looks a lot like slow disk I/O to the casual observer, and that tuning the dirhash is highly important. Thus why I'd like to help out here and see for myself what is going on. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 16:53:26 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D685616A418 for ; Mon, 24 Dec 2007 16:53:26 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6202513C43E for ; Mon, 24 Dec 2007 16:53:26 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id JAA20845; Mon, 24 Dec 2007 09:53:11 -0700 (MST) Message-Id: <200712241653.JAA20845@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Dec 2007 09:53:07 -0700 To: Scott Long From: Brett Glass In-Reply-To: <476FDA10.4060107@samsco.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 16:53:26 -0000 At 09:10 AM 12/24/2007, Scott Long wrote: >Did you also nuke malloc debugging? I believe I did. I tried to take out all debugging to make it a fair test. >>They were. The drives are SATA. > >Connected to what controller? Whatever comes standard on the Intel S5000 motherboards. I believe that it is Intel's own embedded SATA controller, which according to the spec sheet is called their "ESB2-E" embedded SATA RAID controller. We are not using the RAID capability. >>>3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? >>Whatever comes standard with Ubuntu. > >Which is??? EXT3. >>My guess, based on what I saw, is that UFS2 doesn't take as much advantage of >>SMP as Linux's file system does and threads are blocking on file I/O. > >That's really just speculation on your part, though. Yes, it is -- though I'd like to think it is an educated guess. ;-) I'd need to instrument either the benchmark code or the kernel to tell for sure. But the test is, by its nature, bound by file I/O. >I can tell you from my experience that a thrashed namei cache looks a >lot like slow disk I/O to the casual observer, and that tuning the dirhash is highly important. That's always been true. However, Squid's file layout tends to be gentle on the file system. It lays out directories with no more than 256 items in each, and the names of the files are just sequential hexadecimal numbers -- which I'd expect ought to bring about near-perfect if not perfect hashing. If you set the kernel to expect 256 or more entries per directory (I know that Adrian Chadd is on this list; do you recommend 256 or 512?), you seem to get the best performance you are going to get. We have thought about using COSS for small Web objects, but are not sure how it would interact with AUFS or how much it would impact stability by decreasing the size of Squid's "CACHE_MEM" memory pool (which is used for "hot" objects and objects in transit). Squid tends to crash horribly if this pool isn't kept quite big. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 16:57:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E345B16A419; Mon, 24 Dec 2007 16:57:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 530F513C44B; Mon, 24 Dec 2007 16:57:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id ABC5F74400C; Mon, 24 Dec 2007 18:57:37 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN-O4fNbPVcU; Mon, 24 Dec 2007 18:57:37 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2B6F6744007; Mon, 24 Dec 2007 18:57:37 +0200 (EET) Message-ID: <476FE4F9.80309@icyb.net.ua> Date: Mon, 24 Dec 2007 18:57:29 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: g_io_request: usb related crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 16:57:40 -0000 FreeBSD 6.2-RELEASE-p6 amd64 The following happened: 1. I inserted into a USB card-reader a write-protected miniSD card. 2. Tried to mount it (read-write) and that failed, the following messages appeared in the system log: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 1 19 0 0 8 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): DATA PROTECT csi:0,aa,55,61 asc:27,0 (da0:umass-sim0:0:0:0): Write protected field replaceable unit: 1 (da0:umass-sim0:0:0:0): Unretryable error g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 13 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 1 19 0 0 8 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): DATA PROTECT csi:0,aa,55,61 asc:27,0 (da0:umass-sim0:0:0:0): Write protected field replaceable unit: 1 (da0:umass-sim0:0:0:0): Unretryable error g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 13 fsync: giving up on dirty 0xffffff0020f7f7c0: tag devfs, type VCHR usecount 1, writecount 0, refcount 487 mountedhere 0xffffff00265a5400 flags () v_object 0xffffff00254ef0e0 ref 0 pages 485 dev da0s1 3. Removed the card from the reader and got instant crash. Crash info: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff801e554c stack pointer = 0x10:0xffffffffb17c3a30 frame pointer = 0x10:0xffffffffb17c3a70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 41 (syncer) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: kdb_backtrace() at 0xffffffff8024f9e7 = kdb_backtrace+0x37 panic() at 0xffffffff80230861 = panic+0x1d1 trap_fatal() at 0xffffffff803b7588 = trap_fatal+0x3a8 trap_pfault() at 0xffffffff803b71ac = trap_pfault+0x24c trap() at 0xffffffff803b6dd3 = trap+0x2f3 calltrap() at 0xffffffff803a158b = calltrap+0x5 --- trap 0xc, rip = 0xffffffff801e554c, rsp = 0xffffffffb17c3a30, rbp = 0xffffffffb17c3a70 --- g_io_request() at 0xffffffff801e554c = g_io_request+0x2c g_vfs_strategy() at 0xffffffff801e8628 = g_vfs_strategy+0x58 bufwrite() at 0xffffffff8028a68c = bufwrite+0x12c bawrite() at 0xffffffff8028adb5 = bawrite+0x15 vop_stdfsync() at 0xffffffff802948e0 = vop_stdfsync+0x1d0 devfs_fsync() at 0xffffffff801ce25b = devfs_fsync+0x2b VOP_FSYNC_APV() at 0xffffffff803f7a7c = VOP_FSYNC_APV+0x4c sync_vnode() at 0xffffffff8029fb02 = sync_vnode+0x192 sched_sync() at 0xffffffff8029fe9c = sched_sync+0x2bc fork_exit() at 0xffffffff80211b0a = fork_exit+0xaa fork_trampoline() at 0xffffffff803a18ee = fork_trampoline+0xe (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xffffffff80230459 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff80230924 in panic (fmt=0xffffff00799d3720 "\b\032\ry") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xffffffff803b7588 in trap_fatal (frame=0xffffffffb17c3980, eva=0) at /usr/src/sys/amd64/amd64/trap.c:660 #4 0xffffffff803b71ac in trap_pfault (frame=0xffffffffb17c3980, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:573 #5 0xffffffff803b6dd3 in trap (frame= {tf_rdi = -1097678795608, tf_rsi = -1098524564864, tf_rdx = -1098524564816, tf_rcx = 0, tf_r8 = -1317259312, tf_r9 = -1613966144, tf_rax = 2, tf_rbx = -1097678795608, tf_rbp = -1317258640, tf_r10 = 0, tf_r11 = 140737488348584, tf_r12 = -1098524564864, tf_r13 = 0, tf_r14 = -1098958506048, tf_r15 = 2097170, tf_trapno = 12, tf_addr = 0, tf_flags = -1098885697312, tf_err = 0, tf_rip = -2145495732, tf_cs = 8, tf_rflags = 66178, tf_rsp = -1317258688, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:352 #6 0xffffffff803a158b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #7 0xffffffff801e554c in g_io_request (bp=0xffffff006d3ecca8, cp=0xffffff003ad56280) at /usr/src/sys/geom/geom_io.c:299 #8 0xffffffff801e8628 in g_vfs_strategy (bo=0xffffff006d3ecca8, bp=0xffffffff9fcd9d80) at /usr/src/sys/geom/geom_vfs.c:106 #9 0xffffffff8028a68c in bufwrite (bp=0xffffffff9fcd9d80) at buf.h:426 #10 0xffffffff8028adb5 in bawrite (bp=0xffffff006d3ecca8) at buf.h:410 #11 0xffffffff802948e0 in vop_stdfsync (ap=0xffffffffb17c3b80) at /usr/src/sys/kern/vfs_default.c:431 #12 0xffffffff801ce25b in devfs_fsync (ap=0xffffffffb17c3b80) at /usr/src/sys/fs/devfs/devfs_vnops.c:379 #13 0xffffffff803f7a7c in VOP_FSYNC_APV (vop=0x2, a=0xffffff003ad56280) at vnode_if.c:1020 #14 0xffffffff8029fb02 in sync_vnode (bo=0xffffff0020f7f910, td=0xffffff00799d3720) at vnode_if.h:537 #15 0xffffffff8029fe9c in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1698 #16 0xffffffff80211b0a in fork_exit (callout=0xffffffff8029fbe0 , arg=0x0, frame=0xffffffffb17c3c50) at /usr/src/sys/kern/kern_fork.c:821 #17 0xffffffff803a18ee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 (kgdb) fr 7 #7 0xffffffff801e554c in g_io_request (bp=0xffffff006d3ecca8, cp=0xffffff003ad56280) at /usr/src/sys/geom/geom_io.c:299 299 g_trace(G_T_BIO, "bio_request(%p) from %p(%s) to %p(%s) cmd %d", (kgdb) p pp $5 = (struct g_provider *) 0x0 I think this is a crash that could have been avoided, because it seems that there are no data corruption, only an unchecked situation. I see that there is a KASSERT in the code, but I am not sure if this is a situation that can not be expected to happen and to be handled. I'll keep the core file around in case somebody has any interest in this. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 17:04:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E8B16A41A; Mon, 24 Dec 2007 17:04:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id C3BB213C468; Mon, 24 Dec 2007 17:04:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 08D5074400C; Mon, 24 Dec 2007 19:04:31 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGVUQA0tXted; Mon, 24 Dec 2007 19:04:30 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7E27B744007; Mon, 24 Dec 2007 19:04:30 +0200 (EET) Message-ID: <476FE69D.3040709@icyb.net.ua> Date: Mon, 24 Dec 2007 19:04:29 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org References: <476BBCD6.2070804@icyb.net.ua> In-Reply-To: <476BBCD6.2070804@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------060205080807050008050802" Cc: Jeremy Messenger Subject: Re: reduce verboseness for certain scsi error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 17:04:33 -0000 This is a multi-part message in MIME format. --------------060205080807050008050802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Attached is a proposed patch. I am not particularly fond of the names. I am also not sure if the same effect could be achieved by some better means. The patch works for me and greatly reduces messages pollution when using a multi-slot card-reader and hald. P.S. the patch is against sources of 6.2 release. -- Andriy Gapon --------------060205080807050008050802 Content-Type: text/x-patch; name="verboseness.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="verboseness.diff" --- sys/cam/scsi/scsi_all.h.orig Fri Dec 21 17:52:50 2007 +++ sys/cam/scsi/scsi_all.h Fri Dec 21 17:57:29 2007 @@ -90,6 +90,7 @@ typedef enum { * and text. */ SSQ_PRINT_SENSE = 0x0800, + SSQ_PRINT_SENSE_VERBOSE = 0x1000, SSQ_MASK = 0xff00 } scsi_sense_action_qualifier; @@ -104,6 +105,12 @@ typedef enum { /* Fatal error action, with table specified error code */ #define SS_FATAL SS_FAIL|SSQ_PRINT_SENSE + +/* Fatal error action, with table specified error code */ +/* This type of error doesn't imply malfunction of hardware and + * and indicates conditions that can occur in "normal" circumstances + */ +#define SS_FATAL_NORMAL SS_FAIL|SSQ_PRINT_SENSE_VERBOSE struct scsi_generic { --- sys/cam/scsi/scsi_all.c.orig Fri Dec 21 17:54:50 2007 +++ sys/cam/scsi/scsi_all.c Fri Dec 21 17:55:52 2007 @@ -1197,7 +1197,7 @@ static struct asc_table_entry asc_table[ "Rounded parameter") }, /* DTL WRSOMCAE */{SST(0x39, 0x00, SS_RDEF, "Saving parameters not supported") }, -/* DTL WRSOM */{SST(0x3A, 0x00, SS_FATAL|ENXIO, +/* DTL WRSOM */{SST(0x3A, 0x00, SS_FATAL_NORMAL|ENXIO, "Medium not present") }, /* DT WR OM */{SST(0x3A, 0x01, SS_FATAL|ENXIO, "Medium not present - tray closed") }, @@ -1395,7 +1395,7 @@ static struct asc_table_entry asc_table[ "End of user area encountered on this track") }, /* R */{SST(0x63, 0x01, SS_FATAL|ENOSPC, "Packet does not fit in available space") }, -/* R */{SST(0x64, 0x00, SS_FATAL|ENXIO, +/* R */{SST(0x64, 0x00, SS_FATAL_NORMAL|ENXIO, "Illegal mode for this track") }, /* R */{SST(0x64, 0x01, SS_RDEF, "Invalid packet size") }, --- sys/cam/cam_periph.c.orig Fri Dec 21 17:57:53 2007 +++ sys/cam/cam_periph.c Fri Dec 21 18:00:13 2007 @@ -1515,7 +1515,8 @@ camperiphscsisenseerror(union ccb *ccb, } sense_error_done: - if ((err_action & SSQ_PRINT_SENSE) != 0 + if (((err_action & SSQ_PRINT_SENSE) != 0 + || ((err_action & SSQ_PRINT_SENSE_VERBOSE) != 0 && bootverbose)) && (ccb->ccb_h.status & CAM_AUTOSNS_VALID) != 0) { cam_error_print(print_ccb, CAM_ESF_ALL, CAM_EPF_ALL); xpt_print_path(ccb->ccb_h.path); --------------060205080807050008050802-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 17:12:25 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B49C16A417 for ; Mon, 24 Dec 2007 17:12:25 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id B621713C45B for ; Mon, 24 Dec 2007 17:12:24 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (c-69-244-251-12.hsd1.fl.comcast.net [69.244.251.12]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBOHCEvu038426; Mon, 24 Dec 2007 10:12:20 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <476FE868.8080704@samsco.org> Date: Mon, 24 Dec 2007 12:12:08 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Brett Glass References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> In-Reply-To: <200712241653.JAA20845@lariat.net> 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 (pooker.samsco.org [168.103.85.57]); Mon, 24 Dec 2007 10:12:21 -0700 (MST) X-Spam-Status: No, score=2.0 required=5.4 tests=RCVD_IN_PBL, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 17:12:25 -0000 Brett Glass wrote: > At 09:10 AM 12/24/2007, Scott Long wrote: > >> Did you also nuke malloc debugging? > > I believe I did. I tried to take out all debugging to make it a fair test. > >>> They were. The drives are SATA. >> Connected to what controller? > > Whatever comes standard on the Intel S5000 motherboards. I believe that it > is Intel's own embedded SATA controller, which according to the spec sheet > is called their "ESB2-E" embedded SATA RAID controller. We are not using the > RAID capability. > >>>> 3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? >>> Whatever comes standard with Ubuntu. >> Which is??? > > EXT3. > >>> My guess, based on what I saw, is that UFS2 doesn't take as much advantage of >>> SMP as Linux's file system does and threads are blocking on file I/O. >> That's really just speculation on your part, though. > > Yes, it is -- though I'd like to think it is an educated guess. ;-) > I'd need to instrument either the benchmark code or the kernel to > tell for sure. But the test is, by its nature, bound by file I/O. > >> I can tell you from my experience that a thrashed namei cache looks a >> lot like slow disk I/O to the casual observer, and that tuning the dirhash is highly important. > > That's always been true. However, Squid's file layout tends to be > gentle on the file system. It lays out directories with no more than > 256 items in each, and the names of the files are just sequential > hexadecimal numbers -- which I'd expect ought to bring about near-perfect > if not perfect hashing. It's not the same kind of hashing. The kind of "hashing" that squid does on the filesystem is sub optimal for UFS performance. > If you set the kernel to expect 256 or more entries > per directory (I know that Adrian Chadd is on this list; do you recommend > 256 or 512?), you seem to get the best performance you are going to get. It sounds like you're pretty convinced you know what the problem is. For others who might want help with this, tweaking vfs.ufs.dirhash_maxmem is what is needed. A bit of a balancing act is needed if you're on i386 since you'll risk exhausting KVA unless you also tweak KVA_PAGES. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 17:21:13 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A207716A418 for ; Mon, 24 Dec 2007 17:21:13 +0000 (UTC) (envelope-from shieronymus@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 1E09C13C442 for ; Mon, 24 Dec 2007 17:21:12 +0000 (UTC) (envelope-from shieronymus@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1130451mue.6 for ; Mon, 24 Dec 2007 09:21:11 -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; bh=6JkgVb4fsakzzhylWWOyiZwTxCW9KN/ZMUi2rLSZj4A=; b=MIxx7IDVfu0CJbeRDJzclyhL4QXXCUn2VuN83dUZgufn9Wn9nmeNM3M1EZARIsiDpC3RnYPaBX5vzxhfuquWfs8LDWkg9uj7tYZTxzbK5cOtX93WbkdAOyPiUP80DD1XSYa2SdWTL0bjEv/VD2RzwQRq2mKaO58qgrNWniuWMfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=i7dsMLshWQNvIWEGDuGAZ+yB34ru2cH/0Rp1MVFAp++8pFBtySV5865aymaCHTu5OnYlNk0mJzKHnjPmPJR9xbUJrTbFFtkBInQxZNfycASnqOlyDQ07+V/7RITroPpDbgq0zeGZHF1P5SClsaXsWNTrvY/huc3qtk3OuyQoU3o= Received: by 10.78.165.16 with SMTP id n16mr5894440hue.63.1198515341969; Mon, 24 Dec 2007 08:55:41 -0800 (PST) Received: by 10.78.140.2 with HTTP; Mon, 24 Dec 2007 08:55:41 -0800 (PST) Message-ID: <70d306230712240855j3ecd0000w7a7f87cadc15652a@mail.gmail.com> Date: Mon, 24 Dec 2007 09:55:41 -0700 From: "Seth Hieronymus" To: stable@freebsd.org MIME-Version: 1.0 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: Subject: Instant Reboot with 7.0 BETA4 LifeFS Disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 17:21:13 -0000 In testing my Windows desktop with the 7.0 LiveFS disk ( 7.0-BETA4-amd64-livefs.iso), I get an instant reboot when the CD is run. As far as I can tell, no console messages are printed, so it seems the error happens very early in the loading process. Other FreeBSD versions (6.2, i386 7.0) also exhibit the same behavior. If left alone, the computer will just continually reboot. The specs of the system are: Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard AMD Athlon64 3800+ Newcastle 2.4GHz Promise FastTrak 579 RAID Controller (PDC20579) 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card My guess is that the disk controller is not supported. Should this cause an instant reboot with a live filesystem disk? Is there anyway to debug this since no console messages are printed? Thanks for the help, Seth Hieronymus From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 17:23:23 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 090A716A419 for ; Mon, 24 Dec 2007 17:23:23 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id AAA9013C465 for ; Mon, 24 Dec 2007 17:23:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id lBOHNLsF062094; Mon, 24 Dec 2007 12:23:21 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id lBOHNLtt049769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Dec 2007 12:23:21 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200712241723.lBOHNLtt049769@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Dec 2007 12:23:30 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <476FE868.8080704@samsco.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 17:23:23 -0000 At 12:12 PM 12/24/2007, Scott Long wrote: >For others who might want help with this, tweaking >vfs.ufs.dirhash_maxmem is what is needed. A bit of a balancing act is >needed if you're on i386 since you'll risk exhausting KVA unless you >also tweak KVA_PAGES. Hi Scott, How does one know if the vfs.ufs.dirhash_maxmem is set too high and are exhausting KVA ? We set it quite high on our pop3/imap servers since Maildir can contain many small files. eg % sysctl -a vfs.ufs | grep -i dir vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 99097152 vfs.ufs.dirhash_mem: 59259609 ---Mike >Scott >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 17:57:02 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E118116A417 for ; Mon, 24 Dec 2007 17:57:02 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3DF13C461 for ; Mon, 24 Dec 2007 17:57:02 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id KAA21950; Mon, 24 Dec 2007 10:56:49 -0700 (MST) Message-Id: <200712241756.KAA21950@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Dec 2007 10:56:45 -0700 To: Scott Long From: Brett Glass In-Reply-To: <476FE868.8080704@samsco.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 17:57:03 -0000 At 10:12 AM 12/24/2007, Scott Long wrote: >It's not the same kind of hashing. The kind of "hashing" that squid >does on the filesystem is sub optimal for UFS performance. Squid doesn't do any "hashing" on the file system, as far as I know. It does, of course, have a hashed directory of cached Web objects. What it does, however, is lay out files and subdirectories so that there are no more than 256 entries in each directory. (The top level directory usually has only 16 subdirectories in it.) What I am saying is that by keeping directory size down and using hexadecimal numbers as the file names, the Squid storage conventions will likely allow the UFS hashing scheme to work very well -- possibly optimally. Which isn't a surprise, because they were designed with UFS in mind. >It sounds like you're pretty convinced you know what the problem is. Again, I'd have to instrument either the FreeBSD kernel or Squid to be 100% sure. But it APPEARS that it's a problem with large numbers of threads trying to do file I/O simultaneously and blocking. (Aside: I wish that Squid used FreeBSD's sendfile(2) API once it got past the headers and was just streaming out a cached page. I suspect that this would make delivery of cache hits a lot more efficient, because sendfile(2) does "zero copy" transfers and works entirely within the kernel.) >For others who might want help with this, tweaking >vfs.ufs.dirhash_maxmem is what is needed. A bit of a balancing act is >needed if you're on i386 since you'll risk exhausting KVA unless you >also tweak KVA_PAGES. If you'd like, I can reassemble the system and try this. What would your suggested values for these tunables be? --Brett From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 18:01:32 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CBAB16A418 for ; Mon, 24 Dec 2007 18:01:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 98B1913C4D3; Mon, 24 Dec 2007 18:01:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <476FF3FA.9020803@FreeBSD.org> Date: Mon, 24 Dec 2007 19:01:30 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Bengt Ahlgren References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: 6.3-RC1: different port/package versions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 18:01:32 -0000 Bengt Ahlgren wrote: > Hi! > > I'm trying out 6.3-RC1, but had some problems with getting different > (and incompatible) versions of packages and ports. > > When installing packages with sysinstall via FTP, i get older versions > compared to using pkg_add -r. The latter (correctly) takes the > packages from the packages-6.3-release directory, but sysinstall seems > to take the (older) in packages-6-stable. In the sysinstall options, > setting "Release Name" to 6.3-RELEASE only results in that it says > that the directory does not exist on the FTP server. > > Is this expected behaviour? Yes, sysinstall hadn't yet been changed to point to the release directory, which was only recently created. Kris From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 18:11:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8F3616A469 for ; Mon, 24 Dec 2007 18:11:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C8EBA13C459; Mon, 24 Dec 2007 18:11:47 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <476FF662.6050604@FreeBSD.org> Date: Mon, 24 Dec 2007 19:11:46 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Krassimir Slavchev References: <476A5EE1.9000003@bulinfo.net> In-Reply-To: <476A5EE1.9000003@bulinfo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: Performance! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 18:11:48 -0000 Krassimir Slavchev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I have read all related threads about performance problems with multi > core systems but still have no idea what to do to make thinks better. > Below are results of testing postgresql on HP DL380G5 using sysbench. > The results are comparable to: > http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 > but the same tests running on the same hardware using Linux (kernel > 2.6.18-53.1.4.el5 SMP x86_64) are very different. > PostgreSQL is tuned equal. > > dmesg: > ... > CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > > Features=0xbfebfbff > > Features2=0xce3bd> > AMD Features=0x20000800 > AMD Features2=0x1 > Cores per package: 4 > usable memory = 8575655936 (8178 MB) > avail memory = 8288337920 (7904 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > ... > > test: > sysbench --num-threads=${i} --test=oltp --pgsql-user=bench > - --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0 > - --oltp-read-only=on run > > tuning: > kern.ipc.shmmax=2147483647 > kern.ipc.shmall=524288 > kern.ipc.semmsl=512 > kern.ipc.semmap=256 > kern.ipc.somaxconn=2048 > kern.maxfiles=65536 > vfs.read_max=32 > > kern.ipc.semmni=256 > kern.ipc.semmns=2048 > > results: > FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE > #threads #transactions/sec user/system > 1 500 7.4%,5.3% > 5 1990 30.9%,23.4% > 10 2510 39.9%,35.0% > 20 2549 44.5%,43.5% > 40 1921 29.8%,59.4% > 60 1580 22.7%,70.6% > 80 1341 18.9%,75.9% > 100 1227 16.5%,79.3% > > Linux > #threads #transactions/sec > 1 693 > 5 3539 > 10 5789 > 20 5791 > 40 5661 > 60 5517 > 80 5401 > 100 5319 > > > What can be done to improve these results? > > Best Regards > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFHal7hxJBWvpalMpkRAsaiAJ9G3ZoTv6cUbR4yix07TEMf7PKm7gCgoroM > +xvcXkcaFjSTxYfjk5rqMko= > =Tpsq > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > . > postgresql has some poor default settings on FreeBSD. You need to add: stats_command_string = off update_process_title = off Kris From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 19:01:31 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CC016A417; Mon, 24 Dec 2007 19:01:31 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (thingy.kcilink.com [74.92.149.59]) by mx1.freebsd.org (Postfix) with ESMTP id B89ED13C457; Mon, 24 Dec 2007 19:01:30 +0000 (UTC) (envelope-from vivek@khera.org) Received: from host-121.int.kcilink.com (host-121.int.kcilink.com [192.168.7.121]) by yertle.kcilink.com (Postfix) with ESMTP id B841CC943A; Mon, 24 Dec 2007 14:01:29 -0500 (EST) Message-Id: <66DDD8B5-9893-4C4F-8A18-9FEE85017D3C@khera.org> From: Vivek Khera To: Michael Proto In-Reply-To: <476D59B6.4030609@jellydonut.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 24 Dec 2007 14:01:29 -0500 References: <476D59B6.4030609@jellydonut.org> X-Mailer: Apple Mail (2.915) Cc: Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: Trying to initialize padlock support on Via C7 Eden CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 19:01:31 -0000 On Dec 22, 2007, at 1:38 PM, Michael Proto wrote: > I purchased a Jetway J7F4K1G2E w/VIA Eden 1.2GHz cpu/motherboard combo > (http://e-itx.com/jetway-j7f4k1g2e-mini-itx-motherboard.html) that I'm > trying to get working with the FreeBSD padlock driver. Based on what I > see from the manufacturer's CPU support list , > http://www.jetwaycomputer.com/VIA3.html, I have a C7 Esther processer. > > It looks like the CPUID for this processor isn't recognized by FreeBSD > 6.3-RC1 or 7.0-BETA3. GENERIC on 7.0-BETA3 detects the CPU as follows: FWIW, I have the exact same motherboard from E-ITX as well. I run FreeNAS on mine. FreeNAS is running the FreeBSD 6.2-REL-p8 kernel and detects the CPU just fine: CPU: VIA C7 Esther+RNG+AES+AES-CTR+SHA1+SHA256+RSA (1200.01-MHz 686- class CPU) Origin = "CentaurHauls" Id = 0x6a9 Stepping = 9 Features = 0xa7c9baff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CLFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE> Features2=0x181 [[ snip ]] PadLock: HW support loaded for AES-CBC,SHA1,SHA256. It seems you have a newer ID and different Stepping than mine. I have no way to boot 6.3 on this box until FreeNAS is using 6.3. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 22:24:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A77EC16A421; Mon, 24 Dec 2007 22:24:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 3E36713C43E; Mon, 24 Dec 2007 22:24:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBOMOChC015490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Dec 2007 09:24:18 +1100 Date: Tue, 25 Dec 2007 09:24:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20071224131906.GB57756@deviant.kiev.zoral.com.ua> Message-ID: <20071225091009.L3200@besplex.bde.org> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <20071222201613.GX57756@deviant.kiev.zoral.com.ua> <20071223095314.G1323@delplex.bde.org> <20071224131906.GB57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mark Fullmer , freebsd-stable@freebsd.org, Bruce Evans , "Freebsd-Net@Freebsd. Org" Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 22:24:21 -0000 On Mon, 24 Dec 2007, Kostik Belousov wrote: > On Sun, Dec 23, 2007 at 10:20:31AM +1100, Bruce Evans wrote: >> On Sat, 22 Dec 2007, Kostik Belousov wrote: >>> Ok, since you talked about this first :). I already made the following >>> patch, but did not published it since I still did not inspected all >>> callers of MNT_VNODE_FOREACH() for safety of dropping mount interlock. >>> It shall be safe, but better to check. Also, I postponed the check >>> until it was reported that yielding does solve the original problem. >> >> Good. I'd still like to unobfuscate the function call. > What do you mean there ? Make the loop control and overheads clear by making the function call explicit, maybe by expanding MNT_VNODE_FOREACH() inline after fixing the style bugs in it. Later, fix the code to match the comment again by not making a function call in the usual case. This is harder. >> Putting the count in the union seems fragile at best. Even if nothing >> can access the marker vnode, you need to context-switch its old contents >> while using it for the count, in case its old contents is used. Vnode- >> printing routines might still be confused. > Could you, please, describe what you mean by "contex-switch" for the > VMARKER ? Oh, I didn't notice that the marker vnode is out of band (a whole new vnode is malloced for each marker). The context switching would be needed if an ordinary active vnode that uses the union is used as a marker. Bruce From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 01:17:07 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 396A316A419 for ; Tue, 25 Dec 2007 01:17:07 +0000 (UTC) (envelope-from maf@splintered.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id CEC9313C459 for ; Tue, 25 Dec 2007 01:17:06 +0000 (UTC) (envelope-from maf@splintered.net) Received: (qmail 19758 invoked from network); 25 Dec 2007 01:17:05 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 25 Dec 2007 01:17:05 -0000 In-Reply-To: <20071224131906.GB57756@deviant.kiev.zoral.com.ua> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <20071222201613.GX57756@deviant.kiev.zoral.com.ua> <20071223095314.G1323@delplex.bde.org> <20071224131906.GB57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <833223E8-B1ED-4358-A992-F3789E4B3070@splintered.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Mon, 24 Dec 2007 20:16:50 -0500 To: Kostik Belousov X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 01:17:07 -0000 On Dec 24, 2007, at 8:19 AM, Kostik Belousov wrote: > > Mark, could you, please, retest the patch below in your setup ? > I want to put a change or some edition of it into the 7.0 release, and > we need to move fast to do this. It's building now. The testing will run overnight. Your patch to ffs_sync() and vfs_msync() stopped the periodic packet loss, but other file system activity such as (cd /; tar -cf - .) > /dev/ null will cause dropped packets. Same behavior, packets never make it up to the IP layer. -- mark From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 01:55:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF3516A41A for ; Tue, 25 Dec 2007 01:55:39 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id C4B1E13C465 for ; Tue, 25 Dec 2007 01:55:38 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=NUA9UdKaH8wA:15 a=p83PXfNmxBsA:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=i-ZN8qL3AAAA:8 a=dDU4fGbARuVRaFKH0QoA:9 a=WrWZBcDk8aj8Od1NnZEeBufXWr8A:4 a=gi0PWCVxevcA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50941] helo=mail.kc8onw.net) by mail-out1.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id E0/49-28635-91360774 for ; Mon, 24 Dec 2007 20:55:37 -0500 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id 1D9C72842D for ; Mon, 24 Dec 2007 20:55:37 -0500 (EST) Received: from 80.91.220.50 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Mon, 24 Dec 2007 20:55:37 -0500 (EST) Message-ID: <60100.80.91.220.50.1198547737.squirrel@www.kc8onw.net> Date: Mon, 24 Dec 2007 20:55:37 -0500 (EST) From: jonathan@kc8onw.net To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: em1: Unable to allocate bus resource: memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 01:55:39 -0000 I just got a new Intel Gb PCIe network card and installed it today. The card is seen by the system but the driver fails to initialize it with the error seen in the email subject. I'm running FreeBSD RELENG_7 from around BETA3 but can upgrade if needed FreeBSD storage.kc8onw.net 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Fri Nov 30 12:40:25 AST 2007 root@storage.kc8onw.net:/usr/obj/usr/src/sys/STORAGE i386 A standard dmesg is available at http://www.kc8onw.net/~jonathan/temp/dmesg.boot a verbose one can be uploaded if needed. The only changes to the BIOS were to run AHCI instead of emulation for all the SATA drives. Thank you, Jonathan Stewart From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 02:20:16 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472C516A419 for ; Tue, 25 Dec 2007 02:20:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 21A2013C4EC for ; Tue, 25 Dec 2007 02:20:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3189530waf.3 for ; Mon, 24 Dec 2007 18:20:15 -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=Mh51avYwYsEa6TkYXEh7IJTBzK86tIqnnQeL517VG+w=; b=KciAnbyyUALTIJHPXjsIsoQNc5aSJoa8mVOIvLqGMHs2HOvoQ2mo2SEZ4nTB1kdtJlk8KIc2WbIAVWtk7GTY3y1V3WlK6YlsLKzaFAt4j+Fxc/OoHootyjyOPVwJutY84zlN/Wnabg2CnkDM5oHNuPGjOlu4GyxHwfILR/kX610= 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=HT9En6zeQDf4Ai1zvAZqhJNarEN05agy5XJGNaZR88se49kMq1XFGxM4OE1wfXhFIX03BJv5VgtCjfrTABWvyCnJxhx5Fmj876cGyKbli/HWSP+HWJr9fVWzQxQgkLkmEOE4DqclWzM2AdFfv73XoHBx8b4fZwf89Pju7teR4Y8= Received: by 10.142.242.8 with SMTP id p8mr1612624wfh.232.1198549215784; Mon, 24 Dec 2007 18:20:15 -0800 (PST) Received: by 10.143.155.13 with HTTP; Mon, 24 Dec 2007 18:20:15 -0800 (PST) Message-ID: Date: Tue, 25 Dec 2007 11:20:15 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Brett Glass" In-Reply-To: <200712241756.KAA21950@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> X-Google-Sender-Auth: 8f3294b8dd25f63d Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 02:20:16 -0000 On 25/12/2007, Brett Glass wrote: > >It sounds like you're pretty convinced you know what the problem is. > > Again, I'd have to instrument either the FreeBSD kernel or Squid to > be 100% sure. But it APPEARS that it's a problem with large > numbers of threads trying to do file I/O simultaneously and blocking. I'd still check the namei cache; Squid can and does chew through stupid amounts of pathnames. Its why I hacked up that "ifs" thing a few years ago but was suddenly (contractually) required to not hack on caching for a while.. > (Aside: I wish that Squid used FreeBSD's sendfile(2) API once it got past > the headers and was just streaming out a cached page. I suspect that > this would make delivery of cache hits a lot more efficient, because > sendfile(2) does "zero copy" transfers and works entirely within > the kernel.) There's plenty more work to do in Squid before sendfile() would actually matter. I'm slowly working it all out in my spare time and as support contract funding permits. In fact, I think the Linux evolution of sendfile lets you write out a userspace buffer before you glue it to something else like a socket or file fd. That'd be more helpful here. (No idea on the directory sizes these days - perhaps larger files with dir hashing would help; but I certainly haven't benchmarked it. I just use COSS for small objects. :) Adrian -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 02:38:22 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5601E16A417 for ; Tue, 25 Dec 2007 02:38:22 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 17BB113C4F9 for ; Tue, 25 Dec 2007 02:38:21 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.1) with ESMTP id lBP2buri044611 for ; Mon, 24 Dec 2007 20:37:57 -0600 (CST) (envelope-from stephen@math.missouri.edu) Message-ID: <47706D1C.5010201@math.missouri.edu> Date: Mon, 24 Dec 2007 20:38:20 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.11) Gecko/20071221 SeaMonkey/1.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 7.0 freezes with nvidia card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 02:38:22 -0000 I have a Dell D800 Latitude laptop. If I use FreeBSD 7.0, and xorg with the nv driver, when I exit X, sometimes it simply freezes. I tried it with the vesa driver. and the problem didn't seem to happen, but the vesa driver is unable to get the 1680x1050 resolution of my monitor. I sent a similar message a while back because I thought the ndis driver was also involved. But I have since disabled ndis. (However when ndis is on, the problem is worse.) Any ideas? Stephen From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 05:27:56 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6F316A419; Tue, 25 Dec 2007 05:27:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 50E3A13C4D9; Tue, 25 Dec 2007 05:27:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J72KW-0003Rc-O5; Tue, 25 Dec 2007 07:27:55 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBP5RnJ7004058; Tue, 25 Dec 2007 07:27:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBP5Rnba004057; Tue, 25 Dec 2007 07:27:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Dec 2007 07:27:49 +0200 From: Kostik Belousov To: Mark Fullmer Message-ID: <20071225052749.GE57756@deviant.kiev.zoral.com.ua> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <20071222201613.GX57756@deviant.kiev.zoral.com.ua> <20071223095314.G1323@delplex.bde.org> <20071224131906.GB57756@deviant.kiev.zoral.com.ua> <833223E8-B1ED-4358-A992-F3789E4B3070@splintered.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wwSkEpePV3aFlXly" Content-Disposition: inline In-Reply-To: <833223E8-B1ED-4358-A992-F3789E4B3070@splintered.net> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: bb9f355b5be917825c280d06cf0e20ab X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1960 [Dec 24 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 05:27:56 -0000 --wwSkEpePV3aFlXly Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 24, 2007 at 08:16:50PM -0500, Mark Fullmer wrote: >=20 > On Dec 24, 2007, at 8:19 AM, Kostik Belousov wrote: >=20 > > > >Mark, could you, please, retest the patch below in your setup ? > >I want to put a change or some edition of it into the 7.0 release, and > >we need to move fast to do this. >=20 > It's building now. The testing will run overnight. >=20 > Your patch to ffs_sync() and vfs_msync() stopped the periodic packet =20 > loss, > but other file system activity such as (cd /; tar -cf - .) > /dev/=20 > null will > cause dropped packets. Same behavior, packets never make it up to the > IP layer. What fs do you use ? If FFS, are softupdates turned on ? Please, show the total time spent in the softdepflush process. Also, try to add the FULL_PREEMPTION kernel config option and report whether it helps. --wwSkEpePV3aFlXly Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHcJTUC3+MBN1Mb4gRAp8rAJ48R0XeTKFoQjBv9GihgvneGikMgQCeMACM VWaDAdA/fUzq+OtvQA7tdY0= =pqDG -----END PGP SIGNATURE----- --wwSkEpePV3aFlXly-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 06:10:27 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CACA16A417 for ; Tue, 25 Dec 2007 06:10:27 +0000 (UTC) (envelope-from davidb@boothscientific.com) Received: from smtp119.sbc.mail.re3.yahoo.com (smtp119.sbc.mail.re3.yahoo.com [66.196.96.92]) by mx1.freebsd.org (Postfix) with SMTP id CCA7713C447 for ; Tue, 25 Dec 2007 06:10:26 +0000 (UTC) (envelope-from davidb@boothscientific.com) Received: (qmail 12479 invoked from network); 25 Dec 2007 05:43:45 -0000 Received: from unknown (HELO ?192.168.2.27?) (valleyresearch@sbcglobal.net@69.150.166.75 with login) by smtp119.sbc.mail.re3.yahoo.com with SMTP; 25 Dec 2007 05:43:45 -0000 X-YMail-OSG: Kk2bqHgVM1mFdz2E8RMdq680p_M6b_HxyCNKm7rRqwskZvWFN0EnEMR4gJcwnltAtYAt.2qBOOYsJ_piVph2fRscYsnRq5W4ibChlssBUcFyXWy44CyHerFj0nrbRLapi_IbE2mkoKAYyiE- From: David Booth To: freebsd-stable@freebsd.org Date: Mon, 24 Dec 2007 23:43:34 -0600 User-Agent: KMail/1.9.7 References: <47706D1C.5010201@math.missouri.edu> In-Reply-To: <47706D1C.5010201@math.missouri.edu> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200712242343.34495.davidb@boothscientific.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 7.0 freezes with nvidia card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidb@boothscientific.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 06:10:27 -0000 On Monday 24 December 2007, Stephen Montgomery-Smith wrote: > I have a Dell D800 Latitude laptop. If I use FreeBSD 7.0, and xorg > with the nv driver, when I exit X, sometimes it simply freezes. I > tried it with the vesa driver. and the problem didn't seem to > happen, but the vesa driver is unable to get the 1680x1050 > resolution of my monitor. > > I sent a similar message a while back because I thought the ndis > driver was also involved. But I have since disabled ndis. > (However when ndis is on, the problem is worse.) > > Any ideas? > > Stephen > _______________________________________________ Have you tried the Nvidia driver from ports/x11? It works well for me on my Dell I8600. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 06:20:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8416B16A419 for ; Tue, 25 Dec 2007 06:20:48 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6290C13C45A for ; Tue, 25 Dec 2007 06:20:48 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.1) with ESMTP id lBP6KGcp048984; Tue, 25 Dec 2007 00:20:16 -0600 (CST) (envelope-from stephen@math.missouri.edu) Message-ID: <4770A137.4070600@math.missouri.edu> Date: Tue, 25 Dec 2007 00:20:39 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.11) Gecko/20071221 SeaMonkey/1.1.7 MIME-Version: 1.0 To: davidb@boothscientific.com References: <47706D1C.5010201@math.missouri.edu> <200712242343.34495.davidb@boothscientific.com> In-Reply-To: <200712242343.34495.davidb@boothscientific.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 freezes with nvidia card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 06:20:48 -0000 David Booth wrote: > On Monday 24 December 2007, Stephen Montgomery-Smith wrote: >> I have a Dell D800 Latitude laptop. If I use FreeBSD 7.0, and xorg >> with the nv driver, when I exit X, sometimes it simply freezes. I >> tried it with the vesa driver. and the problem didn't seem to >> happen, but the vesa driver is unable to get the 1680x1050 >> resolution of my monitor. >> >> I sent a similar message a while back because I thought the ndis >> driver was also involved. But I have since disabled ndis. >> (However when ndis is on, the problem is worse.) >> >> Any ideas? >> >> Stephen >> _______________________________________________ > > Have you tried the Nvidia driver from ports/x11? It works well for me > on my Dell I8600. That is what I was originally using. But that also froze. I switched to nv in hopes that the problem would go away. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 09:12:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F7F16A419 for ; Tue, 25 Dec 2007 09:12:45 +0000 (UTC) (envelope-from jfvogel@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 9BFF113C43E for ; Tue, 25 Dec 2007 09:12:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so1381426fgg.35 for ; Tue, 25 Dec 2007 01:12:42 -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=N+X3SUWbytTP0khppQXjoRGuIe+nOVxRSQ4EYOJsgcU=; b=P3r8MoHLG/OIhO5xFCGou8VBFEt3ykgsYrr1T/VXRcK5kKEZDRwmEz4jF0MX6nld8j96odHN8YtluAiQ/sjvJ4lal0ATz+2U/+nYm3Tcxk/MYSNVvZU30LhgPkRoaz1yFOvwD/5BjxLK+lcjkf8eAQCkcHidrlhgnSLuJDhD/c8= 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=O7yze+zmXNgXf/SbjBdlbMcXfqjYy/MaZIJbGqaMbzqmSa2M9P8Pt4hRG8YNd8wDzEq5C3+DS/9S4e+YBjpjAA2zpJvw7VnmDMQICeeA5a1NFttRGP5DtEhZXeSLwHF5o8uKUSVKf9hoxKjUhuAOqQyFxLpUHIOTCFBU6GmnOQ4= Received: by 10.86.9.8 with SMTP id 8mr5383332fgi.70.1198573962016; Tue, 25 Dec 2007 01:12:42 -0800 (PST) Received: by 10.86.97.10 with HTTP; Tue, 25 Dec 2007 01:12:41 -0800 (PST) Message-ID: <2a41acea0712250112w45e6241bmd51d2d8d16f5db83@mail.gmail.com> Date: Tue, 25 Dec 2007 01:12:41 -0800 From: "Jack Vogel" To: jonathan@kc8onw.net In-Reply-To: <60100.80.91.220.50.1198547737.squirrel@www.kc8onw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <60100.80.91.220.50.1198547737.squirrel@www.kc8onw.net> Cc: freebsd-stable@freebsd.org Subject: Re: em1: Unable to allocate bus resource: memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 09:12:45 -0000 On Dec 24, 2007 5:55 PM, wrote: > I just got a new Intel Gb PCIe network card and installed it today. The > card is seen by the system but the driver fails to initialize it with the > error seen in the email subject. > > I'm running FreeBSD RELENG_7 from around BETA3 but can upgrade if needed > FreeBSD storage.kc8onw.net 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Fri Nov 30 > 12:40:25 AST 2007 root@storage.kc8onw.net:/usr/obj/usr/src/sys/STORAGE > i386 > > A standard dmesg is available at > http://www.kc8onw.net/~jonathan/temp/dmesg.boot a verbose one can be > uploaded if needed. > > The only changes to the BIOS were to run AHCI instead of emulation for all > the SATA drives. > > Thank you, > Jonathan Stewart the dmesg is unhelpful, is this a new adapter? please show me a pciconf -l Happy Holidays, Jack From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 09:48:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFBED16A417 for ; Tue, 25 Dec 2007 09:48:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id BC77113C45A for ; Tue, 25 Dec 2007 09:48:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1J76P2-0006SF-8m for freebsd-stable@freebsd.org; Tue, 25 Dec 2007 11:48:48 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Dec 2007 11:48:48 +0200 From: Danny Braniss Message-ID: Subject: zfs & diskless boot problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 09:48:50 -0000 Zfs uses /boot/zfs to keep track of it's pools, but in a diskless environment, this is a read-only fs. This causes several inconveniences, - /etc/rc.d/zfs needs : zfs_start_main() { dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` if [ ${dlv:=0} -ne 0 ]; then zpool import -a fi ... - how important is /boot/zfs? danny From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 10:36:38 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6A816A417; Tue, 25 Dec 2007 10:36:38 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id B4A0313C442; Tue, 25 Dec 2007 10:36:38 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id D52D01CD4B; Tue, 25 Dec 2007 11:36:36 +0100 (CET) Date: Tue, 25 Dec 2007 11:36:36 +0100 From: Jan Srzednicki To: Maxim Konovalov Message-ID: <20071225103636.GA89362@oak.pl> References: <20071127135320.GJ2045@oak.pl> <474DB1D0.3010100@elischer.org> <20071128183001.GQ2045@oak.pl> <474DB6B3.1020202@elischer.org> <20071130093628.GS2045@oak.pl> <20071225133012.M40739@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071225133012.M40739@mp2.macomnet.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, Adrian Chadd , freebsd-stable@freebsd.org, Julian Elischer Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 10:36:39 -0000 On Tue, Dec 25, 2007 at 01:30:36PM +0300, Maxim Konovalov wrote: > On Fri, 30 Nov 2007, 19:26+0900, Adrian Chadd wrote: > > > Finding out more about the socket thats been created and what its > > clashing with might help. I'd do it myself but I'm not sure how to > > duplicate the issue. > > > Have you tried to turn net.inet.ip.portrange.randomized off? Yes, it didn't change anything. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 10:55:50 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B6716A41A; Tue, 25 Dec 2007 10:55:50 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id B744D13C442; Tue, 25 Dec 2007 10:55:49 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id lBPAUa5N010042; Tue, 25 Dec 2007 13:30:37 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Tue, 25 Dec 2007 13:30:36 +0300 (MSK) From: Maxim Konovalov To: Adrian Chadd In-Reply-To: Message-ID: <20071225133012.M40739@mp2.macomnet.net> References: <20071127135320.GJ2045@oak.pl> <474DB1D0.3010100@elischer.org> <20071128183001.GQ2045@oak.pl> <474DB6B3.1020202@elischer.org> <20071130093628.GS2045@oak.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Jan Srzednicki , Julian Elischer , freebsd-stable@freebsd.org Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 10:55:50 -0000 On Fri, 30 Nov 2007, 19:26+0900, Adrian Chadd wrote: > On 30/11/2007, Jan Srzednicki wrote: > > > Most of the relevant sockets (that is, between the two host > > mentioned) are in the ESTABLISHED state (200-400 of those). Only > > 20-40 are in TIME_WAIT state (these tend to be from a more > > ephemeric POP3 service). Most of the EADDRINUSE happen for the > > IMAP4 service. > > I'd probably start by patching the places in the tcp code > (src/sys/netinet/tcp_usrreq.c) which returns this error > (Its returned in other places but that seems to me to be the most > likely from your description.) > > Insert some code to print out information about the current socket and > the "oinp" value returned from in_pcbconnect_setup() (if this is the > place where the error occured.) > > Finding out more about the socket thats been created and what its > clashing with might help. I'd do it myself but I'm not sure how to > duplicate the issue. > Have you tried to turn net.inet.ip.portrange.randomized off? -- Maxim Konovalov From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 10:59:04 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59B3516A41B for ; Tue, 25 Dec 2007 10:59:04 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2746D13C467 for ; Tue, 25 Dec 2007 10:59:03 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=DTl47DImNrQA:15 a=Vp1h37jBdlIA:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=i-ZN8qL3AAAA:8 a=moiAjBSNY5dTCljGyoIA:9 a=cPp63lDbwrHPewQQc8AA:7 a=MM3Qv9fe0GfQDTUa-fHOdoj5xpQA:4 a=jtOyKYpszwUA:10 a=LY0hPdMaydYA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50776] helo=mail.kc8onw.net) by mail-out1.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id 38/21-28635-672E0774 for ; Tue, 25 Dec 2007 05:59:03 -0500 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id B91172842D; Tue, 25 Dec 2007 05:59:00 -0500 (EST) Received: from 80.91.220.50 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Tue, 25 Dec 2007 05:59:00 -0500 (EST) Message-ID: <64562.80.91.220.50.1198580340.squirrel@www.kc8onw.net> In-Reply-To: <2a41acea0712250112w45e6241bmd51d2d8d16f5db83@mail.gmail.com> References: <60100.80.91.220.50.1198547737.squirrel@www.kc8onw.net> <2a41acea0712250112w45e6241bmd51d2d8d16f5db83@mail.gmail.com> Date: Tue, 25 Dec 2007 05:59:00 -0500 (EST) From: jonathan@kc8onw.net To: "Jack Vogel" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: em1: Unable to allocate bus resource: memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 10:59:04 -0000 On Tue, December 25, 2007 4:12 am, Jack Vogel wrote: > On Dec 24, 2007 5:55 PM, wrote: > >> I just got a new Intel Gb PCIe network card and installed it today. >> The >> card is seen by the system but the driver fails to initialize it with >> the error seen in the email subject. >> >> I'm running FreeBSD RELENG_7 from around BETA3 but can upgrade if >> needed FreeBSD storage.kc8onw.net 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Fri >> Nov 30 >> 12:40:25 AST 2007 >> root@storage.kc8onw.net:/usr/obj/usr/src/sys/STORAGE >> i386 >> >> A standard dmesg is available at >> http://www.kc8onw.net/~jonathan/temp/dmesg.boot a verbose one can be >> uploaded if needed. >> >> The only changes to the BIOS were to run AHCI instead of emulation for >> all the SATA drives. >> >> Thank you, >> Jonathan Stewart >> > > the dmesg is unhelpful, is this a new adapter? please show me a pciconf > -l Brand new, just got it today :) pciconf -lv at http://www.kc8onw.net/~jonathan/temp/pciconf_lv.txt pciconf -l: (sorry if it's mangled) hostb0@pci0:0:0:0: class=0x060000 card=0x81e91043 chip=0x29908086 rev=0x02 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x00008086 chip=0x29918086 rev=0x02 hdr=0x01 vgapci0@pci0:0:2:0: class=0x030000 card=0x81e91043 chip=0x29928086 rev=0x02 hdr=0x00 em0@pci0:0:25:0: class=0x020000 card=0x82681043 chip=0x104a8086 rev=0x02 hdr=0x00 uhci0@pci0:0:26:0: class=0x0c0300 card=0x81eb1043 chip=0x28348086 rev=0x02 hdr=0x00 uhci1@pci0:0:26:1: class=0x0c0300 card=0x81eb1043 chip=0x28358086 rev=0x02 hdr=0x00 ehci0@pci0:0:26:7: class=0x0c0320 card=0x81eb1043 chip=0x283a8086 rev=0x02 hdr=0x00 none0@pci0:0:27:0: class=0x040300 card=0x81eb1043 chip=0x284b8086 rev=0x02 hdr=0x00 pcib2@pci0:0:28:0: class=0x060400 card=0x81eb1043 chip=0x283f8086 rev=0x02 hdr=0x01 pcib3@pci0:0:28:4: class=0x060400 card=0x81eb1043 chip=0x28478086 rev=0x02 hdr=0x01 uhci2@pci0:0:29:0: class=0x0c0300 card=0x81eb1043 chip=0x28308086 rev=0x02 hdr=0x00 uhci3@pci0:0:29:1: class=0x0c0300 card=0x81eb1043 chip=0x28318086 rev=0x02 hdr=0x00 uhci4@pci0:0:29:2: class=0x0c0300 card=0x81eb1043 chip=0x28328086 rev=0x02 hdr=0x00 ehci1@pci0:0:29:7: class=0x0c0320 card=0x81eb1043 chip=0x28368086 rev=0x02 hdr=0x00 pcib4@pci0:0:30:0: class=0x060401 card=0x81eb1043 chip=0x244e8086 rev=0xf2 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x81eb1043 chip=0x28148086 rev=0x02 hdr=0x00 atapci2@pci0:0:31:2: class=0x010601 card=0x81eb1043 chip=0x28218086 rev=0x02 hdr=0x00 none1@pci0:0:31:3: class=0x0c0500 card=0x81eb1043 chip=0x283e8086 rev=0x02 hdr=0x00 em1@pci0:3:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 hdr=0x00 atapci0@pci0:2:0:0: class=0x010601 card=0x81e41043 chip=0x2363197b rev=0x02 hdr=0x00 atapci1@pci0:2:0:1: class=0x010185 card=0x81e41043 chip=0x2363197b rev=0x02 hdr=0x00 fwohci0@pci0:4:1:0: class=0x0c0010 card=0x808b1043 chip=0x8023104c rev=0x00 hdr=0x00 fxp0@pci0:4:3:0: class=0x020000 card=0x405c1014 chip=0x12298086 rev=0x08 hdr=0x00 Thank you, Jonathan Stewart From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 14:10:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2845316A419 for ; Tue, 25 Dec 2007 14:10:03 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id DEFD013C4E1 for ; Tue, 25 Dec 2007 14:10:02 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.14.1/8.13.1) with ESMTP id lBPDbLe9025663 for ; Tue, 25 Dec 2007 08:37:21 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.14.1/8.13.1/Submit) id lBPDbG4Q025662 for freebsd-stable@freebsd.org; Tue, 25 Dec 2007 08:37:16 -0500 (EST) (envelope-from bv) Date: Tue, 25 Dec 2007 08:37:15 -0500 From: Bill Vermillion To: freebsd-stable@freebsd.org Message-ID: <20071225133715.GA25424@wjv.com> References: <20071225120015.6174B16A4D4@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071225120015.6174B16A4D4@hub.freebsd.org> User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 14:10:03 -0000 It's Tue, Dec 25, 2007 at 12:00 . I'm in a small dim room with doors labeled "Dungeon" and "Forbidden". There is noise, the door marked Dungeon flies open and freebsd-stable-request@freebsd.org SHOUTS: > Date: Mon, 24 Dec 2007 08:49:36 -0700 > From: Brett Glass > Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? > To: Scott Long > Cc: stable@freebsd.org > At 07:14 AM 12/24/2007, Scott Long wrote: > >Brett, > >There could be several problems here: > >1. WITNESS, INVARIANTS, malloc debugging. Are any of these > >turned on for you? I don't recall if malloc debugging got > >turned off yet for the 7.0 snapshots. > I nuked debugging when I recompiled the kernel with SCHED_ULE. > >2. Disk subsystem. What kind of disk controller are you using? > >Not all drivers work well in FreeBSD. Are linux and freebsd > >using identical hardware? > They were. The drives are SATA. That still doesn't tell us if the drives are identical in throughput. Unless the drives are the same model/manufacturer, you should go to the manufacturers web-site for both drives, and look for the technical specs. THen you need to look for the speed of data transfer from the platter to the internal memory. I've seen [ in the past ] drives with lower revolutions per minute out-perform faster rotating drives because the slower drive had a better head design and could transfer data much faster. If this task is not up to you perhaps you could post the make/model number of the drives on both systems. Without knowing the sub-system capability you could be misleading yourself with other tests. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 17:09:00 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DED0216A421 for ; Tue, 25 Dec 2007 17:09:00 +0000 (UTC) (envelope-from alburthoffman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9556813C4E7 for ; Tue, 25 Dec 2007 17:09:00 +0000 (UTC) (envelope-from alburthoffman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so3898762pyb.3 for ; Tue, 25 Dec 2007 09:09:00 -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; bh=966h+TtsENbTUnXGg2I54tMW8qXFe8Ct5i/9MSp9OoA=; b=ggySk181WTIuje1NN5Ta1MswFK04xaWgnTci7raOCH2uvHKFUxmq79GTd9G8koTPi/T8An8we9al+fDIaDN2FE11hZZuLKgR9spYPO7tqita4C+kpOhlsz8awWDyH407Dpr7n6Z9ES1+KBlb76EldiX6eM5LtAaufSPP5Tlxcu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=oCiljVfp+YE4fK4MShCODK3xbqqWS+maOdSt4zHb43eDlR79rj6KXYR4jQVt53yDwKpBRA0tSMYZbQOYlskUaVQJ4GC75T2ylJA7EWx1/cevS8hXxx8pUb9l+6hDFULwQA7sAmJ+4H4jk4JzzgI8U5wFmVAnwiDFG8jmRrofHeo= Received: by 10.65.121.9 with SMTP id y9mr10664646qbm.26.1198600848562; Tue, 25 Dec 2007 08:40:48 -0800 (PST) Received: by 10.65.249.17 with HTTP; Tue, 25 Dec 2007 08:40:48 -0800 (PST) Message-ID: Date: Wed, 26 Dec 2007 00:40:48 +0800 From: "Alburt Hoffman" To: freebsd-stable@freebsd.org MIME-Version: 1.0 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: can't load snd_driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 17:09:01 -0000 Hi guys: I want to install my sound card and it just returned: "kldload:can't load snd_driver:Exec format error" my sound card is Realtek High Definition Audio.Is there any suggestion? with best regards. Alburt Hoffman From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 17:43:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F17216A494 for ; Tue, 25 Dec 2007 17:43:44 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.4.200]) by mx1.freebsd.org (Postfix) with ESMTP id AF6CC13C4DD for ; Tue, 25 Dec 2007 17:43:43 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JTM0050B7US18W0@mta5.srv.hcvlny.cv.net> for freebsd-stable@freebsd.org; Tue, 25 Dec 2007 12:13:42 -0500 (EST) Received: from flosoft.no-ip.biz (localhost [IPv6:::1]) by flosoft.no-ip.biz (8.14.2/8.14.2) with ESMTP id lBPHDeGh051339; Tue, 25 Dec 2007 12:13:40 -0500 Date: Tue, 25 Dec 2007 12:13:40 -0500 From: "Aryeh M. Friedman" In-reply-to: To: Alburt Hoffman Message-id: <47713A44.7070206@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.5 References: User-Agent: Thunderbird 2.0.0.9 (X11/20071217) Cc: freebsd-stable@freebsd.org Subject: Re: can't load snd_driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 17:43:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alburt Hoffman wrote: > Hi guys: > I want to install my sound card and it just returned: > "kldload:can't load snd_driver:Exec format error" > my sound card is Realtek High Definition Audio.Is there any suggestion? > > with best regards. > Alburt Hoffman > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Did you try snd_hda_load="YES" - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHcTpDzIOMjAek4JIRAk+CAJ0XgbyklW73ljI7ulQsevX/jDSC8QCaA6Bu dW7PGXmOKxyDhznB2kQ7lk8= =xzZn -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 21:01:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EC1916A41B; Tue, 25 Dec 2007 21:01:05 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id 2C42B13C4D5; Tue, 25 Dec 2007 21:01:04 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from evilcoder.xs4all.nl ([195.64.94.120] helo=elvandar.local) by galain.elvandar.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J7Foe-0007cs-B9; Tue, 25 Dec 2007 20:51:52 +0100 Message-ID: <47715F84.3050703@FreeBSD.org> Date: Tue, 25 Dec 2007 20:52:36 +0100 From: Remko Lodder User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mark Andrews References: <200712240014.lBO0EfRB014370@drugs.dv.isc.org> In-Reply-To: <200712240014.lBO0EfRB014370@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: PATCH: FreeBSD-7-BETA4 'bge' ether for Dell T105 server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 21:01:05 -0000 Mark Andrews wrote: >> Thanks to Max Laier's help, the ether device is now working with the 'bge' >> driver. Here is a patch that makes it work. I just recompiled the >> kernel afterwards and it comes up. >> >> PS: the T105 is now $399 but includes 1GB RAM and 2x160GB disk, >> in addition to the dual-core 1.8GHz Opteron and DVD reader. >> >> (Is there a better way to do this? sorry for the CC's, wasn't sure which >> was appropriate for getting this into the tree.) > > "send-pr" is the appropriate command for submitting these sorts > of fixes. > Indeed, nevertheless I just committed the information you send (Chris) and hopefully I can get this in soon, thanks for reporting this though! Cheers remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 05:38:13 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3E2D16A41B; Wed, 26 Dec 2007 05:38:13 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9750413C47E; Wed, 26 Dec 2007 05:38:13 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.1/8.14.1) with ESMTP id lBQ5cCdb001790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Dec 2007 00:38:12 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.14.1/8.14.1/Submit) id lBQ5cBUf001789; Wed, 26 Dec 2007 00:38:11 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Mike Tancsa Date: Wed, 26 Dec 2007 00:38:11 -0500 User-Agent: KMail/1.9.7 References: <200712212341.44308@aldan> <200712221313.lBMDDx5M036478@lava.sentex.ca> In-Reply-To: <200712221313.lBMDDx5M036478@lava.sentex.ca> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/umass, devfs: this sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 05:38:14 -0000 On =D3=D5=C2=CF=D4=C1 22 =C7=D2=D5=C4=C5=CE=D8 2007, Mike Tancsa wrote: =3D Perhaps its the one card reader you are using is particularly=20 =3D problematic ? I have been using the multi-type cheapo reader below=20 =3D for some time Perhaps. But /nothing/ excuses devfs hanging for 25 minutes. Nothing. It=20 should be more resilient to such problems. It should be possible to interru= pt=20 a hung operation too. =3D We go through the following steps when using it. =9AWe always plug the= =20 =3D reader in without a card. Then we put the card in and do a =3D cat /dev/null > /dev/da1 =3D ... or whatever the device is. =9AIts been quite reliable this way for = us. =3D The other caveat is never to pull the card or reader when its mounted. Yes, I go through these steps too and am also aware of the caveat(s). And i= t=20 sucks (see Subject), that one has to keep all of this in mind in order to=20 perform a trivial operation: transfer a few pictures from a media card to=20 their home directory. If we want people to give FreeBSD a try in good faith, it is both profoundl= y=20 stupid and dishonest on our part to claim, we have a working USB-system... = It=20 does not matter, how great our buffer-sharing VM is, if a home user can't=20 process their photos with a FreeBSD-powered computer. -mi From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 07:36:20 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87CD316A420; Wed, 26 Dec 2007 07:36:20 +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 52B9E13C46E; Wed, 26 Dec 2007 07:36:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBQ7VNGm021122; Wed, 26 Dec 2007 00:31:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 26 Dec 2007 00:35:47 -0700 (MST) Message-Id: <20071226.003547.-932932005.imp@bsdimp.com> To: mi+kde@aldan.algebra.com From: "M. Warner Losh" In-Reply-To: <200712260038.11546@aldan> References: <200712212341.44308@aldan> <200712221313.lBMDDx5M036478@lava.sentex.ca> <200712260038.11546@aldan> 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: stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/umass, devfs: this sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 07:36:20 -0000 In message: <200712260038.11546@aldan> Mikhail Teterin writes: : If we want people to give FreeBSD a try in good faith, it is both profoundly : stupid and dishonest on our part to claim, we have a working USB-system... It : does not matter, how great our buffer-sharing VM is, if a home user can't : process their photos with a FreeBSD-powered computer. In an ideal world, it would be perfect. However, all the USB hardware I've recently purchased actually does work without a hitch on my FreeBSD system. Older card readers are more problematic. Rather than complain about the system, how about merging RELENG_7's usb stack to RELENG_6? Or fixing a few bugs from the PRs that are filed? I did my time in a big push for 7.0, maybe some other people can help out a little too? Warner From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 07:57:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB03316A421 for ; Wed, 26 Dec 2007 07:57:42 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5B36D13C47E for ; Wed, 26 Dec 2007 07:57:42 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from pavillion-dv6426us.advok.com (unknown [151.197.226.251]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 74932372B8 for ; Wed, 26 Dec 2007 16:39:13 +0900 (JST) Date: Wed, 26 Dec 2007 02:39:01 -0500 From: Yoshihiro Ota To: freebsd-stable@freebsd.org Message-Id: <20071226023901.0b928eb3.ota@j.email.ne.jp> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: 7-BETA4/7-RC1 crashes randomly at shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 07:57:42 -0000 Hello. I have been following RELENG_7 and then RELENG_7_0. I update /usr/src daily and install them. I think the crash started around 12/18. Since then, I started seen pancing at umount during shutdown. I am using GENERIC kernel with SCHED_ULE. This crash tends to happen after some amount of I/O performed. I cannot really tell what kind of I/O will trigger this umount failure, yet. I got a core and 'where' command. Does anyone have any ideas or suggestions? Thanks, Hiro # kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug /var/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: <118>/etc/rc.shutdown: WARNING: $samba_enable is not set properly - see rc.conf(5). <118>Writing entropy file: <118>. <118>. <118>Dec 26 01:11:56 XXXXXX syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Wait iSnygn c(imnagx dis60k s,s evcnoonddess) rfeomra isynsitneg.m. .p3r ocess `syncer' to stop...3 3 1 1 1 1 0 0 0 0 done All buffers synced. GEOM_ELI: Detached da0.eli on last close. acpi_ec0: warning: EC done before starting event wait GEOM_ELI: Detached ad4s2f.eli on last close. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07479d4 stack pointer = 0x28:0xe3c71b1c frame pointer = 0x28:0xe3c71b34 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1 (init) trap number = 12 panic: page fault cpuid = 0 Uptime: 1h24m11s Physical memory: 2025 MB Dumping 155 MB: 140 124 108 92 76 60 44 28 12 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc0753e87 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754149 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a689ec in trap_fatal (frame=0xe3c71adc, eva=392) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a68c70 in trap_pfault (frame=0xe3c71adc, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a6961c in trap (frame=0xe3c71adc) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a4f5ab in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc07479d4 in _mtx_lock_sleep (m=0xc8abfa18, tid=3306133088, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:335 #8 0xc07cc94f in vgone (vp=0xc8abf990) at /usr/src/sys/kern/vfs_subr.c:2471 #9 0xc5742a79 in ?? () #10 0xc8abf990 in ?? () #11 0xc55a9a70 in ?? () #12 0x00000000 in ?? () #13 0xc5743c20 in ?? () #14 0x0000016c in ?? () #15 0xc5746074 in ?? () #16 0x00003002 in ?? () #17 0xc8abf990 in ?? () #18 0xe3c71bf0 in ?? () #19 0x00000004 in ?? () ---Type to continue, or q to quit--- #20 0xc50f9660 in ?? () #21 0xe3c71ba8 in ?? () #22 0xc57420b4 in ?? () #23 0xc55a9a70 in ?? () #24 0xc5746000 in ?? () #25 0x00001002 in ?? () #26 0xe3c71bf0 in ?? () #27 0xc50f9660 in ?? () #28 0xc569d550 in ?? () #29 0xe3c71c00 in ?? () #30 0xc07c6ac1 in dounmount (mp=0xc55a9a70, flags=-982228992, td=0x10) at /usr/src/sys/kern/vfs_mount.c:1270 Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 10:00:13 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFEF616A418 for ; Wed, 26 Dec 2007 10:00:13 +0000 (UTC) (envelope-from akiril@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id B691313C4CC for ; Wed, 26 Dec 2007 10:00:13 +0000 (UTC) (envelope-from akiril@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2885405rvb.43 for ; Wed, 26 Dec 2007 02:00:13 -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=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=CaJeUjIsjqCRXpqoIk2sgNawbJJDaW2hnq4PHD8XAtIrz6WDQN1VEYGrjzrN+wwz1lilTJLfnO5A7LUmXRikyO+lgZlxcBBYyI+5rU/5SuEPADfgDIPVwyi/7NNSjPn3scO4P8jPqQcDr4WJGCJqATYDp4rRXgBGml76hNRJA30= 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=IwBEpifKq6OK+mr3xfi0rpOhNjjIg3uVpve6VsOyxYoa5UQo0C21duT1Th0+I2KCwr5hZXle2Xc2QIzSbJs2Ucpom1JFBEkWqurjVoV6g4zBR7oTvS/3Q6FNtr+W1fpv7Gp6ENmliMxeMeHxWpFke3Y+nvcv8qcyM8d13nNkXgk= Received: by 10.140.193.16 with SMTP id q16mr3174071rvf.109.1198661458296; Wed, 26 Dec 2007 01:30:58 -0800 (PST) Received: by 10.141.33.5 with HTTP; Wed, 26 Dec 2007 01:30:58 -0800 (PST) Message-ID: <92d9fda70712260130y36172e71o788476a016fb9b18@mail.gmail.com> Date: Wed, 26 Dec 2007 12:30:58 +0300 From: "Anton Kirillov" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: (no subject) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 10:00:13 -0000 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 12:54:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C1C16A421 for ; Wed, 26 Dec 2007 12:54:40 +0000 (UTC) (envelope-from maf@splintered.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 30D6B13C457 for ; Wed, 26 Dec 2007 12:54:39 +0000 (UTC) (envelope-from maf@splintered.net) Received: (qmail 92089 invoked from network); 26 Dec 2007 12:54:38 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 26 Dec 2007 12:54:38 -0000 In-Reply-To: <20071225052749.GE57756@deviant.kiev.zoral.com.ua> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <20071222201613.GX57756@deviant.kiev.zoral.com.ua> <20071223095314.G1323@delplex.bde.org> <20071224131906.GB57756@deviant.kiev.zoral.com.ua> <833223E8-B1ED-4358-A992-F3789E4B3070@splintered.net> <20071225052749.GE57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Wed, 26 Dec 2007 07:54:18 -0500 To: Kostik Belousov X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 12:54:40 -0000 On Dec 25, 2007, at 12:27 AM, Kostik Belousov wrote: > > What fs do you use ? If FFS, are softupdates turned on ? Please, > show the > total time spent in the softdepflush process. > > Also, try to add the FULL_PREEMPTION kernel config option and report > whether it helps. FFS with soft updates on all filesystems. With your latest uio_yield() in MNT_VNODE_FOREACH patch it's a little harder to provoke packet loss. Standard nightly crontabs and a tar -cf - / > /dev/null no longer cause drops. A make buildkernel will though. root 38 0.0 0.0 0 8 ?? DL Mon08PM 0:04.62 [softdepflush] Building a new kernel with KTR and FULL_PREEMPTION now. -- mark From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 13:09:54 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 865B116A41A for ; Wed, 26 Dec 2007 13:09:54 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4778913C461 for ; Wed, 26 Dec 2007 13:09:54 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBQD9nac054969; Wed, 26 Dec 2007 06:09:50 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4772529D.9010805@samsco.org> Date: Wed, 26 Dec 2007 08:09:49 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> In-Reply-To: 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 (pooker.samsco.org [168.103.85.57]); Wed, 26 Dec 2007 06:09:51 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Brett Glass , stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 13:09:54 -0000 Adrian Chadd wrote: > On 25/12/2007, Brett Glass wrote: >>> It sounds like you're pretty convinced you know what the problem is. >> Again, I'd have to instrument either the FreeBSD kernel or Squid to >> be 100% sure. But it APPEARS that it's a problem with large >> numbers of threads trying to do file I/O simultaneously and blocking. > > I'd still check the namei cache; Squid can and does chew through > stupid amounts of pathnames. Its why I hacked up that "ifs" thing a > few years ago but was suddenly (contractually) required to not hack on > caching for a while.. > Yes, Squid is the ideal application for IFS. Do you still have any of your work on this, and would you be able to share it? Scott From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 13:11:06 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E84416A469 for ; Wed, 26 Dec 2007 13:11:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7B99313C461 for ; Wed, 26 Dec 2007 13:11:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBQDB0sB054988; Wed, 26 Dec 2007 06:11:01 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <477252E4.4070707@samsco.org> Date: Wed, 26 Dec 2007 08:11:00 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241723.lBOHNLtt049769@lava.sentex.ca> In-Reply-To: <200712241723.lBOHNLtt049769@lava.sentex.ca> 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 (pooker.samsco.org [168.103.85.57]); Wed, 26 Dec 2007 06:11:01 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 13:11:06 -0000 Mike Tancsa wrote: > At 12:12 PM 12/24/2007, Scott Long wrote: >> For others who might want help with this, tweaking >> vfs.ufs.dirhash_maxmem is what is needed. A bit of a balancing act is >> needed if you're on i386 since you'll risk exhausting KVA unless you >> also tweak KVA_PAGES. > > > Hi Scott, > How does one know if the vfs.ufs.dirhash_maxmem is set too high > and are exhausting KVA ? Panics, freezes, failure to exec new programs, failure to create pipes, etc. Scott From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 13:25:06 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32E9D16A41B for ; Wed, 26 Dec 2007 13:25:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 136F413C45B for ; Wed, 26 Dec 2007 13:25:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2950642rvb.43 for ; Wed, 26 Dec 2007 05:25:05 -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=w9HppW3/5c4+483EgXbAFZchByx3vTDpaqqcKkw1iDU=; b=f74dZi2xoU5Hhd8pIJ4pR3sw7CMw3Bix2By0USdgaY9Mq2sdOOFQvtQ/WHLIuSCQCEBYx7JVXRny5fD9TfEapTfhSeNR4l+qZnqKsvU2cwPSS+TxLjY4HIVxl4ZrIQtRHETJOaYRSQSg8vwckN+C+LNnNdnju40DLcP7orL8Nms= 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=QetJFKcEE5UmNw5lukVVdmyesob5SqUUeTD/NbEI89kx05Jtj03LZPB6u4QwfDlB2QWMfM9iJM17ivUbXwwk69PKNYrU5dLa2NvX+GTzeWVMmjuBUYBWgiIDRVCMm1cNjUoEjgin9IPAx5a1QVRfAS+Fma1ZP/f6NHovxGrNZUM= Received: by 10.142.126.17 with SMTP id y17mr1776817wfc.170.1198675505621; Wed, 26 Dec 2007 05:25:05 -0800 (PST) Received: by 10.143.155.13 with HTTP; Wed, 26 Dec 2007 05:25:05 -0800 (PST) Message-ID: Date: Wed, 26 Dec 2007 22:25:05 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Scott Long" In-Reply-To: <4772529D.9010805@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> <4772529D.9010805@samsco.org> X-Google-Sender-Auth: adc687ad75783a7b Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 13:25:06 -0000 On 26/12/2007, Scott Long wrote: > Yes, Squid is the ideal application for IFS. Do you still have any of > your work on this, and would you be able to share it? It'd be easy to rewrite it from scratch if IFS were recovered. In fact, the whole point behind IFS, way back when, is I could layer a user-space directory hierarchy on top of a kernel provided space and then do "stuff" (I had a POP3 Maildir-like server written using IFS back then.) The squid code wasn't difficult at all. The biggest problem back then was rebuilding the disk index - didn't I have some code to export the inode allocation bitmap via a special file in the filesystem so I didn't have to stat() each individual inode, or didn't I end up comitting that? I'm happy to work on that later on next year. I've got enough non-disk Squid code to rewrite and optimise over the next few months; the storage side is going to have to wait a while. Adrian -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 14:33:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 458DF16A418; Wed, 26 Dec 2007 14:33:17 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1140113C4E8; Wed, 26 Dec 2007 14:33:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47726624.6020805@FreeBSD.org> Date: Wed, 26 Dec 2007 15:33:08 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mark Fullmer References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <20071222201613.GX57756@deviant.kiev.zoral.com.ua> <20071223095314.G1323@delplex.bde.org> <20071224131906.GB57756@deviant.kiev.zoral.com.ua> <833223E8-B1ED-4358-A992-F3789E4B3070@splintered.net> <20071225052749.GE57756@deviant.kiev.zoral.com.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 14:33:17 -0000 Mark Fullmer wrote: > > On Dec 25, 2007, at 12:27 AM, Kostik Belousov wrote: > >> >> What fs do you use ? If FFS, are softupdates turned on ? Please, show the >> total time spent in the softdepflush process. >> >> Also, try to add the FULL_PREEMPTION kernel config option and report >> whether it helps. > > FFS with soft updates on all filesystems. > > With your latest uio_yield() in MNT_VNODE_FOREACH patch it's a > little harder to provoke packet loss. Standard nightly > crontabs and a tar -cf - / > /dev/null no longer cause drops. A > make buildkernel will though. > > root 38 0.0 0.0 0 8 ?? DL Mon08PM 0:04.62 > [softdepflush] > > Building a new kernel with KTR and FULL_PREEMPTION now. FYI FULL_PREEMPTION causes performance loss in other situations. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 15:12:59 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3B3C16A417 for ; Wed, 26 Dec 2007 15:12:58 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 736CD13C43E for ; Wed, 26 Dec 2007 15:12:58 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id IAA27697; Wed, 26 Dec 2007 08:12:49 -0700 (MST) Message-Id: <200712261512.IAA27697@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Dec 2007 08:12:42 -0700 To: Scott Long , Adrian Chadd From: Brett Glass In-Reply-To: <4772529D.9010805@samsco.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> <4772529D.9010805@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 15:12:59 -0000 Scott, Adrian: Even more interesting would be a storage schema for caches that rests on top of FreeBSD's GEOM facility. One could bypass all filesystems but still take advantage of the driver architecture. --Brett Glass At 06:09 AM 12/26/2007, Scott Long wrote: >Yes, Squid is the ideal application for IFS. Do you still have any of your work on this, and would you be able to share it? > >Scott From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 15:32:31 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82A2716A421 for ; Wed, 26 Dec 2007 15:32:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4405C13C500 for ; Wed, 26 Dec 2007 15:32:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so381191nzf.13 for ; Wed, 26 Dec 2007 07:32: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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=lnJGbl7Ggo3vqw4ON5W6/w5UjEpcihX0C19BuC9BvCQ=; b=biggXnIshnb7Et9XX29/DRuNljub0EiqxScFUw8SWZJf9aPD9aO6lAthoHkbGzuB64Ev19GMzSThJKwjrDZtWju1nrwt0sel4Rx+5tXg5dgKyT/s8B/baWwGWKzdddsbRGXm/2GVK7mFj7EvCOexAfi8qJhRKR04KFMFOD24vaA= 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=ZBIeyLuGKKfKLBMfh9aqcIvNI2HFj2VFtvgwUlvPxifsBRIa0pD8+cNeYFOUEm29tQKb70Hh/Cs+yWgGxGSH+RMG6tDHtIY5RJmcc8YlKjhWXxwl5TAxys+Zj1rKd3AtsRpFEWwZBo1QTJasiRVAyTrnHxMGpk+ag9lUfvINvzo= Received: by 10.142.231.7 with SMTP id d7mr1888552wfh.30.1198683150042; Wed, 26 Dec 2007 07:32:30 -0800 (PST) Received: by 10.143.155.13 with HTTP; Wed, 26 Dec 2007 07:32:29 -0800 (PST) Message-ID: Date: Thu, 27 Dec 2007 00:32:29 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Brett Glass" In-Reply-To: <200712261512.IAA27697@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> <4772529D.9010805@samsco.org> <200712261512.IAA27697@lariat.net> X-Google-Sender-Auth: 0826b50361ca3f75 Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 15:32:31 -0000 On 27/12/2007, Brett Glass wrote: > Scott, Adrian: > > Even more interesting would be a storage schema for caches that rests > on top of FreeBSD's GEOM facility. One could bypass all filesystems > but still take advantage of the driver architecture. The biggest bonuses to gain high throughput with web caches, at least with small objects, is to apply temporal locality to them and do IO in $LARGE chunks. You then want to pull tricks with your memory cache so you throw away RAM in cluster-sized chunks - the objects grouped by temporal locality above - because really, if you throw away a 4k page, your costs of performing disk IO to read that 4k versus reading say, 32k or 64k, are pretty freaking similar (the same if you happen to be on the same track, slightly more if you're straddling tracks.) So you also want to pull those tricks. If you have two small objects (<64k) which are 50% likely to be fetched together, then by grouping them into one IO operation you're effectively slicing the seeks needed in half with very little impact. Well, there's an impact - you suddenly start pulling lots more data off disk. Could -that- be done without too much trouble? I've looked at madvise() to pull these tricks with mmap()'ed backing files but, again, I've not hit the point where I'm looking to optimise Squid's disk storage. There's just too much catching up to do to varnish's memory-only workload performance. Damn you phk. :) -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 16:31:25 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475BF16A41B; Wed, 26 Dec 2007 16:31:25 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id C7E1113C4E3; Wed, 26 Dec 2007 16:31:24 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id JAA28890; Wed, 26 Dec 2007 09:31:22 -0700 (MST) Message-Id: <200712261631.JAA28890@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Dec 2007 09:31:17 -0700 To: "Adrian Chadd" From: Brett Glass In-Reply-To: References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> <4772529D.9010805@samsco.org> <200712261512.IAA27697@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 16:31:25 -0000 At 08:32 AM 12/26/2007, Adrian Chadd wrote: >The biggest bonuses to gain high throughput with web caches, at least >with small objects, is to apply temporal locality to them and do IO in >$LARGE chunks. By "temporal locality" I assume you mean that you expect items that are fetched at the same time to both be fetched the next time also. Sort of a "working set" concept for Web pages. Correct? >You then want to pull tricks with your memory cache so you throw away >RAM in cluster-sized chunks - the objects grouped by temporal locality >above - because really, if you throw away a 4k page, your costs of >performing disk IO to read that 4k versus reading say, 32k or 64k, are >pretty freaking similar (the same if you happen to be on the same >track, slightly more if you're straddling tracks.) So you also want to >pull those tricks. If you have two small objects (<64k) which are 50% >likely to be fetched together, then by grouping them into one IO >operation you're effectively slicing the seeks needed in half with >very little impact. Well, there's an impact - you suddenly start >pulling lots more data off disk. And you need more buffer space. The key, I think, is to avoid needing that buffer space on multiple levels. The file system may prefetch large chunks and then the Web cache might do so also, doubling the overhead. >Could -that- be done without too much trouble? I've looked at >madvise() to pull these tricks with mmap()'ed backing files but, >again, I've not hit the point where I'm looking to optimise Squid's >disk storage. There's just too much catching up to do to varnish's >memory-only workload performance. Damn you phk. :) I don't know much about Varnish, but I'd been told that it is not a replacement for Squid. In any event, I certainly WOULD like to see a cache that had a true first-level cache in memory and a second-level cache on disk. The way Squid works now, it never keeps copies of objects in RAM once they've been evicted -- a major flaw, IMHO. This may account for the performance disadvantage relative to Varnish. After all, some objects are accessed by many people at certain times of day, and it pays to "promote" them to RAM during those periods. --Brett From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 16:58:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC26F16A4A9 for ; Wed, 26 Dec 2007 16:58:51 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from smtpi2.ngi.it (smtpi2.ngi.it [88.149.128.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3154A13C461 for ; Wed, 26 Dec 2007 16:58:50 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (88-149-173-206.static.ngi.it [88.149.173.206]) by smtpi2.ngi.it (8.13.8/8.13.8) with ESMTP id lBQFwmCq028871 for ; Wed, 26 Dec 2007 16:58:49 +0100 Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id AC40B130C32; Wed, 26 Dec 2007 16:58:48 +0100 (CET) Received: from anakin.madpilot.net (anakin.madpilot.net [172.24.42.10]) by megatron.madpilot.net (Postfix) with ESMTP id 8E54D130C28; Wed, 26 Dec 2007 16:58:48 +0100 (CET) Message-ID: <47727A38.7050406@madpilot.net> Date: Wed, 26 Dec 2007 16:58:48 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: USB umass kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 16:58:51 -0000 Hello, In the last few days I've been experiencing a reproducible kernel panic whenever plugging in my new digital camera (Pentax Optio Z10). Tried with a freshly cvsupped system too. I'm using 7.0. Here is a manual transcript of the panic message, I have some core dumps too, if needed. They're a little big as usual. umass0: uhub3 (da0:umass-sim0:0:0:0): unsupported block size 0 (da0:umass-sim0:0:0:0): lost device panic: kmem_malloc(-1407700992): kmem_map too small: 14807040 total allocated uptime: etc. (I thought the rest is not really needed) I;m available to give any information required to get into the problem. Perhaps the camera is doing something strange(block size 0????) but the panic is surely out of place... Thank you in advance for any help. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 17:35:05 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9EE916A41A; Wed, 26 Dec 2007 17:35:05 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: from av12-1-sn2.hy.skanova.net (av12-1-sn2.hy.skanova.net [81.228.8.185]) by mx1.freebsd.org (Postfix) with ESMTP id 1934A13C442; Wed, 26 Dec 2007 17:35:05 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 2808838D02; Wed, 26 Dec 2007 18:16:51 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 11BB438C90; Wed, 26 Dec 2007 18:16:51 +0100 (CET) Received: from [192.168.0.2] (81-235-156-87-no29.tbcn.telia.com [81.235.156.87]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 7DDFB37E44; Wed, 26 Dec 2007 18:16:48 +0100 (CET) From: Henrik Gulbrandsen To: "M. Warner Losh" , Mikhail Teterin In-Reply-To: <20071226.003547.-932932005.imp@bsdimp.com> References: <200712212341.44308@aldan> <200712221313.lBMDDx5M036478@lava.sentex.ca> <200712260038.11546@aldan> <20071226.003547.-932932005.imp@bsdimp.com> Content-Type: text/plain Date: Wed, 26 Dec 2007 18:15:16 +0100 Message-Id: <1198689316.1119.382.camel@Particle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/umass, devfs: this sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 17:35:05 -0000 On Wed, 2007-12-26 at 00:35 -0700, M. Warner Losh wrote: > In message: <200712260038.11546@aldan> > Mikhail Teterin writes: > : If we want people to give FreeBSD a try in good faith, it is both profoundly > : stupid and dishonest on our part to claim, we have a working USB-system... It > : does not matter, how great our buffer-sharing VM is, if a home user can't > : process their photos with a FreeBSD-powered computer. > > In an ideal world, it would be perfect. > > However, all the USB hardware I've recently purchased actually does > work without a hitch on my FreeBSD system. Older card readers are > more problematic. > > Rather than complain about the system, how about merging RELENG_7's > usb stack to RELENG_6? Or fixing a few bugs from the PRs that are > filed? I did my time in a big push for 7.0, maybe some other people > can help out a little too? Fixing and merging are good, but it seems to me (as an occasional patch contributor without commit privileges) that the bottleneck for USB is still in the handling of incoming patches. At the moment, there are 162 USB PRs to close. Out of these, 103 are marked with "[patch]", but only 42 of those are actually in "patched" state. Almost all of the latter were apparently handled as part of Warner's summer push. The USB stack has to deal with many third-party devices, most of which will not be immediately available for testing by FreeBSD developers. This means that we are more or less forced to rely on external patch contributors (such as myself) to provide workarounds for the problems caused by various hardware peculiarities. Usually, it shouldn't take more than a basic code review to accept these patches, so this would be a good place to start if you want to improve USB handling in FreeBSD. Look at it from my perspective: I would be happy to complete my fix for the infamous five-year-old usb/46176, so people can finally detach umass devices without having to manually unmount them first. However, it will undoubtedly take a non-trivial amount of time to reproduce and eliminate the remaining issues. I'm more likely to put in that effort if I believe that my patches may actually end up in CURRENT, but if a one-line fix such as that in usb/78984 has not been applied after more than a year, how long will it take for patches that involve multiple subsystems? /Henrik From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 17:40:58 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2752E16A418 for ; Wed, 26 Dec 2007 17:40:58 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E64F013C442 for ; Wed, 26 Dec 2007 17:40:57 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id lBQHeuGZ020815; Wed, 26 Dec 2007 12:40:56 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id lBQHetRB061995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Dec 2007 12:40:55 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200712261740.lBQHetRB061995@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Dec 2007 12:38:52 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <477252E4.4070707@samsco.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241723.lBOHNLtt049769@lava.sentex.ca> <477252E4.4070707@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 17:40:58 -0000 At 08:11 AM 12/26/2007, Scott Long wrote: >> How does one know if the vfs.ufs.dirhash_maxmem is set too >> high and are exhausting KVA ? > >Panics, freezes, failure to exec new programs, failure to create pipes, etc. Is there anyway to know ahead of time one is getting close to the stage where all those "bad things" start to happen ? ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 18:37:34 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD89A16A419; Wed, 26 Dec 2007 18:37:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id A9E9D13C467; Wed, 26 Dec 2007 18:37:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id A5CEC8C0E7; Wed, 26 Dec 2007 12:04:15 -0600 (CST) Date: Wed, 26 Dec 2007 12:04:15 -0600 To: Henrik Gulbrandsen Message-ID: <20071226180415.GA27409@soaustin.net> References: <200712212341.44308@aldan> <200712221313.lBMDDx5M036478@lava.sentex.ca> <200712260038.11546@aldan> <20071226.003547.-932932005.imp@bsdimp.com> <1198689316.1119.382.camel@Particle> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1198689316.1119.382.camel@Particle> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: freebsd-usb@freebsd.org, stable@freebsd.org, Mikhail Teterin , freebsd-bugbusters@FreeBSD.org Subject: PR backlog [was: Re: usb/umass, devfs: this sucks] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 18:37:35 -0000 On Wed, Dec 26, 2007 at 06:15:16PM +0100, Henrik Gulbrandsen wrote: > Fixing and merging are good, but it seems to me (as an occasional patch > contributor without commit privileges) that the bottleneck for USB is > still in the handling of incoming patches [...] if a one-line fix > such as that in usb/78984 has not been applied after more than a year, > how long will it take for patches that involve multiple subsystems? I'll put on my bugmeister hat for a moment. First, I share your frustration. Second, unfortunately, it's not just USB. We suffer from this problem in several other areas, notably, patches for the userland utilities ("bin"). There are two interrelated problems that create a chicken-and-egg situation: - the PR tool is insufficient for our needs; - there's not a "culture" of going and fixing bugs outside of the code one usually works on. As for 1), once the releases are out, I intend to start working on defining what "our needs" are. As I've stated before in other places, until we understand those, and get community buy-in to define an actual "process" rather than just a particular PR system, it's unwise just to change the PR system. (IMHO, there's no reason to further automate a process that doesn't work correctly.) I hope to have something concrete to present at BSDCan in May. As for 2), I've scratched my head for what to do about that for a while, and not been able to make much progress. Here's what we've tried: - The creation of a weekly posting "bugs the bugmeister team thinks are ready for commit". This doesn't seem to have attracted the desired attention. Perhaps this is a problem of "push" not being the right solution here; perhaps it just hasn't been publicized enough. - The creation of a hack for classifying PRs, the "[tag]" convention. This is simply working around the weakness of the tool. However, it is sufficient to be able to generate weekly email sorting the PRs by tag, and another email showing only PRs with patches, also sorted by tag. If you are a committer, it's also possible to run queries via: ~gnats/tools/showwithtag to get a summary. - Trying to get more traffic on the freebsd-bugbusters@ mailing list. - Trying to create some interest in #freebsd-bugbusters on EFNet on IRC. This has not attracted enough committers to be viable yet. - Holding some "bugathons" (idea stolen from NetBSD) where we try to get committers to come onto the IRC channel at particular weekends to try to interactively work through PRs. This had some success, but we have not done one in a while. The odd thing is that for ports, the existing PR system -- plus, most importantly, the hacks we've added on top of it -- works reasonably well. - Each port has an explicit "maintainer" field (even though many of the entries are null). Most of the src codebase does not, therefore no one in particular "owns" it. - We've taken advantage of that to layer a PR auto-assigner on top, that also sets things to 'feedback'. - portsmon is also able to track PRs by the port they affect, and semi- weekly reminder emails are sent out. But the first of these items is really particular to ports. Also, more ports PRs than src PRs are upgrades/bugfixes, rather than true bug reports that need substantial investigation (in fact, the ratio is probably exactly reversed). This means we can clear a proportionally larger number of ports PRs. All of this has helped get the port PR count down over the last several years, to the point where it no longer seems as overwhelming as the backlog in the other areas. The size of the backlog creates a substantial disincentive to try to fix a handful -- thus perpeturating the cycle. What we all need to understand is that the PR count will never be at zero; if we can instead settle for a steady-state, where the most concrete PRs can be worked on as they arrive, then I'll feel we've have made great progress. Unfortunately I don't have any brilliant insights as to how to make the work more interesting; most of my ideas have the focus of simply making it less frustrating. I'll throw the floor open for brainstorming at this point. mcl From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 18:43:01 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7224616A419; Wed, 26 Dec 2007 18:43:01 +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 3A38C13C46B; Wed, 26 Dec 2007 18:43:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBQIbsJE033930; Wed, 26 Dec 2007 11:37:54 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 26 Dec 2007 11:42:24 -0700 (MST) Message-Id: <20071226.114224.-432836428.imp@bsdimp.com> To: linimon@lonesome.com From: "M. Warner Losh" In-Reply-To: <20071226180415.GA27409@soaustin.net> References: <20071226.003547.-932932005.imp@bsdimp.com> <1198689316.1119.382.camel@Particle> <20071226180415.GA27409@soaustin.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: stable@freebsd.org, henrik@gulbra.net, freebsd-usb@freebsd.org, mi+kde@aldan.algebra.com, freebsd-bugbusters@freebsd.org Subject: Re: PR backlog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 18:43:01 -0000 Mark and Henrik make a number of good points here. Rather than reply to the details, I'm going to make a couple of quick observations. As a project we're not leveraging the community sufficiently when it comes to contributions. The current system of patch review and submission is very hap-hazard. If you happen to get the attention of the right person at the right time, then it goes in. If not, patches can languish a long time in the PR system. The PR system is also the wrong tool for the job. While Mark touches on the cultural issues in play, they are exacerbated by the misapplication of a problem system to be a patch submission and tracking system. Maybe we need to adopt a practice from the Linux community. At least for arm kernel patches, there is a two step process: submit it to a mailing list for review and refinement, with the second step being submitting it into a queue. I'm not sure the details we need to be successful in the FreeBSD project. Many of the USB patches in the PR system I left alone because I didn't have the time and/or knowledge to evaluate them for inclusion, or I saw something obviously wrong in the patch. When I was trying to just get through the obviously trivial patches. Warner From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 18:48:44 2007 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26F3E16A419; Wed, 26 Dec 2007 18:48:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E61C213C474; Wed, 26 Dec 2007 18:48:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBQIhfWD034032; Wed, 26 Dec 2007 11:43:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 26 Dec 2007 11:48:12 -0700 (MST) Message-Id: <20071226.114812.1649771240.imp@bsdimp.com> To: henrik@gulbra.net From: "M. Warner Losh" In-Reply-To: <1198689316.1119.382.camel@Particle> References: <200712260038.11546@aldan> <20071226.003547.-932932005.imp@bsdimp.com> <1198689316.1119.382.camel@Particle> 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: stable@FreeBSD.org, freebsd-usb@FreeBSD.org, mi+kde@aldan.algebra.com Subject: Re: usb/umass, devfs: this sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 18:48:44 -0000 In message: <1198689316.1119.382.camel@Particle> Henrik Gulbrandsen writes: : Look at it from my perspective: I would be happy to complete my fix for : the infamous five-year-old usb/46176, so people can finally detach umass : devices without having to manually unmount them first. However, it will : undoubtedly take a non-trivial amount of time to reproduce and eliminate : the remaining issues. There's no patches in this bug. : I'm more likely to put in that effort if I believe : that my patches may actually end up in CURRENT, but if a one-line fix : such as that in usb/78984 has not been applied after more than a year, : how long will it take for patches that involve multiple subsystems? The patch in this bug is wrong. There are devices that are an odd number of sectors. This is one of the places where the obvious patch isn't necessarily right. Warner From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 20:13:53 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3275E16A421 for ; Wed, 26 Dec 2007 20:13:53 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id A9C3113C4E3 for ; Wed, 26 Dec 2007 20:13:52 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by koef.zs64.net (8.14.1/8.14.1) with ESMTP id lBQJeIcm030312; Wed, 26 Dec 2007 20:40:18 +0100 (CET) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.14.2/8.14.1/Submit) id lBQJeIRc030311; Wed, 26 Dec 2007 14:40:18 -0500 (EST) (envelope-from cracauer) Date: Wed, 26 Dec 2007 14:40:18 -0500 From: Martin Cracauer To: Brett Glass Message-ID: <20071226194018.GA30004@cons.org> References: <200712220531.WAA09277@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712220531.WAA09277@lariat.net> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 20:13:53 -0000 Brett Glass wrote on Fri, Dec 21, 2007 at 10:31:24PM -0700: > > As has been reported in some other messages on this list, Linux is > currently blowing FreeBSD away. It's taking as much as 20% less > time to get through the benchmark, depending on exactly how the > random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD > SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. How much CPU load is there on the server during this benchmark? As I have measured and reported since 1997, if you have CPU load and do throughput timing at the same time, then FreeBSD always defaults to satisfy the CPU eating processes and starves network (at least TCP) and Linux is the other way round, keeps the throughput up but CPU needing processes lose out. Kind of opposite of what you'd expect from the ninja macho networker OS (FreeBSD) and the desktop friendly OS (Linux). Anyway, the real question is whether you get anything in return, aka is there anything running on the server that uses CPU but is not directly bound to the network throughput and hence gets work done quicker. > It appears, though I'd need to instrument the code more to be sure, > that the slowdown is coming from file I/O. I could measure the above effects with things coming out of nowhere, aka data made up by a process. If you are observing the same phaenomenon then it has nothing to do with file I/O. > Could it be that there > less concurrency or more overhead in FreeBSD file operations than > there is in Linux? Even with SoftUpdates turned on, the cache > volume mounted with -noatime, and aufs (which uses kqueues -- a > FreeBSD invention -- to optimize multithreaded disk access), the > benchmark shows FreeBSD losing out. Why? All that async and softupdates stuff only matters if you use a lot of small files, which you shouldn't do in the first place if you are building a cache of some sorts. In all likelyness the cache that you are building is satisfying requests out of the RAM, even if the cache is file-backed. You need to verify that before you can blame file I/O. So the real questions right now are: - how much CPU load (post top output) - how much disk activity (post iostat or vmstat output) - can't hurt to have a netstat throughput output, too Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 20:29:55 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5452816A419 for ; Wed, 26 Dec 2007 20:29:55 +0000 (UTC) (envelope-from gemini@geminix.org) Received: from geminix.org (geminix.org [213.73.82.81]) by mx1.freebsd.org (Postfix) with ESMTP id 1AFFD13C4E1 for ; Wed, 26 Dec 2007 20:29:50 +0000 (UTC) (envelope-from gemini@geminix.org) Message-ID: <4772B5EC.30807@geminix.org> Date: Wed, 26 Dec 2007 21:13:32 +0100 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.11) Gecko/20071201 SeaMonkey/1.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241723.lBOHNLtt049769@lava.sentex.ca> <477252E4.4070707@samsco.org> <200712261740.lBQHetRB061995@lava.sentex.ca> In-Reply-To: <200712261740.lBQHetRB061995@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cdA-000PEi-NI; Wed, 26 Dec 2007 21:29:49 +0100 Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 20:29:55 -0000 Mike Tancsa wrote: > At 08:11 AM 12/26/2007, Scott Long wrote: >>> How does one know if the vfs.ufs.dirhash_maxmem is set too >>> high and are exhausting KVA ? >> >> Panics, freezes, failure to exec new programs, failure to create >> pipes, etc. > > Is there anyway to know ahead of time one is getting close to the stage > where all those "bad things" start to happen ? At least on FreeBSD 4.11 you can do sysctl -a|grep kvm and get something like this: vm.kvm_size: 1065353216 vm.kvm_free: 348127232 Perhaps this works on later versions of FreeBSD, too. Now, if vm.kvm_free drops to 10% or so of vm.kvm_size and continues to fall, and vfs.ufs.dirhash_mem still hasn't hit the vfs.ufs.dirhash_maxmem limit, it's time to get concerned. Of course, you can also use the vm.kvm_* values to dimension vfs.ufs.dirhash_maxmem properly in the first place. Regards, Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 20:40:11 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9124E16A420 for ; Wed, 26 Dec 2007 20:40:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 23CB413C4E1 for ; Wed, 26 Dec 2007 20:40:10 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1578647mue.6 for ; Wed, 26 Dec 2007 12:40:09 -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=gSYBcFyDWIbI/UjbBLkHPxAPNAoEkG9JJOIi3sKxMc4=; b=QDsJKGbE8E7u7GvO67NiPG3tFzMEA51hzUJeFkuMN4GxiE3CFnQf9zk4p6sjx1BVlz1Ut9FeNtm/lXJyEUwQBco6utYQDGBIbjvLeaei7StTtflwWFHgcD24Fy7UdeGWvRz9QDoaI4YVRWqRWh0j6vfGEaDFV3deIjOIvWcMEoE= 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=t0GKzQo/WJJQ6bhiXVUildluoOgqGkWwYI+6X3pFRTgZ63vsfJ2wZ5k15oc5XjInrLrCnGODHnFK9rwcp4zQuSOacLauLUbfYm0L6Cq1slZd0Cl23kKqIcrgfPZViYBVSrg2DubxbQJ+6FX0kt29eGSRsC33bzVNxiQrXGVF8I8= Received: by 10.78.136.9 with SMTP id j9mr8698255hud.46.1198701609089; Wed, 26 Dec 2007 12:40:09 -0800 (PST) Received: by 10.78.46.11 with HTTP; Wed, 26 Dec 2007 12:40:08 -0800 (PST) Message-ID: Date: Wed, 26 Dec 2007 23:40:08 +0300 From: pluknet To: "Krassimir Slavchev" In-Reply-To: <476F7581.8080100@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <476F7581.8080100@bulinfo.net> Cc: FreeBSD Subject: Re: ifconfig options? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 20:40:11 -0000 Hi, On 24/12/2007, Krassimir Slavchev wrote: > 'ifconfig -l [address_family]' does not work correct on RELENG_7 > > > FreeBSD 6.3-BETA2: > # ifconfig -l > em0 em1 plip0 lo0 pflog0 > > #ifconfig -l ether > em0 em1 > > But: > FreeBSD 7.0-BETA4: > # ifconfig -l > em0 em1 plip0 lo0 pflog0 > > #ifconfig -l ether > em0 em1 plip0 lo0 pflog0 > > I need this functionality to get all ethernet interfaces. Is there other > way to do this? > To revert this functionality try this patch please. --- /usr/src/sbin/ifconfig/ifconfig.c 2007-12-26 23:25:17.000000000 +0300 +++ /tmp/ifconfig.c 2007-12-26 23:18:53.000000000 +0300 @@ -298,9 +298,12 @@ * Are we just listing the interfaces? */ if (namesonly) { - if (ifindex > 1) - printf(" "); - fputs(name, stdout); + if (afp == NULL || afp->af_af != AF_LINK || + sdl->sdl_type == IFT_ETHER) { + if (ifindex > 1) + printf(" "); + fputs(name, stdout); + } continue; } From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 20:49:13 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D1216A419 for ; Wed, 26 Dec 2007 20:49:13 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 31F5213C474 for ; Wed, 26 Dec 2007 20:49:13 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0JTO00HWBCHZR640@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 26 Dec 2007 21:49:11 +0100 (CET) Received: from kg-work.kg4.no ([80.202.173.59]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0JTO00GJ1CHZSQG2@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 26 Dec 2007 21:49:11 +0100 (CET) Date: Wed, 26 Dec 2007 21:49:11 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20071226214911.10e63794.torfinn.ingolfsen@broadpark.no> In-reply-to: <4772B5EC.30807@geminix.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241723.lBOHNLtt049769@lava.sentex.ca> <477252E4.4070707@samsco.org> <200712261740.lBQHetRB061995@lava.sentex.ca> <4772B5EC.30807@geminix.org> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.3; i386-portbld-freebsd6.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 20:49:13 -0000 On Wed, 26 Dec 2007 21:13:32 +0100 Uwe Doering wrote: > Perhaps this works on later versions of FreeBSD, too. Confirmed, it does. tingo@kg-work$ uname -a FreeBSD kg-work.kg4.no 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #5: Sun Nov 4 16:19:56 CET 2007 root@kg-work.kg4.no:/usr/obj/usr/src/sys/SS51G i386 tingo@kg-work$ sysctl -a| grep kvm vm.kvm_size: 1073737728 vm.kvm_free: 247459840 root@kg-vm# ^Dtingo@kg-vm$ uname -a FreeBSD kg-vm.kg4.no 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Sun Dec 2 16:34:41 UTC 2007 root@myers.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 tingo@kg-vm$ sysctl -a | grep kvm vm.kvm_free: 1327493120 vm.kvm_size: 2147479552 HTH -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 21:10:15 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6EBA16A418 for ; Wed, 26 Dec 2007 21:10:15 +0000 (UTC) (envelope-from r.neese@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 736E013C459 for ; Wed, 26 Dec 2007 21:10:15 +0000 (UTC) (envelope-from r.neese@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so471104nzf.13 for ; Wed, 26 Dec 2007 13:10:14 -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:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=jTdumm6m1wJKAk5cvw2DWv8SCyxF9QsuKiHd7yVO0M8=; b=LkSvrY4L9aiZ2sqjprM3sAGas/80/+atZX/2qj4aY2AZIBja9SwQGfUxdSI2F0ThD9K/5doTEJWQGZQtrZJPe5qju98J5OS/fooUC88ZFSuBVo6Gd3Dr3A5a3cAoPNFYedXZeNvyqChLIZ/rBpOKhaZ36X/1lrQPFS4GrFJoTtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=GAm9cmF6s4MXcEwz88jO+hjI3HqukwTSVL+yItpKHvV+l9uZN98TDvSUOmS9EpiGunegyWNWRDCZ83Q4EkMY7Mw2wMTovdWr6d6Rvvw0gZmtA/dZoYOvA/sRakCHSxZIypjv5fEdzU2G8nwJmbJdCMHlr+4MG81pwYEW9x7+rkQ= Received: by 10.142.102.5 with SMTP id z5mr2139582wfb.15.1198701772699; Wed, 26 Dec 2007 12:42:52 -0800 (PST) Received: from laptop.deamonswitch.org ( [69.234.208.201]) by mx.google.com with ESMTPS id h18sm28007727wxd.18.2007.12.26.12.42.50 (version=SSLv3 cipher=OTHER); Wed, 26 Dec 2007 12:42:52 -0800 (PST) From: Richard Neese To: freebsd-usb@freebsd.org Date: Wed, 26 Dec 2007 12:43:06 -0800 User-Agent: KMail/1.9.7 References: <20071226.003547.-932932005.imp@bsdimp.com> <20071226180415.GA27409@soaustin.net> <20071226.114224.-432836428.imp@bsdimp.com> In-Reply-To: <20071226.114224.-432836428.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712261243.08351.r.neese@gmail.com> Cc: linimon@lonesome.com, stable@freebsd.org, mi+kde@aldan.algebra.com, freebsd-bugbusters@freebsd.org Subject: Re: PR backlog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: r.neese@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 21:10:15 -0000 I agree with this and there is also the 2nd issue of commiters not responding to those working on updating ports. Point and Fax I have emaile Sobomax about fixing and updating the asterisk ports. and have sent patches but never got a reply in 9 months. If your going to be a maintainer you need to respond to those working on projects already in ports. On December 26, 2007 10:42:24 am M. Warner Losh wrote: > Mark and Henrik make a number of good points here. Rather than reply > to the details, I'm going to make a couple of quick observations. > > As a project we're not leveraging the community sufficiently when it > comes to contributions. The current system of patch review and > submission is very hap-hazard. If you happen to get the attention of > the right person at the right time, then it goes in. If not, patches > can languish a long time in the PR system. > > The PR system is also the wrong tool for the job. While Mark touches > on the cultural issues in play, they are exacerbated by the > misapplication of a problem system to be a patch submission and > tracking system. Maybe we need to adopt a practice from the Linux > community. At least for arm kernel patches, there is a two step > process: submit it to a mailing list for review and refinement, with > the second step being submitting it into a queue. I'm not sure the > details we need to be successful in the FreeBSD project. > > Many of the USB patches in the PR system I left alone because I didn't > have the time and/or knowledge to evaluate them for inclusion, or I > saw something obviously wrong in the patch. When I was trying to just > get through the obviously trivial patches. > > Warner > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" -- Welcome to the World. An the World gets smaller. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 23:58:17 2007 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8530716A417; Wed, 26 Dec 2007 23:58:17 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: from av9-2-sn2.hy.skanova.net (av9-2-sn2.hy.skanova.net [81.228.8.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9BE13C447; Wed, 26 Dec 2007 23:58:17 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 808EF37ED4; Thu, 27 Dec 2007 00:58:15 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 6ADC737E64; Thu, 27 Dec 2007 00:58:15 +0100 (CET) Received: from [192.168.0.2] (81-235-156-87-no29.tbcn.telia.com [81.235.156.87]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id CDF1337E44; Thu, 27 Dec 2007 00:58:14 +0100 (CET) From: Henrik Gulbrandsen To: "M. Warner Losh" In-Reply-To: <20071226.114812.1649771240.imp@bsdimp.com> References: <200712260038.11546@aldan> <20071226.003547.-932932005.imp@bsdimp.com> <1198689316.1119.382.camel@Particle> <20071226.114812.1649771240.imp@bsdimp.com> Content-Type: text/plain Date: Thu, 27 Dec 2007 00:56:43 +0100 Message-Id: <1198713403.1119.414.camel@Particle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, freebsd-usb@FreeBSD.org, mi+kde@aldan.algebra.com Subject: Re: usb/umass, devfs: this sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 23:58:17 -0000 On Wed, 2007-12-26 at 11:48 -0700, M. Warner Losh wrote: > In message: <1198689316.1119.382.camel@Particle> > Henrik Gulbrandsen writes: > : Look at it from my perspective: I would be happy to complete my fix for > : the infamous five-year-old usb/46176, so people can finally detach umass > : devices without having to manually unmount them first. However, it will > : undoubtedly take a non-trivial amount of time to reproduce and eliminate > : the remaining issues. > > There's no patches in this bug. Correct. I was hoping to have a complete fix before making any official announcements, especially since the approach may be a bit controversial. Fixing underlying issues one by one is not necessarily as clean as doing a complete redesign, but it's pretty efficient and good for merging too. The patches to CURRENT were described in this post to the USB list: http://lists.freebsd.org/pipermail/freebsd-usb/2007-November/004127.html > : I'm more likely to put in that effort if I believe > : that my patches may actually end up in CURRENT, but if a one-line fix > : such as that in usb/78984 has not been applied after more than a year, > : how long will it take for patches that involve multiple subsystems? > > The patch in this bug is wrong. There are devices that are an odd > number of sectors. This is one of the places where the obvious patch > isn't necessarily right. You're right. I realized that myself right after I sent the first email. The patch was already two years old when I submitted it, and I guess I must have focused a little too much on solid-state devices with "large" megabytes, where the sector count is very likely to be a power of two. The patch can be written as a quirk fix for this specific umass device, but (as I've mentioned elsewhere) I'd prefer something that handles the entire category of problems at once. Perhaps an extra line containing "if (is_power_of_two(maxsector))" could be a working compromise, but this can be discussed in a smaller setting than the current one. /Henrik From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 00:45:44 2007 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB8E716A41A; Thu, 27 Dec 2007 00:45:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 808B213C468; Thu, 27 Dec 2007 00:45:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBR0em5f039673; Wed, 26 Dec 2007 17:40:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 26 Dec 2007 17:45:23 -0700 (MST) Message-Id: <20071226.174523.1326317191.imp@bsdimp.com> To: henrik@gulbra.net From: "M. Warner Losh" In-Reply-To: <1198713403.1119.414.camel@Particle> References: <1198689316.1119.382.camel@Particle> <20071226.114812.1649771240.imp@bsdimp.com> <1198713403.1119.414.camel@Particle> 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: stable@FreeBSD.org, freebsd-usb@FreeBSD.org, mi+kde@aldan.algebra.com Subject: Re: usb/umass, devfs: this sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 00:45:44 -0000 In message: <1198713403.1119.414.camel@Particle> Henrik Gulbrandsen writes: : On Wed, 2007-12-26 at 11:48 -0700, M. Warner Losh wrote: : > In message: <1198689316.1119.382.camel@Particle> : > Henrik Gulbrandsen writes: : > : Look at it from my perspective: I would be happy to complete my fix for : > : the infamous five-year-old usb/46176, so people can finally detach umass : > : devices without having to manually unmount them first. However, it will : > : undoubtedly take a non-trivial amount of time to reproduce and eliminate : > : the remaining issues. : > : > There's no patches in this bug. : : Correct. I was hoping to have a complete fix before making any official : announcements, especially since the approach may be a bit controversial. : Fixing underlying issues one by one is not necessarily as clean as doing : a complete redesign, but it's pretty efficient and good for merging too. : : The patches to CURRENT were described in this post to the USB list: : http://lists.freebsd.org/pipermail/freebsd-usb/2007-November/004127.html These patches look good on their surface, but I want to analyse them in more detail. I had recalled seeing something like this, but I couldn't turn it up in my searching of PR database recently. I'd forgotten it was in the usb list... There's problems even when you just pop the flash card out of the adapter.. I'll see if these fix those or not... : > : I'm more likely to put in that effort if I believe : > : that my patches may actually end up in CURRENT, but if a one-line fix : > : such as that in usb/78984 has not been applied after more than a year, : > : how long will it take for patches that involve multiple subsystems? : > : > The patch in this bug is wrong. There are devices that are an odd : > number of sectors. This is one of the places where the obvious patch : > isn't necessarily right. : : You're right. I realized that myself right after I sent the first email. : The patch was already two years old when I submitted it, and I guess I : must have focused a little too much on solid-state devices with "large" : megabytes, where the sector count is very likely to be a power of two. : : The patch can be written as a quirk fix for this specific umass device, : but (as I've mentioned elsewhere) I'd prefer something that handles the : entire category of problems at once. Perhaps an extra line containing : "if (is_power_of_two(maxsector))" could be a working compromise, but : this can be discussed in a smaller setting than the current one. There's already a quirk for this problem that has been applied to the few devices that it affects. Maybe we need to add one more to the list? There was also talk of forcing a read to the last sector if the sector count was odd, but it never got past talk. Interestingly enough, I found the fact that FreeBSD's dd worked while Linux's didn't at a NIST analysis of forensic tools presented at a conference years ago. Warner From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 00:58:59 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B57B16A41B; Thu, 27 Dec 2007 00:58:59 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id E28F313C448; Thu, 27 Dec 2007 00:58:58 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 5DA858C126; Wed, 26 Dec 2007 18:58:58 -0600 (CST) Date: Wed, 26 Dec 2007 18:58:58 -0600 To: Richard Neese Message-ID: <20071227005858.GA7902@soaustin.net> References: <20071226.003547.-932932005.imp@bsdimp.com> <20071226180415.GA27409@soaustin.net> <20071226.114224.-432836428.imp@bsdimp.com> <200712261243.08351.r.neese@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712261243.08351.r.neese@gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: stable@freebsd.org, mi+kde@aldan.algebra.com, freebsd-bugbusters@freebsd.org, freebsd-usb@freebsd.org, linimon@lonesome.com Subject: Re: PR backlog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 00:58:59 -0000 On Wed, Dec 26, 2007 at 12:43:06PM -0800, Richard Neese wrote: > Point and Fax I have emaile Sobomax about fixing and updating the asterisk > ports. and have sent patches but never got a reply in 9 months. For situations like this you need to email portmgr@. We already have defined parameters for resetting inactive maintainers. mcl From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 03:48:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 697C416A41A; Thu, 27 Dec 2007 03:48:20 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by mx1.freebsd.org (Postfix) with ESMTP id 3533C13C448; Thu, 27 Dec 2007 03:48:20 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from localhost (localhost [127.0.0.1]) by ly.sdf.com (Postfix) with ESMTP id 7C07637C002; Wed, 26 Dec 2007 19:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.044 X-Spam-Level: X-Spam-Status: No, score=-4.044 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.355, BAYES_00=-2.599] Received: from ly.sdf.com ([127.0.0.1]) by localhost (ly.sdf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDe2h5iPzhyE; Wed, 26 Dec 2007 19:21:49 -0800 (PST) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by ly.sdf.com (Postfix) with ESMTP id 01E7E37C001; Wed, 26 Dec 2007 19:21:48 -0800 (PST) Date: Wed, 26 Dec 2007 19:21:48 -0800 (PST) From: Tom Samplonius To: Per olof Ljungmark Message-ID: <27828292.4501198725708936.JavaMail.root@ly.sdf.com> In-Reply-To: <476554AF.4000701@intersonic.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.113.193.90] Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@freebsd.org Subject: Re: -net or kernel: where does this belong? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 03:48:20 -0000 ----- "Per olof Ljungmark" wrote: > Posted on -questions but got no response, trying -current and -stable > as > well. Sorry for the cross-post but I'm getting kind of desperate... ... > Since quite a while I have had problems with {CURRENT|RELENG_7} SMP > machines that lock up when accessed from a remote location over a vpn > (ipsec) link and sees a ICMP_REDIRECT. ... Unfortunately, the "How To Repeat" description is rather ... thin. How do you have IPSec configured? Are you accessing the server remotely via ssh within the VPN tunnel, or any remote access? Tom From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 09:01:04 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EDEB16A420; Thu, 27 Dec 2007 09:01:04 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id 0666A13C457; Thu, 27 Dec 2007 09:01:03 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from localhost.we-dare.net ([127.0.0.1] helo=galain.elvandar.org) by galain.elvandar.org with esmtpa (Exim 4.67) (envelope-from ) id 1J7oKa-000O13-06; Thu, 27 Dec 2007 09:43:08 +0100 Received: from 194.74.82.3 (SquirrelMail authenticated user remko) by galain.elvandar.org with HTTP; Thu, 27 Dec 2007 09:43:08 +0100 (CET) Message-ID: <18754.194.74.82.3.1198744988.squirrel@galain.elvandar.org> In-Reply-To: <20071226.114224.-432836428.imp@bsdimp.com> References: <20071226.003547.-932932005.imp@bsdimp.com> <1198689316.1119.382.camel@Particle> <20071226180415.GA27409@soaustin.net> <20071226.114224.-432836428.imp@bsdimp.com> Date: Thu, 27 Dec 2007 09:43:08 +0100 (CET) From: "Remko Lodder" To: "M. Warner Losh" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org, freebsd-usb@freebsd.org, freebsd-bugbusters@freebsd.org, mi+kde@aldan.algebra.com, linimon@lonesome.com, henrik@gulbra.net Subject: Re: PR backlog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@elvandar.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 09:01:04 -0000 Hello Warner et all, On Wed, December 26, 2007 7:42 pm, M. Warner Losh wrote: > Mark and Henrik make a number of good points here. Rather than reply > to the details, I'm going to make a couple of quick observations. > > As a project we're not leveraging the community sufficiently when it > comes to contributions. The current system of patch review and > submission is very hap-hazard. If you happen to get the attention of > the right person at the right time, then it goes in. If not, patches > can languish a long time in the PR system. Indeed, I am one of the persons trying to find these relatively easy things which I can do along side my other projects and things, but I dont see them all (eventhough I try to keep track of them as much as possible); but what will happen is that I learn more and more about the system and at some point in time I will "stop" working on these easy PR's and seeking more difficult ones to fix, at that point someone else has to step up to fill in the gap that gets created; this might be a problematic part :-) Though for everyone having simple fixes, please send them to me so that I can evaluate them and (together with Warner in this case (As my mentor)) I will try to get them in as correctly and quickly as possible :-) (keeping up with the high standards of FreeBSD ofcourse). > > The PR system is also the wrong tool for the job. While Mark touches > on the cultural issues in play, they are exacerbated by the > misapplication of a problem system to be a patch submission and > tracking system. Maybe we need to adopt a practice from the Linux > community. At least for arm kernel patches, there is a two step > process: submit it to a mailing list for review and refinement, with > the second step being submitting it into a queue. I'm not sure the > details we need to be successful in the FreeBSD project. > > Many of the USB patches in the PR system I left alone because I didn't > have the time and/or knowledge to evaluate them for inclusion, or I > saw something obviously wrong in the patch. When I was trying to just > get through the obviously trivial patches. > > Warner Some things that I think need to be done by the bugbuster/bugmeister team and additional people is a constant effort to keep track of the incoming tickets; Mark does a great job at that, and I try to helpout as much as possible there, but we are all busy every now and then and then a backlog on processing the incoming tickets gets created and we loose the "battle" :-) This is where you (the reader) can get in and try to help us with that, so that we can properly assign the tickets, and try to keep track of them so that they can get resolved as soon as possible. Though, some complains are that we are not fast enough etc, I think we need to make sure that everyone keeps understanding that we are a Voluntary project, and that we have resources at unknown times and dates, a committer can be active the one day, and remain inactive the rest of the week; that's a side effect on the project being based on volunteers; we did a good job so far with that, but every now and then something slips in between. What we should do at that point is not ranting around as I see happen sometimes, but instead try to get the bugbusters / bugmeister team involved so that we can see what other options are available, sometimes we can succeed in and sometimes we cannot; but dont keep the problem to yourself and the "assigned" person because that might not work :-) Just my E 0,02 :-) -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 09:59:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 270B716A417 for ; Thu, 27 Dec 2007 09:59:20 +0000 (UTC) (envelope-from eraser95@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id AC95913C458 for ; Thu, 27 Dec 2007 09:59:19 +0000 (UTC) (envelope-from eraser95@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2051847fgg.35 for ; Thu, 27 Dec 2007 01:59: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:to:subject:mime-version:content-type; bh=ylhcB1w+gotDHqI/Tr6vDaQum4bg1L06O5+yPWBJHY4=; b=EKcDYqCkj2mc5uj3wlyHfYGJH3vQ2AvNVaIK+JJsFK/GkimsrN5y/CoP55VC4UHt/65w/Ipn+BewFLpVz85jv5OIDG1hSZAXfKTZ1ELhCH45UFqTvKPZDzKpR/osj3jZBtktkv960wlJmsL6UtyE7be1gKjaUKafIiy+z2Mh6YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=GRjjspy87+usXEFmxszZwjDk0iBB3Xe69nIjiaI302BjBN1exOmebkxm+ort44aEn1t1TFKLetFaNMnxuINMJiVHUj7MpWrJoggcrvZkoqHBWCGT3ezeLf/ZhgN4RhwjGp4lzamJY/xf/ey8tGX+S2jYynrJTnq/Wdiw+SbtYRk= Received: by 10.86.51.2 with SMTP id y2mr7634504fgy.6.1198748056211; Thu, 27 Dec 2007 01:34:16 -0800 (PST) Received: by 10.86.59.18 with HTTP; Thu, 27 Dec 2007 01:34:16 -0800 (PST) Message-ID: Date: Thu, 27 Dec 2007 01:34:16 -0800 From: "Minseok Choi" To: freebsd-stable@freebsd.org MIME-Version: 1.0 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: via DRI module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 09:59:20 -0000 Hi there, Do you know how to use via.ko in Freebsd? In my investigation, Via.ko is not ported to freebsd. right? If so, can you give some information how to port kernel module? Thanks, Minseok Choi From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 10:51:31 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D8AD16A418 for ; Thu, 27 Dec 2007 10:51:31 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id B3A2013C4E1 for ; Thu, 27 Dec 2007 10:51:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1J7qKn-000Fdn-3y; Thu, 27 Dec 2007 12:51:29 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: pyunyh@gmail.com In-reply-to: <20071210095715.GG60272@cdnetworks.co.kr> References: <20071210011714.GC60272@cdnetworks.co.kr> <20071210095715.GG60272@cdnetworks.co.kr> Comments: In-reply-to Pyun YongHyeon message dated "Mon, 10 Dec 2007 18:57:15 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Dec 2007 12:51:29 +0200 From: Danny Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: 7.0-BETA4 and msk problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 10:51:31 -0000 > On Mon, Dec 10, 2007 at 11:03:47AM +0200, Danny Braniss wrote: > > > On Sun, Dec 09, 2007 at 02:41:28PM +0200, Danny Braniss wrote: > > > > with this onboard NIC (LOB?) > > > > > > > > mskc0: > > > > e1000phy0: PHY 0 on miibus0 > > > > > > > > mskc0@pci0:1:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab > > > > rev=0x12 hdr=0x00 > > > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > > > device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' > > > > class = network > > > > subclass = ethernet > > > > > > > > I'm getting allot of: > > > > msk0: watchdog timeout > > > > and > > > > mskc0: Tx descriptor error > > > > and > > > > msk0: link state changed to DOWN > > > > and > > > > msk0: link state changed to UP > > > > > > > > any help is most welcome, > > > > danny > > > > > > > > > > > > > > It seems that the issue happens only on 88E8056/88E1149 PHY. > > > See PR 116853 and 114631. > > > Sorry, I have no cluet yet. > > > > to add some more noise, this is the first host that panicked too :-) > > anything I can do to help? > > Probably ship the hardware to me? :) love to, but the hardware is not mine :-) here is some more info, this is a different board, but with the same Marvell 88E8056, and it panics after printing 'no PHY found!' and the ethernet is -1 (ff.ff...) danny From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 15:00:55 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C406B16A474; Thu, 27 Dec 2007 15:00:55 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC2E13C4FA; Thu, 27 Dec 2007 15:00:55 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.1/8.14.1) with ESMTP id lBRF0p4t078039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Dec 2007 10:00:52 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.14.1/8.14.1/Submit) id lBRF0pAo078038; Thu, 27 Dec 2007 10:00:51 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: "M. Warner Losh" Date: Thu, 27 Dec 2007 10:00:50 -0500 User-Agent: KMail/1.9.7 References: <20071226.003547.-932932005.imp@bsdimp.com> <20071226180415.GA27409@soaustin.net> <20071226.114224.-432836428.imp@bsdimp.com> In-Reply-To: <20071226.114224.-432836428.imp@bsdimp.com> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: stable@freebsd.org, henrik@gulbra.net, freebsd-bugbusters@freebsd.org, freebsd-usb@freebsd.org Subject: Re: PR backlog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 15:00:55 -0000 On =D3=C5=D2=C5=C4=C1 26 =C7=D2=D5=C4=C5=CE=D8 2007, M. Warner Losh wrote: =3D As a project we're not leveraging the community sufficiently when it =3D comes to contributions. =9AThe current system of patch review and =3D submission is very hap-hazard. =9AIf you happen to get the attention of =3D the right person at the right time, then it goes in. =9AIf not, patches =3D can languish a long time in the PR system. This is /generally/ true, and has been for years. However, the USB-part of= =20 =46reeBSD is in a /particularly/ bad shape, so something USB-specific may b= e in=20 order. There is talk about a "whole new" USB reimplementation, and somebody is=20 working in the Perforce nirvana-land on it. Maybe, that work needs a closer= =20 look by other experts so as to bring it to the FreeBSD masses faster... -mi From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 15:55:10 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C877416A419; Thu, 27 Dec 2007 15:55:10 +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 8C6C213C474; Thu, 27 Dec 2007 15:55:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBRFmLMU053735; Thu, 27 Dec 2007 08:48:21 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 27 Dec 2007 08:52:47 -0700 (MST) Message-Id: <20071227.085247.1723236220.imp@bsdimp.com> To: mi+kde@aldan.algebra.com From: "M. Warner Losh" In-Reply-To: <200712271000.50995@aldan> References: <20071226180415.GA27409@soaustin.net> <20071226.114224.-432836428.imp@bsdimp.com> <200712271000.50995@aldan> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: stable@freebsd.org, henrik@gulbra.net, freebsd-bugbusters@freebsd.org, freebsd-usb@freebsd.org Subject: Re: PR backlog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 15:55:10 -0000 SW4gbWVzc2FnZTogPDIwMDcxMjI3MTAwMC41MDk5NUBhbGRhbj4NCiAgICAgICAgICAgIE1pa2hh aWwgVGV0ZXJpbiA8bWkra2RlQGFsZGFuLmFsZ2VicmEuY29tPiB3cml0ZXM6DQo6IE9uINGB0LXR gNC10LTQsCAyNiDQs9GA0YPQtNC10L3RjCAyMDA3LCBNLiBXYXJuZXIgTG9zaCB3cm90ZToNCjog PSBBcyBhIHByb2plY3Qgd2UncmUgbm90IGxldmVyYWdpbmcgdGhlIGNvbW11bml0eSBzdWZmaWNp ZW50bHkgd2hlbiBpdA0KOiA9IGNvbWVzIHRvIGNvbnRyaWJ1dGlvbnMuIO+/vVRoZSBjdXJyZW50 IHN5c3RlbSBvZiBwYXRjaCByZXZpZXcgYW5kDQo6ID0gc3VibWlzc2lvbiBpcyB2ZXJ5IGhhcC1o YXphcmQuIO+/vUlmIHlvdSBoYXBwZW4gdG8gZ2V0IHRoZSBhdHRlbnRpb24gb2YNCjogPSB0aGUg cmlnaHQgcGVyc29uIGF0IHRoZSByaWdodCB0aW1lLCB0aGVuIGl0IGdvZXMgaW4uIO+/vUlmIG5v dCwgcGF0Y2hlcw0KOiA9IGNhbiBsYW5ndWlzaCBhIGxvbmcgdGltZSBpbiB0aGUgUFIgc3lzdGVt Lg0KOiANCjogVGhpcyBpcyAvZ2VuZXJhbGx5LyB0cnVlLCBhbmQgaGFzIGJlZW4gZm9yIHllYXJz LiBIb3dldmVyLCB0aGUgVVNCLXBhcnQgb2YgDQo6IEZyZWVCU0QgaXMgaW4gYSAvcGFydGljdWxh cmx5LyBiYWQgc2hhcGUsIHNvIHNvbWV0aGluZyBVU0Itc3BlY2lmaWMgbWF5IGJlIGluIA0KOiBv cmRlci4NCg0KVXN1YWxseSB0aGF0J3MgY2FsbGVkIGEgbWFpbnRhaW5lciwgYnV0IHdlIGhhdmVu J3QgaGFkIGEgcmVhbCBvbmUgaW4gYQ0KbG9uZyB0aW1lLiAgT3IgZXZlbiBhIGZha2Ugb25lLiAg VGhhdCdzIHdoYXQgaXQgd291bGQgdGFrZSB0byBzb2x2ZQ0KdGhlIHByb2JsZW0uDQoNCjogVGhl cmUgaXMgdGFsayBhYm91dCBhICJ3aG9sZSBuZXciIFVTQiByZWltcGxlbWVudGF0aW9uLCBhbmQg c29tZWJvZHkgaXMgDQo6IHdvcmtpbmcgaW4gdGhlIFBlcmZvcmNlIG5pcnZhbmEtbGFuZCBvbiBp dC4gTWF5YmUsIHRoYXQgd29yayBuZWVkcyBhIGNsb3NlciANCjogbG9vayBieSBvdGhlciBleHBl cnRzIHNvIGFzIHRvIGJyaW5nIGl0IHRvIHRoZSBGcmVlQlNEIG1hc3NlcyBmYXN0ZXIuLi4NCg0K Tm93IHlvdSBhcmUgYmVpbmcgaW5zdWx0aW5nIGhlcmUuICBUaGVyZSBhcmUgcGVvcGxlIGxvb2tp bmcgYXQgSGFucycNCm5ldyBzdGFjaywgYW5kIGhhdmUgaWRlbnRpZmllZCBhIGZldyBpc3N1ZXMg d2l0aCBpdC4gIEhhbnMnIGlzIHdvcmtpbmcNCm9uIHRoZSBpc3N1ZXMgaWRlbnRpZmllZCwgYW5k IGV2ZW4gcHJvdmlkZXMgc25hcHNob3RzIGZyb20gdGltZSB0bw0KdGltZSBmb3IgcGVvcGxlIHRv IHRyeS4NCg0KV2FybmVyDQo= From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 16:11:10 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C684716A417 for ; Thu, 27 Dec 2007 16:11:10 +0000 (UTC) (envelope-from jimmyblim@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.241]) by mx1.freebsd.org (Postfix) with ESMTP id 8059113C46E for ; Thu, 27 Dec 2007 16:11:10 +0000 (UTC) (envelope-from jimmyblim@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so2457527hsj.11 for ; Thu, 27 Dec 2007 08:11:09 -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=2FISt2gK04Quo9IYB7nPJtbvById7KqJD+fodx+g6RE=; b=Q4CiqFSQNKFM0dnSfWlG8e2rSdgIEjR9dJk+0S7S7AIBy8ecy/ZrWXOKA+PzglLEVbmBGmczlyFHn5gYMl7LTf+WAKyCS19NWwvfH0AHFiFvpbfd+7PcuTqzg8dkfaXHvA4LVvF7nztsF6dJLa2nTFOxp3eef5ow8cDBvPj9ZYs= 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=OS/MW24wx6/PYOsGHoLnSUxOikOhGqUrKwSusQ1HIRSKgu2Di7AcxojpLF70znxYALotss2bNHDgvx4aU6LRrZ2wAefaodG1WO/jiykes4AohpapJVxb1UiL1plxHEmiT2vv3M/13e6UqPJh/uzjsPtoHfeUS2+0LmVsRtBaPZI= Received: by 10.150.226.15 with SMTP id y15mr2201676ybg.145.1198770338102; Thu, 27 Dec 2007 07:45:38 -0800 (PST) Received: by 10.150.202.16 with HTTP; Thu, 27 Dec 2007 07:45:38 -0800 (PST) Message-ID: <127fb190712270745o1f2575bbpc9c698d70d37d77b@mail.gmail.com> Date: Thu, 27 Dec 2007 23:45:38 +0800 From: "Jimmy Lim" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Atheros AR5007EG ath_hal STATUS 13 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 16:11:10 -0000 Hi, I have an Acer Aspire 4520 laptop, my atheros wifi is detected but I got ath_hal status 13. Any chance to make this wifi card working under FreeBSD-7.0/AMD64? Thanks in advance. -- Jimmy B. Lim j i m m y b l i m @ g m a i l . c o m From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 17:34:00 2007 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F343B16A41B; Thu, 27 Dec 2007 17:33:59 +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 B899713C465; Thu, 27 Dec 2007 17:33:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBRHSv9S054884; Thu, 27 Dec 2007 10:28:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 27 Dec 2007 10:33:27 -0700 (MST) Message-Id: <20071227.103327.-749251578.imp@bsdimp.com> To: mi+mill@aldan.algebra.com From: "M. Warner Losh" In-Reply-To: <200712271216.22436.mi+mill@aldan.algebra.com> References: <200712271000.50995@aldan> <20071227.085247.1723236220.imp@bsdimp.com> <200712271216.22436.mi+mill@aldan.algebra.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: stable@FreeBSD.org, henrik@gulbra.net, freebsd-usb@FreeBSD.org, mi+kde@aldan.algebra.com, freebsd-bugbusters@FreeBSD.org Subject: Re: USB issues (not just Re: PR backlog) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 17:34:00 -0000 In message: <200712271216.22436.mi+mill@aldan.algebra.com> Mikhail Teterin writes: : =DE=C5=D4=D7=C5=D2 27 =C7=D2=D5=C4=C5=CE=D8 2007 10:52 =C4=CF, M. War= ner Losh =F7=C9 =CE=C1=D0=C9=D3=C1=CC=C9: : > Usually that's called a maintainer, but we haven't had a real one i= n a : > long time. Or even a fake one. : = : Well, you responded to me earlier suggesting, I take it upon myself t= o merge = : USB-advancements from 7.x to 6.x. That implied, somebody did somethin= g for = : 7.x, did not it? Can that body (whoever they are) not put on the vaca= nt = : USB-maintainer hat and push the fixes/improvements into 6.x (preferab= ly -- = : before the 6.3 is released unto the world)? If not that same person, = then, = : maybe, the people, whom you mention below as "looking at Hans' new st= ack", = : can do the merging? I did the bulk of the work for the 7.0 stuff, at least getting things into the tree. Since I did the work, my last job got totally insane and then I switched jobs. I don't have the time needed to do this. : But if somebody is, indeed, working on a new USB stack, that's : terrific news. It also implies, we might get a USB-maintainer some : time soon. I just want it soon/er/, because it has been far too long : already... We can all agree that this is long overdue. But we need to make sure of a few critical details so we don't create another mess for ourselves down the line. Warner From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 17:43:08 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01B9C16A418 for ; Thu, 27 Dec 2007 17:43:08 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id C2C7C13C4CE for ; Thu, 27 Dec 2007 17:43:07 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 4524 invoked from network); 27 Dec 2007 17:16:27 -0000 Received: from aldan.algebra.com (HELO aldan-mlp) ([216.254.65.224]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Dec 2007 17:16:26 -0000 From: Mikhail Teterin To: "M. Warner Losh" Date: Thu, 27 Dec 2007 12:16:20 -0500 User-Agent: KMail/1.7.1 References: <20071226180415.GA27409@soaustin.net> <200712271000.50995@aldan> <20071227.085247.1723236220.imp@bsdimp.com> In-Reply-To: <20071227.085247.1723236220.imp@bsdimp.com> Organization: Virtual Estates, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712271216.22436.mi+mill@aldan.algebra.com> Cc: stable@freebsd.org, henrik@gulbra.net, freebsd-usb@freebsd.org, mi+kde@aldan.algebra.com, freebsd-bugbusters@freebsd.org Subject: USB issues (not just Re: PR backlog) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 17:43:08 -0000 =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80 27 =D0=B3=D1=80=D1=83=D0=B4=D0=B5=D0= =BD=D1=8C 2007 10:52 =D0=B4=D0=BE, M. Warner Losh =D0=92=D0=B8 =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0=D0=BB=D0=B8: > Usually that's called a maintainer, but we haven't had a real one in a > long time. Or even a fake one. Well, you responded to me earlier suggesting, I take it upon myself to merg= e=20 USB-advancements from 7.x to 6.x. That implied, somebody did something for= =20 7.x, did not it? Can that body (whoever they are) not put on the vacant=20 USB-maintainer hat and push the fixes/improvements into 6.x (preferably --= =20 before the 6.3 is released unto the world)? If not that same person, then,= =20 maybe, the people, whom you mention below as "looking at Hans' new stack",= =20 can do the merging? > : There is talk about a "whole new" USB reimplementation, and somebody is > : working in the Perforce nirvana-land on it. Maybe, that work needs a > : closer look by other experts so as to bring it to the FreeBSD masses > : faster... > Now you are being insulting here. =C2=A0There are people looking at Hans' > new stack, and have identified a few issues with it. =C2=A0Hans' is worki= ng > on the issues identified, and even provides snapshots from time to > time for people to try. I sure hope, you were joking about the "insulting" part. I don't see anythi= ng=20 in my words, that's in any way disparaging or insulting. What troubles me,= =20 however, is that this new work is being done in that ivory tower called=20 "perforce". Nothing against that particular revision-control system, but th= e =20 =46reeBSD work "in perforce" in the past tended to take /years/ to be merge= d=20 into the project's official repository -- CVS. Probably, because the actual= =20 development is far more thrilling, than the mundane merging from on=20 repository to another... But if somebody is, indeed, working on a new USB stack, that's terrific new= s.=20 It also implies, we might get a USB-maintainer some time soon. I just want = it=20 soon/er/, because it has been far too long already... I am with FreeBSD since early ninetees (and don't need refreshers on how we= =20 are a volunteer project). But I can't remember another case of a subsystem= =20 being so broken for so long -- through so many releases. -mi From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 17:54:47 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADE3616A419; Thu, 27 Dec 2007 17:54:47 +0000 (UTC) (envelope-from mteterin@mlp.com) Received: from outbound-mail.mlp.com (outbound-mail.mlp.com [204.212.175.37]) by mx1.freebsd.org (Postfix) with ESMTP id 4148B13C442; Thu, 27 Dec 2007 17:54:47 +0000 (UTC) (envelope-from mteterin@mlp.com) Received: from misha (Not Verified[10.5.105.98]) by outbound-mail.mlp.com with MailMarshal (v6, 1, 5, 586) id ; Thu, 27 Dec 2007 12:39:24 -0500 From: Mikhail Teterin To: "M. Warner Losh" Date: Thu, 27 Dec 2007 12:39:21 -0500 User-Agent: KMail/1.7.1 References: <200712271000.50995@aldan> <200712271216.22436.mi+mill@aldan.algebra.com> <20071227.103327.-749251578.imp@bsdimp.com> In-Reply-To: <20071227.103327.-749251578.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712271239.23558.mteterin@mlp.com> Cc: stable@freebsd.org, henrik@gulbra.net, freebsd-usb@freebsd.org, mi+kde@aldan.algebra.com, freebsd-bugbusters@freebsd.org Subject: Re: USB issues (not just Re: PR backlog) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 17:54:47 -0000 =DE=C5=D4=D7=C5=D2 27 =C7=D2=D5=C4=C5=CE=D8 2007 12:33 =D0=CF, M. Warner = Losh =F7=C9 =CE=C1=D0=C9=D3=C1=CC=C9: > I did the bulk of the work for the 7.0 stuff, at least getting things > into the tree. =9ASince I did the work, my last job got totally insane > and then I switched jobs. As the old Russian saying went: if vodka interferes with your job, you ha= ve to=20 stop working. > We can all agree that this is long overdue. But we need to make sure > of a few critical details so we don't create another mess for > ourselves down the line. Seriosly, thank you and do get back to it whenever you can. =20-mi ###################################################################### The information contained in this communication is confidential and may contain information that is privileged or exempt from disclosure under applicable law. If you are not a named addressee, please notify the sender immediately and delete this email from your system. If you have received this communication, and are not a named recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. ###################################################################### From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 19:41:52 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 825E416A41A for ; Thu, 27 Dec 2007 19:41:52 +0000 (UTC) (envelope-from dave@syix.com) Received: from mail01.syix.com (mail01.syix.com [209.77.112.20]) by mx1.freebsd.org (Postfix) with ESMTP id 73A3C13C447 for ; Thu, 27 Dec 2007 19:41:52 +0000 (UTC) (envelope-from dave@syix.com) X-Virus-Scanned: amavisd-new at syix.com Received: from asian (asian.syix.com [209.77.113.38]) (Authenticated sender: dave) by mail01.syix.com (Postfix) with ESMTP id 6B1D534F029 for ; Thu, 27 Dec 2007 11:22:18 -0800 (PST) From: "Dave Overton" To: Date: Thu, 27 Dec 2007 11:22:18 -0800 Organization: SYIX.COM Message-ID: <006f01c848bd$cbcda550$26714dd1@syix.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchIvcuUiUcrpeJoQreoNd2P46xwSw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: portaudit and portsnap acting silly. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dave@syix.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 19:41:52 -0000 Portaudit does this: # portaudit -Fa auditfile.tbz 100% of 46 kB 6001 kBps portaudit: Database too old. Old database restored. portaudit: Download failed. Portsnap does this: # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. Fetching snapshot tag from portsnap3.FreeBSD.org... done. Latest snapshot on server is older than what we already have! Cowardly refusing to downgrade from Thu Dec 27 08:10:58 PST 2007 to Mon Dec 3 17:04:28 PST 2007. In case anyone knows anyone who can beat them back into submission. Dave Overton, Owner SYIX.COM dave@syix.com (530) 755-1751 x101 Fax (530) 751-8871 800-988-SYIX From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 23:11:59 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 087D616A417 for ; Thu, 27 Dec 2007 23:11:59 +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 B0F7413C458 for ; Thu, 27 Dec 2007 23:11:58 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id BADE528448 for ; Fri, 28 Dec 2007 07:11:57 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 68926EC494A; Fri, 28 Dec 2007 07:11:57 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id C-xUHOAhkhBb; Fri, 28 Dec 2007 07:11:52 +0800 (CST) Received: from charlie.delphij.net (pool-71-113-249-14.herntx.dsl-w.verizon.net [71.113.249.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 83D0BEC4940; Fri, 28 Dec 2007 07:11:51 +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:content-type:content-transfer-encoding; b=Ti/3+c21+upNlZkuuentC1tBOD1r/wrjRnrF+SwOFFH9OiKny7+cORL3wFwgvLSHT mSM+GfMcodOyPkkl7ugiQ== Message-ID: <47743135.50103@delphij.net> Date: Thu, 27 Dec 2007 17:11:49 -0600 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Seth Hieronymus References: <70d306230712240855j3ecd0000w7a7f87cadc15652a@mail.gmail.com> In-Reply-To: <70d306230712240855j3ecd0000w7a7f87cadc15652a@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Instant Reboot with 7.0 BETA4 LifeFS Disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 23:11:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Seth Hieronymus wrote: > In testing my Windows desktop with the 7.0 LiveFS disk ( > 7.0-BETA4-amd64-livefs.iso), I get an instant reboot when the CD is run. As > far as I can tell, no console messages are printed, so it seems the error > happens very early in the loading process. Other FreeBSD versions (6.2, > i386 7.0) also exhibit the same behavior. If left alone, the computer will > just continually reboot. > > The specs of the system are: > Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard > AMD Athlon64 3800+ Newcastle 2.4GHz > Promise FastTrak 579 RAID Controller (PDC20579) > 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 > Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card > > My guess is that the disk controller is not supported. Should this cause an > instant reboot with a live filesystem disk? Is there anyway to debug this > since no console messages are printed? One guess: what if you disable and disconnect your hard disk? This will be helpful to narrow down the issue... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHdDE0hcUczkLqiksRAnqZAJ9d5DvreJwI/gciL+xtBcone7uhuACfbakl p/pv89ZWt25HGL9I/4a8avU= =RApP -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 23:49:37 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476C716A419 for ; Thu, 27 Dec 2007 23:49:37 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from smtpi1.ngi.it (smtpi1.ngi.it [88.149.128.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7AB13C46E for ; Thu, 27 Dec 2007 23:49:36 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (88-149-173-206.static.ngi.it [88.149.173.206]) by smtpi1.ngi.it (8.13.8/8.13.8) with ESMTP id lBRNnYbw022597 for ; Fri, 28 Dec 2007 00:49:35 +0100 Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 456EE130C5F; Fri, 28 Dec 2007 00:49:34 +0100 (CET) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 2175C130C5E; Fri, 28 Dec 2007 00:49:34 +0100 (CET) Date: Fri, 28 Dec 2007 00:49:34 +0100 From: Guido Falsi To: Dave Overton Message-ID: <20071227234934.GA86902@megatron.madpilot.net> References: <006f01c848bd$cbcda550$26714dd1@syix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006f01c848bd$cbcda550$26714dd1@syix.com> X-Operating-System: FreeBSD 7.0-PRERELEASE User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org Subject: Re: portaudit and portsnap acting silly. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 23:49:37 -0000 On Thu, Dec 27, 2007 at 11:22:18AM -0800, Dave Overton wrote: > Portaudit does this: > # portaudit -Fa > auditfile.tbz 100% of 46 kB 6001 kBps > portaudit: Database too old. > Old database restored. > portaudit: Download failed. > > > Portsnap does this: > # portsnap fetch > Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. > Fetching snapshot tag from portsnap3.FreeBSD.org... done. > Latest snapshot on server is older than what we already have! > Cowardly refusing to downgrade from Thu Dec 27 08:10:58 PST 2007 > to Mon Dec 3 17:04:28 PST 2007. > > > In case anyone knows anyone who can beat them back into submission. Are you using a proxy server. I encountered similar problems with a proxy. In fact I usually set up squid not to cache portsnap[0-9].freebsd.org. Never seen such a problem with portaudit though... Hope this helps. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 23:49:49 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64AD16A418 for ; Thu, 27 Dec 2007 23:49:49 +0000 (UTC) (envelope-from shieronymus@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 63EE013C45A for ; Thu, 27 Dec 2007 23:49:49 +0000 (UTC) (envelope-from shieronymus@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so4826298fka.11 for ; Thu, 27 Dec 2007 15:49: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:references; bh=SaCv6ZzA4FNU9FIYHdepKMww/EVS3NwjjMxZmW7xKh4=; b=qHX4IphOGERAYbqdmMVzpAOyxGhQCMDNtB+c1AuyKM1Zz9wg96yU8k9tk/NZNdjSjjw4mpFzv+UfR+JTgGznPmrrApOMbO8yqCI4damEIqoY1v34j2R3hFxIPzu2YiHIifFT0erYCP7z5J7ZJafutEnK+5anzX/RIG1unRkWe+U= 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:references; b=R5WSLZkaJJRWZJJn/5FG30IDgOhygMmIPh+M2DO1jnSxjdfCfd7ir8k4cr32IW2R3TL4VoqohKhKbWxd/z+PBV9FiYOw0K4u2D/nqlrjkhk7BlV9phTQlsnyY4M3z2TzVYN1j/XHKqhKOzjBJgp08T4fu/RmV85E6TjMcH/6jIc= Received: by 10.78.193.19 with SMTP id q19mr10648117huf.69.1198799387424; Thu, 27 Dec 2007 15:49:47 -0800 (PST) Received: by 10.78.140.2 with HTTP; Thu, 27 Dec 2007 15:49:47 -0800 (PST) Message-ID: <70d306230712271549j1fc5c31dm3a8d5acc04871c9e@mail.gmail.com> Date: Thu, 27 Dec 2007 16:49:47 -0700 From: "Seth Hieronymus" To: delphij@delphij.net In-Reply-To: <47743135.50103@delphij.net> MIME-Version: 1.0 References: <70d306230712240855j3ecd0000w7a7f87cadc15652a@mail.gmail.com> <47743135.50103@delphij.net> 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: stable@freebsd.org Subject: Re: Instant Reboot with 7.0 BETA4 LifeFS Disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 23:49:49 -0000 On Dec 27, 2007 4:11 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Seth Hieronymus wrote: > > In testing my Windows desktop with the 7.0 LiveFS disk ( > > 7.0-BETA4-amd64-livefs.iso), I get an instant reboot when the CD is run. > As > > far as I can tell, no console messages are printed, so it seems the > error > > happens very early in the loading process. Other FreeBSD versions (6.2, > > i386 7.0) also exhibit the same behavior. If left alone, the computer > will > > just continually reboot. > > > > The specs of the system are: > > Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard > > AMD Athlon64 3800+ Newcastle 2.4GHz > > Promise FastTrak 579 RAID Controller (PDC20579) > > 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 > > Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card > > > > My guess is that the disk controller is not supported. Should this > cause an > > instant reboot with a live filesystem disk? Is there anyway to debug > this > > since no console messages are printed? > > One guess: what if you disable and disconnect your hard disk? This will > be helpful to narrow down the issue... > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4 (FreeBSD) > > iD8DBQFHdDE0hcUczkLqiksRAnqZAJ9d5DvreJwI/gciL+xtBcone7uhuACfbakl > p/pv89ZWt25HGL9I/4a8avU= > =RApP > -----END PGP SIGNATURE----- > Thanks for the response! What you suggested worked -- I removed the SATA cables from both harddrives, and then was able to boot using the 7.0 BETA4 AMD64 LiveFS cd. It appears that the disk controller is not the problem. It is recognized by FreeBSD as (hand copied): atapci0: port 0xd200-0xd27f,0xd300-0xd3ff mem 0xf8236000-0xf8236fff,0xf8200000-0xf821ffff irq 19 at device 9.0 on pci0 Searching the dmesg, there are no other devices on irq 19. Not sure it matters, but one interesting thing is that the motherboard also has another SATA controller (irq 20 at device 15.0), which is: atapci1: Any ideas? Thanks, Seth From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 00:29:35 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E9AE16A419 for ; Fri, 28 Dec 2007 00:29:35 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2719913C447 for ; Fri, 28 Dec 2007 00:29:34 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id lBS0TM2w038078; Fri, 28 Dec 2007 01:29:27 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 184ECB827; Fri, 28 Dec 2007 01:29:22 +0100 (CET) Date: Fri, 28 Dec 2007 01:29:22 +0100 From: Roland Smith To: Seth Hieronymus Message-ID: <20071228002922.GA75879@slackbox.xs4all.nl> References: <70d306230712240855j3ecd0000w7a7f87cadc15652a@mail.gmail.com> <47743135.50103@delphij.net> <70d306230712271549j1fc5c31dm3a8d5acc04871c9e@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <70d306230712271549j1fc5c31dm3a8d5acc04871c9e@mail.gmail.com> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: stable@freebsd.org, delphij@delphij.net Subject: Re: Instant Reboot with 7.0 BETA4 LifeFS Disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 00:29:35 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 27, 2007 at 04:49:47PM -0700, Seth Hieronymus wrote: > > > The specs of the system are: > > > Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard > > > AMD Athlon64 3800+ Newcastle 2.4GHz > > > Promise FastTrak 579 RAID Controller (PDC20579) > > > 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 > > > Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card > > One guess: what if you disable and disconnect your hard disk? This will > > be helpful to narrow down the issue... > Thanks for the response! What you suggested worked -- I removed the SATA > cables from both harddrives, and then was able to boot using the 7.0 BETA4 > AMD64 LiveFS cd. > Not sure it matters, but one interesting thing is that the motherboard al= so > has another SATA controller (irq 20 at device 15.0), which is: > atapci1: I've got two disks attached in RAID1 to the VIA 6420 controller. Works fine here (7.0-BETA3 FreeBSD amd64). Try connecting your disks to the via controller. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHdENiEnfvsMMhpyURAmZ6AJ9OL6lC2SlAF87c+uyDteXhCxZZGgCfQYVN biRLNyv7vEVPDNImp38YzDI= =Vtq7 -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 01:34:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F22716A418 for ; Fri, 28 Dec 2007 01:34:21 +0000 (UTC) (envelope-from barnabasdk@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 913BE13C461 for ; Fri, 28 Dec 2007 01:34:19 +0000 (UTC) (envelope-from barnabasdk@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2236361fgg.35 for ; Thu, 27 Dec 2007 17:34: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:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Fgd4ZgfXcwhhiD4RlJ7DLDZu2xcsGu9HR0Uh0ewyAJE=; b=MCnYIGNQr8kH1b6blY1b9WvbgP1IUHLKXO5bp1E9A27edC+DVXmQZ6flFTmTeiRvhYMS58ur48h2S4wFhmiacLoIBvq1RQywnzxWzXik/QLDyclJM08KGnhcrvMJ5GVcWiUsrWsxxKnZiCunZcLgm4JGjAu0TujCjm6A7LQjq9g= 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=QQGbttep3bu2IdPKkmiWQL9ts5g8TfX6RKlMFOT8ckxPXbZdEeUdAy0/8LTcwIx68/OMq3vbcE5z7Cr4j8poZpVG96Z76r9dkUJsFJRNIusMRQj2X3nYFACjhbN/p69s8dyNVOee0V7Q1pFw9goU9H81WzMVO3vE2znoVdLHvcM= Received: by 10.86.90.2 with SMTP id n2mr8355314fgb.66.1198804001279; Thu, 27 Dec 2007 17:06:41 -0800 (PST) Received: by 10.86.72.6 with HTTP; Thu, 27 Dec 2007 17:06:41 -0800 (PST) Message-ID: <59d23e060712271706v7dbbdee5v9dcb3f8c5d652b3a@mail.gmail.com> Date: Fri, 28 Dec 2007 02:06:41 +0100 From: "Nikolaj Hansen" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Failure of gvinum after panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 01:34:21 -0000 Hi all, I have some problems with my gvinum setup after the system panic'ed. Afterwards the system fails finding the plexes to the subdisks (or at least that is what I can understand after having searched the gvinum source code for the error string in the DMESG log..) The machine is an IBM Netfinity 5000 and the internal HW self tests does not find any errors in the hw. Luckily my root is not on a gvinum drive, so I am able to boot the server in single user. Does anyone have any hints as to what I can do to get gvinum to recognize the disks correctly? The system is 6.3 stable Dont worry about the media disks or anything right now - I am trying to revive the system disks for now. Thanks Nikolaj Hansen 7 drives: D elben State: up /dev/da1s1h A: 0/7825 MB (0%) D donau State: up /dev/da0s1h A: 0/7825 MB (0%) D raid5_4_ad11 State: up /dev/ad11 A: 6/194480 MB (0%) D raid5_3_ad10 State: up /dev/ad10 A: 6/194480 MB (0%) D raid5_2_ad9 State: up /dev/ad9 A: 6/194480 MB (0%) D raid5_1_ad8 State: up /dev/ad8 A: 6/194480 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) 6 volumes: V data01 State: up Plexes: 1 Size: 111 GB V usr State: up Plexes: 0 Size: 0 B V home State: up Plexes: 0 Size: 0 B V tmp State: up Plexes: 0 Size: 0 B V var State: up Plexes: 0 Size: 0 B V media State: up Plexes: 1 Size: 379 GB 10 plexes: P data01.p0 C State: up Subdisks: 1 Size: 111 GB P usr.p1 C State: up Subdisks: 0 Size: 0 B P home.p1 C State: up Subdisks: 0 Size: 0 B P tmp.p1 C State: up Subdisks: 0 Size: 0 B P var.p1 C State: up Subdisks: 0 Size: 0 B P usr.p0 C State: up Subdisks: 0 Size: 0 B P home.p0 C State: up Subdisks: 0 Size: 0 B P tmp.p0 C State: up Subdisks: 0 Size: 0 B P var.p0 C State: up Subdisks: 0 Size: 0 B P media.p0 R5 State: degraded Subdisks: 3 Size: 379 GB 13 subdisks: S data01.p0.s0 State: up D: spree Size: 111 GB S usr.p1.s0 State: up D: elben Size: 5625 MB S home.p1.s0 State: up D: elben Size: 1000 MB S tmp.p1.s0 State: up D: elben Size: 600 MB S var.p1.s0 State: up D: elben Size: 600 MB S usr.p0.s0 State: up D: donau Size: 5625 MB S home.p0.s0 State: up D: donau Size: 1000 MB S tmp.p0.s0 State: up D: donau Size: 600 MB S var.p0.s0 State: up D: donau Size: 600 MB S media.p0.s0 State: up D: raid5_1_ad8 Size: 189 GB S media.p0.s1 State: up D: raid5_2_ad9 Size: 189 GB S media.p0.s2 State: stale D: raid5_3_ad10 Size: 189 GB S media.p0.s3 State: up D: raid5_4_ad11 Size: 189 GB Copyright (c) 1992-2007 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 6.2-RELEASE-p6 #0: Wed Jul 18 23:33:58 CEST 2007 root@sauron.barnabas.dk:/usr/src/sys/i386/compile/KERNEL_6_2 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (498.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387fbff real memory = 536854528 (511 MB) avail memory = 515715072 (491 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe88-0xfe8b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 skc0: <3Com 3C940 Gigabit Ethernet> port 0x2000-0x20ff mem 0xfebfc000-0xfebfffff irq 18 at device 1.0 on pci0 skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0a:5e:5c:c0:83 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ahc0: port 0x2200-0x22ff mem 0xfebfb000-0xfebfbfff irq 16 at device 6.0 on pci0 ahc0: [GIANT-LOCKED] aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x2300-0x23ff mem 0xfebfa000-0xfebfafff irq 16 at device 6.1 on pci0 ahc1: [GIANT-LOCKED] aic7895C: Ultra Wide Channel B, SCSI Id=15, 32/253 SCBs s3pci0: port 0x3c0-0x3df,0x4ae8 mem 0xf8000000-0xfbffffff irq 9 at device 10.0 on pci0 isab0: port 0xfe00-0xfe0f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 irq 18 at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xff700000-0xff700fff irq 18 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib1: on acpi0 pci1: on pcib1 atapci1: port 0x4af0-0x4af7,0x4aec-0x4aef,0x4af8-0x4aff,0x4b00-0x4b03,0x4b10-0x4b1f irq 19 at device 2.0 on pci1 ata2: on atapci1 ata3: on atapci1 atapci2: port 0x4b08-0x4b0f,0x4b04-0x4b07,0x4b20-0x4b27,0x4b28-0x4b2b,0x4b30-0x4b3f mem 0xc0fdc000-0xc0fdffff irq 19 at device 3.0 on pci1 ata4: on atapci2 ata5: on atapci2 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f2-0x3f7,0x3f7 irq 6 drq 2 on acpi0 fdc0: No FDOUT register! device_attach: fdc0 attach returned 6 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 1 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: MLC,PCL,PML plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f2-0x3f7,0x3f7 irq 6 drq 2 on acpi0 fdc0: No FDOUT register! device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xccfff,0xcd000-0xcd7ff,0xcd800-0xd17ff,0xd1800-0xd3fff on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> umass0: Kingston DataTraveler II, rev 2.00/1.00, addr 2 Timecounters tick every 1.000 msec ad4: 114473MB at ata2-master UDMA100 ad6: 114473MB at ata3-master UDMA100 ad8: 194481MB at ata4-master UDMA100 ad9: 194481MB at ata4-slave UDMA100 ad10: 194481MB at ata5-master UDMA100 ad11: 194481MB at ata5-slave UDMA100 Waiting 5 seconds for SCSI devices to settle gv_plex_taste: NULL p for 'media.p0.s3' ses0 at ahc1 bus 0 target 14 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device da0 at ahc1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C) da1 at ahc1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C) SMP: AP CPU #1 Launched! da2 at umass-sim0 bus 0 target 0 lun 0 da2: Removable Direct Access SCSI-0 device da2: 1.000MB/s transfers da2: 983MB (2014208 512 byte sectors: 64H 32S/T 983C) gv_plex_taste: NULL p for 'var.p0.s0' gv_plex_taste: NULL p for 'tmp.p0.s0' gv_plex_taste: NULL p for 'home.p0.s0' gv_plex_taste: NULL p for 'usr.p0.s0' gv_plex_taste: NULL p for 'var.p1.s0' gv_plex_taste: NULL p for 'tmp.p1.s0' gv_plex_taste: NULL p for 'home.p1.s0' gv_plex_taste: NULL p for 'usr.p1.s0' Trying to mount root from ufs:/dev/da0s1a WARNING: / was not properly dismounted WARNING: R/W mount of / denied. Filesystem is not clean - run fsck Subdisk usr.p0.s0: Size: 5898970624 bytes (5625 MB) State: up Drive donau (donau) at offset 2307002880 (2200 MB) /dev/da0s1b none swap sw 0 0 /dev/da1s1b none swap sw 0 0 /dev/da0s1a / ufs rw 1 5 /dev/gvinum/home /home ufs rw 2 5 /dev/da1s1a /rootback ufs rw 2 6 /dev/gvinum/tmp /tmp ufs rw 2 1 /dev/gvinum/usr /usr ufs rw 2 2 /dev/gvinum/var /var ufs rw 2 3 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/acd0 /cdrom1 cd9660 ro,noauto 0 0 #/dev/ad6s1 /mnt/media ufs rw 1 1 #/dev/gvinum/data01 /mnt/data2 ufs rw,noauto 0 0 #/dev/gvinum/media /mnt/media ufs rw,noauto 1 4 From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 04:36:47 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB5216A420; Fri, 28 Dec 2007 04:36:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 30BB213C459; Fri, 28 Dec 2007 04:36:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBS4adHL019236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2007 15:36:42 +1100 Date: Fri, 28 Dec 2007 15:36:39 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mark Fullmer In-Reply-To: <985A3F99-B3F4-451E-BD77-E2EB4351E323@eng.oar.net> Message-ID: <20071228143411.C3587@besplex.bde.org> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <985A3F99-B3F4-451E-BD77-E2EB4351E323@eng.oar.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 04:36:47 -0000 On Sat, 22 Dec 2007, Mark Fullmer wrote: > On Dec 22, 2007, at 12:08 PM, Bruce Evans wrote: >> >> I still don't understand the original problem, that the kernel is not >> even preemptible enough for network interrupts to work (except in 5.2 >> where Giant breaks things). Perhaps I misread the problem, and it is >> actually that networking works but userland is unable to run in time >> to avoid packet loss. > > The test is done with UDP packets between two servers. The em > driver is incrementing the received packet count correctly but > the packet is not making it up the network stack. If > the application was not servicing the socket fast enough I would > expect to see the "dropped due to full socket buffers" (udps_fullsock) > counter incrementing, as shown by netstat -s. I couldn't see any sign of PREEMPTION not working in 6.3-PREREALEASE. em seemed to keep up with the maximum rate that I can easily generate (640 kpps with tiny udp packets), though it cannot transmit at more than 400 kpps on the same hardware. This is without aby syncer activity to cause glitches. The rest of the system couldn't keep up, and with my normal configuration of net.isr.direct=1, systat -ip (udps_fullsock) showed too many packets being dropped, but all the numbers seemed to add up right. (I didn't do end-to-end packet counts. I'm using ttcp to send and receive packets; the receiver loses so many packets that it rarely terminates properly, and when it does terminate it always shows many dropped.) However, with net.isr.direct=0, packets are dropped with no sign of the problem except a reduced count of good packets in systat -ip. Packet rate counter net.isr.direct=1 net.isr.direct=0 ------------------- ---------------- ---------------- netstat -I 639042 643522 (faster later) systat -ip (total rx) 639042 382567 (dropped many b4 here) (UDP total) 639042 382567 (udps_fullsock) 298911 70340 (diff of prev 2) 340031 312227 (300+k always dropped) net.isr.count small large (seems to be correct 643k) net.isr.directed large (correct?) no change net.isr.queued 0 0 net.isr.drop 0 0 net.isr.direct=0 is apparently causing dropped packets without even counting them. However, the drop seems to be below the netisr level. More worryingly, with full 1500-byte packets (1472 data + 28 UDP header), packets can be sent at a rate of 76 kpps (nearly 950 Mbps) with a load of only 80% on the receiver, yet the ttcp receiver still drops about 1000 pps due top "socket buffer full". With net.usr.direct=0 it drops an additinal 700 pps due to this. Glitches from sync(2) taking 25 ms increase the loss by about 1000 packets, and using rtprio for the ttcp receiver doesn't seem to help at all. In previous mail, you (Mark) wrote: # With FreeBSD 4 I was able to run a UDP data collector with rtprio set, # kern.ipc.maxsockbuf=20480000, then use setsockopt() with SO_RCVBUF # in the application. If packets were dropped they would show up # with netstat -s as "dropped due to full socket buffers". # # Since the packet never makes it to ip_input() I no longer have # any way to count drops. There will always be corner cases where # interrupts are lost and drops not accounted for if the adapter # hardware can't report them, but right now I've got no way to # estimate any loss. I tried using SO_RCVBUF in ttcp (it's an old version of ttcp that doesn't have an option for this). With the default kern.ipc.maxsockbuf of 256K, this didn't seem to help. 20MB should work better :-) but I didn't try that. I don't understand how fast the socket buffer fills up and would have thought that 256K was enough for tiny packets but not for 1500-byte packets. Their seems to be a general problem that 1Gbps NICs have or should have rings of size >= 256 or 512 so that they aren't forced to drop packets when their interrupt handler has a reasonable but larger latency, yet if we actually use this feature then we flood the upper layers with hundreds of packets and fill up socket buffers etc. there. Bruce From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 04:51:08 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 322C216A41B for ; Fri, 28 Dec 2007 04:51:08 +0000 (UTC) (envelope-from shieronymus@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id AA59113C4D3 for ; Fri, 28 Dec 2007 04:51:07 +0000 (UTC) (envelope-from shieronymus@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so4949188fka.11 for ; Thu, 27 Dec 2007 20:51: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:references; bh=RbxzDlS8EcCGMhC3XUM675KtOODRh/vt4lNsDJQON3g=; b=pJrrOjWPamLPMCJfjqhkJ0q/xgpYgzlskzOoM8W5Vu60TKQAuzu6gOuADpa101yY8JjSw7PH1cCBtZuRyRSMk9/ah4+bjr8Lsj7HtQu+qYhmGmYbjSJ90pZ2WBlNKPy6oIcj7NR41Wt5n010eLENp8IcsPdym/PDDMvxqMkxmFI= 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:references; b=geZnJa8na77Dqh1CJje67XpMhTU0mCJf8wvHPhfr1bHS8Qf/EmHUlzkfe3W7nCeqLLFVDJomnbBv4wcXvPOjOjjtUZdK71aQyEsVPAsp70PVAv26y7FF3OCitli5YOUTEYD7YIYLpN8X1CGK1eWDT76BDy1eRy6lApkWGEAVJaw= Received: by 10.78.133.2 with SMTP id g2mr10765055hud.26.1198817465945; Thu, 27 Dec 2007 20:51:05 -0800 (PST) Received: by 10.78.140.2 with HTTP; Thu, 27 Dec 2007 20:51:05 -0800 (PST) Message-ID: <70d306230712272051q5aa9f0b2xf9e61150d2da307d@mail.gmail.com> Date: Thu, 27 Dec 2007 21:51:05 -0700 From: "Seth Hieronymus" To: "Roland Smith" In-Reply-To: <20071228002922.GA75879@slackbox.xs4all.nl> MIME-Version: 1.0 References: <70d306230712240855j3ecd0000w7a7f87cadc15652a@mail.gmail.com> <47743135.50103@delphij.net> <70d306230712271549j1fc5c31dm3a8d5acc04871c9e@mail.gmail.com> <20071228002922.GA75879@slackbox.xs4all.nl> 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: stable@freebsd.org, delphij@delphij.net Subject: Re: Instant Reboot with 7.0 BETA4 LifeFS Disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 04:51:08 -0000 On Dec 27, 2007 5:29 PM, Roland Smith wrote: > On Thu, Dec 27, 2007 at 04:49:47PM -0700, Seth Hieronymus wrote: > > > > > The specs of the system are: > > > > Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard > > > > AMD Athlon64 3800+ Newcastle 2.4GHz > > > > Promise FastTrak 579 RAID Controller (PDC20579) > > > > 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 > > > > Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card > > > > One guess: what if you disable and disconnect your hard disk? This > will > > > be helpful to narrow down the issue... > > > Thanks for the response! What you suggested worked -- I removed the > SATA > > cables from both harddrives, and then was able to boot using the 7.0BETA4 > > AMD64 LiveFS cd. > > > Not sure it matters, but one interesting thing is that the motherboard > also > > has another SATA controller (irq 20 at device 15.0), which is: > > atapci1: > > I've got two disks attached in RAID1 to the VIA 6420 controller. Works > fine here (7.0-BETA3 FreeBSD amd64). Try connecting your disks to the > via controller. > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > Thanks for the reply. That's good to know about the VIA controller. I'm not quite ready to wipe my current disks yet, which I think I would have to do to switch RAID controllers, but may go that route in the future. I also confirmed I can install on a plain IDE harddrive, so may just do that for immediate testing. Thanks, Seth From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 05:23:52 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3BC16A417; Fri, 28 Dec 2007 05:23:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id A7B7A13C467; Fri, 28 Dec 2007 05:23:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBS5NfSv022528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2007 16:23:44 +1100 Date: Fri, 28 Dec 2007 16:23:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20071228143411.C3587@besplex.bde.org> Message-ID: <20071228155323.X3858@besplex.bde.org> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <985A3F99-B3F4-451E-BD77-E2EB4351E323@eng.oar.net> <20071228143411.C3587@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-stable@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 05:23:52 -0000 On Fri, 28 Dec 2007, Bruce Evans wrote: > In previous mail, you (Mark) wrote: > > # With FreeBSD 4 I was able to run a UDP data collector with rtprio set, > # kern.ipc.maxsockbuf=20480000, then use setsockopt() with SO_RCVBUF > # in the application. If packets were dropped they would show up > # with netstat -s as "dropped due to full socket buffers". > # # Since the packet never makes it to ip_input() I no longer have > # any way to count drops. There will always be corner cases where > # interrupts are lost and drops not accounted for if the adapter > # hardware can't report them, but right now I've got no way to > # estimate any loss. > > I tried using SO_RCVBUF in ttcp (it's an old version of ttcp that doesn't > have an option for this). With the default kern.ipc.maxsockbuf of 256K, > this didn't seem to help. 20MB should work better :-) but I didn't try that. I've now tried this. With kern.ipc.maxsockbuf=20480000 (~20MB) an SO_RCVBUF of 0x1000000 (16MB), the "socket buffer full lossage increases from ~300 kpps (~47%) to ~450 kpps (70%) with tiny packets. I think this is caused by most accesses to the larger buffer being cache misses -- since the system can't keep up, cache misses make it worse). However, with 1500-byte packets, the larger buffer reduces the lossage from 1 kpps in 76 kpps to precisely zero pps, at a cost of only a small percentage of system overhead (~20Idle to ~18%Idle). The above is with net.isr.direct=1. With net.isr.direct=0, the loss is too small to be obvious and is reported as 0, but I don't trust the report. ttcp's packet counts indicate losses of a few per million with direct=0 but none with direct=1. "while :; do sync; sleep 0.1" in the background causes a loss of about 100 pps with direct=0 and a smaller loss with direct=1. Running the ttcp receiver at rtprio 0 doesn't make much difference to the losses. Bruce From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 06:02:24 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC53916A469 for ; Fri, 28 Dec 2007 06:02:24 +0000 (UTC) (envelope-from novembre@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 9118A13C448 for ; Fri, 28 Dec 2007 06:02:24 +0000 (UTC) (envelope-from novembre@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so673514anc.13 for ; Thu, 27 Dec 2007 22:02:24 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=DEmojF35fmeCnWJncWMSQbrVpk9OETinZeFdOS6XtUo=; b=Nr/zXBw9fCaf+wg3bm1gOkV2kM219ItK3EfdnW8vb6Xyp1jmeGaLPt5N+iO1xTsfhO/LutQ3jA5AYygqKuXlE/FSHHelgDvEIdyAngEnCjwF4e+ohJGnW/leT/i9lSMiEufTzJEzmeiFkL+UBdl4J1V75uqMuTHB7OlL3LABHJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=QEb/o9noeKUdg8AFK8TUG3eE0i++hNTEB6lHOfuy3VKuoKoOp+qtlNpd/s23fVSYe+gTYjKbGaqPQjFOUsNq8wiHsjJYt5cJoqnutlJ+e2e8vP7WUFflwsEEUulEhi/bz2fqD4vcmux3yTtM3ffLtMfiDEYTqYeLFZztQTgxmxM= Received: by 10.100.239.11 with SMTP id m11mr18255089anh.87.1198820167981; Thu, 27 Dec 2007 21:36:07 -0800 (PST) Received: by 10.100.41.13 with HTTP; Thu, 27 Dec 2007 21:36:07 -0800 (PST) Message-ID: <3b47caa90712272136l19214074n780e821d3975bf94@mail.gmail.com> Date: Thu, 27 Dec 2007 23:36:07 -0600 From: Novembre To: eraser95@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-stable@freebsd.org Subject: Re: VIA DRM on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 06:02:24 -0000 Hi, I also have a VIA Unichrome graphics chip in one of my computers and would like to use DRM with it, but it's not possible yet. I have asked Eric Anholt about it, and here's his reply (copy-&-paste): ----- VIA DRM isn't ported. You would need to port it if you wanted DRI. ----- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 06:41:52 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F7D716A419 for ; Fri, 28 Dec 2007 06:41:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id CF1D813C44B for ; Fri, 28 Dec 2007 06:41:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so5603225waf.3 for ; Thu, 27 Dec 2007 22:41:51 -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=uo9Wr4L3sw+XvR2ilSMcrW1i8Gt6XJivErNValbmWug=; b=Ko3o329UTNQVmAHE8HzLPRr4W+VoQojFRGWTvmpcBanG/F/ZRw+lRE2dXJeF6I9bNrvUQKlRhUU07Z9+uiigVWOeNII1bCjb8w+xE+J881uypvMh0MRcnxJQ5ZA461LQJzD1Aq+FcvjiXjo1UNQAppNqWGF3JUFPqF2xUeB+hkw= 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=OL4Dhyre6ja2MEMIrEep5PhyuHcZqVFoy7r42FisXBrLaetx5lQnxmv/oZoLeEuXYIpEsBXNKcxKcOQ4F9VEIXOXox86ZYwB7VTWSy61tbm4HvdRwKT1S1/OqlUlX7S8pr01vHKigohPrCnVE9WK5iyl8HAeKuvmBvh+WPxaNYc= Received: by 10.114.61.1 with SMTP id j1mr9097209waa.62.1198824111683; Thu, 27 Dec 2007 22:41:51 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id v37sm3359958wah.12.2007.12.27.22.41.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Dec 2007 22:41:49 -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 lBS6eqgl010105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2007 15:40:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id lBS6epMD010104; Fri, 28 Dec 2007 15:40:51 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 28 Dec 2007 15:40:51 +0900 From: Pyun YongHyeon To: Danny Braniss Message-ID: <20071228064051.GB8872@cdnetworks.co.kr> References: <20071210011714.GC60272@cdnetworks.co.kr> <20071210095715.GG60272@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: 7.0-BETA4 and msk problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 06:41:52 -0000 On Thu, Dec 27, 2007 at 12:51:29PM +0200, Danny Braniss wrote: > > On Mon, Dec 10, 2007 at 11:03:47AM +0200, Danny Braniss wrote: > > > > On Sun, Dec 09, 2007 at 02:41:28PM +0200, Danny Braniss wrote: > > > > > with this onboard NIC (LOB?) > > > > > > > > > > mskc0: > > > > > e1000phy0: PHY 0 on miibus0 > > > > > > > > > > mskc0@pci0:1:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab > > > > > rev=0x12 hdr=0x00 > > > > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > > > > device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' > > > > > class = network > > > > > subclass = ethernet > > > > > > > > > > I'm getting allot of: > > > > > msk0: watchdog timeout > > > > > and > > > > > mskc0: Tx descriptor error > > > > > and > > > > > msk0: link state changed to DOWN > > > > > and > > > > > msk0: link state changed to UP > > > > > > > > > > any help is most welcome, > > > > > danny > > > > > > > > > > > > > > > > > > It seems that the issue happens only on 88E8056/88E1149 PHY. > > > > See PR 116853 and 114631. > > > > Sorry, I have no cluet yet. > > > > > > to add some more noise, this is the first host that panicked too :-) > > > anything I can do to help? > > > > Probably ship the hardware to me? :) > love to, but the hardware is not mine :-) > > here is some more info, this is a different board, but with the > same Marvell 88E8056, and it panics after printing 'no PHY found!' > and the ethernet is -1 (ff.ff...) > Hmm, I can't reproduce the panic with 88E8053 on my box. What do you mean the ethernet is -1? Sorry I didn't understand it. If PHY was not found in phy probe msk wouldn't be attached to your hardware. Would you show me backtrace information? It seems that there are several 88E8056 controllers with different revision numbers. Recent 88E8056 models doesn't seem to work but I have no clue yet. The common factor was 88E8056/88E1149 PHY. -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 06:49:23 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4864716A419; Fri, 28 Dec 2007 06:49:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id C4A5F13C44B; Fri, 28 Dec 2007 06:49:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBS6nGth032192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2007 17:49:18 +1100 Date: Fri, 28 Dec 2007 17:49:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20071228155323.X3858@besplex.bde.org> Message-ID: <20071228170151.C4166@besplex.bde.org> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <985A3F99-B3F4-451E-BD77-E2EB4351E323@eng.oar.net> <20071228143411.C3587@besplex.bde.org> <20071228155323.X3858@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-stable@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 06:49:23 -0000 On Fri, 28 Dec 2007, Bruce Evans wrote: > On Fri, 28 Dec 2007, Bruce Evans wrote: > >> In previous mail, you (Mark) wrote: >> >> # With FreeBSD 4 I was able to run a UDP data collector with rtprio set, >> # kern.ipc.maxsockbuf=20480000, then use setsockopt() with SO_RCVBUF >> # in the application. If packets were dropped they would show up >> # with netstat -s as "dropped due to full socket buffers". >> # # Since the packet never makes it to ip_input() I no longer have >> # any way to count drops. There will always be corner cases where >> # interrupts are lost and drops not accounted for if the adapter >> # hardware can't report them, but right now I've got no way to >> # estimate any loss. I found where drops are recorded for the net.isr.direct=0 case. It is in net.inet.ip.intr_queue.drops. The netisr subsystem just calls IF_HANDOFF(), and IF_HANDOFF() calls _IF_DROP() if the queue fills up. _IF_DROP(ifq) just increments ifq->ip_drops. The usual case for netisrs is for the queue to be ipintrq for NETISR_IP. The following details don't help: - drops for input queues don't seem to be displayed by any utilities (except ones for ipintrq are displayed primitively by sysctl net.inet.ip.intr_queue_drops). netstat and systat only display drops for send queues and ip frags. - the netisr subsystem's drop count doesn't seem to be displayed by any utilities except sysctl. It only counts drops due to there not being a queue; other drops are counted by _IF_DROP() in the per-queue counter. Users have a hard time integrating all these primitively displayed drop counts with other error counters. - the length of ipintrq defaults to the default ifq length of ipqmaxlen = IPQ_MAXLEN = 50. This is inadequate if there is just one NIC in the system that has an rx ring size of >= slightly less than 50. But 1 Gbps NICs should have an rx ring size of 256 or 512 (I think the size is 256 for em; it is 256 for bge due to bogus configuration of hardware that can handle it being 512). If the larger hardware rx ring is actually used, then ipintrq drops are almost ensured in the direct=0 case, so using the larger h/w ring is worse than useless (it also increases cache misses). This is for just one NIC. This problem is often limited by handling rx packets in small bursts, at a cost of extra overhead. Interrupt moderation increases it by increasing burst sizes. This contrasts with the handling of send queues. Send queues are per-interface and most drivers increase the default length from 50 to their ring size (-1 for bogus reasons). I think this is only an optimization, while a similar change for rx queues is important for avoiding packet loss. For send queues, the ifq acts mainly as a primitive implementation of watermarks. I have found that tx queue lengths need to be more like 5000 than 50 or 500 to provide enough buffering when applications are delayed by other applications or just by sleeping until the next clock tick, and use tx queues of length ~20000 (a couple of clock ticks at HZ = 100), but now think queue lengths should be restricted to more like 50 since long queues cannot fit in L2 caches (not to mention they are bad for latency). The length of ipintrq can be changed using sysctl net.inet.ip.intrq_queue_maxlen. Changing it from 50 to 1024 turns most or all ipintrq drops into "socket buffer full" drops (640 kpps input packets and 434 kpps socket buffer fulls with direct=0; 640 kpps input packets and 324 kpps socket buffer fulls with direct=1). Bruce From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 07:05:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B8616A418 for ; Fri, 28 Dec 2007 07:05:33 +0000 (UTC) (envelope-from barnabasdk@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 7982C13C447 for ; Fri, 28 Dec 2007 07:05:32 +0000 (UTC) (envelope-from barnabasdk@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2336712fgg.35 for ; Thu, 27 Dec 2007 23:05: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=GTnIc3YeSQxS0jCirJQV6MS0Vj+ErHC5Qve3xA8Wk28=; b=ZGYhLnqi9Zsv8lhnbiKT1dBr4VA5y1SEGS5dkQ+xWTmH6Pe0uuo3bbrDWpluEEWjqQl1Q+gr2iuSDCsA2EdmLyd5pKhkDECvZtG51VBaLqQmDWtAdoeGXlHrbSxQ6jYnxUk3jAk+kHgZ7zsS8aTUF9iFE3ixLWN/vZMRIg1HSnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vLGKtWOIGymFNrawcpgwBjgGH5JghXoufOcqsKpSGEJSDdr0z+igQ4xYavGAHVbiLO5N2fHoT4GW6hcW400MpxC0V2B3mhIK0DCA1rXpFgpRLKzUQxuFNr6Tyt2FxwqoZ/B1WJSPj5oZi/5H3vh5fka99oxM7yiw6NPmhgYc7VA= Received: by 10.86.87.5 with SMTP id k5mr8639608fgb.51.1198825531205; Thu, 27 Dec 2007 23:05:31 -0800 (PST) Received: by 10.86.72.6 with HTTP; Thu, 27 Dec 2007 23:05:31 -0800 (PST) Message-ID: <59d23e060712272305y3f27f909ue6eff0369cbf6883@mail.gmail.com> Date: Fri, 28 Dec 2007 08:05:31 +0100 From: "Nikolaj Hansen" To: freebsd-stable@freebsd.org In-Reply-To: <59d23e060712271706v7dbbdee5v9dcb3f8c5d652b3a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <59d23e060712271706v7dbbdee5v9dcb3f8c5d652b3a@mail.gmail.com> Subject: Re: Failure of gvinum after panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 07:05:33 -0000 A little more info on the config and how it should be: current config dump: # Vinum configuration of , saved at Fri Dec 28 07:31:54 2007 drive elben device /dev/da1s1h drive donau device /dev/da0s1h drive raid5_4_ad11 device /dev/ad11 drive raid5_3_ad10 device /dev/ad10 drive raid5_2_ad9 device /dev/ad9 drive raid5_1_ad8 device /dev/ad8 drive spree device /dev/ad4a volume data01 volume usr volume home volume tmp volume var volume media plex name data01.p0 org concat vol data01 plex name usr.p1 org concat plex name home.p1 org concat plex name tmp.p1 org concat plex name var.p1 org concat plex name usr.p0 org concat plex name home.p0 org concat plex name tmp.p0 org concat plex name var.p0 org concat plex name media.p0 org raid5 1024s vol media sd name data01.p0.s0 drive spree len 234434560s driveoffset 265s plex data01.p0 plexoffset 0s sd name usr.p1.s0 drive elben len 11521427s driveoffset 4505865s sd name home.p1.s0 drive elben len 2048000s driveoffset 2457865s sd name tmp.p1.s0 drive elben len 1228800s driveoffset 1229065s sd name var.p1.s0 drive elben len 1228800s driveoffset 265s sd name usr.p0.s0 drive donau len 11521427s driveoffset 4505865s sd name home.p0.s0 drive donau len 2048000s driveoffset 2457865s sd name tmp.p0.s0 drive donau len 1228800s driveoffset 1229065s sd name var.p0.s0 drive donau len 1228800s driveoffset 265s sd name media.p0.s0 drive raid5_1_ad8 len 398282752s driveoffset 265s plex media.p0 plexoffset 0s sd name media.p0.s1 drive raid5_2_ad9 len 398282752s driveoffset 265s plex media.p0 plexoffset 1024s sd name media.p0.s2 drive raid5_3_ad10 len 398282752s driveoffset 265s plex media.p0 plexoffset 2048s sd name media.p0.s3 drive raid5_4_ad11 len 398282752s driveoffset 265s How the plexes should read out: P usr.p1 C State: up Subdisks: 1 Size: 5625 MB P home.p1 C State: up Subdisks: 1 Size: 1000 MB P tmp.p1 C State: up Subdisks: 1 Size: 600 MB P var.p1 C State: up Subdisks: 1 Size: 600 MB P usr.p0 C State: up Subdisks: 1 Size: 5625 MB P home.p0 C State: up Subdisks: 1 Size: 1000 MB P tmp.p0 C State: up Subdisks: 1 Size: 600 MB P var.p0 C State: up Subdisks: 1 Size: 600 MB The way it reads out: P usr.p1 C State: up Subdisks: 0 Size: 0 B P home.p1 C State: up Subdisks: 0 Size: 0 B P tmp.p1 C State: up Subdisks: 0 Size: 0 B P var.p1 C State: up Subdisks: 0 Size: 0 B P usr.p0 C State: up Subdisks: 0 Size: 0 B P home.p0 C State: up Subdisks: 0 Size: 0 B P tmp.p0 C State: up Subdisks: 0 Size: 0 B P var.p0 C State: up Subdisks: 0 Size: 0 B The difference is obvious - somehow gvinum lost track of the plex to subdisk relations. Is there any way of restoring these? What would happen if I where to re-create the Plexes? (Drop/create) and then saveconfig? Thanks Nikolaj Hansen On Dec 28, 2007 2:06 AM, Nikolaj Hansen wrote: > Hi all, > > I have some problems with my gvinum setup after the system panic'ed. > Afterwards the system fails finding the plexes to the subdisks (or at > least that is what I can understand after having searched the gvinum > source code for the error string in the DMESG log..) > > The machine is an IBM Netfinity 5000 and the internal HW self tests > does not find any errors in the hw. > > Luckily my root is not on a gvinum drive, so I am able to boot the > server in single user. > > Does anyone have any hints as to what I can do to get gvinum to > recognize the disks correctly? > > The system is 6.3 stable > > Dont worry about the media disks or anything right now - I am trying > to revive the system disks for now. > > Thanks > > Nikolaj Hansen > > 7 drives: > D elben State: up /dev/da1s1h A: 0/7825 MB (0%) > D donau State: up /dev/da0s1h A: 0/7825 MB (0%) > D raid5_4_ad11 State: up /dev/ad11 A: 6/194480 MB (0%) > D raid5_3_ad10 State: up /dev/ad10 A: 6/194480 MB (0%) > D raid5_2_ad9 State: up /dev/ad9 A: 6/194480 MB (0%) > D raid5_1_ad8 State: up /dev/ad8 A: 6/194480 MB (0%) > D spree State: up /dev/ad4a A: 3/114473 MB (0%) > > 6 volumes: > V data01 State: up Plexes: 1 Size: 111 GB > V usr State: up Plexes: 0 Size: 0 B > V home State: up Plexes: 0 Size: 0 B > V tmp State: up Plexes: 0 Size: 0 B > V var State: up Plexes: 0 Size: 0 B > V media State: up Plexes: 1 Size: 379 GB > > 10 plexes: > P data01.p0 C State: up Subdisks: 1 Size: 111 GB > P usr.p1 C State: up Subdisks: 0 Size: 0 B > P home.p1 C State: up Subdisks: 0 Size: 0 B > P tmp.p1 C State: up Subdisks: 0 Size: 0 B > P var.p1 C State: up Subdisks: 0 Size: 0 B > P usr.p0 C State: up Subdisks: 0 Size: 0 B > P home.p0 C State: up Subdisks: 0 Size: 0 B > P tmp.p0 C State: up Subdisks: 0 Size: 0 B > P var.p0 C State: up Subdisks: 0 Size: 0 B > P media.p0 R5 State: degraded Subdisks: 3 Size: 379 GB > > 13 subdisks: > S data01.p0.s0 State: up D: spree Size: 111 GB > S usr.p1.s0 State: up D: elben Size: 5625 MB > S home.p1.s0 State: up D: elben Size: 1000 MB > S tmp.p1.s0 State: up D: elben Size: 600 MB > S var.p1.s0 State: up D: elben Size: 600 MB > S usr.p0.s0 State: up D: donau Size: 5625 MB > S home.p0.s0 State: up D: donau Size: 1000 MB > S tmp.p0.s0 State: up D: donau Size: 600 MB > S var.p0.s0 State: up D: donau Size: 600 MB > S media.p0.s0 State: up D: raid5_1_ad8 Size: 189 GB > S media.p0.s1 State: up D: raid5_2_ad9 Size: 189 GB > S media.p0.s2 State: stale D: raid5_3_ad10 Size: 189 GB > S media.p0.s3 State: up D: raid5_4_ad11 Size: 189 GB > > Copyright (c) 1992-2007 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 6.2-RELEASE-p6 #0: Wed Jul 18 23:33:58 CEST 2007 > root@sauron.barnabas.dk:/usr/src/sys/i386/compile/KERNEL_6_2 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Pentium III/Pentium III Xeon/Celeron (498.67-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > Features=0x387fbff > real memory = 536854528 (511 MB) > avail memory = 515715072 (491 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 1 > cpu1 (AP): APIC ID: 0 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe88-0xfe8b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > skc0: <3Com 3C940 Gigabit Ethernet> port 0x2000-0x20ff mem > 0xfebfc000-0xfebfffff irq 18 at device 1.0 on pci0 > skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) > sk0: on skc0 > sk0: Ethernet address: 00:0a:5e:5c:c0:83 > miibus0: on sk0 > e1000phy0: on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto > ahc0: port 0x2200-0x22ff mem > 0xfebfb000-0xfebfbfff irq 16 at device 6.0 on pci0 > ahc0: [GIANT-LOCKED] > aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/253 SCBs > ahc1: port 0x2300-0x23ff mem > 0xfebfa000-0xfebfafff irq 16 at device 6.1 on pci0 > ahc1: [GIANT-LOCKED] > aic7895C: Ultra Wide Channel B, SCSI Id=15, 32/253 SCBs > s3pci0: port 0x3c0-0x3df,0x4ae8 mem > 0xf8000000-0xfbffffff irq 9 at device 10.0 on pci0 > isab0: port 0xfe00-0xfe0f at device 15.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 irq 18 at device 15.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > ohci0: mem 0xff700000-0xff700fff irq > 18 at device 15.2 on pci0 > ohci0: [GIANT-LOCKED] > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pcib1: on acpi0 > pci1: on pcib1 > atapci1: port > 0x4af0-0x4af7,0x4aec-0x4aef,0x4af8-0x4aff,0x4b00-0x4b03,0x4b10-0x4b1f > irq 19 at device 2.0 on pci1 > ata2: on atapci1 > ata3: on atapci1 > atapci2: port > 0x4b08-0x4b0f,0x4b04-0x4b07,0x4b20-0x4b27,0x4b28-0x4b2b,0x4b30-0x4b3f > mem 0xc0fdc000-0xc0fdffff irq 19 at device 3.0 on pci1 > ata4: on atapci2 > ata5: on atapci2 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > fdc0: port 0x3f2-0x3f7,0x3f7 irq 6 drq 2 on acpi0 > fdc0: No FDOUT register! > device_attach: fdc0 attach returned 6 > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 > drq 1 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc0 > ppbus0: IEEE1284 device found /NIBBLE/ECP > Probing for PnP devices on ppbus0: > ppbus0: MLC,PCL,PML > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > fdc0: port 0x3f2-0x3f7,0x3f7 irq 6 drq 2 on acpi0 > fdc0: No FDOUT register! > device_attach: fdc0 attach returned 6 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xc7fff,0xc8000-0xccfff,0xcd000-0xcd7ff,0xcd800-0xd17ff,0xd1800-0xd3fff > on isa0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > umass0: Kingston DataTraveler II, rev 2.00/1.00, addr 2 > Timecounters tick every 1.000 msec > ad4: 114473MB at ata2-master UDMA100 > ad6: 114473MB at ata3-master UDMA100 > ad8: 194481MB at ata4-master UDMA100 > ad9: 194481MB at ata4-slave UDMA100 > ad10: 194481MB at ata5-master UDMA100 > ad11: 194481MB at ata5-slave UDMA100 > Waiting 5 seconds for SCSI devices to settle > gv_plex_taste: NULL p for 'media.p0.s3' > ses0 at ahc1 bus 0 target 14 lun 0 > ses0: Fixed Processor SCSI-2 device > ses0: 3.300MB/s transfers > ses0: SAF-TE Compliant Device > da0 at ahc1 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled > da0: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C) > da1 at ahc1 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled > da1: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C) > SMP: AP CPU #1 Launched! > da2 at umass-sim0 bus 0 target 0 lun 0 > da2: Removable Direct Access SCSI-0 device > da2: 1.000MB/s transfers > da2: 983MB (2014208 512 byte sectors: 64H 32S/T 983C) > gv_plex_taste: NULL p for 'var.p0.s0' > gv_plex_taste: NULL p for 'tmp.p0.s0' > gv_plex_taste: NULL p for 'home.p0.s0' > gv_plex_taste: NULL p for 'usr.p0.s0' > gv_plex_taste: NULL p for 'var.p1.s0' > gv_plex_taste: NULL p for 'tmp.p1.s0' > gv_plex_taste: NULL p for 'home.p1.s0' > gv_plex_taste: NULL p for 'usr.p1.s0' > Trying to mount root from ufs:/dev/da0s1a > WARNING: / was not properly dismounted > WARNING: R/W mount of / denied. Filesystem is not clean - run fsck > > Subdisk usr.p0.s0: > Size: 5898970624 bytes (5625 MB) > State: up > Drive donau (donau) at offset 2307002880 (2200 MB) > > /dev/da0s1b none swap sw 0 0 > /dev/da1s1b none swap sw 0 0 > /dev/da0s1a / ufs rw 1 5 > /dev/gvinum/home /home ufs rw 2 5 > /dev/da1s1a /rootback ufs rw 2 6 > /dev/gvinum/tmp /tmp ufs rw 2 1 > /dev/gvinum/usr /usr ufs rw 2 2 > /dev/gvinum/var /var ufs rw 2 3 > /dev/cd0 /cdrom cd9660 ro,noauto 0 0 > /dev/acd0 /cdrom1 cd9660 ro,noauto 0 0 > #/dev/ad6s1 /mnt/media ufs rw 1 1 > #/dev/gvinum/data01 /mnt/data2 ufs rw,noauto 0 0 > #/dev/gvinum/media /mnt/media ufs rw,noauto 1 4 > From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 07:28:47 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD18F16A417; Fri, 28 Dec 2007 07:28:47 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7672F13C47E; Fri, 28 Dec 2007 07:28:47 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (unknown [151.197.183.78]) by mail.asahi-net.or.jp (Postfix) with ESMTP id A073B52E4C; Fri, 28 Dec 2007 16:08:03 +0900 (JST) Date: Fri, 28 Dec 2007 02:07:49 -0500 From: Yoshihiro Ota To: remko@elvandar.org Message-Id: <20071228020749.b5fc0ab2.ota@j.email.ne.jp> In-Reply-To: <18754.194.74.82.3.1198744988.squirrel@galain.elvandar.org> References: <20071226.003547.-932932005.imp@bsdimp.com> <1198689316.1119.382.camel@Particle> <20071226180415.GA27409@soaustin.net> <20071226.114224.-432836428.imp@bsdimp.com> <18754.194.74.82.3.1198744988.squirrel@galain.elvandar.org> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ota@j.email.ne.jp, stable@freebsd.org, freebsd-bugbusters@freebsd.org Subject: Re: PR backlog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 07:28:47 -0000 On Thu, 27 Dec 2007 09:43:08 +0100 (CET) "Remko Lodder" wrote: > > Hello Warner et all, > > On Wed, December 26, 2007 7:42 pm, M. Warner Losh wrote: > > Mark and Henrik make a number of good points here. Rather than reply > > to the details, I'm going to make a couple of quick observations. > > > > As a project we're not leveraging the community sufficiently when it > > comes to contributions. The current system of patch review and > > submission is very hap-hazard. If you happen to get the attention of > > the right person at the right time, then it goes in. If not, patches > > can languish a long time in the PR system. > > Indeed, I am one of the persons trying to find these relatively easy > things which I can do along side my other projects and things, but I dont > see them all (eventhough I try to keep track of them as much as possible); > but what will happen is that I learn more and more about the system and at > some point in time I will "stop" working on these easy PR's and seeking > more difficult ones to fix, at that point someone else has to step up to > fill in the gap that gets created; this might be a problematic part :-) > > Though for everyone having simple fixes, please send them to me so that I > can evaluate them and (together with Warner in this case (As my mentor)) I > will try to get them in as correctly and quickly as possible :-) (keeping > up with the high standards of FreeBSD ofcourse). I also opened the PR database a couple weeks ago looking for a solution to bugs I encountered. It's been quite long, some years, since I opened the PR page last time. It was surprising and also disappointing on the number of PRs left open for long time. How do I help that cleaning job? I am also interested fixing and concerned about this fact. Thanks, Hiro From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:33:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F007616A417 for ; Fri, 28 Dec 2007 12:33:06 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from core.stromnet.se (core.stromnet.se [83.218.84.131]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3C213C455 for ; Fri, 28 Dec 2007 12:33:06 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from localhost (unknown [83.218.84.135]) by core.stromnet.se (Postfix) with ESMTP id CBA53D46F37 for ; Fri, 28 Dec 2007 13:16:22 +0100 (CET) X-Virus-Scanned: amavisd-new at stromnet.se Received: from core.stromnet.se ([83.218.84.131]) by localhost (core.stromnet.se [83.218.84.135]) (amavisd-new, port 10024) with ESMTP id rcHj2i-cMEuY for ; Fri, 28 Dec 2007 13:16:20 +0100 (CET) Received: from [172.28.1.102] (90-224-172-102-no129.tbcn.telia.com [90.224.172.102]) by core.stromnet.se (Postfix) with ESMTP id 578D4D46405 for ; Fri, 28 Dec 2007 13:16:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: quoted-printable Message-Id: <91064C44-1A41-4FCB-A718-1EF3A63E2273@stromnet.se> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: =?ISO-8859-1?Q?Johan_Str=F6m?= Date: Fri, 28 Dec 2007 13:15:38 +0100 X-Mailer: Apple Mail (2.753) Subject: I just broke out of a FreeBSD jail.. Known bug?? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 12:33:07 -0000 Hello list! I'm running a FreeBSD 6.2-p8 box with a few jails. The other day a =20 user of mine uploaded a number of files to one jail, then I (in the =20 actual system outside of all jails) moved that directory to another =20 jail.. When I later did some chdiring in the original jail, I found =20 my self standing in my other jails pwd and beeing able to read/=20 manipulate files!.. Example: jb-1 (the base machine, jailbox-1) shell (jail 1) core (jail 2) shell /home/johan# pwd /home/johan shell /home/johan# ls .cshrc .irssi .login_conf .mailrc .profile=20= .shrc .zcompdump public_html .histfile .login .mail_aliases .noident .rhosts =20= .ssh .zshrc shell /home/johan# mkdir test shell /home/johan# cd test shell /home/johan/test# touch asd shell /home/johan/test# ls -al total 4 drwxr-xr-x 2 root root 512 Dec 28 13:09 . drwxr-x--x 6 johan johan 512 Dec 28 13:09 .. -rw-r--r-- 1 root root 0 Dec 28 13:09 asd shell /home/johan/test# Then moving it on the root box jb-1 /usr/jails# mv shell/home/johan/test core/home/johan/ jb-1 /usr/jails# And back on shell jail: shell /home/johan/test# ls asd shell /home/johan/test# pwd pwd: .: No such file or directory shell /home/johan/test# cd .. shell /home/johan# ls .cshrc .lesshst .mailrc .shrc .vimrc =20= file.big roundcube.sql www.tar.gz .histfile .login .mysql_history .ssh .zcompdu=20= mp pics stuff .history .login_conf .profile .vim .zshrc =20= postfix-2.4.5 test .irssi .mail_aliases .rhosts .viminfo =20 cacert.pem public_html vmail.tar.gz shell /home/johan# Thats my home dir on core!.. That should very much not be visible =20 there! I have full access now (from the wrong jail!) Known bug or did I just stumble upon something pretty bad?? -- Johan Str=F6m Stromnet johan@stromnet.se http://www.stromnet.se/ From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:45:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFC0B16A417 for ; Fri, 28 Dec 2007 12:45:42 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from core.stromnet.se (core.stromnet.se [83.218.84.131]) by mx1.freebsd.org (Postfix) with ESMTP id 7E83D13C4CE for ; Fri, 28 Dec 2007 12:45:42 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from localhost (unknown [83.218.84.135]) by core.stromnet.se (Postfix) with ESMTP id 70456D46F37; Fri, 28 Dec 2007 13:45:41 +0100 (CET) X-Virus-Scanned: amavisd-new at stromnet.se Received: from core.stromnet.se ([83.218.84.131]) by localhost (core.stromnet.se [83.218.84.135]) (amavisd-new, port 10024) with ESMTP id WU8MM9HK3zvs; Fri, 28 Dec 2007 13:45:39 +0100 (CET) Received: from [172.28.1.102] (90-224-172-102-no129.tbcn.telia.com [90.224.172.102]) by core.stromnet.se (Postfix) with ESMTP id 086E8D46405; Fri, 28 Dec 2007 13:45:39 +0100 (CET) In-Reply-To: <20071228124151.GA37323@k7.mavetju> References: <91064C44-1A41-4FCB-A718-1EF3A63E2273@stromnet.se> <20071228124151.GA37323@k7.mavetju> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EC90A5A-ECCC-4983-95CE-D82AEE89C289@stromnet.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Johan_Str=F6m?= Date: Fri, 28 Dec 2007 13:44:57 +0100 To: Edwin Groothuis X-Mailer: Apple Mail (2.753) Cc: freebsd-stable@freebsd.org Subject: Re: I just broke out of a FreeBSD jail.. Known bug?? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 12:45:42 -0000 On Dec 28, 2007, at 13:41 , Edwin Groothuis wrote: > On Fri, Dec 28, 2007 at 01:15:38PM +0100, Johan Str?m wrote: >> Thats my home dir on core!.. That should very much not be visible >> there! I have full access now (from the wrong jail!) >> >> Known bug or did I just stumble upon something pretty bad?? > > You didn't really break out of it, the person who managed the machine > did something he shouldn't have done: Moving the directories while > the jail(s) were running. It should be mentioned in the BUGS section > of the jail(8) command. > Yes, thats true.. Without "super-root" doing that the "breakout" would never happen. But still a bug, so yes I guess it should be mentioned in BUGS (and handbook too? not sure where this kind of "special features" are noted) unless its fixed. -- Johan From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:50:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4D2616A47B for ; Fri, 28 Dec 2007 12:50:18 +0000 (UTC) (envelope-from lileding@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 93EB713C4CC for ; Fri, 28 Dec 2007 12:50:18 +0000 (UTC) (envelope-from lileding@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so693893anc.13 for ; Fri, 28 Dec 2007 04:50: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:from:to:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; bh=W/IO4bEHTk+G2F0R+eIgTjg9qc1TSm8iRDuJZ7oM8jw=; b=m4uDCIL1l1NKHkpX9iRddwpF37+efBIN7+EngvvSCvD4tGHcG/h8BcNV3kuxMKjz4RmokNgvU6z5k+Fkgmt8GgTgv5uBo74fwQsT01kbckBQrWbUpNyGMcGglDfqlD45eXj6SO9oXViQNnEfeIxMxXXJOAxXv6idFTDyjcF3UJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; b=dMFVyFwRyijNQlgQ1nBVEbf4dds9ZOwMV0dFIOEPbcsWMQGw0NFdPmI6p4PtVIslfUZhp4q5HSwu9qxkcbStxJaSs3PGPoumCtrqByJESghwj6FndtCw7Qvt7dsPHUPX08gqhYJlmdxFJvOMVUwAqIqxb24wwn6h9l5lD+gsgik= Received: by 10.100.138.4 with SMTP id l4mr17119975and.18.1198844685188; Fri, 28 Dec 2007 04:24:45 -0800 (PST) Received: from whisperPC ( [60.28.210.6]) by mx.google.com with ESMTPS id v76sm495915nzh.6.2007.12.28.04.24.38 (version=SSLv3 cipher=OTHER); Fri, 28 Dec 2007 04:24:42 -0800 (PST) Message-ID: <4EBEF3BEEC444222BFDF7F52E77E8C62@whisperPC> From: "lileding" To: Date: Fri, 28 Dec 2007 20:24:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 Subject: Problems on intel G33M motherboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 12:50:19 -0000 I got a new box with Core2 E6550 and the motherboard is a Foxtone G33M However, the GENERIC cdrom of 6.2 Release can only start at ACPI disabled, and USB keyboard sucks and AT keyboard sometimes lead to crash during boot up the worst is it cannot launch the other CPU core with apic error I also tried 7-PRERELEASE but still in vain is there any patch ? From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:54:44 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 778B416A421 for ; Fri, 28 Dec 2007 12:54:44 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id 7720013C4EA for ; Fri, 28 Dec 2007 12:54:43 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180134215.adsl.alicedsl.de [85.180.134.215]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id lBSCseZ5093936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Dec 2007 13:54:41 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id lBSCscUN005529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2007 13:54:38 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id lBSCsc2P005528; Fri, 28 Dec 2007 13:54:38 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Fri, 28 Dec 2007 13:54:37 +0100 From: Ulrich Spoerlein To: stable@freebsd.org Message-ID: <20071228125437.GB1532@roadrunner.spoerlein.net> Mail-Followup-To: stable@freebsd.org, Hidetoshi Shimokawa MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Hidetoshi Shimokawa Subject: sbp(4) write error wedging GEOM mirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 12:54:44 -0000 Hello *, since a couple of months, my 6-STABLE box is wedging whenever I rebuild my geom mirrors to two external drives simultaneously. The setup is a follows: Two ATA disks, two external ATA disks attached via firewire. On these four disks there are three geom mirrors. When rebuilding two of them at the same time, I frequently get sbp write errors which will eventually lead to a reset and then I/O to this mirror is no longer possible. The system is still running and delivering MP3s from the other mirror via NFS. ad0: 238475MB at ata0-master UDMA100 ad1: 381554MB at ata0-slave UDMA100 GEOM_MIRROR: Device gm2 created (id=3879710801). GEOM_MIRROR: Device gm2: provider ad1 detected. GEOM_MIRROR: Device gm0 created (id=3640684492). GEOM_MIRROR: Device gm0: provider ad0s1 detected. GEOM_MIRROR: Device gm1 created (id=2853507194). GEOM_MIRROR: Device gm1: provider ad0s2 detected. GEOM_LABEL: Label for provider ad0s3 is msdosfs/DATEN. Root mount waiting for: GMIRROR GMIRROR GMIRROR GEOM_MIRROR: Force device gm2 start due to timeout. Expensive timeout(9) function: 0xc0948e15(0xc343fc00) 0.006123403 s GEOM_MIRROR: Device gm2: provider ad1 activated. GEOM_MIRROR: Device gm2: provider mirror/gm2 launched. GEOM_MIRROR: Force device gm0 start due to timeout. GEOM_MIRROR: Device gm0: provider ad0s1 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. GEOM_MIRROR: Force device gm1 start due to timeout. GEOM_MIRROR: Device gm1: provider ad0s2 activated. GEOM_MIRROR: Device gm1: provider mirror/gm1 launched. Trying to mount root from ufs:/dev/mirror/gm0a GEOM_LABEL: Label msdosfs/DATEN removed. GEOM_LABEL: Label for provider ad0s3 is msdosfs/DATEN. GEOM_LABEL: Label msdosfs/DATEN removed. WARNING: attempt to net_add_domain(netgraph) after domainfinalize() fwohci0: BUS reset fwohci0: node_id=0x8800ffc0, gen=2, non CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 0 (me) firewire0: root node is not cycle master capable firewire0: bus manager 0 (me) fwohci0: too many cycle lost, no cycle master presents? fwohci0: txd err=14 ack busy_X fwohci0: txd err=14 ack busy_X fwohci0: txd err=14 ack busy_X fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=3, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) firewire0: New S400 device ID:0050770e012005cf da0 at sbp0 bus 0 target 0 lun 0 da0: Fixed Simplified Direct Access SCSI-4 device da0: 50.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_MIRROR: Device gm0: provider da0s1 detected. GEOM_MIRROR: Device gm0: provider da0s1 is stale. fwohci0: BUS reset fwohci0: node_id=0xc800ffc2, gen=4, CYCLEMASTER mode firewire0: 3 nodes, maxhop <= 2, cable IRM = 2 (me) firewire0: bus manager 2 (me) fwohci0: txd err=14 ack busy_X fwohci0: txd err=14 ack busy_X fwohci0: txd err=14 ack busy_X fwohci0: BUS reset fwohci0: node_id=0xc800ffc2, gen=5, CYCLEMASTER mode firewire0: 3 nodes, maxhop <= 2, cable IRM = 2 (me) firewire0: bus manager 2 (me) firewire0: New S400 device ID:0050770e013023f0 da1 at sbp0 bus 0 target 1 lun 0 da1: Fixed Simplified Direct Access SCSI-4 device da1: 50.000MB/s transfers da1: 381554MB (781422768 512 byte sectors: 255H 63S/T 48641C) GEOM_MIRROR: Device gm2: provider da1 detected. GEOM_MIRROR: Device gm2: rebuilding provider da1. Rebuilding some components finishes ok, then write errors start appearing (11:27:31) root@coyote: ~# gmirror status Name Status Components mirror/gm2 DEGRADED ad1 da1 (5%) mirror/gm0 DEGRADED ad0s1 da0s1 (87%) mirror/gm1 DEGRADED ad0s2 da0s2 (11:30:05) root@coyote: ~# GEOM_MIRROR: Device gm0: rebuilding provider da0s1 finished. GEOM_MIRROR: Device gm0: provider da0s1 activated. (da0:sbp0:0:0:0): WRITE(10). CDB: 2a 0 0 4a f3 f1 0 0 20 0 (da0:sbp0:0:0:0): CAM Status: SCSI Status Error (da0:sbp0:0:0:0): SCSI Status: Check Condition (da0:sbp0:0:0:0): MEDIUM ERROR csi:70,70,70,70 asc:c,0 (da0:sbp0:0:0:0): Write error (da0:sbp0:0:0:0): Retrying Command (per Sense Data) (da0:sbp0:0:0:0): WRITE(10). CDB: 2a 0 0 48 9c d1 0 0 20 0 (da0:sbp0:0:0:0): CAM Status: SCSI Status Error (da0:sbp0:0:0:0): SCSI Status: Check Condition (da0:sbp0:0:0:0): MEDIUM ERROR csi:70,70,70,70 asc:c,0 (da0:sbp0:0:0:0): Write error (da0:sbp0:0:0:0): Retrying Command (per Sense Data) ... (da0:sbp0:0:0:0): WRITE(10). CDB: 2a 0 0 49 c d1 0 0 20 0 (da0:sbp0:0:0:0): CAM Status: SCSI Status Error (da0:sbp0:0:0:0): SCSI Status: Check Condition (da0:sbp0:0:0:0): MEDIUM ERROR csi:70,70,70,70 asc:c,0 (da0:sbp0:0:0:0): Write error (da0:sbp0:0:0:0): Retrying Command (per Sense Data) (da0:sbp0:0:0:0): WRITE(10). CDB: 2a 0 0 82 7d 31 0 0 20 0 (da0:sbp0:0:0:0): CAM Status: SCSI Status Error (da0:sbp0:0:0:0): SCSI Status: Check Condition (da0:sbp0:0:0:0): MEDIUM ERROR csi:70,70,70,70 asc:c,0 (da0:sbp0:0:0:0): Write error (da0:sbp0:0:0:0): Retrying Command (per Sense Data) (12:17:05) root@coyote: ~# gmirror rebuild gm1 da0s2 GEOM_MIRROR: Device gm1: provider da0s2 disconnected. GEOM_MIRROR: Device gm1: provider da0s2 detected. GEOM_MIRROR: Device gm1: rebuilding provider da0s2. (12:17:11) root@coyote: ~# gmirror status Name Status Components mirror/gm2 DEGRADED ad1 da1 (21%) mirror/gm0 COMPLETE ad0s1 da0s1 mirror/gm1 DEGRADED ad0s2 da0s2 (0%) (da0:sbp0:0:0:0): WRITE(10). CDB: 2a 0 2 3a e6 9 0 0 80 0 (da0:sbp0:0:0:0): CAM Status: SCSI Status Error (da0:sbp0:0:0:0): SCSI Status: Check Condition (da0:sbp0:0:0:0): MEDIUM ERROR csi:70,70,70,70 asc:c,0 (da0:sbp0:0:0:0): Write error (da0:sbp0:0:0:0): Retrying Command (per Sense Data) sbp0:0:0 request timeout(cmd orb:0x1a6029dc) ... agent reset sbp0:0:0 request timeout(cmd orb:0x1a602b14) ... target reset sbp0:0:0 request timeout(mgm orb:0x1a602c4c) ... reset start fwohci0: txd err=14 ack busy_X sbp0:0:0 sbp_reset_start failed: resp=16 >From here on, no login is possible, but I'm still listening to MP3 served from gm1 via NFS (read only, due to noatime). My /home partition is on gm1, too. The system itself resides on gm0. gm2 can also be accessd just fine. An NFS mount request to gm0 never comes back, however. The rebuild of gm2 is also still going on. Two questions remain: Why on earth is sbp(4) starting to spit write errors? The drive is ok, the rebuild is also not complaining about write errors. Could there be some race or bus starvation that leads to the write command timing out? Why is this not appearing if I rebuild all mirrors sequentially? Is the firewire controller crap? And then I'd assume if gmirror is no longer able to write to one of its components, that it kicks it out of the mirror and continues with the other good device. Or is that only possible to detect during failed reads? Here's some ddb(4) output, but I guess it's not helpful KDB: enter: Break sequence on console [thread pid 10 tid 100006 ] Stopped at kdb_enter+0x30: leave db> show pcpu cpuid = 0 curthread = 0xc3237600: pid 10 "idle" curpcb = 0xd4051d90 fpcurthread = none idlethread = 0xc3237600: pid 10 "idle" APIC ID = 0 currentldt = 0x50 spin locks held: db> show locks db> show alllocks db> show lockedvnods Locked vnodes 0xc3621570: tag ufs, type VDIR usecount 1, writecount 0, refcount 144 mountedhere 0 flags (VV_ROOT) lock type ufs: EXCL (count 1) by thread 0xc3c15a80 (pid 29986) with 142 pending#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05ba64a at vget+0xee #5 0xc05b0934 at vfs_hash_get+0xdc #6 0xc06b8343 at ffs_vget+0x49 #7 0xc06c3338 at ufs_root+0x28 #8 0xc05b21c2 at lookup+0x8c9 #9 0xc05b15f0 at namei+0x449 #10 0xc05c7a18 at vn_open_cred+0x2af #11 0xc05c7767 at vn_open+0x33 #12 0xc05bfaa0 at kern_open+0x2b4 #13 0xc05bf7b4 at open+0x36 #14 0xc07294e9 at syscall+0x2d1 #15 0xc07142df at Xint0x80_syscall+0x1f ino 2, on dev mirror/gm0d 0xc3621414: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xc332fa80 (pid 50)#0 0xc0544b0e at lockmgr+0x566 #1 0xc05af7a3 at vop_stdlock+0x32 #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05b9c1d at sync_vnode+0x134 #5 0xc05b9f2f at sched_sync+0x23d #6 0xc0539ab3 at fork_exit+0xc2 #7 0xc07142ec at fork_trampoline+0x8 0xc362fd98: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc3c14180 (pid 29985) with 1 pending#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05ba64a at vget+0xee #5 0xc05aca3c at cache_lookup+0x3d0 #6 0xc05ad05d at vfs_cache_lookup+0xa4 #7 0xc073cb2f at VOP_LOOKUP_APV+0xa6 #8 0xc05b1e33 at lookup+0x53a #9 0xc05b15f0 at namei+0x449 #10 0xc05c7a18 at vn_open_cred+0x2af #11 0xc05c7767 at vn_open+0x33 #12 0xc05bfaa0 at kern_open+0x2b4 #13 0xc05bf7b4 at open+0x36 #14 0xc07294e9 at syscall+0x2d1 #15 0xc07142df at Xint0x80_syscall+0x1f ino 164864, on dev mirror/gm0d 0xc382b828: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xc378ece4 ref 0 pages 11 lock type ufs: EXCL (count 1) by thread 0xc345a180 (pid 719)#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05c3e12 at fsync+0xc0 #5 0xc07294e9 at syscall+0x2d1 #6 0xc07142df at Xint0x80_syscall+0x1f ino 118536, on dev mirror/gm0d 0xc3831d98: tag ufs, type VREG usecount 0, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc3789dec ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc3c15780 (pid 29983)#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05c7d34 at vn_close+0x7a #5 0xc05c8d77 at vn_closefile+0xee #6 0xc052f9b4 at fdrop_locked+0xef #7 0xc052f8bf at fdrop+0x3c #8 0xc052ddb2 at closef+0x426 #9 0xc052af69 at kern_close+0x226 #10 0xc052ad41 at close+0x1a #11 0xc07294e9 at syscall+0x2d1 #12 0xc07142df at Xint0x80_syscall+0x1f ino 70921, on dev mirror/gm0d 0xc3870c3c: tag ufs, type VREG usecount 0, writecount 0, refcount 8 mountedhere 0 flags () v_object 0xc3821d68 ref 0 pages 325 lock type ufs: EXCL (count 1) by thread 0xc332fa80 (pid 50)#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05ba64a at vget+0xee #5 0xc05bbecb at vfs_msync+0xf5 #6 0xc05bc79d at sync_fsync+0x1d8 #7 0xc073e1fa at VOP_FSYNC_APV+0xc4 #8 0xc05b9c43 at sync_vnode+0x15a #9 0xc05b9f2f at sched_sync+0x23d #10 0xc0539ab3 at fork_exit+0xc2 #11 0xc07142ec at fork_trampoline+0x8 ino 189547, on dev mirror/gm0d 0xc3874828: tag ufs, type VREG usecount 0, writecount 0, refcount 10 mountedhere 0 flags () v_object 0xc3821738 ref 0 pages 844 lock type ufs: EXCL (count 1) by thread 0xc345c600 (pid 748)#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05c7d34 at vn_close+0x7a #5 0xc05c8d77 at vn_closefile+0xee #6 0xc052f9b4 at fdrop_locked+0xef #7 0xc052f8bf at fdrop+0x3c #8 0xc052ddb2 at closef+0x426 #9 0xc052af69 at kern_close+0x226 #10 0xc052ad41 at close+0x1a #11 0xc07294e9 at syscall+0x2d1 #12 0xc07142df at Xint0x80_syscall+0x1f ino 189548, on dev mirror/gm0d 0xc38fe984: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc3f91a80 (pid 29984) with 1 pending#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05ba64a at vget+0xee #5 0xc05aca3c at cache_lookup+0x3d0 #6 0xc05ad05d at vfs_cache_lookup+0xa4 #7 0xc073cb2f at VOP_LOOKUP_APV+0xa6 #8 0xc05b1e33 at lookup+0x53a #9 0xc05b15f0 at namei+0x449 #10 0xc05c77c4 at vn_open_cred+0x5b #11 0xc05c7767 at vn_open+0x33 #12 0xc05bfaa0 at kern_open+0x2b4 #13 0xc05bf7b4 at open+0x36 #14 0xc07294e9 at syscall+0x2d1 #15 0xc07142df at Xint0x80_syscall+0x1f ino 211976, on dev mirror/gm0d 0xc3acac3c: tag ufs, type VREG usecount 0, writecount 0, refcount 9 mountedhere 0 flags () v_object 0xc3b8e210 ref 0 pages 56 lock type ufs: EXCL (count 1) by thread 0xc3935000 (pid 1205)#0 0xc0544b0e at lockmgr+0x566 #1 0xc06b98d3 at ffs_lock+0x8a #2 0xc073f176 at VOP_LOCK_APV+0xa6 #3 0xc05c8c00 at vn_lock+0xd3 #4 0xc05c7d34 at vn_close+0x7a #5 0xc05c8d77 at vn_closefile+0xee #6 0xc052f9b4 at fdrop_locked+0xef #7 0xc052f8bf at fdrop+0x3c #8 0xc052ddb2 at closef+0x426 #9 0xc052af69 at kern_close+0x226 #10 0xc052ad41 at close+0x1a #11 0xc07294e9 at syscall+0x2d1 #12 0xc07142df at Xint0x80_syscall+0x1f ino 141531, on dev mirror/gm0d 0xc3e2d15c: tag ufs, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc3f91a80 (pid 29984)#0 0xc0544b0e at lockmgr+0x566 #1 0xc05b0a48 at vfs_hash_insert+0x36 #2 0xc06b84ac at ffs_vget+0x1b2 #3 0xc0698877 at ffs_valloc+0x12f #4 0xc06c6c6a at ufs_makeinode+0x74 #5 0xc06c3682 at ufs_create+0x36 #6 0xc073cd7d at VOP_CREATE_APV+0xc4 #7 0xc05c7933 at vn_open_cred+0x1ca #8 0xc05c7767 at vn_open+0x33 #9 0xc05bfaa0 at kern_open+0x2b4 #10 0xc05bf7b4 at open+0x36 #11 0xc07294e9 at syscall+0x2d1 #12 0xc07142df at Xint0x80_syscall+0x1f ino 212371, on dev mirror/gm0d I then plugged in my laptop into the same Firewire bus and the reset unwedged the whole situation fwohci0: BUS reset fwohci0: node_id=0xc800ffc3, gen=6, CYCLEMASTER mode firewire0: 4 nodes, maxhop <= 2, cable IRM = 3 (me) firewire0: bus manager 3 (me) firewire0: New S400 device ID:354fc00035679830 firewire0: split transaction timeout dst=0xffc1 tl=0x3a state=3 firewire0: split transaction timeout dst=0xffc1 tl=0x0 state=3 firewire0: split transaction timeout dst=0xffc1 tl=0x1 state=3 (da0:sbp0:0:0:0): lost device GEOM_MIRROR: Request failed (error=6). da0s1[WRITE(offset=998121GEOM_MIRROR: Synchronization request failed (error=22). da0s2[WRITE(offset=2763128472, length=16384)] GEOM_MIRROR: Device gm0: provider da0s1 disconnected. 832, length=131072)] GEOM_MIRROR: Device gm1: provider da0s2 disconnected. GEOM_MIRROR: Device gm1: rebuilding provider da0s2 stopped. (da0:sbp0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 (da0:sbp0:0:0:0): removing device entry Please note that I'm using hw.firewire.hold_count=0 so the manual reset shouldn't be necessary, should it? The system would still hang while shutting down, though GEOM_MIRROR: Device gm2: rebuilding provider da1 stopped. Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...13 13 7 2 5 3 3 1 1 0 0 0 0 done All buffers synced. sbp0:1:0 request timeout(cmd orb:0x1195d28c) ... agent reset fwohci0: txd err=1e ack type_err sbp0:1:0 sbp_agent_reset_callback: resp=22 fwohci0: txd err=1e ack type_err sbp_orb_pointer_callback: xfer->resp = 22 sbp0:1:0 request timeout(cmd orb:0x1195d3c4) ... target reset fwohci0: txd err=1e ack type_err sbp0:1:0 sbp_agent_reset_callback: resp=22 fwohci0: txd err=1e ack type_err sbp_orb_pointer_callback: xfer->resp = 22 sbp0:1:0 request timeout(cmd orb:0x1195d634) ... reset start < here I unplugged my laptop again > Uptime: 2h57m3s fwohci0: BUS reset fwohci0: node_id=0xc800ffc2, gen=8, CYCLEMASTER mode firewire0: 3 nodes, maxhop <= 2, cable IRM = 2 (me) firewire0: bus manager 2 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc2, gen=8, CYCLEMASTER mode firewire0: 3 nodes, maxhop <= 2, cable IRM = 2 (me) firewire0: bus manager 2 (me) GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. GEOM_MIRROR: Device gm0 destroyed. Powering system off using ACPI Anything I can do to help debugging this Firewire issue? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:57:12 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02DAB16A41B for ; Fri, 28 Dec 2007 12:57:12 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id AB8C013C45B for ; Fri, 28 Dec 2007 12:57:11 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 996F92218824; Fri, 28 Dec 2007 23:41:52 +1100 (EST) X-Viruscan-Id: <4774EF10000134DF83BB7B@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 5BA5521B1658; Fri, 28 Dec 2007 23:41:52 +1100 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 09A192218808; Fri, 28 Dec 2007 23:41:52 +1100 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id AC7FB2ED; Fri, 28 Dec 2007 23:41:51 +1100 (EST) Date: Fri, 28 Dec 2007 23:41:51 +1100 From: Edwin Groothuis To: Johan Str?m Message-ID: <20071228124151.GA37323@k7.mavetju> Mail-Followup-To: Edwin Groothuis , Johan Str?m , freebsd-stable@freebsd.org References: <91064C44-1A41-4FCB-A718-1EF3A63E2273@stromnet.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91064C44-1A41-4FCB-A718-1EF3A63E2273@stromnet.se> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: I just broke out of a FreeBSD jail.. Known bug?? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 12:57:12 -0000 On Fri, Dec 28, 2007 at 01:15:38PM +0100, Johan Str?m wrote: > Thats my home dir on core!.. That should very much not be visible > there! I have full access now (from the wrong jail!) > > Known bug or did I just stumble upon something pretty bad?? You didn't really break out of it, the person who managed the machine did something he shouldn't have done: Moving the directories while the jail(s) were running. It should be mentioned in the BUGS section of the jail(8) command. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 14:55:51 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A05B16A41A; Fri, 28 Dec 2007 14:55:51 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id 813F013C467; Fri, 28 Dec 2007 14:55:50 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180134215.adsl.alicedsl.de [85.180.134.215]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id lBSEtmqo094815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Dec 2007 15:55:49 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id lBSEtlbp007111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2007 15:55:47 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id lBSEtlMN007110; Fri, 28 Dec 2007 15:55:47 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Fri, 28 Dec 2007 15:55:47 +0100 From: Ulrich Spoerlein To: stable@freebsd.org, Hidetoshi Shimokawa Message-ID: <20071228145547.GC1532@roadrunner.spoerlein.net> Mail-Followup-To: stable@freebsd.org, Hidetoshi Shimokawa References: <20071228125437.GB1532@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071228125437.GB1532@roadrunner.spoerlein.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: sbp(4) write error wedging GEOM mirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 14:55:51 -0000 On Fri, 28.12.2007 at 13:54:37 +0100, Ulrich Spoerlein wrote: > [Ramblings about sbp(4) wedging geom mirror] Ok, it looks like sbp(4) is off the hook. I tried the rebuilding again, this time attaching da0 via umass(4) instead of sbp(4) and while it also eventually wedges, umass can recover from this situation by its own umass0: Prolific PL-3507C USB Storage Device, rev 2.00/0.01, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_MIRROR: Component da0s1 (device gm0) broken, skipping. GEOM_MIRROR: Cannot add disk da0s1 to gm0 (error=22). GEOM_MIRROR: Component da0s2 (device gm1) broken, skipping. GEOM_MIRROR: Cannot add disk da0s2 to gm1 (error=22). GEOM_MIRROR: Component da0s1 (device gm0) broken, skipping. GEOM_MIRROR: Cannot add disk da0s1 to gm0 (error=22). GEOM_MIRROR: Component da0s1 (device gm0) broken, skipping. GEOM_MIRROR: Cannot add disk da0s1 to gm0 (error=22). GEOM_MIRROR: Device gm0: provider da0s1 detected. GEOM_MIRROR: Device gm0: provider da0s1 is stale. GEOM_MIRROR: Device gm1: provider da0s2 detected. GEOM_MIRROR: Device gm1: provider da0s2 is stale. GEOM_MIRROR: Device gm0: provider da0s1 disconnected. GEOM_MIRROR: Device gm0: provider da0s1 detected. GEOM_MIRROR: Device gm0: rebuilding provider da0s1. fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=2, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) fwohci0: txd err=14 ack busy_X fwohci0: txd err=14 ack busy_X fwohci0: txd err=14 ack busy_X fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=3, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) firewire0: New S400 device ID:0050770e013023f0 da1 at sbp0 bus 0 target 0 lun 0 da1: Fixed Simplified Direct Access SCSI-4 device da1: 50.000MB/s transfers da1: 381554MB (781422768 512 byte sectors: 255H 63S/T 48641C) GEOM_MIRROR: Device gm2: provider da1 detected. GEOM_MIRROR: Device gm2: rebuilding provider da1. GEOM_MIRROR: Device gm0: rebuilding provider da0s1 finished. GEOM_MIRROR: Device gm0: provider da0s1 activated. GEOM_MIRROR: Device gm1: provider da0s2 disconnected. GEOM_MIRROR: Device gm1: provider da0s2 detected. GEOM_MIRROR: Device gm1: rebuilding provider da0s2. (14:08:27) root@coyote: ~# gmirror status umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR GEOM_MIRROR: CannotGEOM_MIRROR: Synchronization request failed (error=5). da0s2[WRITE(offset=23111270 write metadata on da0s1 (device=gm0, error=5). GEOM_MIRROR: Cannot update metada400, length=131072)] GEOM_MIRROR: Device gm1: provider da0s2 disconnected. GEOta on disk da0s1 (error=5). M_MIRROR: Device gm1: rebuilding provider da0s2 stopped. GEOM_MIRROR: Device gm0: provider da0s1 disconnected. umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR Expumass0: BBB reset failed, IOERROR eumass0: BBB bulk-in clear stall failed, IOERROR nsumass0: BBB bulk-out clear stall failed, IOERROR ive timeout(9) function: 0xc09623a9(0xc32de800) 0.006188295 s umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR ... (multiple pages) umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR ... (multiple pages) umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR Name Status Components mirror/gm2 DEGRADED ad1 da1 (12%) mirror/gm0 DEGRADED ad0s1 mirror/gm1 DEGRADED ad0s2 (14:14:46) root@coyote: ~# (14:14:46) root@coyote: ~# gmirror status Name Status Components mirror/gm2 DEGRADED ad1 da1 (16%) mirror/gm0 DEGRADED ad0s1 mirror/gm1 DEGRADED ad0s2 (14:41:22) root@coyote: ~# fdisk -s /dev/da0 umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR Expensive timeout(9) function: 0xc0690e74(0xc342a000) 0.007737115 s umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR fdisk: can't open device /dev/da0 fdisk: cannot open disk /dev/da0: Input/output error Exit 1 (14:41:54) root@coyote: ~# camcontrol rescan 1 umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry Re-scan of bus 1 was successful So as you can see, after lots of stalled transfers GEOM mirror will do the right thing and kick out the failing components. Something it cannot do when it is attached via sbp(4). Is this behaviour of sbp(4) tweakable? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 18:29:25 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AF4B16A418 for ; Fri, 28 Dec 2007 18:29:25 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from xm20.infosec.fedex.com (xm20.infosec.fedex.com [199.81.217.42]) by mx1.freebsd.org (Postfix) with ESMTP id 49E7F13C45D for ; Fri, 28 Dec 2007 18:29:25 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) X-AuditID: c751825c-a97babb000000719-e8-47753949c843 Received: from inet03.prod.fedex.com (inet03.prod.fedex.com [199.81.10.43]) by xm20.infosec.fedex.com (FedEx MX) with ESMTP id 6238D4E4004 for ; Fri, 28 Dec 2007 11:58:33 -0600 (CST) Received: from w10.sac.fedex.com (w10.sac.fedex.com [146.18.39.136]) by inet03.prod.fedex.com (8.12.11/8.12.11) with ESMTP id lBSHwWLY026489 for ; Fri, 28 Dec 2007 11:58:33 -0600 (CST) Received: from w10.sac.fedex.com (gcr@localhost [127.0.0.1]) by w10.sac.fedex.com (8.14.2/8.14.2) with ESMTP id lBSHwWOK091846 for ; Fri, 28 Dec 2007 11:58:32 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by w10.sac.fedex.com (8.14.2/8.14.2/Submit) with ESMTP id lBSHwWML091843 for ; Fri, 28 Dec 2007 11:58:32 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Fri, 28 Dec 2007 11:58:32 -0600 (CST) From: Greg Rivers Sender: gcr@sac.fedex.com To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 1.00 (BSF 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== Subject: No more geom_gpt.ko ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 18:29:25 -0000 The kernel module for GPT(8) partition tables is not present in RELENG_7 as it was in RELENG_6. Is "options GEOM_PART_GPT" now mandatory in the kernel config, or is not building the kernel module an oversight? -- Greg From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 18:57:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C6A16A418 for ; Fri, 28 Dec 2007 18:57:23 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id C283A13C458 for ; Fri, 28 Dec 2007 18:57:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id lBSIlAaN013006; Fri, 28 Dec 2007 10:47:11 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id lBSIl906023921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Dec 2007 10:47:10 -0800 (PST) Message-Id: <4829D397-864E-42BB-8EB2-B1CA8CFBEDF3@mac.com> From: Marcel Moolenaar To: Greg Rivers 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 v915) Date: Fri, 28 Dec 2007 10:47:09 -0800 References: X-Mailer: Apple Mail (2.915) Cc: freebsd-stable@freebsd.org Subject: Re: No more geom_gpt.ko ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 18:57:23 -0000 On Dec 28, 2007, at 9:58 AM, Greg Rivers wrote: > The kernel module for GPT(8) partition tables is not present in > RELENG_7 as it was in RELENG_6. Is "options GEOM_PART_GPT" now > mandatory in the kernel config, or is not building the kernel module > an oversight? Building modules is forthcoming. It will be in 7.1... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 20:35:04 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BCDD16A417 for ; Fri, 28 Dec 2007 20:35:04 +0000 (UTC) (envelope-from dave@syix.com) Received: from mail01.syix.com (mail01.syix.com [209.77.112.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0026413C46B for ; Fri, 28 Dec 2007 20:35:03 +0000 (UTC) (envelope-from dave@syix.com) X-Virus-Scanned: amavisd-new at syix.com Received: from asian (asian.syix.com [209.77.113.38]) (Authenticated sender: dave) by mail01.syix.com (Postfix) with ESMTP id 5B64434F04C for ; Fri, 28 Dec 2007 12:35:01 -0800 (PST) From: "Dave Overton" To: References: <006f01c848bd$cbcda550$26714dd1@syix.com> Date: Fri, 28 Dec 2007 12:35:01 -0800 Organization: SYIX.COM Message-ID: <00f001c84991$1eb25b70$26714dd1@syix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <006f01c848bd$cbcda550$26714dd1@syix.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchIvcuUiUcrpeJoQreoNd2P46xwSwA0t/bQ Subject: RE: portaudit and portsnap acting silly. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dave@syix.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:35:04 -0000 Fixed. For reference, it was squid, happily caching the data for me. Makes one wonder why the portsnap and portaudit servers or clients aren't http compliant if they use http protocols... Especially since the author of portsnap suggests a cache server for speed.... Oh well... Dave Overton, Owner SYIX.COM dave@syix.com (530) 755-1751 x101 Fax (530) 751-8871 800-988-SYIX > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Dave Overton > Sent: Thursday, December 27, 2007 11:22 AM > To: freebsd-stable@freebsd.org > Subject: portaudit and portsnap acting silly. > > Portaudit does this: > # portaudit -Fa > auditfile.tbz 100% of 46 kB > 6001 kBps > portaudit: Database too old. > Old database restored. > portaudit: Download failed. > > > Portsnap does this: > # portsnap fetch > Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. > Fetching snapshot tag from portsnap3.FreeBSD.org... done. > Latest snapshot on server is older than what we already have! > Cowardly refusing to downgrade from Thu Dec 27 08:10:58 PST > 2007 to Mon Dec 3 17:04:28 PST 2007. > > > In case anyone knows anyone who can beat them back into submission. > > Dave Overton, Owner > SYIX.COM > > dave@syix.com > (530) 755-1751 x101 > Fax (530) 751-8871 > 800-988-SYIX > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 20:59:27 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94FFA16A41A for ; Fri, 28 Dec 2007 20:59:27 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id 5E06C13C467 for ; Fri, 28 Dec 2007 20:59:27 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from [192.168.1.103] (unknown [64.119.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mbutler-d620.vericept.com", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTP id 44EF060D3 for ; Fri, 28 Dec 2007 15:59:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1198875566; bh=AcoHTCN/ys4VYQ ACw3efBg5COpqySx69ZhL/ljr8OLA=; h=DomainKey-Signature:Message-ID: Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version: Content-Type:Content-Transfer-Encoding; b=blkDdRruQkh7Q6ZAH+MvKXvH eV96MI66Tmv/s2/h+33O+N5x3mnqSMUvncdPIVTBochjC5475v4DLItqEr4bWv09DW0 Dq/MEhzMTqc/2Dva5+xtgorhL9Zs6cUE2iJa+ DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:content-type:content-transfer-encoding; b=buls8v+LSYBHW6BENCZq4IinmDtIk5/TM3OzCZ/0tpaOR4SWV5zlT2Y8TbOBabzxh LilumYY66ZRDxoxM/rK8VCRLPQEDdfTQLJFEFl+F3hB/qvhQdwlNh3vcTABTWfX Message-ID: <477563B6.50307@protected-networks.net> Date: Fri, 28 Dec 2007 15:59:34 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: tiny GSS nit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:59:27 -0000 On 7-stable, /usr/lib contains .. imb@toshi:/home/imb> ll /usr/lib/libgssapi* -r--r--r-- 1 root wheel 57358 Dec 14 12:46 /usr/lib/libgssapi.a lrwxr-xr-x 1 root wheel 14 Dec 19 16:50 /usr/lib/libgssapi.so -> libgssapi.so.9 -r--r--r-- 1 root wheel 28040 Dec 19 16:50 /usr/lib/libgssapi.so.9 -r--r--r-- 1 root wheel 95148 Dec 17 23:07 /usr/lib/libgssapi_krb5.a lrwxr-xr-x 1 root wheel 19 Dec 19 16:50 /usr/lib/libgssapi_krb5.so -> libgssapi_krb5.so.9 -r--r--r-- 1 root wheel 54756 Dec 19 16:50 /usr/lib/libgssapi_krb5.so.9 -r--r--r-- 1 root wheel 97316 Dec 8 10:47 /usr/lib/libgssapi_krb5_p.a -r--r--r-- 1 root wheel 59424 Dec 4 08:44 /usr/lib/libgssapi_p.a .. but /etc/gss/mech contains this from /usr/src/etc/gss/mech .. imb@toshi:/home/imb> less /usr/src/etc/gss/mech # $FreeBSD: src/etc/gss/mech,v 1.1 2005/12/29 14:40:18 dfr Exp $ # # Name OID Library name Kernel module kerberosv5 1.2.840.113554.1.2.2 /usr/lib/libgssapi_krb5.so.8 - It needs a version bump - dunno if -current needs the same .. Michael From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 23:29:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B8A16A41B for ; Fri, 28 Dec 2007 23:29:57 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 0CC0F13C448 for ; Fri, 28 Dec 2007 23:29:56 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2631043fgg.35 for ; Fri, 28 Dec 2007 15:29:55 -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=Fl69JmnwoKEXvgGpJzXq1zUOtildi9XukMPwpcCn0ko=; b=xRVJgr/Yy6EXW9pn1hbai9mPzSjvuIq5HW+5qaa2DXOK3nrbZInJIGvTGuYKF+2MRB0UY5oQJlpD9MDQ/pIzufw4XQCEW6LW0UOwQw6LeCHuejKf3zoGEq0NEMe5e6PqhtH97+WbuiDfGIlJlXxPJOj7aJO6ABmPeH2RxBq4s7k= 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=nIV7QLGtE9GQuSriCu63CJmfQLbKqEEgc3Eoye+2VNfbF58cdMSsKcAhVHZuul091OD4HOGIGHAjx2qmdcPGJX07AqjicvX3VHGFead4qHOasOXmr2+rGegtjjPAlqURiNgLIou7+gjItFz9gBba+H5Jy0vuxCo5X+ybb/33TY4= Received: by 10.86.28.5 with SMTP id b5mr9403954fgb.79.1198884595782; Fri, 28 Dec 2007 15:29:55 -0800 (PST) Received: by 10.86.68.13 with HTTP; Fri, 28 Dec 2007 15:29:55 -0800 (PST) Message-ID: <790a9fff0712281529q5aafb58ay4582f47cb6bd3cbd@mail.gmail.com> Date: Fri, 28 Dec 2007 17:29:55 -0600 From: "Scot Hetzel" To: "Michael Butler" In-Reply-To: <477563B6.50307@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477563B6.50307@protected-networks.net> Cc: freebsd-stable@freebsd.org Subject: Re: tiny GSS nit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 23:29:57 -0000 On 12/28/07, Michael Butler wrote: > On 7-stable, /usr/lib contains .. > > imb@toshi:/home/imb> ll /usr/lib/libgssapi* : > -r--r--r-- 1 root wheel 54756 Dec 19 16:50 /usr/lib/libgssapi_krb5.so.9 : > .. but /etc/gss/mech contains this from /usr/src/etc/gss/mech .. > > imb@toshi:/home/imb> less /usr/src/etc/gss/mech > # $FreeBSD: src/etc/gss/mech,v 1.1 2005/12/29 14:40:18 dfr Exp $ > # > # Name OID Library name > Kernel module > kerberosv5 1.2.840.113554.1.2.2 /usr/lib/libgssapi_krb5.so.8 - > > It needs a version bump - dunno if -current needs the same .. > This change has already been made to -CURRENT, it just needs to be MFC'd to 7-STABLE. Scot From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 19:39:58 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD3D16A420 for ; Sat, 29 Dec 2007 19:39:58 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.freebsd.org (Postfix) with ESMTP id A464813C457 for ; Sat, 29 Dec 2007 19:39:55 +0000 (UTC) (envelope-from frank@exit.com) Received: from jill.exit.com (jill.exit.com [206.223.0.4]) by tinker.exit.com (8.14.1/8.14.1) with ESMTP id lBTJRKwt076656 for ; Sat, 29 Dec 2007 11:27:20 -0800 (PST) (envelope-from frank@exit.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exit.com; s=tinker; t=1198956440; bh=UKOV3QtQEA2gD6jC4RWbplM+rij7s6Jm/xOaJdOgLSc=; h=X-Authentication-Warning:Subject:From:Reply-To:To:Content-Type: Organization:Date:Message-Id:Mime-Version:X-Mailer; b=kZXwcMj594+q WJ3Vn4WQkjwGsJzYaUweZwOzmua6B7aNFew7OzZ1C2d+iaxFcGrmBK8p0rpuQOhxYDG kdwAMZrxbEqiGXTzrfOhOOBCLgslWqLF0UkMMDkF1zO965CoV5qym5YMxU/JlTaFJy7 zGhKYX9dSvLAebjHzOx3aP4Ew= Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.14.2/8.14.1) with ESMTP id lBTJSIVs003629 for ; Sat, 29 Dec 2007 11:28:18 -0800 (PST) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.14.2/8.14.2/Submit) id lBTJSIiq003628 for stable@freebsd.org; Sat, 29 Dec 2007 11:28:18 -0800 (PST) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: stable@freebsd.org Content-Type: multipart/mixed; boundary="=-6cmc0M+yL53x5izSzaGB" Organization: Exit Consulting Date: Sat, 29 Dec 2007 11:28:18 -0800 Message-Id: <1198956498.2124.6.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Cc: Subject: panic: vm_page_unwire: invalid wire count: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 19:39:58 -0000 --=-6cmc0M+yL53x5izSzaGB Content-Type: text/plain Content-Transfer-Encoding: 7bit This is on a very recent -stable (like, as of just a couple of days ago). Doing nothing in particular, ZERO_COPY_SOCKETS _not_ specified in the config. This has happened twice this morning; if it happens again I'll drop back to my older kernel, built back in May. I've attached my config and dmesg; the stack trace is here: #20 0xffffffff80273e73 in doadump () at /usr/src/sys/kern/kern_shutdown.c:243 #21 0xffffffff80274485 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #22 0xffffffff80274b95 in panic (fmt=0xffffff005488f000 "") at /usr/src/sys/kern/kern_shutdown.c:565 #23 0xffffffff803b4f9b in vm_page_unwire (m=0xffffff007d61f308, activate=2118678981) at /usr/src/sys/vm/vm_page.c:1275 #24 0xffffffff802cf366 in vfs_vmio_release (bp=0xffffffffa18fdf88) at /usr/src/sys/kern/vfs_bio.c:1489 #25 0xffffffff802d2a76 in getnewbuf (slpflag=0, slptimeo=0, size=0, maxsize=16384) at /usr/src/sys/kern/vfs_bio.c:1798 #26 0xffffffff802d2eb4 in getblk (vp=0xffffff007a7431f0, blkno=0, size=2048, slpflag=0, slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2516 #27 0xffffffff802d496c in breadn (vp=0xffffff007a7431f0, blkno=107449315523013, size=0, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x61b97e48a90e) at /usr/src/sys/kern/vfs_bio.c:742 #28 0xffffffff802d4dae in bread (vp=0xa, blkno=107449315523013, size=0, cred=0x61b97e48cf58, bpp=0xffffff005488f000) at /usr/src/sys/kern/vfs_bio.c:723 #29 0xffffffff8038514c in ffs_blkatoff (vp=0xa, offset=0, res=0x0, bpp=0xffffffffb5ae4690) at /usr/src/sys/ufs/ffs/ffs_subr.c:87 #30 0xffffffff80391aa2 in ufs_lookup (ap=0xffffffffb5ae4780) at /usr/src/sys/ufs/ufs/ufs_lookup.c:259 #31 0xffffffff80426aba in VOP_CACHEDLOOKUP_APV (vop=0x61b97e48a90e, a=0x61b97e4879c5) at vnode_if.c:150 #32 0xffffffff802d6730 in vfs_cache_lookup (ap=0xa) at vnode_if.h:82 #33 0xffffffff804277fe in VOP_LOOKUP_APV (vop=0xffffffff805b7000, a=0xffffffffb5ae4880) at vnode_if.c:99 #34 0xffffffff802db19b in lookup (ndp=0xffffffffb5ae4990) at vnode_if.h:56 #35 0xffffffff802dbf4b in namei (ndp=0xffffffffb5ae4990) at /usr/src/sys/kern/vfs_lookup.c:216 #36 0xffffffff802eda9b in kern_lstat (td=0xffffff005488f000, path=0x61b97e4879c5
, pathseg=UIO_USERSPACE, sbp=0xffffffffb5ae4af0) at /usr/src/sys/kern/vfs_syscalls.c:2127 #37 0xffffffff802edf5a in lstat (td=0xa, uap=0xffffffffb5ae4bc0) at /usr/src/sys/kern/vfs_syscalls.c:2110 #38 0xffffffff803dea02 in syscall (frame= {tf_rdi = 8049928, tf_rsi = 7588984, tf_rdx = 4407994, tf_rcx = 0, tf_r8 = 410, tf_r9 = 0, tf_rax = 190, tf_rbx = 10, tf_rbp = 7589160, tf_r10 = 6625968, tf_r11 = 8044136, tf_r12 = 140737488350360, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0, tf_trapno = 22, tf_addr = 0, tf_flags = 7588928, tf_err = 2, tf_rip = 1084076476, tf_cs = 43, tf_rflags = 582, tf_rsp = 7588944, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:807 #39 0xffffffff803c4d98 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:287 I'm happy to provide any other information requested. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* --=-6cmc0M+yL53x5izSzaGB Content-Disposition: attachment; filename=dmesg.boot Content-Type: text/plain; name=dmesg.boot; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgNi4zLVBSRVJFTEVBU0UgIzg6IFRodSBEZWMg MjcgMTU6MzQ6NTYgUFNUIDIwMDcNCiAgICByb290QGppbGwuZXhpdC5jb206L3Vzci9vYmovdXNy L3NyYy9zeXMvSklMTA0KQUNQSSBBUElDIFRhYmxlOiA8QSBNIEkgIE9FTUFQSUMgPg0KVGltZWNv dW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDANCkNQVTogQU1EIE9w dGVyb24odG0pIFByb2Nlc3NvciAyNDggKDIxOTAuNzItTUh6IEs4LWNsYXNzIENQVSkNCiAgT3Jp Z2luID0gIkF1dGhlbnRpY0FNRCIgIElkID0gMHgyMGY1MSAgU3RlcHBpbmcgPSAxDQogIEZlYXR1 cmVzPTB4NzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQ LE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyPg0K ICBBTUQgRmVhdHVyZXM9MHhlMDUwMDgwMDxTWVNDQUxMLE5YLE1NWCssTE0sM0ROb3chKywzRE5v dyE+DQpyZWFsIG1lbW9yeSAgPSAyMTQ3NDE4MTEyICgyMDQ3IE1CKQ0KYXZhaWwgbWVtb3J5ID0g MjA2MzYwMTY2NCAoMTk2OCBNQikNCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0g RGV0ZWN0ZWQ6IDIgQ1BVcw0KIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwDQogY3B1MSAoQVApOiBB UElDIElEOiAgMQ0KTUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZlbCB0 cmlnZ2VyIGZvciBTQ0kNCmlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVy Ym9hcmQNCmlvYXBpYzEgPFZlcnNpb24gMS4xPiBpcnFzIDI0LTI3IG9uIG1vdGhlcmJvYXJkDQpp b2FwaWMyIDxWZXJzaW9uIDEuMT4gaXJxcyAyOC0zMSBvbiBtb3RoZXJib2FyZA0Ka2JkMSBhdCBr YmRtdXgwDQphY3BpMDogPEEgTSBJIE9FTVhTRFQ+IG9uIG1vdGhlcmJvYXJkDQphY3BpMDogUG93 ZXIgQnV0dG9uIChmaXhlZCkNClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5 NTQ1IEh6IHF1YWxpdHkgMTAwMA0KYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1 NDVNSHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3BpMA0KYWNwaV9ocGV0MDogPEhpZ2ggUHJl Y2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlYzAxMDAwLTB4ZmVjMDEzZmYgb24gYWNwaTAN ClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5MDANCmNw dTA6IDxBQ1BJIENQVT4gb24gYWNwaTANCmFjcGlfdGhyb3R0bGUwOiA8QUNQSSBDUFUgVGhyb3R0 bGluZz4gb24gY3B1MA0KY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhv c3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjANCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYu MCBvbiBwY2kwDQpwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQ0Kb2hjaTA6IDxPSENJIChn ZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmVhZmMwMDAtMHhmZWFmY2ZmZiBpcnEgMTkg YXQgZGV2aWNlIDAuMCBvbiBwY2kzDQpvaGNpMDogW0dJQU5ULUxPQ0tFRF0NCnVzYjA6IE9IQ0kg dmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0DQp1c2IwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNv bnRyb2xsZXI+IG9uIG9oY2kwDQp1c2IwOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMDogQU1EIE9I Q0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxDQp1aHViMDogMyBw b3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCm9oY2kxOiA8T0hDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZlYWZkMDAwLTB4ZmVhZmRmZmYgaXJxIDE5IGF0IGRl dmljZSAwLjEgb24gcGNpMw0Kb2hjaTE6IFtHSUFOVC1MT0NLRURdDQp1c2IxOiBPSENJIHZlcnNp b24gMS4wLCBsZWdhY3kgc3VwcG9ydA0KdXNiMTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9s bGVyPiBvbiBvaGNpMQ0KdXNiMTogVVNCIHJldmlzaW9uIDEuMA0KdWh1YjE6IEFNRCBPSENJIHJv b3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQ0KdWh1YjE6IDMgcG9ydHMg d2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpvaGNpMjogPE5FQyB1UEQgOTIxMCBVU0Ig Y29udHJvbGxlcj4gbWVtIDB4ZmVhZmEwMDAtMHhmZWFmYWZmZiBpcnEgMTYgYXQgZGV2aWNlIDQu MCBvbiBwY2kzDQpvaGNpMjogW0dJQU5ULUxPQ0tFRF0NCnVzYjI6IE9IQ0kgdmVyc2lvbiAxLjAN CnVzYjI6IDxORUMgdVBEIDkyMTAgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kyDQp1c2IyOiBVU0Ig cmV2aXNpb24gMS4wDQp1aHViMjogTkVDIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEu MDAvMS4wMCwgYWRkciAxDQp1aHViMjogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQNCm9oY2kzOiA8TkVDIHVQRCA5MjEwIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZWFmYjAw MC0weGZlYWZiZmZmIGlycSAxNyBhdCBkZXZpY2UgNC4xIG9uIHBjaTMNCm9oY2kzOiBbR0lBTlQt TE9DS0VEXQ0KdXNiMzogT0hDSSB2ZXJzaW9uIDEuMA0KdXNiMzogPE5FQyB1UEQgOTIxMCBVU0Ig Y29udHJvbGxlcj4gb24gb2hjaTMNCnVzYjM6IFVTQiByZXZpc2lvbiAxLjANCnVodWIzOiBORUMg T0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDENCnVodWIzOiAy IHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KZWhjaTA6IDxORUMgdVBEIDcy MDEwMCBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZlYWZlODAwLTB4ZmVhZmU4ZmYgaXJxIDE4 IGF0IGRldmljZSA0LjIgb24gcGNpMw0KZWhjaTA6IFtHSUFOVC1MT0NLRURdDQp1c2I0OiBFSENJ IHZlcnNpb24gMC45NQ0KdXNiNDogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAzIHBvcnRzIGVhY2g6 IHVzYjIgdXNiMw0KdXNiNDogPE5FQyB1UEQgNzIwMTAwIFVTQiAyLjAgY29udHJvbGxlcj4gb24g ZWhjaTANCnVzYjQ6IFVTQiByZXZpc2lvbiAyLjANCnVodWI0OiBORUMgRUhDSSByb290IGh1Yiwg Y2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDENCnVodWI0OiA1IHBvcnRzIHdpdGggNSBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjU6IHZlbmRvciAweDA0MDkgcHJvZHVjdCAweDAw NWEsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAyDQp1aHViNTogc2luZ2xlIHRyYW5z YWN0aW9uIHRyYW5zbGF0b3INCnVodWI1OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYg cG93ZXJlZA0KdWh1YjY6IHZlbmRvciAweDA0MDkgcHJvZHVjdCAweDAwNWEsIGNsYXNzIDkvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAzDQp1aHViNjogc2luZ2xlIHRyYW5zYWN0aW9uIHRyYW5zbGF0 b3INCnVodWI2OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdW1hc3Mw OiBQcm9saWZpYyBUZWNobm9sb2d5IEluYy4gQVRBUEktNiBCcmlkZ2UgQ29udHJvbGxlciwgcmV2 IDIuMDAvMC4wMSwgYWRkciA0DQphdGFwY2kwOiA8U2lJIFNpSSAzMTE0IFNBVEExNTAgY29udHJv bGxlcj4gcG9ydCAweGJjMDAtMHhiYzA3LDB4Yjg4MC0weGI4ODMsMHhiODAwLTB4YjgwNywweGFj MDAtMHhhYzAzLDB4YTg4MC0weGE4OGYgbWVtIDB4ZmVhZmVjMDAtMHhmZWFmZWZmZiBpcnEgMTkg YXQgZGV2aWNlIDUuMCBvbiBwY2kzDQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMA0K YXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTANCmF0YTQ6IDxBVEEgY2hhbm5lbCAyPiBv biBhdGFwY2kwDQphdGE1OiA8QVRBIGNoYW5uZWwgMz4gb24gYXRhcGNpMA0KcGNpMzogPGRpc3Bs YXksIFZHQT4gYXQgZGV2aWNlIDYuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KaXNhYjA6IDxQQ0kt SVNBIGJyaWRnZT4gYXQgZGV2aWNlIDcuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNh YjANCmF0YXBjaTE6IDxBTUQgODExMSBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgx ZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBkZXZpY2UgNy4xIG9u IHBjaTANCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxDQphdGExOiA8QVRBIGNoYW5u ZWwgMT4gb24gYXRhcGNpMQ0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgNy4y IChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2UgNy4zIChubyBk cml2ZXIgYXR0YWNoZWQpDQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAx MC4wIG9uIHBjaTANCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyDQphaGQwOiA8QWRhcHRl YyBBSUM3OTAyIFVsdHJhMzIwIFNDU0kgYWRhcHRlcj4gcG9ydCAweDgwMDAtMHg4MGZmLDB4Nzgw MC0weDc4ZmYgbWVtIDB4ZmM4ZGMwMDAtMHhmYzhkZGZmZiBpcnEgMjQgYXQgZGV2aWNlIDYuMCBv biBwY2kyDQphaGQwOiBbR0lBTlQtTE9DS0VEXQ0KYWljNzkwMjogVWx0cmEzMjAgV2lkZSBDaGFu bmVsIEEsIFNDU0kgSWQ9NywgUENJIDMzIG9yIDY2TWh6LCA1MTIgU0NCcw0KYWhkMTogPEFkYXB0 ZWMgQUlDNzkwMiBVbHRyYTMyMCBTQ1NJIGFkYXB0ZXI+IHBvcnQgMHg4ODAwLTB4ODhmZiwweDg0 MDAtMHg4NGZmIG1lbSAweGZjOGRlMDAwLTB4ZmM4ZGZmZmYgaXJxIDI1IGF0IGRldmljZSA2LjEg b24gcGNpMg0KYWhkMTogW0dJQU5ULUxPQ0tFRF0NCmFpYzc5MDI6IFVsdHJhMzIwIFdpZGUgQ2hh bm5lbCBCLCBTQ1NJIElkPTcsIFBDSSAzMyBvciA2Nk1oeiwgNTEyIFNDQnMNCmJnZTA6IDxCcm9h ZGNvbSBCQ001NzA0IEEzLCBBU0lDIHJldi4gMHgyMDAzPiBtZW0gMHhmYzgxMDAwMC0weGZjODFm ZmZmLDB4ZmM4MDAwMDAtMHhmYzgwZmZmZiBpcnEgMjQgYXQgZGV2aWNlIDkuMCBvbiBwY2kyDQpt aWlidXMwOiA8TUlJIGJ1cz4gb24gYmdlMA0KYnJncGh5MDogPEJDTTU3MDQgMTAvMTAwLzEwMDBi YXNlVFggUEhZPiBvbiBtaWlidXMwDQpicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEw MGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvDQpi Z2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDplMDo4MTozMzo3ZTo5YQ0KYmdlMTogPEJyb2FkY29t IEJDTTU3MDQgQTMsIEFTSUMgcmV2LiAweDIwMDM+IG1lbSAweGZjOGMwMDAwLTB4ZmM4Y2ZmZmYs MHhmYzgzMDAwMC0weGZjODNmZmZmIGlycSAyNSBhdCBkZXZpY2UgOS4xIG9uIHBjaTINCm1paWJ1 czE6IDxNSUkgYnVzPiBvbiBiZ2UxDQpicmdwaHkxOiA8QkNNNTcwNCAxMC8xMDAvMTAwMGJhc2VU WCBQSFk+IG9uIG1paWJ1czENCmJyZ3BoeTE6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFz ZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8NCmJnZTE6 IEV0aGVybmV0IGFkZHJlc3M6IDAwOmUwOjgxOjMzOjdlOjliDQpwY2liMzogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAxMS4wIG9uIHBjaTANCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIzDQphbXIwOiA8TFNJTG9naWMgTWVnYVJBSUQgMS41Mz4gbWVtIDB4ZmY0ZjAwMDAtMHhm ZjRmZmZmZiBpcnEgMjkgYXQgZGV2aWNlIDEuMCBvbiBwY2kxDQphbXIwOiBVc2luZyA2NC1iaXQg RE1BDQphbXIwOiBkZWxldGUgbG9naWNhbCBkcml2ZXMgc3VwcG9ydGVkIGJ5IGNvbnRyb2xsZXIN CmFtcjA6IDxMU0lMb2dpYyBNZWdhUkFJRCBTQVRBIDE1MC00RD4gRmlybXdhcmUgNzEzRywgQklP UyBHMTE3LCA2NE1CIFJBTQ0KYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMA0K YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJx IDEgb24gYWNwaTANCmF0a2JkMDogPEFUIEtleWJvYXJkPiBmbGFncyAweDEwMCBpcnEgMSBvbiBh dGtiZGMwDQprYmQwIGF0IGF0a2JkMA0KYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0Kc2lvMDogY29u ZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnNpbzA6IHBvcnQg bWF5IG5vdCBiZSBlbmFibGVkDQpzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBv cnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMA0Kc2lvMDogdHlwZSAxNjU1 MEEsIGNvbnNvbGUNCnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9i ZWQgaXJxcyAwDQpzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZA0Kc2lvMTogPDE2NTUwQS1j b21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwDQpzaW8x OiB0eXBlIDE2NTUwQQ0KZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyIChGREUpPiBwb3J0 IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwDQpmZGMwOiBbRkFTVF0NCm9y bTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4 Y2M3ZmYgb24gaXNhMA0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlz YTANCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDEwMD4NCnZnYTA6IDxH ZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZm IG9uIGlzYTANCnVjb20wOiB2ZW5kb3IgMHgwNjdiIHByb2R1Y3QgMHgyMzAzLCByZXYgMS4xMC8y LjAyLCBhZGRyIDINCnVodWI3OiBBTENPUiBHZW5lcmljIFVTQiBIdWIsIGNsYXNzIDkvMCwgcmV2 IDEuMTAvMy4xMiwgYWRkciAyDQp1aHViNzogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQNCnVjb20xOiBQcm9saWZpYyBUZWNobm9sb2d5IEluYy4gVVNCLVNlcmlhbCBDb250 cm9sbGVyLCByZXYgMS4xMC8zLjAwLCBhZGRyIDMNCnVjb20yOiBQcm9saWZpYyBUZWNobm9sb2d5 IEluYy4gVVNCLVNlcmlhbCBDb250cm9sbGVyLCByZXYgMS4xMC8zLjAwLCBhZGRyIDQNCnVjb20z OiBQcm9saWZpYyBUZWNobm9sb2d5IEluYy4gVVNCLVNlcmlhbCBDb250cm9sbGVyLCByZXYgMS4x MC8zLjAwLCBhZGRyIDUNCnVjb200OiBQcm9saWZpYyBUZWNobm9sb2d5IEluYy4gVVNCLVNlcmlh bCBDb250cm9sbGVyLCByZXYgMS4xMC8zLjAwLCBhZGRyIDYNClRpbWVjb3VudGVycyB0aWNrIGV2 ZXJ5IDEuMDAwIG1zZWMNCldhaXRpbmcgMTAgc2Vjb25kcyBmb3IgU0NTSSBkZXZpY2VzIHRvIHNl dHRsZQ0KYWQ0OiAxOTA3ODJNQiA8U2VhZ2F0ZSBTVDMyMDA4MjJBUyAzLjAxPiBhdCBhdGEyLW1h c3RlciBTQVRBMTUwDQphbXIwOiBkZWxldGUgbG9naWNhbCBkcml2ZXMgc3VwcG9ydGVkIGJ5IGNv bnRyb2xsZXINCmFtcmQwOiA8TFNJTG9naWMgTWVnYVJBSUQgbG9naWNhbCBkcml2ZT4gb24gYW1y MA0KYW1yZDA6IDExNDQ2NDdNQiAoMjM0NDIzNzA1NiBzZWN0b3JzKSBSQUlEIDUgKG9wdGltYWwp DQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ0czFnIGlzIHVmcy9hbWFuZGEuDQpH RU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ0czFoIGlzIHVmcy9taXNjLg0KR0VPTV9M QUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFtcmQwczFkIGlzIHVmcy9ob21lLg0KR0VPTV9MQUJF TDogTGFiZWwgZm9yIHByb3ZpZGVyIGFtcmQwczFlIGlzIHVmcy9hcmNoaXZlLg0KR0VPTV9MQUJF TDogTGFiZWwgZm9yIHByb3ZpZGVyIGFtcmQwczFmIGlzIHVmcy9tbWVkaWEuDQoocHJvYmU4OmFo ZDA6MDo4OjApOiBHb3QgQ0hFQ0sgQ09ORElUSU9ODQoocHJvYmU4OmFoZDA6MDo4OjApOiBNT0RF IFNFTlNFKDA2KS4gQ0RCOiAxYSAwIGEgMCAxNCAwIA0KKHByb2JlODphaGQwOjA6ODowKTogVU5J VCBBVFRFTlRJT04gYXNjOjI5LDINCihwcm9iZTg6YWhkMDowOjg6MCk6IFNjc2kgYnVzIHJlc2V0 IG9jY3VycmVkIGZpZWxkIHJlcGxhY2VhYmxlIHVuaXQ6IDINCihwcm9iZTg6YWhkMDowOjg6MCk6 IGNhbXBlcmlwaHNjc2lzZW5zZWVycm9yIGNjYl9oIHN0YXR1cyBjYyBjY2JfaCBmbGFncyA0MCBj c2lvIHN0YXR1cyAyIGFjdGlvbiAxMDEwNSByZXRyeSAzDQpkYTAgYXQgYWhkMCBidXMgMCB0YXJn ZXQgMCBsdW4gMA0KZGEwOiA8UVVBTlRVTSBBVExBU19WXzM2X1dMUyAwMjMwPiBGaXhlZCBEaXJl Y3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgDQpkYTA6IDgwLjAwME1CL3MgdHJhbnNmZXJzICg0MC4w MDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEwOiAz NTAyME1CICg3MTcyMjc3NiA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDQ0NjRDKQ0KZGEx IGF0IGFoZDAgYnVzIDAgdGFyZ2V0IDggbHVuIDANCmRhMTogPFNFQUdBVEUgU1gxNzM0MDRMQyBC RDBBPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgDQpkYTE6IDgwLjAwME1CL3Mg dHJhbnNmZXJzICg0MC4wMDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcg RW5hYmxlZA0KZGExOiA3MDAwN01CICgxNDMzNzQ3MzggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2 M1MvVCA4OTI0QykNClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQ0KKGNkMDp1bWFzcy1zaW0wOjA6 MDowKTogR290IENIRUNLIENPTkRJVElPTg0KKGNkMDp1bWFzcy1zaW0wOjA6MDowKTogUkVBRCBD RCBSRUNPUkRFRCBDQVBBQ0lUWS4gQ0RCOiAyNSAwIDAgMCAwIDAgMCAwIDAgMCANCihjZDA6dW1h c3Mtc2ltMDowOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMA0KKGNkMDp1bWFzcy1zaW0wOjA6MDow KTogTWVkaXVtIG5vdCBwcmVzZW50DQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBjYW1wZXJpcGhz Y3Npc2Vuc2VlcnJvciBjY2JfaCBzdGF0dXMgOGMgY2NiX2ggZmxhZ3MgNDAgY3NpbyBzdGF0dXMg MiBhY3Rpb24gMjAwMDYgcmV0cnkgMQ0KY2QwIGF0IHVtYXNzLXNpbTAgYnVzIDAgdGFyZ2V0IDAg bHVuIDANCmNkMDogPF9ORUMgRFZEX1JXIE5ELTI1MTBBIDIuMTU+IFJlbW92YWJsZSBDRC1ST00g U0NTSS0wIGRldmljZSANCmNkMDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMNCmNkMDogQXR0ZW1wdCB0 byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50 DQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBHb3QgQ0hFQ0sgQ09ORElUSU9ODQooY2QwOnVtYXNz LXNpbTA6MDowOjApOiBSRUFEIENEIFJFQ09SREVEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAg MCAwIDAgMCAwIA0KKGNkMDp1bWFzcy1zaW0wOjA6MDowKTogTk9UIFJFQURZIGFzYzozYSwwDQoo Y2QwOnVtYXNzLXNpbTA6MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQNCihjZDA6dW1hc3Mtc2lt MDowOjA6MCk6IGNhbXBlcmlwaHNjc2lzZW5zZWVycm9yIGNjYl9oIHN0YXR1cyA4YyBjY2JfaCBm bGFncyA0MCBjc2lvIHN0YXR1cyAyIGFjdGlvbiAyMDAwNiByZXRyeSAxDQooY2QwOnVtYXNzLXNp bTA6MDowOjApOiBHb3QgQ0hFQ0sgQ09ORElUSU9ODQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBS RUFEIENEIFJFQ09SREVEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAgMCAwIDAgMCAwIA0KKGNk MDp1bWFzcy1zaW0wOjA6MDowKTogTk9UIFJFQURZIGFzYzozYSwwDQooY2QwOnVtYXNzLXNpbTA6 MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQNCihjZDA6dW1hc3Mtc2ltMDowOjA6MCk6IGNhbXBl cmlwaHNjc2lzZW5zZWVycm9yIGNjYl9oIHN0YXR1cyA4YyBjY2JfaCBmbGFncyA0MCBjc2lvIHN0 YXR1cyAyIGFjdGlvbiAyMDAwNiByZXRyeSAxDQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBHb3Qg Q0hFQ0sgQ09ORElUSU9ODQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBSRUFEIENEIFJFQ09SREVE IENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAgMCAwIDAgMCAwIA0KKGNkMDp1bWFzcy1zaW0wOjA6 MDowKTogTk9UIFJFQURZIGFzYzozYSwwDQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBNZWRpdW0g bm90IHByZXNlbnQNCihjZDA6dW1hc3Mtc2ltMDowOjA6MCk6IGNhbXBlcmlwaHNjc2lzZW5zZWVy cm9yIGNjYl9oIHN0YXR1cyA4YyBjY2JfaCBmbGFncyA0MCBjc2lvIHN0YXR1cyAyIGFjdGlvbiAy MDAwNiByZXRyeSAxDQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBHb3QgQ0hFQ0sgQ09ORElUSU9O DQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBSRUFEIENEIFJFQ09SREVEIENBUEFDSVRZLiBDREI6 IDI1IDAgMCAwIDAgMCAwIDAgMCAwIA0KKGNkMDp1bWFzcy1zaW0wOjA6MDowKTogTk9UIFJFQURZ IGFzYzozYSwwDQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQNCihj ZDA6dW1hc3Mtc2ltMDowOjA6MCk6IGNhbXBlcmlwaHNjc2lzZW5zZWVycm9yIGNjYl9oIHN0YXR1 cyA4YyBjY2JfaCBmbGFncyA0MCBjc2lvIHN0YXR1cyAyIGFjdGlvbiAyMDAwNiByZXRyeSAxDQpH RU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczFlIGlzIHVmcy9zcmMuDQpHRU9NX0xB QkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczFmIGlzIHVmcy9jdnMuDQpHRU9NX0xBQkVMOiBM YWJlbCBmb3IgcHJvdmlkZXIgZGEwczFnIGlzIHVmcy9tbnQuDQpHRU9NX0xBQkVMOiBMYWJlbCBm b3IgcHJvdmlkZXIgZGExczFlIGlzIHVmcy9vYmouDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJv dmlkZXIgZGExczFmIGlzIHVmcy9wb3J0cy4NCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRl ciBkYTFzMWcgaXMgdWZzL3NwYXJlLg0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rl di9hZDRzMWENCldBUk5JTkc6IC8gd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQpXQVJOSU5H OiAvdXNyIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZA0KV0FSTklORzogL3ZhciB3YXMgbm90 IHByb3Blcmx5IGRpc21vdW50ZWQNCi92YXI6IG1vdW50IHBlbmRpbmcgZXJyb3I6IGJsb2NrcyAy MTgzNiBmaWxlcyAyDQpXQVJOSU5HOiAvdXNyL2xvY2FsIHdhcyBub3QgcHJvcGVybHkgZGlzbW91 bnRlZA0KV0FSTklORzogL2FtYW5kYSB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQNCldBUk5J Tkc6IC9taXNjIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZA0KV0FSTklORzogL3Vzci9zcmMg d2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQpXQVJOSU5HOiAvY3ZzIHdhcyBub3QgcHJvcGVy bHkgZGlzbW91bnRlZA0KV0FSTklORzogL21udCB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQN CldBUk5JTkc6IC91c3Ivb2JqIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZA0KV0FSTklORzog L3Vzci9wb3J0cyB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQNCldBUk5JTkc6IC9zcGFyZSB3 YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQNCldBUk5JTkc6IC9ob21lIHdhcyBub3QgcHJvcGVy bHkgZGlzbW91bnRlZA0KL2hvbWU6IG1vdW50IHBlbmRpbmcgZXJyb3I6IGJsb2NrcyAxNiBmaWxl cyA0DQpXQVJOSU5HOiAvYXJjaGl2ZSB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQNCldBUk5J Tkc6IC9tbWVkaWEgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQpiZ2UwOiBsaW5rIHN0YXRl IGNoYW5nZWQgdG8gVVANCm== --=-6cmc0M+yL53x5izSzaGB Content-Disposition: attachment; filename=JILL Content-Transfer-Encoding: base64 Content-Type: text/plain; name=JILL; charset=ISO-8859-1 Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24gZmlsZSBmb3IgRnJl ZUJTRC9pMzg2DQojDQoNCm1hY2hpbmUJCWFtZDY0DQpjcHUJCUhBTU1FUgkJCSMgYWthIEs4LCBh a2EgT3B0ZXJvbiAmIEF0aGxvbjY0DQppZGVudAkJUkVBTFRJTUUNCg0KbWF4dXNlcnMJNTEyDQoN Cm1ha2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRoIGdkYigxKSBkZWJ1ZyBz eW1ib2xzDQoNCm9wdGlvbnMJCUhaPTEwMDANCm9wdGlvbnMgCVNDSEVEXzRCU0QJCSMgNEJTRCBz Y2hlZHVsZXINCm9wdGlvbnMgCVBSRUVNUFRJT04JCSMgNEJTRCBzY2hlZHVsZXINCm9wdGlvbnMg CUlORVQJCQkjIEludGVyTkVUd29ya2luZw0Kb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBGYXN0 IEZpbGVzeXN0ZW0NCm9wdGlvbnMgCVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRh dGVzIHN1cHBvcnQNCm9wdGlvbnMgCVVGU19FWFRBVFRSDQpvcHRpb25zIAlVRlNfRVhUQVRUUl9B VVRPU1RBUlQNCm9wdGlvbnMgCVVGU19BQ0wJCQkjIFN1cHBvcnQgZm9yIGFjY2VzcyBjb250cm9s IGxpc3RzDQpvcHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJp ZyBkaXJlY3Rvcmllcw0KI29wdGlvbnMgCU1EX1JPT1QJCQkjIE1EIGlzIGEgcG90ZW50aWFsIHJv b3QgZGV2aWNlDQpvcHRpb25zIAlORlNDTElFTlQJCSMgTmV0d29yayBGaWxlc3lzdGVtIENsaWVu dA0Kb3B0aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXINCm9wdGlv bnMgCU5GU19ST09UCQkjIE5GUyB1c2FibGUgYXMgLywgcmVxdWlyZXMgTkZTQ0xJRU5UDQpvcHRp b25zIAlNU0RPU0ZTCQkJIyBNU0RPUyBGaWxlc3lzdGVtDQpvcHRpb25zIAlDRDk2NjAJCQkjIElT TyA5NjYwIEZpbGVzeXN0ZW0NCm9wdGlvbnMgCVBST0NGUwkJCSMgUHJvY2VzcyBmaWxlc3lzdGVt IChyZXF1aXJlcyBQU0VVRE9GUykNCm9wdGlvbnMgCVBTRVVET0ZTCQkjIFBzZXVkby1maWxlc3lz dGVtIGZyYW1ld29yaw0Kb3B0aW9ucyAJR0VPTV9HUFQJCSMgR1VJRCBQYXJ0aXRpb24gVGFibGVz Lg0Kb3B0aW9ucyAJQ09NUEFUXzQzCQkjIENvbXBhdGlibGUgd2l0aCBCU0QgNC4zIFtLRUVQIFRI SVMhXQ0Kb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNE NA0Kb3B0aW9ucyAJU0NTSV9ERUxBWT0xMDAwMAkjIERlbGF5IChpbiBtcykgYmVmb3JlIHByb2Jp bmcgU0NTSQ0Kb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydA0Kb3B0aW9ucyAJ U1lTVlNITQkJCSMgU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5DQpvcHRpb25zIAlTWVNWTVNHCQkJ IyBTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzDQpvcHRpb25zIAlTWVNWU0VNCQkJIyBTWVNWLXN0 eWxlIHNlbWFwaG9yZXMNCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAjIFBP U0lYIFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnNpb25zDQpvcHRpb25zIAlLQkRfSU5TVEFMTF9D REVWCSMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4gL2Rldg0Kb3B0aW9ucyAJQURBUFRJVkVfR0lB TlQJCSMgR2lhbnQgbXV0ZXggaXMgYWRhcHRpdmUuDQoNCiMgRGVidWdnaW5nIGZvciB1c2UgaW4g LWN1cnJlbnQNCm9wdGlvbnMJCUtEQgkJCSMgRW5hYmxlIGtlcm5lbCBkZWJ1Z2dlciBzdXBwb3J0 Lg0Kb3B0aW9ucwkJS0RCX1VOQVRURU5ERUQNCm9wdGlvbnMJCUREQgkJCSMgU3VwcG9ydCBEREIu DQpvcHRpb25zCQlHREIJCQkjIFN1cHBvcnQgcmVtb3RlIEdEQi4NCm9wdGlvbnMJCUJSRUFLX1RP X0RFQlVHR0VSDQojb3B0aW9ucwkJSU5WQVJJQU5UUw0KI29wdGlvbnMJCUlOVkFSSUFOVF9TVVBQ T1JUDQojb3B0aW9ucwkJV0lUTkVTUw0KI29wdGlvbnMJCVdJVE5FU1NfU0tJUFNQSU4NCg0KI29w dGlvbnMJCUtUUg0KI29wdGlvbnMJCUtUUl9FTlRSSUVTPTUyNDI4OA0KI29wdGlvbnMJCUtUUl9D T01QSUxFPShLVFJfSU5UUnxLVFJfUFJPQykNCiNvcHRpb25zCQlLVFJfTUFTSz0oS1RSX0dFTnxL VFJfREVWfEtUUl9JTlRSfEtUUl9JT3xLVFJfRVZIfEtUUl9WRlN8S1RSX0NBTExPVVR8S1RSX0dF T018S1RSX0JVRnxLVFJfQ1QxfEtUUl9DVDJ8S1RSX0NUM3xLVFJfQ1Q0fEtUUl9DVDV8S1RSX0NU NnxLVFJfQ1Q3fEtUUl9DVDgpDQojb3B0aW9ucwkJS1RSX0NQVU1BU0s9MHgzDQojb3B0aW9ucwkJ S1RSX1ZFUkJPU0UNCg0Kb3B0aW9ucyAJQ09NUEFUX0lBMzINCm9wdGlvbnMgCUNPTVBBVF9MSU5V WDMyDQpvcHRpb25zIAlMSU5QUk9DRlMJCSMgQ2Fubm90IGJlIGEgbW9kdWxlIHlldC4NCg0Kb3B0 aW9ucyAJTElCSUNPTlYNCg0KI29wdGlvbnMJCUlQU0VDCQkJI0lQIHNlY3VyaXR5DQojb3B0aW9u cwkJSVBTRUNfRVNQCQkjSVAgc2VjdXJpdHkgKGNyeXB0bzsgZGVmaW5lIHcvIElQU0VDKQ0KDQpv cHRpb25zCQlNQVhEU0laPSgxMDI0VUwqMTAyNCoxMDI0KQ0Kb3B0aW9ucwkJTUFYU1NJWj0oNTEy VUwqMTAyNCoxMDI0KQ0Kb3B0aW9ucwkJREZMRFNJWj0oMTAyNFVMKjEwMjQqMTAyNCkNCg0KIyBU byBtYWtlIGFuIFNNUCBrZXJuZWwsIHRoZSBuZXh0IHR3byBhcmUgbmVlZGVkDQpvcHRpb25zIAlT TVAJCSMgU3ltbWV0cmljIE11bHRpUHJvY2Vzc29yIEtlcm5lbA0KDQpkZXZpY2UJCWFjcGkNCmRl dmljZQkJcGNpDQoNCiMgRmxvcHB5IGRyaXZlcw0KZGV2aWNlCQlmZGMNCg0KIyBBVEEgYW5kIEFU QVBJIGRldmljZXMNCmRldmljZQkJYXRhDQpkZXZpY2UJCWF0YWRpc2sJCSMgQVRBIGRpc2sgZHJp dmVzDQpkZXZpY2UJCWF0YXJhaWQJCSMgQVRBIFJBSUQgZHJpdmVzDQpkZXZpY2UJCWF0YXBpY2QJ CSMgQVRBUEkgQ0RST00gZHJpdmVzDQpkZXZpY2UJCWF0YXBpZmQJCSMgQVRBUEkgZmxvcHB5IGRy aXZlcw0KZGV2aWNlCQlhdGFwaXN0CQkjIEFUQVBJIHRhcGUgZHJpdmVzDQpvcHRpb25zIAlBVEFf U1RBVElDX0lECSMgU3RhdGljIGRldmljZSBudW1iZXJpbmcNCg0KIyBTQ1NJIENvbnRyb2xsZXJz DQpkZXZpY2UJCXN5bQkJIyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3ZXIgY2hpcHNldHMgKyB0aG9z ZSBvZiBgbmNyJykNCm9wdGlvbnMgCVNZTV9TRVRVUF9NQVhfTFVOPTY0DQoNCiMgU0NTSSBwZXJp cGhlcmFscw0KZGV2aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kpDQpk ZXZpY2UJCWNoCQkjIFNDU0kgbWVkaWEgY2hhbmdlcnMNCmRldmljZQkJZGEJCSMgRGlyZWN0IEFj Y2VzcyAoZGlza3MpDQpkZXZpY2UJCXNhCQkjIFNlcXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykN CmRldmljZQkJY2QJCSMgU0NTSSBDRC1ST01zDQpkZXZpY2UJCXNlcwkJIyBTQ1NJIEVudmlyb25t ZW50YWwgU2VydmljZXMgKGFuZCBTQUYtVEUpDQpkZXZpY2UJCXB0CQkjIFNDU0kgcHJvY2Vzc29y DQpkZXZpY2UJCXRhcmcJCSMgU0NTSSBUYXJnZXQgTW9kZSBDb2RlDQpkZXZpY2UJCXRhcmdiaAkJ IyBTQ1NJIFRhcmdldCBNb2RlIEJsYWNraG9sZSBEZXZpY2UNCmRldmljZQkJcGFzcwkJIyBDQU0g cGFzc3Rocm91Z2ggZHJpdmVyDQoNCm9wdGlvbnMJCUNBTURFQlVHDQoNCiMgYXRrYmRjMCBjb250 cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhlIFBTLzIgbW91c2UNCmRldmljZQkJYXRrYmRj CQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXINCmRldmljZQkJYXRrYmQJCSMgQVQga2V5Ym9hcmQN CmRldmljZQkJcHNtCQkjIFBTLzIgbW91c2UNCg0KZGV2aWNlCQlrYmRtdXgJCSMga2V5Ym9hcmQg bXVsdGlwbGV4ZXINCg0KZGV2aWNlCQl2Z2EJCSMgVkdBIHZpZGVvIGNhcmQgZHJpdmVyDQoNCmRl dmljZQkJc3BsYXNoCQkjIFNwbGFzaCBzY3JlZW4gYW5kIHNjcmVlbiBzYXZlciBzdXBwb3J0DQoN CiMgc3lzY29ucyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBhbiBT Q08gY29uc29sZQ0KZGV2aWNlCQlzYw0KDQpkZXZpY2UJCWFncA0KDQojIFNlcmlhbCAoQ09NKSBw b3J0cw0KZGV2aWNlCQlzaW8JCSMgODI1MCwgMTZbNDVdNTAgYmFzZWQgc2VyaWFsIHBvcnRzDQoN CiMgUGFyYWxsZWwgcG9ydA0KI2RldmljZQkJcHBjDQojZGV2aWNlCQlwcGJ1cwkJIyBQYXJhbGxl bCBwb3J0IGJ1cyAocmVxdWlyZWQpDQojZGV2aWNlCQlscHQJCSMgUHJpbnRlcg0KI2RldmljZQkJ cHBpCQkjIFBhcmFsbGVsIHBvcnQgaW50ZXJmYWNlIGRldmljZQ0KDQojIFBzZXVkbyBkZXZpY2Vz Lg0KZGV2aWNlCQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sNCmRldmljZQkJbWVtCQkjIE1lbW9y eSBhbmQga2VybmVsIG1lbW9yeSBkZXZpY2VzDQpkZXZpY2UJCWlvCQkjIEkvTyBkZXZpY2UNCmRl dmljZQkJcmFuZG9tCQkjIEVudHJvcHkgZGV2aWNlDQpkZXZpY2UJCWV0aGVyCQkjIEV0aGVybmV0 IHN1cHBvcnQNCiNkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVsLg0KZGV2aWNlCQlwdHkJCSMg UHNldWRvLXR0eXMgKHRlbG5ldCBldGMpDQpkZXZpY2UJCW1kCQkjIE1lbW9yeSAiZGlza3MiDQoj ZGV2aWNlCQlnaWYJCSMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcNCiNkZXZpY2UJCWZhaXRoCQkj IElQdjYtdG8tSVB2NCByZWxheWluZyAodHJhbnNsYXRpb24pDQoNCiMgVGhlIGBicGYnIGRldmlj ZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLg0KIyBCZSBhd2FyZSBvZiB0aGUg YWRtaW5pc3RyYXRpdmUgY29uc2VxdWVuY2VzIG9mIGVuYWJsaW5nIHRoaXMhDQpkZXZpY2UJCWJw ZgkJIyBCZXJrZWxleSBwYWNrZXQgZmlsdGVyDQoNCiMgVVNCIHN1cHBvcnQNCmRldmljZQkJdWhj aQkJIyBVSENJIFBDSS0+VVNCIGludGVyZmFjZQ0KZGV2aWNlCQlvaGNpCQkjIE9IQ0kgUENJLT5V U0IgaW50ZXJmYWNlDQpkZXZpY2UJCWVoY2kNCmRldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVp cmVkKQ0KI2RldmljZQkJdWRicAkJIyBVU0IgRG91YmxlIEJ1bGsgUGlwZSBkZXZpY2VzDQpkZXZp Y2UJCXVnZW4JCSMgR2VuZXJpYw0KZGV2aWNlCQl1aGlkCQkjICJIdW1hbiBJbnRlcmZhY2UgRGV2 aWNlcyINCmRldmljZQkJdWtiZAkJIyBLZXlib2FyZA0KZGV2aWNlCQl1bHB0CQkjIFByaW50ZXIN CmRldmljZQkJdW1hc3MJCSMgRGlza3MvTWFzcyBzdG9yYWdlIC0gUmVxdWlyZXMgc2NidXMgYW5k IGRhDQpkZXZpY2UJCXVtcwkJIyBNb3VzZQ0KI2RldmljZQkJdXJpbwkJIyBEaWFtb25kIFJpbyA1 MDAgTVAzIHBsYXllcg0KZGV2aWNlCQl1c2Nhbm5lcgkjIFNjYW5uZXJzDQojIFVTQiBFdGhlcm5l dCwgcmVxdWlyZXMgbWlpDQojZGV2aWNlCQlhdWUJCSMgQURNdGVrIFVTQiBFdGhlcm5ldA0KI2Rl dmljZQkJYXhlCQkjIEFTSVggRWxlY3Ryb25pY3MgVVNCIEV0aGVybmV0DQojZGV2aWNlCQljdWUJ CSMgQ0FUQyBVU0IgRXRoZXJuZXQNCiNkZXZpY2UJCWt1ZQkJIyBLYXdhc2FraSBMU0kgVVNCIEV0 aGVybmV0DQojZGV2aWNlCQlydWUJCSMgUmVhbFRlayBSVEw4MTUwIFVTQiBFdGhlcm5ldA0KDQoj IEZpcmVXaXJlIHN1cHBvcnQNCiNkZXZpY2UJCWZpcmV3aXJlCSMgRmlyZVdpcmUgYnVzIGNvZGUN CiNkZXZpY2UJCXNicAkJIyBTQ1NJIG92ZXIgRmlyZVdpcmUgKFJlcXVpcmVzIHNjYnVzIGFuZCBk YSkNCiNkZXZpY2UJCWZ3ZQkJIyBFdGhlcm5ldCBvdmVyIEZpcmVXaXJlIChub24tc3RhbmRhcmQh KQ0K --=-6cmc0M+yL53x5izSzaGB--